Siempre Listo Escuela
← Volver al listado de tecnologías ← Índice de Organic Driven Development (ODD)

El protocolo en siete pasos

Por: Artiko
oddprotocoloflujofundamentos

El protocolo en siete pasos

Objetivos

  • Memorizar los siete pasos y su orden.
  • Reconocer los tres recorridos que produce el protocolo.
  • Saber dónde se decide cada cosa, para ubicar el detalle en los capítulos siguientes.

Los siete pasos

El texto que se instala se titula ODD protocol (MANDATORY, in this order, on every request): obligatorio, en este orden y en cada pedido.

#PasoPregunta que respondeCapítulo
1Authorize¿Este pedido autoriza un cambio?04
2Explore¿Qué existe ya?05
3Resolve uncertainty¿Queda alguna duda que importe?05
4Classify¿Es pequeña o grande?06
5Track before the first write¿Necesita documento de feature?07
6Implement task by task¿Quién escribe y cómo se prueba?08 y módulo 3
7Close¿Qué se comprobó y qué sigue?09

El protocolo entra en juego también cuando solo haces una pregunta. Lo que cambia es el recorrido: el primer paso desvía el pedido hacia la lectura.

El flujo completo

Este diagrama resume el de docs/usage.md, sin el detalle de la revisión nativa, que se trata en el capítulo 16.

flowchart TD
    A["Pedido"] --> B{"¿Autoriza un cambio?"}
    B -->|"No"| C["Explorar o explicar<br/>sin artefactos"]
    B -->|"Ambiguo"| B2["Una aclaración<br/>y esperar"]
    B2 --> B
    B -->|"Sí"| D["Explorar el código existente"]
    D --> E["Resolver incertidumbre<br/>solo si hay una real"]
    E --> F{"¿Se puede retomar desde<br/>el pedido y git diff?"}
    F -->|"Sí"| G["Sin artefactos duraderos"]
    F -->|"No"| H["Documento de feature<br/>y espejo en Engram"]
    G --> I["Implementar con test-first aplicable"]
    H --> I
    I --> J["Comprobaciones proporcionales"]
    J --> K{"¿Quedan tareas?"}
    K -->|"Sí"| I
    K -->|"No"| L["Cerrar: resultado, comprobaciones<br/>y línea Risk"]

Qué ocurre en cada paso

1. Authorize

Investigar, explicar, revisar, auditar, comparar o proponer es solo lectura, a menos que pidas implementar. Si la intención de cambio es ambigua o condicional, hay una aclaración y el agente sigue en solo lectura hasta recibir respuesta.

2. Explore

Se explora el código y los requisitos antes de proponer o escribir, en proporción al pedido. Si el agente va a escribir inline, lee lo necesario él mismo. La exploración separada se usa solo cuando necesita un mapa para decidir o enrutar.

3. Resolve uncertainty

Son tres herramientas opcionales con un uso limitado:

  • Investigación solo para una incertidumbre con nombre.
  • Una pregunta enfocada solo para una decisión de producto real, y luego se espera.
  • Como máximo un desafío de supuestos de solo lectura para una premisa no demostrada de alta consecuencia.

4. Classify

Una tarea es pequeña si cumple tres condiciones: se comprende, su riesgo está contenido y se puede retomar desde el pedido original y git diff. Es grande solo cuando falla esa prueba de reanudación.

5. Track before the first write

Para tareas grandes, el agente crea odd/tasks/<feature-name>.md y su espejo en Engram antes de escribir código, sin pedir permiso, y te avisa en una línea qué documento creó y cuántas tareas contiene.

6. Implement task by task

Es el paso más denso. Incluye:

  • Traspaso por referencia a los workers.
  • Enrutamiento por la topología útil más pequeña.
  • Política test-first por defecto.
  • Marcar cada elemento solo con el resultado observado.
  • Actualizar el documento y su espejo después de cada tarea.
  • Commits por unidad de trabajo en porciones de unas 400 líneas en la rama de la feature.

7. Close

Se informa el resultado verificado, cada comprobación fallida, omitida o pendiente, y el siguiente paso. Todo cambio de código cierra con su línea Risk. Una tarea registrada solo puede quedar pendiente con tu orden explícita de parar o con un único resultado Needs your decision.

