* feat(roadmap): parse **Mode:** field on phase sections Adds a 'mode' field to roadmap.get-phase and roadmap.analyze outputs. Recognizes '**Mode:** mvp' lines in phase sections; lowercased + trimmed. Forward-compat: unrecognized values preserved verbatim, no enum check. Foundation for --mvp flag in plan-phase (PRD: vertical-mvp-slice). * feat(plan-phase): parse --mvp flag and resolve MVP_MODE Resolution order: CLI flag → ROADMAP **Mode:** field → workflow.mvp_mode config → false. Walking Skeleton gate fires for new-project Phase 1. Wires MVP_MODE + WALKING_SKELETON into gsd-planner subagent prompt. Per PRD vertical-mvp-slice Phase 1 (Q1, Q2, Q4). * docs(planner): add vertical-slice planning reference New reference loaded by gsd-planner when MVP_MODE=true. Defines slice ordering, Walking Skeleton rules, and anti-patterns. Referenced from plan-phase workflow MVP_MODE wiring. * docs(planner): add SKELETON.md template Template emitted by gsd-planner under WALKING_SKELETON=true. Captures architectural decisions and out-of-scope list for new-project Phase 1. * chore(inventory): register new planner references Added planner-mvp-mode.md and skeleton-template.md to INVENTORY.md and INVENTORY-MANIFEST.json. References now: 53. * feat(gsd-planner): add MVP Mode Detection section Mode-switched branch in the existing planner agent (per Q4: single agent). Vertical-slice decomposition rules, Walking Skeleton handling, and TDD-mode compatibility. Heavy guidance lives in references/planner-mvp-mode.md. * test(plan-phase): add --mvp resolution-chain integration cases Validates roadmap.get-phase --pick mode and confirms workflow.mvp_mode default is unset in fresh projects. * docs(changelog): announce --mvp vertical-slice planning (#2826) * feat(mvp-phase): add /gsd mvp-phase slash command Standalone command for vertical MVP planning. Frontmatter only; heavyweight workflow at get-shit-done/workflows/mvp-phase.md follows in next commit. Mirrors discuss-phase/edit-phase command shape. * docs(planner): add user-story-template reference Defines the canonical 'As a / I want to / So that' format and the ROADMAP.md / PLAN.md emit rules. Used by mvp-phase workflow and gsd-planner agent under MVP_MODE. * docs(planner): add SPIDR splitting reference Defines size signals, the five SPIDR axes (Spike/Paths/Interfaces/Data/Rules), the interactive workflow, and anti-patterns. Per PRD Q3 decision: full interactive flow, not lightweight check. Used by mvp-phase workflow. * fix(mvp-phase): trim description to fit 100-char budget * feat(mvp-phase): add mvp-phase workflow Standalone workflow: phase validation -> user story prompts (As a / I want to / So that) -> SPIDR splitting check -> ROADMAP write (Mode + Goal) -> delegation to plan-phase. Per PRD Phase 2 (Q3 full SPIDR; Phase-2-A/B/C/D decisions). Plan-phase auto-detects MVP via Phase 1's resolution chain, so no flags are needed when delegating. * feat(gsd-planner): emit user-story header in PLAN.md under MVP mode Extends the MVP Mode Detection section (added in Phase 1) so the planner sources the user story from ROADMAP **Goal:** and emits the bolded **As a** / **I want to** / **so that** form as the first content under the phase header in PLAN.md. References user-story-template.md. * test(mvp-phase): integration smoke test for ROADMAP mutation Validates roadmap.get-phase output after a workflow-spec'd ROADMAP write: mode=mvp and goal=full user story. Catches schema drift between workflow emit and parser expectation. Includes a long-story case (>120 chars) to confirm SPIDR-rejected stories still parse correctly. * chore(inventory): register mvp-phase command + 2 new references Adds /gsd mvp-phase to commands list, mvp-phase workflow to workflows list, and user-story-template.md + spidr-splitting.md to references. References count: 53 -> 55. * docs(changelog): announce /gsd mvp-phase command (#2826) * fix(mvp-phase): add TEXT_MODE plain-text fallback for non-Claude runtimes (#2012) * docs(executor): add MVP+TDD gate reference Defines the runtime gate semantics for execute-phase when both MVP_MODE and TDD_MODE are true: pre-task verification of failing-test commit, end-of-phase review escalation from advisory to blocking, behavior-adding task definition. Loaded conditionally by execute-phase workflow and gsd-executor agent. * feat(execute-phase): MVP+TDD runtime gate + blocking review Resolves MVP_MODE in Step 1 (CLI flag -> roadmap mode -> config -> false). Adds per-task gate that halts before behavior-adding tasks run if no failing-test commit exists for the plan. Escalates end-of-phase TDD review from advisory to blocking when both MVP_MODE and TDD_MODE active. Also updates INVENTORY-MANIFEST.json to register execute-mvp-tdd.md (added by Task 1) so manifest-sync tests pass. Per PRD vertical-mvp-slice Phase 3a (decisions Phase-3-A, Phase-3-Split). * feat(gsd-executor): add MVP+TDD Gate section Mirrors the planner's MVP Mode Detection pattern from Phase 1. Instructs halt-and-report when the runtime gate trips, references execute-mvp-tdd.md for full semantics. No agent changes outside the new section. * test(execute-phase): add MVP+TDD resolution-chain integration cases Validates roadmap.get-phase --pick mode and confirms workflow.mvp_mode default is unset in fresh projects. Mirrors the Phase 1 plan-phase resolution-chain integration test. * chore(inventory): register execute-mvp-tdd reference Bumps References count 55 -> 56. Registers execute-mvp-tdd.md. Adds "init" to PROSE_ALLOWLIST in registry integration test so bare `gsd-sdk query init` prose examples in plan docs don't trigger the unregistered-handler guard (real commands are all init.<subcommand>). * docs(changelog): announce MVP+TDD runtime gate in execute-phase (#2826) * docs(verifier): add verify-mvp-mode reference Defines UAT framing under MVP mode: user-flow walk-through first, technical checks deferred, coverage check as goal-backward narrowing to the user story's outcome clause. Loaded conditionally by verify-work workflow and gsd-verifier agent. * feat(verify-work): MVP-mode UAT framing — user flow first Resolves MVP_MODE from phase mode field. Under MVP mode, generates UAT in three ordered sections: user-flow walk-through (derived from user story), technical checks (deferred), coverage check (goal-backward). Falls back to standard UAT generation when mode is null/absent. User-story-format guard refuses to verify a mode:mvp phase with a non-user-story goal. Also updates docs/INVENTORY.md (56 references) and docs/INVENTORY-MANIFEST.json to register verify-mvp-mode.md added in Task 1. Per PRD vertical-mvp-slice Phase 3b (decisions Phase-3-B, Phase-3-Verify-Structure). * feat(gsd-verifier): add MVP Mode Verification section Narrows goal-backward verification to the user-story [outcome] clause when phase mode is mvp. References verify-mvp-mode.md. Preserves existing goal-backward methodology for non-MVP phases. User-story-format guard refuses to verify a mode:mvp phase with a non-user-story goal. * docs(changelog): announce MVP-mode UAT framing in verify-work (#2826) * feat(new-project): add Vertical MVP vs Horizontal Layers mode prompt Asks user at project init how to structure the project. Vertical MVP emits **Mode:** mvp on every initial roadmap phase (per-phase mode preserved per PRD Q1). Horizontal Layers falls back to standard template — no behavioral change for existing flows. Per PRD vertical-mvp-slice Phase 4 (decision Phase-4-Persistence). * feat(progress): add MVP-mode user-flow display When phase has **Mode:** mvp, progress renders user-flow status from PLAN.md task names alongside standard task progress. Tasks that aren't user-flow-shaped (technical-sounding) are filtered out of the user-flow sub-block. Falls back to standard display when mode is null/absent. Per PRD vertical-mvp-slice Phase 4 (decision Phase-4-Progress). * feat(stats): add MVP phase count summary Reads roadmap.analyze (which surfaces mode per phase from Phase 1) and emits 'Phases: N total | M MVP | K standard' summary line. Suppressed when MVP_COUNT == 0 to avoid clutter on non-MVP projects. Per PRD vertical-mvp-slice Phase 4. * feat(graphify): add MVP-mode visual differentiation MVP-mode phases render with #22c55e fill color AND ' (MVP)' label suffix — two-channel signaling for color-blind and grayscale renders. Standard phases unchanged. Per PRD vertical-mvp-slice Phase 4 (PRD Q5: distinct visual treatment). * docs(changelog): announce Phase 4 discovery & progress (#2826) * chore(release): bump dev to 1.50.0-canary.0 for first 1.50.0 canary Sets the base version that .github/workflows/canary.yml derives the canary tag from (strips suffix → base 1.50.0 → next available v1.50.0-canary.N). This kicks off the 1.50.0 release train, opened by the MVP/TDD/UAT vertical slice landed across PRs #2867, #2874, #2878, #2880, #2883. * docs: add CANARY stream README + v1.50.0-canary.1 release notes - docs/CANARY.md — explains the dev→@canary stream policy, install/rollback paths, and when (not) to install canary builds - docs/RELEASE-v1.50.0-canary.1.md — release notes for the first 1.50.0 canary cut: vertical MVP/TDD/UAT slice (#2867 + #2874 + #2878 + #2880 + #2883), opening the 1.50.0 train under PRD #2826 - docs/README.md — index entry + quick link for the canary stream * fix(ci/canary): publish gate checks dev branch, not main Four publish-step `if:` conditions in .github/workflows/canary.yml were checking `github.ref == 'refs/heads/main'`. Those steps (Tag and push, Publish to npm, Publish SDK to npm, Verify publish) therefore always skipped on every workflow_dispatch invocation since canary runs from dev, never main. The workflow's own header comment is unambiguous: `dev → @canary`. The gate was a copy-paste from release.yml (which correctly targets main for the @next/@latest streams) that was never corrected for the canary stream. This is why the 1.50.0-canary.1 publish hadn't materialized despite three green workflow runs. With the gate corrected, the next dispatch will actually publish. * ci(release-sdk): make release-sdk.yml dispatchable from the dev branch The workflow lives on main only, so the GitHub Actions "Use workflow from" dropdown doesn't list dev — meaning dev → @dev publishes can't be triggered from the dev branch directly. Add the file to dev so an operator can dispatch it with branch=dev and tag=dev. Per project release-stream policy: dev branch publishes canary (@dev). This is the stream that needs the file most, since main never publishes @dev itself (main does @next / @latest). File is byte-identical to main's release-sdk.yml — straight propagation, no behavioral change. Tracking issues #2925, #2929. * docs(mvp): canary-prep concept cleanup — CONTEXT.md, mvp-concepts index, --prd interaction (#3176) * chore(mvp): concept cleanup + cross-ref index for v1.50.0-canary.2 prep - CONTEXT.md gains 7 MVP domain terms (MVP Mode, User Story, Walking Skeleton, Vertical Slice, Behavior-Adding Task, MVP+TDD Gate, SPIDR Splitting) so the project glossary matches the shipped surface. - New get-shit-done/references/mvp-concepts.md indexes the six MVP reference files and concept-to-file map so agents and contributors can find the right canonical doc without grepping. - plan-phase.md Walking Skeleton block now documents that --mvp and --prd compose orthogonally on Phase 1; no precedence needed. - INVENTORY/INVENTORY-MANIFEST refreshed for the new reference (58 -> 59). No behavior change. Canary-prep cleanup ahead of v1.50.0-canary.2. Surfaced for follow-up (not in this PR): - MVP_MODE resolution shell block duplicated across plan-phase, execute-phase, verify-work workflows (needs a shared workflow-include mechanism; structural change). - Behavior-Adding Task predicate is prose-only; no shared utility. - User Story regex hardcoded in verify-work; would benefit from a central definition consumed by the verifier and the mvp-phase command. * chore(changeset): set PR number for mvp concept cleanup * feat(mvp): centralize resolution surfaces + fix SDK roadmap mode parity (#3178) Three new SDK query verbs replace the architectural duplication surfaced by the v1.50.0-canary.2 review against dev tip 12c4e565: phase.mvp-mode <N> [--cli-flag] Single canonical precedence resolver (CLI flag -> ROADMAP **Mode:** mvp -> workflow.mvp_mode config -> false). Replaces 4-8 lines of bash that were duplicated across plan-phase.md, execute-phase.md, verify-work.md, and progress.md. Returns {active, source, roadmap_mode, config_mvp_mode, cli_flag_present}. task.is-behavior-adding <plan-file> | --task-content <xml> Behavior-Adding Task predicate (tdd="true" + <behavior> block + non-test source files in <files>). Replaces prose-only specification in references/execute-mvp-tdd.md; gsd-executor agent now invokes the verb instead of re-inlining the three checks. Returns {is_behavior_adding, checks, reason}. user-story.validate <text> | --story <text> Owns the canonical User Story regex /^As a .+, I want to .+, so that .+\.$/ previously hardcoded in verify-work.md prose. Consumed by gsd-verifier (phase-goal guard) and /gsd-mvp-phase (interactive-prompt validation). Returns {valid, slots: {role, capability, outcome}, errors[]}. Bug fix bundled: sdk/src/query/roadmap.ts searchPhaseInContent now extracts the mode field from **Mode:**, restoring parity with roadmap.cjs:120-123. Without this, roadmap.get-phase --pick mode returned null on the native dispatch path even when the phase had **Mode:** mvp set, causing MVP_MODE to silently fall through to the config/false branch in every consuming workflow. The original PRs Phase 1 (#2885) shipped the CJS parser but the SDK port omitted the field; this fix brings them back to parity. Workflows + agents updated to call the verbs: - plan-phase.md, execute-phase.md, verify-work.md, progress.md call phase.mvp-mode (one line replaces the duplicated bash chains). - execute-phase.md MVP+TDD gate calls task.is-behavior-adding. - verify-work.md goal guard calls user-story.validate. - mvp-phase.md interactive prompt validates via user-story.validate. - gsd-executor agent references task.is-behavior-adding instead of prose. - gsd-verifier agent references user-story.validate instead of inlined regex. Tests: 24 new vitest tests in sdk/src/query/mvp.test.ts cover all three verbs + the regression. Two existing contract tests (progress, verify) updated to assert on the new verb shape. All 60 existing MVP contract tests pass; golden integration suite (38 + 42 tests) passes. Closes #3177 * fix(canary.2): unblock release gates for v1.50.0-canary.2 Run 25451329660 (Release SDK Bundle on dev, 2026-05-06T17:41) failed at the test-suite step with 3 deterministic content/structure gate failures, all attributable to the MVP umbrella integration in #3178 and the docs sweep in #3180. Failure 1: /gsd-mvp-phase undocumented in workflows/help.md - tests/bug-2954-help-md-slash-command-stubs.test.cjs requires every shipped commands/gsd/<X>.md to have a /gsd-<X> mention in help.md - PR #3180 updated docs/COMMANDS.md but missed help.md (which the AI agents load in-product) - Fix: add a /gsd-mvp-phase entry to help.md right before /gsd-plan-phase Failures 2 + 3: execute-phase.md (1727) and plan-phase.md (1714) over XL budget (1700) - PR #3178 added MVP-mode verb calls (phase.mvp-mode, task.is-behavior-adding, user-story.validate) to both workflow files, pushing them past 1700 lines - Fix: bump XL_BUDGET 1700 -> 1800 with inline comment pointing at the structural follow-up (extract MVP bodies to <workflow>/modes/mvp.md per the discuss-phase/modes/ precedent) - The structural extract is the right long-term fix but is bigger than canary unblock scope; will land in a follow-up after canary cycles Local verification: $ node --test tests/bug-2954-help-md-slash-command-stubs.test.cjs tests/workflow-size-budget.test.cjs tests 111 pass 111 fail 0 After this lands, re-trigger Release SDK Bundle on dev for v1.50.0-canary.2. * chore(changeset): set PR number for canary.2 unblock * fix(codex): generate-claude-md writes to AGENTS.md on Codex runtime When config.runtime === 'codex' or GSD_RUNTIME=codex, override the output target to AGENTS.md regardless of claude_md_path, so Codex projects no longer have GSD sections written to CLAUDE.md by mistake. Fixes both the CJS (gsd-tools) and SDK (profile-output.ts) paths. Explicit --output flags are still honoured in both paths. Closes #3163 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(plan-phase): remove agent: directive that caused OpenCode subagent dispatch On OpenCode, any command with `agent: <name>` in its frontmatter is auto-dispatched to a subagent context where the Agent tool is unavailable. plan-phase.md and mvp-phase.md both carried `agent: gsd-planner`, causing them to run inside gsd-planner's subagent context with no ability to spawn researcher/planner/checker subagents — the orchestrator fell back to inline execution for all three phases. Fix: remove `agent: gsd-planner` from both command files so they run in the main agent context. Also replace the stale `Task` tool in allowed-tools with `Agent` (the correct dispatcher tool name post-#3168 rename). Adds a structural regression test that parses YAML frontmatter of every commands/gsd/*.md file and asserts no command carries an `agent:` directive. Closes #3156 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(mvp): address CodeRabbit workflow and contract findings * fix(execute-phase): use registered state.update query command --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
650 lines
19 KiB
Markdown
650 lines
19 KiB
Markdown
<purpose>
|
|
Check project progress, summarize recent work and what's ahead, then intelligently route to the next action — either executing an existing plan or creating the next one. Provides situational awareness before continuing work.
|
|
</purpose>
|
|
|
|
<required_reading>
|
|
Read all files referenced by the invoking prompt's execution_context before starting.
|
|
</required_reading>
|
|
|
|
<process>
|
|
|
|
<step name="init_context">
|
|
**Load progress context (paths only):**
|
|
|
|
```bash
|
|
INIT=$(gsd-sdk query init.progress)
|
|
if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
|
|
```
|
|
|
|
Extract from init JSON: `project_exists`, `roadmap_exists`, `state_exists`, `phases`, `current_phase`, `next_phase`, `milestone_version`, `completed_count`, `phase_count`, `paused_at`, `state_path`, `roadmap_path`, `project_path`, `config_path`.
|
|
|
|
```bash
|
|
DISCUSS_MODE=$(gsd-sdk query config-get workflow.discuss_mode 2>/dev/null || echo "discuss")
|
|
```
|
|
|
|
If `project_exists` is false (no `.planning/` directory):
|
|
|
|
```
|
|
No planning structure found.
|
|
|
|
Run /gsd-new-project to start a new project.
|
|
```
|
|
|
|
Exit.
|
|
|
|
If missing STATE.md: suggest `/gsd-new-project`.
|
|
|
|
**If ROADMAP.md missing but PROJECT.md exists:**
|
|
|
|
This means a milestone was completed and archived. Go to **Route F** (between milestones).
|
|
|
|
If missing both ROADMAP.md and PROJECT.md: suggest `/gsd-new-project`.
|
|
</step>
|
|
|
|
<step name="load">
|
|
**Use structured extraction from `gsd-sdk query` (or legacy gsd-tools.cjs):**
|
|
|
|
Instead of reading full files, use targeted tools to get only the data needed for the report:
|
|
- `ROADMAP=$(gsd-sdk query roadmap.analyze)`
|
|
- `STATE=$(gsd-sdk query state-snapshot)`
|
|
|
|
This minimizes orchestrator context usage.
|
|
</step>
|
|
|
|
<step name="analyze_roadmap">
|
|
**Get comprehensive roadmap analysis (replaces manual parsing):**
|
|
|
|
```bash
|
|
ROADMAP=$(gsd-sdk query roadmap.analyze)
|
|
```
|
|
|
|
This returns structured JSON with:
|
|
- All phases with disk status (complete/partial/planned/empty/no_directory)
|
|
- Goal and dependencies per phase
|
|
- Plan and summary counts per phase
|
|
- Aggregated stats: total plans, summaries, progress percent
|
|
- Current and next phase identification
|
|
|
|
Use this instead of manually reading/parsing ROADMAP.md.
|
|
</step>
|
|
|
|
<step name="recent">
|
|
**Gather recent work context:**
|
|
|
|
- Find the 2-3 most recent SUMMARY.md files
|
|
- Use `summary-extract` for efficient parsing:
|
|
```bash
|
|
gsd-sdk query summary-extract <path> --fields one_liner
|
|
```
|
|
- This shows "what we've been working on"
|
|
</step>
|
|
|
|
<step name="position">
|
|
**Parse current position from init context and roadmap analysis:**
|
|
|
|
- Use `current_phase` and `next_phase` from `$ROADMAP`
|
|
- Note `paused_at` if work was paused (from `$STATE`)
|
|
- Count pending todos: use `init todos` or `list-todos`
|
|
- Check for active debug sessions: `(ls .planning/debug/*.md 2>/dev/null || true) | grep -v resolved | wc -l`
|
|
</step>
|
|
|
|
<step name="report">
|
|
> ⚠️ Context authority: PROJECT.md, STATE.md, and ROADMAP.md are the authoritative sources
|
|
> for project name, milestone, current phase, and next-step routing. CLAUDE.md ## Project
|
|
> blocks are a secondary config aid that may be significantly stale — do NOT use the
|
|
> CLAUDE.md project description as a source for any progress report field.
|
|
|
|
**Generate progress bar from `gsd-sdk query progress` / `progress.json`, then present rich status report:**
|
|
|
|
```bash
|
|
# Get formatted progress bar
|
|
PROGRESS_BAR=$(gsd-sdk query progress.bar --raw)
|
|
```
|
|
|
|
Present:
|
|
|
|
```
|
|
# [Project Name]
|
|
|
|
**Progress:** {PROGRESS_BAR}
|
|
**Profile:** [quality/balanced/budget/inherit]
|
|
**Discuss mode:** {DISCUSS_MODE}
|
|
|
|
## Recent Work
|
|
- [Phase X, Plan Y]: [what was accomplished - 1 line from summary-extract]
|
|
- [Phase X, Plan Z]: [what was accomplished - 1 line from summary-extract]
|
|
|
|
## Current Position
|
|
Phase [N] of [total]: [phase-name]
|
|
Plan [M] of [phase-total]: [status]
|
|
CONTEXT: [✓ if has_context | - if not]
|
|
|
|
## Key Decisions Made
|
|
- [extract from $STATE.decisions[]]
|
|
- [e.g. jq -r '.decisions[].decision' from state-snapshot]
|
|
|
|
## Blockers/Concerns
|
|
- [extract from $STATE.blockers[]]
|
|
- [e.g. jq -r '.blockers[].text' from state-snapshot]
|
|
|
|
## Pending Todos
|
|
- [count] pending — /gsd-capture --list to review
|
|
|
|
## Active Debug Sessions
|
|
- [count] active — /gsd-debug to continue
|
|
(Only show this section if count > 0)
|
|
|
|
## What's Next
|
|
[Next phase/plan objective from roadmap analyze]
|
|
```
|
|
|
|
</step>
|
|
|
|
<step name="mvp_display">
|
|
**MVP-mode display (when phase has `**Mode:** mvp` in ROADMAP.md).**
|
|
|
|
Resolve `MVP_MODE` per phase via the centralized resolver. progress has no `--mvp` CLI flag (mode is inherited from the planned phase), so we omit `--cli-flag`:
|
|
|
|
```bash
|
|
MVP_MODE=$(gsd-sdk query phase.mvp-mode "${PHASE_NUMBER}" --pick active)
|
|
```
|
|
|
|
When `MVP_MODE=true`, the per-phase progress block adds a **user-flow status** sub-block sourced from the phase's PLAN.md task names. Each task whose name reads like a user-visible capability (e.g., "Register flow", "Login flow", "Password reset") is rendered as a status line:
|
|
|
|
```
|
|
Phase 1 — User Auth MVP
|
|
✅ Walking Skeleton complete ← from SKELETON.md existence
|
|
✅ Register flow working ← from PLAN.md task with summary
|
|
✅ Login flow working ← from PLAN.md task with summary
|
|
🔄 Password reset (in progress) ← from PLAN.md task without summary
|
|
⬜ Email verification ← from PLAN.md task not yet started
|
|
```
|
|
|
|
**User-flow filter:** Tasks whose names are technical-sounding ("Wire DB schema", "Create migration", "Bump deps") are NOT rendered as user-flow status lines. Heuristic: a task name is user-flow-shaped if it ends in "flow", "page", "screen", or starts with a verb the user would recognize ("Register", "Login", "Upload", "View"). Tasks that fail the heuristic still count toward the standard task progress total but don't appear in the user-flow sub-block.
|
|
|
|
When `MVP_MODE=false` (mode is null, absent, or the phase has no `**Mode:**` line), fall back to the standard display path — no behavioral change.
|
|
</step>
|
|
|
|
<step name="route">
|
|
**Determine next action based on verified counts.**
|
|
|
|
**Step 1: Count plans, summaries, and issues in current phase**
|
|
|
|
List files in the current phase directory:
|
|
|
|
```bash
|
|
(ls -1 .planning/phases/[current-phase-dir]/*-PLAN.md 2>/dev/null || true) | wc -l
|
|
(ls -1 .planning/phases/[current-phase-dir]/*-SUMMARY.md 2>/dev/null || true) | wc -l
|
|
(ls -1 .planning/phases/[current-phase-dir]/*-UAT.md 2>/dev/null || true) | wc -l
|
|
```
|
|
|
|
State: "This phase has {X} plans, {Y} summaries."
|
|
|
|
**Step 1.5: Check for unaddressed UAT gaps**
|
|
|
|
Check for UAT.md files with status "diagnosed" (has gaps needing fixes).
|
|
|
|
```bash
|
|
# Check for diagnosed UAT with gaps or partial (incomplete) testing
|
|
grep -l "status: diagnosed\|status: partial" .planning/phases/[current-phase-dir]/*-UAT.md 2>/dev/null || true
|
|
```
|
|
|
|
Track:
|
|
- `uat_with_gaps`: UAT.md files with status "diagnosed" (gaps need fixing)
|
|
- `uat_partial`: UAT.md files with status "partial" (incomplete testing)
|
|
|
|
**Step 1.6: Cross-phase health check**
|
|
|
|
Scan ALL phases in the current milestone for outstanding verification debt using the CLI (which respects milestone boundaries via `getMilestonePhaseFilter`):
|
|
|
|
```bash
|
|
DEBT=$(gsd-sdk query audit-uat --raw 2>/dev/null)
|
|
```
|
|
|
|
Parse JSON for `summary.total_items` and `summary.total_files`.
|
|
|
|
Track: `outstanding_debt` — `summary.total_items` from the audit.
|
|
|
|
**If outstanding_debt > 0:** Add a warning section to the progress report output (in the `report` step), placed between "## What's Next" and the route suggestion:
|
|
|
|
```markdown
|
|
## Verification Debt ({N} files across prior phases)
|
|
|
|
| Phase | File | Issue |
|
|
|-------|------|-------|
|
|
| {phase} | {filename} | {pending_count} pending, {skipped_count} skipped, {blocked_count} blocked |
|
|
| {phase} | {filename} | human_needed — {count} items |
|
|
|
|
Review: `/gsd-audit-uat ${GSD_WS}` — full cross-phase audit
|
|
Resume testing: `/gsd-verify-work {phase} ${GSD_WS}` — retest specific phase
|
|
```
|
|
|
|
This is a WARNING, not a blocker — routing proceeds normally. The debt is visible so the user can make an informed choice.
|
|
|
|
**Step 2: Route based on counts**
|
|
|
|
| Condition | Meaning | Action |
|
|
|-----------|---------|--------|
|
|
| uat_partial > 0 | UAT testing incomplete | Go to **Route E.2** |
|
|
| uat_with_gaps > 0 | UAT gaps need fix plans | Go to **Route E** |
|
|
| summaries < plans | Unexecuted plans exist | Go to **Route A** |
|
|
| summaries = plans AND plans > 0 | Phase complete | Go to Step 3 |
|
|
| plans = 0 | Phase not yet planned | Go to **Route B** |
|
|
|
|
---
|
|
|
|
**Route A: Unexecuted plan exists**
|
|
|
|
Find the first PLAN.md without matching SUMMARY.md.
|
|
Read its `<objective>` section.
|
|
|
|
```
|
|
---
|
|
|
|
## ▶ Next Up — [${PROJECT_CODE}] ${PROJECT_TITLE}
|
|
|
|
**{phase}-{plan}: [Plan Name]** — [objective summary from PLAN.md]
|
|
|
|
`/clear` then:
|
|
|
|
`/gsd-execute-phase {phase} ${GSD_WS}`
|
|
|
|
---
|
|
```
|
|
|
|
---
|
|
|
|
**Route B: Phase needs planning**
|
|
|
|
Check if `{phase_num}-CONTEXT.md` exists in phase directory.
|
|
|
|
Check if current phase has UI indicators:
|
|
|
|
```bash
|
|
PHASE_SECTION=$(gsd-sdk query roadmap.get-phase "${CURRENT_PHASE}" 2>/dev/null)
|
|
PHASE_HAS_UI=$(echo "$PHASE_SECTION" | grep -qi "UI hint.*yes" && echo "true" || echo "false")
|
|
```
|
|
|
|
**If CONTEXT.md exists:**
|
|
|
|
```
|
|
---
|
|
|
|
## ▶ Next Up — [${PROJECT_CODE}] ${PROJECT_TITLE}
|
|
|
|
**Phase {N}: {Name}** — {Goal from ROADMAP.md}
|
|
<sub>✓ Context gathered, ready to plan</sub>
|
|
|
|
`/clear` then:
|
|
|
|
`/gsd-plan-phase {phase-number} ${GSD_WS}`
|
|
|
|
---
|
|
```
|
|
|
|
**If CONTEXT.md does NOT exist AND phase has UI (`PHASE_HAS_UI` is `true`):**
|
|
|
|
```
|
|
---
|
|
|
|
## ▶ Next Up — [${PROJECT_CODE}] ${PROJECT_TITLE}
|
|
|
|
**Phase {N}: {Name}** — {Goal from ROADMAP.md}
|
|
|
|
`/clear` then:
|
|
|
|
`/gsd-discuss-phase {phase}` — gather context and clarify approach
|
|
|
|
---
|
|
|
|
**Also available:**
|
|
- `/gsd-ui-phase {phase}` — generate UI design contract (recommended for frontend phases)
|
|
- `/gsd-plan-phase {phase}` — skip discussion, plan directly
|
|
- `/gsd-discuss-phase {phase}` — include assumptions check before planning
|
|
|
|
---
|
|
```
|
|
|
|
**If CONTEXT.md does NOT exist AND phase has no UI:**
|
|
|
|
```
|
|
---
|
|
|
|
## ▶ Next Up — [${PROJECT_CODE}] ${PROJECT_TITLE}
|
|
|
|
**Phase {N}: {Name}** — {Goal from ROADMAP.md}
|
|
|
|
`/clear` then:
|
|
|
|
`/gsd-discuss-phase {phase} ${GSD_WS}` — gather context and clarify approach
|
|
|
|
---
|
|
|
|
**Also available:**
|
|
- `/gsd-plan-phase {phase} ${GSD_WS}` — skip discussion, plan directly
|
|
- `/gsd-discuss-phase {phase} ${GSD_WS}` — include assumptions check before planning
|
|
|
|
---
|
|
```
|
|
|
|
---
|
|
|
|
**Route E: UAT gaps need fix plans**
|
|
|
|
UAT.md exists with gaps (diagnosed issues). User needs to plan fixes.
|
|
|
|
```
|
|
---
|
|
|
|
## ⚠ UAT Gaps Found
|
|
|
|
**{phase_num}-UAT.md** has {N} gaps requiring fixes.
|
|
|
|
`/clear` then:
|
|
|
|
`/gsd-plan-phase {phase} --gaps ${GSD_WS}`
|
|
|
|
---
|
|
|
|
**Also available:**
|
|
- `/gsd-execute-phase {phase} ${GSD_WS}` — execute phase plans
|
|
- `/gsd-verify-work {phase} ${GSD_WS}` — run more UAT testing
|
|
|
|
---
|
|
```
|
|
|
|
---
|
|
|
|
**Route E.2: UAT testing incomplete (partial)**
|
|
|
|
UAT.md exists with `status: partial` — testing session ended before all items resolved.
|
|
|
|
```
|
|
---
|
|
|
|
## Incomplete UAT Testing
|
|
|
|
**{phase_num}-UAT.md** has {N} unresolved tests (pending, blocked, or skipped).
|
|
|
|
`/clear` then:
|
|
|
|
`/gsd-verify-work {phase} ${GSD_WS}` — resume testing from where you left off
|
|
|
|
---
|
|
|
|
**Also available:**
|
|
- `/gsd-audit-uat ${GSD_WS}` — full cross-phase UAT audit
|
|
- `/gsd-execute-phase {phase} ${GSD_WS}` — execute phase plans
|
|
|
|
---
|
|
```
|
|
|
|
---
|
|
|
|
**Step 3: Check milestone status (only when phase complete)**
|
|
|
|
Read ROADMAP.md and identify:
|
|
1. Current phase number
|
|
2. All phase numbers in the current milestone section
|
|
|
|
Count total phases and identify the highest phase number.
|
|
|
|
State: "Current phase is {X}. Milestone has {N} phases (highest: {Y})."
|
|
|
|
**Route based on milestone status:**
|
|
|
|
| Condition | Meaning | Action |
|
|
|-----------|---------|--------|
|
|
| current phase < highest phase | More phases remain | Go to **Route C** |
|
|
| current phase = highest phase | Milestone complete | Go to **Route D** |
|
|
|
|
---
|
|
|
|
**Route C: Phase complete, more phases remain**
|
|
|
|
Read ROADMAP.md to get the next phase's name and goal.
|
|
|
|
Check if next phase has UI indicators:
|
|
|
|
```bash
|
|
NEXT_PHASE_SECTION=$(gsd-sdk query roadmap.get-phase "$((Z+1))" 2>/dev/null)
|
|
NEXT_HAS_UI=$(echo "$NEXT_PHASE_SECTION" | grep -qi "UI hint.*yes" && echo "true" || echo "false")
|
|
```
|
|
|
|
**If next phase has UI (`NEXT_HAS_UI` is `true`):**
|
|
|
|
```
|
|
---
|
|
|
|
## ✓ Phase {Z} Complete
|
|
|
|
## ▶ Next Up — [${PROJECT_CODE}] ${PROJECT_TITLE}
|
|
|
|
**Phase {Z+1}: {Name}** — {Goal from ROADMAP.md}
|
|
|
|
`/clear` then:
|
|
|
|
`/gsd-discuss-phase {Z+1}` — gather context and clarify approach
|
|
|
|
---
|
|
|
|
**Also available:**
|
|
- `/gsd-ui-phase {Z+1}` — generate UI design contract (recommended for frontend phases)
|
|
- `/gsd-plan-phase {Z+1}` — skip discussion, plan directly
|
|
- `/gsd-verify-work {Z}` — user acceptance test before continuing
|
|
|
|
---
|
|
```
|
|
|
|
**If next phase has no UI:**
|
|
|
|
```
|
|
---
|
|
|
|
## ✓ Phase {Z} Complete
|
|
|
|
## ▶ Next Up — [${PROJECT_CODE}] ${PROJECT_TITLE}
|
|
|
|
**Phase {Z+1}: {Name}** — {Goal from ROADMAP.md}
|
|
|
|
`/clear` then:
|
|
|
|
`/gsd-discuss-phase {Z+1} ${GSD_WS}` — gather context and clarify approach
|
|
|
|
---
|
|
|
|
**Also available:**
|
|
- `/gsd-plan-phase {Z+1} ${GSD_WS}` — skip discussion, plan directly
|
|
- `/gsd-verify-work {Z} ${GSD_WS}` — user acceptance test before continuing
|
|
|
|
---
|
|
```
|
|
|
|
---
|
|
|
|
**Route D: Milestone complete**
|
|
|
|
```
|
|
---
|
|
|
|
## 🎉 Milestone Complete
|
|
|
|
All {N} phases finished!
|
|
|
|
## ▶ Next Up — [${PROJECT_CODE}] ${PROJECT_TITLE}
|
|
|
|
**Complete Milestone** — archive and prepare for next
|
|
|
|
`/clear` then:
|
|
|
|
`/gsd-complete-milestone ${GSD_WS}`
|
|
|
|
---
|
|
|
|
**Also available:**
|
|
- `/gsd-verify-work ${GSD_WS}` — user acceptance test before completing milestone
|
|
|
|
---
|
|
```
|
|
|
|
---
|
|
|
|
**Route F: Between milestones (ROADMAP.md missing, PROJECT.md exists)**
|
|
|
|
A milestone was completed and archived. Ready to start the next milestone cycle.
|
|
|
|
Read MILESTONES.md to find the last completed milestone version.
|
|
|
|
```
|
|
---
|
|
|
|
## ✓ Milestone v{X.Y} Complete
|
|
|
|
Ready to plan the next milestone.
|
|
|
|
## ▶ Next Up — [${PROJECT_CODE}] ${PROJECT_TITLE}
|
|
|
|
**Start Next Milestone** — questioning → research → requirements → roadmap
|
|
|
|
`/clear` then:
|
|
|
|
`/gsd-new-milestone ${GSD_WS}`
|
|
|
|
---
|
|
```
|
|
|
|
</step>
|
|
|
|
<step name="edge_cases">
|
|
**Handle edge cases:**
|
|
|
|
- Phase complete but next phase not planned → offer `/gsd-plan-phase [next] ${GSD_WS}`
|
|
- All work complete → offer milestone completion
|
|
- Blockers present → highlight before offering to continue
|
|
- Handoff file exists → mention it, offer `/gsd-resume-work ${GSD_WS}`
|
|
</step>
|
|
|
|
<step name="forensic_audit">
|
|
**Forensic Integrity Audit** — only runs when `--forensic` is present in ARGUMENTS.
|
|
|
|
If `--forensic` is NOT present in ARGUMENTS: skip this step entirely. Default progress behavior (standard report + routing) is unchanged.
|
|
|
|
If `--forensic` IS present: after the standard report and routing suggestion have been displayed, append the following audit section.
|
|
|
|
---
|
|
|
|
## Forensic Integrity Audit
|
|
|
|
Running 6 deep checks against project state...
|
|
|
|
Run each check in order. For each check, emit ✓ (pass) or ⚠ (warning) with concrete evidence when a problem is found.
|
|
|
|
**Check 1 — STATE vs artifact consistency**
|
|
|
|
Read STATE.md `status` / `stopped_at` fields (from the STATE snapshot already loaded). Compare against the artifact count from the roadmap analysis. If STATE.md claims the current phase is pending/mid-flight but the artifact count shows it as complete (all PLAN.md files have matching SUMMARY.md files), flag inconsistency. Emit:
|
|
- ✓ `STATE.md consistent with artifact count` — if both agree
|
|
- ⚠ `STATE.md claims [status] but artifact count shows phase complete` — with the specific values
|
|
|
|
**Check 2 — Orphaned handoff files**
|
|
|
|
Check for existence of:
|
|
```bash
|
|
ls .planning/HANDOFF.json .planning/phases/*/.continue-here.md .planning/phases/*/*HANDOFF*.md 2>/dev/null || true
|
|
```
|
|
Also check `.planning/continue-here.md`.
|
|
|
|
Emit:
|
|
- ✓ `No orphaned handoff files` — if none found
|
|
- ⚠ `Orphaned handoff files found` — list each file path, add: `→ Work was paused mid-flight. Read the handoff before continuing.`
|
|
|
|
**Check 3 — Deferred scope drift**
|
|
|
|
Search phase artifacts (CONTEXT.md, DISCUSSION-LOG.md, BUG-BRIEF.md, VERIFICATION.md, SUMMARY.md, HANDOFF.md files under `.planning/phases/`) for patterns:
|
|
```bash
|
|
grep -rl "defer to Phase\|future phase\|out of scope Phase\|deferred to Phase" .planning/phases/ 2>/dev/null || true
|
|
```
|
|
|
|
For each match, extract the referenced phase number. Cross-reference against ROADMAP.md phase list. If the referenced phase number is NOT in ROADMAP.md, flag as deferred scope not captured.
|
|
|
|
Emit:
|
|
- ✓ `All deferred scope captured in ROADMAP` — if no mismatches
|
|
- ⚠ `Deferred scope references phase(s) not in ROADMAP` — list: file, reference text, missing phase number
|
|
|
|
**Check 4 — Memory-flagged pending work**
|
|
|
|
Check if `.planning/MEMORY.md` or `.planning/memory/` exists:
|
|
```bash
|
|
ls .planning/MEMORY.md .planning/memory/*.md 2>/dev/null || true
|
|
```
|
|
|
|
If found, grep for entries containing: `pending`, `status`, `deferred`, `not yet run`, `backfill`, `blocking`.
|
|
|
|
Emit:
|
|
- ✓ `No memory entries flagging pending work` — if none found or no MEMORY.md
|
|
- ⚠ `Memory entries flag pending/deferred work` — list the matching lines (max 5, truncated at 80 chars)
|
|
|
|
**Check 5 — Blocking operational todos**
|
|
|
|
Check for pending todos:
|
|
```bash
|
|
ls .planning/todos/pending/*.md 2>/dev/null || true
|
|
```
|
|
|
|
For files found, scan for keywords indicating operational blockers: `script`, `credential`, `API key`, `manual`, `verification`, `setup`, `configure`, `run `.
|
|
|
|
Emit:
|
|
- ✓ `No blocking operational todos` — if no pending todos or none match operational keywords
|
|
- ⚠ `Blocking operational todos found` — list the file names and matching keywords (max 5)
|
|
|
|
**Check 6 — Uncommitted code**
|
|
|
|
```bash
|
|
git status --porcelain 2>/dev/null | grep -v "^??" | grep -v "^.planning\/" | grep -v "^\.\." | head -10
|
|
```
|
|
|
|
If output is non-empty (modified/staged files outside `.planning/`), flag as uncommitted code.
|
|
|
|
Emit:
|
|
- ✓ `Working tree clean` — if no modified files outside `.planning/`
|
|
- ⚠ `Uncommitted changes in source files` — list up to 10 file paths
|
|
|
|
---
|
|
|
|
After all 6 checks, display the verdict:
|
|
|
|
**If all 6 checks passed:**
|
|
```
|
|
### Verdict: CLEAN
|
|
|
|
The standard progress report is trustworthy — proceed with the routing suggestion above.
|
|
```
|
|
|
|
**If 1 or more checks failed:**
|
|
```
|
|
### Verdict: N INTEGRITY ISSUE(S) FOUND
|
|
|
|
The standard progress report may not reflect true project state.
|
|
Review the flagged items above before acting on the routing suggestion.
|
|
```
|
|
|
|
Then for each failed check, add a concrete next action:
|
|
- Check 2 (orphaned handoff): `Read the handoff file(s) and resume from where work was paused: /gsd-resume-work ${GSD_WS}`
|
|
- Check 3 (deferred scope): `Add the missing phases to ROADMAP.md or update the deferred references`
|
|
- Check 4 (memory pending): `Review the flagged memory entries and resolve or clear them`
|
|
- Check 5 (blocking todos): `Complete the operational steps in .planning/todos/pending/ before continuing`
|
|
- Check 6 (uncommitted code): `Commit or stash the uncommitted changes before advancing`
|
|
- Check 1 (STATE inconsistency): `Run /gsd-verify-work ${PHASE} ${GSD_WS} to reconcile state`
|
|
</step>
|
|
|
|
</process>
|
|
|
|
<success_criteria>
|
|
|
|
- [ ] Rich context provided (recent work, decisions, issues)
|
|
- [ ] Current position clear with visual progress
|
|
- [ ] What's next clearly explained
|
|
- [ ] Smart routing: /gsd-execute-phase if plans exist, /gsd-plan-phase if not
|
|
- [ ] User confirms before any action
|
|
- [ ] Seamless handoff to appropriate gsd command
|
|
</success_criteria>
|