# 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.