docs: progression CONTEXT, ADRs 0001-0004, phase A plan

ignore .idea/ .superpowers/ bin/ obj/; drop 3 identical csproj backups

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

@@ -0,0 +1,21 @@
+# 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.