Chair y workers

Un Chair por proyecto, elegido por llegada. Un segundo Chair interactivo se rechaza, y los workers no pueden lanzar workers.

Qué es#

Dos roles, y solo dos.

Rol Cómo se define ¿Puede lanzar workers?
chair El primer asiento interactivo orch <agent> de un proyecto, abierto sin tarea Sí — dispatch_worker, task_add, task_run
worker Creado por task_run o dispatch_worker, o cualquier proceso con ORCH_ROLE=worker No — el intento da error 
        tú, escribiendo en la interfaz del agente
                   |
                 Chair                (uno por proyecto git)
             /     |     \
        worker  worker  worker        (un worktree orch/<session> cada uno)
             \     |     /
           msg_send / ask / verify_report
                   |
                 Chair

La elección es por llegada, no por configuración. Abres orch claude en un proyecto y ese asiento es el Chair. Abres un segundo asiento interactivo en el mismo proyecto y orch lo rechaza:

project already has Chair session <id> (<name>) — one Chair per project; spawn workers with orch task run, or pass --force-chair

--force-chair existe para el caso que nombra el mensaje: de verdad quieres dos Chairs vivos. Los asientos fantasma que deja una terminal muerta se limpian solos, así que rara vez debería hacer falta.

El fan-out desde un worker se deniega en ambos transportes, con la misma cadena:

dispatch_worker denied: ORCH_ROLE=worker — only the Chair may spawn (use orch msg to the Chair)

Por qué existe#

Un worker que puede lanzar workers es una bomba de bifurcación con tarjeta de crédito. Más silencioso todavía: también es un hueco de responsabilidad, porque nadie queda sosteniendo el hilo que decide cuándo la tarea está lista. Un Chair por proyecto deja un solo lugar donde se reparte el trabajo, una sola bandeja para las preguntas y un solo veredicto al final.

Reportar no es fan-out, y la regla es explícita: un worker sí puede llamar a verify_report, porque decir lo que hiciste no es lo mismo que repartir más trabajo.

Cómo se relaciona con el resto#

  • Un worker que necesita una decisión levanta un ask bloqueante en vez de adivinar o de lanzar a alguien que decida por él.
  • Cada worker lanzado recibe por defecto un worktree git orch/<session>; orch worktree status, orch worktree promote <session> y orch worktree prune son su ciclo de vida. promote cierra en falso ante conflictos y nunca hace push.
  • Una tarea puede llevar context de fondo y una lista de acceptance_criteria; cada criterio se renderiza en el prompt del worker como una casilla sin marcar y tiene que volver por verify_report marcado como cumplido o no. Un worker que nunca reporta los deja a todos como incumplidos en el board, a propósito.
  • Cuando clarify_before_spawn está activo, lanzar queda supeditado a que orch ledger check pase, salvo que la llamada use force.

Aquí no hay nada que ejecutar#

Eliges un Chair abriendo un asiento, y lanzas un worker pidiéndoselo al Chair en el chat. orch dispatch --prompt "…" existe para scripts y CI, no para el uso diario.