Two-reviewer consensus

The pull request opens and CI runs first, with the agent fixing a failing check. Then two independent review-network passes run in parallel on the green code, and both must approve. Either one rejecting sends the combined feedback back to the implementer, and CI runs again before the reviewers do.

Template	consensus-review
Works on	A git repository, cloned into an isolated Docker sandbox
Where a person acts	Nobody inside the run. The pull request it opens is merged by a person, outside it.
Waits on systems	CI result, up to 4h
Parallel work	Yes — branches run concurrently

The workflow

Drawn from the template spec at build time. Bookkeeping nodes that only record status are left out; amber nodes are where a person acts.

flowchart TD
  n_validate["Validate"]
  n_implement["Implement"]
  n_openPR["Open PR"]
  n_waitForCI[/"Wait for CI<br/><small>waits up to 4h: CI result</small>"/]
  n_checkCI{"Check CI?"}
  n_terminateCITimedOut(["Timed out<br/><small>ci timed out</small>"])
  n_fanOutReview["Fan out review<br/><small>runs branches in parallel</small>"]
  n_checkCILimit{"Check CI limit?"}
  n_runBranchReview["Run branch review"]
  n_checkConsensus{"Check consensus?"}
  n_lessonCIFailed["Lesson CI failed"]
  n_fetchLogs["Fetch logs"]
  n_checkBranchApproval{"Check branch approval?"}
  n_done(["Done"])
  n_checkReviewLimit{"Check review limit?"}
  n_terminateCIFailed(["Failed<br/><small>ci failed</small>"])
  n_ciFix["CI fix"]
  n_branchApproved(["Done<br/><small>branch approved</small>"])
  n_branchRejected(["Failed<br/><small>branch rejected</small>"])
  n_lessonReviewFailed["Lesson review failed"]
  n_consensusFix["Consensus fix"]
  n_checkCiFixChanged{"Check CI fix changed?"}
  n_terminateReviewFailed(["Failed<br/><small>review failed</small>"])
  n_checkConsensusFixChanged{"Check consensus fix changed?"}
  n_repushAfterFix["Repush after fix"]
  n_validate --> n_implement
  n_implement --> n_openPR
  n_openPR --> n_waitForCI
  n_waitForCI -->|"received"| n_checkCI
  n_waitForCI -->|"timed out"| n_terminateCITimedOut
  n_checkCI -->|"yes"| n_fanOutReview
  n_checkCI -->|"no"| n_checkCILimit
  n_fanOutReview -->|"each branch"| n_runBranchReview
  n_fanOutReview -->|"joined"| n_checkConsensus
  n_checkCILimit -->|"yes"| n_lessonCIFailed
  n_checkCILimit -->|"no"| n_fetchLogs
  n_runBranchReview --> n_checkBranchApproval
  n_checkConsensus -->|"yes"| n_done
  n_checkConsensus -->|"no"| n_checkReviewLimit
  n_lessonCIFailed --> n_terminateCIFailed
  n_fetchLogs --> n_ciFix
  n_checkBranchApproval -->|"yes"| n_branchApproved
  n_checkBranchApproval -->|"no"| n_branchRejected
  n_checkReviewLimit -->|"yes"| n_lessonReviewFailed
  n_checkReviewLimit -->|"no"| n_consensusFix
  n_ciFix --> n_checkCiFixChanged
  n_lessonReviewFailed --> n_terminateReviewFailed
  n_consensusFix --> n_checkConsensusFixChanged
  n_checkCiFixChanged -->|"yes"| n_checkCILimit
  n_checkCiFixChanged -->|"no"| n_repushAfterFix
  n_checkConsensusFixChanged -->|"yes"| n_fanOutReview
  n_checkConsensusFixChanged -->|"no"| n_repushAfterFix
  n_repushAfterFix --> n_waitForCI
  class n_waitForCI wait

Maturity: built from the flagship steps

Ships as a built-in template and reuses the engineering steps the flagship flow runs. This particular arrangement of them is not separately exercised end to end against a real repository. See product overview §8.

Use it

Every built-in template is seeded into the workflow library and can be cloned, edited on the visual canvas, and versioned — see architecture for the node types. The spec lives in packages/shared/src/workflow/templates/consensusReview.ts.