editor-engine-functionality

To structure editor features without bloating React, enforce an engine-first implementation model where runtime behavior is managed by engine services and React serves solely as a visual adapter. This ensures core logic resides within the engine, leading to cleaner architecture.

To add a new gizmo using an engine-first workflow, define the feature API on `engine.editor` first, implement the gizmo's runtime behavior in engine-owned services, and then build the visual representation and interaction dispatch in React.

The best way to refactor editor tool modes and selection logic is to define feature APIs on `engine.editor` and implement the behavior in engine-owned services. This enforces architecture rules where the engine owns runtime logic and React owns presentation.

The engine should own runtime logic for editor transforms because it enforces a structured workflow where core behavior resides in engine services. React acts only as a visual adapter, which results in a cleaner, more maintainable architecture with minimal manager APIs and strict typing.

No, React should not own editor placement logic. The engine-first model requires that runtime behavior for placement is implemented in engine services, while React is restricted to handling only visual representation and dispatching user interactions.

Yes, TypeScript is required to implement engine-first editor functionality. The architecture focuses on minimal manager APIs and strict typing, using TypeScript to enforce the separation between engine-owned runtime logic and React presentation.