What happened
Running record-gate-review on a superpowers-lane epic that had just completed a full two-reviewer Gate 2:
conductor: record-gate-review only applies to openspec-lane epics
('per-verb-help-from-flag-registry' is lane 'superpowers')
The refusal is correct against the current design — the mechanical archive gate is openspec-only, and a verdict field nothing consumes would be worse than none. But the review had genuinely happened, under reviewMode: thorough, with two independent fresh-context reviewers, a BASE..HEAD range, and findings that changed the code. There was nowhere structured to put any of it.
The workaround was --notes with the whole verdict as prose. That is the shape this repo already recognises as a filing rather than a footnote: a convention invented because no verb existed for it.
Why it matters
set-review-mode is lane-agnostic — standard and thorough describe reviewer budget per gate for "OpenSpec Gate 1/Gate 2, a Superpowers task review", in the rules block's own words. So pm tells every lane to run reviews and can only record the verdict for one of them.
The consequences are the ones #113 and #122 already established as defects, reappearing one lane over:
- Evidence is unverifiable.
--base-sha/--head-sha exist so a verdict whose recorded head does not reach the epic's attributed commits reads stale. In --notes those shas are prose; nothing compares them, so nothing can go stale, so a superpowers verdict cannot be wrong — which is exactly the "record over-reporting completion" problem 0.27.0 was built to end.
integrity cannot see it. Its gate checks key off gateReview, so a superpowers epic archived after a real two-reviewer gate is indistinguishable from one nobody reviewed.- Silence and reviewed-and-clean look identical, the same asymmetry the cross-spec gate exists to remove at release scope.
Not asking for the archive gate to be extended
Blocking a superpowers archive on a recorded Gate 2 would be a different, much larger decision, and probably the wrong one — the lanes differ precisely in how much ceremony they carry. The ask is narrower: let a verdict be recorded and rendered where a review actually happened, without making it mandatory anywhere it is not today.
Sketch, not a design:
- Accept
record-gate-review on any lane, storing the same {verdict, reviewedAt, baseSha, headSha, reviewer} shape.
- Keep the archive gate openspec-only, exactly as now.
- Let
integrity's staleness check run wherever a verdict exists, since that check is about the record's internal consistency and not about the lane.
- Render it in
PROJECT.md and the briefing the way openspec verdicts already are.
The one real design question is what --gate 1|2 means outside OpenSpec, where there is no propose/apply split. A superpowers review is one gate, not two. Possibly --gate review, possibly gate 2 by convention — worth deciding rather than inheriting.
Evidence
Found while shipping 0.37.0. The verdict now lives at per-verb-help-from-flag-registry's --notes in this repo's own .conductor/state.json: a full Gate 2 pass, two reviewers, a real commit range, one Important finding that falsified the release's headline invariant and was fixed before merge — and none of it is machine-readable.
What happened
Running
record-gate-reviewon asuperpowers-lane epic that had just completed a full two-reviewer Gate 2:The refusal is correct against the current design — the mechanical archive gate is openspec-only, and a verdict field nothing consumes would be worse than none. But the review had genuinely happened, under
reviewMode: thorough, with two independent fresh-context reviewers, aBASE..HEADrange, and findings that changed the code. There was nowhere structured to put any of it.The workaround was
--noteswith the whole verdict as prose. That is the shape this repo already recognises as a filing rather than a footnote: a convention invented because no verb existed for it.Why it matters
set-review-modeis lane-agnostic —standardandthoroughdescribe reviewer budget per gate for "OpenSpec Gate 1/Gate 2, a Superpowers task review", in the rules block's own words. So pm tells every lane to run reviews and can only record the verdict for one of them.The consequences are the ones #113 and #122 already established as defects, reappearing one lane over:
--base-sha/--head-shaexist so a verdict whose recorded head does not reach the epic's attributed commits reads stale. In--notesthose shas are prose; nothing compares them, so nothing can go stale, so a superpowers verdict cannot be wrong — which is exactly the "record over-reporting completion" problem 0.27.0 was built to end.integritycannot see it. Its gate checks key offgateReview, so a superpowers epic archived after a real two-reviewer gate is indistinguishable from one nobody reviewed.Not asking for the archive gate to be extended
Blocking a superpowers archive on a recorded Gate 2 would be a different, much larger decision, and probably the wrong one — the lanes differ precisely in how much ceremony they carry. The ask is narrower: let a verdict be recorded and rendered where a review actually happened, without making it mandatory anywhere it is not today.
Sketch, not a design:
record-gate-reviewon any lane, storing the same{verdict, reviewedAt, baseSha, headSha, reviewer}shape.integrity's staleness check run wherever a verdict exists, since that check is about the record's internal consistency and not about the lane.PROJECT.mdand the briefing the way openspec verdicts already are.The one real design question is what
--gate 1|2means outside OpenSpec, where there is no propose/apply split. A superpowers review is one gate, not two. Possibly--gate review, possibly gate 2 by convention — worth deciding rather than inheriting.Evidence
Found while shipping 0.37.0. The verdict now lives at
per-verb-help-from-flag-registry's--notesin this repo's own.conductor/state.json: a full Gate 2 pass, two reviewers, a real commit range, one Important finding that falsified the release's headline invariant and was fixed before merge — and none of it is machine-readable.