swarm-review — the milestone gate
Reviews against the spec, not just the code — that is the difference between this and
a linter. Expect a top-tier model; warn if the session runs less. Milestone cadence only
(token economy): not per-commit.
Scope: the milestone's diff (git log since last sweep), its tickets, and its FR specs.
The four lenses, in order
- Fulfillment (the one that matters most): every Must-FR of the milestone,
individually — no sampling. Are the acceptance criteria actually met? Do the tests
assert the criteria (not just execute the code)? Is the FR → ticket → commit → test
chain intact?
- Standards: naming, error handling (exceptions handled, not swallowed), comment
discipline (light, constraint-stating), test quality (behavior asserted, not
implementation), commit hygiene — audited against swarm-implement's
references/clean-code.md where available, including its dogma traps: fragment soup,
one-implementation abstractions, pattern theater, and SRP shrapnel are findings, not
compliance. End-user text shipped in the
milestone (UI strings, README, release notes, marketing) is audited against the project's
voice.md and the audience firewall — load swarm-write for the criteria.
- Simplification: duplicated logic to merge, needless abstraction to delete, blocks
that could be simpler or generalized. If a fix is obvious and small, still ticket it —
see the rule below.
- Risk: input validation gaps, security smells, and a devil's-advocate pass — "what
assumption, if wrong, hurts most?"
Findings
One per issue, compact (machine lane): severity (blocker/major/minor), FR link,
file:line evidence, concrete suggested fix. Write the report to
30 Plans/<P>/reviews/M<N>-sweep.md (human-lane summary + machine-lane findings), then
one ticket per accepted finding — findings that stay chat messages die in scrollback.
Never auto-fix. Reporting and fixing in the same pass corrupts the review; fixes are
swarm-implement's job via the tickets.
Closing the gate
- Gated mode: present the report; the user decides what's waived; milestone closes on
their word.
- Auto mode: the sweep IS the gate —
blocker/fulfillment findings must be fixed and
re-swept before the next milestone opens; the user reads the report in the vault at
their leisure. Minor findings may carry forward as open tickets.
Update flow-state either way (J1).
Influences: Pocock's code-review (two-axis); Jeffallan's code-reviewer &
security-reviewer & the-fool; superpowers verification-before-completion; euxx
code-simplifier — see CREDITS.md.
1---2name: swarm-review3description: swarm-review — the milestone gate4---56# swarm-review — the milestone gate78Reviews against the **spec**, not just the code — that is the difference between this and9a linter. Expect a top-tier model; warn if the session runs less. Milestone cadence only10(token economy): not per-commit.1112**Scope:** the milestone's diff (git log since last sweep), its tickets, and its FR specs.1314## The four lenses, in order15161. **Fulfillment** (the one that matters most): every Must-FR of the milestone,17 individually — no sampling. Are the acceptance criteria actually met? Do the tests18 *assert the criteria* (not just execute the code)? Is the FR → ticket → commit → test19 chain intact?202. **Standards:** naming, error handling (exceptions handled, not swallowed), comment21 discipline (light, constraint-stating), test quality (behavior asserted, not22 implementation), commit hygiene — audited against swarm-implement's23 `references/clean-code.md` where available, **including its dogma traps**: fragment soup,24 one-implementation abstractions, pattern theater, and SRP shrapnel are findings, not25 compliance. **End-user text** shipped in the26 milestone (UI strings, README, release notes, marketing) is audited against the project's27 `voice.md` and the audience firewall — load swarm-write for the criteria.283. **Simplification:** duplicated logic to merge, needless abstraction to delete, blocks29 that could be simpler or generalized. If a fix is obvious and small, still ticket it —30 see the rule below.314. **Risk:** input validation gaps, security smells, and a devil's-advocate pass — "what32 assumption, if wrong, hurts most?"3334## Findings3536One per issue, compact (machine lane): severity (`blocker/major/minor`), FR link,37`file:line` evidence, concrete suggested fix. Write the report to38`30 Plans/<P>/reviews/M<N>-sweep.md` (human-lane summary + machine-lane findings), then39**one ticket per accepted finding** — findings that stay chat messages die in scrollback.4041**Never auto-fix.** Reporting and fixing in the same pass corrupts the review; fixes are42swarm-implement's job via the tickets.4344## Closing the gate4546- **Gated mode:** present the report; the user decides what's waived; milestone closes on47 their word.48- **Auto mode:** the sweep IS the gate — `blocker`/fulfillment findings must be fixed and49 re-swept before the next milestone opens; the user reads the report in the vault at50 their leisure. Minor findings may carry forward as open tickets.5152Update flow-state either way (J1).5354---55*Influences: Pocock's code-review (two-axis); Jeffallan's code-reviewer &56security-reviewer & the-fool; superpowers verification-before-completion; euxx57code-simplifier — see CREDITS.md.*