PD-81 — Confrontation Gate 5 v2¶

1. Synthese¶

Le plan v1.2.0 adresse les 3 ecarts BLOQUANTS et les 5 ecarts MAJEURS identifies dans la review v1. Les corrections sont substantielles et documentees : ajout du LegalWriteBlockGuard (ERR-81-11), realignement de la signature generateLegalReKey sur le contrat spec §9.2, reformulation explicite du stub TSP comme dette technique tracee (pas comme suffisance), formalisation du controle bloquant bobPublicKey, retrait du role admin, ajout de la delegation IAM pour getLegalAuditProof, alignement des champs du snippet de monitoring, et distinction explicite entre invariants contractuels et contraintes d'ingenierie dans les code-contracts.

Neanmoins, l'analyse croisee revele 3 divergences residuelles (1 MAJEURE, 2 MINEURES) et 4 zones d'ombre non couvertes par les corrections v2. Le plan v1.2.0 constitue une amelioration significative par rapport au v1.1.0, mais certains points meritent attention avant verdict.

2. Ecarts v1 -> traitement v2¶

3. Convergences¶

Les documents convergent sur les points suivants :

Architecture et flux : - Les 4 flux nominaux (N1-N4) sont decrits de maniere coherente entre la spec §5, le cahier de tests §2, le plan §4, et les code-contracts (modules 3, 4, 5, 7, 8, 9). L'ordre logique mandat → validation → activation → cloture est respecte dans tous les documents. - Le modele de donnees (spec §7) est fidellement transpose dans les entites TypeORM (plan §3.4) avec tous les champs obligatoires presents et les types coherents. - Les transitions d'etat LegalReKeyStatus (spec §7.3) sont identiques dans le plan §3.2 (LegalReKeyStatus enum) et les code-contracts module 1.

Invariants : - Les 12 invariants (INV-81-01 a INV-81-12) de la spec §4 sont tous mappes a des mecanismes techniques dans le plan §5, et a des invariants dans les code-contracts. - Le mapping INV → composant → test est complet dans le plan §5 et §6, et coherent avec la matrice de couverture du cahier de tests §1.1.

Cas d'erreur : - Les 18 cas d'erreur (ERR-81-01 a ERR-81-18) de la spec §6 sont tous mappes dans le plan §7 a des handlers techniques, des codes d'exception et des codes HTTP. Le cahier de tests §1.3 couvre exhaustivement les 18 erreurs.

Securite et fail-closed : - Le principe fail-closed (INV-81-11) est coherent entre spec §4, plan §8.1, et code-contracts modules 3, 5, 6. Toutes les sources s'accordent sur : pas de catch silencieux, exceptions propagees, transactions SERIALIZABLE. - L'isolation Legal/Standard (INV-81-10) est decrite de maniere coherente : spec §4 (principe), plan §8.2 (mecanisme storageDomain + custom repository), code-contracts module 5 (interdiction @InjectRepository(LegalReKey) directe).

Double validation : - Le mapping PD-82 (DPO→PARENT, LegalOfficer→AUTHORITY) est coherent entre spec §3, plan §3.5.2, code-contracts module 4. - Le controle d'identite juridique (INV-81-03, ERR-81-08) est decrit de maniere identique dans les 4 documents.

Destruction cryptographique : - Le cycle {REVOKED|EXPIRED|COMPLETED} → DESTROYED est coherent partout. - La zeroisation en 2 temps (overwrite zeros + set null) est decrite dans le plan §3.5.6 et protegee par le code-contract module 7. - Le delai destructionDeadline (defaut 1h, configurable [1min..24h]) est coherent entre spec §7.3, plan §3.1 (constantes), et code-contracts module 1.

Rate limiting : - Valeur par defaut 10/min par legalReKeyId, configurable [1..60] : coherent entre spec §3, §10.2, plan §3.6 LegalRateLimitGuard, code-contracts module 10, et tests E18/S5.

Preuve composite : - Les 5 composants de la preuve (mandateEvidence, doubleValidationEvidence, rekeyLifecycleEvidence, auditLogEvidence, anchoringEvidence) sont coherents entre spec §7.5, plan §3.5.5, et code-contracts module 8.

