Quality-Gate — "listo" es un código de salida, no una sensación

Overview

El momento más peligroso de una sesión con IA es cuando dice "listo, ya funciona". Esta skill convierte esa frase en algo verificable: un comando corre, produce números, y esos números se comparan contra la constitución del proyecto.

Si la salida no está pegada en el reporte, no se corrió. Decir "los tests pasan" sin mostrar la salida es la mentira más común del desarrollo asistido por IA — y casi siempre es involuntaria: el modelo infiere el resultado en lugar de observarlo.

Cuándo usar

• Antes de decir "terminado" o entregar a alguien.
• Antes de merge, tag, release o deploy.
• Al recibir código de otro agente o de otra sesión.
• Periódicamente en un proyecto vivo (el trinquete se verifica, no se supone).

Cuándo NO usar

Regla de hierro: sin salida pegada, no pasó

CADA AFIRMACION DE CALIDAD VIENE CON: COMANDO EJECUTADO + SALIDA REAL + NUMERO vs UMBRAL.

Prohibido: "todo verde", "los tests pasan", "no hay errores de tipos", "cobertura ~80%", si no se ejecutó en esta sesión y no se está mostrando la evidencia. Si un comando no existe o no se puede ejecutar, se reporta como NO VERIFICADO, no como aprobado.

Proceso

1. Localiza el gate

Busca en este orden: docs/project/constitution.md → AGENTS.md → scripts del manifiesto (package.json, Makefile, justfile, pyproject.toml) → configuración de CI. Si no hay gate: no continúes verificando a ciegas; ejecuta constitution primero y dilo.

2. Ejecuta, en orden barato → caro

Ejecuta todo aunque algo falle temprano. Un reporte con un solo fallo obliga a repetir el ciclo entero; uno con la lista completa se arregla de una pasada.

3. Compara contra umbrales y decide

4. Revisión humana de capa 2

Si el diff toca zonas sensibles declaradas en la constitución (auth, dinero, datos personales, migraciones, criptografía, envíos masivos), el gate verde no alcanza: marca el diff como pendiente de lectura humana y di exactamente qué archivos y por qué. Las métricas no detectan un if (user.role) invertido ni un endpoint sin verificación de propiedad.

5. Reporte

GATE: <PASA | BLOQUEA> — <proyecto> @ <commit/rama>

| Chequeo        | Comando                  | Resultado | Umbral | Estado |
|----------------|--------------------------|-----------|--------|--------|
| Tipos          | tsc --noEmit             | 0 errores | 0      | OK     |
| Tests          | vitest run               | 84/84     | todos  | OK     |
| Cobertura nueva| vitest --coverage        | 71%       | ≥80%   | FALLA  |
| Complejidad    | eslint                   | máx 14    | ≤10    | FALLA  |
| Secretos       | gitleaks detect          | 0         | 0      | OK     |
| Paquetes       | lockfile + existencia    | 0 fantasma| 0      | OK     |
| Mutación       | —                        | —         | ≥60%   | NO VERIFICADO |

BLOQUEA por: cobertura de código nuevo, complejidad en src/orders/calc.ts:88
Revisión humana pendiente: src/auth/session.ts (zona sensible)
Siguiente paso: tests para calc.ts + extraer la rama de descuentos.

Trampas del propio gate

Anti-racionalización

Formato de salida

Tabla de chequeos (comando, resultado real, umbral, estado), veredicto PASA/BLOQUEA, lista de fallas con archivo:línea, chequeos NO VERIFICADOS, diffs pendientes de revisión humana, y el siguiente paso concreto.