Pipeline integrity + brownfield adoption system

Pipeline integrity (4 fixes for snapshot-vs-live-reference problem):
- NEW docs/architecture/tr-registry.yaml: persistent stable TR-IDs per GDD
  requirement; /architecture-review bootstraps and appends, never renumbers
- /create-control-manifest: added Manifest Version stamp to header
- /create-epics-stories: stories embed TR-ID reference (not quoted text),
  Manifest Version from manifest, ADR status gate (Proposed → Blocked)
- /story-done: TR-ID registry lookup at review time, manifest staleness check
- /story-readiness: ADR Accepted check, TR-ID validity, manifest version check
- /review-all-gdds + /architecture-review: fixed parenthetical status values
  ("Needs Revision" only, no parentheticals that break exact-match reads)

Workflow infrastructure:
- NEW /help skill: context-aware "what's next" using workflow-catalog.yaml
- NEW .claude/docs/workflow-catalog.yaml: YAML-driven phase/step sequence
- /sprint-plan + /sprint-status: sprint-status.yaml machine-written tracking

Brownfield adoption system (migrate, not replace):
- NEW /adopt skill: format compliance audit (not existence check); classifies
  gaps BLOCKING/HIGH/MEDIUM/LOW; produces docs/adoption-plan-[date].md with
  numbered migration plan; never regenerates existing artifacts
- /design-system retrofit [path]: fills only missing GDD sections, preserves
  all existing content
- /architecture-decision retrofit [path]: adds missing ADR sections (Status,
  ADR Dependencies, Engine Compatibility) without touching existing content
- /start option D: split into D1 (early-stage) and D2 (has GDDs/ADRs → adopt)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.claude/skills/story-done/SKILL.md

@@ -40,7 +40,8 @@ read that file directly.
 Read the full story file. Extract and hold in context:
 
 - **Story name and ID**
-- **GDD Requirement ID(s)** referenced
+- **GDD Requirement TR-ID(s)** referenced (e.g., `TR-combat-001`)
+- **Manifest Version** embedded in the story header (e.g., `2026-03-10`)
 - **ADR reference(s)** referenced
 - **Acceptance Criteria** — the complete list (every checkbox item)
 - **Implementation files** — files listed under "files to create/modify"
@@ -49,9 +50,15 @@ Read the full story file. Extract and hold in context:
 - **Estimated vs actual scope** — if an estimate was noted
 
 Also read:
+- `docs/architecture/tr-registry.yaml` — look up each TR-ID in the story.
+  Read the *current* `requirement` text from the registry entry. This is the
+  source of truth for what the GDD required — do not use any requirement text
+  that may be quoted inline in the story (it may be stale).
 - The referenced GDD section — just the acceptance criteria and key rules, not
-  the full document
+  the full document. Use this to cross-check the registry text is still accurate.
 - The referenced ADR(s) — just the Decision and Consequences sections
+- `docs/architecture/control-manifest.md` header — extract the current
+  `Manifest Version:` date (used in Phase 4 staleness check)
 
 ---
 
@@ -96,19 +103,29 @@ Compare the implementation against the design documents.
 
 Run these checks automatically:
 
-1. **GDD rules check**: Read the GDD section referenced in the story. `Grep` the
-   implemented files for key function names, data structures, or class names
-   mentioned in the GDD. If the GDD specifies a formula, check for recognizable
-   variable names from that formula.
+1. **GDD rules check**: Using the current requirement text from `tr-registry.yaml`
+   (looked up by the story's TR-ID), check that the implementation reflects what
+   the GDD actually requires now — not what it required when the story was written.
+   `Grep` the implemented files for key function names, data structures, or class
+   names mentioned in the current GDD section.
 
-2. **ADR constraints check**: Read the referenced ADR's Decision section. Check
+2. **Manifest version staleness check**: Compare the `Manifest Version:` date
+   embedded in the story header against the `Manifest Version:` date in the
+   current `docs/architecture/control-manifest.md` header.
+   - If they match → pass silently.
+   - If the story's version is older → flag as ADVISORY:
+     `ADVISORY: Story was written against manifest v[story-date]; current manifest
+     is v[current-date]. New rules may apply. Run /story-readiness to check.`
+   - If control-manifest.md does not exist → skip this check.
+
+3. **ADR constraints check**: Read the referenced ADR's Decision section. Check
    for forbidden patterns from `docs/architecture/control-manifest.md` (if it
    exists). `Grep` for patterns explicitly forbidden in the ADR.
 
-3. **Hardcoded values check**: `Grep` the implemented files for numeric literals
+4. **Hardcoded values check**: `Grep` the implemented files for numeric literals
    in gameplay logic that should be in data files.
 
-4. **Scope check**: Did the implementation touch files outside the story's stated
+5. **Scope check**: Did the implementation touch files outside the story's stated
    scope? (files not listed in "files to create/modify")
 
 For each deviation found, categorize:
@@ -201,6 +218,12 @@ If yes, edit the story file:
 3. If advisory deviations exist, ask: "Should I log these as tech debt in
    `docs/tech-debt-register.md`?"
 
+4. **Update `production/sprint-status.yaml`** (if it exists):
+   - Find the entry matching this story's file path or ID
+   - Set `status: done` and `completed: [today's date]`
+   - Update the top-level `updated` field
+   - This is a silent update — no extra approval needed (already approved in step above)
+
 ---
 
 ## Phase 8: Surface the Next Story