Gestionar el estado con principios ACID

Una transferencia a medias

Imagina que transfieres 100 euros y el banco resta el dinero de tu cuenta, pero se cae antes de sumarlo en la otra. Dinero perdido. Los bancos evitan esto con reglas muy estrictas para sus operaciones, conocidas por las siglas ACID.

El curso toma prestada esa idea para el estado de un agente: todo lo que ha hecho, en qué punto está y qué ha cambiado. Parece complicado, pero se reduce a cuatro hábitos.

Atomicidad: todo o nada

Cada operación lógica (por ejemplo «añadir un endpoint y actualizar sus tests») recibe un commit de git. Si falla a la mitad, se revierte (con git stash o descartando cambios). No existe el «medio hecho».

Consistencia: nunca guardes un estado roto

Define qué es un estado consistente: todos los tests pasan, el linter no da errores. El agente comprueba esto tras cada operación y no hace commit de estados intermedios inconsistentes. Como la transferencia: no puedes restar sin sumar.

Aislamiento: no pisarse entre agentes

Cuando varios agentes trabajan a la vez, sus archivos de estado deben evitar choques. Soluciones simples: que cada agente tenga su propio archivo de progreso, o usar ramas de git separadas. Dos cocineros no sazonan la misma olla a la vez: si queda salada, no se sabe quién fue.

Durabilidad: lo importante, escrito

El conocimiento clave del proyecto vive en archivos versionados con git. El estado temporal puede quedarse en la memoria de la sesión, pero lo que debe sobrevivir entre sesiones se guarda en archivos. Lo que está en la «cabeza» del agente no cuenta; cuenta lo escrito.

Ejemplo mínimo

Un flujo de trabajo en el AGENTS.md que aplica los cuatro principios:

## Al terminar cada tarea
1. Ejecuta `npm run check` (tests + lint).
2. Si falla, corrige o revierte; nunca hagas commit en rojo.
3. Haz un commit por tarea con mensaje descriptivo.
4. Apunta el resultado en PROGRESS.md.