World Bootstrap and System Order
The 6.0 runtime is not just a bag of services. It depends on predictable bootstrap steps and an explicit ordering model.
Bootstrap sequence
The high-level shape is:
- create the runtime entity store
- register the supported placement and manipulation services
- initialize the services and adapter dependencies
- load placeable and resource data
- create initial runtime state 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 stages
Example runtime stage categories
The supported 6.0 runtime groups work 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 stages
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 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