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/sprint-plan/SKILL.md

@@ -101,6 +101,47 @@ For `status`:
 - [Any new risks identified this sprint]
 ```
 
+### Sprint Status File
+
+After generating a new sprint plan, also write `production/sprint-status.yaml`.
+This is the machine-readable source of truth for story status — read by
+`/sprint-status`, `/story-done`, and `/help` without markdown parsing.
+
+Ask: "May I also write `production/sprint-status.yaml` to track story status?"
+
+Format:
+
+```yaml
+# Auto-generated by /sprint-plan. Updated by /story-done.
+# DO NOT edit manually — use /story-done to update story status.
+
+sprint: [N]
+goal: "[sprint goal]"
+start: "[YYYY-MM-DD]"
+end: "[YYYY-MM-DD]"
+generated: "[YYYY-MM-DD]"
+updated: "[YYYY-MM-DD]"
+
+stories:
+  - id: "[epic-story, e.g. 1-1]"
+    name: "[story name]"
+    file: "[production/stories/path.md]"
+    priority: must-have        # must-have | should-have | nice-to-have
+    status: ready-for-dev      # backlog | ready-for-dev | in-progress | review | done | blocked
+    owner: ""
+    estimate_days: 0
+    blocker: ""
+    completed: ""
+```
+
+Initialize each story from the sprint plan's task tables:
+- Must Have tasks → `priority: must-have`, `status: ready-for-dev`
+- Should Have tasks → `priority: should-have`, `status: backlog`
+- Nice to Have tasks → `priority: nice-to-have`, `status: backlog`
+
+For `update`: read the existing `sprint-status.yaml`, carry over statuses for
+stories that haven't changed, add new stories, remove dropped ones.
+
 ### Agent Consultation
 
 For comprehensive sprint planning, consider consulting: