PD-281 — Rapport de confrontation (Gate 8 — Closure)¶

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

1. Sources confrontees¶

2. Convergences¶

2.1 Invariants et criteres d'acceptation¶

Les 4 documents s'accordent sur les 8 invariants (INV-281-01 a INV-281-08) et les 8 criteres d'acceptation (CA-01 a CA-08). La specification les definit, les tests les couvrent (matrice 8/8 INV, 8/8 CA), le plan les mappe a des mecanismes concrets, et l'acceptabilite confirme leur verification.

2.2 Mecanisme de discrimination¶

Convergence totale sur la regle de discrimination : - Spec §5.2 : colonnes status OU mapping explicite _z_enum_type_mappings → inclusion ; sinon → exclusion. - Tests TC-NOM-01/02/03 : testent les 3 branches (exclusion, inclusion status, inclusion mapping). - Plan C1 : pseudo-code du filtre dans write_zlint_config(). - Acceptabilite Phase 1 : Z-lint 9/9 PASS confirme l'elimination des faux positifs.

2.3 Liste des 5 exclusions contractuelles¶

Concordance exacte entre les 4 documents sur les 5 couples exclus : - anchor_batch_event.event_type - key_envelope.envelope_type - legal_access_event.event_type - legal_mandate.validation_status - deposit.document_category

2.4 Types Z obligatoires¶

Concordance sur les 4 types Z a ajouter (Spec §5.3, Tests TC-NOM-05, Plan C2, Acceptabilite INV-281-03 PASS) : - TimestampBatchStatus dans RFC_3161.zed - AnchorBatchStatus dans NF_Z42_013.zed et ISO_14641.zed - LegalReKeyStatus dans PV_PRE.zed

2.5 Perimetre doc-only¶

Les 4 documents confirment que PD-281 est limite a ProbatioVault-doc (scripts Python, fichiers .zed, configs YAML generees, documentation). Aucune modification backend.

2.6 Resultat global 9/9 PASS¶

• Spec CA-01/CA-04 : verify-norm.sh = SUCCESS, Z-lint 9/9 PASS.
• Tests TC-NOM-08 : verifie les deux observables.
• Plan C3 : decrit le flux de regeneration et validation.
• Acceptabilite Phase 1 : Z-lint 9/9 PASS confirme en execution reelle.

2.7 Non-modification du linter¶

Les 4 documents convergent : z-notation-lint.py n'est PAS modifie. La correction porte sur le generateur (extract-facts.py) et les specs (.zed).

2.8 Regle conditionnelle DepositStatus¶

Les 4 documents definissent la meme regle conditionnelle : si deposit.status existe comme colonne lifecycle → DepositStatus obligatoire dans NF_Z42_013.zed et ISO_14641.zed ; sinon → pas d'exigence.

2.9 Resolution DepositStatus¶

L'acceptabilite (E-03) et le plan (C4) convergent : l'execution reelle confirme que deposit.status est absent des faits Prolog. La branche conditionnelle n'est donc pas executee. Les tests TC-NOM-07 (branche fausse) couvrent ce cas.

3. Divergences¶

DIV-01 : Referentiel des 9 normes (Spec vs Plan)¶

• Spec §5.1 : le regex norm_id liste pv-anchor, nf-z42-013, iso-14641, rfc-3161, pv-envelope, pv-pre, etsi-119-xxx, eidas, rgpd (9 valeurs).
• Plan H-281-01 (v2) : verification filesystem identifie les 9 normes reelles comme rfc-3161, rfc-5054, nf-z42-013, iso-14641, pv-anchor, pv-audit, pv-envelope, pv-pre, pv-proof.
• Ecart : 3 normes du regex Spec n'existent pas (etsi-119-xxx, eidas, rgpd) et 3 normes reelles ne figurent pas dans le regex Spec (rfc-5054, pv-audit, pv-proof).
• Tracabilite : deja identifie comme AMB-01 en Gate 5 (v1), resolu en AMB-01r (v2). Acceptabilite le trace comme E-02 (MINEUR).
• Impact : MINEUR — le regex §5.1 de la Spec n'a pas ete mis a jour, mais le resultat 9/9 PASS est obtenu sur les normes reelles. La divergence est documentaire, pas fonctionnelle.

DIV-02 : Hypotheses — enrichissement Plan vs Spec¶

