Observed on a live card (mult-021), where the log tells the whole story: Documentation
returned an advisory REVISE asking for implementation work, the card was "moved back to
in-progress for remediation", and 467ms later Code Review started again. No step was ever
created, no executor session ran, and the demand was never implemented — the card merged
when the second Documentation pass happened to pass.
Two separate defects produced that.
FIRST, the reporter could hold the merge. An advisory REVISE records `advisory_failure`,
and `resolveRequiredPreMergeStepIds` included the Documentation group, so
`evaluatePreMergeApprovals` read it as "not-approved". `gateMode: "advisory"` only stops
the node blocking traversal; it says nothing to the merge door.
SECOND, the reporter could bounce. `requestPreMergeOptionalStepFix` accepts
`advisory_failure`, and under this workflow's named-remediation policy the resulting
`sendTaskBackForFix` reopens NOTHING. With no pending step the foreach answered
`already-expanded` and the walk replayed the review lane over an unchanged tree. The
budget was 1/10, so it could have burned ten rounds of two model calls each.
New opt-in `reportingOnly` on an optional group states the contract once — no approval to
withhold, no remediation to request — and both doors read it. It is set only on
Documentation, so advisory gates that DO own remediation (browser verification) keep their
behaviour exactly.
Plus the general invariant that would have caught both: under `stepReopenPolicy: "none"`,
a bounce that appended no named steps is refused and logged on the card. Only the gates
that can APPEND work may send a card back. Code Review REVISE and the deterministic
verification failure still produce named fix steps — unchanged, still covered.
pnpm lint 0 errors, test:gate green, core + engine typecheck clean, pipeline-smoke 90/90.
56ee1622df