Validation and Rules

-Validation in 6.0 is part of the runtime workflow, not a side concern.## What validation coversThe current public architecture calls out a few major validation areas:- grid occupancy- bounds and terrain checks- placeable constraints- manipulation constraintsThose checks gate whether placement or manipulation can proceed.## Where validation livesThe public repository direction is:- Core and ECS code own the main business checks and result reporting- Godot adapters translate engine data into the runtime world instead of quietly rewriting the rulesThat means you should not expect 6.0 validation to behave like 5.0-era node scripts with loosely shared state.## Typical validation sequenceThe supported validation flow is roughly this:1. check bounds2. check occupancy3. check placeable constraints4. check manipulation-specific constraints when relevant5. return a validation result object that the next stage can act on## Why this matters for migrationIf you are coming from 5.0, the key shift is not just “ECS exists now”.The important shift is that validation is meant to be more explicit, better typed, and easier to verify through focused workflow tests, even though the current workflow suite is still under repair on the audited branch.## Public guidance- treat validation as part of the supported pipeline, not an afterthought- do not assume a node tree callback is the real source of truth for whether a request is valid- follow the workflow coverage lane when you need to confirm what behavior is intended to be proven today, and verify that it passes on your branch first