7. Bucles de verificación — fijar la definición de 'listo' en el sistema

Esta es la parte 7 de la serie Alice Way. En la parte 6 Delegación Multi-Agent, la verificación automatizada apareció como la puerta para el trabajo delegado. Este artículo eleva esa verificación un nivel: tanto si el trabajo se hizo directamente como si se delegó, el sistema aplica un bucle en el momento en que "listo" está a punto de pronunciarse.

0. Un bucle de verificación es el sistema re-verificando lo que "la mente cree que está listo"

El momento en que el trabajo se siente terminado es el más peligroso. La mente se inclina hacia el alivio del "ya está" y los procedimientos omitidos son difíciles de detectar. Lint sin ejecutar, build roto, tests saltados: y "listo" se escribe de todas formas.

El bucle de verificación es el dispositivo que rompe ese momento por un instante. Justo antes de que se escriba "listo," lint · build · test · seguridad · comprobaciones de diff se ejecutan automáticamente, y el reporte no puede salir a menos que pasen. El sistema re-confirma lo que la mente cree que está listo.

Este artículo es un registro de los siete pasos que componen ese bucle, qué activa el auto-disparo y cómo se gestiona el bypass.

El mecanismo de auto-disparo es el sistema de hooks de Anthropic Claude Code, ya citado en la parte 5 — Hooks y automatización. Este artículo es un registro de los pasos de verificación que el operador construyó sobre ese mecanismo.

1. Por qué se requiere el auto-disparo

Si el operador tiene que invocar conscientemente la verificación, a veces la salta. Las verificaciones saltadas se acumulan y el sistema en producción acaba rompiéndose. Si omitir algo es un límite cognitivo, la aplicación tiene que vivir fuera de la cognición.

El tercero es la respuesta. Forzar la verificación antes de que salga el reporte y la omisión se bloquea a nivel del sistema. CI es una red de seguridad secundaria, no la primera línea.

2. El bucle de verificación de 7 pasos

Lo que encontré. Cada paso se detiene de inmediato ante el fallo y reporta un mensaje claro.

2.1 Lint

Estilo, variables sin usar, errores obvios. Es el más rápido y el que con más frecuencia detecta problemas. Se ejecuta primero: un fallo aquí ahorra el tiempo de los pasos posteriores.

2.2 Verificación de tipos

TypeScript / mypy / otros verificadores de tipos estáticos. Detecta errores más profundos que lint no puede.

2.3 Build

¿El build real falla? Impide que cambios que el compilador no puede pasar lleguen al merge.

2.4 Test

Tests unitarios + tests de integración. Los tests de integración tocan recursos reales, no simulados: hubo una vez en que los tests simulados pasaron y una migración en producción se rompió. Ese incidente estableció la regla.

2.5 Verificación de seguridad

Hardcoding de secretos, patrones de SQL injection, filtración del nombre real del operador: grep para riesgos. Una lista de comprobación de 8 elementos se ejecuta en cada cambio. Detención inmediata ante cualquier coincidencia.

2.6 Revisión de diff

¿Las líneas cambiadas coinciden con la intención del operador? ¿Ha entrado algo no intencionado? Es la última puerta antes de que el ojo humano apruebe.

2.7 Comprobación de salida del reporte

¿El texto del reporte en sí conlleva riesgo de filtración (secretos, identificadores internos, nombres reales)? Un grep adicional justo antes de que el reporte se envíe.

El reporte de "listo" no puede salir a menos que los siete pasen. Ante cualquier fallo, el reporte se bloquea y el operador recibe un "paso X fallido" en una sola línea.

3. Disparadores de auto-disparo — cuándo se ejecuta

Condiciones bajo las cuales el bucle de verificación se dispara automáticamente.

3.1 Disparador explícito — justo antes de la redacción "listo"

Justo cuando el operador intenta generar "terminado" / "listo" / "ready" / equivalente, el hook interviene. Antes de la salida, no después — después sería tarde.

3.2 Disparador explícito — reportes "PR ready" / "mergeable"

Los mensajes como "el PR está listo" también disparan el mismo hook. La verificación no se ejecuta después de que el PR sale; se ejecuta antes.

3.3 Disparador explícito — reportes "commit-ready"

"Listo para commit" — igual. No bloquea el propio commit, pero aplica la verificación una vez más antes de que esa señal llegue al operador.

