PD-277 — Rapport de confrontation (Étape 8 — Gate CLOSURE)¶

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

1. Sources confrontées¶

2. Convergences¶

2.1 Périmètre et objectif¶

• Tous les documents s'accordent sur l'objectif : supprimer les 2 non-conformités bloquantes restantes (CHECK 23 anti-rejeu nonce, CHECK 24 PKI certificate binding).
• Tous les documents s'accordent sur le périmètre : module legal-pre uniquement, aucune modification de pre.service.ts ni umbral.provider.ts.
• Tous les documents excluent les 5 checks non bloquants (cron destruction, cron expiration, ETSI trusted list, blockchain anchoring, revocation propagation).

2.2 Invariants — Couverture complète et cohérente¶

Les 8 invariants INV-277-01 à INV-277-08 sont définis de manière identique dans la spécification, repris intégralement dans la matrice de couverture des tests (§2), mappés un à un dans le plan d'implémentation (§3), et vérifiés dans le rapport d'acceptabilité (⅞ PASS applicatif, INV-277-06 validé par configuration infra conformément à la spec §5 et aux tests §9). Aucune divergence de formulation ou de sémantique sur les invariants.

2.3 Codes d'erreur — Alignement 4 documents¶

Les 5 codes d'erreur (ERR-NONCE-MISSING, ERR-NONCE-FORMAT, PRE_NONCE_REPLAY_DETECTED, PRE_CERTIFICATE_BINDING_FAILED, ERR-PERSISTENCE-CONTROL) sont définis dans la spécification §10, testés dans les scénarios TC-ERR-01 à TC-ERR-07, implémentés dans le plan C6, et vérifiés dans l'acceptabilité.

2.4 Mécanisme anti-rejeu nonce¶

• Spec ↔ Plan ↔ Acceptabilité : le format UUID v4 lowercase ASCII 36 caractères est contractualisé dans spec §4, implémenté via regex dans plan C3, et validé par l'acceptabilité (correction S-01 : retrait du flag i pour strictement lowercase).
• Spec ↔ Plan : l'atomicité (vérification + insertion + re-chiffrement dans transaction SERIALIZABLE) est définie spec §7 et détaillée plan §2 flux F2.
• Acceptabilité : confirme la correction S-02 (remplacement includes() applicatif par opérateur JSONB @> atomique DB-level), alignant l'implémentation sur le plan C3 qui prescrivait déjà @>.

2.5 PKI certificate binding¶

• Spec ↔ Plan ↔ Tests : la création de LegalReKey exige owner_certificate_id et recipient_certificate_id valides (spec INV-277-04, plan C4, tests TC-NOM-01 / TC-ERR-04/05/06).
• Spec ↔ Plan : l'immuabilité post-création est définie spec INV-277-05 et implémentée plan C5.
• Acceptabilité : confirme la couverture avec tests d'immuabilité présents dans repository.spec.ts (faux positif review initiale corrigé).

2.6 Faits Prolog — Convergence sur les 3 faits canoniques¶

Tous les documents s'accordent sur les 3 faits canoniques attendus : - entity_column(legal_re_key, used_nonces, jsonb). - entity_column(legal_re_key, owner_certificate_id, varchar). - entity_column(legal_re_key, recipient_certificate_id, varchar).

Le plan confirme qu'aucune modification de extract-facts.py n'est requise (extraction automatique depuis @Column).

2.7 Migration DDL¶

• Spec ↔ Plan : 3 colonnes ajoutées avec migration up/down (spec §6, plan C1, flux F4).
• Tests : TC-NOM-05 couvre up/down.
• Acceptabilité : CA-277-09 validé.

2.8 Critères d'acceptation¶

Les 9 critères CA-277-01 à CA-277-09 sont définis dans la spec, testés dans les scénarios, mappés dans le plan, et évalués dans l'acceptabilité. L'acceptabilité confirme : 174/174 tests legal-pre PASS, coverage 92.89%, ESLint 0 erreur, TypeScript 0 erreur.

2.9 Absence de nouvel état métier¶

