Preuves

N'importe qui peut affirmer qu'un bug est corrigé. Cette page montre le correctif, le test qui le protège, et la preuve que le test échoue quand le bug revient.

Généré le 2026-10-03 à partir de tools/prove_regressions.py · 4 sur 4 tests de régression dont la non-vacuité est prouvée.

Comment chaque preuve est produite

Lancer le test de régression sur le code corrigé : il doit passer.
Modifier le code source pour réintroduire le bug d'origine.
Relancez le même test : il doit échouer, avec un véritable échec d'assertion. Une erreur de collecte ne compte pas : elle signifie que le test ne s'est jamais exécuté.
Restaurez le fichier, vérifiez que son SHA-256 correspond à l'original, puis relancez : il doit de nouveau réussir.

L'assistant disait aux visiteurs que le webhook transporte leur conversation. Il n'en transporte rien.

commit e027e6b · protégé par apps/gateway/tests/test_webhook_content_claim.py

Les payloads de webhook ne transportent délibérément que la FORME d'un tour : nom d'événement, horodatage, nombre d'étapes, crédits, et jamais son contenu. L'assistant, interrogé sur la présence de la conversation dans les webhooks, a répondu « Oui : chaque payload de webhook inclut l'historique complet de la conversation pour ce tour. » C'est l'exact opposé de la garantie contre laquelle l'allow-list est testée. Mesuré à 2 inventions sur 6 exécutions avant le correctif.

Code corrigé, tests exécutés	RÉUSSI	`21 passed in 1.15s`
Bug réintroduit, même test	INTERCEPTÉ	`8 failed, 13 passed in 1.20s`
Fichier restauré, le test s'exécute	RÉUSSI	`sha256 a8d4cb0b10787eff…`

Le test n'est pas creux : il échoue quand le bug revient.

Nous avons dit aux propriétaires de cliquer sur une carte du tableau de bord qui n'existe pas.

commit b4a203a · protégé par apps/gateway/tests/test_card_names.py

La base de connaissances, la documentation et une tuile de démarrage disaient toutes aux propriétaires de chercher une carte nommée « Send turns to a webhook ». La vraie carte du tableau de bord s'intitule « Send events to your own system ». Le nom a été inventé lors de la rédaction de la section de connaissances et s'est propagé à trois endroits sans vérification. Mesuré : 2 réponses de configuration sur 2 citaient un contrôle qui n'a jamais existé.

Code corrigé, tests exécutés	RÉUSSI	`5 passed in 1.12s`
Bug réintroduit, même test	INTERCEPTÉ	`3 failed, 2 passed in 1.23s`
Fichier restauré, le test s'exécute	RÉUSSI	`sha256 f6348e1a5bbae209…`

Le test n'est pas creux : il échoue quand le bug revient.

Le message d'accueil en mode sombre s'affichait avec un contraste de 1.73:1, pratiquement invisible, et le garde-fou n'aurait pas pu le détecter.

commit ca47f41 · protégé par apps/studio/test/themeContrast.test.mjs

Trouvé à partir d'une capture d'écran prise sur un vrai iPhone, pas par un test. Le message d'accueil était codé en dur en #3a3a3c, ce qui donne 1.73:1 contre le panneau en mode sombre, bien en dessous du minimum de 4.5:1 et à peine lisible. Tous les nouveaux visiteurs en mode sombre l'ont vu. Le correctif fait passer la couleur par la variable de thème --pw-mist pour qu'elle suive le panneau ; le garde-fou calcule désormais le vrai ratio de contraste pour chaque paire thématisée au lieu de se fier au fait qu'une couleur a été définie.

Code corrigé, tests exécutés	RÉUSSI	`pass 5, fail 0`
Bug réintroduit, même test	INTERCEPTÉ	`pass 3, fail 2`
Fichier restauré, le test s'exécute	RÉUSSI	`sha256 54f8802b444b6194…`

Le test n'est pas creux : il échoue quand le bug revient.

Un tour échoué laissait le visiteur attendre indéfiniment sur un flux mort.

commit 4bcc691 · protégé par apps/studio/test/streamError.test.mjs

Quand l'appel au modèle a échoué, le serveur a correctement envoyé une trame d'erreur, mais le widget a écrit le message dans un élément que la branche de trace de gouvernance avait déjà masqué, et n'a jamais replié la trace. Le visiteur voyait « Lecture de votre message » clignoter indéfiniment sur un tour qui avait déjà échoué : aucune erreur, aucune reprise, aucun moyen de le savoir. Le texte d'erreur était correctement assigné et affiché nulle part. Trouvé pendant une vraie panne, quand le compte API s'est retrouvé à court de crédit.

Code corrigé, tests exécutés	RÉUSSI	`pass 4, fail 0`
Bug réintroduit, même test	INTERCEPTÉ	`pass 2, fail 2`
Fichier restauré, le test s'exécute	RÉUSSI	`sha256 54f8802b444b6194…`

Le test n'est pas creux : il échoue quand le bug revient.

Registre opérationnel

Ce qui existe derrière la plateforme, et ce qui n'est pas testé. Uniquement ce qu'un script ou un journal peut montrer.

Sauvegardes : chaque nuit à 03:17 UTC, pg_dump --clean --if-exists, gzip ; poussées vers un dépôt git distant privé après chaque exécution ; dernière : 20261003T031701Z ; 29 dumps conservés.
Exercice de restauration 2026-10-03 : le dump 20261003T031701Z a été restauré en 2 s dans un conteneur jetable pgvector/pgvector:pg16 sur le même hôte : 34 locataires, 270 lignes de connaissances, 47 tables. Le dump date de 03:17 UTC ; à 13:26 UTC, le nettoyage programmé des démos a supprimé un locataire de démo abandonné vieux de plus de 30 jours (journal de la passerelle), donc la restauration montre un locataire de plus que la production au moment de l'exercice.
Retour arrière : site : tools/deploy-site.sh --rollback (un second basculement de lien symbolique vers la version précédente) ; Studio : tools/deploy-studio.sh --rollback (image précédente, avec contrôle de santé).
Objectifs de reprise : aucun n'est promis. Le dump nocturne limite la perte de données à une journée ; aucun délai de restauration annoncé.
Non testé : charge au-delà d'une instance ; basculement multi-région ; restauration sur un autre hôte.

Extrait de docs/ops-record.json, écrit par l'exercice de restauration (docs/runbooks/db-backup.md).

Ce que cela ne prouve pas

Ce sont des vérifications que j'exécute moi-même sur mon propre code. Elles montrent que des tests précis détectent des bugs précis, pas que le système est exempt d'autres bugs, pas que les audits étaient exhaustifs, et pas que quiconque d'indépendant l'a examiné. Le harnais est dans le dépôt ; l'affirmation est vérifiable en l'exécutant.

PANTHEON · Prouvez-le, attaquez le système en production · Registre d'audit · Démonstrations commentées · Réalisations · CV