PD-296 — Rapport de confrontation (Étape 5 — Pré-Gate 5)¶

Ce rapport est produit par l'orchestrateur Claude avant la gate PMO 5. Il confronte les documents produits pour identifier convergences, divergences et zones d'ombre.

1. Sources confrontées¶

Spécification : PD-296-specification.md (étape 1)
Tests : PD-296-tests.md (étape 2)
Plan d'implémentation : PD-296-plan.md (étape 4)
Code Contracts : PD-296-code-contracts.yaml (étape 4)

2. Convergences¶

Fail-closed systématique : Les 4 documents s'accordent sur le principe fail-closed (INV-296-08). Outil indisponible, timeout, erreur runtime => verdict FAIL, blocage immédiat. Aucune exception. (Spec §4 INV-296-08, Tests TC-ERR-08/09, Plan §6, Contracts C1 invariants)
FSM à 4 états : Les 4 documents s'accordent sur les 4 états PENDING, RUNNING, PASSED, FAILED_BLOCKING et la matrice de transitions autorisées/interdites. (Spec §5.4, Tests TC-INV-01/02, Plan §3 INV-296-12/13, Contracts C2 invariants/forbidden)
Absence totale de mode skip/warning : Convergence explicite sur l'interdiction de tout mode non-bloquant (INV-296-17). (Spec §4, Tests TC-INV-03/TC-ERR-12, Plan §3, Contracts C1/C4 forbidden)
Mécanismes de protection distribuée : Lock flock, idempotence SHA-256, rate-limiting, réconciliation orphelins sont alignés entre les 4 documents. (Spec §5.6, Tests TC-NOM-10/12/TC-ERR-10/11, Plan §3 INV-296-15, Contracts C3)
Guard Done/DONE_ANOMALY/REJECTED : Les 4 documents couvrent le blocage de clôture Jira sur les 3 transitions (31, 2, 3) si un FAIL formel reste ouvert. (Spec INV-296-09, Tests TC-ERR-13, Plan §7 Écart 5, Contracts C2 invariants)
Payload D-296-14 : Convergence sur les 12 clés requises du résultat JSON et la validation stricte. (Spec §5.1, Tests TC-NOM-09/TC-ERR-03, Plan §3 INV-296-14, Contracts C1 invariants)
Validation des entrées : Toutes les sources exigent la validation regex des entrées D-296-01..15 avant toute exécution, avec rejet + FAILED_BLOCKING. (Spec §5.1, Tests TC-ERR-01/02 + TC-NEG-01..08, Plan §6, Contracts C1 invariants)
Article VIII constitutionnel : Convergence sur l'obligation d'ajouter l'Article VIII dans CONSTITUTIONAL.md et de le référencer dans CLAUDE.md. (Spec INV-296-11, Tests TC-NOM-08, Plan §3, Contracts C5)
Pas de retry automatique : formal_retry_on_failure = 0 confirmé partout. (Spec §5.2, Tests TC-NEG-10/TC-NR-04, Plan §3, Contracts C1 forbidden)
Architecture en 3 scripts + skills + docs : Le plan (6 composants C1-C6) et les code contracts (6 modules) sont alignés sur le découpage fonctionnel.

3. Divergences¶

Les conflits ne doivent JAMAIS être lissés. Chaque divergence est rendue visible.

