Revision cruzada entre proveedores

Una segunda CLI, de otro proveedor, revisa una tarea de escritura sellada antes de que su rama sea elegible para promover.

Objetivo#

Que un agente CLI distinto — otro proveedor, nunca el que escribio el codigo — revise cada tarea de escritura sellada limpia antes de mezclarla. Solo lectura: el revisor no puede tocar un archivo, y su propio sellado falla si lo intenta. Apagado por defecto.

Pasos#

Enciendelo en orch.yaml:

review:
  enabled: true
  reviewer: copilot      # opcional — ver "Que preset revisa" mas abajo
  on: [write]            # por defecto; el unico disparador hoy
  block_on_reject: true  # opcional — rechaza promover en request_changes
  timeout_sec: 180       # por defecto

Despacha trabajo como siempre (dispatch_worker, orch task run, orch dispatch). Cuando una tarea sella ok con al menos un archivo cambiado, Orchemax despacha un revisor de solo lectura en un preset distinto, con tope de timeout_sec, y bloquea el sellado hasta que responde — el mismo finish() que ya reporta al Chair, asi que task_wait/dispatch_worker ven el veredicto ya adjunto.
Lee el veredicto en verify_report.review:
```
{
  "review": {
    "verdict": "approve",
    "reviewer": "copilot",
    "session": "20260917T...-copilot",
    "elapsed_ms": 41230
  }
}
```
orch task show <id> y el paquete de evidencia (orch evidence <session>) llevan el mismo campo. verdict es uno de: approve, request_changes (con hasta 10 hallazgos file:line — issue), unparsed (el revisor respondio algo que no era una de las dos etiquetas), invalid (el revisor escribio en un archivo — su veredicto se descarta), timeout, error, o skipped (ver abajo).
Con block_on_reject: true, worktree_promote (y el comando de Telegram /approve) rechaza un veredicto request_changes, nombrando la sesion del revisor; sin eso, el veredicto solo queda anotado.

Que preset revisa#

review.reviewer nombra el preset explicitamente. Vacio, o igual al preset que acaba de usar quien escribio, Orchemax cae al siguiente preset headless distinto que el workshop tenga configurado (agents.cmds). Un workshop de un solo proveedor no tiene con que cruzar la revision — el veredicto queda skipped: no second vendor en vez de aprobar en silencio.

Por que solo lectura, no un checkout de la rama exacta#

Git rechaza un segundo worktree sobre una rama ya usada en otro lado, asi que el revisor recibe su propio worktree e inspecciona el diff con git plano (git diff <base>...<branch>) en vez de sacar la rama de quien escribio por segunda vez. El sellado es lo que de verdad exige solo lectura: un revisor que crea, edita o borra algo falla su propia verificacion con review: reviewer modified files, y ese veredicto queda invalid en vez de confiarse.