Rutas y presupuestos

Objetivos

• Elegir entre las dos rutas de implementación.
• Recordar los presupuestos de evidencia y su carácter.
• Distinguir la ruta de la delegación por acción.
• Reconocer los flujos ligeros canónicos.

---

Dos rutas, una por cambio

Todo cambio autorizado toma exactamente una ruta de implementación:

Ruta	Se usa cuando	Qué ocurre
Direct inline	Tareas pequeñas, y tareas grandes sin motivo de Writer trigger	El parent lee, edita y ejecuta la prueba enfocada y la suite
Delegated direct	La comprensión excede el presupuesto inline, un writer tiene un motivo con nombre, o el cambio nombra un punto de alto riesgo	Se delega la exploración acotada, un writer por unidad o el verificador que corresponda

La forma por defecto para implementación autorizada, según el orquestador, es esta:

flowchart LR
    A["El parent aclara<br/>y revisa git"] --> B["El parent escribe inline<br/>siguiendo la bitácora"]
    B --> C["Prueba enfocada<br/>y suite inline"]
    C --> D["El parent informa"]

Con un motivo de writer, un worker acotado por unidad escribe en lugar del parent. Si hubo unidades en paralelo, agrega una comprobación de costura al final.

Lo que no decide la ruta

La lista de exclusiones se repite en varios archivos:

File count, changed lines, size, or perceived risk alone never forces a heavier route.

internal/components/agentguidance/routing.go

Ni el modelo que escribe ni la relación de precios entre modelos deciden tampoco la ruta.

---

Los presupuestos

Los valores son datos del proyecto, definidos en internal/agents/capabilitymanifest/manifest.go y proyectados al texto.

Presupuesto	Valor	Para qué
Tandas de evidencia inline	1	Decidir o verificar sin delegar
Llamadas por tanda	Hasta 3	Lectura paralela
Tokens de evidencia inline	~10k	Tope aproximado de esa tanda
Búsquedas secuenciales	~5	Más allá de esto se pide un mapa
Tamaño del traspaso del explorador	~2k tokens	Con evidencia path:line
Comprobaciones del parent sobre el mapa	1	No se relee toda la evidencia
Contexto del parent	~150k tokens	Backstop de sesión larga

flowchart TD
    A["Necesito evidencia"] --> B{"¿1 tanda, 3 llamadas, ~10k tokens?"}
    B -->|"Alcanza"| C["Decidir inline"]
    B -->|"No alcanza"| D["Mapping trigger"]
    D --> E["Explorador: ~2k tokens de mapa"]
    E --> F["1 comprobación del parent"]
    F --> G["Reevaluar el tamaño"]
    C --> H["Seguir"]
    G --> H
    H --> I{"¿Contexto cerca de ~150k?"}
    I -->|"Sí"| J["Delegar la siguiente unidad acotada"]
    I -->|"No"| H

Son límites de evidencia

La aclaración es importante: estos valores no son reglas por número de archivos.

• Se usa búsqueda acotada y rangos de líneas, sin leer archivos grandes completos.
• Un mismo cambio comprendido se queda inline aunque abarque varios archivos.
• La lectura que prepara una escritura delegada se delega con ella, y una escritura inline lee inline.

El backstop de contexto es orientativo

El número de 150k es una guía que nadie mide mecánicamente. El texto lo aclara dos veces: no está observado ni aplicado por el sistema, y el agente no debe afirmar telemetría o aplicación en tiempo de ejecución. Si el modelo estima que está cerca, se pausa y delega la siguiente unidad acotada.

---

Mantener delgado el contexto del parent

• Salida de bash acotada. La salida de comandos del parent se limita a conteos, --stat, tail o resúmenes.
• Suites largas. En una tarea grande, las suites y builds largos se delegan y devuelven resultados observados concisos, incluidas las fallas.
• Hilo delgado. El parent mantiene una conversación corta y sintetiza resultados.

La explicación se da en la propia guía: la delegación mantiene el contexto del parent lo bastante delgado para orquestar, sin ralentizar el trabajo.

---

Delegación por acción

Las rutas se refieren a quién implementa. Existe otra categoría que no cambia la ruta:

These are implementation routes, not a ban on per-action delegation. Tests, builds, installs, and review actors may still use fresh workers without changing the selected route.

internal/components/agentguidance/routing.go

Un trabajo sigue siendo direct inline aunque un worker fresco corra la suite completa.

---

Flujos ligeros canónicos

El orquestador incluye tres patrones que conviene tener presentes. Los traducimos manteniendo su secuencia:

flowchart TD
    subgraph A["Bug en un flujo desconocido"]
        A1["Parent: git status y aclarar"] --> A2["Explorador mapea flujo y archivos"]
        A2 --> A3["Parent arregla y prueba inline"]
        A3 --> A4["Verificación enfocada"]
        A4 --> A5["Parent informa"]
    end
    subgraph B["Conflictos o marcadores de dependencias"]
        B1["Parent reproduce o revisa el conflicto"] --> B2["Parent o writer resuelve dentro del alcance"]
        B2 --> B3["Verificar marcadores, lockfile y limpieza"]
        B3 --> B4["Parent informa"]
    end
    subgraph C["Tras un incidente de herramienta o worktree"]
        C1["Detener escrituras"] --> C2["Parent captura git status"]
        C2 --> C3["Diagnosticar sin editar"]
        C3 --> C4["Aplicar solo recuperación confirmada"]
    end

El tercero es el más distinto: ante un incidente, lo primero es dejar de escribir.

---

Evitar lanzamientos duplicados

Los orquestadores incluyen una regla obligatoria de deduplicación. Se lleva un registro por sesión de pares (phase, task-fingerprint), y si el mismo par ya se lanzó en el turno, no se lanza otra vez. La razón declarada es evitar conflictos del tipo “este archivo cambió desde la última lectura” y el gasto de tokens.

---

Cuando el runtime no puede delegar

No todos los runtimes tienen subagentes. Un disparador activado sigue siendo obligatorio, pero si falta el mecanismo se sigue la degradación documentada del runtime, o se detiene el trabajo explicando el bloqueo, en lugar de seguir inline en silencio. El capítulo 13 cubre la forma reducida de verificación y el capítulo 18 las diferencias por runtime.

---

Actividad

Durante una sesión con tu agente, registra cuántas lecturas hace antes de decidir el primer cambio. ¿Cabrían en una tanda de 3 llamadas? ¿Hubo una lectura repetida porque un subagente ya la había hecho? Anota una regla concreta que evitaría esa duplicación.

---

Autoevaluación

1. ¿Cómo se trata un cambio comprendido que abarca muchos archivos?

   • A. Se delega por superar cuatro archivos
   • B. Se queda inline
   • C. Se divide en un worker por archivo
   • D. Requiere un documento de feature

2. ¿Qué afirma el texto sobre los ~150k tokens?

   • A. El runtime los mide y detiene la sesión
   • B. Activan una revisión RDD
   • C. Obligan a compactar el contexto
   • D. Son orientación que no se observa ni se aplica mecánicamente

3. Un worker fresco corre la suite larga de una tarea inline. ¿Cambia la ruta?

   • A. Sí, pasa a delegated direct
   • B. Sí, y se debe crear un documento
   • C. No: es delegación por acción
   • D. Solo si la suite falla

4. ¿Qué es lo primero tras un incidente con el worktree?

   • A. Detener las escrituras
   • B. Reiniciar la rama desde main
   • C. Reinstalar las herramientas
   • D. Pedir un mapa a un explorador

Respuestas

1. B. El número de archivos nunca decide la ruta.
2. D. Es la aclaración literal.
3. C. Pruebas, builds e instalaciones pueden usar workers sin cambiar la ruta.
4. A. Es la primera acción del flujo canónico.

Lista de control

• Sé qué ruta corresponde sin mirar el número de archivos.
• Recuerdo los presupuestos y que son aproximados.
• No releo lo que un explorador ya mapeó.
• Sé qué hacer tras un incidente de herramienta.

Fuentes

internal/components/agentguidance/routing.go, internal/agents/capabilitymanifest/manifest.go, internal/assets/skills/_shared/odd-orchestrator-sections.md, internal/assets/generic/orchestrator.md, docs/trigger-rules.md.