PD-285 — Retour d'experience (REX)¶

1. Resume executif¶

2. Metriques de convergence¶

2.1 Temps et iterations¶

2.2 Scores de convergence par gate¶

2.3 Ecarts par categorie¶

3. Points fluides¶

Ce qui a bien fonctionne : - Workflow ultra-rapide : toutes les gates passees en v1, aucune iteration corrective. Story completee en moins d'une heure. - Perimetre minimal et bien delimite : aucun code applicatif modifie, uniquement une migration SQL data + mocks de tests + documentation. La separation configuration/logique du backend a parfaitement fonctionne. - Score Gate 8 exceptionnel (9.688) : la simplicite du changement (UPDATE SQL) a elimine les risques de divergence spec/impl et de securite. - Capitalisation inter-EB : la detection de l'incoherence PD-101/backend par la pipeline de coherence a directement genere cette story corrective.

4. Points difficiles¶

Obstacles rencontres (sans justification) : - CA-07 non verifiable : la pipeline de coherence inter-EB (coherence-report.py) n'a pas ete executee pendant le workflow. CA-07 reste en attente post-migration. - Derogation Art. II systematique : toutes les gates ont utilise Claude comme reviewer des deux phases (review + confrontation) par fallback Art. II (prompts > 30KB pour OpenCode). Le principe de validation croisee n'a pas ete applique strictement.

5. Hypotheses revelees tardivement¶

Hypotheses non explicites decouvertes en cours de workflow : - storage.category_max_bytes vs maxSizeBytes — decouverte a l'etape 3 (Gate 3, C-01/C-02). Deux noms designent le meme concept (parametre de config global vs champ DB par categorie). Ambiguite documentaire, sans impact code. - Categorie determinee par la route, pas par le body — decouverte a l'etape 3 (Gate 3, C-09). Le middleware determine la categorie via la route d'upload (ex: /deposit/:category), pas via le body. Non documente dans la spec.

6. Invariants complexes¶

Invariants difficiles a implementer ou sensibles aux regressions : - INV-285-07-doc-sync — TC-NOM-07. Invariant documentaire : la synchronisation PD-252 depend d'un amendement manuel dans un autre repo (ProbatioVault-doc). Risque de desynchronisation si PD-252 est modifie independamment. - INV-285-08 a INV-285-12 — TC-INV-08 a TC-INV-12. Invariants d'absence (pas de transition temporelle, pas d'etats retour, etc.). Non testables par automate — assertions d'analyse du perimetre.

7. Dette technique¶

Compromis acceptes et non bloquants : - CA-07 differe — impact: faible. La verification de coherence inter-EB sera executee au prochain deploiement en dev. Le risque est nul car le changement aligne une borne deja effective cote client (PD-101). - Invariants d'absence non automatisables — impact: faible. INV-285-08 a INV-285-12 documentent des decisions de perimetre, pas des regles fonctionnelles. Leur presence dans la spec alourdit la matrice de couverture sans apporter de valeur testable.

8. Risques residuels¶

8bis. Matrice de delegation inter-PD¶

8ter. Bugs de tests¶

Aucun bug de test rencontre. Les mocks ont ete mis a jour mecaniquement (104857600 -> 524288000).

8quater. Corrections post-Gate 8¶

Aucune correction post-Gate 8 necessaire. Pipeline TSC OK, 44/44 tests.

9. Patterns recurrents detectes¶

9.1 Patterns confirmes (deja vus dans d'autres stories)¶

• Derogation Art. II par defaut pour prompts > 30KB — aussi dans PD-283, PD-284, PD-80. Le fallback Claude-only pour les confrontations est devenu systematique quand les prompts depassent 30KB (limitation OpenCode/ChatGPT).
• Invariants d'absence (checklist-style) — aussi dans PD-253, PD-284, PD-85. Les invariants INV-XX-08 a INV-XX-12 (absence de transition temporelle, etats retour, protection distribuee, atomicite DDL, inter-module) sont generes systematiquement par le template de specification mais ne sont pas testables par automate. Pattern de bruit documentaire.

9.2 Nouveaux patterns identifies¶

• Story "config-only" ultra-rapide — premiere story completee en < 1h avec toutes gates v1 GO. Le pattern "modification de donnee DB sans logique applicative" elimine les risques de divergence et de securite. A identifier comme archetype pour calibrer les estimations futures.
• Ambiguite naming config/DB — le double nommage storage.category_max_bytes (documentaire) vs maxSizeBytes (DB/code) genere des constats en Gate 3 sans impact reel. A clarifier dans le template de specification pour eviter ce bruit.

10. Ameliorations du workflow¶

10.1 Ameliorations des prompts/templates¶

10.2 Ameliorations des agents¶

10.3 Ameliorations du processus¶

• Archetype "config-only" : Identifier les stories qui ne modifient que des donnees de configuration (pas de code applicatif) et proposer un workflow allege (skip step 6a decomposition, simplifier les templates).
• Art. II — seuil 30KB : Documenter officiellement le seuil de 30KB comme limite operationnelle d'OpenCode et prevoir un reviewer alternatif (Ollama local ?) pour garantir la validation croisee.

11. Enseignements cles¶

1. Les stories "config-only" sont des quick-wins — quand la logique applicative lit la config depuis la DB sans constante hardcodee, un changement de valeur est une simple migration SQL. Le workflow complet reste pertinent pour la tracabilite mais la duree est divisee par 15.
2. Le template de spec genere du bruit pour les stories simples — les invariants d'absence (INV-08 a INV-12) et les tests associes (TC-INV-08 a TC-INV-12) representent 5/12 invariants et 5/16+ tests pour zero valeur fonctionnelle sur une story de configuration.
3. La pipeline de coherence inter-EB genere correctement des stories correctives — PD-285 est le premier exemple de story generee directement par un ecart detecte par coherence-report.py. Le cycle detection → correction → validation est operationnel.

12. Metriques cumulatives (auto-calculees)¶