egutierrez
fac2cceea3
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>
fn-registry — Schema de documentación
Registry personal de código con búsqueda FTS. Diseñado para composición funcional y agentes.
Archivos
functions.md— Schema de la tabla functions (incluye pipelines y componentes React)types.md— Schema de la tabla typesintegrity.md— Reglas de integridad y referencias cruzadasarchitecture.md— Visión general del sistemasync_setup.md— Vincular una PC al serverregistry.organic-machine.com(env vars,fn sync, troubleshooting)adr/— Architecture Decision Records: decisiones de diseño (qué se decidió y por qué)../reports/— Reportes de trabajo: artefacto local (entregable de una tarea: qué se hizo, cómo se verificó, gaps). Gitignored salvo.gitkeep, NO sube a Gitea ni se versiona (como los vaults). Convención en.claude/rules/reports.md. Decisión: ADR 0006
Tablas
| Tabla | Descripción |
|---|---|
functions |
Funciones atómicas, pipelines y componentes React |
types |
Tipos algebraicos (product / sum) |
kind: valores posibles
| Valor | Descripción |
|---|---|
function |
Función atómica pura o impura |
pipeline |
Composición de funciones, siempre impura |
component |
Componente React, extiende el schema base |
fn-registry schema v1.0