What problem does it solve? When modifying the SparkEngine C++23 game engine, it is easy to break load-bearing design rules—adding a global subsystem pointer that is null inside game-module DLLs, registering an ECS system in the wrong phase, or hard-coding a GPU backend that breaks headless CI. This Skill states the engine's six architectural invariants, the reasoning behind each, and the exact failure mode caused by violating them. ## Core Features & Use Cases - Subsystem ownership rules: Defines that EngineRuntime owns all subsystems and EngineContext acts as the single service locator, including the non-const type-id trick that prevents Release-only ICF folding bugs. - DLL boundary guidance: Explains how the host injects EngineContext into game-module DLLs and why per-module singletons cause duplicate subsystems. - ECS phase topology: Documents the canonical PhaseSystemManager registration point and the fixed Physics-to-Render ordering, plus wiring verification via tools/check-wiring.sh. - Use Case: Before adding a new audio subsystem, consult this Skill to learn it must be owned by EngineRuntime, registered with RegisterSubsystem and dependency ordering, fetched via EngineContext::Get(), and wired into the real startup and frame loop in the same change. ## Quick Start Ask the AI to review your planned SparkEngine subsystem change against the architecture contract invariants before writing any code.
