Un gate rojo no es un fracaso. Es un freno que funciona.

Un sistema que nunca se detiene también puede avanzar sobre un error. Los controles existen para impedirlo. Aquí tienes tres bloqueos del mismo run — el de los pagos con Stripe — con su resolución.

Auditoría y validación no son lo mismo

El auditor cuestiona el trabajo hecho y señala riesgos concretos, con fichero y línea. El validator ejecuta comprobaciones automáticas y solo acepta números. Son perspectivas complementarias — una ataca, la otra mide.

Bloqueo 1 — el auditor caza una violación de arquitectura

El builder conectó el panel de cobros directo a la base de datos, que en el repo real se traduce en algo así:

routes/api/pagos/+server.ts importa supabase → VIOLACIÓN de la regla 3 (la hexagonal: las rutas no tocan la base; hablan con puertos).

Veredicto del auditor, numerado:

FALLO 1: routes/api/pagos/+server.ts:14 — import directo de supabase en capa de ruta. FALLO 2: sin contrato de puerto para CreatePayment.

Qué pasa: nada más. La fase vuelve al builder (bucle rojo ④→③), que reimplementa hablando con el puerto PaymentRepository. El architect ya había definido el contrato en su plan: el builder lo había saltado, no lo tenía que inventar. Todo el intercambio queda firmado en el journal (evento blocked).

Bloqueo 2 — el validator no acepta un «casi»

El builder repara, el auditor da PASS, y llega el momento de medir:

arquitectura → check-architecture → VERDE suite billing → 41/42 (1 test en rojo: reintento duplicado) lint → 0 · typecheck → 0 · builds → OK skill-ui lint → PASS · docs check → exit 0

Un solo ROJO. La fase NO avanza: la auto-reparación arranca con presupuesto (máx N intentos). El builder arregla el caso de reintento — un pago duplicado debe rechazarse, que era precisamente un test que él mismo escribió ANTES de implementar. Segunda pasada: 42/42 → release.

Si el presupuesto se agotara, la fase queda BLOQUEADA y se te avisa. Nunca un bucle infinito, nunca un «déjalo así».

Bloqueo 3 — la evidencia falta

Release intenta cerrar f1 y encuentra un criterio sin número:

[x] suite billing verde — 42/42 [x] arquitectura — hexagonal VERDE [ ] webhook idempotente (replay de eventos) — sin evidencia grabada

Resultado: f1 queda ABIERTA. Sin trampas. El replay de eventos se ejecuta, su veredicto se graba en el spec, y solo entonces f1 pasa a CERRADA. El sistema no distingue entre «no lo hice» y «no lo anoté»: ambos dejan la fase abierta.

Un gate rojo de verdad (caso real, 2026-10-29)

Esto NO es ilustrativo: es un gate real del propio desarrollo de Canary, capturado del sistema:

g4-tck-must-level — 48 failed, 17 passed, 170 skipped in 5.47s, exit 1 severity=high · event_type=validation_failure “real MUST-level conformance gap… escalated verbatim per SPEC rule, fail recorded with learning event”

Fíjate en lo que NO pasó: el veredicto no se suavizó, no se «dispositionó» para quedar bien ni se enterró. Quedó grabado como evento de aprendizaje de severidad alta, escalado al owner tal cual — y la entrega siguió su curso con el fallo documentado. El gate no aceptó la realidad que quería; aceptó la que había. (Puedes ver el output completo en la página Verificado.)

Qué conviene revisar cuando algo se detiene

• La comprobación fallida exacta (¿qué criterio, qué comando?).
• El alcance afectado (¿una fase, la tarea entera?).
• La evidencia del fallo (¿dónde quedó firmado?).

Y no conviertas el verde en garantía absoluta: los gates prueban criterios concretos («42/42», «webhook replay idempotente»). Pasarlos no demuestra la ausencia de cualquier defecto. Su valor está en que el criterio y su resultado son visibles y repetibles — el LLM puede equivocarse mil veces; el gate solo acepta la realidad.