silent-failure-catalog

# Catálogo de Fallos Silenciosos (Silent Failure Catalog) Este es un catálogo sistemático que recopila patrones de fallo en los que **la validación parece superarse pero en realidad no comprueba nada**. Se centra en problemas de "falso verde" o "brechas de validación" en puertas de CI, suites de pruebas, canalizaciones de datos y cadenas de herramientas de agentes de IA. ## El problema central > "Una prueba que siempre pasa es peor que no tener prueba. Parece que hay cobertura, pero en realidad no hay ninguna garantía." Un fallo catastrófico se anuncia por sí mismo, pero un fallo silencioso no. La página carga con normalidad, el DOI se resuelve con normalidad, la canalización imprime `PASS` con normalidad, el agente informa de progreso con normalidad —**nada está en rojo, y nada es correcto**. La característica común de estos fallos es que el sistema carece de una señal de que "lo que debería haber ocurrido no ocurrió". Los estados ausentes, vacíos, omitidos, no contabilizados y mal atribuidos terminan todos presentándose como **éxito**. ## Estructura del catálogo Este catálogo contiene **14 patrones de fallo silencioso con nombre propio**, agrupados en cinco familias: - **A · Verificación vacua (Vacuous Verification)**: la comprobación se ejecuta, pero no tiene poder discriminante (SF-001 a SF-004) - **B · Ausencia no contabilizada (Uncounted Absence)**: falta un elemento obligatorio, pero la ausencia no cuenta como fallo (SF-005 a SF-007) - **C · Evidencia incorrecta (Wrong Evidence)**: la señal utilizada no puede demostrar la conclusión obtenida (SF-008 a SF-010) - **D · Oráculo a la deriva (Drifting Oracle)**: la propia comprobación se degrada —exenciones, coincidencia de subcadenas, atribución errónea (SF-011 a SF-012) - **E · Proceso y entorno (Process & Environment)**: el fallo reside fuera de la lógica —artefactos obsoletos, procesos zombis (SF-013 a SF-014) Cada entrada sigue una estructura uniforme de seis partes: **síntoma → por qué es silencioso → reproducción mínima → autoverificación → solución → relacionados**. ## Causa raíz común Todas las familias son, en esencia, la misma deficiencia manifestada en distintos niveles: > **Tomar "la ausencia de evidencia" como evidencia de "la ausencia de problemas".** De aquí se derivan dos reglas prácticas fundamentales: 1. **La ausencia debe reflejarse en el código de salida** —si "lo que debería estar no está" solo se registra como log, marcador neutro u omisión, siempre producirá `exit 0`, y la puerta de control queda ciega justo en el punto más crítico. 2. **Sin control negativo no hay evidencia** —una comprobación que nunca se ha observado fallar no ha demostrado que pueda fallar. Toda conclusión negativa necesita un control positivo. ## Inicio rápido ```bash git clone https://github.com/zhaoxinghua09-cell/silent-failure-catalog.git cd silent-failure-catalog # Comprueba tus scripts de puerta/validador/auditoría en los que confías python tools/gate-lint.py path/to/your_gate.py # Verifica la coherencia interna del propio catálogo python tools/check-catalog.py ``` Ambos scripts son implementaciones de **biblioteca estándar pura** —sin instalación, sin conexión a red, con Python 3.9+ es suficiente. ## Verificador propio (gate-lint.py) Esta herramienta puede escanear tus propios scripts de puerta e identificar estos patrones de fallo silencioso, por ejemplo: - `SFL-001 no-nonzero-exit`: no hay ningún `exit()`/`raise`/`assert` en el archivo, no puede fallar - `SFL-002 swallow-exception`: el bloque `except` solo ejecuta `pass` - `SFL-003 unchecked-empty`: los valores vacíos/falsos se tratan como normales - `SFL-004 counter-does-not-gate-exit`: el contador nunca afecta al código de salida - `SFL-005 zero-item-pass`: se invoca el ejecutor de pruebas pero nunca se protege contra "0 elementos recopilados" - `SFL-006 no-negative-control`: no se detectan muestras de control negativo, no se puede demostrar que la comprobación pueda fallar Los hallazgos de baja severidad se **marcan explícitamente como degradados en la salida**, en lugar de descartarse silenciosamente —porque el descarte silencioso es precisamente el fallo que documenta este catálogo. Usa `--strict` para elevar los hallazgos de bajo nivel a salida distinta de cero. ## Integridad del contenido `INTEGRITY.md` y `manifest.sha256` registran el resumen SHA-256 de cada archivo y proporcionan un resumen de conjunto, para que el lector pueda confirmar que posee exactamente los mismos bytes que describe esta página. `tools/make-manifest.py --check` devuelve un código de salida 1 ante cualquier deriva. CI exige regenerar el manifiesto al modificar archivos de contenido, y corrompe deliberadamente un byte para verificar que la comprobación efectivamente puede fallar. ## Contribuciones Se aceptan nuevas entradas siempre que puedas proporcionar una **reproducción** y un **control negativo** —un informe de incidente por sí solo no es suficiente, porque no puede comprobarse mecánicamente. ## Licencia Este repositorio utiliza una licencia por capas: **el código es MIT**, **el contenido se reserva todos los derechos** (se puede citar indicando la procedencia).