telemetry-leak-lab
Qué puede sobrevivir a la redacción de registros y trazas, y cómo comprobarlo sin perder la señal útil.
Explorar caso y demo ↗IX / LABORATORIO DE INGENIERÍA
La confianza merece
una prueba difícil.
Herramientas pequeñas para preguntas importantes. Exploro cómo demostrar que un sistema responde bien, especialmente cuando algo sale mal.
01 / FALSE-GREEN
Alfa pública · verificada localmentePruebas en verde.
¿Producto roto?
Un checkout. Cinco fallos deliberados. Dos maneras de verificar el mismo recorrido. El informe muestra por qué pasar una prueba no basta para confiar en lo que comprueba.
INFORME APORTADO / 18 SEP 2026
0/5fallos detectados · suite débil5/5fallos detectados · suite de comportamiento
Dos repeticiones por fase y controles sin fallos antes y después. Resultados del informe, no una nueva ejecución en esta web.
El mismo fallo. Distinta capacidad de detectarlo.
| Fallo introducido | Suite débil | Suite de comportamiento |
|---|---|---|
| El botón de compra no hace nada | No detectado | Detectado |
| La imagen no se puede decodificar | No detectado | Detectado |
| La información de envío desaparece | No detectado | Detectado |
| La confirmación cambia de significado | No detectado | Detectado |
| Se retira la etiqueta accesible explícita | No detectado | Detectado |
Qué demuestra y qué falta comprobar
El resultado describe sensibilidad a cinco fallos configurados. El 50 % agregado del informe combina dos suites deliberadamente distintas; no es una puntuación de calidad o cobertura del producto. Un fallo no aplicado no cuenta como detectado ni como superviviente.
La alfa se recuperó y verificó el 19 de septiembre de 2026: instalación limpia, 71 pruebas unitarias, 18 de navegador offline y 20 HTTP aprobadas en Windows con Node 24.15.0, Playwright Core 1.56.1 y Chromium 141.0.7390.37. La demo volvió a reproducir el contraste mostrado. La validación local no equivale a compatibilidad universal ni a una auditoría independiente de seguridad. Consulta en el repositorio el estado separado de CI.
02 / HEALTH-INTEROP-LAB
Del mensaje al
sistema conectado.
Un laboratorio de interoperabilidad clínica ya documentado en el portafolio. Ahora incluye un recorrido reproducible Angular → HTTP → gRPC, con datos sintéticos y estados desconocidos explícitos.
Leer el caso existente ↗HERRAMIENTAS PÚBLICAS / EXPERIMENTOS DE SEGURIDAD
tenant-fence
Una pregunta de negocio, convertida en una prueba: ¿puede una organización leer los datos de otra?
Explorar caso y demo ↗03 / AGENDA ABIERTA
Las preguntas
que siguen.
Seis propuestas por construir y validar. Nombres de trabajo; no son productos disponibles ni compromisos de entrega.
evidence-contract
Contratos para distinguir hechos, estimaciones e hipótesis antes de publicar.
clinical-chaos
Escenarios sintéticos adversos para integraciones de salud.
rules-replay
Comparación explicable de decisiones entre versiones de reglas.
route-atlas
Contrastar rutas declaradas, enlaces y recorridos observados por rol.
money-invariants
Propiedades de idempotencia, totales y redondeo con dinero ficticio.
mcp-failure-lab
Errores y reintentos de herramientas de agentes sin efectos reales.
CRITERIO DE PUBLICACIÓN
Que otra persona
pueda comprobarlo.
Código legible, instalación reproducible, ejemplos sintéticos y límites claros. Cada herramienta tendrá su repositorio cuando esté lista para ponerse a prueba.
Mi perfil en GitHub ↗DEL EXPERIMENTO A LA DECISIÓN
Decide qué límite revisar primero.
El diagnóstico técnico y estratégico convierte una pregunta acotada en un mapa del sistema, hallazgos priorizados y una ruta ejecutable. El alcance y los accesos se acuerdan antes de trabajar.
Preparar mi diagnóstico ↗