/journey

Journey

Give one honest, read-only view of a feature's path through the suite, by composing artifacts that already exist — it builds no new store, writes nothing, and gates nothing (the real gates stay downstream). Feature (a slug, a name, or a PRD path): $ARGUMENTS

The one honesty this command leads with

The suite has no feature-id; the de-facto key is the PRD slug. The docs-side and the task-side join only when the plan was created the recommended way — /taskmanager:plan docs/prd/prd-{slug}.md — so plan_analyses.prd_source is that exact path. If the plan was seeded from a bare prompt or a different path, the two sides cannot be auto-joined. Always state which case you're in, and when they don't join, render the docs-side and task-side stages separately, each marked unlinked — never imply a join that isn't there.

What to do

1. Resolve the slug. From $ARGUMENTS, derive {slug} (strip docs/prd/prd- and .md if a path was given; else match the nearest docs/prd/prd-*.md by name). If none exists, say so and point to prd-builder:prd.

2. Read the docs-side stages (files, read-only):

   • Idea / PRD → docs/prd/prd-{slug}.md (present/absent).
   • Design → docs/architecture/ (boundaries/data-model/interfaces) + docs/adr/ ADRs that reference the feature (present/partial/absent).
   • Shipped / current truth → docs/STATUS.md (does it mention the feature as delivered?).
   • Roadmap → docs/roadmap.md (scribe's living SSOT for planned work; fall back to docs/deep-analysis/roadmap.md for the audit-derived view) — is it still planned vs. shipped?

3. Read the task-side stages through taskmanager:show — NOT raw SQL. Run taskmanager:show --analysis, taskmanager:show --milestones, and taskmanager:show --verification and read their output. (Do not SELECT against plan_analyses/v_task_verification/ v_task_regression yourself — journey is a composer of the existing views, not a second consumer that drifts when taskmanager's schema moves.) From that output, for this feature:

   • Tasks — does a plan_analyses row's prd_source resolve to the same file as docs/prd/prd-{slug}.md? Normalize both to repo-relative paths before comparing — prd_source may be stored absolute or relative, so a raw string-equality check misses a true join (e.g. /abs/.../docs/prd/prd-x.md vs docs/prd/prd-x.md). If they resolve equal → joined; report its milestones + task counts. If no → unlinked: show the task-side state that exists, plainly marked as not provably this feature's.
   • Verified — milestone/PRD verification roll-up (verified / needs-review).
   • Regression-clean — the latest regression verdict state, read from the Regression column of taskmanager:show --verification (pass / fail / overridden / none). A feature is regression-clean when its tasks read pass/overridden; none means the gate has not run yet, not that it passed.

4. Render ONE stage table. One row per stage, in order, each = label · status glyph (✓ present/done · ~ partial · · absent · ? unlinked) · an absolute-path or show-flag pointer to where the detail lives. Lead the table with the join verdict (joined on docs/prd/prd-{slug}.md or NOT joined — docs-side and task-side shown separately).

5. Degrade gracefully. No docs/ → show task-side only and point to scribe:init. No .taskmanager/ → show docs-side only and point to taskmanager:init. Never invent a stage.

What journey never does

• No new datastore, table, column, view, feature_id FK, daemon, cache, or snapshot — it reads live.
• No raw SELECTs against taskmanager's internals — it goes through taskmanager:show. (If a by-slug filter is needed often, the right-sized fix is a show --analysis --by-prd <slug> flag in taskmanager, never a private query here.)
• No write-back and no gate — it observes; the real gates (taskmanager's done-gate, the regression verdict) are untouched.
• No cross-project scope — one project's journey at a time.