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

@@ -51,7 +51,14 @@ found — burndown assessment skipped."
 
 ## 3. Scan Story Status
 
-For each story or task referenced in the sprint plan:
+**First: check for `production/sprint-status.yaml`.**
+
+If it exists, read it directly — it is the authoritative source of truth.
+Extract status for each story from the `status` field. No markdown scanning needed.
+Use its `sprint`, `goal`, `start`, `end` fields instead of re-parsing the sprint plan.
+
+**If `sprint-status.yaml` does not exist** (legacy sprint or first-time setup),
+fall back to markdown scanning:
 
 1. If the entry references a story file path, check if the file exists.
    Read the file and scan for status markers: DONE, COMPLETE, IN PROGRESS,
@@ -61,6 +68,9 @@ For each story or task referenced in the sprint plan:
 3. If no status marker is found, classify as NOT STARTED.
 4. If a file is referenced but does not exist, classify as MISSING and note it.
 
+When using the fallback, add a note at the bottom of the output:
+"⚠ No `sprint-status.yaml` found — status inferred from markdown. Run `/sprint-plan update` to generate one."
+
 Optionally (fast check only — do not do a deep scan): grep `src/` for a
 directory or file name that matches the story's system slug to check for
 implementation evidence. This is a hint only, not a definitive status.