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 firstThe 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 consumersThose are the APIs a consuming game should prefer.## What should stay internalConsumers 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 now6.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 ruleThe 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 ruleIf 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 churnThat is better than leaking internal type graphs into every public guide.