Come lavoriamo.

• —Una lacuna strutturale blocca la build: un'affermazione senza fonte, ambito, responsabile o data non può essere pubblicata.
• —Le date devono avere gli zeri iniziali: uno zero mancante (2026-9-18) impedirebbe la scadenza di un'affermazione fino al cambio d'anno.
• —La scadenza NON blocca la build: cambia la pagina. Un'affermazione scaduta non è falsa, ma non verificata; non viene eliminata e appare in attesa di nuova verifica.
• —Una scheda statistica non può mostrare una cifra assente dall'affermazione a cui rimanda.
• —Un prodotto non ancora pubblicato non può mostrare schermate inventate; ogni schermata riporta versione di origine e data di acquisizione.
• —Un controllo dei testi cerca per nome 12 affermazioni rivelatesi false in passato e ne impedisce il ritorno.
• —Regola per i casi di studio: senza autorizzazione, situazione iniziale, artefatto, risultato misurato, lezione dal fallimento e data di validità, nessun caso viene pubblicato.

• —Quando i nuovi invii di contatto sono disattivati, l'endpoint del modulo restituisce 503. L'invio delle notifiche già accettate dipende da configurazione e-mail ed esecuzione del worker della coda; chiudere i nuovi invii non annulla le e-mail in attesa.
• —Il consenso non è una semplice casella, ma una registrazione separata con la versione datata dell'informativa: sapere che una persona ha accettato non dice cosa abbia accettato.
• —La misurazione del percorso degli utenti rifiuta il testo libero: i valori ammessi sono limitati e i parametri delle query vengono rimossi dai percorsi delle pagine. I dati grezzi hanno un periodo di conservazione di 30 giorni e un processo elimina quelli scaduti; l'effettiva cancellazione in produzione viene confermata dai registri di esecuzione.
• —Le richieste sui dati prevedono la verifica dell'indirizzo e-mail. Verificare l'indirizzo non significa aver soddisfatto una richiesta di accesso, rettifica o cancellazione.
• —Il sito usa una CSP che limita le fonti dei contenuti e intestazioni che impediscono ad altri siti di incorporarlo in frame. Le pagine generali e la verifica e-mail adottano regole CSP diverse.

• —Decisioni del fondatore: invii agli store, prezzi, denaro reale, proprietà degli account, questioni legali e decisioni irreversibili spettano solo a una persona.
• —Il lavoro su sicurezza, pagamenti, migrazioni e privacy richiede una revisione indipendente prima dell'accettazione; nessuno approva il proprio lavoro. Le revisioni respingono davvero: il registro contiene cicli rifiutati più di una volta.
• —“Finito” non è una percentuale: il lavoro termina solo allo stato ACCEPTED, raggiungibile soltanto con una riga di prova.
• —I passaggi che richiedono una persona, un dispositivo o una scadenza sono registrati come EXTERNAL GATES, indicando esplicitamente azione richiesta e prova del completamento.

• !Il controllo dei testi viene eseguito a ogni build, ma i riferimenti tra repository esistono solo localmente e in CI: il deploy che serve questa pagina ne esegue una versione più limitata.
• !Un caso di studio non fornisce il proprio numero: specifica quale cifra verificata di un'affermazione del registro riporta, e il numero visualizzato viene letto dal registro. La stessa regola vale per titolo, etichetta della metrica e sezione “cosa è cambiato dopo”, perché sono affermazioni. Situazione iniziale, vincoli, decisioni, etichette degli artefatti, ambito del permesso e lezione dal fallimento restano testo libero: lì un numero è normale. Limite noto: una stringa simile a un identificativo, come “Accuracy-95”, è accettata come etichetta.
• !Le pagine prodotto usano date di verifica per store e disponibilità; le dichiarazioni di disponibilità scadute mostrano un avviso di nuova verifica. Il periodo di verifica è terminato per 5 superfici registrate. Il controllo non copre ogni testo promozionale.
• !La raggiungibilità dei link non blocca la CI: un URL di store non funzionante genera un avviso, non interrompe la pipeline.
• !La CI comprende lint, controllo dei tipi, test, build e verifiche delle dipendenze. I risultati vanno valutati rispetto alla modifica e al registro di esecuzione; i controlli locali non dimostrano un rilascio in produzione.
• !La configurazione di deploy predefinita pianifica il processo e-mail una volta al giorno. Non è un impegno sui tempi di consegna: l'invio dipende da configurazione, fornitore ed esecuzione riuscita del processo.

Correlato: trasparenza dei prodotti · casi di studio