Las listas de funciones como primitivas del harness
Si «hecho» es solo una sensación, el agente se sentirá hecho demasiado pronto. Escribe las funciones como cosas que un bucle puede comprobar, y todo lo que viene después es más fácil.
Un constructor no dice que la casa está lista porque lo parezca. Hay una lista, y un inspector firma cada línea: cableado, fontanería, aislamiento. Una lista de funciones es esa lista, y la puerta de verificación es el inspector. El done es una firma, no una sensación.
Convierte el «hecho» en datos
Una lista de funciones es la tarea expresada como ítems discretos y comprobables: cada uno una capacidad concreta con una forma de confirmar que funciona. No es una descripción vaga de la intención, son los criterios de aceptación, hechos lo bastante explícitos como para que un programa pregunte «¿este ya se cumple?».
{
"agent_tool": "claude",
"max_retries": 3,
"features": [
{ "id": "login", "name": "Login email + contraseña", "state": "done" },
{ "id": "refresh", "name": "Rotación de refresh-token", "state": "coding" },
{ "id": "logout", "name": "Logout + revocar", "state": "pending" }
]
}flowchart LR P["pending"] --> C["coding"] C --> V["verifying"] V --> RT["ready_to_test"] RT --> D["done"] V -->|rojo tras max_retries| B["blocked"] linkStyle 3 stroke:#2ea043,stroke-width:2.5px,color:#2ea043 linkStyle 4 stroke:#e0493f,stroke-width:2.5px,color:#e0493f
Por qué es una primitiva, no un doc
Como la lista es comprobable, se vuelve portante para el resto del harness. El motor la lee para elegir la siguiente función. La puerta escribe el estado de vuelta en ella. El progreso es el recuento de funciones done, no la opinión del agente. Es el único artefacto que conecta objetivo, ejecución y verificación, que es justo por lo que cuenta como primitiva y no como mera documentación.
El motor corre sobre la lista
En Agentum, feature_list.json es el backlog, y cada función lleva un estado que el motor avanza: pending → coding → verifying → ready_to_test → done (o blocked al agotar max_retries). El motor deriva el prompt del agente de AGENTS.md más el nombre y la descripción de la función, lo lanza y corre verify.sh con la clave $HARNESS_FEATURE_ID, marcando done solo en verde. Los campos de nivel superior (agent_tool, max_retries, agent_yolo, settle_timeout_secs) ajustan la corrida. La finalización se mide, no se afirma.
Puntos clave
- Una lista de funciones expresa el «hecho» como ítems discretos y comprobables.
- Como es comprobable, se vuelve portante, la usan tanto el bucle como la verificación.
- El progreso es el recuento de ítems verificados, no la autoevaluación del agente.
- Agentum corre el bucle contra la lista y solo para cuando todos los ítems están en verde.
Ejercicios
- Escribe una feature list. Convierte tu próxima tarea en tres a cinco funciones, cada una con un nombre y un done comprobable.
- Haz el done comprobable. Para una función, escribe el comando exacto que prueba que funciona.