05-delta · 2–6 h · 5 min
Re-audit : qu’est-ce qui a bougé après les correctifs.
Tu as déjà un journal et une QA. Tu as patché. La question n’est plus « y a-t-il des trous » : c’est « lesquels sont encore ouverts ». Le mode Delta compare au snapshot. Il n’ouvre pas un second dossier pour faire semblant d’un nouvel audit.
- Quand l’ouvrir
- Une passe 2, 3 ou 4 a déjà produit un journal
- Après une vague de correctifs, ou « qu’est-ce qui a bougé ? »
- Même projet, même dossier — pas un clone « …-delta »
- Agents
- 00, 01, spécialiste delta-reaudit, 10, 11
- Hors de ce mode
- S’il n’existe aucun finding antérieur, ce n’est pas un delta — ouvre Web, SaaS ou MCP
- Toute classe absente de la baseline reste hors scope, sauf nouvelle origine au brief
Le geste
Avant toute collecte neuve : snapshot daté (project.yaml, findings, coverage). Puis collecte ciblée sur les mêmes classes. Re-vérif des findings ouverts (GET/HEAD sur l’URL de la preuve). Rescore. QA sur le delta et les Confirmé encore ouverts. Livrable delta-compare.
Ce que ça n’est pas
Pas un Complet déguisé. Pas un red-team. Pas un rapport board automatique. Si tu veux la synthèse décideur après le delta, tu enchaînes le mode 8 — seulement si la QA a signé.
Phrase type
Delta sur le projet déjà ouvert. Snapshot d’abord. Relis les findings ouverts.
Avant de lancer
- Premier audit ?
- Alors ce n’est pas un Delta. Express, Complet Web, Complet SaaS ou MCP, selon le produit.
Le kit, pas le guide.
Open source, MIT. Tu clones, tu l’ouvres dans Claude, Codex, Cursor ou Hermes. Rapport tenu — ou le silence de la QA.