git:20261105.9da51a7 to git:20261107.629412d

+ description: Review a verified spex feature from its diff, read only, for what no test sees — unrequested changes, a broken boundary, a signature that differs from produces, a bug or a hole the tests missed — and route each finding into a fix task, a question, a test rewritten by a test-developer subagent, or the deferred list. The script already proved the tests; the reviewer never reruns them. Use when the user says "review", "spex review", or after /spex:verify is green.

+ allowed-tools: Bash(node ${CLAUDE_PLUGIN_ROOT}/scripts/spex.mjs *), Agent, Read(${CLAUDE_PLUGIN_ROOT}/skills/*/SKILL.md)

+ 1. `SPEX gate review <dir>`; refused: relay the `fix` text (a task left, or no green

+ `spex verify` at this tree) and stop.

+ prints the evidence line (which verify round proved the tests), the requirements, the

+ tasks, the boundaries and the deferred list. If it refuses with `REVIEW-DIFF-BIG`, review

+ per task: `SPEX show <dir> --review --task T01`, one task at a time. Read the diff file.

+ Do not explore the codebase and do not rerun the tests: the script proved them, and the

+ evidence is in `.spex/evidence/`.

+ **More than three tasks:** say `Review: 6 tasks → 6 agents`, then start one

+ `spex:reviewer` subagent per task, all in one message, each with one line:

+ `<dir> <task>. Review its slice.` Each returns its spec verdict, unrequested changes and

+ blocking findings with file and line. Treat them as claims: open the diff at every

+ blocking finding before you route it. The quality verdict over the whole diff (step 4)

+ stays yours, because duplication and coherence live between the slices.

+ 3. Spec verdict, one line per requirement. A requirement whose tests are green is `met` by

+ the evidence; read the diff for `cannot-verify` ones (no test can see them) and for

+ `contradicts` (the code does other or more than the record). Then list `unrequested`

+ changes: code no requirement asked for. The developer's report is a claim, not evidence.

+ requirement ids, `paths`, `context`, `instructions`, `done_when`, `status: todo`. Its

+ proof: when the finding is a missed case of a record, append the task id to the

+ `covers` of that record's tests in `tests.yaml`; a finding no test sees gets one

+ `spex:test-analyst` with `<dir> <task id>: <finding>`, which plans one.

+ options and a recommendation, then settle it here the way `/spex:clarify` does in auto

+ mode: read `${CLAUDE_PLUGIN_ROOT}/skills/clarify/SKILL.md` and do its steps 4 to 7

+ with the decider. The record change it makes sets the record back to `draft`.

+ - `test-bug`: a green test asserts other than its claim, and the code was written to it.

+ Say `Fix test: TSxx → 1 test developer` and start one `spex:test-developer` with

+ `<dir> TSxx: <what is wrong>`; it rewrites that one test from its plan record, never

+ reads the source, and proves it. Then `SPEX run <dir> --test TSxx`: red means the code

+ met the wrong test, so route a `patch` with the finding as `source`; green means the

+ code meets the claim already. Never edit the test yourself.

+ - `defer`: never ask the user. One `spex:decider` gets the finding, the records it

+ touches and the feature's Why; on its verdict to defer, append to `deferred[]`

+ (`finding`, `why`, `by: agent`), else route it as `patch`.

+ finding, one `--question` per spec gap. `done` means clean: ship is next. `concerns`

+ means findings were routed, and the NEXT block names the stage that takes them. The

+ round count is on the first line of the show output; past `review_rounds`, stop and

+ hand the feature to a person.

+ unrequested changes, the blocking findings with their route, and the deferred items. Last,

+ the output of `SPEX next <dir>`, as printed.

+

+ The NEXT block is copied as `SPEX next` printed it, the two rules included, never rewritten

+ into prose or shortened, and it does not count toward the line cap.