Validation and Rules

Validation in 6.0 is part of the runtime workflow, not a side concern.

What validation covers

The current public architecture calls out a few major validation areas:

  • grid occupancy
  • bounds and terrain checks
  • placeable constraints
  • manipulation constraints

Those checks gate whether placement or manipulation can proceed.

Where validation lives

The 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 rules

That means you should not expect 6.0 validation to behave like 5.0-era node scripts with loosely shared state.

Typical validation sequence

The supported validation flow is roughly this:

  1. check bounds
  2. check occupancy
  3. check placeable constraints
  4. check manipulation-specific constraints when relevant
  5. return a validation result object that the next stage can act on

Why this matters for migration

If 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

Validated By

  • cs/Core/Tests/WorkflowCoverage/PlacementManipulationEndToEndTests.cs (coverage target under repair on the audited branch)
  • the current release-readiness guidance for the 6.0 internal development line