3.4 Invocación explícita — /verify

Cuando el operador quiere verificar conscientemente, el slash command invoca el mismo bucle. Dos entradas que apuntan al mismo procedimiento que el hook.

4. Cuándo se omite el auto-disparo

No todo el trabajo necesita verificación. Las siguientes condiciones se declaran como SKIP para el auto-disparo.

• Trabajo de solo lectura — escaneos · revisiones · investigaciones. Sin cambio de código, nada que verificar.
• Cambios solo de docs — solo se tocaron archivos .md. Lint/build no tiene sentido aquí.
• Scratch intencional — experimentos, prototipos. El operador declara.
• El operador dijo explícitamente "omitir verificación" — bypass explícito.

Las condiciones SKIP viven en la persona, de modo que el hook juzga automáticamente. El operador no tiene que decir "omitir esto" en cada ocasión.

5. El rastro que deja el bypass

A veces el operador necesita hacer bypass intencionalmente: depuración a mitad, trabajo ad-hoc, hotfix en curso.

El bypass es posible. Pero el hecho del bypass siempre aterriza en el log.

[verify] BYPASSED at 2026-05-17 14:23 — reason: emergency hotfix
[verify] Skipped: lint / build / test / security / diff / report
[verify] Note: re-run /verify manually after hotfix lands

Así, los bypasses son rastreables y las investigaciones post-hoc de "¿por qué no se verificó esto?" resultan sencillas. El bypass no se bloquea, pero el rastro permanece.

Si el bypass no es posible, el operador desactiva la verificación por completo. Una vez desactivada, permanece así para siempre.

6. Manejar el fallo

Lo que el operador ve cuando la verificación falla.

[verify] FAILED at step: Test (3/7)
[verify] 2 tests failed:
  - integration/auth.test.ts > "github oauth callback redirects to next"
  - integration/db.test.ts > "rls policy blocks other user's row"
[verify] Full log: /tmp/verify-2026-05-17-1423.log
[verify] Report blocked.

El núcleo es: la información del fallo cabe en una pantalla. Dónde falló, cuál es el problema, dónde vive el log detallado. El operador decide a partir de esa pantalla única (corregir / bypass / SKIP).

Volcar el log completo en la consola obliga al operador a resumirlo él mismo. Eso en sí mismo es una carga de atención fresca.

7. Trampas — patrones donde falla la verificación

7.1 Demasiado lenta

Si la verificación tarda más de 30 segundos, el operador empieza a pensar "esto es demasiado lento" y usa el bypass con frecuencia. Una vez que el bypass se convierte en el comportamiento por defecto, la verificación pierde su sentido. → Los pasos más baratos primero (lint/tipos detectan la mayoría de los fallos), los pasos costosos después.

7.2 Demasiados falsos positivos

Si la verificación genera falsas alarmas con frecuencia, el operador empieza a desconfiar de ella. Desconfianza → bypass. → La verificación en sí debe ser fiable. En el momento en que se detecta una falsa alarma, hay que corregir la propia lógica de verificación de inmediato.

7.3 Solo pasa/falla, sin especificaciones

Decir solo "falló" sin indicar dónde ni por qué obliga al operador a buscar en los logs por su cuenta. La carga vuelve al operador. → La salida se mantiene breve pero específica (qué paso, qué test, qué línea).

7.4 Condiciones SKIP demasiado estrechas

Si la verificación se dispara ante casi cualquier acción, el operador se fatiga. Verificar trabajo de solo lectura convierte la propia verificación en ruido. → Especificar suficientes condiciones SKIP en la persona.

8. Comprimido en un principio

El núcleo del diseño del bucle de verificación se resume en una oración.

"En el momento en que el operador está a punto de decir 'listo,' el sistema interviene por un instante. Solo cuando pasa puede salir esa palabra. El bypass es posible pero siempre deja un rastro."

Cuando esto se cumple, el bucle de verificación se convierte en una red de seguridad que detiene el alivio del operador por un instante. Cuando se rompe — la verificación se desactiva, se descarta como fuente de falsas alarmas, o el bypass se convierte en el comportamiento por defecto.

El siguiente artículo cubre el recurso fundamental del que depende todo lo anterior (verificación, memoria, skills, hooks): la economía de tokens, es decir, qué admitir en la context window y qué mantener fuera.