What happens
On spec 250, 20 implementation consultation rounds ran (2 lanes each, 43 lane files on disk).
status.yaml history records 9.
Recorded:
phase_1 iter1 phase_2 iter1 phase_3 iter1
phase_4 iter1 phase_4 iter2 phase_5 iter1
phase_6 iter1 phase_10 iter1 phase_11 iter1
The pattern is exact
Cross-referencing every recorded round against its verdicts, a round is recorded if and only if
at least one lane did not approve.
- phases 7, 8 and 9 are absent entirely. They are the three phases where both lanes approved on
round 1. They have lane files on disk and no history entry at all.
- Every terminal (approving) round is missing. phase_1 iter2, phase_2 iter2, phase_3 iter2,
phase_4 iter3, phase_5 iter2, phase_6 iter2, phase_10 iter2, phase_11 iter2 — all APPROVE on both
lanes, none recorded.
- phase_4 iter2 is recorded, and it is the one middle iteration that still carried a
REQUEST_CHANGES (opencode).
There is no exception in either direction across 20 rounds.
Why it matters
history is the only machine-readable record of what review actually happened, and it currently
shows the rework and never the approval that ended it. Two concrete consequences:
- A phase reviewed cleanly is indistinguishable from a phase never reviewed. Both have no
entry. That is the "could not tell must not be spelled like no" rule broken in the protocol's
own state file.
history understates review effort by more than half (9 of 20), and it understates it
selectively — the record is biased toward phases that went badly.
Anyone auditing a project's review coverage from status.yaml will draw the wrong conclusion, and
the artifacts that would correct them (codev/projects/*/*.txt) are gitignored, so they do not
travel with the PR.
Expected
Every consultation round appends to history, whatever its verdicts. The approving round is the
most useful one to record: it is the one that says the phase was cleared, and by whom.
Reproduce
Any SPIR project where a phase's consultation approves on the first round. Compare:
# rounds that ran
ls codev/projects/<id>-*/ | grep '\.txt$' \
| sed 's/-\(claude\|opencode\|codex\|gemini\)\.txt$//' | sort -u | wc -l
# rounds recorded
grep -c 'plan_phase:' codev/projects/<id>-*/status.yaml
Found by
Spec 250, review phase — raised by the claude lane's PR review of #266 and confirmed against the
artifacts. status.yaml was not hand-edited.
What happens
On spec 250, 20 implementation consultation rounds ran (2 lanes each, 43 lane files on disk).
status.yamlhistoryrecords 9.Recorded:
The pattern is exact
Cross-referencing every recorded round against its verdicts, a round is recorded if and only if
at least one lane did not approve.
round 1. They have lane files on disk and no
historyentry at all.phase_4 iter3, phase_5 iter2, phase_6 iter2, phase_10 iter2, phase_11 iter2 — all APPROVE on both
lanes, none recorded.
REQUEST_CHANGES(opencode).There is no exception in either direction across 20 rounds.
Why it matters
historyis the only machine-readable record of what review actually happened, and it currentlyshows the rework and never the approval that ended it. Two concrete consequences:
entry. That is the "could not tell must not be spelled like no" rule broken in the protocol's
own state file.
historyunderstates review effort by more than half (9 of 20), and it understates itselectively — the record is biased toward phases that went badly.
Anyone auditing a project's review coverage from
status.yamlwill draw the wrong conclusion, andthe artifacts that would correct them (
codev/projects/*/*.txt) are gitignored, so they do nottravel with the PR.
Expected
Every consultation round appends to
history, whatever its verdicts. The approving round is themost useful one to record: it is the one that says the phase was cleared, and by whom.
Reproduce
Any SPIR project where a phase's consultation approves on the first round. Compare:
Found by
Spec 250, review phase — raised by the claude lane's PR review of #266 and confirmed against the
artifacts.
status.yamlwas not hand-edited.