Evidencia y verificación adversarial

Implementado. Es la regla de evidencia del repositorio y el procedimiento con el que se cierran los hallazgos de seguridad y los gates.

Evidencia, no afirmacionesCopiar enlace

Un test no cierra un hallazgo si puede pasar saltándose la frontera que el hallazgo cuestiona. Este patrón, el verde falso, ya ocurrió varias veces en la historia del proyecto:

• un carril de tests completo en verde con un componente sin cablear y un test que esquivaba el manejador;
• una métrica de HDR inventada a partir de la tasa de bits;
• una piscina serie presentada como «agregado multicanal»;
• una prueba de ciclo de vida que abría y cerraba sesiones sin leer ningún byte, de modo que el planificador nunca procesó nada.

Por eso el contador de tests no es evidencia: que todo esté verde no significa que se haya ejercitado el camino que importa. Un rojo honesto vale más que un verde falso.

Cerrar un P0 o un P1Copiar enlace

Cerrar un hallazgo de severidad P0 o P1 exige verificación independiente: quien verifica no es quien implementa. El verificador hace tres cosas:

1. Busca los puntos de llamada: ¿el código que ejercita el test es el camino de producción o un doble?
2. Lee el camino de producción: ¿el manejador o servicio que el test ejercita es el que el cableado conecta en tiempo de ejecución?
3. Hace un humo interactivo: ¿el sistema arranca y responde con datos reales?

Y un arreglo se acepta con rojo antes y verde después (la misma prueba falla sin el cambio), más mutantes: variantes rotas a propósito del arreglo que la prueba debe detectar. Una prueba que no detecta su mutante no demuestra nada.

Verificación adversarialCopiar enlace

Para cierres de P0 o P1, revisiones posteriores a un merge grande de Zig o la declaración de un gate con evidencia fuerte, se usa el procedimiento de verificación adversarial multiagente:

• varios auditores buscan por dimensión (en TypeScript: contratos, capas, Result, formato de errores; en Zig: seguridad de memoria, estabilidad de punteros, conjuntos de error, concurrencia) y reportan hallazgos con fichero:línea y severidad;
• un panel de jueces intenta refutar cada hallazgo y dictamina la preparación;
• los hallazgos P0 y P1 pasan una verificación adicional.

Los flujos reutilizables están en .claude/workflows/ y se invocan con la habilidad adversarial-verification (el cruce completo de un nodo es gate-audit, parametrizable por nodo).

Pasadas AppSecCopiar enlace

La misma lógica gobierna las pasadas de seguridad: auditor sin permiso de edición, verificador distinto que intenta refutar, un arreglo por hallazgo con su prueba roja y verde, y un integrador distinto. El bucle sigue hasta que una pasada salga seca; si no ocurre, el informe lo dice (ver modelo de amenazas).

Qué es una evidencia válida de un gateCopiar enlace

Un item de gate no abierto exige, en su manifiesto de evidencia:

• el comando que se ejecutó y su salida, no un plan;
• un autor y un verificador distintos (comprobación mecánica);
• referencias a la evidencia: commits y artefactos en docs/<nodo>/evidence/.

La guarda comprueba presencia y forma. No garantiza la calidad: un manifiesto fabricado con dos nombres distintos pasaría. La barrera real es la verificación independiente de arriba.

Reglas de bolsilloCopiar enlace

• ¿La prueba ejercita el camino real? Si pasa saltándose la frontera, no cierra nada.
• ¿Quién la verificó? Debe ser otra persona o agente.
• ¿Hay mutante? Sin él, la prueba no ha demostrado que discrimina.
• ¿Se está declarando un contador de verdes? No se cuenta: se da un veredicto por item.
• ¿Se difiere algo? Se documenta, con ticket, y sin dejar roto el camino que se declara cerrado.