Rétrospective — PD-72¶
Résumé story¶
- Story : PD-72 — Worker PRE transfert coffre entreprise → salarié
- Domaine : crypto-proof
- Date : 2026-03-06
- Gates : G3 GO (v2, 8.2/10) | G5 GO (v1, 8.0/10) | G8 GO (v1, 9.44/10)
- Temps total : 2.5h (vs 6.41h moyenne, -61%)
Learnings de cette story¶
Depuis les gates¶
| Gate | Verdict | Score | Tags | Note |
|---|---|---|---|---|
| G3 v1 | NON_CONFORME | 5.5 | #spec, #gate3 | 5 écarts bloquants : SLA ancrage, PRE-01 vs state machine, retry, auth, timing |
| G3 v2 | GO | 8.2 | #spec, #convergence | Corrections exhaustives, +2.7 points |
| G5 | GO | 8.0 | #plan, #code-contracts | GO v1, plan solide |
| G8 | GO | 9.44 | #stubs, #gate8 | Score record projet — 8 stubs tracés, 0 bloquant |
Depuis le REX¶
- Besoin détaillé = spec rapide : Un besoin structuré avec flux nominaux + cas erreur + invariants permet une spec ChatGPT en 3 min.
- Gate 3 NON_CONFORME = investissement : Les corrections post-G3 v1 enrichissent la spec suffisamment pour G5+G8 GO en v1.
- Stubs tracés avec story destination = ROI : 8 stubs n'empêchent pas un score de 9.44/10.
- Implémentation séquentielle viable : Claude -p produit 29 fichiers en 28 min sans itération si code-contracts explicites.
- Tri orchestrateur critique : Taux de faux positifs LLM ~60% en step 7.
Patterns récurrents (domaine crypto-proof + backend)¶
Alerte forte (>= 5 stories)¶
| Pattern | Stories | Impact |
|---|---|---|
| #crypto : Machine d'états explicite pour entités multi-statut | 25 stories | Systématiquement GO quand implémentée |
| #backend : Stubs inter-PD acceptés si tracés avec story destination | 27 stories | Atténuation criticité MAJEUR → mineur |
| #security : Invariants de sécurité non-négociables (INV) | 17 stories | Foundation du scoring Gate 8 |
| #bullmq : Workers BullMQ avec retry/backoff spécifiés | 7 stories | SLA et conditions retry doivent être dans spec v1 |
| #spec : Contractualisation format/SLA dès spec v1 | 7 stories | Format non contractualisé = NON_CONFORME G3 v1 récurrent |
| #gate3 : Gate 3 NON_CONFORME suivi de GO G5+G8 | 6 stories | Pattern normal — G3 v1 sert de filtre correctif |
Pattern bloquant (NON_CONFORME récurrent)¶
| Axe | Occurrences | Stories | Recommandation |
|---|---|---|---|
| SLA/retry non contractualisé en spec v1 | >=6 | PD-72, PD-55, PD-265, PD-250... | Exiger SLA + retry dans template spec pour stories BullMQ/blockchain |
| Faux positifs LLM en reviews step 7 | >=5 | PD-72, PD-251, PD-276, PD-277, PD-275... | Injecter stubs connus + type de flux dans prompt 7a/7b/7c |
Recommandations¶
Priorité haute (>= 5 stories ou NON_CONFORME récurrent)¶
- Template spec v1 : Ajouter section obligatoire "SLA & Retry" pour toute story avec worker BullMQ ou ancrage blockchain. Contenu : SLA défaut/min/max, erreurs récupérables vs non-récupérables, formule backoff, timeout.
- Prompt reviews 7a/7b/7c : Injecter la liste des stubs connus avec story destination ET le type de flux (BullMQ worker vs HTTP controller) pour réduire les faux positifs (~60% actuellement).
- Infrastructure Sonar : Résoudre le problème d'infrastructure Sonar (9 stories en tier degraded). La dérogation ESLint+tsc ne couvre pas les analyses de sécurité Sonar (S2245, etc.).
Priorité normale¶
- Gate 3 scoring : Considérer que Gate 3 NON_CONFORME v1 est un pattern normal (6 occurrences) — ne pas le traiter comme un échec mais comme un filtre correctif enrichissant.
- Implémentation séquentielle : Documenter les critères de choix séquentiel vs parallèle : si architecture claire (10 composants, contrats explicites), le mode séquentiel Claude -p est plus efficace.
Signal CLAUDE.md¶
Suggestion 1 — .claude/rules/procedures.md section "Étape 1"¶
## Stories BullMQ/Worker — Section SLA & Retry obligatoire (spec v1)
Pour toute story impliquant un worker BullMQ ou un ancrage blockchain :
- SLA défaut + bornes min/max configurables
- Liste exhaustive erreurs récupérables vs non-récupérables
- Formule de backoff (ex: 30s * 2^n, plafond 5 min)
- Timeout configurable avec borne
Source : PD-72, PD-55, PD-265, PD-250 (>= 6 occurrences Gate 3 NON_CONFORME sur cet axe)
Suggestion 2 — .claude/rules/procedures.md section "Étape 7"¶
## Réduction faux positifs LLM — Injection contexte dans prompts 7a/7b/7c
Injecter dans les prompts de review :
1. Liste des stubs connus avec story destination (ex: "STUB: PD-41 — PRE re-encryption")
2. Type de flux (BullMQ worker vs HTTP controller) pour filtrer critères inapplicables
3. Nombre de tests et suites pour contrer "preuves d'exécution non fournies"
Source : PD-72 (60% faux positifs), PD-251, PD-276, PD-277, PD-275 (>= 5 occurrences)