Retrospective — PD-177¶

Resume story¶

• Story : PD-177 — Configurer wallet Ethereum et gestion cles privees
• Domaine : blockchain
• Date : 2026-02-23
• Gates : G3 GO (v2, 8.25/10) | G5 GO (v2, 8.45/10) | G8 GO (v2, 8.60/10)
• Duree totale : 16h
• Iterations totales : 6 (2+2+2)

Learnings de cette story¶

Depuis les gates¶

Depuis le REX¶

1. Learnings-as-invariants : Transformer learnings en invariants contractuels (INV-177-20 PostgreSQL, INV-177-21 BullMQ) est le mecanisme le plus efficace — verifies par gates, zero ecart constate.
2. Fail-closed NestJS : Interceptor RxJS post-handler (tap/catchError), jamais Guard — les plans qui ne precisent pas la sequence RxJS sont systematiquement signales en Gate 5.
3. Defense-in-depth cadrage : Les reviewers LLM surestiment les ecarts sur les couches secondaires sans considerer les barrieres primaires (KMS/HSM). Le cadrage explicite evite des MAJEUR injustifies.
4. Scan recursif : 3 protections obligatoires (WeakSet anti-cycles, MAX_DEPTH configurable, extraction methodes) pour tout parcours recursif de structures JSON.
5. 2 iterations par gate : Norme observee sur le domaine blockchain (5 stories, 100% des gates).

Patterns recurrents (domaine blockchain)¶

Analyse sur 5 stories blockchain (PD-52, PD-53, PD-55, PD-245, PD-177)¶

Analyse globale (30 dernieres entrees, 173 total)¶

Pattern bloquant : NON_CONFORME Gate 3¶

7 NON_CONFORME au total : - 6 sur 7 en Gate 3 (revue specification) — Gate 3 est le point de rejet principal - 0 en Gate 8 — aucune implementation rejetee apres passage Gates 3+5 - Domaines : auth-identity (5), mobile-ios (1), blockchain (0) - Tags recurrents : #spec-incomplete (3), #security (3), #rate-limiting (2)

Insight : Le domaine blockchain n'a JAMAIS recu de NON_CONFORME. Les specs blockchain sont plus formalisees (RFC, cryptographie) ce qui force la rigueur des la v1.

Recommandations¶

Priorite haute (>= 5 stories ou NON_CONFORME recurrent)¶

• Checklist completude specs auth-identity : Ajouter dans templates/prompts/1 Specification.md une checklist specifique au domaine auth : JWT requirements, rate-limiting thresholds, session invalidation bounds, observability metrics, Keycloak delegation scope. Justification : 5/7 NON_CONFORME proviennent de ce domaine.

• Pre-review securite en etape 4 : Pour les stories blockchain/crypto, ajouter une verification securite legere dans le prompt de plan (etape 4) couvrant : fail-closed mecanisme (sequence RxJS), defense-in-depth cadrage, barrieres primaires identifiees. Justification : les ecarts SEC apparaissent en Gate 8 (+1.20 delta v1->v2 pour PD-177) — les anticiper en etape 4 reduirait les iterations Gate 8.

Priorite normale¶

• Systematiser learnings-as-invariants : A chaque etape 9, identifier les 2-3 learnings les plus impactants et les transformer en invariants pour les prochaines stories du meme domaine. ROI mesure : zero ecart sur PD-177 pour les invariants issus de PD-55.

• Injection formalisme RFC dans prompt spec blockchain : Ajouter dans templates/prompts/1 Specification.md une section conditionnelle blockchain : "Pour les stories blockchain, inclure : format canonique (RFC 8785), format preuve (champs obligatoires), politique confirmations par reseau, circuit breaker/escalade". Justification : PD-55 et PD-177 ont eu 2 iterations Gate 3 pour ce meme manque.

• Scanner Sonar local systematique : Le pattern "Sonar detecte ce que ESLint/TSC ne voient pas" est confirme sur 6+ stories (PD-55, PD-177, PD-107, PD-31, PD-44, PD-82). Le scan Sonar local (Phase 1.5 de /gov-accept) est deja documente mais doit etre renforce comme BLOQUANT (pas optionnel) avant les reviews LLM.

Signal CLAUDE.md¶

Patterns forts identifies justifiant une revision :

Section : "Templates prompts > Specification"¶

Suggestion : Ajouter un bloc conditionnel par domaine dans le prompt specification :

## Contraintes specifiques domaine

### Si domaine = blockchain/crypto :
- Format canonique obligatoire (RFC 8785 ou equivalent)
- Politique confirmations par reseau : chainId -> confirmations + timeout
- Format preuve : champs obligatoires (hash, timestamp, signature, blockchain_ref)
- Circuit breaker et mecanisme escalade pour depassements

### Si domaine = auth-identity :
- JWT requirements : audience, issuer, expiration, signing algorithm
- Rate limiting : seuils par endpoint, stockage (Redis obligatoire)
- Session invalidation : latence bornee, mecanisme de propagation
- Keycloak delegation : scope, observability, fail-closed

Section : "Etape 7 > Acceptabilite"¶

Suggestion : Renforcer le scan Sonar local comme prerequis BLOQUANT (pas optionnel) :

Phase 1.5 (Sonar local) est BLOQUANTE. Si Sonar QG ERROR -> STOP avant reviews LLM.
Justification : 6+ stories avec corrections post-Gate 8 causees par Sonar QG FAILED.

Section : "Learnings > Capitalisation"¶

Suggestion : Ajouter une regle de capitalisation systematique :

A chaque etape 9, identifier les 2-3 learnings les plus impactants et les
transformer en invariants contractuels pour les stories suivantes du meme domaine.
ROI mesure sur PD-177 : zero ecart en 3 gates pour les invariants issus de learnings PD-55.