DIV-01 : Nombre de checkpoints — 5 (spec) vs 6 (plan/contracts)
Spécification (§4 INV-296-01) : "Chaque story DOIT exécuter exactement 5 checkpoints formels"
Spécification (§5.2) : mandatory_checkpoints_per_story = 5 (min 5, max 5)
Plan (§résolution Écarts, table finale) : 6 checkpoints avec ajout de GATE3_SPEC_FORMAL
Plan (note finale) : mandatory_checkpoints_per_story = 6
Contracts C2 : count_checkpoints_passed retourne 6 (pas 5)
Impact : CRITIQUE. Le plan modifie un invariant NON NÉGOCIABLE (INV-296-01) sans que la spec n'ait été amendée. Le chiffre "5" dans la spec et le chiffre "6" dans le plan/contracts sont directement contradictoires. Ce conflit invalide toute la matrice de couverture des tests qui référence INV-296-01.
DIV-02 : Enum D-296-03 (checkpoint_id) — 5 valeurs (spec) vs 6 (plan/contracts)
Spécification (§5.1 D-296-03) : regex ^(STEP1_SPEC_COHERENCE|STEP4_CONTRACTS_FORMAL|GATE5_PLAN_FORMAL|STEP6_CODE_FORMAL|GATE8_FINAL_FORMAL)$ — 5 valeurs
Plan (table finale §Les 6 checkpoints) : ajoute GATE3_SPEC_FORMAL
Contracts C4 : référence GATE3_SPEC_FORMAL dans gov-gate.md
Impact : CRITIQUE. La regex D-296-03 de la spec rejetterait GATE3_SPEC_FORMAL comme invalide, déclenchant INV-296-16 (rejet + FAILED_BLOCKING). Le plan ne peut pas fonctionner avec la spec telle quelle.
DIV-03 : Enum D-296-04 (trigger_event) — 5 valeurs (spec) vs 6 (plan)
Spécification (§5.1 D-296-04) : regex ^(SPEC_SAVED|PLAN_AND_CONTRACTS_SAVED|CHECK_PLAN_PHASE4_START|STEP6C_DONE|GOV_ACCEPT_PHASE2_DONE)$ — 5 valeurs
Plan (table finale) : ajoute GATE3_REVIEW_START
Impact : CRITIQUE. Même problème que DIV-02 — l'événement déclencheur du 6e checkpoint serait rejeté par la validation spec.
DIV-04 : Enum D-296-05 (check_scope) — 5 valeurs (spec) vs 6 (plan)
Spécification (§5.1 D-296-05) : regex ^(coherence_spec|formal_contracts|formal_plan|formal_code|formal_full)$ — 5 valeurs
Plan (table finale) : ajoute formal_spec pour GATE3_SPEC_FORMAL
Impact : MAJEUR. Le scope formal_spec serait rejeté par la validation spec.
DIV-05 : Terminalité de PASSED — terminal strict (spec) vs conditionnel (plan)
Spécification (§5.4) : PASSED -> * : INTERDITE — état terminal, "résolution manuelle uniquement"
Plan (§2.3, H-PLAN-06) : transition PASSED -> PENDING autorisée via flag --force-recheck
Contracts C2 forbidden : "Transition PASSED→* sans flag --force-recheck" (implique qu'avec le flag, c'est autorisé)
Tests (TC-NEG-12) : "Tentative de sortie depuis état PASSED => Rejet (état terminal)"
Impact : MAJEUR. La spec et les tests disent que PASSED est terminal sans exception. Le plan introduit une exception (--force-recheck) non prévue par la spec. TC-NEG-12 et INV-296-13 contredisent directement le flux §2.3 du plan.
DIV-06 : Rate-limit — comportement au dépassement
Spécification (§5.2) : "Hors bornes : Rejet de requête (équivalent 429)"
Plan (H-PLAN-09) : "rejet simple (pas de FAILED_BLOCKING) : le checkpoint reste dans son état actuel"
Contracts C3 forbidden : "Rate-limit qui produit FAILED_BLOCKING (rejet simple sans changement d'état)"
Tests (TC-NEG-09) : "Rejet (équivalent 429), pas de progression"
Impact : MINEUR. Plan et contracts sont plus précis que la spec mais cohérents dans l'esprit. La spec est ambiguë (ne dit pas explicitement si le rejet produit FAILED_BLOCKING ou non). Le plan tranche : rejet simple. Aligné avec les tests.
DIV-07 : Tests TC-INV-01..04 — définis dans le plan, pas dans le document tests
Tests (§2 matrice) : Référence TC-INV-01..04 sans les définir (GIVEN/WHEN/THEN absents)
Plan (§5.3) : Fournit les définitions complètes de TC-INV-01..04
Impact : MINEUR. Les scénarios existent mais dans le mauvais document. Le document tests est incomplet. Le plan les fournit en résolution de l'Écart 3 de Gate 3 v1, mais contractuellement les tests appartiennent au document tests.
DIV-08 : Flux Gate 3 absent de la spec
Spécification (§5.5) : 5 flux F-296-01..05. Aucun flux pour Gate 3.
Plan (table finale + §2.1) : GATE3_SPEC_FORMAL est un flux à part entière
Impact : CRITIQUE. Le plan ajoute un checkpoint pré-Gate 3 sans que la spec ne définisse le flux correspondant (déclencheur, scope, résultat GO/FAIL, comportement de blocage).
DIV-09 : mandatory_gates_formal — incohérence résiduelle
Spécification (§5.2) : mandatory_gates_formal = 3 (Gate 3, Gate 5, Gate 8)
Spécification (§5.5) : Aucun checkpoint Gate 3 dans les flux
Plan : Ajoute GATE3_SPEC_FORMAL pour résoudre cette incohérence, mais la spec n'est pas amendée
Tests (§9 règles non testables) : "Aucun checkpoint_id Gate 3 dans D-296-03 et aucun flux Gate 3 en §5.5" — listé comme bloquant
Impact : CRITIQUE. Le document tests identifie lui-même ce problème comme bloquant. Le plan le résout mais la spec reste en l'état.

