docs(orquestador): tope de fan-out duro = 6 ejecutores por orquestador

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>

.claude/commands/orquestador.md

@@ -214,16 +214,17 @@ duda, terminal del fleet.
   frena cuando gestionas muchos proyectos a la vez. Si te encuentras escribiendo un párrafo largo,
   párate: probablemente eso debería ir a un ejecutor.
 - **El orquestador no hace el trabajo pesado.** Descompone, lanza, sigue, integra. Si te encuentras
-  escribiendo tú la feature, párate: ¿no debería ser un secundario?
-- **El orquestador va pinneado arriba en el sidebar** gracias a `role=orchestrator` (★), separado de
-  los ejecutores.
+  escribiendo tú la feature, párate: ¿no debería ser un secundario? (Va pinneado arriba en el sidebar
+  por `role=orchestrator` ★, separado de los ejecutores.)
 - **Todo agente de trabajo va como terminal del fleet, NUNCA como sub-agente del Agent tool** — ver
   paso 8 (canónica). El Agent tool queda solo para utilidades internas read-only tuyas.
 - **Cada secundario, su aislamiento.** Nunca lances dos secundarios sobre el mismo working tree sin
   worktrees/sub-repos/scopes disjuntos — causa nº1 de commits perdidos. Su prompt lleva SIEMPRE las
   reglas de aislamiento (dir, qué NO tocar, rama, cómo commitear). Nunca `git add -A` salvo dir
   exclusivamente suyo (worktree/sub-repo).
-- **Tope de fan-out** — ver `.claude/rules/orchestration.md`.
+- **Tope de fan-out: máximo 6 ejecutores `role=executor` activos a la vez** por orquestador. Al
+  alcanzarlo, encola el resto hasta que un slot se libere (ejecutor `met` + `kill_fleet_agent`).
+  Detalle y justificación en `.claude/rules/orchestration.md`.
 - **Nunca `pkill`/`killall claude`** — ver paso 6 (canónica). Kill dirigido (`kill_fleet_agent`), por
   PID exacto, o `reboot_all_claudes --exclude-current`.
 - **El humano habla contigo.** Tú resumes la flota; no le hagas perseguir 5 terminales.
@@ -265,8 +266,7 @@ git -C ~/fn_registry worktree add /tmp/orq_capdoc -b orq/cap-deploy master
 ./fn run launch_claude_agent_kitty "kanban · health endpoint" ~/fn_registry/apps/kanban /tmp/orq_health.md
 ./fn run launch_claude_agent_kitty "fn_registry · doc deploy" /tmp/orq_capdoc /tmp/orq_capdoc.md
 
-# 5. Seguir la flota cada turno: drena el FLEET-STATE, verifica los DICE_TERMINADO, nudge a los
-#    ESTANCADO (maquinaria en .claude/rules/orchestration.md). Lee sus reports/ al terminar.
+# 5. Seguir cada turno: drena FLEET-STATE, verifica DICE_TERMINADO, nudge a ESTANCADO, lee reports/ (maquinaria en orchestration.md).
 
 # 7. Integrar (desde el working tree principal):
 git -C ~/fn_registry/apps/kanban merge --no-ff issue/health     # sub-repo de la app

.claude/rules/orchestration.md

@@ -242,7 +242,16 @@ secuenciales encadenadas), **siempre dentro del tope de fan-out** (ver "Tope de
 
 ### Tope de fan-out (regla dura)
 
-Para no explotar la flota.
+**Máximo 6 ejecutores `role=executor` activos simultáneos por orquestador.** Si se alcanza el tope,
+el orquestador NO lanza más: **encola** las sub-tareas restantes y las despacha a medida que un slot
+se libera — un slot se libera cuando un ejecutor se verifica `met` y se cierra con `kill_fleet_agent`
+(auto-kill). El conteo es de la **familia propia** (ejecutores con tu `parent_orchestrator`), no de
+toda la flota; resuélvelo con el routing por `parent_orchestrator`, igual que el push activo.
+
+Por qué un número duro y no "los que hagan falta": 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`
+(el hook que reescribía el `dod` con un LLM por prompt). Más ejecutores no es más throughput: el
+cuello de botella es el rate-limit compartido y los DoD que nadie cierra, no el número de procesos.
 
 ### Cadencia