World Bootstrap and System Order

The 6.0 runtime is not just a bag of systems. It depends on predictable bootstrap steps and an explicit ordering model.

Bootstrap sequence

The high-level shape is:

create the Friflo EntityStore
register the supported systems
initialize the services and adapter dependencies
load placeable and resource data
create initial runtime entities such as cursor or preview state

That sequence matters because placement validation, occupancy updates, and visual feedback all depend on earlier state being in place.

Ordering principles

input before validation so requests reflect the latest intent
validation before execution so invalid requests never look committed
execution before visuals so previews and indicators mirror committed state instead of stale state
cleanup last so end-of-frame removals do not break earlier systems

Example system categories

The supported 6.0 runtime groups systems roughly like this:

input routing and targeting
manipulation input handling
placement validation
occupancy tracking
placement and manipulation execution
indicator mapping and visuals
preview and cleanup systems

The exact class inventory may evolve, but the ordering rules should remain stable.

Why the docs are cautious here

The repository is still approaching GA, so this site is documenting the supported internal development flow, not pretending every historical test lane has already converged on one clean solution.

For public consumers, the important point is that 6.0 expects a real world bootstrap process rather than ad hoc node-first wiring.

When to revisit ordering

Revisit this page when:

you add or remove placement stages
a new adapter boundary changes where input or visuals are handled
a workflow coverage test proves a different ordering requirement

Validated By

dotnet build cs/Core/ECS/GridPlacement.ECS.csproj --nologo -v minimal
cs/Core/Tests/WorkflowCoverage/PlacementManipulationEndToEndTests.cs