Criteres d'acceptation : - Les 16 AC (AC-81-01 a AC-81-16) sont tous mappes dans le plan §6. Les AC-81-15 et AC-81-16 sont correctement identifies comme non testables (hors perimetre) dans les deux documents (spec §8, tests §7).

4. Divergences residuelles¶

D-01 — Scenario R-ANCHOR : tracabilite dans le referentiel de tests (MAJEURE)¶

Sources : Plan §5 INV-81-08 [CORRECTION v2] / Cahier de tests PD-81-tests.md

Constat : Le plan v1.2.0 justifie l'absence du scenario R-ANCHOR dans le cahier de tests en indiquant que le test est dans legal-anchoring-monitor.scheduler.spec.ts (test d'implementation interne). Le cahier de tests n'est pas modifie pour autant. Or, la verification du delai d'ancrage 24h (INV-81-08) est un invariant contractuel, pas une contrainte d'ingenierie.

Impact : Le referentiel de tests contractuels ne couvre pas explicitement le mecanisme de monitoring d'ancrage. La matrice de couverture §1.1 du cahier de tests ne reference pas de scenario validant le respect du delai 24h. Le test d'implementation interne (scheduler.spec.ts) n'a pas la meme portee contractuelle qu'un scenario du cahier de tests.

Gravite : MAJEURE — L'invariant INV-81-08 mentionne "delai max 24h" mais aucun scenario du referentiel QA contractuel ne le valide explicitement.

D-02 — LegalWriteBlockGuard : application sur l'ensemble de /legal-pre/** vs endpoints specifiques (MINEURE)¶

Sources : Plan §3.6 LegalWriteBlockGuard / Plan §3.8 Controller routes / Spec §6 ERR-81-11

