PD-281 — Rapport de confrontation (Étape 5 — v2)¶

Ce rapport est produit par l'orchestrateur Claude avant la gate 5 PMO (AMBIGUITY). Il confronte les documents produits pour identifier convergences, divergences et zones d'ombre. Version 2 : basée sur le Plan v2 et les Code Contracts v2 (corrections post-review v1/v2).

1. Sources confrontées¶

2. Convergences¶

• CONV-01 — 8 invariants identiques : Les 4 documents partagent la même liste de 8 invariants (INV-281-01 à INV-281-08) avec formulations et justifications cohérentes. Convergence totale.

• CONV-02 — 5 couples d'exclusion : Spec (§5.2), Tests (TC-NOM-04), Plan (C1) et Code contracts (module discriminateur-enum) listent les mêmes 5 couples exclus : anchor_batch_event.event_type, key_envelope.envelope_type, legal_access_event.event_type, legal_mandate.validation_status, deposit.document_category. Convergence totale.

• CONV-03 — Discrimination couple entité+colonne (v2) : Le Plan v2 corrige l'écart AMB-02 de la review v1 : le pseudo-code itère sur le couple (ent_name, field) et filtre par field == 'status' ou mapping explicite. Aligné avec Spec §5.2 et INV-281-01. Convergence restaurée.

• CONV-04 — TimestampBatchStatus explicite (v2) : Le Plan v2 corrige l'écart ECT-01 : TimestampBatchStatus est créé explicitement dans RFC_3161.zed (SECTION 1), avec mapping _z_enum_type_mappings référençant {'timestamp_batch': 'TimestampBatchStatus'}. Aligné avec Spec §5.3 et TC-NOM-05. Convergence restaurée.

• CONV-05 — 4 types Z obligatoires : Les 4 types Z, leurs fichiers .zed cibles et leurs valeurs exactes sont cohérents entre Spec §5.3, Tests TC-NOM-05, Plan §1 C2 et Code Contracts completion-types-z. Convergence totale.

• CONV-06 — Règle conditionnelle DepositStatus : Spec (§5.3), Tests (TC-NOM-06, TC-NOM-07), Plan (C4, Flux D) et Code contracts (module condition-deposit-status) convergent sur la logique binaire : si deposit.status existe → DepositStatus obligatoire ; sinon → non exigé. Convergence totale.

• CONV-07 — Objectif global 9/9 PASS : Spec §5.4, Tests TC-NOM-08, Plan C3 et Code contracts regeneration-validation convergent sur verify-norm.sh = SUCCESS et AUDIT-SYNTHESIS.md affichant Z-lint 9/9 PASS. Convergence totale.

• CONV-08 — Périmètre doc-only : Spec (INV-281-08, §2), Tests (TC-NOM-12, TC-NR-03), Plan (§10) et Code contracts (INV-281-08 sur chaque module) convergent : modifications limitées à ProbatioVault-doc. Convergence totale.

• CONV-09 — Idempotence : Les 4 documents exigent le déterminisme. Le Plan précise le mécanisme (sorted(), pas de random). Tests TC-NOM-09 et TC-ERR-07 couvrent les deux cas. Convergence totale.

• CONV-10 — Non-régression Anchor entity : Les 4 documents exigent que les checks Anchor entity restent inchangés. Le Plan précise le mécanisme (dict entities séparé de enum_states). Tests TC-NOM-10, TC-NR-01, TC-ERR-06 couvrent ce point. Convergence totale.

• CONV-11 — z-notation-lint.py non modifié : Spec (§2 Exclu), Plan (§10) et Code contracts (forbidden sur modules discriminateur-enum et regeneration-validation) convergent.

• CONV-12 — Couverture de test : Tests (§2 Matrice) couvrent les 8 invariants et les 8 CAs. Plan (§5) mappe chaque test à un mécanisme et un observable concrets. Convergence totale.

3. Divergences¶

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

• DIV-01 — Ensemble des norm_id : Spec vs Plan vs Filesystem
• Spec §5.1 : regex norm_id inclut etsi-119-xxx, eidas, rgpd dans l'ensemble fermé (9 valeurs : pv-anchor, nf-z42-013, iso-14641, rfc-3161, pv-envelope, pv-pre, etsi-119-xxx, eidas, rgpd).
• Plan H-281-01 : les 9 normes réelles vérifiées sur le filesystem sont rfc-3161, rfc-5054, nf-z42-013, iso-14641, pv-anchor, pv-audit, pv-envelope, pv-pre, pv-proof.
• Écart : 3 norm_ids de la Spec (etsi-119-xxx, eidas, rgpd) n'existent pas sur le filesystem. 3 norm_ids du filesystem (rfc-5054, pv-audit, pv-proof) ne sont pas dans la regex de la Spec. Le Plan note "divergence AMB-01 résolue, la Spec doit être mise à jour" — mais la Spec canonique n'a pas été modifiée.