Tous les documents confirment qu'aucun nouveau StatusEnum n'est introduit par PD-277 (INV-277-08, CA-277-08, TC-INV-08).

2.10 Corrections post-review sécurité¶

L'acceptabilité documente 2 corrections de sécurité (S-01 regex lowercase strict, S-02 anti-replay atomique JSONB) qui alignent l'implémentation sur les exigences déjà formulées dans la spec §4 et §7 et le plan C3. Les corrections ne sont pas des ajouts : elles corrigent des écarts d'implémentation vers la cible contractuelle.

3. Divergences¶

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

DIV-01 — DEFAULT DDL colonnes certificats : spec vs plan vs implémentation¶

• Spécification §6 (DDL contractuel) : déclare owner_certificate_id VARCHAR(255) NOT NULL et recipient_certificate_id VARCHAR(255) NOT NULL sans DEFAULT.
• Plan C1 : introduit DEFAULT '' (chaîne vide) pour les deux colonnes certificats, justifié par H-277-T01 (LegalReKey pré-existants) et contractualisé comme décision d'implémentation.
• Acceptabilité E-01 : identifie cet écart, le classifie MINEUR (divergence documentaire non fonctionnelle), note que l'implémentation suit le plan et que la spec sera alignée post-merge.
• Impact : La spec n'a pas été formellement amendée. La protection fail-closed du flux F2 étape 3b (rejet des ReKeys avec certificats vides) neutralise le risque fonctionnel. Écart documentaire, pas fonctionnel.

DIV-02 — Audit Prolog : objectif 24/24 vs résultat 23/24¶

• Spécification §1 : objectif "24/24 checks BLOQUANTS à l'état OK".
• Spécification §11 CA-277-07 : "L'audit Prolog retourne 24/24 checks BLOQUANTS OK".
• Tests TC-NOM-04 : attendu "24/24 checks bloquants à OK".
• Acceptabilité (métriques finales) : rapporte "Prolog audit : 23/24 OK (HSM FIPS attendu en échec)".
• Impact : Le résultat observable (23/24) ne satisfait pas l'objectif contractuel (24/24) tel que formulé. L'acceptabilité ne fournit pas d'analyse formelle de ce delta. Le check HSM FIPS pourrait être : (a) un des 24 checks bloquants déjà en échec avant PD-277, auquel cas c'est une non-régression mais l'objectif contractuel reste non atteint tel que formulé ; ou (b) un des 5 checks de complétude non bloquants exclus par la spec §2, auquel cas le comptage 23/24 est un artefact de présentation et non une divergence réelle. Aucun document ne tranche cette ambiguïté.

DIV-03 — Phase Sonar BLOQUANTE : obligation vs indisponibilité¶

• Procédure workflow (CLAUDE.md, rules/procedures.md) : Phase 1.5 Sonar local est BLOQUANTE. "Si Sonar QG ERROR → STOP avant reviews LLM."
• Acceptabilité Phase 1.5 : "Quality Gate : INDISPONIBLE. Raison : Token Sonar non disponible dans Vault (réponse null). Action : Vérification reportée au pipeline CI/CD post-merge."
• Impact : L'acceptabilité a poursuivi vers Phase 2 (reviews LLM) sans Sonar, contrevenant à la procédure établie. Le report au CI/CD post-merge crée une fenêtre de risque (security hotspots, code smells non détectés à ce stade). Il s'agit d'une dérogation de fait, non formellement validée.

DIV-04 — Couverture tests unitaires : 10/29 TC¶

• Tests v2 (§10 Verdict QA) : prescrit "Exécuter la suite complète (nominaux, erreur, invariants, non-régression, adversarial)" sans distinction de niveau.
• Acceptabilité §2.2 : rapporte "Couverture contractuelle : 10/29 TC en tests unitaires". Les 19 TC restants sont classifiés intégration/CI/infra.
• Plan §5 : introduit une colonne "Niveau de test visé" (Unit / Integration / Review) pour chaque TC, légitimant la répartition.
• Impact : La distinction unitaire/intégration est introduite par le plan mais n'apparaît ni dans la spec ni dans les tests. L'acceptabilité fournit une analyse détaillée de chaque TC manquant. Un seul écart réel identifié : T-01 (TC-ERR-07 couvert implicitement mais pas explicitement testé), classifié MINEUR.

