La lista de funciones

«Compra algo de fruta»

Le pides a un amigo que compre fruta y vuelve con limones. Su fruta no es tu fruta. Con los agentes pasa igual: dices «añade un carrito de compra» y el agente entiende «un componente Cart y un método addToCart». Tú querías «el usuario ve productos, los añade y completa la compra». Sin una definición compartida de «hecho», el agente usa la suya: «he escrito mucho código y parece completo».

Una nota de progreso como «auth hecha, carrito casi, falta pagos» no ayuda: ¿qué es «casi»? ¿Qué pruebas pasó? ¿Qué bloquea los pagos? Nadie lo sabe.

Una lista que manda

La lista de funciones no es una nota para humanos que se olvida. Es una pieza de datos de la que dependen otras partes del harness:

• El planificador elige la siguiente función sin empezar.
• El verificador ejecuta la comprobación y decide si se permite el cambio de estado.
• El informe de traspaso se genera a partir de ella.
• El seguimiento cuenta cuántas funciones hay en cada estado.

Es como las claves primarias de una base de datos: no decides «prescindir» de ellas, porque lo demás se apoya encima. Y debe ser la única fuente de verdad del alcance: si lo que hay que hacer está repartido entre la conversación, comentarios TODO y la lista, tarde o temprano se contradicen.

Cada función es una terna

Tres campos, y si falta uno la entrada está coja como un taburete de dos patas:

1. Comportamiento: qué puede hacer el usuario, en términos visibles.
2. Comprobación: cómo verificarlo exactamente.
3. Estado: no empezada, activa, bloqueada o aprobada.

Un ejemplo basado en la plantilla del curso:

{
  "id": "chat-002",
  "priority": 2,
  "title": "Enviar un mensaje en la conversación actual",
  "user_visible_behavior": "El usuario envía un mensaje y lo ve en el hilo activo.",
  "status": "not_started",
  "verification": [
    "Abrir una conversación existente.",
    "Escribir un mensaje y enviarlo.",
    "Comprobar que el mensaje aparece en el hilo."
  ],
  "evidence": [],
  "notes": ""
}

La plantilla completa añade, arriba del archivo, reglas globales (una sola función activa, no aprobar sin evidencia, no saltarse la verificación) y una leyenda de estados. Los campos del ejemplo están en inglés porque así vienen en la plantilla; puedes mantenerlos o traducirlos mientras tu herramienta los lea igual.

La granularidad

Cada función debe poder terminarse en una sesión. «Implementar el carrito» es demasiado grande y no terminará. «Crear el campo name del modelo Cart» es demasiado pequeño y la gestión pesa más que el trabajo. «El usuario puede añadir productos al carrito» está bien: como cortar un filete, ni la pieza entera ni carne picada.

Las reglas en el archivo de instrucciones

Para que el agente respete la lista, escríbelo en CLAUDE.md o AGENTS.md:

## Reglas de la lista de funciones
- La lista está en feature_list.json
- Solo una función activa a la vez
- Una función solo pasa a «passing» si su verificación pasa y hay evidencia
- No cambies estados a mano sin ejecutar la verificación

En el ideal de la lección, el cambio de estado lo hace el propio script de verificación y no el agente. Ese es el tema de la máquina de estados.