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

Paso 4: Tamaño de tarea y riesgo

5 de noviembre de 2026 Por: Artiko

oddprotocolotamano-de-tareariesgo

Paso 4: Tamaño de tarea y riesgo

Objetivos

Aplicar los tres criterios de tarea pequeña y la prueba de reanudación.
Enumerar los seis puntos de alto riesgo y sus exclusiones.
Escribir una línea Risk correcta.
Separar las tres decisiones que suelen mezclarse: documento, escritor y verificador.

Este capítulo es el más importante del curso. Casi todas las demás reglas dependen de lo que se decide aquí.

Tarea pequeña: tres condiciones

Una tarea es pequeña cuando se cumplen las tres:

#	Criterio	Cómo se comprueba
1	Comprendida	El resultado está especificado, se sabe qué y dónde cambiar, y no hay decisión de producto o diseño abierta. Se demuestra con una tanda de lectura: hasta 3 llamadas y unos 10k tokens
2	Riesgo contenido	No toca ningún punto de alto riesgo
3	Reanudable desde el diff	Si la sesión se detuviera ahora, alguien podría terminar el trabajo con el pedido original y `git diff`

La prueba de reanudación

El tercer criterio tiene nombre propio y decide el documento de feature. Una tarea es grande únicamente cuando falla, cosa que la fuente asocia a estos casos:

Varias sesiones de trabajo.
Espera de algo externo.
Entregables separados que quieres mantener aparte. Esto no incluye varias funcionalidades pedidas a la vez.
Requisitos demasiado largos para sobrevivir a una compactación del contexto.

The number of files, commands or tests, fixes, or a requested todo list never decides size.

internal/components/agentguidance/routing.go

La documentación usa “large” y “substantial” como sinónimos: las reglas de enrutamiento dicen large, y la guía de uso prefiere substantial.

Contraejemplos útiles

Situación	Clasificación	Motivo
Renombrar un campo en 30 archivos con un patrón claro	Pequeña	Se comprende y el diff lo explica todo
”Hazme una lista de tareas y arregla estos 5 bugs”	Por sí mismo no es grande	Una lista pedida y un número de arreglos no deciden el tamaño
Tres funcionalidades distintas pedidas juntas	Por sí mismo no es grande	”Nunca varias funcionalidades pedidas a la vez”
Integración que espera credenciales de un proveedor	Grande	Depende de algo externo
Especificación de 80 líneas con mensajes exactos	Grande	Los requisitos no sobreviven a una compactación
Un cambio con 2 sesiones previstas	Grande	Falla la prueba de reanudación

El camino pequeño

Cuando la tarea es pequeña, el camino es breve:

Trabajo inline, incluidos varios archivos de un mismo cambio comprendido.
Se observa RED inline antes del arreglo.
La prueba enfocada y la suite corren inline, una vez cada una.
Sin explorador, worker ni verificador.
Sin documento de feature, espejo ni commits, salvo que los pidas.
La lista de tareas es opcional.

Alto riesgo: los seis puntos

La definición general dice que un error sería difícil de detectar, difícil de deshacer o llegaría más allá del cambio. La lista es cerrada y numerada porque otras herramientas la citan por número.

#	Punto	Incluye	No incluye
1	Datos o efectos irreversibles	Migraciones, cambiar o borrar datos almacenados, cambios de formato persistido	Guardar registros nuevos, una base de desarrollo o pruebas que un seed o backup reconstruye
2	Seguridad	Autenticación, permisos, credenciales, secretos, guardas, sandbox
3	Contratos que otros consumen	Cambiar o eliminar API pública, flags de CLI, formatos de configuración, exports publicados, prompts o contratos espejados	Agregar un flag, comando o campo opcional. Los cambios pedidos no son de alto riesgo por sí mismos, pero las roturas no pedidas en código compartido sí lo son
4	Concurrencia	Locks, condiciones de carrera, orden asíncrono
5	Entrega o entorno	Instaladores, release, CI, deploy, dependencias
6	Sin prueba que atrape una regresión	Lo que cambia no tiene ninguna prueba capaz de detectarlo

”No está claro” no es alto riesgo por defecto

“Unclear” cuenta como alto riesgo solo cuando una mirada acotada no puede determinar si aplican los puntos del 1 al 5. La regla existe porque tratar toda duda como riesgo alto activaría verificadores sin motivo.

La línea Risk

Todo cambio de código, pequeño o delegado, cierra con una línea en uno de estos formatos:

Risk: item 3 (cambia el formato de salida de --json, que consumen otros scripts)

Risk: none

Cualquier punto citado activa el disparador de verificación. Antes de escribir Risk: none hay una comprobación concreta:

Check whether the diff changes code that existing behavior the request did not mention also uses (shared options, parsers, helpers); if it does, that is item 3.

internal/components/agentguidance/routing.go

Es decir, si tocaste un parser compartido para agregar una opción a un comando, debes preguntarte qué le pasó a los otros comandos que lo usan.

