PD-265 — Rétrospective¶

1. Patterns récurrents confirmés¶

P1 — Machine d'états composite (flags-as-source-of-truth)¶

Occurrences : PD-82, PD-250, PD-264, PD-279, PD-280, PD-278, PD-282, PD-265 Pattern : Stocker les conditions individuelles (flags/bitfield) en DB et dériver l'état visible par calcul. Ne JAMAIS stocker un état pré-calculé. Impact PD-265 : Élimine toute incohérence état/flags. Le clearing conditionnel (2 cycles conformes) et les policies par état sont calculés dynamiquement. Recommandation : Formaliser dans le template spec un paragraphe obligatoire "modèle d'état : flags vs state-column" pour toute story avec >= 3 conditions de dégradation.

P2 — STUBs inter-PD acceptés si tracés avec story destination¶

Occurrences : PD-63, PD-82, PD-250, PD-251, PD-282, PD-265 Pattern : // STUB: PD-XX — description avec story destination exacte. Criticité atténuée MAJEUR → MINEUR en Gate 8. Impact PD-265 : 6 STUBs tracés (PD-37 + PD-265 phase 2), Gate 8 GO v1 sans correction. Recommandation : Pattern stabilisé, aucune modification nécessaire.

P3 — Faux positifs LLM en reviews d'acceptabilité¶

Occurrences : PD-251, PD-280, PD-278, PD-282, PG-01, PD-265 Pattern : Les LLM ne distinguent pas STUB-tracé vs fonction-manquante. ChatGPT sur-classifie les décisions d'implémentation comme BLOQUANTS. Impact PD-265 : 5 findings (3 MAJEUR tests, 2 MAJEUR sécurité) rejetés après analyse contextuelle. Recommandation : Injecter la distinction STUB-tracé vs manquant dans les prompts 7a/7b/7c. Priorité haute.

P4 — Triple NON_CONFORME/RESERVE v1 = complexité élevée¶

Occurrences : PD-280, PD-278, PD-282, PD-265 Pattern : Gate 3 v1 NON_CONFORME + Gate 5 v1 RESERVE = 3 itérations structurelles nécessaires sur chaque gate. Impact PD-265 : Gate 3 (5.875→7.50→8.75), Gate 5 (8.00→8.125→8.625). Total 7 itérations. Recommandation : Détecter le pattern tôt (score v1 < 7 sur Gate 3) et pré-allouer 3 itérations.

P5 — Guard de sécurité fail-closed obligatoire¶

Occurrences : PD-238, PD-282, PD-265 Pattern : Tout endpoint critique doit avoir un guard fail-closed avec refus normé (code + état + flags). Impact PD-265 : TstEmissionGuard + canEmitTst() + canRehorodatage() avec TstEmissionRefusalDto. Recommandation : Ajouter section "Contrat de refus API" dans le template spec.

2. Nouveaux patterns identifiés¶

N1 — Clearing conditionnel (N cycles conformes)¶

Le clearing NTS requiert 2 cycles conformes sur TOUS les serveurs avant de revenir à HEALTHY. Pattern de stabilisation applicable à tout monitoring fail-closed.

N2 — SLA post-rotation par alerte (pas par flag)¶

Les transitions RETIRED→ARCHIVED et ARCHIVED→DESTROYED ne déclenchent pas de flag de dégradation car ce sont des actions opérateur. L'enforcement par alerte CRITICAL est le bon pattern quand l'action finale est humaine.

N3 — ESLint rules dans prompt agent¶

41 erreurs ESLint post-génération. Les rules detect-object-injection, restrict-template-expressions, no-unused-vars, require-await sont les plus fréquentes. Injecter un résumé dans le prompt agent économiserait ~30min de corrections.

3. Améliorations CLAUDE.md proposées¶

Note : Les modifications touchent des fichiers de configuration/templates, pas CLAUDE.md ni CONSTITUTIONAL.md directement. Pas de validation humaine requise.

4. Signal de clôture¶

Workflow PD-265 complet (étapes 0-10). Prochaines actions : - Merge feature/PD-265-monitoring-tsa-lifecycle → dev (post Gate 8 GO) - Pipeline GitLab (lint + tests + Sonar) - Transition Jira → Done (31)