mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-09-21 12:50:25 +08:00
Alex Verkhovsky
4626b1128a
The `review` status is an atavism of the v6 pipeline. Back then implementation and review were two skills: bmad-dev-story implemented, set the story to `review`, and handed off, closing with the tip to run code-review "using a different LLM than the one that implemented this story". The implementing model could not credibly review its own work, so `review` was the seam between two skills and code-review was the only thing that could carry a story to `done`. bmad-dev-story is a deprecated shim now. Build absorbed the implementation role and inherited the seam without the reason for it. Build reviews internally: step-04 stages a diff, runs three context-free subagents in parallel, verifies each finding at the site it names, assigns severity, triages, and patches. The independence the v6 tip asked a human to arrange by switching models, build arranges structurally by denying its reviewers context. The handoff it announces is to nobody. The leftover write also contradicts itself and blocks the retro: step-05 sets the spec frontmatter to `done` and syncs sprint-status.yaml to `review` two lines later, and bmad-retrospective gates on stories not being `done`, so a fully built epic always opens with an "unfinished stories, retro anyway?" prompt. Demoting the spec is not available — step-01 scans for `status: done` to load previous-story continuity and build-auto halts on `in-review` — so the sprint key is the side that moves. Sync `done` from both routes instead. `review` stays in the vocabulary as the state for a story someone deliberately parks for another pair of eyes, and code-review keeps its power to send one back to `in-progress` when it finds unresolved work.