Definition of Done

¿Cuándo está lista la tarta?

«Está lista cuando huele bien» es una opinión. «Está lista cuando un palillo sale limpio del centro» es una prueba. La primera depende de quién la huela; la segunda la puede hacer cualquiera y da el mismo resultado.

La Definition of Done (DoD, «definición de hecho») es el palillo de tus tareas: un conjunto claro de condiciones que se deben cumplir todas antes de declarar que algo está terminado. Se escribe una vez en el repo y vale para todas las sesiones.

Por qué hace falta con agentes

Sin una DoD explícita, el agente usa su criterio interno, que suele ser «el código parece bien». Es lo que vimos en la victoria prematura. La DoD transforma «hecho» de un juicio subjetivo en una determinación objetiva: el agente debe satisfacer todas las condiciones antes de decir la palabra.

Qué incluir

Una buena DoD es corta y cada línea se puede comprobar. A partir de las ideas del curso, un punto de partida:

## Definition of Done
- La función tiene su verificación ejecutada y pasa (extremo a extremo si cruza componentes)
- Lint y tipos pasan
- La evidencia está registrada (salida, captura o log)
- El estado en la lista de funciones es «passing»
- El progreso y el traspaso están actualizados
- Todo está en un commit y no queda nada a medias
- El repo sigue arrancando y verificándose con los comandos estándar

Algunas de esas líneas vienen de las lecciones del curso (la jerarquía de verificación, la evidencia obligatoria) y otras de la plantilla de estado limpio. Adapta la lista a tu proyecto; lo importante es que cada línea sea una acción o una comprobación, no un deseo.

Una lista de estado limpio como parte de la DoD

La plantilla clean-state-checklist.md del curso sirve de cierre práctico. Dice, en esencia:

• La ruta estándar de arranque sigue funcionando.
• La ruta estándar de verificación sigue ejecutándose.
• El progreso actual está registrado.
• El estado de las funciones refleja lo realmente aprobado frente a lo no verificado.
• No hay ningún paso a medias sin documentar.
• La próxima sesión puede continuar sin reparaciones manuales.

La retomaremos en el módulo de observabilidad. Aquí basta con entender que «hecho» incluye dejar el terreno ordenado.

Dónde escribirla

En AGENTS.md o CLAUDE.md, en una sección con título evidente. Mejor aún si ahí se enlaza el comando exacto de verificación. Un agente que lee la DoD al empezar sabe a dónde va; uno que no la lee la inventa.

Orden de prioridades

Una regla útil que recoge la lección: primero la corrección funcional, después el rendimiento, al final el estilo. Y nada de refactorizar hasta que lo central esté verificado. Si lo incluyes en la DoD, evitas el «ya que estoy» más peligroso.