• Impact : MAJEUR. TC-NEG-05 teste contre la regex de la Spec. En exécution réelle, des norm_ids valides du pipeline (rfc-5054, etc.) seraient rejetés par la regex, et des norm_ids de la Spec (etsi-119-xxx, etc.) ne correspondent à aucun dossier. La Spec est le contrat canonique ; le Plan ne peut pas unilatéralement déclarer qu'elle "doit être mise à jour".

• DIV-02 — Clé d'écrasement multi-enum dans anchored_enums

• Plan §1 C1 pseudo-code v2 : anchored_enums[ent_name] = {'values': values, 'expected_z_type': z_type} — la clé reste ent_name. Si une entité a deux colonnes éligibles (ex : status + mapping explicite), la seconde écrase la première.
• Plan §9.1 : identifie ce risque et propose la mitigation multi-enum (liste d'enums par entité). La décision architecturale §code_contracts confirme "Adapter_collect_zlint_entities() pour le multi-enum par entité".
• Spec INV-281-01 : "Seules les colonnes status et celles mappées dans _z_enum_type_mappings sont éligibles" — implique que chaque colonne éligible doit produire son check.
• Écart : Le pseudo-code v2 du §1 C1 n'intègre pas la correction multi-enum dans la structure anchored_enums. Le mécanisme décrit dans le corps du Plan (§9.1) et le pseudo-code (§1 C1) sont contradictoires.

• Impact : MAJEUR. Perte silencieuse possible d'un check Anchor enum. Violation potentielle d'INV-281-03.

• DIV-03 — Code Contracts forbidden vs Plan Flux D (_z_enum_type_mappings)

• Code Contracts discriminateur-enum : forbidden: "Supprimer ou modifier des entrées existantes dans _z_enum_type_mappings".
• Plan §2 Flux D étape 3c : "Mettre à jour _z_enum_type_mappings si nécessaire" (pour le cas DepositStatus).
• Interprétation : La clause forbidden interdit la modification d'entrées existantes. L'ajout d'une nouvelle entrée (mapping deposit pour DepositStatus) pourrait être considéré comme hors de cette interdiction. Mais la formulation est ambiguë : "modifier des entrées" couvre-t-il l'ajout ?

• Impact : MAJEUR. L'agent d'implémentation pourrait hésiter sur la légitimité d'ajouter un mapping pour deposit. Ambiguïté d'exécution contractuelle.

• DIV-04 — Chevauchement de périmètre fichiers entre modules Code Contracts

• Code Contracts completion-types-z : files inclut NF_Z42_013.zed et ISO_14641.zed.
• Code Contracts condition-deposit-status : files inclut les mêmes NF_Z42_013.zed et ISO_14641.zed.
• Écart : Deux modules distincts avec owner_agent: agent-developer modifient les mêmes fichiers sans règle d'arbitrage ni ordre d'exécution défini.

• Impact : MINEUR (même agent dans les deux cas pour un périmètre doc-only). Néanmoins, la traçabilité d'audit est affaiblie : quelle modification de NF_Z42_013.zed relève de quel module contractuel ?

• DIV-05 — Couverture minimale 80% hors contrat Spec

• Plan §12 : "La couverture minimale de 80% s'applique à l'ensemble du périmètre."
• Spec : Aucune mention d'un seuil de couverture de 80%.

• Impact : MINEUR. Le Plan introduit une exigence normative absente de la Spec canonique. Ajout de garde supplémentaire non contractualisé.

• DIV-06 — Contraintes techniques non documentées dans le Plan

• Review v2 : relève l'absence de section "Contraintes techniques" dédiée (framework de test, compatibilité ESM/CJS, dépendances inter-PD avec statut, variables CI).
• Plan v2 : aucune section ajoutée pour répondre à ces écarts.
• Spec §10.1 : demande confirmation que la stack ProbatioVault-doc (Shell, Python 3, YAML, .zed, Markdown) est la référence.
• Impact : MAJEUR au regard des exigences de revue. Modéré en pratique pour un périmètre doc-only (pas de Jest/Vitest, pas d'ESM/CJS). Mais la non-réponse laisse le point formellement non résolu.

4. Zones d'ombre¶

• ZO-01 — Existence de deposit.status non confirmée : Spec (§10.8, H-281-05), Tests (§9 — impact Majeur), Plan (§9.5, H-281-05) reconnaissent tous que l'existence de deposit.status comme colonne lifecycle n'est pas confirmée. CA-08 et TC-NOM-06/TC-NOM-07 en dépendent. Le Plan C4 fournit le mécanisme de vérification (recherche dans les faits Prolog) mais le résultat reste inconnu avant exécution.

• ZO-02 — Référence épique non propagée : La Spec indique "A clarifier (reference epique non fournie)". Les Tests utilisent "EPIC-XX". Le WORKFLOW-STATE.md contient PD-217 (LEGAL & COMPLIANCE). La référence est connue mais non propagée dans les documents canoniques.

• ZO-03 — Coexistence BatchState / TimestampBatchStatus dans RFC_3161.zed : Le Plan v2 §9.2 corrige ECT-01 en créant TimestampBatchStatus explicitement, avec BatchState qui coexiste. La décision architecturale note "le linter ne valide que les types référencés par expected_z_type". Mais aucun document ne confirme contractuellement que deux types avec les mêmes valeurs dans le même .zed ne causent pas de conflit ou d'avertissement dans le linter.

• ZO-04 — Garantie non-régressive des 5 exclusions : Le Plan traite les 5 exclusions comme conséquence mécanique du filtre field != 'status'. Si l'une de ces 5 entités est ajoutée à _z_enum_type_mappings dans le futur, elle serait automatiquement incluse. Aucun garde-fou explicite (assertion, test de régression dédié vérifiant l'exclusion de la liste contractuelle) n'est contractualisé au-delà de TC-NOM-04 (test d'intégration ponctuel).

