Fin de session — met à jour doc, changelog, CLAUDE.md, commit conventionnel et push.

Push — Commit et push de fin de session

Batch 1 — Collecter (tout en parallèle)

Bash : git status --short && echo "---DIFF---" && git diff --stat && echo "---CACHED---" && git diff --cached --stat
Bash : node -e "const p=require('path').join(process.env.TMPDIR||process.env.TMP||process.env.TEMP||'/tmp','codebloom-statusline','session.json');try{console.log(require('fs').readFileSync(p,'utf8'))}catch{console.log('NOT_FOUND')}"
Read : TODO.md (si existe)

Actions

1. Analyser

Utiliser les résultats du batch 1. Identifier les features ajoutées / modifiées / corrigées.

2. Gate agents — Pipeline bloquant avant commit

RÈGLE D'OR : aucun git add / git commit / git push n'est exécuté tant que tous les agents déclenchés n'ont pas terminé ET que les bloquants ne sont pas corrigés. Ce gate est non-négociable.

2a. Sélection des agents à lancer

Toujours (background parallèle) :

reviewer — review qualité, sécurité, footprint sur les fichiers modifiés
tester — exécuter les tests existants + vérifier les régressions

Conditionnellement (background parallèle, uniquement si le trigger correspond) :

Agent	Trigger à vérifier sur le diff	Raison à afficher
`security-auditor`	Diff matche un des patterns sensibles : `password`, `token`, `secret`, `api_key`, `auth`, `jwt`, `bcrypt`, `crypto`, `\.env`, `admin/`, `upload`, `login`, `session`, `cors`, `csp`, `sql`, `query.*user`	"zones sensibles touchées : [liste]"
`researcher`	Diff ajoute une entrée dans `package.json` (dependencies/devDependencies), `composer.json` (require), `requirements.txt`, `pyproject.toml` (dependencies), `Cargo.toml` (dependencies), `go.mod` (require), `Gemfile`	"nouvelle dépendance : [nom@version]"
`doc-writer`	Diff touche : nouveau fichier/dossier à la racine, nouveau script dans manifest, nouvelle commande dans `commands/`, nouvelle skill dans `skills/`, nouvel agent dans `agents/`, modification d'API publique (routes/)	"changements structurels détectés"
`git-historian`	Un des fichiers modifiés a ≥5 commits dans les 7 derniers jours (lancer `git log --since="7 days ago" --pretty=format: --name-only \| sort \| uniq -c \| sort -rn \| head -5` pour détecter)	"hotspot détecté : [fichier]"

Détection des triggers : exécuter en un seul Bash compact avant de lancer les agents, pour savoir lesquels activer.

2b. Annonce visible au lancement

Avant d'appeler Agent, afficher une ligne par agent activé :

🔍 **Pipeline gate** — agents lancés :
  ⏳ reviewer         — review qualité/sécurité/footprint
  ⏳ tester           — exécution tests et vérif régressions
  ⏳ security-auditor — zones sensibles touchées : auth/, session
  ⏳ researcher       — nouvelle dépendance : [email protected]

Si agent non lancé, ne pas l'afficher. L'utilisateur voit exactement ce qui tourne et pourquoi.

2c. Attente stricte

Attendre tous les agents lancés. Aucune action de commit avant. Pendant l'attente : ne rien écrire, ne rien modifier, juste attendre.

À la fin, afficher le statut de chacun :

✅ reviewer         — score 8.2/10, 2 suggestions
✅ tester           — 47/47 tests OK
⚠️ security-auditor — 1 medium : token en clair dans logs
✅ researcher       — [email protected] : maintenu, MIT, CVE-free

2d. Rapport agrégé unifié

Fusionner les rapports en un seul bloc compact classé par sévérité :

📋 **Rapport agrégé**

🔴 BLOQUANT :
- [source] [fichier:ligne] problème → fix proposé
- …

🟠 IMPORTANT :
- [source] [description] → [fix]
- …

🟡 SUGGESTIONS :
- [source] [description]
- …

📊 Score global : [X/10]

La colonne [source] indique l'agent à l'origine du finding (review, test, sec, audit, research, doc, hotspot).

2e. Fenêtre de correction — AVANT le commit

Trois cas :

🔴 Présence de bloquants → arrêt automatique. Appliquer les corrections immédiatement (bug critique, faille sécurité, test qui casse). Puis relancer les agents impactés par les corrections (boucle courte : corriger → relancer → vérifier). Ne jamais commiter avec un bloquant non résolu.
🟠 Points importants non bloquants → demander à l'utilisateur avant de continuer :
```
🟠 [N] points importants détectés :
[liste]

On corrige avant de push, ou on push quand même (ils seront ajoutés au TODO) ?
```
Attendre la réponse. corrige → appliquer les fixes, relancer les agents sur les corrections, boucler. push → continuer, capitaliser dans TODO (voir 2f).
🟡 Suggestions seules → continuer sans interruption, capitalisation directe dans TODO (voir 2f).

