Hermes Conductor

Donde otros puentes entre agentes dan por bueno el «tests pasan» que escribe el propio CLI, aquí el controlador vuelve a ejecutar las puertas de verificación, inspecciona el diff del worktree y solo entonces cierra la tarjeta con IDs de commit y salida de comandos. El orquestador no implementa: enruta, descompone, comprueba e integra.

Los patrones salen de 18 tableros de producción, 367 tarjetas y 566 despachos, y de cada incidente que casi los tira abajo: colisiones al mutar el mismo checkout, auto-promoción de lanes con HEAD obsoleto, bucles de aprobación que devoran tokens y cierres sin evidencia. Claude Code, OpenCode, Codex CLI, MiMo u otro ejecutor que edite ficheros trabaja en su propio worktree; el kanban de Hermes Agent sigue siendo el único dueño de la tarjeta.

Reglas que el propio fallo impuso

• Un worktree por lane que mute el código; nunca el checkout canónico.
• Los autoinformes del agente no cuentan como evidencia de cierre.
• --parent es una arista de dependencia: el hijo sigue bloqueado hasta que el padre complete con pruebas.
• Cadenas dependientes en cola ordenada; fan-out solo si el plan demuestra independencia.

En producción el ejecutor de lane puede ser un CLI crudo (claude -p) o un runner sobre el SDK de Claude Agent: tope de presupuesto, máximo de turnos, timeout, herramientas explícitas y un recibo JSON que el controlador adjunta a la tarjeta. Completar sin evidencia se revierte.