El doc hablaba de "tope de fan-out para no explotar la flota" sin numero. Se
fija un maximo DURO: 6 ejecutores role=executor activos simultaneos por
orquestador. Al alcanzarlo, el orquestador no lanza mas: encola las sub-tareas
restantes hasta que un slot se libere (ejecutor verificado met + kill_fleet_agent).
Justificacion: ya hubo el caso de 30 agentes que no cerraban nada y, al competir
todos por el mismo rate-limit compartido, hubo que desactivar goal_refine. Mas
ejecutores no es mas throughput; el cuello de botella es el rate-limit compartido
y los DoD que nadie cierra.
Escrito en el splitter + regla dura de orchestration.md (detalle + justificacion)
y en las reglas duras del command (numero + encolado, puntero al detalle).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El command /orquestador (555 lineas) se cargaba entero en contexto cada turno y
predicaba "responde conciso" siendo el mismo prolijo. Se parte en dos:
- Nueva regla .claude/rules/orchestration.md con la maquinaria estable: seguir
la flota (fleetview, tiempo de actividad), cola del watcher (events.jsonl,
push activo, FLEET-STATE), clasificacion (classify_fleet_termination),
politicas por clasificacion, verificador adversarial, auto-kill
(kill_fleet_agent), nudge, splitter, cadencia y el catalogo de funciones del
grupo orchestration. Todo el contenido sustantivo se mueve integro.
- El command queda con la doctrina y el flujo: arranque (marcar role +
confirmacion), diferencia con fn-orquestador/autopilot, ciclo de 8 pasos
(resumido donde la maquinaria se fue a la regla, con punteros), reglas duras,
anti-patrones, ejemplo end-to-end y salida del modo. Baja de 555 a 299 lineas.
Redundancias colapsadas a una canonica + punteros: "NUNCA Agent tool para
lanzar trabajo" vive en el paso 8; "nunca pkill/killall claude" en el paso 6.
El resto referencia esos pasos.
Fila 38 anadida a .claude/rules/INDEX.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Integra las 4 mejoras de la tanda: (1) --parent en los ejemplos de spawn y la
explicacion del routing del watcher por parent_orchestrator; (2) regla de
auto-kill — cerrar cada ejecutor con kill_fleet_agent tras verificar met, con sus
guards; (3) push activo del watcher (tmux send-keys al pane del orquestador padre)
+ indicador 'idle nuevo sin ver' de la TUI fleetview (los implementa otro agente,
aqui solo se describen); (4) el dod movil del statusline ya no se regenera con LLM
por turno (objetivo/DoD fijo, ajustable con dod:). Anade mark_claude_parent y
kill_fleet_agent a la tabla del grupo orchestration.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El orquestador reporta el tiempo de actividad (cuanto lleva sin avanzar)
via fleetview list AGE/idle_seconds, no el etime (vida del proceso = 8h de
sesion), que no es progreso.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El orquestador responde conciso (velocidad de iteracion sobre detalle) y
va pinneado arriba en el sidebar de fleetview via role=orchestrator. Se
corrige una regla previa que afirmaba erroneamente un comportamiento de
no-conmutacion del pane (no era lo pedido).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- spawn_fleet_agent (bash/functions/infra): lanza un Claude como window de
la sesion tmux de un perfil fleet (no kitty suelta), con --skill para
arrancar en un modo (ej. /orquestador), --prompt-file para ejecutores
autocontenidos, y --role para marcar el goal.json via mark_claude_role.
Asi ejecutores y orquestador viven en la flota, visibles en fleetview y
conmutables con /fleet focus.
- skill /orquestador: paso 2 ahora prefiere spawn_fleet_agent sobre kitty
cuando se opera dentro de un perfil fleet ($FLEET_SOCKET seteado); tabla
de funciones del grupo actualizada.
Validado en vivo: el orquestador arranca en la flota fleet2 en modo
(MODO ORQUESTADOR activo), role=orchestrator marcado, pinneado arriba en
la TUI; los 9 ejecutores existentes intactos.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- mark_claude_role (python/functions/infra): resuelve PID->sessionId
esperando sessions/<PID>.json y escribe role en el goal.json sin pisar
el resto. 4 tests.
- launch_fleetclaude: el pane derecho arranca el ORQUESTADOR con el skill
/orquestador embebido como primer prompt; tras arrancar, mark_claude_role
le pone role=orchestrator (en background, no-fatal) para que la TUI lo
pinee arriba; ademas siembra 1 ejecutor idle inicial en su propia window.
- skill /orquestador: regla 'no te vigiles a ti mismo' (ignora en la cola
su propia sesion y cualquier role=orchestrator).
Validado en vivo (perfil aislado): claude /orquestador entra en modo,
role marcado, idle sembrado, pin correcto, fleet2 intacto.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Primitivas (python/functions/infra):
- drain_fleet_events: consume la cola del watcher (~/.claude/fleet/
events.jsonl) desde un cursor, agrupa por clasificacion, marca
urgentes. 7 tests.
- set_dod_contract: escribe el DoD-contrato fijo (dod_contract/dod_status)
en el goal.json de un agente sin pisar el resto (escritura atomica).
5 tests.
Skill /orquestador evolucionado (sin romper lo existente): vigila la
flota por su DoD (no por 'esta vivo'). Nueva seccion 'Consumo de la cola
de la flota': DoD-contrato obligatorio al lanzar, drenar la cola,
politicas por clasificacion (RECLAMA escala / DICE_TERMINADO verifica /
ESTANCADO nudge / MAL_LANZADO re-DoD), verificador independiente del
ejecutor (lee el report vs dod_contract), splitter con tope de fan-out,
y cadencia (drain al actuar + heartbeat).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Nuevo slash command que codifica el modo orquestador: el Claude principal
descompone una tarea grande y lanza Claudes secundarios interactivos, cada uno
en su propia terminal kitty con un prompt autonomo inyectado y aislamiento git
impuesto (worktree / sub-repo / scope disjunto). El humano habla solo con el
orquestador, ve a los secundarios en sus terminales y puede saltar a cualquiera.
El cuerpo cubre los 8 pasos del ciclo (descomponer, lanzar, aislar, prompt,
seguir, no pkill, integrar, kitty vs Agent tool), la plantilla del comando de
lanzamiento, la tabla de seguimiento de la flota, las reglas de aislamiento, los
anti-patrones y un ejemplo end-to-end. Referencia las funciones del registry
launch_claude_agent_kitty_bash_infra, list_claude_agents_bash_infra y
reboot_all_claudes_bash_infra (grupo orchestration). Deja explicita la diferencia
con fn-orquestador / autopilot (Agent tool en sandbox no-interactivo).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
egutierrez
Egutierrez