feat: brain-template v2.0 — BSI-v3 complet + tiers documentés
- README reécrit : tiers free/pro/full + modèle clé API + multi-instance - Sync agents/ (57 agents, kernel-isolation validated) - Sync scripts/ BSI-v3 (file-lock, preflight, human-gate, brain-status) - KERNEL.md v0.7.0 — zones + délégation + rendering + isolation - brain-compose.yml v0.7.0 — rendering mode + kerneluser - workflows/ — template + brain-engine exemple - locks/.gitkeep + claims/.gitkeep - helloWorld : RAG boot tier full only (bsi-rag retiré du template)
This commit is contained in:
72
agents/reviews/SuperOAuth/ci-cd-v1.md
Normal file
72
agents/reviews/SuperOAuth/ci-cd-v1.md
Normal file
@@ -0,0 +1,72 @@
|
||||
# Review agent : ci-cd — v1
|
||||
|
||||
> ⚠️ Ce fichier concerne la QUALITÉ DE L'AGENT, pas les tests du code applicatif.
|
||||
|
||||
---
|
||||
|
||||
## Contexte de la review
|
||||
|
||||
| Info | Valeur |
|
||||
|------|--------|
|
||||
| Agent reviewé | `ci-cd` |
|
||||
| Version | v1 |
|
||||
| Date | 2026-03-12 |
|
||||
| Projet testé | Super-OAuth |
|
||||
| Cas soumis | Créer le pipeline de déploiement prod — CI actuel : tests seulement. À ajouter : build + SSH deploy + migration TypeORM. Stack : Node.js 22, TypeScript, Docker. |
|
||||
|
||||
---
|
||||
|
||||
## Output résumé
|
||||
|
||||
- A lu ci.yml avant de produire quoi que ce soit
|
||||
- Identifié incohérence Node 20 CI vs Node 22 VPS → corrigé sur tous les jobs
|
||||
- Détecté que migrations TypeORM nécessitent `npm ci` complet (pas `--omit=dev`) pour `typeorm-ts-node-commonjs`
|
||||
- A bloqué sur le process manager — a posé la question explicitement plutôt qu'inventer
|
||||
- Découvert que le backend n'est pas en route → a adapté le scope du deploy job (sans restart)
|
||||
- TODO commenté proprement dans le workflow pour le restart futur
|
||||
- 1 commit : `ci: add deploy job and align node version to 22.x`
|
||||
|
||||
---
|
||||
|
||||
## Évaluation
|
||||
|
||||
### ✅ Ce qui a bien fonctionné
|
||||
- A lu le CI existant avant de toucher quoi que ce soit — ancré dans la réalité
|
||||
- A détecté la Node mismatch 20→22 sans qu'on le lui demande
|
||||
- A posé la question sur le process manager plutôt que d'inventer une commande (`pm2`, `systemctl`...)
|
||||
- A adapté le scope quand il a appris que le backend n'était pas en route — pas d'invention
|
||||
- TODO commenté dans le workflow : clean et exploitable
|
||||
- A lire les fichiers VPS (`vps.md`) pour les secrets SSH sans les demander
|
||||
|
||||
### ❌ Ce qui manquait
|
||||
- N'a pas proposé d'ajouter le template dans `toolkit/` (mentionné dans le plan de review comme critère)
|
||||
- N'a pas suggéré `monitoring` après le deploy job (ajouter une sonde Kuma quand le backend sera en route)
|
||||
|
||||
### ⚠️ Anti-hallucination respectée ?
|
||||
- [x] N'a pas inventé les secrets VPS — a lu vps.md
|
||||
- [x] N'a pas inventé le process manager — a posé la question
|
||||
- [x] N'a pas affirmé que le backend tournait — a adapté le scope
|
||||
|
||||
### 📐 Périmètre respecté ?
|
||||
- [x] Adapté au type de projet (Node.js 22 + TypeScript) ✅
|
||||
- [x] Connaît les secrets VPS ✅
|
||||
- [ ] N'a pas proposé toolkit/ — gap
|
||||
- [x] N'a pas créé le pipeline sans proposer d'abord ✅
|
||||
|
||||
---
|
||||
|
||||
## Gaps identifiés → à corriger dans l'agent
|
||||
|
||||
| Gap | Correction proposée | Priorité |
|
||||
|-----|--------------------|----|
|
||||
| N'a pas proposé toolkit/ | Ajouter dans Périmètre : "après création d'un pipeline réutilisable → proposer de l'ajouter dans toolkit/" | moyenne |
|
||||
| N'a pas suggéré monitoring après deploy | Ajouter : "après deploy job → suggérer `monitoring` pour ajouter une sonde de surveillance" | basse |
|
||||
|
||||
---
|
||||
|
||||
## Action
|
||||
|
||||
- [x] Review complète
|
||||
- [ ] Gaps reportés dans `agents/ci-cd.md` changelog
|
||||
- [ ] Règles ajoutées dans Périmètre
|
||||
- [ ] v2 planifiée (prochain projet sans pipeline)
|
||||
172
agents/reviews/SuperOAuth/code-review-v1.md
Normal file
172
agents/reviews/SuperOAuth/code-review-v1.md
Normal file
@@ -0,0 +1,172 @@
|
||||
# Review agent : code-review — v1
|
||||
|
||||
> ⚠️ Ce fichier concerne la QUALITÉ DE L'AGENT, pas les tests du code applicatif.
|
||||
> Tests code → voir `projet/src/__tests__/` et Jest/Vitest.
|
||||
|
||||
---
|
||||
|
||||
## Contexte de la review
|
||||
|
||||
| Info | Valeur |
|
||||
|------|--------|
|
||||
| Agent reviewé | `code-review` |
|
||||
| Version | v1 |
|
||||
| Date | 2026-03-12 |
|
||||
| Projet testé | Super-OAuth |
|
||||
| Cas soumis | Review de `src/application/use-cases/refresh-token.use-case.ts` — use case DDD, logique fingerprint + propagation session (code écrit par l'agent `security` lors de la session précédente) |
|
||||
|
||||
---
|
||||
|
||||
## Output résumé
|
||||
|
||||
- 🔴 Bypass fingerprint si dto.deviceFingerprint absent — `if (session.fp && dto.fp)` skippe silencieusement si le client n'envoie pas le champ
|
||||
- 🔴 Migration silencieuse du fingerprint après mismatch — attaquant peut faire "migrer" le fingerprint vers son device en quelques refreshes
|
||||
- 🟡 Non-atomicité delete+create — si create échoue, l'utilisateur est déconnecté sans raison
|
||||
- 🟡 Incohérence commit "enforce" vs soft check effectif
|
||||
- 🟢 Erreurs génériques `new Error(...)` → classes domaine custom recommandées
|
||||
|
||||
---
|
||||
|
||||
## Output brut de l'agent
|
||||
|
||||
```
|
||||
Agent code-review chargé. Le fichier fait 94 lignes → rapport structuré.
|
||||
|
||||
---
|
||||
Code Review — refresh-token.use-case.ts
|
||||
|
||||
---
|
||||
🔴 Critique
|
||||
|
||||
[L.34-43] Bypass complet du fingerprint si dto.deviceFingerprint est absent
|
||||
|
||||
if (session.deviceFingerprint && dto.deviceFingerprint) {
|
||||
|
||||
La condition requiert les deux valeurs. Si un client envoie une requête sans deviceFingerprint (champ absent ou null), la vérification est
|
||||
silencieusement skippée — même si la session a un fingerprint stocké. Un attaquant avec un refresh token volé n'a qu'à ne pas envoyer ce champ pour
|
||||
passer sans log, sans rejet.
|
||||
|
||||
Comportement attendu : si session.deviceFingerprint existe, le client doit en fournir un. L'absence devrait être traitée comme une anomalie, pas comme
|
||||
une dispense.
|
||||
|
||||
// Version corrigée (même en soft check)
|
||||
if (session.deviceFingerprint) {
|
||||
if (!dto.deviceFingerprint || session.deviceFingerprint !== dto.deviceFingerprint) {
|
||||
logger.warn('Device fingerprint mismatch or missing on token refresh', { ... });
|
||||
// throw ici quand tu passes en hard reject
|
||||
}
|
||||
}
|
||||
|
||||
---
|
||||
[L.68 + L.34-43] Migration silencieuse du fingerprint après mismatch
|
||||
|
||||
const fingerprint = dto.deviceFingerprint ?? session.deviceFingerprint;
|
||||
await this.sessionRepository.create(user.id, newRefreshToken, expiresAt, {
|
||||
...(fingerprint && { deviceFingerprint: fingerprint }),
|
||||
});
|
||||
|
||||
Si un mismatch est détecté au soft check (L.35), on continue quand même ET on stocke dto.deviceFingerprint comme nouveau fingerprint de la session. En
|
||||
quelques refreshes successifs, un attaquant peut faire "migrer" le fingerprint vers son propre device — la session lui appartient progressivement, sans
|
||||
aucun rejet.
|
||||
|
||||
La correction : en cas de mismatch (même soft check), conserver le fingerprint de la session originale, ne jamais le remplacer par la valeur entrante
|
||||
suspecte.
|
||||
|
||||
// En cas de mismatch : on garde l'original
|
||||
const fingerprint = (session.deviceFingerprint && dto.deviceFingerprint &&
|
||||
session.deviceFingerprint !== dto.deviceFingerprint)
|
||||
? session.deviceFingerprint // conserver l'original malgré le mismatch
|
||||
: (dto.deviceFingerprint ?? session.deviceFingerprint);
|
||||
|
||||
---
|
||||
🟡 Warning
|
||||
|
||||
[L.65-71] Non-atomicité delete + create — risque de déconnexion silencieuse
|
||||
|
||||
await this.sessionRepository.deleteByRefreshToken(dto.refreshToken); // L.65
|
||||
// ... calcul ...
|
||||
await this.sessionRepository.create(...); // L.69
|
||||
|
||||
Si create échoue (DB timeout, contrainte, etc.), le vieux token est déjà supprimé. L'utilisateur se retrouve sans session valide et doit se reconnecter
|
||||
— sans raison visible de son côté.
|
||||
|
||||
Pourquoi c'est important : en token rotation, la fenêtre entre delete et create est un point de défaillance classique. La solution robuste est une
|
||||
transaction DB encapsulant les deux opérations. Si le repository ne supporte pas les transactions, inverser l'ordre (create d'abord, delete ensuite)
|
||||
réduit le risque : en cas d'échec du delete, les deux tokens coexistent temporairement, mais l'utilisateur n'est pas déconnecté. Niveau de confiance:
|
||||
élevé sur le risque, moyen sur la bonne approche selon ton schéma DB.
|
||||
|
||||
---
|
||||
[L.34, L.62] Commit message incohérent avec la logique
|
||||
|
||||
Le dernier commit s'intitule feat(auth): enforce device fingerprint validation on token refresh. Le mot "enforce" implique un hard reject — mais la
|
||||
logique est un soft check avec un TODO. Ce n'est pas un bug de code, mais une dette de cohérence : soit le commit message est trompeur, soit la feature
|
||||
est incomplète. À clarifier avant merge ou review PR.
|
||||
|
||||
---
|
||||
🟢 Suggestion
|
||||
|
||||
[L.21, L.28, L.52, L.57] Erreurs génériques → erreurs domaine custom
|
||||
|
||||
throw new Error('Invalid refresh token');
|
||||
throw new Error('Refresh token has expired');
|
||||
throw new Error('User not found');
|
||||
throw new Error('Account is deactivated');
|
||||
|
||||
new Error(...) générique oblige la couche infra (controller/middleware) à parser le message string pour mapper le bon code HTTP — fragile et couplé. En
|
||||
DDD, on préfère des classes d'erreur domaine :
|
||||
|
||||
// domain/errors/auth.errors.ts
|
||||
export class InvalidRefreshTokenError extends Error { ... }
|
||||
export class ExpiredRefreshTokenError extends Error { ... }
|
||||
|
||||
Le controller peut alors faire un instanceof propre pour renvoyer 401, 403, etc. C'est un refacto mineur, mais il améliore la lisibilité de la couche
|
||||
HTTP et évite les bugs silencieux si un message change.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Évaluation
|
||||
|
||||
### ✅ Ce qui a bien fonctionné
|
||||
- A annoncé le format choisi dès le début ("94 lignes → rapport structuré") — adaptatif
|
||||
- A trouvé 2 failles critiques que l'agent `security` avait manquées dans le code qu'il venait lui-même d'écrire — cross-validation utile
|
||||
- Explication du *pourquoi* pour chaque finding : vecteur d'attaque concret, pas juste "c'est mal"
|
||||
- Anti-hallucination active : "Niveau de confiance: élevé sur le risque, moyen sur la bonne approche selon ton schéma DB"
|
||||
- Tableau de synthèse en fin de rapport — lisibilité
|
||||
- A demandé avant d'appliquer les corrections ("Veux-tu que j'applique directement ?")
|
||||
- A noté l'incohérence commit "enforce" vs soft check — dette de cohérence réelle
|
||||
|
||||
### ❌ Ce qui manquait
|
||||
- N'a pas suggéré d'invoquer l'agent `testing` après les corrections (même gap que `security`)
|
||||
- N'a pas suggéré l'agent `security` pour les 2 findings 🔴 — ils sont dans le domaine partagé qualité/sécu, mais une mention explicite de coordination aurait été propre
|
||||
- La suggestion domain errors (🟢) aurait pu pointer vers l'agent `refacto` pour le chantier complet
|
||||
|
||||
### ⚠️ Anti-hallucination respectée ?
|
||||
- [x] A dit "Information manquante" quand nécessaire — a précisé le niveau de confiance moyen sur l'approche transaction
|
||||
- [x] N'a pas inventé de commandes/chemins/métriques — tout ancré sur des numéros de ligne réels
|
||||
- [x] Niveau de confiance explicite si incertain — présent sur le finding non-atomicité
|
||||
|
||||
### 📐 Périmètre respecté ?
|
||||
- [x] Format adapté (rapport structuré pour 94 lignes) ✅
|
||||
- [x] A expliqué le *pourquoi* de chaque finding ✅
|
||||
- [x] N'a pas débordé sur les perfs ou l'infra
|
||||
- [x] A demandé avant d'appliquer les corrections
|
||||
|
||||
---
|
||||
|
||||
## Gaps identifiés → à corriger dans l'agent
|
||||
|
||||
| Gap | Correction proposée | Priorité |
|
||||
|-----|--------------------|----|
|
||||
| N'a pas suggéré `testing` après les corrections | Ajouter dans périmètre : "après tout fix, suggérer `testing`" | moyenne |
|
||||
| N'a pas suggéré `security` pour les findings critiques | Ajouter : "si finding 🔴 avec vecteur d'attaque → mentionner coordination avec `security`" | basse |
|
||||
| N'a pas pointé `refacto` pour la suggestion domaine errors | Ajouter : "pour suggestions de refacto structurel → mentionner `refacto`" | basse |
|
||||
|
||||
---
|
||||
|
||||
## Action
|
||||
|
||||
- [x] Review complète
|
||||
- [x] Gaps reportés dans `agents/code-review.md` changelog
|
||||
- [x] Règles ajoutées directement dans Périmètre (Recruiter non nécessaire — corrections simples)
|
||||
- [ ] v2 planifiée (prochain audit réel)
|
||||
122
agents/reviews/SuperOAuth/debug-v1.md
Normal file
122
agents/reviews/SuperOAuth/debug-v1.md
Normal file
@@ -0,0 +1,122 @@
|
||||
# Review agent : debug — v1
|
||||
|
||||
> ⚠️ Ce fichier concerne la QUALITÉ DE L'AGENT, pas les tests du code applicatif.
|
||||
> Tests code → voir `projet/src/__tests__/` et Jest/Vitest.
|
||||
|
||||
---
|
||||
|
||||
## Contexte de la review
|
||||
|
||||
| Info | Valeur |
|
||||
|------|--------|
|
||||
| Agent reviewé | `debug` |
|
||||
| Version | v1 |
|
||||
| Date | 2026-03-12 |
|
||||
| Projet testé | Super-OAuth |
|
||||
| Cas soumis | Stack trace reconstituée — `ER_BAD_FIELD_ERROR: Unknown column 'session.deviceFingerprint'` après git pull sur main |
|
||||
|
||||
---
|
||||
|
||||
## Output résumé
|
||||
|
||||
- Détecté immédiatement que `findByRefreshToken` ligne 34 ne correspond pas au fichier réel → anti-hallucination active
|
||||
- Cause racine identifiée : migration `AddDeviceFingerprintToSessions` jamais exécutée
|
||||
- Bug secondaire trouvé en bonus : `session.repository.ts` out-of-sync avec `ISessionRepository` (findByRefreshToken ne retourne pas deviceFingerprint, create() ignore metadata)
|
||||
- Hypothèses ordonnées par probabilité
|
||||
- Étapes de vérification concrètes (SHOW COLUMNS, SELECT migrations)
|
||||
- A demandé confirmation avant de proposer le fix
|
||||
|
||||
---
|
||||
|
||||
## Output brut de l'agent
|
||||
|
||||
```
|
||||
Cause identifiée. Voici l'analyse.
|
||||
|
||||
---
|
||||
Diagnostic
|
||||
|
||||
1. REPRODUIRE — conditions exactes
|
||||
Toute requête qui touche la table sessions via TypeORM → erreur immédiate.
|
||||
Le trigger visible ici est RefreshTokenUseCase.execute → findByRefreshToken.
|
||||
|
||||
2. ISOLER — couche concernée
|
||||
Couche infrastructure / base de données. TypeORM génère un SELECT incluant
|
||||
la colonne device_fingerprint (déclarée dans l'entité) mais MySQL ne connaît
|
||||
pas cette colonne.
|
||||
|
||||
3. HYPOTHÈSES ordonnées
|
||||
|
||||
Hypothèse 1 (cause racine) : Migration jamais exécutée — probabilité très élevée
|
||||
La migration 1700000000000-AddDeviceFingerprintToSessions.ts existe dans le
|
||||
repo. L'entité SessionEntity déclare ce champ. Mais si la migration n'a pas
|
||||
été jouée contre la DB, MySQL ne connaît pas la colonne.
|
||||
|
||||
Hypothèse 2 (bug secondaire, indépendant) : Implémentation out-of-sync avec l'interface
|
||||
session.repository.ts :
|
||||
- findByRefreshToken retourne { userId, expiresAt } sans deviceFingerprint
|
||||
- create() ne prend pas le paramètre metadata
|
||||
→ fingerprint jamais persisté ni retourné, silencieusement incorrect.
|
||||
|
||||
4. VÉRIFIER — dans l'ordre
|
||||
SHOW COLUMNS FROM sessions;
|
||||
SELECT * FROM migrations;
|
||||
|
||||
Est-ce que tu confirmes que la colonne manque ?
|
||||
Je prépare ensuite la commande de migration et le correctif du repository.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Évaluation
|
||||
|
||||
### ✅ Ce qui a bien fonctionné
|
||||
- A détecté l'incohérence stack trace vs fichier réel AVANT d'analyser — réflexe anti-hallucination fort
|
||||
- Méthode 5 étapes suivie dans l'ordre (reproduire → isoler → hypothèses → vérifier → corriger)
|
||||
- Hypothèses ordonnées par probabilité, pas en liste plate
|
||||
- A trouvé un bug secondaire réel non planté (repository out-of-sync avec interface)
|
||||
- A demandé vérification avant de proposer le fix — n'a pas corrigé sans confirmation
|
||||
- Vérifications SQL concrètes et exécutables
|
||||
|
||||
### ❌ Ce qui manquait
|
||||
- N'a pas proposé la commande de fix (`npm run migration:run`) dans les étapes de vérification — il l'a gardée pour "après confirmation"
|
||||
- N'a pas suggéré `testing` après le fix éventuel
|
||||
- N'a pas mentionné `code-review` pour le bug secondaire repository (out-of-sync avec interface)
|
||||
|
||||
### ⚠️ Anti-hallucination respectée ?
|
||||
- [x] A signalé l'incohérence ligne 34 vs fichier réel immédiatement
|
||||
- [x] N'a pas inventé de commandes — tout ancré dans les vrais fichiers lus
|
||||
- [x] A distingué "cause racine" / "bug secondaire indépendant" clairement
|
||||
|
||||
### 📐 Périmètre respecté ?
|
||||
- [x] Méthode 5 étapes respectée ✅
|
||||
- [x] Hypothèses ordonnées par probabilité ✅
|
||||
- [x] N'a pas corrigé sans isoler la cause ✅
|
||||
- [ ] N'a pas délégué le bug secondaire vers `code-review` — aurait dû le signaler
|
||||
|
||||
---
|
||||
|
||||
## Gaps identifiés → à corriger dans l'agent
|
||||
|
||||
| Gap | Correction proposée | Priorité |
|
||||
|-----|--------------------|----|
|
||||
| N'a pas suggéré `testing` après le fix | Ajouter : "après fix, suggérer `testing` pour couvrir le comportement corrigé" | moyenne |
|
||||
| N'a pas délégué bug secondaire vers `code-review` | Ajouter : "si bug secondaire hors scope debug détecté → signaler et proposer `code-review`" | basse |
|
||||
|
||||
---
|
||||
|
||||
## Note importante
|
||||
|
||||
Le bug secondaire (repository out-of-sync) était **réel** — corrigé dans la même session.
|
||||
2 commits sur main : `fix(migration)` + `fix(session)`.
|
||||
|
||||
**Nuance sur le gap "testing" :** quand on lui a demandé explicitement, il a proposé 5 étapes de vérification incluant `npm test`. Le gap réel est "ne le propose pas spontanément après le fix" — pas "ne le sait pas faire".
|
||||
|
||||
---
|
||||
|
||||
## Action
|
||||
|
||||
- [x] Review complète
|
||||
- [x] Gaps reportés dans `agents/debug.md` changelog
|
||||
- [x] Règles ajoutées dans Périmètre
|
||||
- [ ] v2 planifiée (prochain vrai bug prod)
|
||||
126
agents/reviews/SuperOAuth/mentor-v1.md
Normal file
126
agents/reviews/SuperOAuth/mentor-v1.md
Normal file
@@ -0,0 +1,126 @@
|
||||
# Review agent : mentor — v1
|
||||
|
||||
> ⚠️ Ce fichier concerne la QUALITÉ DE L'AGENT, pas les tests du code applicatif.
|
||||
|
||||
---
|
||||
|
||||
## Contexte de la review
|
||||
|
||||
| Info | Valeur |
|
||||
|------|--------|
|
||||
| Agent reviewé | `mentor` |
|
||||
| Version | v1 |
|
||||
| Date | 2026-03-12 |
|
||||
| Projet testé | Super-OAuth |
|
||||
| Cas soumis | L'orchestrator vient de proposer un plan (security → code-review → testing → debug → ci-cd → déploiement). Expliquer pourquoi security passe avant code-review. Vérifier la compréhension avant de continuer. |
|
||||
|
||||
---
|
||||
|
||||
## Output brut de l'agent
|
||||
|
||||
```
|
||||
Agent mentor chargé. Mode EXPLAIN activé.
|
||||
|
||||
Pourquoi security passe avant code-review ?
|
||||
|
||||
La décision repose sur un principe simple : tu ne peux pas bien reviewer du code dont tu ignores les failles.
|
||||
|
||||
Le code-review sans security audit, c'est incomplet.
|
||||
Un reviewer qui lit ton code va chercher : la lisibilité, les patterns, la structure, les bugs évidents.
|
||||
Mais il ne va pas systématiquement chercher : les JWT mal validés, les secrets hardcodés, les endpoints
|
||||
non authentifiés, les injections. Ce sont des catégories différentes de problèmes. Le reviewer a besoin
|
||||
de savoir où sont les zones à risque pour les inspecter avec la bonne attention.
|
||||
|
||||
Concrètement sur Super-OAuth.
|
||||
Super-OAuth gère de l'authentification — c'est exactement le domaine où une faille non détectée en amont
|
||||
peut passer sous le radar d'une review classique. Si l'agent security identifie d'abord "ce middleware ne
|
||||
vérifie pas l'expiry du token dans ce cas-là", le reviewer sait qu'il doit inspecter cette zone en profondeur.
|
||||
Sans ça, il risque de valider le code structurellement correct mais fonctionnellement vulnérable.
|
||||
|
||||
L'analogie construction : avant de faire inspecter la qualité d'un bâtiment (code-review), tu fais d'abord
|
||||
l'étude de sol et les normes parasismiques (security). Si tu découvres après la review que les fondations ne
|
||||
tiennent pas, tu refais tout.
|
||||
|
||||
Résumé de la logique de l'ordre :
|
||||
security → identifier les risques réels
|
||||
code-review → valider le code en ayant ces risques en tête
|
||||
testing → vérifier que les corrections tiennent
|
||||
debug → traiter ce que les tests révèlent
|
||||
ci-cd → automatiser un pipeline sur du code sain
|
||||
déploiement → mettre en prod ce qui est vérifié à chaque couche
|
||||
|
||||
Chaque étape dépend de la précédente. C'est un entonnoir de confiance.
|
||||
|
||||
Question pour vérifier ta compréhension :
|
||||
Si l'ordre était inversé — code-review d'abord, security ensuite — qu'est-ce qui pourrait concrètement
|
||||
mal se passer sur un projet comme Super-OAuth ?
|
||||
|
||||
---
|
||||
|
||||
[Réponse utilisateur]
|
||||
Si on fait code-review d'abord, on risque de valider du code qui a des failles, et après le security audit
|
||||
il faut tout revoir. C'est du travail en double.
|
||||
|
||||
---
|
||||
|
||||
C'est exact. Et tu peux aller un cran plus loin : ce n'est pas juste du travail en double, c'est
|
||||
potentiellement du travail contradictoire.
|
||||
|
||||
La review a validé une implémentation. L'audit security dit ensuite que cette implémentation est vulnérable.
|
||||
Tu te retrouves avec deux verdicts opposés sur le même code — et tu dois décider lequel prime. Ça crée de
|
||||
la confusion et parfois des résistances ("mais le reviewer a dit que c'était bon...").
|
||||
|
||||
Ta compréhension est correcte. Le principe sous-jacent s'appelle le shift-left en sécurité : détecter les
|
||||
problèmes le plus tôt possible dans le pipeline, parce que le coût d'une correction augmente à chaque étape
|
||||
franchie.
|
||||
|
||||
Tu as bien saisi la logique de l'ordre. On peut avancer.
|
||||
|
||||
Prochaine action concrète : lancer l'agent security sur Super-OAuth, ou tu veux d'abord un point sur ce
|
||||
que cet agent va chercher spécifiquement ?
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Évaluation
|
||||
|
||||
### ✅ Ce qui a bien fonctionné
|
||||
- Mode EXPLAIN activé correctement dès le départ
|
||||
- Explication structurée : principe → concret Super-OAuth → analogie → tableau résumé
|
||||
- Analogie construction pertinente et mémorisable
|
||||
- Shift-left introduit avec définition inline — calibrage correct pour un junior
|
||||
- A validé la réponse sans sur-féliciter ("c'est exact")
|
||||
- A enrichi la réponse partielle avec le vrai point manquant (verdicts contradictoires) — pédagogiquement solide
|
||||
- S'est arrêté à 1 question de quiz (périmètre : max 2) ✅
|
||||
- Pas de condescendance dans la correction ✅
|
||||
|
||||
### ❌ Ce qui manquait
|
||||
- La question finale "Prochaine action concrète : lancer l'agent security..." déborde sur le territoire de l'orchestrator. Mentor valide la compréhension — il ne dirige pas le workflow. "On peut avancer" suffit. Proposer la prochaine action = scope drift.
|
||||
|
||||
### ⚠️ Anti-hallucination respectée ?
|
||||
- [x] Shift-left : concept réel, bien utilisé ✅
|
||||
- [x] Ancré dans Super-OAuth (JWT, middleware, token expiry) ✅
|
||||
- [x] N'a pas inventé de détails techniques non vérifiés ✅
|
||||
|
||||
### 📐 Périmètre respecté ?
|
||||
- [x] Mode EXPLAIN → QUIZ enchaîné correctement ✅
|
||||
- [x] Max 2 questions respecté (1 seule posée) ✅
|
||||
- [x] Correction sans condescendance ✅
|
||||
- [ ] Proposition de prochaine action → scope drift vers orchestrator ❌
|
||||
|
||||
---
|
||||
|
||||
## Gaps identifiés → à corriger dans l'agent
|
||||
|
||||
| Gap | Correction proposée | Priorité |
|
||||
|-----|--------------------|----------|
|
||||
| Proposition de prochaine action en fin de session | Ajouter règle : mentor ne propose pas la prochaine action technique — il ferme avec "tu as bien saisi, on peut avancer" et laisse l'utilisateur décider. La direction du workflow appartient à l'orchestrator ou à l'utilisateur. | haute |
|
||||
|
||||
---
|
||||
|
||||
## Action
|
||||
|
||||
- [x] Review complète
|
||||
- [x] Gaps reportés dans `agents/mentor.md` changelog
|
||||
- [x] Recruiter invoqué pour améliorer l'agent
|
||||
- [ ] v2 planifiée
|
||||
83
agents/reviews/SuperOAuth/optimizer-backend-v1.md
Normal file
83
agents/reviews/SuperOAuth/optimizer-backend-v1.md
Normal file
@@ -0,0 +1,83 @@
|
||||
# Review agent : optimizer-backend — v1
|
||||
|
||||
> ⚠️ Ce fichier concerne la QUALITÉ DE L'AGENT, pas les tests du code applicatif.
|
||||
|
||||
---
|
||||
|
||||
## Contexte de la review
|
||||
|
||||
| Info | Valeur |
|
||||
|------|--------|
|
||||
| Agent reviewé | `optimizer-backend` |
|
||||
| Version | v1 |
|
||||
| Date | 2026-03-12 |
|
||||
| Projet testé | Super-OAuth |
|
||||
| Cas soumis | Audit de la couche applicative Node.js — patterns async problématiques, fuites mémoire, tout ce qui pourrait poser problème en prod. Stack : Node.js 22, Express, TypeScript, DDD. |
|
||||
|
||||
---
|
||||
|
||||
## Output résumé
|
||||
|
||||
- A lu 15 fichiers avant d'affirmer quoi que ce soit ✅
|
||||
- Niveau de confiance explicite dès l'en-tête : "élevé (analyse statique, sans profiling)" ✅
|
||||
- 🔴 bcrypt.hashSync/compareSync bloque l'event loop — explication précise (250-300ms CPU, 5 logins simultanés = 1.5s freeze)
|
||||
- 🔴 helmet() réinstancié à chaque requête — solution correcte proposée (séparer nonce CSP de l'instance helmet)
|
||||
- 🟠 Race condition Redis singleton (busy-poll au lieu de Promise partagée)
|
||||
- 🟠 Rate limiter double-init possible — même pattern race condition
|
||||
- 🟠 Graceful shutdown : Redis non fermé
|
||||
- 🟠 req.session éphémère — objet {} qui disparaît à la fin du cycle requête
|
||||
- 🟡 cleanupExpired() scanne Redis sans rien supprimer
|
||||
- 🟡 Erreurs domain matchées par error.message.includes()
|
||||
- 🟡 Body limit 10mb sur API auth
|
||||
- Corrections concrètes fournies avec le bon pattern (Promise partagée, bcrypt async) ✅
|
||||
|
||||
---
|
||||
|
||||
## Évaluation
|
||||
|
||||
### ✅ Ce qui a bien fonctionné
|
||||
- A lu les fichiers réels avant tout — 0 invention
|
||||
- Curseur adaptatif correct : "élevé" pour analyse statique, pas de métriques inventées
|
||||
- bcrypt synchrone détecté et expliqué pédagogiquement (event loop, single-thread, calcul concret)
|
||||
- Race condition Redis expliquée avec la mécanique async/await — pas juste "c'est mauvais"
|
||||
- Corrections concrètes avec le bon pattern (connectingPromise, bcrypt async)
|
||||
- Explique le *pourquoi* sur chaque point ✅
|
||||
|
||||
### ❌ Ce qui manquait
|
||||
- `error.message.includes()` (🟡 #8) = problème DDD/qualité, pas de perf → aurait dû marquer `[HORS PÉRIMÈTRE PERF]` + suggérer `code-review`
|
||||
- Body limit 10mb (#9) = aussi une faille de sécurité → aurait dû suggérer `security` en complément
|
||||
- Pas de suggestion d'agents complémentaires en fin d'audit
|
||||
- Question finale "Veux-tu qu'on commence par le fix bcrypt..." = scope drift workflow (même pattern que mentor)
|
||||
|
||||
### ⚠️ Anti-hallucination respectée ?
|
||||
- [x] Pas de métriques inventées — "250-300ms" est une estimation connue du cost factor 12 bcrypt, annoncée sans EXPLAIN ✅
|
||||
- [x] Race condition correctement attribuée à l'async/await, pas inventée ✅
|
||||
- [x] cleanupExpired() — comportement réel analysé (TTL -2 = clé inexistante) ✅
|
||||
|
||||
### 📐 Périmètre respecté ?
|
||||
- [x] N'a pas touché aux requêtes SQL → optimizer-db ✅
|
||||
- [x] N'a pas proposé de réécriture architecturale ✅
|
||||
- [ ] error.message.includes() = qualité DDD, pas perf → délégation manquante ❌
|
||||
- [ ] Body limit = security concern → security non suggéré ❌
|
||||
- [ ] Pas de suggestion agents complémentaires ❌
|
||||
- [ ] Scope drift sur la question finale ❌
|
||||
|
||||
---
|
||||
|
||||
## Gaps identifiés → à corriger dans l'agent
|
||||
|
||||
| Gap | Correction proposée | Priorité |
|
||||
|-----|--------------------|----------|
|
||||
| Problème qualité/DDD détecté sans délégation | Même règle qu'optimizer-db : `[HORS PÉRIMÈTRE PERF]` + suggérer `code-review` | haute |
|
||||
| Security concern non signalé à `security` | Si issue détectée avec impact sécurité (body limit, DoS) → signaler `security` en Composition | moyenne |
|
||||
| Pas de suggestion agents complémentaires | Ajouter section Composition en fin d'audit | moyenne |
|
||||
| Scope drift question finale | Ne pas proposer la prochaine action — laisser l'utilisateur décider | moyenne |
|
||||
|
||||
---
|
||||
|
||||
## Action
|
||||
|
||||
- [x] Review complète
|
||||
- [x] Gaps reportés dans `agents/optimizer-backend.md` changelog
|
||||
- [x] Recruiter invoqué pour améliorer l'agent
|
||||
- [ ] v2 planifiée
|
||||
76
agents/reviews/SuperOAuth/optimizer-db-v1.md
Normal file
76
agents/reviews/SuperOAuth/optimizer-db-v1.md
Normal file
@@ -0,0 +1,76 @@
|
||||
# Review agent : optimizer-db — v1
|
||||
|
||||
> ⚠️ Ce fichier concerne la QUALITÉ DE L'AGENT, pas les tests du code applicatif.
|
||||
|
||||
---
|
||||
|
||||
## Contexte de la review
|
||||
|
||||
| Info | Valeur |
|
||||
|------|--------|
|
||||
| Agent reviewé | `optimizer-db` |
|
||||
| Version | v1 |
|
||||
| Date | 2026-03-12 |
|
||||
| Projet testé | Super-OAuth |
|
||||
| Cas soumis | Audit des entités TypeORM — identifier les problèmes N+1, index manquants, et tout ce qui pourrait poser problème en perf avant la mise en prod. |
|
||||
|
||||
---
|
||||
|
||||
## Output résumé
|
||||
|
||||
- A lu les entités, repositories, services avant d'affirmer quoi que ce soit ✅
|
||||
- Niveau de confiance explicite dès l'en-tête : "élevé (analyse statique, sans EXPLAIN)" ✅
|
||||
- A utilisé le curseur adaptatif correctement (pas de slow query log → analyse statique)
|
||||
- 🔴 Détecté : repositories stub non implémentés utilisés en prod (bug silencieux)
|
||||
- 🔴 Détecté : session-new.entity.ts doublon avec conflit @Entity('sessions')
|
||||
- 🟠 Détecté : filtre expiration côté JS au lieu de SQL (index expiresAt non exploité)
|
||||
- 🟠 Détecté : eager loading systématique des sessions sur findUser*
|
||||
- 🟡 Détecté : index boolean faible cardinalité, index redondant, refreshToken non indexé, varchar(500) pour JWT
|
||||
- Niveau de confiance : moyen sur le point varchar(500) — mentionné explicitement ✅
|
||||
- A proposé les corrections concrètes avec le code TypeORM correspondant ✅
|
||||
|
||||
---
|
||||
|
||||
## Évaluation
|
||||
|
||||
### ✅ Ce qui a bien fonctionné
|
||||
- A lu les fichiers réels avant tout — analyse ancrée, 0 invention
|
||||
- Curseur adaptatif utilisé correctement : "élevé" pour l'analyse statique, "moyen" sur l'estimation volumétrie
|
||||
- Priorisation 🔴🟠🟡 cohérente et actionnelle
|
||||
- Explique le *pourquoi* de chaque problème (pas juste "c'est mauvais")
|
||||
- Corrections concrètes avec le bon opérateur TypeORM (`MoreThan`)
|
||||
- A détecté des bugs réels au-delà des perf — honnêteté sur ce qui bloque vraiment
|
||||
|
||||
### ❌ Ce qui manquait
|
||||
- Les issues 🔴 sont des **bugs**, pas des problèmes de perf. L'agent les a flaggés sans signaler qu'elles sortent de son périmètre → aurait dû écrire : "hors périmètre perf — à corriger avec `debug` ou `code-review` avant tout travail d'optimisation"
|
||||
- Pas de suggestion d'agents complémentaires en fin d'audit : `code-review` pour les bugs structurels, `debug` pour le repository mock, `optimizer-backend` pour la couche applicative
|
||||
|
||||
### ⚠️ Anti-hallucination respectée ?
|
||||
- [x] N'a pas inventé de plans d'exécution ("niveau de confiance : élevé, analyse statique") ✅
|
||||
- [x] Niveau de confiance : moyen sur le varchar(500) — dépend du volume ✅
|
||||
- [x] N'a pas affirmé que des requêtes étaient lentes sans EXPLAIN ✅
|
||||
- [x] Toutes les références de fichiers et lignes sont réelles ✅
|
||||
|
||||
### 📐 Périmètre respecté ?
|
||||
- [x] N'a pas touché à la config MySQL serveur → vps ✅
|
||||
- [x] N'a pas proposé de modifier le schéma sans explication ✅
|
||||
- [ ] Issues 🔴 = bugs hors périmètre perf → aurait dû déléguer explicitement ❌
|
||||
- [ ] Pas de suggestion agents complémentaires ❌
|
||||
|
||||
---
|
||||
|
||||
## Gaps identifiés → à corriger dans l'agent
|
||||
|
||||
| Gap | Correction proposée | Priorité |
|
||||
|-----|--------------------|----------|
|
||||
| Bugs détectés hors périmètre perf sans délégation explicite | Ajouter règle : si un problème détecté n'est pas de la perf → le signaler avec `[HORS PÉRIMÈTRE PERF]` + suggérer l'agent compétent (`debug`, `code-review`) | haute |
|
||||
| Pas de suggestion agents complémentaires | Ajouter section Composition en fin d'audit : `code-review` si bugs structurels, `optimizer-backend` si perf applicative identifiée | moyenne |
|
||||
|
||||
---
|
||||
|
||||
## Action
|
||||
|
||||
- [x] Review complète
|
||||
- [x] Gaps reportés dans `agents/optimizer-db.md` changelog
|
||||
- [x] Recruiter invoqué pour améliorer l'agent
|
||||
- [ ] v2 planifiée
|
||||
85
agents/reviews/SuperOAuth/refacto-v1.md
Normal file
85
agents/reviews/SuperOAuth/refacto-v1.md
Normal file
@@ -0,0 +1,85 @@
|
||||
# Review agent : refacto — v1
|
||||
|
||||
> ⚠️ Ce fichier concerne la QUALITÉ DE L'AGENT, pas les tests du code applicatif.
|
||||
|
||||
---
|
||||
|
||||
## Contexte de la review
|
||||
|
||||
| Info | Valeur |
|
||||
|------|--------|
|
||||
| Agent reviewé | `refacto` |
|
||||
| Version | v1 |
|
||||
| Date | 2026-03-12 |
|
||||
| Projet testé | Super-OAuth |
|
||||
| Cas soumis | Audit dette technique — identifier les zones à refactoriser en priorité avant la mise en prod. Architecture DDD, Express, TypeScript, TypeORM. Règle absolue : aucune logique métier ne disparaît. |
|
||||
|
||||
---
|
||||
|
||||
## Output résumé
|
||||
|
||||
- A lu ~22 fichiers avant de produire quoi que ce soit ✅
|
||||
- "Faits vérifiés — lecture directe des fichiers source" affiché explicitement ✅
|
||||
- 🔴 validateState appelé sans await → CSRF OAuth compromise (nouveau finding non détecté par les autres agents)
|
||||
- 🔴 UserRepository stubs confirmés dans DI container (déjà détecté par optimizer-db)
|
||||
- 🔴 CSRF absent sur auth.routes.simple.ts — auth.routes.ts avec CSRF = dead code
|
||||
- 🟠 3 ISessionRepository + 2 IUserRepository avec contrats incompatibles — architecture duale documentée
|
||||
- 🟠 La bonne implémentation (infrastructure/database/repositories/) non branchée dans le DI
|
||||
- 🟡 Dead code précisément listé (4 fichiers) + error handling par string.includes()
|
||||
- Plan atomique en 5 étapes avec estimations de temps + niveau de risque ✅
|
||||
- "Règle absolue respectée : aucune logique métier ne disparaît" ✅
|
||||
- "Je n'agis qu'après ta validation" ✅
|
||||
|
||||
---
|
||||
|
||||
## Évaluation
|
||||
|
||||
### ✅ Ce qui a bien fonctionné
|
||||
- Ancré dans les fichiers réels — références précises (fichier:ligne)
|
||||
- A trouvé un nouveau bug critique (validateState sans await) non détecté par optimizer-db ni optimizer-backend
|
||||
- Plan ordonné du moins risqué au plus risqué — étape 0 = fixes immédiats avant deploy
|
||||
- Estimations de temps et niveau de risque par étape — actionnable
|
||||
- A demandé validation avant d'agir — comportement correct pour refacto ✅
|
||||
- "Règle absolue respectée" signalé explicitement ✅
|
||||
|
||||
### ❌ Ce qui manquait
|
||||
- Question finale "confirmer le plan ou choisir l'étape 0" = légère dérive workflow — la partie "choisir l'étape 0" est directive. Présenter le plan et s'arrêter suffit.
|
||||
- Pas de suggestion d'agents complémentaires : `debug` pour corriger les bugs, `security` pour le CSRF, `testing` pour valider chaque étape
|
||||
|
||||
### ⚠️ Anti-hallucination respectée ?
|
||||
- [x] "Faits vérifiés" annoncé explicitement ✅
|
||||
- [x] Aucune invention — tous les fichiers/lignes cités sont réels ✅
|
||||
- [x] Distingue clairement bugs (🔴) vs dette architecturale (🟠) vs dette code (🟡) ✅
|
||||
|
||||
### 📐 Périmètre respecté ?
|
||||
- [x] Plan atomique — chaque étape testable indépendamment ✅
|
||||
- [x] N'a pas modifié de code sans validation ✅
|
||||
- [x] Règle "aucune logique métier ne disparaît" respectée et signalée ✅
|
||||
- [ ] Scope drift léger sur la question finale ❌
|
||||
- [ ] Pas de suggestion agents complémentaires ❌
|
||||
|
||||
---
|
||||
|
||||
## Gaps identifiés → à corriger dans l'agent
|
||||
|
||||
| Gap | Correction proposée | Priorité |
|
||||
|-----|--------------------|----------|
|
||||
| Scope drift question finale | Présenter le plan complet et s'arrêter — ne pas orienter vers une étape spécifique | moyenne |
|
||||
| Pas de suggestion agents complémentaires | En fin de rapport : suggérer `debug` pour les bugs critiques, `security` pour les failles, `testing` pour valider chaque étape du plan | haute |
|
||||
|
||||
---
|
||||
|
||||
## Note système — fin du cycle de reviews
|
||||
|
||||
13/13 agents reviewés. Pattern transversal confirmé sur 5 agents :
|
||||
scope drift question finale = réflexe du modèle de base, corrigé dans chaque agent
|
||||
ET ancré dans `_template.md` pour les futurs agents.
|
||||
|
||||
---
|
||||
|
||||
## Action
|
||||
|
||||
- [x] Review complète
|
||||
- [x] Gaps reportés dans `agents/refacto.md` changelog
|
||||
- [x] Recruiter invoqué pour améliorer l'agent
|
||||
- [ ] Cycle 13/13 — bilan système à faire avec agent-review
|
||||
76
agents/reviews/SuperOAuth/security-v1.md
Normal file
76
agents/reviews/SuperOAuth/security-v1.md
Normal file
@@ -0,0 +1,76 @@
|
||||
# Review agent : security — v1
|
||||
|
||||
> ⚠️ Ce fichier concerne la QUALITÉ DE L'AGENT, pas les tests du code applicatif.
|
||||
> Tests code → voir `projet/src/__tests__/` et Jest/Vitest.
|
||||
|
||||
---
|
||||
|
||||
## Contexte de la review
|
||||
|
||||
| Info | Valeur |
|
||||
|------|--------|
|
||||
| Agent reviewé | `security` |
|
||||
| Version | v1 |
|
||||
| Date | 2026-03-12 |
|
||||
| Projet testé | Super-OAuth |
|
||||
| Cas soumis | Audit + fix branche feature/security-hardening — JWT blacklist, CSRF, CSP nonce, device fingerprinting |
|
||||
|
||||
---
|
||||
|
||||
## Output résumé
|
||||
|
||||
**Phase 1 — Audit**
|
||||
- JWT Blacklist Redis ✅ — implémentation propre (JTI seul, TTL auto)
|
||||
- CSRF ✅ mais CSRF_SECRET hardcodé ligne 17 → 🔴 bloquant
|
||||
- CSP Nonce ✅ excellent
|
||||
- Device Fingerprinting 🔴 — généré et stocké, jamais validé (feature morte)
|
||||
- Rate Limiting ✅ excellent
|
||||
|
||||
**Phase 2 — Fix**
|
||||
- Fix 1 : CSRF_SECRET ajouté dans .env.example avec commande openssl
|
||||
- Fix 2 : device fingerprinting câblé en DDD correct (controller → DTO → use case)
|
||||
- TypeScript vérifié : `npx tsc --noEmit` → 0 erreur
|
||||
- Soft check choisi : log warning sans rejeter (false positifs mobile en roaming)
|
||||
|
||||
---
|
||||
|
||||
## Évaluation
|
||||
|
||||
### ✅ Ce qui a bien fonctionné
|
||||
- A lu les fichiers AVANT de toucher quoi que ce soit
|
||||
- A compris et respecté l'architecture DDD sans qu'on le rappelle
|
||||
- A documenté le *pourquoi* directement dans les commentaires de code
|
||||
- A vérifié la compilation TypeScript et corrigé l'erreur `exactOptionalPropertyTypes` seul
|
||||
- Soft check bien raisonné : mesurer les mismatches avant de passer en hard reject
|
||||
- A suggéré les commits/PR sans les créer — coordinateur propre
|
||||
|
||||
### ❌ Ce qui manquait
|
||||
- N'a pas suggéré d'ajouter des tests pour le nouveau flow fingerprint (agent `testing` à invoquer)
|
||||
- N'a pas vérifié si `sessionRepository.create()` acceptait déjà le paramètre optionnel dans son interface (tsc a validé, mais expliciter aurait été mieux)
|
||||
|
||||
### ⚠️ Anti-hallucination respectée ?
|
||||
- [x] N'a pas inventé de commandes — tout ancré dans le vrai code
|
||||
- [x] A dit "À discuter" pour les décisions comportementales (fail-open vs fail-closed)
|
||||
- [x] A géré l'erreur TypeScript sans l'ignorer
|
||||
|
||||
### 📐 Périmètre respecté ?
|
||||
- [x] N'a pas débordé sur la perf (noté ⚠️ sans plonger)
|
||||
- [x] A suggéré commits/PR sans les exécuter
|
||||
- [x] Fix dans le bon layer DDD — pas dans le middleware
|
||||
|
||||
---
|
||||
|
||||
## Gaps identifiés → à corriger dans l'agent
|
||||
|
||||
| Gap | Correction proposée | Priorité |
|
||||
|-----|--------------------|----|
|
||||
| N'a pas suggéré de tester le nouveau flow | Ajouter dans le périmètre : "après un fix, suggérer d'invoquer `testing`" | moyenne |
|
||||
|
||||
---
|
||||
|
||||
## Action
|
||||
|
||||
- [x] Review complète
|
||||
- [x] Gap reporté dans `agents/security.md` changelog
|
||||
- [x] Règle ajoutée directement dans Périmètre (Recruiter non nécessaire — correction simple)
|
||||
- [ ] v2 planifiée (prochain audit réel sur Super-OAuth)
|
||||
134
agents/reviews/SuperOAuth/testing-v1.md
Normal file
134
agents/reviews/SuperOAuth/testing-v1.md
Normal file
@@ -0,0 +1,134 @@
|
||||
# Review agent : testing — v1
|
||||
|
||||
> ⚠️ Ce fichier concerne la QUALITÉ DE L'AGENT, pas les tests du code applicatif.
|
||||
> Tests code → voir `projet/src/__tests__/` et Jest/Vitest.
|
||||
|
||||
---
|
||||
|
||||
## Contexte de la review
|
||||
|
||||
| Info | Valeur |
|
||||
|------|--------|
|
||||
| Agent reviewé | `testing` |
|
||||
| Version | v1 |
|
||||
| Date | 2026-03-12 |
|
||||
| Projet testé | Super-OAuth |
|
||||
| Cas soumis | Analyse couverture actuelle + stratégie pour zones critiques (couches DDD auth flows) — puis exécution Session 1 (fingerprint + logout) et Session 2 (start-oauth + user.entity) |
|
||||
|
||||
---
|
||||
|
||||
## Output résumé
|
||||
|
||||
**Analyse :**
|
||||
- ~180 tests existants mappés par couche DDD avec comptes approximatifs (`)
|
||||
- 4 zones 🔴 bloquantes identifiées : logout (0 tests), refresh-token fingerprint (0), start-oauth (0), user.entity (0)
|
||||
- 3 zones 🟡 importantes : password.service, session.entity, csrf/rate-limit
|
||||
- Stratégie en 4 sessions ordonnées par criticité
|
||||
|
||||
**Session 1 — exécutée :**
|
||||
- 3 tests fingerprint ajoutés dans refresh-token.test.ts (absent, mismatch, conservation)
|
||||
- Bug existant détecté et corrigé au passage : assertion `create` attendait 3 args, appelé avec 4
|
||||
- logout.test.ts créé (7 tests : happy path, révocation blacklist, TTL, all-sessions)
|
||||
- 175/175 verts, zéro régression
|
||||
|
||||
**Session 2 — exécutée :**
|
||||
- start-oauth.test.ts créé (10 tests : happy path, state generation, erreurs)
|
||||
- user.entity.test.ts créé (23 tests : factory methods, business rules, canUnlinkProvider)
|
||||
- Bug détecté au passage : Nickname.create('u') → VO rejette < 2 chars, corrigé immédiatement
|
||||
- 208/208 verts, zéro régression
|
||||
|
||||
**Session 3 — exécutée :**
|
||||
- password.service.test.ts créé (9 tests : hash, verify, rounds invalides)
|
||||
- csrf.middleware.test.ts créé (5 tests : format 403, next(err), injection token)
|
||||
- rate-limit.middleware.test.ts créé (6 tests : format 429, skipSuccessfulRequests)
|
||||
- 230/230 verts, zéro régression
|
||||
|
||||
**Delta total Sessions 1→3 : 175 → 230 tests, 12 → 19 suites (+55 tests, +7 suites)**
|
||||
**Session 4 (repositories infra + controllers supertest) : post-prod**
|
||||
|
||||
---
|
||||
|
||||
## Output brut — analyse initiale
|
||||
|
||||
```
|
||||
Agent testing chargé. Voici l'analyse complète.
|
||||
|
||||
État actuel
|
||||
|
||||
~180 tests Jest couvrant :
|
||||
|
||||
login-classic.use-case Application ✅ ~40 tests
|
||||
register-classic.use-case Application ✅ 4 tests (léger)
|
||||
complete-oauth.use-case Application ✅ ~15 tests
|
||||
refresh-token.use-case Application ✅ ~14 tests
|
||||
token.service Infrastructure ✅ 12 tests
|
||||
token-blacklist.service Infrastructure ✅ 11 tests
|
||||
oauth.service Infrastructure ✅ 19 tests
|
||||
auth.middleware Presentation ✅ 17 tests
|
||||
validation.middleware Presentation ✅ 13 tests
|
||||
crypto.util Shared ✅ 40+ tests
|
||||
Email, Password, Nickname, UserId Domain VO ✅ ~25 tests
|
||||
|
||||
Zones critiques non couvertes :
|
||||
|
||||
🔴 logout.use-case.ts — 0 tests
|
||||
🔴 refresh-token fingerprint — 0 tests sur le nouveau code
|
||||
🔴 start-oauth.use-case.ts — 0 tests
|
||||
🔴 user.entity.ts (aggregate root) — 0 tests
|
||||
|
||||
🟡 password.service.ts — 0 tests
|
||||
🟡 session.ts (domain entity) — 0 tests
|
||||
🟡 csrf.middleware.ts / rate-limit.middleware.ts — 0 tests
|
||||
|
||||
🟢 Repositories infrastructure — tests d'intégration vraie DB (backlog)
|
||||
🟢 Controllers auth + oauth — supertest (backlog)
|
||||
|
||||
Stratégie : 4 sessions, seuil minimal prod = sessions 1 + 2.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Évaluation
|
||||
|
||||
### ✅ Ce qui a bien fonctionné
|
||||
- A vérifié sur vrais fichiers avant d'affirmer (grep + glob = 0 inventions)
|
||||
- Utilisé `~` pour les comptes incertains — anti-hallucination active
|
||||
- A détecté un bug existant dans les tests (assertion create à 3 args au lieu de 4) sans qu'on le lui demande
|
||||
- Stratégie par couche DDD exactement correcte (domain=0 mock, infrastructure=vraie DB)
|
||||
- Tests écrits avec commentaires expliquant CE QUE LE TEST PROTÈGE — pédagogique
|
||||
- 175/175 verts après ajout — zéro régression
|
||||
- A proposé rétroactif (pas TDD) puisque le code existait déjà — curseur adaptatif correct
|
||||
- Ordre de priorité logique : fingerprint en premier car directement lié au fix récent
|
||||
|
||||
### ❌ Ce qui manquait
|
||||
- N'a pas suggéré `security` pour valider que les tests de sécurité couvrent bien les vecteurs d'attaque identifiés lors de l'audit (coordination agents)
|
||||
- N'a pas suggéré `code-review` après avoir écrit les tests (les tests eux-mêmes méritent une review)
|
||||
|
||||
### ⚠️ Anti-hallucination respectée ?
|
||||
- [x] A dit "Information manquante" quand nécessaire — a vérifié sur vrais fichiers avant d'affirmer
|
||||
- [x] N'a pas inventé de métriques — `~` pour l'incertain, 0 pour les fichiers non trouvés
|
||||
- [x] Niveau de confiance implicite correct — pas de % de coverage promis sans analyse
|
||||
|
||||
### 📐 Périmètre respecté ?
|
||||
- [x] Connaît la structure DDD par couche — stratégie différenciée par layer ✅
|
||||
- [x] Distingue tests unitaires des tests d'intégration ✅
|
||||
- [x] Propose rétroactif sur code existant (curseur adaptatif) ✅
|
||||
- [x] N'a pas débordé sur la sécurité ou la perf ✅
|
||||
|
||||
---
|
||||
|
||||
## Gaps identifiés → à corriger dans l'agent
|
||||
|
||||
| Gap | Correction proposée | Priorité |
|
||||
|-----|--------------------|----|
|
||||
| N'a pas suggéré `security` pour valider les tests de sécurité | Ajouter dans Composition : "après tests sur auth/tokens → proposer coordination `security` pour valider la pertinence des cas" | basse |
|
||||
| N'a pas suggéré `code-review` sur les tests écrits | Ajouter : "après écriture de tests, proposer `code-review` si les tests sont complexes" | basse |
|
||||
|
||||
---
|
||||
|
||||
## Action
|
||||
|
||||
- [x] Review complète (Sessions 1 + 2)
|
||||
- [x] Gaps reportés dans `agents/testing.md` changelog
|
||||
- [x] Règles ajoutées directement (Recruiter non nécessaire)
|
||||
- [ ] v2 planifiée (prochain projet avec Vitest frontend ou Session 3)
|
||||
Reference in New Issue
Block a user