Traducción automática. El texto en inglés es la versión de referencia. English

Pruebas

Cualquiera puede decir que un bug está corregido. Esta página muestra la corrección, el test que la protege y la prueba de que el test falla cuando el bug vuelve.

Generado el 2026-10-03 a partir de tools/prove_regressions.py · 4 de 4 pruebas de regresión demostradas como no vacuas.

Cómo se genera cada prueba

  1. Ejecuta el test de regresión contra el código corregido: debe pasar.
  2. Edita el código fuente para reintroducir el bug original.
  3. Ejecuta de nuevo la misma prueba: debe fallar, con un fallo de aserción real. Un error de recolección no cuenta: significa que la prueba nunca se ejecutó.
  4. Restaura el archivo, verifica que su SHA-256 coincide con el original y vuelve a ejecutarlo: debe pasar de nuevo.

El asistente decía a los visitantes que el webhook transporta su conversación. No transporta nada de ella.

commit e027e6b · protegido por apps/gateway/tests/test_webhook_content_claim.py

Los payloads de los webhooks llevan deliberadamente solo la FORMA de un turno (nombre del evento, marca de tiempo, número de pasos, créditos) y nunca su contenido. Al preguntarle si los webhooks incluyen la conversación, el asistente respondió: 'Sí, cada payload de webhook incluye el historial completo de la conversación de ese turno.' Eso es exactamente lo contrario de la garantía contra la que se prueba la lista de permitidos. Medido: 2 invenciones en 6 ejecuciones antes de la corrección.

Código corregido, ejecuciones de tests SUPERADO 21 passed in 1.15s
Bug reintroducido, mismo test DETECTADO 8 failed, 13 passed in 1.20s
Archivo restaurado, el test se ejecuta SUPERADO sha256 a8d4cb0b10787eff…

El test no es vacuo: falla cuando el bug vuelve.

Dijimos a los propietarios que hicieran clic en una tarjeta del panel que no existe.

commit b4a203a · protegido por apps/gateway/tests/test_card_names.py

La base de conocimiento, la documentación y un mosaico de inicio indicaban a los propietarios que buscaran una tarjeta llamada 'Send turns to a webhook'. La tarjeta real del panel dice 'Send events to your own system'. El nombre se inventó al redactar la sección de conocimiento y se propagó a tres sitios sin comprobarse. Medido: 2 de 2 respuestas de configuración nombraban un control que nunca ha existido.

Código corregido, ejecuciones de tests SUPERADO 5 passed in 1.12s
Bug reintroducido, mismo test DETECTADO 3 failed, 2 passed in 1.23s
Archivo restaurado, el test se ejecuta SUPERADO sha256 f6348e1a5bbae209…

El test no es vacuo: falla cuando el bug vuelve.

El saludo en modo oscuro se mostraba con un contraste de 1.73:1, prácticamente invisible, y la comprobación no podría haberlo detectado.

commit ca47f41 · protegido por apps/studio/test/themeContrast.test.mjs

Encontrado a partir de una captura de pantalla hecha en un iPhone real, no con ningún test. El saludo de bienvenida tenía el color #3a3a3c fijado en el código, lo que da 1.73:1 sobre el panel en modo oscuro, muy por debajo del mínimo de 4.5:1 y apenas legible. Todos los visitantes nuevos en modo oscuro lo veían. La corrección hace pasar el color por la variable del tema --pw-mist para que siga al panel; la comprobación ahora calcula el ratio de contraste real de cada par del tema en lugar de dar por hecho que se había asignado un color.

Código corregido, ejecuciones de tests SUPERADO pass 5, fail 0
Bug reintroducido, mismo test DETECTADO pass 3, fail 2
Archivo restaurado, el test se ejecuta SUPERADO sha256 54f8802b444b6194…

El test no es vacuo: falla cuando el bug vuelve.

Un turno fallido dejaba al visitante esperando para siempre en un stream muerto.

commit 4bcc691 · protegido por apps/studio/test/streamError.test.mjs

Cuando la llamada al modelo falló, el servidor envió correctamente un frame de error, pero el widget escribió el mensaje en un elemento que la rama de la traza de gobernanza ya había ocultado, y nunca colapsó la traza. El visitante veía 'Leyendo tu mensaje' parpadeando indefinidamente en un turno que ya había fallado: sin error, sin recuperación, sin forma de saberlo. El texto del error se asignaba correctamente y no se pintaba en ningún sitio. Lo encontré durante una caída real, cuando la cuenta de la API se quedó sin crédito.

Código corregido, ejecuciones de tests SUPERADO pass 4, fail 0
Bug reintroducido, mismo test DETECTADO pass 2, fail 2
Archivo restaurado, el test se ejecuta SUPERADO sha256 54f8802b444b6194…

El test no es vacuo: falla cuando el bug vuelve.

Registro operativo

Lo que existe detrás de la plataforma y lo que no está probado. Solo lo que un script o un registro puede mostrar.

De docs/ops-record.json, escrito por el simulacro de restauración (docs/runbooks/db-backup.md).

Lo que esto no demuestra

Son comprobaciones que ejecuto yo mismo sobre mi propio código. Muestran que tests concretos detectan bugs concretos: no que el sistema esté libre de otros, no que las auditorías fueran exhaustivas, ni que alguien independiente lo haya revisado. El harness está en el repositorio; la afirmación se puede comprobar ejecutándolo.

PANTHEON · Demuéstralo, ataca el sistema en vivo · Registro de auditoría · Recorridos · Trabajo · CV