Retrospective — PD-264¶
Resume story¶
- Story : PD-264 — Nonce anti-rejeu + interoperabilite TSA RFC 3161
- Domaine : blockchain
- Date : 2026-02-24
- Gates : G3 GO (v3, 8.75/10) | G5 GO (v1, 8.812/10) | G8 GO (v1, 9.438/10)
- Temps total : 3.1h (plus rapide du projet backend)
Learnings de cette story¶
Depuis les gates¶
| Gate | Verdict | Score | Tags | Note |
|---|---|---|---|---|
| G3 v1 | RESERVE | 7.06 | #rfc3161, #nonce, #atomicity, #bullmq | INV-264-13 atomicite ACCEPTED→PERSISTED non clarifie |
| G3 v2 | RESERVE | 7.75 | #rfc3161, #timing, #statistical-test | Protocole statistique temps constant a formaliser |
| G3 v3 | GO | 8.75 | #nonce, #rfc3161, #tsa, #blockchain | Migration DDL cluster adressable au plan |
| G5 | GO | 8.812 | #plan, #migration, #nonce, #cross-validation | Confrontation reclasse 1 BLOQ→MAJ, 2 MAJ→MIN |
| G8 | GO | 9.438 | #nonce, #rfc3161, #crypto, #migration, #postgresql | Defense en profondeur + migration BYTEA pattern |
Depuis le REX¶
- Contractualiser les migrations DDL : Toute modification de schema doit etre specifiee avant Gate 3. L'absence a coute 2 iterations (7.06→8.75). INV candidat : INV-XXX-DDL-MIGRATION.
- Atomicite multi-composant : Clarifier DB synchrone vs post-commit asynchrone (BullMQ, Merkle). INV-264-13 a necessite 3 iterations. INV candidat : INV-XXX-ATOMICITY-SCOPE.
- Constats Gate 3 comme inputs plan : Traiter les constats R01-R11 de Gate 3 dans le plan §0 → Gate 5 GO v1 (8.812/10).
- Defense en profondeur : timingSafeEqual + UNIQUE index DB → SEC 9.75/10 sans iteration.
- Fallback LLM transparent : OpenCode→claude-p en Gate 8 sans impact sur verdict.
Patterns recurrents (domaine blockchain)¶
Pattern B1 — Migration DDL comme cluster d'ecarts Gate 3 (3 stories)¶
| Story | Manifestation | Iterations |
|---|---|---|
| PD-264 | VARCHAR→BYTEA + trigger + backfill | 3 |
| PD-55 | Subquery index partiels PostgreSQL | 3 |
| PD-63 | Tables manquantes (shares, co_holders) | 2 |
Impact : Chaque changement de schema non contractualise coute 1-2 iterations de gate. Recommandation : Section obligatoire "Strategie de migration DDL" dans le template spec (appliquee par REX PD-264, v1.3.0).
Pattern B2 — Defense en profondeur elimine ecarts SEC (4 stories)¶
| Story | Mecanisme | Score SEC Gate 8 |
|---|---|---|
| PD-264 | timingSafeEqual + UNIQUE index | 9.75 |
| PD-238 | timingSafeEqual + rate limiting | 8.0+ |
| PD-55 | Trigger immutabilite + advisory lock | 8.0 |
| PD-177 | SecretLeakInterceptor + KMS | 8.6 |
Impact : Pattern mature — Gate 8 GO v1 systematique quand applique. Recommandation : Documenter comme pattern de reference dans agent-developer.md.
Pattern B3 — BullMQ workers necessitent clarification atomicite (3 stories)¶
| Story | Enjeu | Resolution |
|---|---|---|
| PD-264 | Transaction DB vs post-commit Merkle | 3 iterations spec |
| PD-55 | Rollback lot vs token individuel | 2 iterations plan |
| PD-21 | Idempotence processors | REX |
Impact : L'asynchronisme BullMQ cree systematiquement de l'ambiguite sur le perimetre transactionnel. Recommandation : Invariant candidat INV-XXX-ATOMICITY-SCOPE pour les specs avec flux BullMQ.
Pattern B4 — Confrontation croisee reclasse les gravites (4 stories)¶
| Story | Gate | Reclassement |
|---|---|---|
| PD-264 | G5 | 1 BLOQ→MAJ, 2 MAJ→MIN |
| PD-55 | G8 | Faux positifs securite annules |
| PD-177 | G5 | Mecanisme fail-closed reclasse |
| PD-79 | G3+G5 | ⅚ ecarts annules |
Impact : La deliberation multi-agents ajoute de la valeur quand reviewers divergent sur la gravite. Recommandation : Pattern stable, pas d'action requise.
Pattern B5 — Gate 3 blockchain = 3 iterations systematiques (3 stories)¶
| Story | Gate 3 iterations | Cause |
|---|---|---|
| PD-264 | 3 | Migration DDL + atomicite + automate |
| PD-55 | 3 | RFC 8785 + format preuve + circuit breaker |
| PD-81 | 3 | SLA temporels + destruction deadline |
Impact : Les specs blockchain/crypto manquent systematiquement de formalisme RFC. Recommandation : Template spec blockchain avec sections pre-remplies (RFC, canonicalisation, formats preuve).
Tags recurrents (>= 5 stories)¶
| Tag | Stories | Type |
|---|---|---|
| #backend | 26 | Foundation |
| #crypto | 21 | Foundation |
| #security | 13 | Cross-cutting |
| #testing | 11 | Cross-cutting |
| #auth | 10 | Domain |
| #plan | 9 | Process |
| #code-contracts | 9 | Process |
| #blockchain | 8 | Domain |
| #spec-incomplete | 7 | Alerte |
| #nestjs | 7 | Tech |
| #mobile-ios | 6 | Domain |
| #postgresql | 6 | Tech |
| #bullmq | 5 | Tech |
Recommandations¶
Priorite haute (>= 5 stories ou NON_CONFORME recurrent)¶
- Template spec v1.3.0 : Section "Strategie de migration DDL" ajoutee (REX PD-264). Economie estimee : 1-2 iterations/story blockchain.
- Template spec v1.3.0 : Section "Atomicite multi-composant" ajoutee (REX PD-264). Economie estimee : 1-3 iterations/story BullMQ.
- Template spec blockchain : Creer un template pre-rempli pour les stories blockchain avec sections RFC, canonicalisation, formats preuve, migration DDL. 3/3 stories blockchain = 3 iterations Gate 3.
Priorite normale¶
- agent-developer.md : Ajouter regle "errorCode dans les catch globaux : ne pas masquer le code d'erreur specifique par un code generique" (ecart R-01/S-01 PD-264).
- Constats Gate 3 → Plan : Pattern "constats de gate = exigences du plan" documente dans REX PD-264 et applique (Gate 5 GO v1 8.812/10).
- Invariant candidat INV-XXX-DDL-MIGRATION : Transformer le learning en invariant injectable dans les specs touchant des colonnes existantes.
- Invariant candidat INV-XXX-ATOMICITY-SCOPE : Transformer le learning en invariant pour les specs avec flux DB + queue.
Signal CLAUDE.md¶
Le REX PD-264 a deja applique les modifications au template spec (v1.3.0).
Suggestions supplementaires pour revision humaine :
- CLAUDE.md > Etape 4 > Checklist pre-soumission : Ajouter un check "migrations DDL specifiees si colonnes modifiees"
- CLAUDE.md > Conventions : Ajouter convention "constats Gate 3 = inputs formels du plan (§0)"
- config/agents/agent-developer.md : Regle catch global errorCode preservation
Metriques¶
| Metrique | PD-264 | Moyenne blockchain (4 stories) | Tendance |
|---|---|---|---|
| Temps total | 3.1h | 13.9h | ↓↓ |
| Iterations gates | 5 | 7.5 | ↓ |
| Score G8 final | 9.438 | 8.5 | ↑ |
| Ecarts totaux | 27 | 24.5 | → |
| Gate 3 iterations | 3 | 2.75 | → |
PD-264 est la story la plus rapide et la mieux notee du projet backend. La convergence rapide s'explique par : perimetre bien borne (nonce seul), dependance PD-55 stable, integration systematique des constats Gate 3.