Checklist de cierre y calidad

Cerrar bien es una rutina

En un restaurante, el cierre tiene una lista: apagar fuegos, guardar género, limpiar, apuntar lo que falta. No depende de la memoria de nadie. Para agentes funciona igual: lo que cierra bien una sesión es una lista escrita y un par de hábitos periódicos.

Pieza 1: el checklist de cierre

La plantilla del curso es corta a propósito. Copia y adapta:

# Checklist de estado limpio
- [ ] La ruta de arranque estándar sigue funcionando.
- [ ] La ruta de verificación estándar sigue ejecutándose.
- [ ] El progreso actual está en el registro de progreso.
- [ ] El estado de las funciones refleja lo realmente verificado y lo no verificado.
- [ ] No queda ningún paso a medias sin documentar.
- [ ] La próxima sesión puede continuar sin reparación manual.

Ponlo en el archivo de instrucciones y exige que el agente lo marque, con evidencia, antes de dar la sesión por terminada. Es la versión operativa de las cinco dimensiones.

Pieza 2: el documento de calidad

Un documento de calidad es un archivo vivo que da una nota a cada módulo o capa. No es una auditoría única: se actualiza tras cada sesión importante, así ves si el código se fortalece o se degrada con el tiempo.

Escala de la plantilla: A (todo verificado, arquitectura limpia, legible para agentes, tests estables), B (verificado, pequeñas lagunas), C (funciona en parte, zonas difíciles de entender), D (no funciona o con problemas estructurales). Un fragmento:

## Módulo de pagos (C)
- Verificación: parcial (falta probar el callback)
- Legible para el agente: difícil (lógica repartida en 3 archivos)
- Tests: inestables (2 intermitentes)

La sesión nueva lo lee y sabe por dónde empezar: arregla primero lo que tiene peor nota.

Pieza 3: limpieza en dos ritmos

• Al salir de cada sesión: retirar temporales, actualizar estados, comprobar build y tests. Es la limpieza inmediata.
• Cada semana: un repaso más amplio. El material sugiere escanear documentos obsoletos y violaciones de estructura, actualizar las notas de calidad, abrir cambios pequeños de limpieza y repetir un conjunto fijo de pruebas de referencia.

Pieza 4: limpieza idempotente

Una operación idempotente da el mismo resultado si la ejecutas una vez o diez. Es importante porque las limpiezas se reintentan tras fallos y no deben romper nada la segunda vez.

rm -f /tmp/debug-*.log     # -f: no falla si no hay archivos
git checkout -- .env.local # vuelve a un estado conocido
npm test                   # comprueba que limpiar no rompió nada

Pieza 5: quitar lo que ya sobra

Cada pieza del harness existe porque el modelo no podía hacer algo por sí solo. Pero los modelos mejoran, y una restricción necesaria hace unos meses puede ser peso muerto hoy. La práctica propuesta: cada mes, desactiva temporalmente un componente y ejecuta tareas de referencia. Si el resultado no empeora, elimínalo; si empeora, vuelve a ponerlo o cámbialo por algo más ligero.