Modificar con evidencia

Paso a paso

1. Lee el issue #12 en GitHub. Fíjate en tres cosas del cuerpo: la anécdota de los seis tickets del viernes, la frase “se supone que el deduplicador evita esto” (sabe el síntoma, no la causa), y los pasos para reproducir: “mandar la misma alerta muy seguido, con una sola no pasa”. Es la palabra concurrencia, escrita por alguien que nunca la dijo.

2. Levanta Postgres en otra terminal y espera el healthy: docker compose -f deploy/compose/docker-compose.yml up -d db.

3. En la misma sesión del Nivel 1 (o /resume), pide reproducir antes de arreglar:

El issue #12 reporta duplicación de incidentes bajo concurrencia, y el
mapa del repo sugiere por qué. Reprodúcelo primero con un test que falle,
arréglalo, y muéstrame el diff completo antes de dar nada por terminado.

Acá aparece el primer permiso: el agente quiere ejecutar un comando y se detiene a pedirte aprobación. Opciones: “sí, solo esta vez” (la que usas casi siempre), “no me preguntes de nuevo por este comando” (cada una es una puerta que dejas abierta; guárdalo para el Nivel 7). Dos atajos: Tab edita el comando antes de aprobarlo, Ctrl+E le pide que explique qué hace.

Resultado esperado: reproduce con un test que falla (si el primer intento sale verde, pídele que lo haga determinístico: una carrera que no aparece cuando quieres verla es exactamente el problema). Encuentra el comentario del importador legacy y va a verificarlo a scripts/legacy_import.py (no le cree al comentario, lo comprueba). Explica por qué descarta el UNIQUE constraint (compliance) y aplica un candado de base de datos en un solo archivo. Corre la suite y reporta verde.

4. Revisa el diff antes de aceptar. Dos cosas: toca solo lo necesario, y hay una sola transacción dentro de la función. Si quedó un commit intermedio (el del AuditEvent), ese commit libera el candado a mitad de camino y la carrera sigue viva. Si lo ves, pídeselo: “deja una sola transacción: el commit intermedio libera el candado antes de insertar”.

5. Verifica con tus manos, no con su reporte:

Dame el comando exacto para correr ese test yo mismo en mi terminal,
usando el entorno que tú ya dejaste preparado.

La coletilla del entorno importa: sin ella te da la receta genérica con pip install, y esa falla.

6. El teatro de los dos colores, en tu terminal: corres su comando (verde) · git stash y lo corres de nuevo (rojo: sin el arreglo, N incidentes para la misma alerta; el test sí caza el bug) · git stash pop y de nuevo (verde). Rojo sin el arreglo, verde con él. Ciclo cerrado.

7. Commit, lo hace el agente. Solo commit, sin push.

Haz el commit del fix, con un mensaje decente que referencie el issue #12.

El botón de volver atrás (/rewind)

8. Un pedido vago, a propósito, como los que uno tira apurado:

Mejora los mensajes de error del módulo de notificaciones.

Dos ramas posibles: pisó de más (tocó archivos que no querías) o salió disciplinado. En cualquiera, prompt vacío, Esc Esc, y aparece el menú de checkpoints: cada paso de la sesión con sus archivos cambiados al lado. Eliges la fila del pedido vago, Enter, “Restore code only”. Los archivos vuelven.

Dos precisiones: los checkpoints cubren lo que el agente edita, no todo lo que un comando de terminal pueda tocar. Y no reemplazan a git: git es la historia oficial, el checkpoint es el deshacer de la sesión.

9. El mismo pedido, acotado:

Mejora los mensajes de error SOLO en app/adapters/, sin tocar ningún otro
archivo, y muéstrame el diff.

Recuperarse es barato. Acotar el pedido es más barato todavía.

El gemelo de infra (se enseña una vez, acá)

La misma disciplina de evidencia existe al otro lado del repo:

CÓDIGO                      INFRAESTRUCTURA
test rojo → fix → verde     terraform plan → apply → verify
el diff del código          el plan ES el diff de la infra
PR con review               PR con review del plan
bug → logs                  drift: ¿quién tocó este recurso?

10. Con Terraform inicializado en infra/environments/staging/, pega el bloque completo (pedido y comando juntos):

En infra/ hay una variable de etiquetado inconsistente entre módulos.
Corrígela. Muéstrame fmt, validate y el plan. NO ejecutes apply.
terraform fmt -check && terraform validate && terraform plan

Resultado esperado: encuentra solo la inconsistencia (un bloque de labels copiado de otro proyecto, con su TODO delatándolo), propone el diff (seis líneas hardcodeadas a una: labels = var.labels), corre fmt y validate, y muestra el plan. Si no tiene project_id, pregunta en vez de adivinar. Si no tienes state, el plan dirá “crear todo desde cero” y el agente lo aclara: el plan es un diff contra el estado que conoces del mundo.

Un diff de veinte líneas de Terraform puede tener más blast radius que quinientas líneas de aplicación. No revisamos cantidad de líneas: revisamos superficie de impacto.

Comandos desbloqueados

• /rewind · checkpoints automáticos de los archivos en cada paso. Esc Esc abre el menú.

Lo que este nivel deja anotado para el siguiente: el comando correcto para correr los tests y por qué el atajo falla · la convención de los tests de concurrencia (Postgres de verdad, no el motor de juguete) · los comentarios del código son pistas que se verifican, no órdenes · nada se declara terminado sin diff y evidencia. Y una decisión operativa: el test de concurrencia entra al gate obligatorio del pipeline.

Backlog: ítem 1 tachado. Marcador: autonomía sube (ya modifica) · control sube (solo con evidencia).