PD-283 — Rétrospective¶

Périmètre d'analyse¶

• Domaine : b2c-mineurs / crypto / mobile
• Stories analysées : 337 learnings dans learnings.jsonl, 13 avec tag #zero-knowledge
• Story courante : PD-283 — Assemblage local ZIP dossier plainte (Zero-Knowledge)

Patterns identifiés¶

Pattern 1 : Validation format-only vs fonctionnelle (SEC-format-validation)¶

Fréquence : 3 stories (PD-283, PD-282, PD-265) Sévérité : BLOCKING

Les schémas de validation (Zod, class-validator) vérifient le format (regex, longueur) mais pas la sémantique. PD-283 integrityHash : format hex 64 chars validé, mais jamais comparé au fichier téléchargé. Pattern identique PD-282 (certificat validé en format mais trustedRoots optionnel) et PD-265 (monitoring NTS format OK mais clearing conditionnel absent).

Recommandation : Ajouter dans la checklist pre-Gate 5 (/gov-check-plan) un item "Vérification fonctionnelle de chaque champ de sécurité" distinct de la validation de format.

Pattern 2 : Purge proactive obligatoire (SEC-crash-residual)¶

Fréquence : 2 stories (PD-283, PD-262) Sévérité : WARNING

Le finally block ne suffit pas — un crash app (OOM, kill signal) bypass le finally. PD-283 : fichiers clairs résiduels après crash. PD-262 : données anti-tampering résiduelles en cache.

Recommandation : Pour toute story manipulant des fichiers temporaires sensibles, exiger un appel purgeStale() ou équivalent au démarrage du flux, documenté comme invariant dans la spec.

Pattern 3 : Passthrough byte vs sémantique (ARCH-passthrough)¶

Fréquence : 1 story (PD-283), mais pattern potentiellement récurrent Sévérité : INFO

Quand la spec dit "passthrough strict", elle peut signifier byte-level (identité binaire) ou sémantique (clés/valeurs préservées). JSON parsing détruit l'identité byte-level (ordre des clés, espacement). PD-283 : confrontation a identifié la divergence, reclassée comme décision architecturale.

Recommandation : Quand une spec mentionne "passthrough", qualifier explicitement : passthrough: byte-level (pour binaire) ou passthrough: semantic (pour JSON/XML).

Pattern 4 : Coverage effective hors I/O natif (QA-coverage-mobile)¶

Fréquence : 3 stories (PD-283, PD-262, PD-97) Sévérité : INFO

Les modules dépendant d'I/O natif (expo-file-system, expo-notifications, Keychain) ont une couverture systématiquement faible (15-20%) car les mocks sont difficiles. La couverture globale est tirée vers le bas par ces modules. PD-283 : 77% vs 80% objectif, causé par pvproof-assembler (14%) et streaming-hasher (17%).

Recommandation : Calculer et afficher la "coverage effective" (hors barrel files et modules I/O natif) en complément de la coverage globale.

Pattern 5 : Gate 3 comme investissement (PROCESS-gate3-roi)¶

Fréquence : PD-283 + 8 stories avec #spec-ambiguous/#spec-incomplete Sévérité : INFO

PD-283 Gate 3 a identifié 15 écarts (7 ambiguïtés, 5 complétude, 3 sécurité). Après correction, Gate 5 = GO v1 et Gate 8 = RESERVE v1 avec seulement des limitations documentées. Le ROI de Gate 3 sévère est mesurable : moins d'itérations en aval.

Recommandation : Maintenir la sévérité Gate 3 actuelle. Ne pas assouplir pour "gagner du temps".

Signal à l'humain¶

Candidats à intégration CLAUDE.md¶

Action requise¶

Oui — Pattern SEC-format-validation (3 occurrences, blocking) mérite une règle dans procedures.md ou learnings.md.

Métriques de cette rétrospective¶