Systems Flow

-The 6.0 runtime is easier to understand if you stop thinking in terms of isolated ECS types and instead think in terms of flow.## Four main stages### 1. InputInput systems and adapters translate player intent into runtime requests.Typical responsibilities include:- cursor or target updates- manipulation commands- placement requests### 2. ValidationValidation systems inspect the current grid, occupancy, constraints, and mode state.This stage should answer one question clearly: can the requested operation proceed right now?### 3. ExecutionExecution systems commit valid placement or manipulation operations.This is where the runtime updates occupancy, entity state, and long-lived results.### 4. Visual reflectionPreview, indicator, or Godot-side systems reflect the updated state back into visuals.In 6.0, that visual layer is not supposed to own the business rules.## Why this matters for public docsOlder 6.0 drafts blurred architecture talk with GECS-specific details that no longer match the codebase. This flow is the stable public framing that better matches the repository today.If you are integrating GridPlacement into a game, this sequence is more useful than memorizing every internal type on day one.## Public takeaway- input and Godot nodes produce requests- validation decides whether work is allowed- execution changes the authoritative runtime state- visuals follow the authoritative stateThat is the 6.0 mental model the rest of the public docs should preserve.