flowchart TD
    A["Terminé el cambio"] --> B{"¿Toca alguno de los puntos 1 al 6?"}
    B -->|"Sí"| C["Risk: item N (motivo)"]
    B -->|"No lo parece"| D{"¿Cambia código compartido por<br/>comportamiento que el pedido no menciona?"}
    D -->|"Sí"| E["Risk: item 3 (motivo)"]
    D -->|"No"| F["Risk: none"]
    C --> G["Verificador independiente<br/>tras las comprobaciones propias"]
    E --> G

Tres decisiones independientes

Este es el punto que más confusión genera. Tamaño, escritor y verificador se deciden por separado, cada uno con su propio disparador.

Decisión	Depende de	Consecuencia
¿Hay documento de feature?	Solo la prueba de reanudación	Documento, espejo y commits
¿Hay worker?	Solo el Writer trigger	Delegación de la escritura
¿Hay verificador independiente?	Solo un punto de alto riesgo nombrado	Verificación extra

docs/trigger-rules.md lo deja claro: el alto riesgo saca a una tarea del camino pequeño, pero el documento de feature sigue dependiendo únicamente de que falle la prueba de reanudación.

Eso produce combinaciones que al principio sorprenden:

flowchart LR
    subgraph A["Cambio de 2 líneas en login"]
        A1["Reanudable: sin documento"]
        A2["Sin motivo de writer: inline"]
        A3["Punto 2: con verificador"]
    end
    subgraph B["Refactor de varias sesiones sin riesgo"]
        B1["No reanudable: con documento"]
        B2["Sin motivo de writer: inline"]
        B3["Sin punto de riesgo: sin verificador"]
    end
    subgraph C["Dos módulos independientes grandes"]
        C1["Según reanudación"]
        C2["Unidades paralelas: con writers"]
        C3["Según punto de riesgo"]
    end

Reevaluar

Cuando un mecanismo termina, se vuelve a evaluar el tamaño. Una tarea que parecía incierta puede pasar a pequeña después de recibir el mapa de un explorador, y sigue siendo pequeña mientras se mantengan los tres criterios.

Tres números que no se deben mezclar

Número	Qué es	Qué no es
~400 líneas por tarea	Heurística de planificación	Criterio de tamaño, tope o disparador
~400 líneas acumuladas	Presupuesto de entrega de la rama, capítulo 15	Criterio para decidir si una tarea es grande
Presupuesto del revisor	Límite de lo que cabe en el prompt de RDD	Indicador de riesgo

Actividad

Clasifica cada caso con tamaño, ruta y línea Risk:

Corregir un typo en un mensaje de error que un script externo analiza.
Agregar un flag nuevo y opcional a un comando, tocando el parser compartido por 5 comandos.
Migrar una columna en producción, con un script de 40 líneas.
Traducir toda la documentación del proyecto en varias sesiones.

Una posible solución

Aplica el punto 3, porque otro consumidor analiza el mensaje, así que no cumple el criterio de riesgo contenido. Como sigue siendo reanudable, no lleva documento. Inline con verificador.
Agregar el flag no es alto riesgo. Pero el parser es compartido: si el cambio afecta a los otros comandos, aplica el punto 3. La línea depende de la comprobación diferencial del capítulo 8.
Punto 1. El documento depende de la reanudación, y 40 líneas pueden no necesitarlo. Verificador obligatorio.
Grande por varias sesiones. Risk: none si es documentación sin efectos ejecutables. Inline, salvo que existan unidades paralelas con motivo.

Autoevaluación

¿Qué decide que una tarea sea grande?
- A. Que toque más de 400 líneas
- B. Que se hayan pedido varias funcionalidades a la vez
- C. Que toque más de cinco archivos
- D. Que falle la prueba de reanudación
Agregar un flag opcional nuevo a una CLI, sin alterar lo existente, ¿es punto 3?
- A. No: agregar un flag está excluido
- B. Sí, siempre
- C. Solo si supera las 100 líneas
- D. Solo si RDD está activo
¿Cuál es la excepción dentro del punto 1?
- A. Las migraciones en staging
- B. Cualquier formato persistido
- C. Guardar registros nuevos o una base que un seed reconstruye
- D. Los cambios de esquema pedidos por el usuario
Un cambio de dos líneas en autenticación, reanudable desde el diff, recibe:
- A. Documento de feature y worker
- B. Sin documento, y verificador independiente por el punto 2
- C. Documento de feature sin verificador
- D. Ningún control, porque es pequeño en líneas

Respuestas

D. Los demás criterios están descartados expresamente.
A. La exclusión del punto 3 lo menciona, siempre que no rompa código compartido sin pedirlo.
C. Es la aclaración entre paréntesis del punto 1.
B. El documento depende de la reanudación, y el verificador del punto de riesgo.

Lista de control

Aplico los tres criterios sin mirar el número de archivos.
Recuerdo los seis puntos y sus exclusiones.
Hago la comprobación de código compartido antes de escribir Risk: none.
Decido documento, escritor y verificador por separado.

Fuentes

internal/components/agentguidance/routing.go, docs/trigger-rules.md, odd/tasks/task-size-canon.md, odd/tasks/1731-parity-delegate-for-reason.md.