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 sequenceThe high-level shape is:1. create the **Friflo EntityStore**2. register the supported systems3. initialize the services and adapter dependencies4. load placeable and resource data5. create initial runtime entities such as cursor or preview stateThat 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 categoriesThe 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 systemsThe exact class inventory may evolve, but the ordering rules should remain stable.## Why the docs are cautious hereThe 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 orderingRevisit 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