* feat(#1945): tracer-first planning default + executor feedback gate Make "thin end-to-end slice first, verify, then expand" the default planning + execution discipline instead of the opt-in --mvp mode. - gsd-planner: first-class `type="tracer"` task; every plan LEADS with one production-quality end-to-end tracer slice by default; --no-tracer restores horizontal layers; --mvp/--tdd compose on top. - gsd-executor + execute-plan: post-tracer feedback gate — autonomous runs halt-on-fail before expansion, interactive runs emit checkpoint:human-verify after the tracer. - --no-tracer flag wired through plan-phase workflow/command/help/skill. - CONTEXT.md glossary defines tracer bullet vs prototype; docs + references reconciled. - tests/tracer-bullet.test.cjs: prose-contract + behavioral (verify plan-structure accepts tracer) coverage. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * chore(#1945): backfill changeset PR number to 2294 --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Tom Boucher
@@ -215,7 +215,8 @@ GSD uses a multi-agent architecture where thin orchestrators (workflow files) sp
|
||||
- Fresh 200K context window per plan
|
||||
- Follows XML task instructions precisely
|
||||
- Atomic git commit per completed task
|
||||
- Handles checkpoint types: auto, human-verify, decision, human-action
|
||||
- Handles task types: auto, tracer, checkpoint (human-verify, decision, human-action)
|
||||
- Tracer feedback gate: after a `tracer` slice, verifies it end-to-end before expansion tasks — autonomous runs halt on failure; interactive runs emit a human-verify checkpoint
|
||||
- Reports deviations from plan in SUMMARY.md
|
||||
- Invokes node repair on verification failure
|
||||
|
||||
|
||||
@@ -211,8 +211,9 @@ Research, plan, and verify a phase.
|
||||
| `--validate` | Run state validation before planning begins |
|
||||
| `--bounce` | Run external plan bounce validation after planning (uses `workflow.plan_bounce_script`) |
|
||||
| `--skip-bounce` | Skip plan bounce even if enabled in config |
|
||||
| `--mvp` | Vertical MVP mode — planner organizes tasks as feature slices (UI→API→DB) instead of horizontal layers. On Phase 1 of a new project with no prior phase summaries, also emits `SKELETON.md` (Walking Skeleton). Can be persisted on a phase via `**Mode:** mvp` in ROADMAP.md, which applies `--mvp` automatically without the flag. |
|
||||
| `--tdd` | TDD mode — planner applies `type: tdd` to eligible behavior-adding tasks so each begins with a failing test. Composable with `--mvp`: `--mvp --tdd` produces vertical slices where every behavior-adding task starts red-green. |
|
||||
| `--mvp` | MVP enrichment on top of the default tracer-first ordering — frames the phase goal as a user story and, on Phase 1 of a new project with no prior phase summaries, also emits `SKELETON.md` (Walking Skeleton). Vertical slicing is now the default (see `--no-tracer`); `--mvp` no longer turns it on. Can be persisted on a phase via `**Mode:** mvp` in ROADMAP.md, which applies `--mvp` automatically without the flag. |
|
||||
| `--no-tracer` | Opt out of the default **tracer-first** decomposition and plan horizontal layers (the legacy default). By default every plan leads with one production-quality end-to-end `tracer` slice that the executor verifies before any expansion task. |
|
||||
| `--tdd` | TDD mode — planner applies `type: tdd` to eligible behavior-adding tasks so each begins with a failing test. Composable with `--mvp`: `--mvp --tdd` produces vertical slices where every behavior-adding task starts red-green. The leading `tracer` task also starts red under `--tdd`. |
|
||||
| `--granularity <coarse\|standard\|fine>` | Override the planning granularity for this invocation, ignoring config. Valid values: `coarse`, `standard`, `fine`. Takes precedence over `granularities.planning`, top-level `granularity`, and `planning.granularity` config. |
|
||||
|
||||
**Prerequisites:** `.planning/ROADMAP.md` exists
|
||||
|
||||
@@ -78,17 +78,23 @@ If you want this granularity applied permanently, set it in config — see [CONF
|
||||
|
||||
---
|
||||
|
||||
## Plan vertical feature slices instead of horizontal layers
|
||||
## Tracer-first slices (the default) and opting out
|
||||
|
||||
**If you want tasks organised as thin end-to-end slices** (UI → API → DB per feature) rather than by technical layer:
|
||||
**By default, every plan leads with a `tracer` task** — the thinnest end-to-end slice (UI → API → DB) that touches every layer the phase modifies, wired and verified before any expansion task. A tracer is production-quality, not a throwaway prototype (see the `tracer bullet` glossary entry in `CONTEXT.md`). This proves the architecture early instead of discovering an integration dead-end after ten committed layers.
|
||||
|
||||
To opt out and plan horizontal layers (the legacy default):
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 1 --no-tracer
|
||||
```
|
||||
|
||||
`--mvp` layers MVP enrichment on top of tracer-first — it frames the phase goal as a user story and, on Phase 1 of a new project with no prior phase summaries, also produces `SKELETON.md` (a Walking Skeleton covering project scaffold, routing, one real DB read/write, one real UI interaction, and dev deployment):
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 1 --mvp
|
||||
```
|
||||
|
||||
On Phase 1 of a new project with no prior phase summaries, `--mvp` also produces `SKELETON.md` — a Walking Skeleton covering project scaffold, routing, one real DB read/write, one real UI interaction, and dev deployment.
|
||||
|
||||
You can persist MVP mode for a phase without the flag by adding `**Mode:** mvp` to that phase's entry in ROADMAP.md.
|
||||
You can persist MVP enrichment for a phase without the flag by adding `**Mode:** mvp` to that phase's entry in ROADMAP.md.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -144,7 +144,7 @@ References source files the executor needs to read. Includes project-level plann
|
||||
|
||||
### `<tasks>`
|
||||
|
||||
Contains one or more `<task>` elements. Every task element must carry `<name>`, `<files>`, `<read_first>`, `<action>`, `<verify>`, `<acceptance_criteria>`, and `<done>` for `type="auto"` tasks.
|
||||
Contains one or more `<task>` elements. Every task element must carry `<name>`, `<files>`, `<read_first>`, `<action>`, `<verify>`, `<acceptance_criteria>`, and `<done>` for `type="auto"` and `type="tracer"` tasks.
|
||||
|
||||
---
|
||||
|
||||
@@ -153,6 +153,7 @@ Contains one or more `<task>` elements. Every task element must carry `<name>`,
|
||||
| Type | Use | Autonomy |
|
||||
|---|---|---|
|
||||
| `auto` | Everything the executor can do independently. | Fully autonomous. |
|
||||
| `tracer` | The leading thin end-to-end slice a plan starts with by default (tracer-first) — production-quality, wired through every layer, with a real end-to-end `<verify>`. | Fully autonomous; after committing, the executor runs the tracer's `<verify>` as an early integration gate — autonomous runs halt on failure before expansion, interactive runs present a `checkpoint:human-verify`. |
|
||||
| `checkpoint:human-verify` | Visual or functional verification that requires a human to look at a running UI or service. | Pauses execution; presents to the developer; resumes on approval. |
|
||||
| `checkpoint:decision` | Implementation choices that arose during execution and require the developer's input. | Pauses execution; presents options; resumes on selection. |
|
||||
| `checkpoint:human-action` | Truly unavoidable manual steps (account creation, hardware interaction). Used sparingly. | Pauses execution; resumes on confirmation. |
|
||||
|
||||
Reference in New Issue
Block a user