/push

Push — Commit et push de fin de session

Batch 1 — Collecter (tout en parallèle)

1. Bash : git status --short && echo "---DIFF---" && git diff --stat && echo "---CACHED---" && git diff --cached --stat
2. 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')}"
3. 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, attente, statut

Avant d'appeler Agent, afficher une ligne par agent activé (agents non lancés : ne pas les afficher — l'utilisateur voit exactement ce qui tourne et pourquoi) :

🔍 **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]

Attendre tous les agents lancés. Aucune action de commit avant ; pendant l'attente, ne rien écrire ni modifier. À la fin, repasser chaque ligne en ✅/⚠️ avec un résumé court (✅ tester — 47/47 tests OK, ⚠️ security-auditor — 1 medium : token en clair dans logs).

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, sec, audit, research, doc, hotspot). Les findings du tester ne portent pas de source capitalisable : un bloquant 🔴 doit être corrigé, une zone non couverte doit voir son test écrit avant commit, le reste reste dans le rapport.

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

Trois cas :

1. 🔴 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.

2. 🟠 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).

3. 🟡 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], [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
• Pas de [test] — les findings du tester ne vont jamais dans TODO.md : soit le test est écrit avant commit, soit la limite (env externe, QA manuelle) reste mentionnée dans le rapport de session

3. Documentation

Lancer en parallèle :

• Mettre à jour CHANGELOG.md — suivre ${CLAUDE_PLUGIN_ROOT}/references/procedures/changelog-merge.md (Keep a Changelog + convention Codebloom : 1 jour = 1 version, doublons éliminés, règle same-day).
• Health-check CLAUDE.md — suivre ${CLAUDE_PLUGIN_ROOT}/references/procedures/claude-md-healthcheck.md (mode push : alertes de taille + auto-fix des références mortes ; jamais bloquant). Reporter dans le récap étape 8 si non-✅.
• Agent doc-writer (background) — synchroniser le reste de la doc (README, DOCS.md, DESIGN.md si impactés).

4. Enregistrer le temps

Suivre ${CLAUDE_PLUGIN_ROOT}/references/procedures/time-merge.md : source de durée (cache statusline > marqueur TIME.md > rien), format canonique, fusion same-day, recalcul du total, suppression du marqueur > Session en cours depuis :.

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.