@yonathan124/zentry 1.0.0

package/src/config/constants.js

@@ -0,0 +1,1232 @@
+export const STACKS={
+  "njs-supa":{label:"Next.js + Supabase",tag:"Next·Supabase",db:"Supabase (PostgreSQL+RLS)",auth:"Supabase Auth",adapt:null,
+    sec:["RLS activé sur toutes les tables (auth.uid()=user_id)","SERVICE_ROLE_KEY : serveur uniquement","Politiques SELECT/INSERT/UPDATE/DELETE séparées","NEXT_PUBLIC_ sans données sensibles"],
+    perf:["Server Components pour les données statiques","Supabase realtime : désabonner dans useEffect cleanup","Edge Functions pour la logique proche des données","select() avec colonnes explicites, jamais *"],
+    rules:"## SUPABASE\n- SERVICE_ROLE_KEY : serveur UNIQUEMENT\n- auth.uid() dans TOUTES les politiques RLS\n- rpc() pour transactions multi-tables\n- .single() au lieu de .limit(1) pour assertions"},
+  "njs-prisma":{label:"Next.js + Prisma",tag:"Next·Prisma",db:"PostgreSQL via Prisma",auth:"NextAuth.js / Lucia",
+    adapt:"• RLS → where:{userId:session.user.id} sur chaque requête\n• auth.uid() → session.user.id (getServerSession)\n• rawQuery interdit avec variables interpolées\n• findUnique au lieu de findFirst pour les assertions",
+    sec:["Chaque requête filtrée par userId de session","findMany({}) interdit sans filtre","rawQuery interdit avec interpolation","select explicite, no include profond"],
+    perf:["Prisma.$transaction pour opérations multiples","select:{} pour limiter les colonnes retournées","Pagination obligatoire avec take+skip ou cursor","Index dans schema.prisma sur colonnes filtrées"],
+    rules:"## PRISMA\n- TOUJOURS : where:{userId:session.user.id}\n- select:{} explicite sur chaque query\n- $transaction pour les opérations atomiques"},
+  "node-express":{label:"Node.js / Express",tag:"Node·Express",db:"PostgreSQL (pg/knex)",auth:"JWT / Passport.js",
+    adapt:"• helmet→cors→rateLimit→authJwt→routes (ordre obligatoire)\n• req.user.id depuis JWT vérifié, jamais req.body\n• SQL : paramètres positionnels $1,$2 uniquement",
+    sec:["Ordre middleware : helmet→cors→rateLimit→authJwt→routes","JWT_SECRET en env, longueur ≥ 32 chars","SQL $1,$2 positionnels","res.json(error) interdit"],
+    perf:["Connection pooling pg.Pool avec max adapté","Async/await partout, pas de callbacks","Compression middleware pour les réponses > 1kb","Cache Redis pour les données fréquentes"],
+    rules:"## NODE/EXPRESS\n- Ordre : helmet→cors→rateLimit→verifyJWT→routes\n- Connection pool configuré\n- Jamais de blocking I/O dans le thread principal"},
+  "django":{label:"Django + PostgreSQL",tag:"Django·DRF",db:"PostgreSQL via Django ORM",auth:"Django Auth/DRF",
+    adapt:"• queryset.filter(user=request.user) sur tout\n• CSRF middleware actif partout\n• raw() interdit avec variables\n• select_related/prefetch_related pour éviter N+1",
+    sec:["queryset.filter(user=request.user) partout","CSRF actif","ORM uniquement","SECRET_KEY en env"],
+    perf:["select_related() pour FK, prefetch_related() pour M2M","only()/defer() pour limiter les colonnes","Cache avec django.core.cache","Pagination avec DRF PageNumberPagination"],
+    rules:"## DJANGO\n- TOUJOURS : queryset.filter(user=request.user)\n- select_related/prefetch_related pour éviter N+1\n- only() pour limiter les colonnes retournées"},
+  "fastapi":{label:"FastAPI + PostgreSQL",tag:"FastAPI·SQLAlchemy",db:"PostgreSQL via SQLAlchemy",auth:"JWT/OAuth2",
+    adapt:"• Depends(get_current_user) EN PREMIER sur toutes routes\n• Pydantic BaseModel strict sur tous inputs\n• CORS origins explicites, jamais wildcard *\n• async def sur toutes les routes I/O-bound",
+    sec:["Depends(get_current_user) en premier","Pydantic strict","CORS origins explicites","SQL paramètres SQLAlchemy"],
+    perf:["async def sur routes I/O-bound","Connection pool asyncpg avec pool_size adapté","Pydantic response_model pour filtrer les champs","Background tasks pour opérations longues"],
+    rules:"## FASTAPI\n- Toute route protégée : Depends(get_current_user) EN PREMIER\n- async def sur toutes les routes qui font I/O\n- response_model sur chaque endpoint"},
+  "react-native":{label:"React Native + Expo",tag:"RN·Expo",db:"Supabase/Firebase",auth:"Supabase Auth",
+    adapt:"• localStorage → Expo SecureStore uniquement\n• AsyncStorage pour tokens = INTERDIT\n• Certificate pinning sur endpoints critiques\n• Code push : valider côté serveur les versions autorisées",
+    sec:["Expo SecureStore pour tokens","Clés API hors bundle","Security Rules testées","Certificate pinning"],
+    perf:["FlatList avec getItemLayout pour les grandes listes","React.memo sur les composants de liste","Hermes engine activé","expo-image au lieu de Image pour le cache"],
+    rules:"## REACT NATIVE\n- Expo SecureStore UNIQUEMENT pour tokens\n- FlatList obligatoire pour listes > 20 items\n- Hermes activé en production"},
+  "laravel":{label:"Laravel + MySQL/PG",tag:"Laravel·Eloquent",db:"MySQL/PostgreSQL Eloquent",auth:"Sanctum/Passport",
+    adapt:"• Policy Laravel + where('user_id',auth()->id())\n• $fillable explicite sur chaque Model\n• CSRF sur routes POST web\n• Eager loading with() pour éviter N+1",
+    sec:["authorize() en premier","where('user_id',auth()->id())","$fillable explicite","CSRF sur POST/PUT/DELETE"],
+    perf:["with() pour eager loading","chunk() pour traitement de grands datasets","Cache::remember pour données fréquentes","DB::listen pour détecter les N+1 en dev"],
+    rules:"## LARAVEL\n- authorize() EN PREMIER dans chaque action\n- with() pour eager loading\n- chunk() pour > 1000 records"},
+  "nuxt":{label:"Nuxt + Supabase",tag:"Nuxt·Supabase",db:"Supabase (PostgreSQL+RLS)",auth:"nuxt-auth-utils",adapt:null,
+    sec:["RLS Supabase activé","event.context.user vérifié en premier","Composables client-only","NUXT_PUBLIC_ sans données sensibles"],
+    perf:["useFetch avec lazy:true pour non-critique","useAsyncData avec transform pour minimiser les données","Nitro prerender pour pages statiques","Composants Suspense pour SSR partiel"],
+    rules:"## NUXT\n- Server routes : event.context.user AVANT toute logique\n- useFetch avec getCachedData pour déduplication\n- RLS Supabase requis même avec auth Nuxt"},
+};
+
+// ─── PHASE GROUPS ──────────────────────────────────────────────
+export const GROUPS=[
+  {id:"discovery",label:"Découverte",color:"#6B5CF6",phases:["p0","p05"]},
+  {id:"security", label:"Sécurité",  color:"#E5534B",phases:["p1","p2","p_cfg"]},
+  {id:"quality",  label:"Qualité",   color:"#1E7FD8",phases:["p3","p4","p5","p6"]},
+  {id:"advanced", label:"Avancé",    color:"#0D9373",phases:["p_tests","p_deps","p_obs","p_a11y","p_integ","p_biz"]},
+  {id:"data",     label:"Données",   color:"#C47D0E",phases:["p7","p8","p85"]},
+  {id:"redteam",  label:"Red Team",  color:"#E5534B",phases:["p9a","p9b","p9c"]},
+  {id:"dast",     label:"DAST & Fuzz", color:"#9333EA",phases:["p_dast_infra","p_dast_api"]},
+  {id:"closure",  label:"Clôture",   color:"#1A7F4B",phases:["p10","p11"]},
+];
+
+// ─── PHASES (22) ──────────────────────────────────────────────
+export const PHASES=[
+  // ── DISCOVERY ───────────────────────────────────────────────
+  {id:"p0",n:"0",icon:"🗺",label:"Découverte & Contexte Métier",color:"#6B5CF6",tag:"DISCOVERY",group:"discovery",
+   deps:[],
+   what:"Cartographie complète : stack, données sensibles, rôles, flux critiques, métriques de charge. Ce contexte enrichit automatiquement toutes les phases suivantes.",
+   how:"Copie le prompt → colle dans Antigravity avec le contexte du projet → récupère le tableau de blocs + contexte métier complet → reviens remplir et cocher.",
+   prompt:`Tu es un Lead Security Architect & Solutions Expert. Cartographie ce projet AVANT tout audit.
+
+SECTION A — TECHNIQUE
+1. Stack complète (framework+version, BDD+ORM, auth, payment, storage, CDN, cache)
+2. Architecture globale (monolithe / microservices / serverless / hybride ?)
+3. Environnements (dev/staging/prod) et différences entre eux
+4. Points d'intégration externes (APIs tierces, webhooks, OAuth providers, messaging)
+
+SECTION B — LOGIQUE MÉTIER (CRITIQUE — enrichit toutes les phases)
+1. Acteurs : qui utilise le système ? (rôles, permissions, types d'utilisateurs)
+2. Flux critiques : inscription, paiement, traitement de données, envoi de communication
+3. Données sensibles : PII, financières, audio, médicales, contrats — où stockées, comment protégées
+4. Règles métier INVARIANTES (celles qui ne doivent JAMAIS être violées, même en cas d'erreur)
+5. Métriques de charge : utilisateurs actifs quotidiens, pics simultanés, SLA cible, géographie
+
+SECTION C — CONFORMITÉS À DÉDUIRE
+RGPD si données EU/Afrique · PCI-DSS si paiement carte · HIPAA si médical · SOC2 si SaaS B2B
+
+SECTION D — PLAN D'AUDIT (sortie obligatoire)
+Tableau Markdown :
+| Bloc | Fichiers (max 5) | Criticité | Phase principale | Règles métier concernées | Dépendances |
+
+RÈGLE : Aucun audit maintenant. Signal GO BLOC [N] pour démarrer.`,
+   checks:["Stack technique complète identifiée","Rôles et flux critiques documentés","Données sensibles listées et classifiées","Règles métier invariantes notées","Métriques de charge documentées","Conformités déduites automatiquement","Blocs d'audit créés (max 5 fichiers/bloc)"]},
+
+  {id:"p05",n:"0.5",icon:"📁",label:"Génération des Sessions d'Audit",color:"#6B5CF6",tag:"GENERATION",group:"discovery",
+   deps:["p0"],
+   what:"L'IA crée audit-sessions/ avec un .md prêt par bloc, contexte métier injecté, et les dépendances entre blocs documentées.",
+   how:"Copie le prompt → colle dans Antigravity → l'IA crée les fichiers → vérifie audit-sessions/README.md → cocher.",
+   prompt:`La cartographie et le contexte métier sont dans AUDIT_MASTER_TRACKER.md. Génère les sessions.
+
+1. Crée audit-sessions/ à la racine
+2. Pour chaque bloc du tracker, crée bloc-XX.md :
+   - En-tête : nom, criticité, phase, fichiers exacts, règles métier pertinentes
+   - Contexte métier injecté : flux critiques, rôles, données sensibles du bloc
+   - Prompt d'audit COMPLET avec fichiers déjà insérés et contexte préfixé
+   - Règles anti-faux-positifs : "Signale UNIQUEMENT ce que tu as VU dans le code"
+   - Format obligatoire (✅/🟡/🔴 avec ligne + correctif)
+   - Dépendances : "Lire d'abord bloc-XX.md si applicable"
+   - Instruction finale : "Après audit → mets à jour AUDIT_MASTER_TRACKER.md"
+3. Crée audit-sessions/README.md :
+   - Ordre d'exécution recommandé avec justification
+   - Carte des dépendances entre blocs
+   - Estimation de durée totale
+4. Crée audit-sessions/FINDINGS_REGISTER.md :
+   - Template pour centraliser tous les findings cross-phases
+5. Mets à jour AUDIT_MASTER_TRACKER.md : "Prompt généré" + "Contexte métier injecté"
+
+N'exécute pas les audits. Crée les fichiers.`,
+   checks:["audit-sessions/ créé","Un bloc-XX.md par bloc avec prompt + contexte métier","Dépendances entre blocs documentées","README.md avec ordre + durée estimée","FINDINGS_REGISTER.md créé","Tracker mis à jour"]},
+
+  // ── SECURITY ────────────────────────────────────────────────
+  {id:"p1",n:"1",icon:"🔐",label:"Sécurité & Authentification",color:"#E5534B",tag:"SECURITY",group:"security",
+   deps:["p0"],
+   what:"Audit exhaustif des secrets, contrôle d'accès BDD, validation des inputs, authentification et autorisation. Module par module, zéro tolérance pour les faux positifs.",
+   how:"Remplis Bloc + Fichiers → le prompt inclut automatiquement les règles métier de Phase 0 → Copie → colle dans Antigravity.",
+   prompt:`Tu es un Expert Cybersécurité Senior spécialisé sur cette stack. BLOC [N].
+
+PÉRIMÈTRE : [colle ici les 3-5 fichiers]
+
+PROTOCOLE — DANS CET ORDRE STRICT :
+
+1. SECRETS & ENVIRONMENT
+   Cherche : strings ressemblant à tokens (sk-, pk-, AIza, ghp_, ey...), clés AWS/GCP/Azure, JWT_SECRET hardcodé
+   Cherche : .env dans .gitignore ? .env.local dans le repo ? Variables d'env dans le code client ?
+   → COMMANDE DE VÉRIFICATION : git log --all -S "sk-ant\|pk_live\|AIza" --source (à suggérer à l'utilisateur)
+
+2. CONTRÔLE D'ACCÈS AUX DONNÉES
+   Pour chaque requête BDD identifiée : l'identifiant utilisateur est-il filtré (WHERE user_id = session.user.id) ?
+   Peut-on changer un ID dans la requête et accéder aux données d'un autre ? (IDOR)
+   Les 4 opérations CRUD sont-elles toutes protégées, pas seulement READ ?
+   Les ressources de niveau admin sont-elles vérifiées avec role === 'admin' côté serveur ?
+
+3. VALIDATION DES INPUTS
+   Chaque champ de formulaire a-t-il un schéma Zod/Yup/Pydantic en amont de la BDD ?
+   Les IDs dans les requêtes viennent-ils de la SESSION ou du body/params ?
+   Les types sont-ils validés (nombre négatif possible pour un prix ? email malformé accepté ?)
+   .strict() sur les schémas Zod pour rejeter les champs inconnus ?
+
+4. AUTHENTIFICATION & AUTORISATION
+   Ordre dans chaque handler : session vérifiée → rôle vérifié → logique → réponse ?
+   Middleware auth actif sur 100% des routes privées (pas seulement les routes listées) ?
+   Les tokens JWT sont-ils vérifiés avec la bonne clé et l'algorithme HS256/RS256 explicitement ?
+   Les sessions expirent-elles ? Révocation de session possible ?
+
+5. INJECTIONS & XSS
+   Concaténation de string dans des requêtes SQL/NoSQL (même partielle) ?
+   dangerouslySetInnerHTML / v-html / innerHTML sans DOMPurify ?
+   eval(), new Function(), setTimeout(string) avec données utilisateur ?
+   Path traversal possible (../../etc/passwd via des chemins de fichiers) ?
+
+FORMAT : ✅ [fichier] — SÉCURISÉ : [ce qui a été vérifié]
+🔴 [fichier] — [CRITIQUE|HAUTE|MOYENNE|BASSE] : [ligne précise + impact + correctif immédiat]
+RÈGLE ABSOLUE : Ne signale que ce VU dans le code. Incertain → "À VÉRIFIER MANUELLEMENT : [raison]"`,
+   checks:["Aucun secret hardcodé (clé, token, password, private key)","IDOR impossible : données filtrées par session sur les 4 opérations CRUD","Schéma de validation sur chaque input externe","Session vérifiée EN PREMIER dans chaque handler","100% des routes privées protégées côté serveur","Pas d'injection SQL/XSS/eval identifiée","JWT vérifié avec algorithme explicite"]},
+
+  {id:"p2",n:"2",icon:"🔌",label:"API & Backend Logic",color:"#E5534B",tag:"API",group:"security",
+   deps:["p1"],
+   what:"Audit des endpoints, flux de données bout-en-bout, idempotence, logique métier et gestion d'erreurs. Trace chaque requête de l'entrée à la BDD.",
+   how:"Remplis Bloc + Fichiers → Copie → colle dans Antigravity. Contexte des findings p1 injecté automatiquement.",
+   prompt:`Tu es un Expert Backend & API Security. BLOC [N].
+
+PÉRIMÈTRE : [colle ici les 3-5 fichiers]
+
+PROTOCOLE — TRACE CHAQUE FLUX BOUT EN BOUT :
+
+1. ORDRE DE TRAITEMENT (obligatoire dans cet ordre)
+   auth vérifiée → schéma validé → autorisations → logique métier → BDD → réponse
+   Toute déviation de cet ordre est une vulnérabilité architecturale.
+
+2. TRACE DU FLUX DONNÉES
+   Pour chaque endpoint : Input → [validation] → [transformation] → [BDD] → [filtrage] → Output
+   Les champs retournés au client sont-ils le minimum nécessaire ? (pas de password_hash, pas de token interne)
+   Les objets imbriqués ne révèlent-ils pas des données d'autres utilisateurs ?
+
+3. IDEMPOTENCE & LOGIQUE MÉTIER
+   Paiements : nonce/idempotency key pour prévenir la double facturation ?
+   Webhooks : signature vérifiée (Stripe-Signature, X-Hub-Signature) AVANT tout traitement ?
+   Suppressions : vérifie-t-on que l'utilisateur est bien propriétaire avant DELETE ?
+   Actions critiques (envoi email, SMS, notification) : une seule exécution garantie ?
+   Les règles métier invariantes (Phase 0) sont-elles respectées dans tous les cas d'erreur ?
+
+4. RATE LIMITING & PROTECTION
+   Rate limiting sur les routes sensibles (login, password reset, envoi de message) ?
+   CORS configuré avec une liste blanche d'origines (pas * en production) ?
+   Request body size limité (pas de 1GB payload possible) ?
+
+5. GESTION DES ERREURS
+   try/catch sur CHAQUE opération I/O (BDD, API externe, file system) ?
+   Les stack traces et noms de tables BDD ne remontent-ils jamais au client ?
+   Les erreurs sont-elles loggées côté serveur avec un identifiant de corrélation ?
+   Les codes d'erreur HTTP sont-ils sémantiquement corrects (401 vs 403, 404 vs 403) ?
+
+FORMAT : ✅ [endpoint] — OK : [flux vérifié]
+🔴 [endpoint] — [niveau] : [ligne + impact + correctif]`,
+   checks:["Ordre auth→validation→logique respecté dans chaque handler","Flux client→BDD tracé : données minimales retournées","Webhooks vérifient signature avant traitement","Paiements/actions critiques idempotentes","Rate limiting sur routes sensibles","CORS avec liste blanche","Erreurs sanitisées (pas d'info système au client)","Règles métier invariantes respectées y compris sur les erreurs"]},
+
+  {id:"p_cfg",n:"2.5",icon:"⚙",label:"Configuration & Hardening",color:"#E5534B",tag:"CONFIG",group:"security",
+   deps:["p1"],
+   what:"Audit profond de la configuration : headers HTTP, CORS, CSP, cookies, CSRF, session management et configuration des bibliothèques tierces.",
+   how:"Remplis Bloc + Fichiers (next.config.js, middleware, headers, cookie config) → Copie → colle dans Antigravity.",
+   prompt:`Tu es un Expert en Configuration Sécurité. BLOC [N].
+
+PÉRIMÈTRE : [colle ici les fichiers de configuration : next.config.js, middleware.ts, server config, nginx/caddy config, cookie settings]
+
+PROTOCOLE CONFIGURATION & HARDENING :
+
+1. HEADERS HTTP DE SÉCURITÉ (chacun a un rôle précis)
+   Content-Security-Policy : présente et efficace (pas default-src *) ?
+   → Valide que script-src ne contient pas unsafe-inline ou unsafe-eval
+   → Valide que connect-src liste explicitement les domaines externes
+   Strict-Transport-Security : max-age ≥ 31536000, includeSubDomains, preload ?
+   X-Frame-Options : DENY ou SAMEORIGIN ?
+   X-Content-Type-Options : nosniff présent ?
+   Referrer-Policy : no-referrer-out-downgrade-when-cross-origin ou plus strict ?
+   Permissions-Policy : caméra/micro/géolocalisation restreints si non utilisés ?
+
+2. GESTION DES COOKIES
+   Session cookie : HttpOnly=true, Secure=true, SameSite=Strict ou Lax ?
+   Les cookies tiers sont-ils limités au nécessaire ?
+   Domain et Path explicites pour éviter la propagation ?
+   Expiration raisonnable (pas de session permanente sur des données sensibles) ?
+
+3. PROTECTION CSRF
+   Tokens CSRF sur toutes les mutations (POST/PUT/DELETE) ?
+   SameSite=Strict sur le cookie de session ?
+   Origin header validé côté serveur ?
+
+4. SESSION MANAGEMENT
+   Sessions expirées après inactivité (idle timeout) ?
+   Session ID régénéré après authentification (session fixation) ?
+   Invalidation de session possible côté serveur (pas seulement supprimer le cookie côté client) ?
+   Limite du nombre de sessions actives par utilisateur ?
+
+5. CONFIGURATION DES DÉPENDANCES
+   TLS/SSL : version minimale TLS 1.2, ciphers forts uniquement ?
+   CORS : origines explicites, methods explicites, credentials:true seulement si nécessaire ?
+   Les bibliothèques d'auth sont-elles correctement configurées (pas de modes débug en prod) ?
+
+FORMAT : ✅ [config] — DURCIE : [résumé]
+🔴 [config] — [CRITIQUE|HAUTE|MOYENNE] : [paramètre + valeur actuelle + valeur correcte + impact]`,
+   checks:["CSP présente et restrictive (pas de unsafe-inline/eval)","HSTS max-age ≥ 31536000 avec preload","Cookies : HttpOnly + Secure + SameSite=Strict","CSRF protection sur toutes les mutations","Sessions : expiration + idle timeout + invalidation serveur","TLS 1.2+ uniquement","CORS : origines et méthodes explicites"]},
+
+  // ── QUALITY ─────────────────────────────────────────────────
+  {id:"p3",n:"3",icon:"🖥",label:"Frontend & Accessibilité",color:"#1E7FD8",tag:"FRONTEND",group:"quality",
+   deps:["p1"],
+   what:"Audit des composants, états async, hydratation SSR, accessibilité WCAG 2.2 et performances UI (Core Web Vitals).",
+   how:"Remplis Bloc + Fichiers → Copie → colle dans Antigravity.",
+   prompt:`Tu es un Expert Frontend Senior & Accessibility Specialist. BLOC [N].
+
+PÉRIMÈTRE : [colle ici les 3-5 fichiers]
+
+PROTOCOLE FRONTEND COMPLET :
+
+1. SÉCURITÉ CÔTÉ CLIENT
+   Tokens, clés, données de session dans localStorage/sessionStorage ? (HttpOnly cookies uniquement)
+   dangerouslySetInnerHTML / v-html / innerHTML sans sanitisation DOMPurify explicite ?
+   Les données d'un utilisateur n'affichent-elles pas des infos d'un autre par erreur ?
+   XSS via les paramètres URL affichés directement dans le DOM ?
+
+2. ÉTATS ASYNC & ROBUSTESSE UX
+   Chaque fetch/mutation a-t-il : état loading visible + état d'erreur clair + état vide géré ?
+   Formulaires désactivés (disabled) pendant la soumission ? (pas de double-envoi)
+   Retry automatique avec backoff exponentiel sur les erreurs réseau transitoires ?
+   Optimistic updates avec rollback en cas d'erreur serveur ?
+   Skeleton screens plutôt que spinners pour le contenu prévisible ?
+
+3. RENDU & HYDRATATION
+   Hydration Mismatches (différences server/client au premier rendu) ?
+   'use client' au niveau le plus bas possible dans l'arbre de composants ?
+   Dynamic import() sur les composants > 30kb ou chargés conditionnellement ?
+   Les données sensibles ne sont-elles pas exposées dans le HTML SSR (window.__INITIAL_DATA__) ?
+   Streaming Suspense pour les données lentes ?
+
+4. ACCESSIBILITÉ WCAG 2.2
+   Images : alt pertinent (pas "image" ou vide — décrire le CONTENU et le CONTEXTE) ?
+   Formulaires : labels explicitement associés (htmlFor, aria-labelledby, aria-label) ?
+   Navigation clavier : focus visible et logique, piège modal géré (FocusTrap) ?
+   Contraste : texte normal ≥ 4.5:1, texte large ≥ 3:1 (vérifier les couleurs exactes) ?
+   ARIA roles corrects (pas aria-label sur un div générique sans role) ?
+   Annonces aux screen readers pour les états dynamiques (aria-live) ?
+   Cibles de touch ≥ 44×44px sur mobile ?
+
+5. PERFORMANCES UI (Core Web Vitals)
+   Images avec width+height explicites pour éviter le CLS ?
+   Image LCP avec fetchpriority="high" et preload link ?
+   Polices : font-display: swap, preconnect sur le provider ?
+   Handlers d'événements coûteux debounced/throttled ?
+   Pas de layout thrashing (lecture+écriture DOM alternés dans une boucle) ?
+
+FORMAT : ✅ [composant] — VALIDÉ : [résumé]
+🟡 [composant] — [HAUTE|MOYENNE|BASSE] : [description + solution]
+🔴 [composant] — CRITIQUE : [description + correctif]`,
+   checks:["Aucun token/secret en localStorage","Loading + error + empty state sur chaque opération async","Formulaires désactivés pendant soumission","Pas de Hydration Mismatch","dynamic import sur composants > 30kb","Alt text pertinent et contextuel sur toutes les images","Labels associés sur tous les champs de formulaire","Contraste ≥ 4.5:1 sur le texte normal","Focus visible et navigation clavier fonctionnelle","Images LCP avec fetchpriority=high"]},
+
+  {id:"p4",n:"4",icon:"⚡",label:"Performance & Scalabilité",color:"#1E7FD8",tag:"PERFORMANCE",group:"quality",
+   deps:["p0"],hasPerf:true,
+   what:"Audit adapté aux métriques métier réelles. Quantifie l'impact à la charge cible, pas des généralités.",
+   how:"Remplis les métriques métier + Bloc + Fichiers → le prompt adapte les seuils à ta charge cible → Copie → colle dans Antigravity.",
+   prompt:`Tu es un Expert Performance & Scalabilité. BLOC [N].
+
+MÉTRIQUES MÉTIER [auto-injectées depuis les champs] :
+Utilisateurs actifs : [UAD] · Pics simultanés : [PEAK] · SLA : [SLA] · Géographie : [GEO]
+
+PÉRIMÈTRE : [colle ici les 3-5 fichiers]
+
+PROTOCOLE PERFORMANCE — QUANTIFIE PAR RAPPORT À LA CHARGE RÉELLE :
+
+1. REQUÊTES BDD (impact critique à l'échelle)
+   Requête dans une boucle (N+1) ? → À [PEAK] utilisateurs simultanés, combien de requêtes/seconde ?
+   SELECT * alors que 2-3 colonnes suffisent ? → Impact mémoire à [UAD] requêtes/jour ?
+   Index manquants sur colonnes filtrées ? → Vérifier avec EXPLAIN ANALYZE sur les requêtes fréquentes
+   Pagination sur toutes les listes ? → Sans pagination, quelle est la taille maximale du jeu de données ?
+   Jointures non optimisées ? → Suggérer les index composites manquants
+   Transactions trop longues qui bloquent la BDD ?
+
+2. BUNDLE & IMPORTS
+   Import de bibliothèque entière pour une fonction ? (lodash, moment, etc.)
+   → Calculer la taille ajoutée : lodash = +70kb gzippé
+   Bibliothèques non tree-shakeable importées entièrement ?
+   Polyfills inutiles pour les navigateurs cibles ?
+   Code mort inclus dans le bundle ?
+   → Recommander bundle-analyzer : npx @next/bundle-analyzer
+
+3. STRATÉGIE DE CACHE (critique pour SLA [SLA])
+   Données statiques sans cache ? → TTL recommandé selon la fréquence de mise à jour
+   Cache invalidé trop souvent (every request) ?
+   CDN configuré pour les assets statiques ?
+   Calculs coûteux répétés sans memoization ?
+   Rate limits des APIs tierces pris en compte dans la stratégie de cache ?
+
+4. RENDERING & CORE WEB VITALS
+   LCP : élément principal avec priority/fetchpriority="high" ?
+   CLS : dimensions réservées pour images et éléments dynamiques ?
+   INP : handlers d'événements synchrones sur le thread principal > 50ms ?
+   Stratégie ISR/SSG/SSR adaptée à la fréquence de mise à jour des données ?
+   Streaming pour les sections lentes ?
+
+5. SCALABILITÉ SOUS [PEAK] UTILISATEURS SIMULTANÉS
+   Connection pool BDD : max_connections adapté au nombre d'instances ?
+   Opérations longues bloquantes ? (déplacer en background job)
+   State applicatif partagé entre instances ? (Redis/Upstash au lieu de mémoire locale)
+   Goulots d'étranglement évidents dans l'architecture ? (single point of failure)
+
+FORMAT : ✅ [module] — OPTIMISÉ : [résumé + contexte de charge]
+🟡 [module] — OPTIMISATION [impact estimé à [PEAK] simultanés] : [description + solution]
+🔴 [module] — BLOQUANT À SCALE : [impact à [UAD] req/jour + correctif]`,
+   checks:["Pas de N+1 (requête en boucle)","SELECT avec colonnes explicites","Index BDD sur colonnes filtrées (EXPLAIN ANALYZE suggéré)","Pagination sur toutes les listes","Connection pool configuré","Pas d'import de bibliothèque entière inutile","Cache configuré sur données statiques","Stratégie rendering adaptée","Images LCP prioritaires","Pas de blocking I/O sur le thread principal"]},
+
+  {id:"p5",n:"5",icon:"🧩",label:"Architecture & Modularité",color:"#1E7FD8",tag:"ARCHITECTURE",group:"quality",
+   deps:["p0"],
+   what:"Audit de la séparation des responsabilités, typage TypeScript, réutilisabilité, dette technique et testabilité du code.",
+   how:"Remplis Bloc + Fichiers → Copie → colle dans Antigravity.",
+   prompt:`Tu es un Expert Architecture Logicielle & Clean Code. BLOC [N].
+
+PÉRIMÈTRE : [colle ici les 3-5 fichiers]
+
+PROTOCOLE ARCHITECTURE :
+
+1. SÉPARATION DES RESPONSABILITÉS (SRP)
+   Chaque fichier/module fait-il UNE seule chose ? (ex: un component qui fetch ET affiche ET gère le formulaire = trop)
+   La logique métier est-elle dans des services/hooks séparés du rendu ?
+   Les règles métier invariantes (Phase 0) sont-elles dans une couche dédiée et testée séparément ?
+   Les dépendances vont-elles dans la bonne direction ? (UI → business logic → data access)
+
+2. TYPAGE TYPESCRIPT (lance mentalement tsc --noEmit)
+   any non justifié par un commentaire "// RAISON : ..." ?
+   Types qui reflètent les règles métier ? (ex: type Price = number & {readonly __brand: 'Price'} pour les prix)
+   Interfaces vs types : cohérence dans le projet ?
+   Les types génériques sont-ils contraints (T extends ...) quand nécessaire ?
+   as casting non justifié (contourne le compilateur) ?
+   unknown au lieu de any quand le type n'est pas connu ?
+
+3. RÉUTILISABILITÉ & DRY
+   Logique identique dans ≥ 2 endroits → candidat à l'extraction ?
+   Composants UI qui pourraient être paramétrables plutôt que dupliqués ?
+   Les constantes métier (statuts, codes d'erreur, limites) sont-elles centralisées ?
+   Les utilitaires purs (formatage, calculs) sont-ils dans des fichiers dédiés et testables ?
+
+4. DETTE TECHNIQUE QUANTIFIÉE
+   TODO sans date + issue tracker → risque de ne jamais être traité
+   Fonctions > 50 lignes → identifier et proposer le découpage
+   Dépendances obsolètes → npm outdated (suggérer la commande)
+   Code commenté ou mort → le signaler pour suppression
+   Couplage fort (import circulaire, God Object) ?
+
+5. TESTABILITÉ
+   La logique métier est-elle isolable ? (pas de fetch dans les business rules)
+   Les effets de bord sont-ils explicites et injectables ?
+   Les fonctions pures sont-elles identifiables (même input → même output) ?
+   Les dépendances externes sont-elles mockables ?
+
+FORMAT : ✅ [module] — PROPRE : [résumé]
+🟡 [module] — DETTE [HAUTE|MOYENNE|BASSE] : [description + refactoring suggéré]
+🔴 [module] — CRITIQUE : [description + impact maintenabilité + correctif]`,
+   checks:["SRP : chaque module fait une chose","Logique métier dans une couche séparée","tsc --noEmit sans erreur","Pas de any non justifié","Constantes métier centralisées","Pas de code mort","Fonctions > 50 lignes identifiées et découpées","Logique métier isolable pour les tests"]},
+
+  {id:"p6",n:"6",icon:"🎯",label:"Edge Cases & Résilience",color:"#1E7FD8",tag:"EDGE CASES",group:"quality",
+   deps:["p2","p5"],
+   what:"Audit systématique des cas limites, valeurs extrêmes, pannes réseau et comportements imprévus. 90% des bugs en production viennent d'ici.",
+   how:"Remplis Bloc + Fichiers → Copie → colle dans Antigravity.",
+   prompt:`Tu es un Expert en Qualité Logicielle et Test de Résilience. BLOC [N].
+
+PÉRIMÈTRE : [colle ici les 3-5 fichiers]
+
+PROTOCOLE EDGE CASES — PENSE COMME UN UTILISATEUR MALCHANCEUX ET UN ATTACKER CRÉATIF :
+
+1. NULL, UNDEFINED & ÉTATS VIDES
+   Optional chaining utilisé systématiquement sur les objets optionnels ?
+   array.map(), .filter(), .reduce() sur un tableau potentiellement vide ?
+   Valeur par défaut sur tous les paramètres optionnels ?
+   Accès à des propriétés imbriquées sans vérification (obj.a.b.c) ?
+   JSON.parse() sans try/catch sur des données externes ?
+
+2. VALEURS LIMITES (BOUNDARY CONDITIONS)
+   Nombre : 0, négatif, Infinity, NaN, très grand (overflow int64 ?)
+   String : vide "", 1 caractère, 10 000 caractères, caractères spéciaux (<>"'&), emojis 🎉, RTL (عربي)
+   Date : passé lointain (1900), futur lointain (2099), timezone différent de l'utilisateur, DST changements
+   Fichier : taille 0 octets, taille maximale dépassée, mauvais MIME type, nom avec espaces/accents/../
+   URL : query params encodés, fragments (#), URLs très longues, Unicode dans les paths
+
+3. CONCURRENCE & RACE CONDITIONS
+   Deux requêtes en parallèle sur la même ressource (ex: double-clic sur "Confirmer") ?
+   Mutation puis lecture immédiate avant que la BDD ne soit à jour ?
+   Cache qui retourne une valeur obsolète pendant une opération critique ?
+   Expiration de session EN COURS d'une opération longue (> 30 secondes) ?
+   Optimistic update qui entre en conflit avec une modification serveur concurrente ?
+
+4. PANNES RÉSEAU & SERVICES TIERS
+   API externe indisponible : timeout défini ? Message d'erreur utilisateur clair ?
+   Retry exponentiel avec jitter (pas de retry storm) ?
+   Circuit breaker pour les services tiers critiques ?
+   Que se passe-t-il si Stripe/PayPal est down pendant un paiement en cours ?
+   Webhook non livré : idempotence du traitement si relivré ?
+   Mobile Afrique : que se passe-t-il avec une connexion 2G/coupée en milieu d'opération ?
+
+5. DONNÉES CORROMPUES & SCHÉMA INATTENDU
+   Que se passe-t-il si la BDD retourne null sur un champ NON_NULL attendu ?
+   Si un webhook externe change son format de payload ?
+   Si un fichier importé (CSV, Excel) a des colonnes inversées ou manquantes ?
+   Si un utilisateur contourne le front-end et envoie directement des payloads malformés ?
+
+6. RÈGLES MÉTIER AUX FRONTIÈRES (basé sur Phase 0)
+   Les invariants métier tiennent-ils pour les valeurs limites ?
+   (0 agents, 0 appels, paiement de 0€, fichier audio de 0 secondes, etc.)
+
+FORMAT : ✅ [module] — RÉSILIENT : [cas testés]
+🟡 [module] — CAS LIMITE NON GÉRÉ [HAUTE|MOYENNE] : [scénario précis → impact → solution]
+🔴 [module] — CRASH EN PRODUCTION : [scénario → impact métier → correctif immédiat]`,
+   checks:["null/undefined géré sur tous les champs critiques","Tableaux vides gérés (affichage + calculs)","Valeurs limites : 0, négatif, très grand, chaîne vide","Race conditions protégées sur actions critiques","Timeout défini sur tous les appels d'API externe","Retry avec backoff exponentiel + jitter","Règles métier invariantes respectées aux valeurs limites","Session expirée gérée en cours d'opération longue"]},
+
+  // ── ADVANCED ────────────────────────────────────────────────
+  {id:"p_tests",n:"7",icon:"🧪",label:"Tests & Couverture",color:"#0D9373",tag:"TESTS",group:"advanced",
+   deps:["p5","p6"],
+   what:"Audit de la stratégie de tests existante et génération des tests manquants pour la logique métier critique. Un projet sans tests est un projet qui régresse.",
+   how:"Remplis Bloc + Fichiers (tests existants + code source) → Copie → colle dans Antigravity.",
+   prompt:`Tu es un Expert en Test Engineering & Quality Assurance. BLOC [N].
+
+PÉRIMÈTRE : [colle ici les fichiers de test ET le code source correspondant]
+
+PROTOCOLE AUDIT TESTS — IDENTIFIER CE QUI MANQUE ET GÉNÉRER :
+
+1. INVENTAIRE DES TESTS EXISTANTS
+   Tests unitaires : couverture des fonctions de logique métier ?
+   Tests d'intégration : les flux API critiques sont-ils testés end-to-end ?
+   Tests E2E : les parcours utilisateur critiques (inscription, paiement, flux principal) ?
+   Tests de performance : seuils de charge validés ?
+   Calcule une couverture approximative (% de la logique métier critique couverte)
+
+2. TESTS CRITIQUES MANQUANTS (GÉNÈRE-LES)
+   Pour chaque fonction de logique métier non testée, génère le test :
+   \`\`\`typescript
+   describe('[nomFonction]', () => {
+     it('should [comportement attendu] when [condition]', () => {
+       // Arrange
+       const input = [valeur représentative];
+       // Act
+       const result = maFonction(input);
+       // Assert
+       expect(result).toEqual([valeur attendue]);
+     });
+     
+     it('should handle [edge case]', () => {
+       expect(() => maFonction(null)).toThrow('[message d erreur attendu]');
+     });
+   });
+   \`\`\`
+
+3. TESTS DES RÈGLES MÉTIER INVARIANTES (basé sur Phase 0)
+   Pour chaque règle métier qui ne doit JAMAIS être violée, génère un test qui valide cette invariante.
+   Ces tests doivent être dans un fichier séparé business-rules.test.ts
+
+4. MOCKING & ISOLATION
+   Les appels BDD sont-ils mockés dans les tests unitaires (sinon ce sont des tests d'intégration) ?
+   Les services externes (email, SMS, paiement) sont-ils mockés ?
+   Les tests sont-ils déterministes (pas de Date.now() ou Math.random() sans mock) ?
+
+5. TESTS DE RÉGRESSION
+   Pour chaque bug critique corrigé, y a-t-il un test de non-régression ?
+   Les tests couvrent-ils les edge cases identifiés en Phase 6 ?
+
+FORMAT : ✅ [module] — BIEN TESTÉ : [couverture résumée]
+🟡 [module] — TESTS MANQUANTS [impact] : [liste + tests générés]
+🔴 [module] — LOGIQUE MÉTIER NON TESTÉE : [tests critiques générés]`,
+   checks:["Logique métier critique couverte par des tests unitaires","Flux API critiques couverts par des tests d'intégration","Règles métier invariantes testées dans un fichier dédié","Edge cases Phase 6 couverts par des tests","Tests déterministes (mocks sur Date/Random/API)","Tests de non-régression sur les bugs passés","Couverture ≥ 80% sur la logique métier (pas le boilerplate)"]},
+
+  {id:"p_deps",n:"8",icon:"📦",label:"Dépendances & Supply Chain",color:"#0D9373",tag:"DEPS",group:"advanced",
+   deps:["p8"],
+   what:"Audit complet des dépendances : vulnérabilités CVE, licences incompatibles, alternatives légères, risque d'abandon et sécurité de la supply chain.",
+   how:"Remplis Bloc + Fichiers (package.json, yarn.lock, Gemfile, requirements.txt) → Copie → colle dans Antigravity.",
+   prompt:`Tu es un Expert en Supply Chain Security & Dependency Management. BLOC [N].
+
+PÉRIMÈTRE : [colle ici package.json, lockfile (package-lock.json ou yarn.lock), et tout fichier de dépendances]
+
+PROTOCOLE AUDIT DÉPENDANCES :
+
+1. SÉCURITÉ (CVE)
+   npm audit --json → lister les CVE critiques et hautes avec leur impact réel
+   Pour chaque CVE critique : est-il réellement exploitable dans ce contexte ? (CVSS contextuel)
+   Dépendances transitives avec CVE connues ?
+   → Commandes à suggérer : npm audit fix --force (avec précautions)
+
+2. LICENCES (risque légal)
+   Licences incompatibles avec le modèle commercial ?
+   GPL/AGPL dans un projet commercial non open-source → risque légal
+   → Licence requise pour chaque dépendance critique (MIT, Apache 2.0, BSD = safe ; GPL = attention)
+
+3. TAILLE & ALTERNATIVES LÉGÈRES
+   Dépendances > 50kb gzippé qui pourraient être remplacées ?
+   moment.js (67kb) → dayjs (7kb) ou date-fns (tree-shakeable)
+   lodash (entire) → lodash-es (tree-shakeable) ou fonctions natives
+   axios → fetch natif si pas de besoin spécifique d'axios
+   left-pad ou tiny-utility-packages pouvant être réécrites en 5 lignes ?
+
+4. RISQUE D'ABANDON
+   Dépendances sans release depuis > 2 ans ?
+   Mainteneurs uniques (bus factor = 1) ?
+   Issues critiques ouvertes sans réponse depuis > 6 mois ?
+   Forks populaires qui ont remplacé le package original ?
+
+5. SÉCURITÉ SUPPLY CHAIN
+   Typosquatting : des dépendances avec des noms proches de packages populaires ?
+   Scripts postinstall qui exécutent du code (potentiel malware) ?
+   Lockfile versionné ? (sans lockfile, npm install peut installer des versions différentes)
+   Dépendances qui ont accès aux variables d'env au build time ?
+
+FORMAT : ✅ [dépendance] — SÛRE : [version + licence + statut maintenance]
+🟡 [dépendance] — ATTENTION [CVE|LICENCE|TAILLE|ABANDON] : [détail + alternative recommandée]
+🔴 [dépendance] — CRITIQUE : [CVE exploitable ou licence incompatible + action immédiate]`,
+   checks:["npm audit : pas de CVE critique non justifié","Licences compatibles avec le modèle commercial","Pas de dépendance > 100kb sans alternative légère étudiée","Dépendances maintenues activement (< 2 ans sans release)","Lockfile versionné (yarn.lock ou package-lock.json)","Pas de typosquatting détecté","Scripts postinstall identifiés et audités"]},
+
+  {id:"p_obs",n:"9",icon:"📊",label:"Observabilité & Monitoring",color:"#0D9373",tag:"OBSERVABILITY",group:"advanced",
+   deps:["p8"],
+   what:"Audit de la visibilité en production : logs structurés, métriques, alertes, tracing et gestion des incidents. Un bug qu'on ne voit pas en production est pire qu'un bug connu.",
+   how:"Remplis Bloc + Fichiers (Sentry config, logger, monitoring config, dashboards) → Copie → colle dans Antigravity.",
+   prompt:`Tu es un Expert en Observabilité & Site Reliability Engineering. BLOC [N].
+
+PÉRIMÈTRE : [colle ici les fichiers de config monitoring, logger, Sentry/Datadog/etc., alerting rules]
+
+PROTOCOLE OBSERVABILITÉ :
+
+1. LOGS STRUCTURÉS
+   Les logs sont-ils structurés (JSON) avec des champs standardisés (level, timestamp, requestId, userId) ?
+   Les logs contiennent-ils des données sensibles ? (passwords, tokens, PII dans les logs = violation RGPD)
+   Un requestId unique tracé à travers toute la requête (headers → BDD → réponse) ?
+   Les niveaux de log sont-ils corrects ? (debug en dev, warn/error en prod)
+   Les erreurs non capturées (unhandledRejection, uncaughtException) sont-elles loggées ?
+   Volumétrie : les logs ne vont-ils pas saturer le stockage à [UAD] req/jour ?
+
+2. MÉTRIQUES BUSINESS & TECHNIQUES
+   Les métriques clés du domaine métier sont-elles trackées ? (ex: appels audités/jour, taux de succès)
+   Métriques techniques : p95/p99 latence, taux d'erreur 4xx/5xx, connexions BDD actives ?
+   Golden signals : Latency, Traffic, Errors, Saturation (RED/USE) ?
+   Les SLA définis en Phase 0 sont-ils mesurés automatiquement ?
+
+3. ALERTES (ne pas subir, anticiper)
+   Alerte sur erreur rate > seuil (ex: > 1% de 5xx) ?
+   Alerte sur latence p95 > SLA cible ?
+   Alerte sur saturation BDD (connexions, disk, CPU) ?
+   Dead Man's Switch : alerte si le système est SILENCIEUX (pas de requêtes = problème) ?
+   Les alertes sont-elles actionnables ? (pas d'alert fatigue avec des faux positifs)
+   Rotation d'astreinte définie pour les alertes critiques ?
+
+4. ERROR TRACKING
+   Erreurs capturées avec contexte (user, stack trace, breadcrumbs) ?
+   Taux d'erreur par endpoint trackés séparément ?
+   Erreurs groupées intelligemment (pas un ticket par occurrence) ?
+   Release tracking pour corréler erreurs et déploiements ?
+
+5. TRACING DISTRIBUÉ (si microservices ou services multiples)
+   Trace ID propagé entre services ?
+   Temps passé dans chaque service visible ?
+   Goulots d'étranglement identifiables par trace ?
+
+FORMAT : ✅ [composant] — OBSERVABLE : [résumé]
+🟡 [composant] — ANGLE MORT [impact] : [ce qui manque + solution]
+🔴 [composant] — NON OBSERVABLE EN PRODUCTION : [risque + mise en place urgente]`,
+   checks:["Logs structurés (JSON) sans données sensibles","RequestId tracé bout-en-bout","Métriques métier clés trackées","Alertes sur : error rate, latence p95, saturation BDD","Dead Man's Switch configuré","Error tracking avec contexte (user + stack)","SLA définis en Phase 0 mesurés automatiquement","Rotation d'astreinte définie pour les alertes critiques"]},
+
+  {id:"p_a11y",n:"9.5",icon:"♿",label:"Accessibilité Avancée",color:"#0D9373",tag:"A11Y",group:"advanced",
+   deps:["p3"],
+   what:"Audit d'accessibilité WCAG 2.2 complet avec tests concrets pour les technologies d'assistance. L'accessibilité est un droit, pas une option.",
+   how:"Remplis Bloc + Fichiers (composants, pages, styles) → Copie → colle dans Antigravity. Idéalement : coller aussi les résultats d'axe-core ou Lighthouse.",
+   prompt:`Tu es un Expert en Accessibilité Web (WCAG 2.2, ARIA, AT). BLOC [N].
+
+PÉRIMÈTRE : [colle ici les fichiers de composants et pages, et idéalement les résultats de : npx axe-core-cli http://localhost:3000 ou Lighthouse accessibility report]
+
+PROTOCOLE ACCESSIBILITÉ WCAG 2.2 COMPLET :
+
+1. STRUCTURE SÉMANTIQUE (WCAG 1.3)
+   Hiérarchie des titres : h1 unique par page, h2-h6 logiquement imbriqués (pas de saut) ?
+   Landmarks ARIA : main, nav, header, footer, aside, section avec aria-label ?
+   Listes sémantiques : les menus de navigation sont-ils des <ul>/<ol> ?
+   Les tableaux ont-ils des <caption>, <th scope="col/row"> ?
+   Les boutons sont-ils des <button> ou des <a href> avec le rôle approprié ?
+   Les icônes purement décoratives ont-elles aria-hidden="true" ?
+
+2. ALTERNATIVES TEXTUELLES (WCAG 1.1)
+   Images informatives : alt décrivant le contenu ET le contexte ?
+   Images complexes (graphiques, diagrammes) : description longue (longdesc ou aria-describedby) ?
+   Icônes de boutons sans texte : aria-label descriptif ?
+   PDF, vidéos, audio : alternatives textuelles ou transcriptions ?
+
+3. NAVIGATION AU CLAVIER (WCAG 2.1)
+   Tous les éléments interactifs atteignables via Tab ?
+   Ordre de focus logique (suit l'ordre visuel) ?
+   Focus visible : outline visible avec ratio de contraste ≥ 3:1 ?
+   Modales : focus piégé dans la modale, retour au déclencheur à la fermeture ?
+   Menus déroulants : navigables aux flèches ?
+   Drag & drop : alternative au clavier ?
+   Raccourcis clavier documentés et sans conflits (Escape, Entrée, Espace) ?
+
+4. CONTRASTE & COULEURS (WCAG 1.4)
+   Texte normal (< 18pt) : ratio ≥ 4.5:1 ?
+   Texte large (≥ 18pt ou ≥ 14pt gras) : ratio ≥ 3:1 ?
+   Composants UI (bordures de champ, icônes actives) : ratio ≥ 3:1 ?
+   L'information n'est pas transmise UNIQUEMENT par la couleur (erreurs rouges avec icône ?) ?
+
+5. FORMULAIRES & ERREURS (WCAG 3.3)
+   Chaque champ a un label associé (pas juste un placeholder) ?
+   Les messages d'erreur identifient le champ concerné et expliquent le problème ?
+   Les champs obligatoires sont marqués (aria-required="true") ?
+   Validation : les erreurs sont-elles annoncées aux screen readers (aria-live="assertive") ?
+
+6. CONTENU DYNAMIQUE (WCAG 4.1)
+   Les mises à jour dynamiques sont-elles annoncées via aria-live ?
+   Les chargements sont-ils indiqués (aria-busy="true") ?
+   Les composants personnalisés ont-ils le bon rôle ARIA et les bons états (aria-expanded, aria-checked) ?
+
+FORMAT : ✅ [composant] — ACCESSIBLE : [résumé]
+🟡 [composant] — WCAG [critère] — [HAUTE|MOYENNE] : [description + solution concrète]
+🔴 [composant] — BARRIÈRE D'ACCÈS CRITIQUE : [description + correctif]`,
+   checks:["Hiérarchie h1-h6 logique et unique","Landmarks ARIA sur toutes les sections","Alt text pertinent sur toutes les images non-décoratives","Navigation clavier complète sur tous les éléments interactifs","Focus visible avec contraste ≥ 3:1","Contraste texte ≥ 4.5:1 (normal) / 3:1 (large)","Modales avec FocusTrap et retour au déclencheur","Erreurs formulaire avec aria-live=assertive","Pas d'info transmise par couleur seule","Composants ARIA avec états corrects (expanded, checked)"]},
+
+  {id:"p_integ",n:"10",icon:"🔗",label:"Intégrations Tierces",color:"#0D9373",tag:"INTEGRATIONS",group:"advanced",
+   deps:["p2","p_cfg"],
+   what:"Audit des intégrations externes : APIs tierces, OAuth/SSO, webhooks entrants/sortants, services email/SMS, stockage cloud. Chaque intégration est une surface d'attaque.",
+   how:"Remplis Bloc + Fichiers (code d'intégration, config OAuth, webhook handlers) → Copie → colle dans Antigravity.",
+   prompt:`Tu es un Expert en Sécurité des Intégrations & API Tierce. BLOC [N].
+
+PÉRIMÈTRE : [colle ici les fichiers d'intégration : handlers OAuth, webhook receivers, API clients, email/SMS service config]
+
+PROTOCOLE INTÉGRATIONS TIERCES :
+
+1. OAUTH & SSO
+   State parameter présent et validé (prévient CSRF sur le flow OAuth) ?
+   PKCE implémenté pour les flows publics (SPA, mobile) ?
+   Tokens stockés côté serveur (HttpOnly cookie) et non dans localStorage ?
+   Scopes demandés : minimum nécessaire (principle of least privilege) ?
+   Token refresh sécurisé et rotation du refresh token ?
+   Validation de l'audience (aud claim) dans les tokens JWT reçus ?
+
+2. WEBHOOKS ENTRANTS (Stripe, GitHub, Twilio, etc.)
+   Signature vérifiée AVANT tout traitement ?
+   Idempotence : deux livraisons du même webhook ne créent pas de doublon ?
+   Queue/buffer pour les pics de webhooks (pas de traitement synchrone bloquant) ?
+   Réponse 200 rapide + traitement asynchrone pour les webhooks longs ?
+   Replay d'attaque prévenu (timestamp vérifié, tolérance ≤ 5 minutes) ?
+
+3. APIs EXTERNES CONSOMMÉES
+   Clés API en variables d'env (jamais hardcodées) ?
+   Timeout défini sur chaque appel externe (pas de hang infini) ?
+   Circuit breaker : que se passe-t-il si l'API externe est down > 5 minutes ?
+   Gestion des rate limits de l'API tierce (retry avec backoff, file d'attente) ?
+   Données sensibles loggées dans les logs d'API tiers (attention aux SDK qui loggent tout) ?
+
+4. EMAIL & SMS
+   Templates email : injection possible dans les champs utilisateur ?
+   Rate limiting sur l'envoi (pas de spam bombing via l'API email) ?
+   Bounces et unsubscribes traités (impact délivrabilité) ?
+   SPF, DKIM, DMARC configurés pour le domaine d'envoi ?
+   SMS : vérification du numéro avant envoi, pas de SMS bombing ?
+
+5. STOCKAGE CLOUD (S3, GCS, Azure Blob)
+   Buckets privés par défaut (pas de public read) ?
+   URLs signées avec expiration courte pour les fichiers sensibles ?
+   ACL par objet ou politique de bucket (pas d'accès croisé entre utilisateurs) ?
+   Upload direct : validation du type MIME côté serveur (pas seulement l'extension) ?
+   Scan antivirus sur les fichiers uploadés ?
+
+FORMAT : ✅ [intégration] — SÉCURISÉE : [résumé]
+🔴 [intégration] — [CRITIQUE|HAUTE|MOYENNE] : [description + vecteur d'attaque + correctif]`,
+   checks:["OAuth : state + PKCE + scopes minimum","Webhooks : signature vérifiée avant traitement","Webhooks : idempotents","APIs tierces : timeout + circuit breaker définis","Clés API tierces en variables d'env","Templates email : pas d'injection possible","SPF/DKIM/DMARC configurés","Buckets cloud privés avec URLs signées","Upload : type MIME validé côté serveur"]},
+
+  {id:"p_biz",n:"10.5",icon:"📋",label:"Tests Logique Métier",color:"#0D9373",tag:"BUSINESS LOGIC",group:"advanced",
+   deps:["p0","p2","p6"],
+   what:"Audit des invariants métier et des workflows complexes. Vérifie que le code reflète fidèlement les règles du domaine, même dans les cas extrêmes.",
+   how:"Copie le prompt → colle dans Antigravity avec le code des domaines métier → valide chaque règle avec l'IA.",
+   prompt:`Tu es un Expert en Domain-Driven Design et Logique Métier. BLOC [N].
+
+CONTEXTE MÉTIER COMPLET (issu de Phase 0) : [règles métier invariantes]
+PÉRIMÈTRE : [colle ici les fichiers de logique métier, services, domain models]
+
+PROTOCOLE TESTS LOGIQUE MÉTIER — VALIDE CHAQUE RÈGLE DU DOMAINE :
+
+1. INVARIANTS MÉTIER (règles qui ne doivent JAMAIS être violées)
+   Pour chaque règle invariante identifiée en Phase 0, valide qu'elle est :
+   a. Implémentée dans le code (pas seulement dans l'UI)
+   b. Protégée même si l'UI est contournée (appel API direct)
+   c. Testée unitairement dans un fichier de tests dédié
+   d. Documentée dans le code avec un commentaire expliquant POURQUOI
+
+2. TRANSITIONS D'ÉTAT (State Machine)
+   Les objets du domaine ont-ils des états définis ?
+   Les transitions d'état sont-elles explicites et validées ?
+   (ex: un appel peut passer de EN_COURS → TERMINÉ mais pas de TERMINÉ → EN_COURS)
+   Un état invalide est-il impossible à atteindre (type safety + validation) ?
+
+3. RÈGLES DE GESTION COMPLEXES
+   Les calculs critiques (prix, commissions, scores, quotas) sont-ils corrects ?
+   Vérifie les calculs avec des exemples concrets tirés des cas d'usage métier
+   Les arrondis sont-ils gérés correctement ? (bancaire : half-even, pas half-up)
+   Les devises multiples sont-elles gérées sans erreur de conversion ?
+
+4. WORKFLOWS & SAGA
+   Les processus multi-étapes (ex: audit complet) sont-ils résilients ?
+   Que se passe-t-il si l'étape 3 échoue après que les étapes 1 et 2 ont réussi ?
+   Compensation transactions pour les workflows distribués ?
+   Les deadlines métier (ex: "audit doit être terminé en X jours") sont-elles trackées ?
+
+5. COHÉRENCE DES DONNÉES MÉTIER
+   Les données de référence (statuts, types, catégories) sont-elles cohérentes entre les modules ?
+   Les totaux et agrégats sont-ils recalculés ou maintenus à jour ?
+   Les données sont-elles cohérentes entre le cache et la BDD ?
+
+FORMAT : ✅ [règle métier] — RESPECTÉE : [comment elle est implémentée + testée]
+🟡 [règle métier] — PARTIELLEMENT IMPLÉMENTÉE : [ce qui manque + risque métier]
+🔴 [règle métier] — VIOLÉE OU NON IMPLÉMENTÉE : [impact métier + correctif]`,
+   checks:["Toutes les règles invariantes Phase 0 implémentées côté serveur","Machine à états explicite pour les objets du domaine","Calculs critiques vérifiés avec des exemples concrets","Arrondis et devises gérés correctement","Workflows résilients (compensation en cas d'échec partiel)","Règles métier testées unitairement dans un fichier dédié","Transitions d'état invalides impossibles par construction"]},
+
+  // ── DATA ─────────────────────────────────────────────────────
+  {id:"p7",n:"11",icon:"🗄",label:"Données & Migrations",color:"#C47D0E",tag:"DATA",group:"data",
+   deps:["p0","p1"],
+   what:"Audit du schéma BDD, migrations, intégrité des données, PII et stratégie de disaster recovery.",
+   how:"Remplis Bloc + Fichiers (migrations, schema, models) → Copie → colle dans Antigravity.",
+   prompt:`Tu es un Expert en Conception de Base de Données & Data Engineering. BLOC [N].
+
+PÉRIMÈTRE : [colle ici les fichiers de migration, schéma (schema.sql, prisma.schema, models.py, migrations/), seeds]
+
+PROTOCOLE DONNÉES :
+
+1. INTÉGRITÉ DU SCHÉMA
+   FK : ON DELETE approprié selon le domaine métier ?
+   CASCADE : utilise-t-on vraiment la suppression en cascade ? (souvent trop agressif)
+   SET NULL : la colonne est-elle nullable ? (cohérence)
+   RESTRICT : comportement voulu si une référence existe encore ?
+   NOT NULL : les colonnes critiques pour la logique métier sont-elles contraintes ?
+   UNIQUE : les identifiants métier (email, référence commande) sont-ils uniques ?
+   CHECK constraints : les valeurs sont-elles contraintes au niveau BDD ? (prix ≥ 0, statut IN (...))
+   Types corrects : DECIMAL pour les montants (pas FLOAT), TIMESTAMPTZ pour les dates (pas TIMESTAMP)
+   Index : colonnes utilisées dans WHERE, ORDER BY, JOIN — index manquants identifiés ?
+   Index composites : ordre des colonnes optimisé pour les requêtes fréquentes ?
+
+2. MIGRATIONS
+   Chaque migration a-t-elle une down migration testée ?
+   Les migrations sur grandes tables utilisent-elles des techniques non-bloquantes ?
+   (ADD COLUMN DEFAULT NULL → backfill séparé → ADD NOT NULL)
+   L'ordre des migrations est-il idempotent ? (peut-on rejouer depuis zéro ?)
+   Les migrations destructives (DROP) ont-elles un plan de rollback ?
+
+3. DONNÉES SENSIBLES & RGPD
+   Mots de passe : bcrypt avec cost ≥ 12 ou argon2id ?
+   PII : chiffrées au repos si nécessaire (numéros de téléphone, données médicales) ?
+   Droit à l'oubli : mécanisme de suppression/anonymisation implémenté ?
+   Rétention des données : les données sont-elles supprimées après la période légale ?
+   Logs BDD ne contiennent pas de PII (pg_audit, slow query logs) ?
+
+4. DISASTER RECOVERY
+   RPO (Recovery Point Objective) : fréquence des backups adaptée ? (toutes les heures pour des données critiques)
+   RTO (Recovery Time Objective) : procédure de restauration testée et chronométrée ?
+   Backups : stockés dans une région géographique différente ?
+   Point-in-time recovery disponible ?
+   Test de restauration effectué dans les 90 derniers jours ?
+
+FORMAT : ✅ CONFORME : [résumé]
+🟡 AMÉLIORATION : [description + impact + solution]
+🔴 RISQUE INTÉGRITÉ : [description + impact métier + correctif obligatoire]`,
+   checks:["FK avec ON DELETE adapté au domaine métier","NOT NULL et CHECK constraints sur colonnes critiques","Types corrects (DECIMAL pour montants, TIMESTAMPTZ pour dates)","Index sur colonnes filtrées/triées (EXPLAIN ANALYZE suggéré)","Migrations réversibles et non-bloquantes sur grandes tables","Mots de passe : bcrypt cost ≥ 12 ou argon2id","PII chiffrées au repos selon conformités","Mécanisme de droit à l'oubli RGPD implémenté","RPO/RTO définis et testés"]},
+
+  {id:"p8",n:"12",icon:"🖥️",label:"Infra, CI/CD & DevSecOps",color:"#C47D0E",tag:"INFRA",group:"data",
+   deps:["p_cfg"],
+   what:"Audit de l'infrastructure, pipeline CI/CD, variables d'env, headers HTTP et pratiques DevSecOps.",
+   how:"Remplis Bloc + Fichiers (.env.example, Dockerfile, workflows/, nginx config) → Copie → colle dans Antigravity.",
+   prompt:`Tu es un Expert DevSecOps & Infrastructure Security. BLOC [N].
+
+PÉRIMÈTRE : [colle ici .env.example, Dockerfile, .github/workflows/*.yml, docker-compose.yml, nginx.conf, package.json]
+
+PROTOCOLE DEVSECOPS :
+
+1. VARIABLES D'ENVIRONNEMENT
+   .env.example à jour avec TOUTES les variables + description de chacune ?
+   Différenciation obligatoire dev/staging/prod (jamais les mêmes secrets) ?
+   Secrets dans les variables d'env du pipeline (GitHub Secrets) — pas dans les YAML ?
+   Rotation des secrets planifiée (pas les mêmes depuis > 1 an) ?
+   Variables non utilisées à nettoyer ?
+
+2. PIPELINE CI/CD (Shift Left Security)
+   SAST (analyse statique) avant merge ? (Semgrep, CodeQL)
+   DAST (analyse dynamique) sur staging avant prod ? (OWASP ZAP)
+   Scan de secrets dans le code (Gitleaks) en pre-commit et CI ?
+   Tests de sécurité automatisés (npm audit, snyk) bloquants si CVE critique ?
+   Image Docker scannée (Trivy, Snyk Container) avant déploiement ?
+   Branche production protégée : PR obligatoire + review + tests verts ?
+   Déploiement bleu/vert ou canary pour les réductions de risque ?
+
+3. DOCKERFILE & IMAGES
+   Image de base officielle et version fixée (pas :latest) ?
+   Utilisateur non-root dans le container (USER appuser) ?
+   Image multi-stage pour réduire la surface d'attaque ?
+   Variables sensibles non incluses dans le Dockerfile (ARG vs ENV) ?
+   .dockerignore présent et complet (pas de node_modules, .env, .git dans l'image) ?
+
+4. HEADERS HTTP (rappel du p_cfg + vérification finale)
+   Content-Security-Policy effectivement délivrée en production ?
+   HSTS avec preload soumis à la preload list des navigateurs ?
+   Tous les headers vérifiés avec securityheaders.com ?
+
+5. MONITORING & INCIDENT RESPONSE
+   Runbook pour les incidents critiques (procédure step-by-step) ?
+   Post-mortem template défini ?
+   Canaux d'alerte testés régulièrement (PagerDuty, Slack, email) ?
+   SLA de réponse aux incidents défini (P1 < 15min, P2 < 1h) ?
+
+FORMAT : ✅ CONFORME : [résumé]
+🟡 AMÉLIORATION : [description + risque + solution]
+🔴 CRITIQUE : [description + impact + correctif]`,
+   checks:["Toutes variables d'env dans .env.example avec description","Secrets dans pipeline secrets (jamais dans les YAML)","Scan de secrets (Gitleaks) en pre-commit et CI","Tests de sécurité bloquants si CVE critique","Image Docker : non-root + version fixée + multi-stage","Branche production protégée (PR + review + tests)","Headers HTTP vérifiés avec securityheaders.com","Runbook incidents et SLA de réponse définis"]},
+
+  {id:"p85",n:"12.5",icon:"📚",label:"Documentation Profonde",color:"#C47D0E",tag:"DOCS",group:"data",
+   deps:["p5"],
+   what:"Audit de la documentation + génération des JSDoc/docstrings manquants pour chaque fonction. L'IA génère la documentation réelle, pas juste les recommandations.",
+   how:"Remplis Bloc + Fichiers (code source + docs existantes) → Copie → colle dans Antigravity → récupère la documentation générée.",
+   prompt:`Tu es un Expert en Documentation Technique & Knowledge Engineering. BLOC [N].
+
+PÉRIMÈTRE : [colle ici le code source + README.md + tout fichier de documentation existant]
+
+PROTOCOLE DOCUMENTATION EN DEUX NIVEAUX :
+
+NIVEAU 1 — DOCUMENTATION PROJET
+1. README FONCTIONNEL (test du "30 minutes rule")
+   Un développeur junior peut-il lancer le projet en < 30 minutes sans aide ?
+   Prérequis : versions exactes (Node 20.x, Python 3.11, Postgres 15) ?
+   Commandes step-by-step : clone → install → env → seed → run → test ?
+   Dépannage : erreurs communes et solutions ?
+
+2. ARCHITECTURE DECISION RECORDS (ADR)
+   Les choix techniques importants sont-ils documentés avec le CONTEXTE et le RAISONNEMENT ?
+   (ex: "Pourquoi Supabase et pas Firebase ?" → les ADR documentent la décision)
+
+NIVEAU 2 — DOCUMENTATION DU CODE (GÉNÈRE LA DOCUMENTATION MANQUANTE)
+Pour chaque fonction/module sans documentation complète, génère :
+
+\`\`\`typescript
+/**
+ * [Ce que fait la fonction en 1 phrase active : "Calcule", "Vérifie", "Transforme"...]
+ *
+ * Contexte métier : [Dans quel flux cette fonction s'insère, pourquoi elle existe,
+ * quelles règles métier elle implémente — critique pour comprendre le code dans 6 mois]
+ *
+ * @param {Type} nomParam - [Description précise + unité si applicable + valeurs invalides]
+ * @param {Type} [optionnel] - [Description + valeur par défaut + quand l'omettre]
+ *
+ * @returns {Type} [Description de ce qui est retourné + cas null/undefined]
+ *
+ * @throws {ErrorType} [Dans quelles conditions + message d'erreur attendu]
+ *
+ * @example
+ * // [Exemple concret avec vraies valeurs métier — pas de "foo" ou "bar"]
+ * const score = calculateAuditScore({ phases: completedPhases, findings: criticalFindings });
+ * // → { score: 87, grade: 'B', recommendation: 'Corriger 2 findings critiques' }
+ *
+ * @see [Lien vers la règle métier, le ticket, ou le document de spec si disponible]
+ */
+\`\`\`
+
+Pour chaque fichier/module sans commentaire d'en-tête :
+\`\`\`typescript
+/**
+ * [Nom du Module] — [Responsabilité en 1 ligne]
+ *
+ * Ce module [fait X] et [ne fait PAS Y].
+ * Point d'entrée : [fonction principale]
+ * Dépendances clés : [autres modules dont il dépend + pourquoi]
+ *
+ * ⚠️ Points d'attention :
+ * - [Piège ou contrainte importante à connaître]
+ * - [Comportement non intuitif à documenter]
+ *
+ * @module [NomModule]
+ */
+\`\`\`
+
+FORMAT : ✅ [fichier] — DOCUMENTÉ : [résumé]
+🟡 [fichier] — DOCUMENTATION MANQUANTE : [liste des fonctions + documentation générée ci-dessous]
+🔴 [fichier] — CRITIQUE NON DOCUMENTÉ : [logique complexe sans doc = bombe à retardement]`,
+   checks:["README : lancement en < 30min sans aide","ADR pour les choix techniques majeurs","Chaque fonction complexe a un JSDoc avec contexte métier","Chaque module a un commentaire d'en-tête avec responsabilité","Paramètres optionnels documentés avec valeur par défaut","Exemples concrets avec vraies valeurs métier","Points d'attention documentés (pièges, comportements non intuitifs)"]},
+
+  // ── RED TEAM ─────────────────────────────────────────────────
+  {id:"p9a",n:"13",icon:"👁",label:"Red Team — Reconnaissance",color:"#E5534B",tag:"RED·RECON",group:"redteam",
+   deps:["p1","p2","p_cfg"],
+   what:"Phase 1/3 du Red Team. Cartographie exhaustive de la surface d'attaque SANS exploitation. Le résultat alimente directement Phase 9b.",
+   how:"Copie le prompt → colle dans Antigravity avec maximum de contexte → récupère le plan d'attaque → commence p9b.",
+   prompt:`Tu changes de posture. Tu es un Hacker Éthique Senior (OSCP + Bug Bounty Top 5%). Phase RECONNAISSANCE.
+
+CONTEXTE DISPONIBLE (issu des phases précédentes) :
+- Findings sécurité (p1/p2/p_cfg) : [auto-injecté]
+- Architecture (p5) : [auto-injecté]
+- Données sensibles (p0) : [auto-injecté]
+
+PHASE RECONNAISSANCE — CARTOGRAPHIE SANS EXPLOITATION :
+
+1. SURFACE D'ATTAQUE EXTERNE (sans auth)
+   Quels endpoints répondent sans token ?
+   Les messages d'erreur révèlent-ils des versions, noms de technos, structure BDD ?
+   Les headers de réponse exposent-ils des infos (X-Powered-By, Server, X-Framework) ?
+   Les endpoints sont-ils enumérables ? (robots.txt, sitemap.xml, /.well-known/)
+   Les assets JS/CSS du bundle contiennent-ils des endpoints hardcodés ?
+   Les paramètres GET sont-ils dans les logs serveur (potentiel leak de tokens) ?
+
+2. SURFACE D'ATTAQUE AUTHENTIFIÉE
+   Avec un compte user standard, quels endpoints admin répondent en 403 vs 404 ?
+   (La différence révèle l'existence d'endpoints admin)
+   Les IDs de ressources sont-ils séquentiels (prévisibles) ou UUIDs ?
+   Les paramètres de pagination (page=1&limit=100) ont-ils des limites ?
+   Les filtres de recherche permettent-ils un bruteforce des données ?
+
+3. VECTEURS D'ATTAQUE IDENTIFIÉS (pas exploités, juste cartographiés)
+   Pour chaque vecteur, évalue : Exploitabilité × Impact × Probabilité de détection
+   🔴 HAUTE PROBABILITÉ (exploitable avec compétences basiques) :
+   🟡 PROBABILITÉ MODÉRÉE (nécessite des conditions spécifiques) :
+   ⚪ FAIBLE PROBABILITÉ (très difficile ou impact limité) :
+
+4. PLAN D'ATTAQUE POUR p9b (priorité décroissante)
+   Établis l'ordre des blocs à attaquer avec la justification :
+   | Priorité | Bloc | Vecteur principal | Raison |
+
+FORMAT FINAL :
+📊 SURFACE D'ATTAQUE
+   Endpoints publics : [N] | Paramètres prévisibles : [liste] | Infos exposées : [liste]
+🎯 PLAN D'ATTAQUE p9b (ordre prioritaire) :
+   1. [bloc+vecteur le plus prometteur]
+   2. ...`,
+   checks:["Endpoints publics exhaustivement cartographiés","Headers de réponse révélateurs identifiés","Différence 403/404 sur endpoints admin notée","Prévisibilité des IDs analysée","Vecteurs listés par exploitabilité × impact","Plan d'attaque p9b établi avec priorités"]},
+
+  {id:"p9b",n:"14",icon:"⚔️",label:"Red Team — Attaque par Module",color:"#E5534B",tag:"RED·ATTACK",group:"redteam",
+   deps:["p9a"],
+   what:"Phase 2/3 du Red Team. Exploitation module par module avec le même système de blocs. Chaque tentative est documentée honnêtement (protégé ou exploitable).",
+   how:"Utilise le plan de p9a → Remplis Bloc + Fichiers → Copie → colle dans Antigravity. Répète pour chaque bloc identifié.",
+   prompt:`EXPLOITATION MODULE PAR MODULE — BLOC [N] (issu du plan p9a)
+
+Tu es un Hacker Éthique Senior. Tu exploites le BLOC [N] identifié lors de la reconnaissance.
+
+CONTEXTE D'ATTAQUE :
+- Vecteurs identifiés en p9a pour ce bloc : [colle les vecteurs correspondants]
+- Findings de sécurité (p1) pour ce bloc : [colle si disponibles]
+PÉRIMÈTRE : [colle ici les 3-5 fichiers du bloc]
+
+OBJECTIFS D'ATTAQUE (ordre de valeur décroissant) :
+1. BOLA/IDOR : accéder aux données d'autres utilisateurs en changeant un ID
+2. Privilege Escalation : user → admin → super-admin
+3. CSRF / Session Fixation : agir en tant qu'un autre utilisateur
+4. Exfiltration : récupérer des données en masse (BDD dump, fichiers sensibles)
+5. Business Logic Bypass : contourner les règles métier (paiement 0€, quota illimité)
+6. DoS ciblé : planter ce module spécifiquement
+
+POUR CHAQUE TEST, DOCUMENTE HONNÊTEMENT :
+
+🔴 TEST [N] — [Nom de l'attaque]
+   Fichier ciblé : [fichier:ligne ou endpoint]
+   Payload : [exactement ce que tu enverrais — curl, JSON body, modifié dans l'URL]
+   
+   SI EXPLOITABLE :
+   → Impact réel : [ce que l'attaquant obtient concrètement]
+   → Preuve d'exploitation : [comment démontrer sans ambiguïté]
+   → Criticité : CRITIQUE / HAUTE
+   
+   SI PROTÉGÉ :
+   → Défense en place : [ce qui bloque précisément]
+   → Conclusion : PROTÉGÉ ✅
+
+TESTS OBLIGATOIRES :
+□ IDOR : [GET/PUT/DELETE] /api/resource/{ID_AUTRE_USER} → données d'un autre ?
+□ Mass Assignment : { "role": "admin", "isAdmin": true } dans le body → accepté ?
+□ Paramètre pollution : dupliquer des paramètres GET (?user_id=1&user_id=2) → lequel gagne ?
+□ JWT : modifier le payload sans resigner → accepté ?
+□ Path traversal : ../../../etc/passwd dans un champ fichier → réponse ?
+□ Méthodes HTTP non autorisées : PUT/DELETE sur des endpoints GET-only → réponse ?
+□ Business logic : valeur négative, 0, très grande → comportement ?
+
+RÈGLE D'OR : Honnêteté absolue. "Protégé" honnête > faux positif.`,
+   checks:["IDOR testé sur toutes les ressources du bloc","Mass Assignment testé avec champs privilégiés","JWT manipulation tentée","Path traversal tenté","Méthodes HTTP inattendues testées","Business logic bypass tenté avec valeurs limites","Chaque tentative documentée avec payload concrète","'Protégé' justifié techniquement (pas juste 'semble OK')"]},
+
+  {id:"p9c",n:"15",icon:"💥",label:"Red Team — Attaques Chaînées & Verdict",color:"#E5534B",tag:"RED·CHAIN",group:"redteam",
+   deps:["p9a","p9b"],
+   what:"Phase 3/3 du Red Team. Combine les findings de tous les blocs pour des attaques multi-étapes, puis donne un verdict global honnête.",
+   how:"Copie le prompt → colle dans Antigravity avec tous les findings p9a et p9b → récupère le verdict de posture sécurité.",
+   prompt:`PHASE FINALE RED TEAM — ATTAQUES CHAÎNÉES & VERDICT POSTURE GLOBALE
+
+Tu as terminé la reconnaissance (p9a) et l'exploitation par module (p9b).
+
+DONNÉES DISPONIBLES :
+- Findings p9a : [colle ici]
+- Findings p9b (tous blocs) : [colle ici]
+
+SECTION 1 — ATTAQUES CHAÎNÉES
+Combine les findings pour des attaques multi-étapes plus sophistiquées :
+
+Pour chaque chaîne possible :
+🔗 CHAÎNE [N] : [Nom de l'attaque composée]
+   Étape 1 : [Exploiter finding A → obtenir X]
+   Étape 2 : [Utiliser X pour exploiter finding B → obtenir Y]
+   Étape 3 : [Résultat final de la chaîne]
+   Impact total : [Ce que l'attaquant détient au bout de la chaîne]
+   Difficulté : BASIQUE / INTERMÉDIAIRE / AVANCÉ
+   Criticité : CRITIQUE / HAUTE
+
+Si aucune chaîne n'est possible : explique pourquoi (défense en profondeur réelle).
+
+SECTION 2 — POST-EXPLOITATION (compte lambda)
+Avec le plus haut niveau d'accès obtenu :
+- Quel est le rayon de blast maximal ?
+- Y a-t-il des informations permettant un pivot (social engineering, credential stuffing) ?
+- Les données visibles permettent-elles d'attaquer d'autres utilisateurs ?
+
+SECTION 3 — VERDICT POSTURE SÉCURITÉ GLOBALE
+Choisis exactement un des quatre niveaux :
+
+🔴 NIVEAU CRITIQUE — NE PAS DÉPLOYER :
+   [Findings exploitables + plan de remédiation prioritisé]
+
+🟠 NIVEAU ÉLEVÉ — DÉPLOIEMENT RISQUÉ :
+   [Findings à corriger avant toute mise en production]
+
+🟡 NIVEAU MODÉRÉ — DÉPLOIEMENT AVEC SURVEILLANCE :
+   [Findings à corriger dans les 30 jours + mesures compensatoires]
+
+🟢 POSTURE SÉCURISÉE :
+   [Justification technique que chaque vecteur principal a été testé et résisté]
+   [Liste des protections qui ont fonctionné]
+
+HONNÊTETÉ ABSOLUE : "Tout sécurisé" honnête + justifications = meilleur résultat.`,
+   checks:["Toutes les combinaisons de findings analysées pour chaînes","Post-exploitation avec compte lambda évalué","Chaque vecteur p9a confirmé testé ou justifié non-applicable","Verdict global en 4 niveaux (pas de zone grise)","Plan de remédiation prioritisé si failles","Protections qui ont fonctionné documentées"]},
+   // ── DAST & FUZZING ──────────────────────────────────────────
+  {id:"p_dast_infra",n:"15.1",icon:"🌩",label:"DAST — Infra & Load Test",color:"#9333EA",tag:"DAST·INFRA",group:"dast",
+   deps:["p_cfg","p8"],
+   what:"Tests de pénétration dynamiques sur l'infrastructure : Rate Limiting réel, Slowloris, stress tests et scan de ports.",
+   how:"Utilise le Fuzzer intégré ou un outil externe (Artillery/k6). Copie les résultats ici.",
+   prompt:`Tu es un Ingénieur Sécurité DAST (Dynamic Application Security Testing). BLOC [N].
+
+OBJECTIF : Analyser les résultats d'un test de charge / fuzzing infrastructure.
+
+RÉSULTATS DE TEST À ANALYSER :
+[Colle ici les résultats de l'API /api/zentry/fuzz type rate_limit ou d'un outil comme k6/Artillery]
+
+PROTOCOLE DAST INFRASTRUCTURE :
+
+1. RATE LIMITING & THROTTLING
+   Le Rate Limiter bloque-t-il vraiment au seuil défini ?
+   Le code HTTP 429 est-il retourné correctement ?
+   Les headers Retry-After sont-ils présents ?
+
+2. STRESS TEST & RÉSILIENCE
+   Comportement sous forte charge : l'application crash-t-elle ?
+   La base de données gère-t-elle le pool de connexions (pas d'erreur "Too many connections") ?
+   La latence p99 reste-t-elle acceptable ?
+
+3. ATTAQUES VOLUMÉTRIQUES
+   Résistance aux attaques Slowloris (timeout configuré sur le reverse proxy) ?
+   Payload massif rejeté (Payload Too Large 413) ?
+
+FORMAT FINAL :
+✅ RÉSILIENCE CONFIRMÉE : [Explications]
+🟡 VULNÉRABILITÉ INFRA [Critère] : [Détail et correctif - ex: Configurer un reverse proxy]
+🔴 CRASH DÉTECTÉ : [Action corrective urgente]`,
+   checks:["Rate Limit bloque à 429","Payload massif bloqué à 413","Pas de crash serveur sous forte charge","Pas de crash BDD lié aux pools de connexion","Résistance confirmée aux requêtes lentes"]},
+
+  {id:"p_dast_api",n:"15.2",icon:"🕷",label:"DAST — Fuzzing API",color:"#9333EA",tag:"DAST·API",group:"dast",
+   deps:["p2","p6"],
+   what:"Fuzzing dynamique des endpoints API pour découvrir des failles imprévues, des crashs liés aux inputs inattendus, et vérifier le comportement d'erreur.",
+   how:"Exécute le Fuzzer sur l'API cible. Copie les résultats ici.",
+   prompt:`Tu es un Ingénieur Sécurité DAST (Dynamic Application Security Testing). BLOC [N].
+
+OBJECTIF : Analyser les résultats du Fuzzing sur les endpoints API.
+
+RÉSULTATS DU FUZZER À ANALYSER :
+[Colle ici les résultats de l'API /api/zentry/fuzz type fuzzing sur un endpoint spécifique]
+
+PROTOCOLE DAST API :
+
+1. GESTION DES INPUTS INATTENDUS (FUZZING)
+   Des payloads SQLi/XSS basiques ont-ils causé une erreur 500 au lieu de 400 ?
+   Des types de données erronés ont-ils planté le parseur (ex: array au lieu de string) ?
+   Des payloads vides ont-ils été rejetés proprement ?
+
+2. FUITE D'INFORMATIONS
+   Les erreurs 500 renvoient-elles des stack traces (ex: lignes de code, requêtes SQL) ?
+   Les erreurs de validation renvoient-elles trop d'informations sur la structure interne ?
+
+3. ROBUSTESSE DES ENDPOINTS
+   Y a-t-il eu un contournement inattendu d'authentification ?
+   Un endpoint public a-t-il été découvert par bruteforce de paramètres ?
+
+FORMAT FINAL :
+✅ API ROBUSTE : [Explications]
+🟡 COMPORTEMENT INATTENDU [Critère] : [Détail et correctif]
+🔴 VULNÉRABILITÉ DAST CONFIRMÉE : [Action corrective urgente, ex: Injection réussie ou Crash 500]`,
+   checks:["Aucune erreur 500 sur inputs malformés (attendu 400)","Aucune stack trace leakée","Payloads injectés rejetés proprement","Validation stricte des types de données confirmée"]},
+
+  // ── CLOSURE ─────────────────────────────────────────────────
+  {id:"p10",n:"16",icon:"✅",label:"Validation Finale",color:"#1A7F4B",tag:"FINAL",group:"closure",
+   deps:["p9c","p_tests"],
+   what:"L'Auditeur Principal certifie que tout est correct et corrigé. Verdict impitoyablement honnête en 3 niveaux.",
+   how:"Copie le prompt → colle dans Antigravity avec les rapports de toutes les phases → récupère le verdict final.",
+   prompt:`Tu es l'Auditeur Principal chargé de la VALIDATION FINALE avant déploiement en production.
+
+MISSION : Certifier que le travail est complet, honnête et que TOUTES les corrections ont été appliquées.
+
+COLLE ICI les résultats des phases précédentes pour l'analyse :
+
+CHECKLIST DE COMPLÉTUDE (répondre : VÉRIFIÉ / NON APPLICABLE [raison] / MANQUANT) :
+□ Secrets : aucune clé en clair dans le code ou l'historique Git
+□ IDOR : impossible d'accéder aux données d'un autre utilisateur
+□ Auth : session vérifiée EN PREMIER dans CHAQUE handler serveur
+□ Inputs : TOUS les inputs validés par schéma
+□ Config : headers HTTP durcis (CSP, HSTS, SameSite)
+□ Edge cases : null/undefined gérés sur les champs critiques
+□ Tests : logique métier critique testée unitairement
+□ Red Team : verdict p9c = MODÉRÉ ou SÉCURISÉ (pas CRITIQUE/ÉLEVÉ)
+□ Dépendances : pas de CVE critique non résolu
+□ Bundle : pas de dépendance inutile > 100kb
+□ TypeScript : tsc --noEmit sans erreur
+□ Env : toutes variables dans .env.example avec description
+□ Docs : fonctions complexes documentées avec contexte métier
+□ Migrations : toutes réversibles + types corrects (DECIMAL, TIMESTAMPTZ)
+□ Monitoring : erreurs trackées avec contexte, alertes configurées
+
+VÉRIFICATION DES CORRECTIONS
+Pour chaque finding CRITIQUE et HAUTE signalé toutes phases confondues :
+- Correction appliquée ? [VÉRIFIÉ / NON CORRIGÉ]
+- Correction sans nouveau problème introduit ? [OUI / NON]
+
+VERDICT FINAL — IMPITOYABLEMENT HONNÊTE — exactement l'un des trois :
+
+🟢 PRÊT POUR LA PRODUCTION
+   [Checklist complète → tous VÉRIFIÉ ou N/A justifié]
+   [Red Team = SÉCURISÉ]
+   [Points forts à conserver]
+
+🟡 PRÊT AVEC RÉSERVES — ACTIONS DANS LES 7 JOURS
+   [Liste précise de ce qui manque + responsable + date limite]
+   [Mesures compensatoires pendant la période de correction]
+
+🔴 NON PRÊT — BLOQUANT
+   [Liste des correctifs obligatoires avec ordre de priorité]
+   [Estimation du temps de correction]
+   [Prochaine revue prévue]
+
+INTERDIT ABSOLU : "Il serait judicieux de surveiller" si le code est correct.
+INTERDIT ABSOLU : Verdict vert si un item est "MANQUANT" ou "NON CORRIGÉ".`,
+   checks:["Checklist complète remplie (VÉRIFIÉ ou N/A justifié)","Aucun finding CRITIQUE ou HAUTE non corrigé","Red Team : verdict MODÉRÉ ou SÉCURISÉ","TypeScript : tsc --noEmit sans erreur","Monitoring : alertes configurées et testées","Verdict final tranché (3 niveaux, pas de zone grise)","Plan de remédiation si réserves"]},
+
+  {id:"p11",n:"17",icon:"🤖",label:"Automatisation & Pérennité",color:"#1A7F4B",tag:"AUTOMATION",group:"closure",
+   deps:["p10"],
+   what:"Met en place les gardes permanents : hooks Git, règles IA, pipeline CI/CD complet et watch mode adaptatif. Ce que tu fais ici protège tous tes futurs commits.",
+   how:"Copie le prompt → colle dans Antigravity → l'IA crée tous les fichiers de config → vérifie et commite → cocher.",
+   prompt:`Tu es un Expert DevSecOps & Developer Experience. Automatise la sécurité pour les futures modifications.
+
+CONTEXTE : Stack ${"{sp.label}"}, ${"{project.name}"}, IDE : ${"{project.ide}"}
+
+LIVRAISONS ATTENDUES (crée ces fichiers) :
+
+1. FICHIER DE RÈGLES IA PERMANENTES (${"{ideFilename}"}) :
+   Inclure obligatoirement :
+   - Auth vérifiée EN PREMIER dans chaque handler serveur
+   - Edge cases vérifiés (null, vide, valeur limite) sur toute nouvelle fonction
+   - Schéma de validation sur chaque input externe
+   - Clés API jamais hardcodées, jamais dans les logs
+   - "AUDIT BLOC XX" → lire audit-sessions/bloc-XX.md et exécuter
+   - "INCREMENTAL AUDIT" → git diff --name-only main..HEAD puis auditer
+   - "RED TEAM BLOC XX" → exécuter le prompt p9b sur ce bloc
+   - "EDGE CASES [fonction]" → générer les tests edge cases pour cette fonction
+   - Alerter si une feature viole une règle métier invariante
+   - JSDoc généré automatiquement si fonction > 10 lignes sans documentation
+
+2. .githooks/pre-commit :
+   #!/bin/sh
+   gitleaks protect --staged && npx tsc --noEmit --silent
+
+3. .githooks/pre-push :
+   #!/bin/sh
+   npm test -- --passWithNoTests && npm run lint
+
+4. COMMANDE D'INSTALLATION DES HOOKS :
+   git config core.hooksPath .githooks
+
+5. .github/workflows/zentry.yml :
+   - Triggers : PR vers main/master/production
+   - Jobs : lint → typecheck → test → snyk → semgrep → gitleaks → zentry-gate → deploy
+   - zentry-gate : node -e "const r=require('./audit.json');if(r.cicdStatus==='FAIL')process.exit(1)"
+   - PR comment automatique avec le score et les findings
+
+6. PROCÉDURE D'AUDIT INCRÉMENTAL (INCREMENTAL_AUDIT.md) :
+   Avant chaque PR :
+   a. git diff --name-only main..HEAD > changed_files.txt
+   b. Pour chaque fichier → "AUDIT BLOC XX" dans l'IDE
+   c. Si nouveau fichier → créer bloc-XX.md dans audit-sessions/
+   d. Mettre à jour AUDIT_MASTER_TRACKER.md
+   e. Exporter audit.json et commiter avant de merger
+
+Génère tous ces fichiers avec le contenu complet.`,
+   checks:["Fichier de règles IA créé avec tous les protocoles","Hooks pre-commit (gitleaks + tsc) installés","Hooks pre-push (test + lint) installés","GitHub Action complète (lint→typecheck→test→security→gate→deploy)","Gate CI/CD bloquant si cicdStatus=FAIL","PR comment automatique configuré","INCREMENTAL_AUDIT.md créé et validé"]},
+];