Plugin Boundaries
6.0 is trying to become easier to integrate and easier to change internally. That only works if the public and internal boundaries stay explicit.
Public APIs first
The supported public guides call out these kinds of public-facing surfaces:
- placement services
- input or targeting service contracts when exposed
- application-facing facades that compose runtime work for consumers
Those are the APIs a consuming game should prefer.
What should stay internal
Consumers should avoid coupling to:
- low-level ECS implementation details that are not intentionally documented as stable
- Godot adapter internals used only to bridge the runtime into scenes and nodes
- historical compatibility layers that exist to keep older tests or experiments alive
Why this boundary matters now
6.0 is still in internal development.
That means internal implementations may keep shifting while the supported public story is stabilized. If external integrators build on the wrong surface, they inherit internal churn that the docs should have warned them away from.
Godot boundary rule
The canonical Godot plugin code home for 6.0 is:
cs/Godot/addons/GridPlacement/
Legacy grid_building paths belong to the 5.0 maintenance line or compatibility assets, not to the current 6.0 architecture story.
Public documentation rule
If a page needs to explain behavior, it should describe:
- what the consumer can rely on
- what commands and guides are the proof source
- what is still subject to internal development churn
That is better than leaking internal type graphs into every public guide.
Validated By
- the current v6.0 guides index
- the current v6.0 API reference