Orquestación de larga duración
Un coordinador es un punto de decisión en serie: cada lectura que hace y cada decisión que se canaliza a través de él espera en una cola sin reloj, y cuando se satura el trabajo se detiene en silencio. Esta habilidad evita que cualquier cosa llegue a esa cola.
El nivel superior de un drive consta de dos sesiones. El comunicador es la sesión en la que escribe el propietario; su único trabajo es él. El coordinador es una sesión Orca hermana vinculada como carril root: genera un carril para cada solicitud con un cuerpo en el turno en que llega, decide lo que un proceso ha escalado y retransmite lo que producen los puestos. Junto a ellos se encuentran el metacarril, que toma cada cambio de habilidad, herramienta y proceso y convierte cada fallo en una actualización de la habilidad, y el carril de señal, que sigue al coordinador para que el comunicador nunca tenga que hacerlo. Todo lo demás es un verbo de la herramienta de drive lr o un proceso que se ejecuta sin ninguno de ellos. Una regla aquí nombra el verbo o proceso que hace que un fallo sea imposible; una regla sin ninguno de ellos es un defecto que corregir en el paquete.
Esta habilidad reside en ~/.claude/CLAUDE.md, que controla la forma de fan-out, el enrutamiento de modelos y la profundidad de verificación. El paquete es un binario Go, lr, con los scripts de Python que reemplaza conservados solo hasta que cada verbo se active (diseño).
Tres o más carriles a la vez, una tarea que supera una ventana de contexto, una espera en CI, una cola, una aplicación o una prueba de inmersión, o un barrido sobre muchas unidades independientes es un drive. Una investigación de un solo carril es un subagente en modo directo, no un drive.
Contenido
- Lee el archivo para tu trabajo
- Juicio primero
- Ganchos y rechazos
- Los cambios meta aterrizan en la habilidad
- Antes de cada llamada a herramienta
- Pregunta al verbo, nunca leas
- Las reglas
- Fase 0: las sesiones permanentes
- Lo que se ejecuta sin el coordinador
- Carriles y puestos
- Las superficies del propietario
- Registros y la lista de tareas
- Inicio y reanudación
- Añadir una regla a esta habilidad
Lee el archivo para tu trabajo
Lee solo la fila que estás haciendo. Cada archivo expone sus reglas en su totalidad.
| Tú eres | Lee |
|---|---|
| Respondiendo al propietario: respuestas, elecciones, rediseños, su Slack y tablero | communicator-brief.md |
| Renderizando la actualización del propietario o manteniendo el dashboard | owner-report-table.md, drive-dashboard.md |
| El coordinador | coordinator-brief.md |
| El metacarril o su implementador | meta-lane-brief.md |
| El carril de señal; el carril de tareas | signal-lane-brief.md; chores-lane-brief.md |
| Escribiendo un resumen de carril, o trabajando como carril o puesto bajo uno | orca-lane-brief.md |
| Rotando el contexto de un carril; una transferencia o una compactación | handoff-subagent-brief.md, compaction.md |
| Lanzando o retransmitiendo trabajadores Orca, en Mac o en Sprite | orca-desk-brief.md, orca-workers.md, orca-sprite-workers.md |
| Aterrizando un PR, la cola de fusión, D1 a D23 | landing.md, merge-train-brief.md |
| Calificando una cabeza, un aterrizaje o un plan | grading-principles.md, finder-brief.md, finder-desk-brief.md, finder-desk-rows.md, fidelity-desk-brief.md, fidelity-job-brief.md, semantic-collisions-brief.md |
| Siendo dueño de un rojo sin propietario | red-sweep-brief.md |
| Una alerta o incidente | active-alert-brief.md, alert-fix-brief.md, alerts-desk-brief.md, alert-evidence-brief.md, alert-comms-brief.md, unfixed-case-brief.md |
| Una versión | release-lanes.md, manual-release-brief.md |
| Publicando en Slack | slack-lane-brief.md, comms-desk-brief.md |
| Publicando o leyendo registros cci, el bus de carril, reglas B | bus-contracts.md |
| Registrando o aplicando un fallo del propietario, el registro, los jueces | owner-rulings.md |
| Actividad del carril: por qué un carril no puede silenciarse, el supervisor y los vigilantes | supervisor.md, watchers.md, drive-watchdog-brief.md |
| El único resultado número uno; enfrentando al propietario contra una superficie | priority-desk-brief.md; user-test-brief.md |
| Iniciando un sub-drive | sub-drives.md |
| Leyendo un corpus grande en carriles de corrección | the bulk-read skill |
| Preguntando por qué existe una regla; ningún carril necesita esto para hacer su trabajo | lessons.md |
Juicio primero
- Ninguna regla prohíbe leer la línea única de la que depende una decisión.
- Un hallazgo en mano es una corrección, nunca un carril, una re-auditoría o un flujo de trabajo.
- Lee cada frase del propietario como lo haría un colega cuidadoso. Una corrección nombra un defecto en la lectura, nunca un rediseño de algo que él falló antes; lee las filas del registro sobre ese tema antes de actuar. Una repetición es un informe de defecto sobre la primera lectura: corrige cada lugar donde sobrevivió, en ese turno.
Ganchos y rechazos
- Los ganchos advierten. Bloquean solo por confianza: una fusión sin la aprobación del propietario, un cambio en quién aprueba aterrizajes, una reversión sin su palabra, un runner o puesto iniciado desde el comunicador, un carril conduciendo su navegador con sesión iniciada en producción, ediciones a los archivos de gancho instalados y a las protecciones de sesión. Una lectura fallida solo advierte;
tests/test_fail_open.pylo exige y enumera las excepciones, y el gancho de permiso de Slack falla abierto (slack-lane-brief.md). - Un gancho que falla en tu trabajo recibe un carril de corrección en el turno en que te bloquea, y sigues trabajando en lo que no bloquea. Un rechazo que es correcto, como el guardia de identidad de producción, no recibe ninguno. La sesión bloqueada lo lanza, ya sea carril, puesto, coordinador o comunicador, sin preguntar a
rooty sin metacarril:lr launch lane hook-fix-<hook> opus high <brief> --drive <drive> --lane <tú>, a menos quelr lanes hook-fix-<hook>muestre uno activo. - Los ganchos viven en
plugins/long-running/capt-hook/hooks/en yasyf/cc-skills y encaptain_hook/builtin_packs/en yasyf/captain-hook, y cada cambio siguecaptain-hook:authoring-hooks, cuyos lint y test se ejecutan en el CI de ese repositorio. El carril de corrección corrige el defecto real del gancho con una prueba de regresión, lo envía, lo instala donde se ejecuta la sesión bloqueada, y su prueba es que la llamada rechazada pase (orca-lane-brief.md). - Corregir no es rodear: mientras un rechazo esté vigente, nadie ejecuta lo bloqueado a través de un wrapper,
cc-sudoo un script. Las reglas de seguridad del propietario se mantienen como están escritas: fusión, Slack, pruebas de carga y el guardia de proceso. Un gancho que protege uno de ellos y falla recibe la corrección de su fallo con una prueba de regresión, y la regla misma solo cambia con su palabra. El único gancho deshabilitado antes de su corrección es aquel que bloquea cada paso del comunicador: coméntalo en el código fuente del paquete con un TODO que nombre su carril de corrección, en un PR fusionado de inmediato, ya que una edición en la caché instalada solo dura hasta la próxima instalación, que este Mac ejecuta en minutos. - Un gancho que no bloquea nada y podría mejorarse va al metacarril como un
cci post --kind note --to meta-desk. Cualquier otro rechazo de herramienta va al metacarril en el mismo turno y el trabajo procede en su ruta manual. Ningún rechazo es una excusa o una pregunta para el propietario, y tampoco lo es la plataforma: un registro que culpa a un Sprite, un host o una herramienta compartida por una espera o un fallo nombra el carril que corrige su causa raíz y el reloj de esa corrección, y sin tal carril pregunta al coordinador por uno en ese turno. Reemplazar una máquina es un parche temporal y nunca la respuesta.
Los cambios meta aterrizan en la habilidad
El carril que recibe un cambio meta globalmente aplicable, cualquier fallo sobre cómo funcionan los carriles, tarjetas, esperas, respuestas, ganchos, enrutamiento o respuestas, lo envía al metacarril en el turno en que llega, como un registro cci. El metacarril siempre lo convierte en una actualización de esta habilidad, o del documento de resumen, gancho o notas cc que lo posee, fusionado e instalado, reescribiendo y refactorizando la sección que toca para que la habilidad se lea como un solo diseño, nunca una línea añadida desnuda. Un archivo de memoria o un registro es un puntero y nunca cuenta como hecho.
Antes de cada llamada a herramienta
| Si la llamada es | Haz |
|---|---|
| Algo que un verbo responde | Ejecuta el verbo. |
| Trabajo con un cuerpo | Genera el carril con su tarea y fila de libro mayor. |
| Una espera | Dóblala en el carril que actúa. |
| Estado | El comunicador envía el render del puesto de actualización; el coordinador no envía nada. |
| Un mensaje del propietario | El comunicador genera un subagente para él, que responde en la superficie de la que vino; el coordinador aplica el fallo en todas partes; un fallo sobre cómo funciona el drive va al metacarril en ese turno, que lo convierte en una actualización de habilidad. |
| Una alerta que el supervisor no ha respondido | lr incident run <slug> ahora. |
| Un rechazo de herramienta, o algo que salió mal dos veces | Un gancho bloqueando tu trabajo recibe el carril de corrección que lanzas este turno (Ganchos y rechazos); cualquier otra cosa va al metacarril este turno, donde la corrección es un verbo Go. Procede de cualquier manera. |
| Una aprobación, retención, inicio o cancelación | La orden del propietario lo lleva o un carril lo posee. |
Agentes terminados detenidos, operaciones de producción registradas, nada llamado hecho que no esté vivo y verificado. Una llamada que sobrevive a la lista decide algo que ningún verbo y ningún carril puede decidir. Todo lo demás es un carril.
Pregunta al verbo, nunca leas
| Para saber | Ejecuta |
|---|---|
| Si un carril está vivo, y qué dijo por última vez | lr lanes <carril> --config <lr.json> |
| Cada carril, su estado, PRs y deber permanente | lr lanes |
| Qué pasó desde la última vez que miró | cci digest --drive <drive>, luego cci tail --drive <drive> --cursor root |
| Qué espera al propietario | cci owner-waits --drive <drive> |
| Qué sub-drives están abiertos y qué retiene cada uno | lr drive sub list |
| El estado de los PRs que debe nombrar | ccx vcs pr status <n1> <n2> ..., en lote |
| Qué PRs aprobó el propietario en el tablero, y cuáles de ellos siguen abiertos | lr approved [--since <seq>], veredictos retroactivos excluidos |
| Cada solicitud abierta, y qué está aterrizado pero no vivo | lr asks |
| La actualización del propietario, completa y desde fuentes | lr update render, ejecutado por el update-desk del comunicador |
| Qué está haciendo un incidente; una frase sobre qué es | lr incident status <slug>; lr incident describe <slug> |
A dónde va el correo de un carril; cada verbo lr toma un tallo, meta-desk, para su carril vivo más reciente | lr route <carril> |
Una lectura que la tabla no contiene pertenece a un carril: un PR, un log de CI, un hilo de Slack, un archivo largo, un listado de la nube, una página de build. Un diff, plan o veredicto que estás aprobando es tuyo para leer. El coordinador genera un lector y recibe como máximo cinco líneas; una búsqueda es una llamada, lr ask-lane '<pregunta>'. Los ganchos root_context y root_reads advierten en cada lectura de esos tipos, en una segunda fuente abierta para una solicitud del propietario, y en los registros de un carril canalizados a través de tail o grep; en la ventana del comunicador root_context rechaza una búsqueda amplia y nombra lr ask-lane.
Las reglas
Los ids son estables; scripts, ganchos y referencias los citan. root significa el coordinador a menos que la regla nombre al comunicador.
R1. La verdad fundamental proviene del carril propietario o del verbo, nunca de un grep, un listado, un curl o una página de build; como máximo cinco líneas de vuelta. El estado de los PRs prioritarios se lee en una llamada ccx vcs pr status en lote.
R2. Cualquier cosa con un cuerpo es un carril: una lectura más allá de una ventana acotada, un log, una investigación, mecánica de PR o fusión, una enumeración. Se permite una lectura acotada de un archivo nombrado, de hasta 150 líneas.
R3. Un carril por cadena de espera-y-luego-acción, y ningún carril estaciona: un carril espera en un Monitor, una notificación de Agente, CronCreate para un reloj, o una llamada lr wait, a un estado terminal, e informa una vez. shell_waits bloquea un bucle o durmiente de shell. El Monitor de un puesto se rearma al expirar.
R4. Nunca vuelvas a informar a un carril, nunca respondas a un duplicado. Un SendMessage a un agente terminado re-ejecuta su resumen. lr wait marca el correo impreso como leído.
R5. Escríbelo, no lo retengas: hallazgos a cc-notes desde el carril que los encontró, resúmenes como adjuntos en el log briefs: <slug>, nada hecho a mano bajo ~/.claude/scratch.
R6. Cada solicitud del propietario está en vuelo en el turno en que llega, un carril por solicitud, nunca añadida a la cola de un carril ocupado. Un carril posee un PR por entregable y aterriza sus correcciones como commits en él; orca-lane-brief.md dice cuándo apila.
R7. El estado de un PR se lee antes de que se informe: ccx vcs status o el commit squash en la rama principal obtenida, nunca un mensaje o memoria.
R8. Cada solicitud del propietario es una fila del libro mayor en el turno en que llega, y está hecha solo en LIVE; antes de eso la respuesta es "en #N, aún no vivo: ".
…
[truncado para traducción]