Deferred triage: blocking should block the land, not the run #193

Closed
opened 2026-08-16 15:41:13 +00:00 by john · 1 comment
Owner

The problem

Blocking currently means "blocks the run". A blocking risk_surface FAIL or an
adjudicated triage gate stops the phase and waits for a human, which means the
human has to be there, which means Cadence can only run while someone is
watching it.

That is defensible as a default and it is also the single constraint that stops
the tool from working overnight. The guarantee that actually matters is that
unreviewed work does not LAND, not that unreviewed work is not WRITTEN.

The proposal

A third gate mode beside advisory and adjudicated: deferred.

  • The gate still fires, still runs the reviewer, still persists findings to the
    phase's artifacts exactly as the advisory arm already does.
  • The run does NOT stop. The phase completes, the commits exist on the
    integration branch, and the findings queue.
  • The cursor lands in a state that names the queue, so /cad-progress reports it
    and /cad-land REFUSES while any deferred finding is unadjudicated.

The block moves from the dispatch boundary to the land boundary. Nothing ships
unreviewed; the review just stops being synchronous with the work.

What this deliberately does not change

The protected-branch guard stays where it is. That one is not a review finding,
it is a question about where commits go, and it has to be answered before the
first one exists.

The one-round re-arm cap in triage-gate.md still binds. A deferred gate that
FAILs is adjudicated once, later, not looped.

Why it is a philosophy change

Today the design assumes a human is standing at every gate. That population
shrinks as agents improve, and Cadence's answer to it should not be to weaken a
gate. Moving the block to the land boundary keeps every guarantee and gives up
only immediacy.

How you would know it worked

An overnight run that completes a multi-phase milestone, with /cad-land
refusing until the queued findings are triaged in one sitting the next morning.
If the queue is routinely large enough that batch triage is worse than
per-phase triage, the mode is wrong and should be deleted.

## The problem Blocking currently means "blocks the run". A blocking `risk_surface` FAIL or an adjudicated triage gate stops the phase and waits for a human, which means the human has to be there, which means Cadence can only run while someone is watching it. That is defensible as a default and it is also the single constraint that stops the tool from working overnight. The guarantee that actually matters is that unreviewed work does not LAND, not that unreviewed work is not WRITTEN. ## The proposal A third gate mode beside `advisory` and `adjudicated`: `deferred`. - The gate still fires, still runs the reviewer, still persists findings to the phase's artifacts exactly as the advisory arm already does. - The run does NOT stop. The phase completes, the commits exist on the integration branch, and the findings queue. - The cursor lands in a state that names the queue, so `/cad-progress` reports it and `/cad-land` REFUSES while any deferred finding is unadjudicated. The block moves from the dispatch boundary to the land boundary. Nothing ships unreviewed; the review just stops being synchronous with the work. ## What this deliberately does not change The protected-branch guard stays where it is. That one is not a review finding, it is a question about where commits go, and it has to be answered before the first one exists. The one-round re-arm cap in `triage-gate.md` still binds. A deferred gate that FAILs is adjudicated once, later, not looped. ## Why it is a philosophy change Today the design assumes a human is standing at every gate. That population shrinks as agents improve, and Cadence's answer to it should not be to weaken a gate. Moving the block to the land boundary keeps every guarantee and gives up only immediacy. ## How you would know it worked An overnight run that completes a multi-phase milestone, with `/cad-land` refusing until the queued findings are triaged in one sitting the next morning. If the queue is routinely large enough that batch triage is worse than per-phase triage, the mode is wrong and should be deleted.
Author
Owner

Accepted - build it. This is the only item on the decision list that buys a CAPABILITY rather than making an existing thing cheaper or tidier: a deferred gate mode moves the block from the dispatch boundary to the land boundary, and that is what lets a run finish without a human watching it. The guarantee is preserved as stated - the gate still fires, findings still persist to the phase artifacts exactly as the advisory arm already does, and /cad-land refuses while anything is unadjudicated. The carve-outs in the issue are right and stand: the protected-branch guard does not move, and the one-round re-arm cap still binds (#197 closed 2026-08-17 as refuted, so no valve is coming).

Not milestoned here - scope it into a release when the v3.5.3 branch lands.

Accepted - build it. This is the only item on the decision list that buys a CAPABILITY rather than making an existing thing cheaper or tidier: a `deferred` gate mode moves the block from the dispatch boundary to the land boundary, and that is what lets a run finish without a human watching it. The guarantee is preserved as stated - the gate still fires, findings still persist to the phase artifacts exactly as the advisory arm already does, and `/cad-land` refuses while anything is unadjudicated. The carve-outs in the issue are right and stand: the protected-branch guard does not move, and the one-round re-arm cap still binds (#197 closed 2026-08-17 as refuted, so no valve is coming). Not milestoned here - scope it into a release when the v3.5.3 branch lands.
john added this to the v3.5.7 milestone 2026-08-20 15:34:04 +00:00
john closed this issue 2026-08-22 11:45:37 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: crenshawdev/cadence-archived#193
No description provided.