Type de gate : AMBIGUITY
1. Documents de référence
2. Rapport de confrontation
Voir : PD-281-confrontation-step5.md
3. Hypothèses déclarées
| ID | Hypothèse | Impact si faux |
| H-281-01 | Le pipeline cible couvre exactement 9 normes (rfc-3161, rfc-5054, nf-z42-013, iso-14641, pv-anchor, pv-audit, pv-envelope, pv-pre, pv-proof) | Les CAs numériques (9/9 PASS) deviennent invalides. Ajuster le nombre cible. |
| H-281-02 | La structure actuelle de _collect_zlint_entities() stocke un seul enum par entité (le dernier trouvé). La modification pour filtrer par field doit conserver ce comportement mono-enum ou le rendre multi-enum. | Si multi-enum nécessaire (entité avec status ET event_type), adapter le dict pour une liste d'enums par entité. Le filtre doit alors itérer sur chaque enum de l'entité. |
| H-281-03 | Les fichiers .zed référencés (RFC_3161.zed, NF_Z42_013.zed, ISO_14641.zed, PV_PRE.zed) sont les sources de vérité de leurs normes respectives | Risque de corriger le mauvais artefact si un autre fichier .zed est la référence |
| H-281-04 | Le check Anchor entity et le check Anchor enum sont orthogonaux dans z-notation-lint.py (check_anchoring traite les deux sections indépendamment) | Si couplage caché, la modification du filtre enum pourrait affecter les checks entity |
| H-281-05 | deposit n'a qu'une seule colonne enum (document_category). L'existence de deposit.status est vérifiable dans les faits Prolog extraits. | Si deposit a un status, il faut ajouter DepositStatus (CA-08). Si la source de vérité est inaccessible, CA-08 n'est pas testable. |
| H-281-06 | RFC_3161.zed contient déjà un type BatchState ::= OPEN \| SEALED \| TIMESTAMPED \| FAILED (constaté). Le type à ajouter est TimestampBatchStatus avec les mêmes valeurs, car le mapping expected_z_type dans _generated-z-lint.yaml référence timestamp_batch_state (convention {entity}_state). | Si BatchState est suffisant, le mapping _z_enum_type_mappings pour rfc-3161 doit être ajouté : {'timestamp_batch': 'BatchState'}. Alternative : renommer BatchState en TimestampBatchStatus. L'approche mapping est préférable (non-breaking). |
4. Corrections v1→v2
| Écart v1 | Statut v2 | Vérification |
| ECT-01 (BLOQUANT) — TimestampBatchStatus mapping vs physique | Résolu — Plan v2 §9.2 + Code contracts v2 : création explicite du type | P2 v2 CONV-04 confirme |
| AMB-01 (MAJEUR) — Liste 9 normes divergente | Partiellement résolu — Plan H-281-01 v2 documente les normes réelles (vérifié filesystem). Spec non modifiée. | P2 v2 DIV-01 : Spec canonique non mise à jour |
| AMB-02 (MAJEUR) — Pseudo-code centré entité | Résolu — Plan v2 §1 C1 : pseudo-code itère sur couple (ent_name, field) | P2 v2 CONV-03 confirme |
5. Écarts résiduels v2 (synthèse croisée P1 v2 + P2 v2)
Écarts BLOQUANTS
Aucun.
Écarts MAJEURS
| ID | Type | Source | Description | Justification |
| AMB-01r | Divergence Spec/Plan | P1 v2 + P2 v2 DIV-01 | Normes : Spec non mise à jour — La regex norm_id de la Spec §5.1 est contractuelle mais ne correspond pas au filesystem. Le Plan documente les 9 normes réelles mais ne peut pas modifier la Spec unilatéralement. | Impact atténué : le Plan H-281-01 v2 fournit la preuve factuelle (ls filesystem). La Spec sera mise à jour lors de l'implémentation (étape 6) car elle sera consommée par l'agent. |
| AMB-06 | Écrasement multi-enum | P1 v2 BLOQUANT #1 + P2 v2 DIV-02 | anchored_enums[ent_name] : la clé de sortie reste ent_name. Si une entité a 2 colonnes éligibles, écrasement silencieux. Plan §9.1 documente le risque + mitigation mais le pseudo-code v2 §1 C1 n'intègre pas la correction multi-enum dans la structure de sortie. | Impact atténué : aucune entité n'a actuellement 2 colonnes éligibles simultanément (status + mapping explicite). Le risque est théorique. La mitigation est documentée en §9.1. |
Écarts MINEURS
| ID | Type | Source | Description | Justification |
| AMB-03 | Code contracts ambigu | P2 v2 DIV-03 | forbidden: "modifier des entrées existantes" vs ajout mapping DepositStatus. L'ajout n'est pas une modification d'existant. | Interprétation standard. |
| AMB-04 | Chevauchement modules | P2 v2 DIV-04 | Deux modules touchent NF_Z42_013.zed et ISO_14641.zed. Même agent. | Traçabilité audit faible, pas d'impact fonctionnel. |
| AMB-05 | Référence épique | P2 v2 ZO-02 | "EPIC-XX" dans Tests, "A clarifier" dans Spec. WORKFLOW-STATE contient PD-217. | Non propagé dans les documents mais connu. |
| AMB-07 | Couverture 80% hors contrat | P2 v2 DIV-05 | Plan §12 introduit "couverture 80%". Absent de la Spec. | Garde supplémentaire non contractualisée. |
| AMB-08 | Inter-PD, Variables CI | P1 v2 MINEUR + P2 v2 DIV-06 | Pas de section "contraintes techniques" dédiée. Mais PD-281 = doc (Python/Shell), pas de Jest/ESM/CI variables. | P2 note "modéré en impact réel pour doc-only". |
Écarts rejetés (faux positifs)
| Source | Motif de rejet |
| P1 v2 BLOQUANT #1 (discrimination ent_name) | Le pseudo-code v2 itère bien sur le couple (ent_name, field). P1 confond la clé de boucle avec la clé de sortie anchored_enums. Reclassifié en AMB-06 MAJEUR. |
| P1 v2 BLOQUANT #2 (TC-NOM-03 irréalisable) | Identique au faux positif v1. Plan §5 documente le mécanisme et l'observable. P1 persiste sur ce point malgré la correction v2. |
| P1 v2 MAJEUR × 2 (Jest/Vitest, ESM/CJS) | PD-281 = projet doc-only (Python/Shell). Pas de JavaScript. P2 v2 DIV-06 note "modéré en impact réel". |
Zones d'ombre (non bloquantes)
| ID | Description | Source |
| ZO-01 | deposit.status non confirmé — branche conditionnelle indéterminée (CA-08) | P2 v2 ZO-01 |
| ZO-03 | Coexistence BatchState/TimestampBatchStatus dans RFC_3161.zed — pas de conflit confirmé | P2 v2 ZO-03 |
| ZO-04 | Contenu actuel de _z_enum_type_mappings non fourni | P2 v2 ZO-05 |
| ZO-05 | Impact multi-enum sur consommateurs de enum_states non documenté | P2 v2 ZO-06 |
6. Scoring v2 (critères AMBIGUITY)
| Critère | Score v1 | Score v2 | Delta | Justification v2 |
| feasibility | 7.5 | 8.5 | +1.0 | ECT-01 résolu (TimestampBatchStatus explicite). Plan v2 techniquement solide. Pénalité résiduelle -0.5 : multi-enum clé écrasement (théorique). Pénalité -1.0 : Spec norm_id non mise à jour. |
| coverage | 8.0 | 8.5 | +0.5 | Pseudo-code v2 corrigé (couple entité+colonne). Tous tests mappés. Pénalité -0.5 : zones d'ombre deposit.status. Pénalité -1.0 : norm_id Spec/Plan pas encore harmonisé. |
| risk_mitigation | 8.5 | 9.0 | +0.5 | 6 hypothèses + 6 mitigations. ECT-01 résolu proactivement. Pénalité -0.5 : clause forbidden ambiguë. Pénalité -0.5 : chevauchement modules. |
| coherence | 7.0 | 8.0 | +1.0 | ECT-01 résolu → convergence 4 documents sur TimestampBatchStatus. AMB-02 résolu → pseudo-code aligné. Pénalité -1.0 : norm_id Spec vs filesystem. Pénalité -1.0 : multi-enum pseudo-code vs §9.1. |
7. Verdict attendu
Justification : Moyenne v2 = (8.5 + 8.5 + 9.0 + 8.0) / 4 = 8.50 ≥ 8.0 pour tous les critères → GO. Delta v1→v2 = +0.75 (significatif ≥ 0.5).