Constat : Le plan decrit le LegalWriteBlockGuard comme interceptant PUT/PATCH/DELETE sur /legal-pre/** (toutes les routes du controller). Or, certaines routes comme POST /legal-pre/rekeys/:id/revoke ou POST /legal-pre/access/close sont des operations de mutation d'etat (pas de lecture). Le guard ne doit pas bloquer les POST legitimement definis.

Precision : Le guard cible uniquement les methodes HTTP PUT/PATCH/DELETE, pas POST. Les routes POST du plan sont toutes des POST. Donc pas de conflit fonctionnel reel — la divergence est que le plan mentionne /legal-pre/** en scope mais la spec parle de "tentative de modification/suppression document" (ERR-81-11), pas de tentative de modification d'etat de dossier.

Impact : Mineur — le scope du guard est plus large que la preoccupation spec (documents WORM), mais cela constitue une protection defense-en-profondeur acceptable. Le plan le justifie explicitement.

Gravite : MINEURE.

D-03 — activateLegalAccess : orchestration interne vs appel externe (MINEURE)¶

Sources : Spec §5 N3.1 / Plan §3.5.7 activateLegalAccess / Plan §3.3 interfaces

Constat : La spec §5 N3.1 indique que activateLegalAccess "orchestre en interne generateLegalReKey(); aucun second appel API externe n'est requis pour le meme dossier". Le plan §3.5.7 delegue a legalReKeyManager.generateLegalReKey(...) qui appelle PreService.generateReKey(). L'interface ActivateLegalAccessInput du plan ne contient pas alicePublicKey ni bobPublicKey — ces parametres doivent etre resolus en interne par l'orchestrateur a partir du dossier legal et du mandat.

Impact : Le chemin de resolution de alicePublicKey (owner du coffre) et bobPublicKey (autorite judiciaire, extrait du mandat) n'est pas explicitement decrit dans activateLegalAccess. Le plan montre GenerateLegalReKeyInput avec ces champs, mais la sequence §4.3 N3 passe directement de activateLegalAccess(input) a LegalReKeyManager.generateLegalReKey(...) sans montrer comment alicePublicKey et bobPublicKey sont resolus depuis le legalCaseId.

Gravite : MINEURE — l'information est implicitement disponible (mandat contient bobPublicKey, coffre fournit alicePublicKey), mais le chemin de resolution n'est pas explicite dans la sequence.

5. Zones d'ombre¶

ZO-01 — Story de dependance TSP reel : creation et calendrier¶

Sources : Plan §1 H-01 [CORRECTION v2], Spec §2.1

Le plan reformule le stub TSP comme "dette technique tracee" et mentionne "story de dependance TSP reel a creer si non existante". Mais cette story n'est pas referencee (pas de PD-XXX). La spec §2.3 point 1-2 liste des informations manquantes bloquantes liees au TSP. Aucun document ne precise quand ni comment cette dette technique sera soldee.

ZO-02 — Resolution alicePublicKey dans le flux activateLegalAccess¶

Sources : Plan §3.5.7, Plan §3.3 GenerateLegalReKeyInput, Plan §4.3 N3

Le GenerateLegalReKeyInput requiert alicePublicKey (owner du coffre). La sequence activateLegalAccess charge le LegalValidationCase et le LegalMandate, mais aucun des deux ne contient alicePublicKey. La cle publique de l'owner doit etre recuperee via un mecanisme non decrit (IAM ? KeychainService ? UserService ?). Le plan ne documente pas cette resolution.

ZO-03 — Politique de retention des preuves composites et journaux¶

Sources : Spec §2.3 point 6, Spec §10.3

La spec identifie explicitement la "politique de retention des preuves composites et journaux probatoires" comme information manquante a contractualiser. Le plan ne mentionne aucune strategie de retention, purge ou archivage des tables legal_access_event et legal_composite_proof. Pour une table append-only, la croissance est unidirectionnelle.

ZO-04 — Fenetre de 5 secondes : comportement exact des consultations en cours¶

Sources : Spec §10.2 [CORRECTION v3], Tests R7 [CORRECTION v3], Plan §8.5

La spec precise que "les consultations en cours peuvent aboutir" pendant la fenetre de 5s, mais que "toute consultation initiee apres la confirmation de la revocation DOIT etre refusee". Le plan §8.5 indique que la transaction SERIALIZABLE rend la revocation "visible immediatement" — ce qui signifierait zero tolerance (pas de fenetre). Le test R7 verifie explicitement que des consultations en cours au moment de la revocation "peuvent aboutir". Il y a une ambiguite entre le mecanisme du plan (visibilite immediate) et la tolerance de la spec/tests (consultations en cours peuvent aboutir dans la fenetre).

6. Conclusion¶

Resolution des ecarts v1 : Sur les 11 ecarts identifies dans la review v1, 10 sont pleinement corriges dans le plan v1.2.0 et les code-contracts v1.1.0. Les corrections sont substantielles, tracees par des marqueurs [CORRECTION v2], et coherentes entre les documents. Le 11e ecart (R-ANCHOR) est partiellement corrige — le mecanisme est decrit et teste dans l'implementation, mais la tracabilite dans le referentiel de tests contractuels reste absente.

Divergences residuelles : 1 divergence MAJEURE (D-01 : couverture contractuelle du monitoring ancrage 24h) et 2 MINEURES (D-02, D-03). Aucun nouveau conflit BLOQUANT n'est introduit par les corrections v2.

Zones d'ombre : 4 questions ouvertes, dont aucune ne constitue un blocage d'implementation immediat, mais dont certaines (ZO-01 story TSP, ZO-03 retention) devront etre resolues avant la mise en production.

Evaluation factuelle : Le plan v1.2.0 represente une amelioration substantielle par rapport au v1.1.0. Les 3 ecarts BLOQUANTS de v1 sont resolus. Le score risk_mitigation qui etait a 6/10 en v1 (principalement ECT-07 isolation et ECT-08 ancrage) devrait etre reevalue positivement car les deux mecanismes sont desormais decrits en detail (custom repository + monitoring scheduler). La divergence residuelle D-01 est le point le plus notable : elle concerne la tracabilite QA contractuelle, pas le design technique lui-meme.