Cross-vendor review
A second CLI, on a different vendor, reads a sealed write task before its branch is eligible to promote.
Goal#
Have a different agent CLI — a different vendor, never the one that wrote the code — look at every clean write task before you merge it. Read-only: the reviewer cannot touch a file, and its own seal fails if it tries. Off by default.
Steps#
-
Turn it on in
orch.yaml:review: enabled: true reviewer: copilot # optional — see "Which preset reviews" below on: [write] # default; the only trigger today block_on_reject: true # optional — refuse to promote on request_changes timeout_sec: 180 # default -
Dispatch work as usual (
dispatch_worker,orch task run,orch dispatch). When a task sealsokwith at least one changed file, Orchemax dispatches a read-only reviewer on a different preset, capped attimeout_sec, and blocks the seal until it answers — the same finish() that already reports to the Chair, sotask_wait/dispatch_workersee the verdict already attached. -
Read the verdict in
verify_report.review:{ "review": { "verdict": "approve", "reviewer": "copilot", "session": "20260917T...-copilot", "elapsed_ms": 41230 } }orch task show <id>and the evidence bundle (orch evidence <session>) carry the same field.verdictis one of:approve,request_changes(with up to 10file:line — issuefindings),unparsed(the reviewer replied with something that was not one of the two tags),invalid(the reviewer wrote to a file — its verdict is discarded),timeout,error, orskipped(see below). -
With
block_on_reject: true,worktree_promote(and the Telegram/approvecommand) refuses arequest_changesverdict, naming the reviewer's session; without it, the verdict only annotates.
Which preset reviews#
review.reviewer names the preset explicitly. Left empty, or set to the same
preset the writer just used, Orchemax falls back to the next different headless
preset the workspace has configured (agents.cmds). A single-vendor workspace
has nothing to cross-check with — the verdict reads skipped: no second vendor instead of silently approving.
Why read-only, not a checkout of the exact branch#
Git refuses a second worktree on a branch already checked out elsewhere, so
the reviewer gets its own worktree and inspects the diff with plain git
(git diff <base>...<branch>) rather than checking the writer's branch out a
second time. The seal is what actually enforces read-only: a reviewer that
creates, edits or deletes anything fails its own verification with review: reviewer modified files, and that verdict is invalid rather than trusted.