Los tres recorridos

flowchart LR
    subgraph L["Solo lectura"]
        L1["Authorize"] --> L2["Explore"] --> L3["Responder"]
    end
    subgraph P["Tarea pequeña"]
        P1["Authorize"] --> P2["Explore"] --> P3["Classify"] --> P4["RED y arreglo inline"] --> P5["Prueba y suite una vez"] --> P6["Close con Risk"]
    end
    subgraph G["Tarea grande"]
        G1["Authorize"] --> G2["Explore"] --> G3["Classify"] --> G4["Documento y espejo"] --> G5["Tarea por tarea<br/>con commits"] --> G6["Close"]
    end
AspectoSolo lecturaPequeñaGrande
Escribe archivosNoSíSí
Documento de featureNoNoSí
Espejo en EngramNoNoSí
Commits automáticosNoNo, salvo que los pidasSí, en la rama de la feature
SubagentesSolo si hace falta un mapaNingunoSolo por motivo con nombre
Línea RiskNo aplicaSíSí

Grande no implica delegado. Una tarea grande sin motivo para delegar sigue inline siguiendo su bitácora. Esto se detalla en el capítulo 10.

Reanudar es un recorrido más

El flujo tiene una entrada lateral para una feature interrumpida:

sequenceDiagram
    participant P as Parent
    participant E as Engram
    participant D as odd/tasks/feature.md
    P->>E: mem_context
    P->>E: mem_search por proyecto y feature
    P->>E: mem_get_observation del documento completo
    P->>D: Leer el archivo real
    P->>P: Conciliar requisitos, código y pruebas
    P->>P: Continuar con la siguiente tarea sin terminar

El capítulo 17 cubre este mecanismo.

Lo que el usuario ve

Pese a toda esta maquinaria, la interacción normal solo reporta cuatro estados:

EstadoSignificado
WorkingLa implementación aún puede cambiar
CheckingSe hacen la prueba funcional aplicable y la revisión acotada
ReadyEl candidato exacto tiene evidencia suficiente para la ruta de entrega elegida
Needs your decisionNo es posible converger de forma segura y automática, y se presentan causa, impacto y opciones

docs/trigger-rules.md lo plantea así: tú pides el resultado y no eliges los detalles internos de revisión, los hashes, los recibos ni las transiciones.

Actividad

Toma los tres pedidos del capítulo 1 y escribe, para cada uno, qué recorrido seguiría y por qué. Marca con un signo de pregunta los que no puedas clasificar todavía. Revísalos al terminar el capítulo 6.

Autoevaluación

  1. ¿En qué momento se crea el documento de feature?

    • A. Al cerrar la tarea
    • B. Tras el primer commit
    • C. Cuando el usuario lo pide
    • D. Después de explorar y antes de la primera escritura de código

  2. ¿Qué paso decide si un pedido es de solo lectura?

    • A. Authorize
    • B. Classify
    • C. Explore
    • D. Close

  3. Una tarea grande sin motivo para delegar, ¿cómo se ejecuta?

    • A. Con un worker por cada tarea
    • B. Inline, siguiendo su bitácora
    • C. Se rechaza hasta que el usuario divida el pedido
    • D. Con un verificador independiente en cada commit

  4. ¿Qué estado corresponde a “no se puede converger de forma segura y automática”?

    • A. Working
    • B. Checking
    • C. Needs your decision
    • D. Ready
Respuestas
  1. D. El paso 5 se titula “Track before the first write” y va después de explorar.
  2. A. Authorize establece si el pedido autoriza un cambio.
  3. B. Grande recibe seguimiento, y un writer solo llega con su propio disparador.
  4. C. Presenta la causa, el impacto y opciones concretas.

Lista de control

  • Puedo recitar los siete pasos en orden.
  • Sé diferenciar los tres recorridos y qué produce cada uno.
  • Entiendo que “grande” y “delegado” son decisiones independientes.
  • Conozco los cuatro estados públicos.

Fuentes

docs/usage.md, docs/trigger-rules.md, internal/components/agentguidance/routing.go.

← Volver al listado de tecnologías ← Índice de Organic Driven Development (ODD)