Prove

Chiunque può dire che un bug è stato corretto. Questa pagina mostra la correzione, il test che la protegge e la prova che il test fallisce quando il bug ritorna.

Generato il 2026-10-03 da tools/prove_regressions.py · 4 su 4 test di regressione dimostrati non vacui.

Come viene prodotta ogni prova

Esegui il test di regressione sul codice corretto: deve passare.
Modifica il sorgente per reintrodurre il bug originale.
Esegui di nuovo lo stesso test: deve fallire, con un vero fallimento di un'asserzione. Un errore di collection non conta: significa che il test non è mai stato eseguito.
Ripristina il file, verifica che il suo SHA-256 corrisponda all'originale e rieseguilo: deve passare di nuovo.

L'assistente diceva ai visitatori che il webhook trasporta la loro conversazione. Non ne trasporta nulla.

commit e027e6b · protetto da apps/gateway/tests/test_webhook_content_claim.py

I payload dei webhook trasportano deliberatamente solo la FORMA di un turno (nome dell'evento, timestamp, numero di step, crediti) e mai il suo contenuto. L'assistente, alla domanda se i webhook includano la conversazione, ha risposto 'Sì, ogni payload del webhook include l'intera cronologia della conversazione per quel turno.' È l'esatto opposto della garanzia su cui è testata l'allow-list. Misurato: 2 invenzioni su 6 esecuzioni prima della correzione.

Codice corretto, test eseguiti	PASS	`21 passed in 1.15s`
Bug reintrodotto, stesso test	INTERCETTATO	`8 failed, 13 passed in 1.20s`
File ripristinato, il test gira	PASS	`sha256 a8d4cb0b10787eff…`

Il test non è vacuo: fallisce quando il bug ritorna.

Abbiamo detto ai proprietari di cliccare su una scheda della dashboard che non esiste.

commit b4a203a · protetto da apps/gateway/tests/test_card_names.py

La knowledge base, la documentazione e un riquadro iniziale dicevano tutti ai proprietari di cercare una scheda chiamata 'Send turns to a webhook'. La scheda reale della dashboard si chiama 'Send events to your own system'. Il nome era stato inventato quando è stata scritta la sezione della knowledge base e si è propagato in tre punti senza verifiche. Misurato: 2 risposte di configurazione su 2 nominavano un controllo che non è mai esistito.

Codice corretto, test eseguiti	PASS	`5 passed in 1.12s`
Bug reintrodotto, stesso test	INTERCETTATO	`3 failed, 2 passed in 1.23s`
File ripristinato, il test gira	PASS	`sha256 f6348e1a5bbae209…`

Il test non è vacuo: fallisce quando il bug ritorna.

Il saluto in modalità scura veniva reso a 1.73:1, di fatto invisibile, e il controllo non avrebbe potuto rilevarlo.

commit ca47f41 · protetto da apps/studio/test/themeContrast.test.mjs

Scoperto da uno screenshot fatto su un vero iPhone, non da un test. Il saluto di benvenuto era fissato nel codice a #3a3a3c, che ha un contrasto di 1.73:1 rispetto al pannello in dark mode - molto sotto il minimo di 4.5:1 e appena leggibile. Ogni visitatore alla prima visita in dark mode lo vedeva. La correzione fa passare il colore attraverso la variabile del tema --pw-mist, così segue il pannello; il controllo ora calcola il rapporto di contrasto effettivo per ogni coppia tematizzata invece di fidarsi del fatto che un colore fosse impostato.

Codice corretto, test eseguiti	PASS	`pass 5, fail 0`
Bug reintrodotto, stesso test	INTERCETTATO	`pass 3, fail 2`
File ripristinato, il test gira	PASS	`sha256 54f8802b444b6194…`

Il test non è vacuo: fallisce quando il bug ritorna.

Un turno fallito lasciava il visitatore in attesa infinita su uno stream morto.

commit 4bcc691 · protetto da apps/studio/test/streamError.test.mjs

Quando la chiamata al modello falliva, il server inviava correttamente un frame di errore, ma il widget scriveva il messaggio in un elemento che il ramo della governance-trace aveva già nascosto, e non comprimeva mai la trace. Il visitatore vedeva 'Reading your message' pulsare all'infinito su un turno già fallito: nessun errore, nessun recupero, nessun modo di saperlo. Il testo dell'errore veniva assegnato correttamente e non veniva mostrato da nessuna parte. Trovato durante un'interruzione reale, quando il credito dell'account API si è esaurito.

Codice corretto, test eseguiti	PASS	`pass 4, fail 0`
Bug reintrodotto, stesso test	INTERCETTATO	`pass 2, fail 2`
File ripristinato, il test gira	PASS	`sha256 54f8802b444b6194…`

Il test non è vacuo: fallisce quando il bug ritorna.

Registro operativo

Cosa esiste dietro la piattaforma, e cosa non è testato. Solo ciò che uno script o un log può dimostrare.

Backup: notturni alle 03:17 UTC, pg_dump --clean --if-exists, gzip; inviati a un remote git privato dopo ogni esecuzione; ultimo 20261003T031701Z; 29 dump conservati.
Prova di ripristino 2026-10-03: dump 20261003T031701Z ripristinato in 2 s in un container usa e getta pgvector/pgvector:pg16 sullo stesso host: 34 tenant, 270 righe di conoscenza, 47 tabelle. Il dump è delle 03:17 UTC; alle 13:26 UTC la pulizia programmata delle demo ha rimosso un tenant demo abbandonato più vecchio di 30 giorni (log del gateway), quindi il ripristino mostra un tenant in più rispetto a quelli live al momento della prova.
Rollback: sito: tools/deploy-site.sh --rollback (un secondo cambio di symlink verso la release precedente); Studio: tools/deploy-studio.sh --rollback (immagine precedente, con health check).
Obiettivi di ripristino: nessuno promesso. Il dump notturno limita la perdita di dati a un giorno; nessun tempo di ripristino dichiarato.
Non testato: carico oltre una singola istanza; failover multi-regione; ripristino su un host diverso.

Da docs/ops-record.json, scritto dalla prova di ripristino (docs/runbooks/db-backup.md).

Cosa questo non dimostra

Sono controlli che eseguo io stesso sul mio codice. Mostrano che test specifici intercettano bug specifici: non che il sistema sia privo di altri, non che gli audit siano stati esaustivi, e non che qualcuno di indipendente lo abbia revisionato. L'harness è nel repository; l'affermazione è verificabile eseguendolo.

PANTHEON · Mettilo alla prova, attacca il sistema live · Registro di audit · Walkthrough · Lavori · CV