4. Zones d'ombre¶

ZO-01 : Interface init_formal_checkpoints — Les code contracts (C2) listent une interface init_formal_checkpoints <story_id> qui n'est mentionnée nulle part dans le plan (§2.1 flux technique). Quand est-elle appelée ? Par quel skill ? Avant quel step ? Cette initialisation est un prérequis implicite non documenté.
ZO-02 : Scope exact de formal_spec (GATE3_SPEC_FORMAL) — Le plan indique que le 6e checkpoint invoque /formal-verify avec scope formal_spec pour "vérifier l'alignement spec<>tests<>invariants avant Gate 3". Mais ce scope et ce périmètre de vérification ne sont pas contractualisés. Quelle est la différence concrète entre coherence_spec (STEP1) et formal_spec (GATE3) ? Sans cette distinction, le checkpoint GATE3 risque d'être redondant avec STEP1.
ZO-03 : Cascade de re-vérification post-correction Gate — Le plan (§9.3 Pièges connus) mentionne : "Si Gate 8 échoue → le code est corrigé → il faut relancer STEP6_CODE_FORMAL ET GATE8_FINAL_FORMAL". Mais ni la spec, ni les tests, ni les contracts ne formalisent cette règle de cascade. Quels checkpoints doivent être relancés après chaque gate ? La règle est-elle systématique (tous les checkpoints depuis la dernière modification) ou ciblée ?
ZO-04 : Comportement du --force-recheck dans la matrice FSM — Si DIV-05 est résolu en faveur du plan (PASSED→PENDING via --force-recheck), la matrice de transitions §5.4 de la spec doit être amendée. Mais : comment cela interagit-il avec l'idempotence ? Un artefact modifié génère une nouvelle idempotency_key (H-PLAN-04), donc le replay n'est pas idempotent. Est-ce documenté ?
ZO-05 : SLA configurabilité — nommage des clés — La spec (Q-296-04) et les tests (§9 non testable) signalent que le nommage exact des clés de configuration des SLA n'est pas fourni. Le plan mentionne GOV_FORMAL_TIMEOUT_SEC (variable d'environnement) mais ne couvre pas les autres bornes (lock TTL, idempotency window, reconciliation interval, orphan threshold, rate-limit). Comment sont-elles configurées ?
ZO-06 : Mapping GO|FAIL pour /coherence — La spec (Q-296-02) demande si le mapping est natif ou via adaptateur. Le plan (H-PLAN-01) précise le mapping (blocking:true + issues>0 → FAIL), mais c'est une hypothèse, pas un contrat. Si /coherence change son format de sortie, le mapping casse silencieusement.
ZO-07 : Epic parent Jira — Non fournie dans la spec (Q-296-01), absente du plan, référencée comme EPIC-XX dans les tests. Tracabilité incomplète.
ZO-08 : Interaction --force-recheck avec les guards aval — Si un checkpoint est relancé en force-recheck (PASSED→PENDING→RUNNING), les guards aval bloquent-ils immédiatement (puisque l'état n'est plus PASSED) ? Les skills en cours d'exécution en aval sont-ils interrompus ? Non documenté.

5. Recommandation¶

Procéder — convergence confirmée, aucun conflit bloquant
Rework nécessaire — divergences à résoudre avant de continuer
Escalade — décision humaine requise sur un point structurant

Justification¶

Les divergences DIV-01 à DIV-04 et DIV-08/09 sont CRITIQUES : le plan introduit un 6e checkpoint (GATE3_SPEC_FORMAL) que la spec ne connaît pas. Les enums contractuels D-296-03/04/05, l'invariant INV-296-01, et les bornes §5.2 doivent être alignés. Sans cet alignement, l'implémentation est en conflit direct avec les invariants non négociables de la spec.

La divergence DIV-05 (terminalité de PASSED) est MAJEURE : le plan introduit une exception (--force-recheck) que la spec et les tests interdisent explicitement. Ce point doit être tranché et la spec amendée si le plan est retenu.

Actions requises avant Gate 5 : 1. Amender la spec : INV-296-01 → 6 checkpoints, D-296-03/04/05 → ajouter les valeurs GATE3, §5.5 → ajouter flux F-296-06 (Gate 3), §5.2 → mandatory_checkpoints_per_story = 6 2. Amender la spec §5.4 : documenter la transition PASSED → PENDING sous condition --force-recheck OU retirer ce mécanisme du plan 3. Mettre à jour le document tests : intégrer TC-INV-01..04, lever la réserve "bloquante" sur Gate 3, amender TC-NEG-12 si PASSED n'est plus strictement terminal 4. Compléter les zones d'ombre ZO-01 (init) et ZO-02 (scope formal_spec vs coherence_spec)