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#

  1. 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
    
  2. Dispatch work as usual (dispatch_worker, orch task run, orch dispatch). When a task seals ok with at least one changed file, Orchemax dispatches a read-only reviewer on a different preset, capped at timeout_sec, and blocks the seal until it answers — the same finish() that already reports to the Chair, so task_wait/dispatch_worker see the verdict already attached.

  3. 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. verdict is one of: approve, request_changes (with up to 10 file:line — issue findings), 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, or skipped (see below).

  4. With block_on_reject: true, worktree_promote (and the Telegram /approve command) refuses a request_changes verdict, 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.