Audit — Chantier d'audit complet

Parsing des arguments

$ARGUMENTS détermine le scope :

Argument	Exemple	Scope
(vide) ou full	/codebloom:audit	Tout le projet
Chemin (contient / ou \ ou .)	/codebloom:audit src/api	Dossier ou fichier ciblé
Mot-clé	/codebloom:audit auth	Fichiers liés à cette feature (grep + glob)

Si l'argument est un chemin, vérifier qu'il existe. Sinon → "❌ [path] introuvable."

Exécution

Batch 1 — Collecter le contexte (parallèle)

1. Read : CLAUDE.md (si pas déjà en contexte)
2. Bash : git log --oneline -10 (activité récente)
3. Si scope = mot-clé → Grep pour identifier les fichiers concernés

Batch 2 — Lancer les 4 agents (tous en parallèle, tous en background)

Chaque agent reçoit le scope dans son prompt. Si le scope est un dossier ou une feature, chaque agent doit limiter son analyse à ce périmètre.

Agent 1 — auditor (santé globale)

Audit de santé du projet. Scope : [scope].
Couvre les 9 axes : dépendances, architecture, dead code, sécurité, qualité, tests, documentation, config, performance.
Si le scope est limité, concentre-toi sur les axes pertinents pour ce périmètre.

Agent 2 — reviewer (qualité + bugs + dead code)

Review approfondie en mode audit. Scope : [scope].
Focus particulier sur :
- Dead code : imports inutilisés, fonctions mortes, variables non lues, code commenté
- Valeurs hardcodées : URLs, ports, magic strings, couleurs hex répétées
- Bugs potentiels : logique inversée, edge cases non gérés, null safety
- Simplicité : sur-engineering, abstractions inutiles, code qui pourrait être simplifié
- Optimisation : boucles inutiles, N+1, re-renders, gros imports

Pas de diff — analyse tout le code dans le scope.
Utilise `git log --oneline -5 -- [fichiers]` pour le contexte.

Agent 3 — security-auditor (sécurité)

Scan de sécurité complet. Scope : [scope].
Si le scope est limité, vérifie aussi les fichiers de config globaux (.env, .gitignore, headers).

Agent 4 — tester (tests)

Audit des tests. Scope : [scope].
Ne génère PAS de nouveaux tests. Analyse uniquement :
- Tests existants : passent-ils ? Couverture ? Pertinence ?
- Test gaps : quelles zones critiques ne sont pas testées ?
- Tests fragiles : dépendances d'ordre, mocks excessifs, assertions faibles
- Framework : est-il bien configuré ?
Rapport uniquement — pas de création de fichiers.

Batch 3 — Consolider (après retour des 4 agents)

Attendre les 4 rapports, puis produire le rapport consolidé.

Format du rapport consolidé

🏥 **Audit complet — [Nom du projet]** [scope si limité]

## Scores

| Axe | Agent | Score | Verdict |
|-----|-------|-------|---------|
| Santé globale | auditor | X/10 | 🟢🟡🔴 |
| Qualité code | reviewer | X/10 | 🟢🟡🔴 |
| Sécurité | security-auditor | X/100 (Grade) | 🟢🟡🔴 |
| Tests | tester | X/Y passent | 🟢🟡🔴 |

## 🔴 Critiques (action immédiate)
[Findings critiques de tous les agents, dédupliqués, triés par impact]

## 🟠 Importants
[Findings importants, groupés par thème]

## 🟡 Suggestions
[Améliorations recommandées, groupées par thème]

## ✅ Points forts
[Ce qui va bien — important pour le moral]

## 📋 Plan d'action
[Top 5 actions prioritaires, ordonnées par impact/effort]

Dédoublonnage

Les agents ont des recouvrements (sécurité dans auditor + security-auditor, qualité dans auditor + reviewer). Lors de la consolidation :

• Fusionner les findings identiques → garder la version la plus détaillée
• Si deux agents divergent sur la sévérité → garder la plus haute
• Citer l'agent source entre parenthèses

Capitalisation dans TODO.md

Ajouter les findings 🔴 et 🟠 dans TODO.md sous ## Bugs (si bug) ou ## À faire (si amélioration) :

• Format : - [ ] [audit] [description] ([fichier:ligne])
• Ne pas dupliquer si une entrée similaire existe déjà
• Les 🟡 ne vont PAS dans TODO (trop de bruit)

Batch 4 — Proposer les corrections (après validation utilisateur)

Après affichage du rapport, demander :

On corrige ? Tu peux répondre :

• oui / all — corriger tous les 🔴 et 🟠
• 🔴 — corriger uniquement les critiques
• 1, 3, 5 — corriger des findings spécifiques par numéro
• non — garder le rapport tel quel

Si l'utilisateur accepte :

1. Numéroter chaque finding dans le rapport (🔴 puis 🟠) pour référence
2. Appliquer les corrections sélectionnées séquentiellement (un fichier à la fois, vérifier que chaque edit compile/fonctionne avant le suivant)
3. Pour chaque correction :
   • Montrer le diff avant d'appliquer (ancien → nouveau)
   • Appliquer l'edit
   • Cocher le finding dans TODO.md si il y avait été ajouté
4. Après toutes les corrections, relancer les agents concernés uniquement sur les fichiers modifiés pour valider qu'aucune régression n'a été introduite
5. Récap final :

✅ **Corrections appliquées**

| # | Finding | Fichier | Statut |
|---|---------|---------|--------|
| 1 | [description] | [fichier:ligne] | ✅ corrigé |
| 3 | [description] | [fichier:ligne] | ✅ corrigé |
| 5 | [description] | [fichier:ligne] | ⚠️ correction partielle — [raison] |

🔄 **Validation post-correction :** [résultat des agents de vérification]

Si l'utilisateur refuse : ne rien modifier. Le rapport et le TODO.md suffisent.

Règles

• Audit = read-only — les agents d'audit ne modifient rien. Seul le batch 4 (après accord utilisateur) écrit dans le code
• Factuel — chaque finding doit citer un fichier et une ligne. Pas d'observation vague
• Pas de faux positifs — en cas de doute, ne pas reporter. Un audit crédible > un audit exhaustif
• Scope respecté — si l'utilisateur cible un dossier, ne pas déborder sur tout le projet (sauf config globale pour la sécurité)
• Bref — le rapport consolidé est un résumé exécutif. Les détails sont dans les rapports individuels des agents
• Corrections prudentes — ne jamais corriger sans montrer le diff. En cas de doute sur une correction (risque de régression, logique métier ambiguë), signaler plutôt que corriger