• ZO-05 — Contenu actuel de _z_enum_type_mappings : Les 4 documents réfèrent à cette structure comme mécanisme central mais aucun ne liste les mappings existants. Le Plan v2 ajoute un mapping rfc-3161 ({'timestamp_batch': 'TimestampBatchStatus'}). Le Code contracts interdit de "modifier des entrées existantes" sans les énumérer.

• ZO-06 — Impact du multi-enum sur les consommateurs de enum_states : Plan §9.1 propose de passer de dict[entity] = {field, values} à dict[entity] = [{field, values}, ...]. L'impact sur les fonctions autres que write_zlint_config() qui accèdent à enum_states n'est pas documenté.

• ZO-07 — Liste nominale exacte des 9 normes : Le Plan liste les 9 normes réelles. Les Tests et la Spec utilisent le cardinal (9) sans les nommer toutes. Tests §9 signale "Majeur — les noms exacts ne sont pas fournis dans l'entrée". La concordance exacte repose sur le filesystem, pas sur un contrat.

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 corrections v2 ont résolu les deux écarts bloquants de la confrontation v1 :

• Ex-DIV-01 (TimestampBatchStatus) → résolu : le Plan v2 crée explicitement le type dans le .zed (CONV-04).
• Ex-DIV-03 (nombre de types Z) → résolu : conséquence de la résolution de DIV-01.

Cependant, 4 divergences résiduelles subsistent :

1. DIV-01 (norm_id set) — MAJEUR : La regex de la Spec est contractuelle mais ne correspond pas au filesystem. Le Plan déclare unilatéralement que "la Spec doit être mise à jour" sans que cette mise à jour ait été effectuée. Décision requise : mettre à jour la Spec §5.1 ou adapter le Plan au périmètre normatif de la Spec.

2. DIV-02 (clé d'écrasement multi-enum) — MAJEUR : Le pseudo-code v2 et la section §9.1 du Plan sont contradictoires. Le pseudo-code utilise ent_name comme clé unique, tandis que §9.1 recommande une liste. Correction requise : aligner le pseudo-code sur la structure multi-enum décrite en §9.1.

3. DIV-03 (forbidden vs ajout mapping) — MAJEUR : La clause forbidden du Code Contracts est ambiguë sur la distinction entre "modifier une entrée existante" et "ajouter une nouvelle entrée". Clarification requise dans le code contracts.

4. DIV-06 (contraintes techniques) — MAJEUR au regard des exigences formelles de revue, mais modéré en impact réel pour un périmètre doc-only Python/Shell.

Les DIV-01 et DIV-02 sont les plus impactantes pour l'implémentation. Recommandation : (a) aligner le pseudo-code C1 sur le multi-enum (clé composite ou liste), (b) clarifier la clause forbidden pour distinguer modification/ajout, © trancher formellement sur la liste des normes (Spec vs filesystem).