Règle stricte : le commit ne se fait qu'après que cette étape 2e soit terminée avec un état vérifié (pas de 🔴, décision utilisateur sur 🟠).

2f. Capitalisation dans TODO.md

Les findings non corrigés (🟡 et 🟠 que l'utilisateur a choisi de push) sont ajoutés à TODO.md sous ## À faire :

Format : - [ ] [source] [description courte] ([fichier:ligne] si applicable)
Sources : [review], [test], [sec], [audit], [doc], [research], [hotspot]
Anti-duplication : si une entrée avec le même [source] et description ≥80% similaire existe déjà, ne pas ré-ajouter
Max 10 entrées par agent par session — au-delà, agréger en une seule entrée "[source] 15+ suggestions, voir rapport complet"
Ne PAS ajouter les 🔴 — ils doivent être corrigés, pas reportés

3. Documentation

Lancer en parallèle :

Mettre à jour CHANGELOG.md — Format Keep a Changelog + convention Codebloom : 1 jour = 1 version, doublons éliminés.

Règle same-day (avant d'ajouter la nouvelle entrée) :
1. Lire la dernière entrée ## [x.y.z] — YYYY-MM-DD du fichier
2. Si la date correspond à aujourd'hui → fusionner dans cette entrée :
  - Remonter le numéro de version si la nouvelle est plus haute (ex: 1.5.0 → 1.5.1). Si la version cible est identique à celle déjà présente (ex: 2 pushs 1.5.1 le même jour), conserver le numéro tel quel — seule la liste d'items grossit.
  - Ajouter les nouveaux items aux sections ### Added / ### Changed / ### Fixed / ### Removed correspondantes
  - Éliminer les doublons intra-jour : si un item ### Fixed corrige un bug introduit par un item ### Added / ### Changed du même jour → supprimer les deux (l'état final est propre, pas besoin de raconter les zigzags)
  - Éliminer les annulations : si un item ### Removed / ### Changed annule un item ### Added / ### Changed du même jour → supprimer les deux (ex: ajouter X puis le retirer = ne rien mentionner)
  - Fusionner les corrections progressives : si deux items décrivent la même correction en 2 passes (ex: "Fix X dans A" puis "Alignement X dans B") → fusionner en une ligne unique mentionnant les deux fichiers
3. Si la date est antérieure → créer une nouvelle entrée ## [x.y.z] — YYYY-MM-DD en haut du fichier (sous [Unreleased] s'il existe)
La règle s'applique aussi à la section ## [Unreleased] : si deux items ajoutés dans la même session se contredisent, les consolider avant le push.

Créer CHANGELOG.md depuis ${CLAUDE_PLUGIN_ROOT}/references/CHANGELOG.md s'il n'existe pas.
CLAUDE.md health-check — voir étape 3b ci-dessous
Agent doc-writer (background) — synchroniser le reste de la doc (README, API_DOC, DESIGN_SYSTEM si impactés)

3b. CLAUDE.md — Health-check automatique

Objectif : garder le CLAUDE.md projet dense, à jour et sous le seuil de dilution sans intervention manuelle. Le check est rapide (pas d'agent background ici — exécution directe dans le flow /push).

Étape 1 — Compter et détecter :

wc -l CLAUDE.md → récupérer le nombre de lignes
grep -c '^##' CLAUDE.md → nombre de sections
grep -n '<!-- codebloom:rules:start' CLAUDE.md → présence du bloc rules
grep -n '<!-- codebloom:format:lean' CLAUDE.md → marqueur format lean

Étape 2 — Extraire les référents :

Chercher les commandes citées dans ## Commands (pattern \npm run \w+`/`composer \w+`/`make \w+`/`just \w+``)
Chercher les fichiers référencés par @FILE.md dans la section ## Project files
Chercher les chemins mentionnés dans le texte (src/, app/, lib/, etc. — best effort, pas exhaustif)

Étape 3 — Vérifier :

Check	Action
Taille ≤ 120 lignes	✅ OK
Taille 121-150 lignes	🟡 Signaler : "CLAUDE.md à 135 lignes — commence à être long. Rien de critique."
Taille 151-199 lignes	🟠 Warning : "CLAUDE.md à 178 lignes — risque de dilution des règles, pense à le slim manuellement"
Taille ≥ 200 lignes	🔴 Alerte forte : "CLAUDE.md à 215 lignes — les règles risquent d'être ignorées. Slim impératif : réduire sections Stack/Structure/Dépendances/Principes au minimum, déléguer le reste aux skills."
Commande citée absente du manifest	Auto-fix : retirer la ligne du CLAUDE.md
Import `@FILE.md` vers fichier inexistant	Auto-fix : retirer la ligne
Chemin `src/xxx/` mentionné mais absent	Ignorer (trop d'ambiguïté, risque de faux positif)
Bloc rules absent	Auto-fix : le laisser à `/codebloom:update` (pas le job de push) — juste signaler
Marqueur `format:lean` absent	Signaler : "CLAUDE.md pas encore migré vers le format lean — `/codebloom:update` pour migrer"

Étape 4 — Rapporter dans le récap final :

Ajouter une ligne dans le récap /push étape 8 :

Silence si tout est ✅
Ligne 📋 CLAUDE.md : X lignes [✅|🟡|🟠|🔴] [+ Y auto-fix appliqués] sinon

Principe : les auto-fix sont appliqués sans demander (conforme à la règle : "corriger automatiquement"). Les alertes de taille sont informatives, jamais bloquantes.

4. Enregistrer le temps

Source de durée (par priorité) :

Cache statusline (batch 1) → champ duration_ms. Source fiable.
Marqueur DEV_TIME.md (fallback) → > Session en cours depuis :, calcule maintenant − timestamp.
Absent → ignorer silencieusement.

Enregistrement dans DEV_TIME.md :

Format de durée canonique :
- < 60 min → {N}min (ex: 45min)
- ≥ 60 min et M == 0 → {H}h (ex: 1h, 2h)
- ≥ 60 min et M > 0 → {H}h{MM} avec minutes zero-paddées à 2 chiffres (ex: 1h05, 2h30)
Fusion same-day — regarde la dernière ligne du tableau (parser la date en colonne 2 au format YYYY-MM-DD) :
- Si date == aujourd'hui → merger en place :
  1. Parser la durée existante avec les regex strictes :
    - ^(\d+)min$ → minutes directes
    - ^(\d+)h$ → H * 60
    - ^(\d+)h(\d{2})$ → H * 60 + M
  2. Si le format existant ne matche aucune des 3 regex (édition manuelle de l'utilisateur : 90 min, 1h30m, 45) → abandonner le merge, ajouter une nouvelle ligne à la place. Ne jamais tenter de deviner.
  3. Additionner les minutes existantes + nouvelles, reformater avec le format canonique ci-dessus
  4. Concaténer les résumés : {ancien} + {nouveau}. Si le total dépasse ~120 caractères, raccourcir en gardant les préfixes conventionnels (feat:, fix:, refactor:, docs:, chore:, test:) au début et en tronquant les descriptions derrière
  5. Conserver le même numéro de ligne
- Sinon → nouvelle ligne : numéro = dernier + 1, date = aujourd'hui, durée formatée, résumé
Recalculer **Total : ...** en bas du fichier
Supprimer le marqueur > Session en cours depuis : ...
Fichier absent → le créer depuis ${CLAUDE_PLUGIN_ROOT}/references/DEV_TIME.md

Règle : max 1 ligne par jour par projet (fusion automatique). Le fallback "format inconnu → nouvelle ligne" garantit qu'on n'écrase jamais une édition manuelle de l'utilisateur.

5. Packaging WordPress (si applicable)

Détecte un projet WordPress via le skill wp-pack. Si détecté → re-zip avec bump (cache-busting CSS/JS). Sinon → passer.

6. Vérification cohérence versions (si `.version-bump.json` existe)

Lire .version-bump.json à la racine du projet. Ce fichier déclare les fichiers qui portent la version.

Pour chaque entrée dans files : lire le fichier au path et extraire la valeur au field (dotted path, ex: plugins.0.version)
Si claude_md est défini : lire le fichier au path et extraire la version après le pattern
Source de vérité : le premier fichier de la liste files
Désynchronisés → aligner tous les fichiers sur la source de vérité, signaler : "🔄 Versions alignées → v[X.Y.Z]"
Synchronisés → silence

7. Commit et Push

git add (code + doc)
Message conventionnel : feat: / fix: / refactor: / docs: / chore: / test:
git push
Si TODO.md modifié pendant la session → supprimer les tâches résolues (leur trace reste dans le CHANGELOG)

8. Récap

"✅ Push effectué

Commit : [message]
Fichiers : [nombre]
Session : [durée]
Review : [score /10] — [résumé]
Tests : [X passent / Y échouent]
CLAUDE.md : [ligne seulement si non-OK — omettre si ✅ silencieux]"

Règles

JAMAIS commiter : .env, node_modules, fichiers temp, clés API
Vérifie le .gitignore
Pas de remote → commit seul + prévenir
Conflits → prévenir, ne pas forcer
Gate agents bloquant — ne JAMAIS commiter tant que tous les agents lancés n'ont pas terminé ET que les 🔴 ne sont pas corrigés ET que l'utilisateur n'a pas tranché sur les 🟠. Le gate peut boucler (corriger → relancer → vérifier) plusieurs fois, c'est normal.

push