• Spec : 5 hypotheses (H-281-01 a H-281-05).
• Plan : 6 hypotheses (H-281-01 a H-281-06), ajout de H-281-06 sur la coexistence BatchState/TimestampBatchStatus dans RFC_3161.zed.
• Impact : NON BLOQUANT — enrichissement du Plan qui contractualise un risque identifie lors de l'analyse. La Spec ne l'avait pas anticipe car la decouverte de BatchState existant est un fait d'implementation.

DIV-03 : Verdict QA des tests vs verdict acceptabilite¶

• Tests §10 : verdict "Testable partiellement (avec reserves)" — 3 reserves listees (deposit.status a confirmer, liste nominale des 9 normes, reference epique).
• Acceptabilite : verdict "ACCEPTE" — 0 BLOQUANT, 0 MAJEUR, 4 MINEUR.
• Resolution : les reserves des tests ont ete levees par l'execution reelle :
• deposit.status tranche par C4 (absent).
• 9/9 PASS confirme sur les normes reelles.
• Reference epique reste incomplte (E-04, cosmetique).
• Impact : NON BLOQUANT — les reserves sont resolues par les faits d'execution.

4. Zones d'ombre¶

ZO-01 : Spec §5.1 non mise a jour (norm_id regex)¶

Le regex norm_id de la Spec §5.1 contient toujours des valeurs factuellement incorrectes (3 normes inexistantes, 3 normes manquantes). Bien que la divergence AMB-01r soit tracee depuis Gate 5, la Spec elle-meme n'a pas ete corrigee. Question : la mise a jour de la Spec est-elle requise avant cloture, ou le trace AMB-01r suffit-il ?

ZO-02 : Reference epique non fournie¶

La Spec indique "A clarifier (reference epique non fournie)". Les Tests referencent "EPIC-XX" (placeholder). L'Acceptabilite trace l'ecart E-04 (MINEUR/cosmetique). Aucun document ne fournit la reference reelle.

ZO-03 : Contenu effectif de _z_enum_type_mappings¶

La Spec definit le mecanisme de mapping explicite (INV-281-01). Le Plan reference le mapping dans le pseudo-code (C1). Mais aucun document ne fournit la liste exhaustive des entrees actuelles de _z_enum_type_mappings par norme. L'acceptabilite confirme que le resultat est correct (9/9 PASS), mais la configuration exacte n'est pas documentee dans les artefacts de gouvernance.

ZO-04 : Tests negatifs et adversariaux — execution non tracee¶

Les tests definissent 10 scenarios negatifs (TC-NEG-01 a TC-NEG-10) portant sur la validation des formats §5.1. L'acceptabilite Phase 1 confirme la syntaxe Python/Shell et le Z-lint 9/9 PASS, mais ne mentionne pas explicitement l'execution des tests negatifs. Ces scenarios sont-ils des exigences de design (verification par inspection) ou des tests executables ?

ZO-05 : Coexistence BatchState / TimestampBatchStatus¶

Le Plan (§9.2) documente la decision d'ajouter TimestampBatchStatus explicitement dans RFC_3161.zed alors que BatchState avec les memes valeurs existe deja. Le risque de conflit linter est evalue comme faible. Mais ni la Spec ni les Tests ne mentionnent BatchState ni ne contractualisent cette coexistence. L'acceptabilite ne la releve pas non plus.

5. Recommandation¶

• Proceder — convergence confirmee, aucun conflit bloquant

Justification :

Les 4 documents sont fortement convergents sur les 8 invariants, les 8 criteres d'acceptation, le mecanisme de discrimination, les types Z, le perimetre et le resultat global 9/9 PASS.

Les 3 divergences identifiees sont toutes NON BLOQUANTES : - DIV-01 est une divergence documentaire deja tracee depuis Gate 5 (AMB-01r). - DIV-02 est un enrichissement du Plan, pas une contradiction. - DIV-03 est resolue par les faits d'execution (acceptabilite leve les reserves des tests).

Les zones d'ombre sont de criticite MINEURE : ZO-01 et ZO-02 sont cosmetiques (mise a jour documentaire), ZO-03 et ZO-04 concernent la granularite de tracabilite (non bloquant pour le verdict), ZO-05 est un risque faible documente dans le Plan.

Rapport genere le 2026-03-01 par l'orchestrateur Claude (confrontation pre-Gate 8).