4. Zones d'ombre¶

ZO-01 — Comptage exact des checks bloquants vs non bloquants¶

La spécification §2 exclut 5 checks de complétude non bloquants mais ne fournit pas la liste numérotée des 24 checks bloquants vs les 5 non bloquants. L'audit rapporte 23/24 avec HSM FIPS en échec. Aucun document ne clarifie si le check HSM FIPS fait partie des 24 bloquants ou des 5 non bloquants. Cette ambiguïté empêche de trancher formellement DIV-02.

ZO-02 — Résultat post-corrections (commit f2e2cc6)¶

L'acceptabilité mentionne 2 corrections de sécurité (S-01, S-02) et 2 ajouts de tests (TC-NEG-01, TC-ERR-03) dans le commit f2e2cc6. Aucun document ne confirme explicitement : - Que les 174/174 tests passent toujours après ces corrections. - Que la coverage n'a pas baissé. - Que le pipeline CI/CD GitLab est vert post-corrections.

Les métriques finales (174/174, 92.89%) sont présentées sans préciser si elles sont pré ou post-corrections.

ZO-03 — 4 échecs tests pré-existants hors module legal-pre¶

L'acceptabilité Phase 1 mentionne "4 échecs pré-existants dans d'autres modules (deposit.controller, delete-account-rate-limit, reauth-token-blacklist, session-invalidation) — vérifiés non liés à PD-277". La méthode de vérification n'est pas documentée (pas de diff baseline avant/après, pas de commit de référence pré-PD-277).

ZO-04 — Stubs TSP sans story de destination précise¶

L'acceptabilité (D-01, D-02) documente 2 stubs (TspVerifierStub, consultDocument TODO) avec mention "destination PD-XXX" sans numéro de story réel. La procédure (.claude/rules/procedures.md) exige que chaque stub inter-PD porte la story de destination exacte. L'absence de numéro de story concret rend ces stubs non traçables selon la convention.

ZO-05 — Comportement des ReKeys hérités (pré-PD-277) en production¶

Le plan (V5, F2 étape 3b) contractualise le rejet fail-closed des ReKeys avec certificats vides. L'acceptabilité ne mentionne pas de test explicite de ce scénario. Les tests (TC-*) ne couvrent pas explicitement le cas "ReKey avec owner_certificate_id = '' tente reEncrypt". Ce cas est couvert implicitement par le mécanisme fail-closed, mais aucun TC ne le vérifie nominalement.

ZO-06 — Planification du backfill LegalReKey pré-existants¶

Le plan V5 contractualise le DEFAULT transitoire '' pour les certificats et mentionne "sera supprimé lors du backfill (story séparée)". Aucun document ne référence l'identifiant de cette story de backfill ni le délai acceptable pour ce DEFAULT transitoire en production.

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 :

La convergence globale des 4 documents est forte (invariants, codes d'erreur, mécanismes, périmètre). Cependant, 2 divergences nécessitent un positionnement explicite du PMO avant verdict :

1. DIV-02 (23/24 vs 24/24) : l'objectif contractuel n'est pas atteint tel que formulé. Le PMO doit statuer sur la nature du check HSM FIPS manquant (bloquant pré-existant ou non bloquant mal comptabilisé). Si le check HSM FIPS est hors périmètre des 24 bloquants, l'objectif est satisfait et DIV-02 tombe.

2. DIV-03 (Sonar indisponible) : la procédure BLOQUANTE n'a pas été respectée pour une raison d'infrastructure. Le PMO doit accepter formellement la dérogation ou exiger l'exécution Sonar avant verdict.

Les divergences DIV-01 (DEFAULT DDL) et DIV-04 (couverture TC 10/29) sont documentées, justifiées et classifiables MINEUR — elles ne nécessitent pas de rework.