przygody-pana-cegly/docs/adr/0004-domain-does-not-reference-godot.md

The progression domain does not reference Godot

The progression domain lives in its own assembly with no Godot reference. Aggregates raise plain C# event records as part of their operations, and a single adapter republishes those as EventBus signals. This is the only enforceable version of the goal — correctness checkable without a scene tree, with the compiler enforcing the rule rather than discipline. The leak it removes was already visible: PlayerState documented itself as a POCO "for predictable state management" while holding List<SkillData>, and SkillData : Resource, which is why saves had to store skill names and re-resolve them through SkillManager on load.

Republishing rather than replacing EventBus keeps existing scene wiring and subscribers intact, and makes "state changed ⇒ signal fired" un-bypassable — the original defect, where ConsoleManager mutated state directly and re-emitted signals by hand, sometimes without the invariants the store's own operations applied.

Consequences

• GameStateStore stops being a Node. The autoload becomes a composition root that owns the aggregates, so the aggregates' lifetime is no longer tied to the scene tree and most Store?. null-guards disappear.
• Skill progression cannot live on SkillData. A Resource is one cached instance per process, so with save slots it would leak levels between Playthroughs.
• Godot types (Vector2, Mathf, GD.Print) are not available in the domain; where they appear today they are replaced by domain values or moved to adapters.