Aller au contenu

PD-277 — Rapport de confrontation (Étape 3)

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

1. Sources confrontées

  • Spécification canonique v2 : PD-277 — Specification canonique anti-rejeu nonce et PKI certificate binding (v2) (étape 1 — spécification)
  • Scénarios de tests contractuels v2 : PD-277 — Scénarios de tests contractuels (v2) (étape 2 — tests & validation)

2. Convergences

  • Objectif de conformité aligné : exigence explicite de 24/24 checks bloquants OK dans la spécification (objectif, CA-277-07) et dans les tests (TC-NOM-04, TC-ERR-10, verdict QA).
  • Couverture des deux non-conformités bloquantes alignée : anti-rejeu nonce (CHECK 23) et PKI binding (CHECK 24) présents et testés dans les deux documents.
  • Contrat de persistance convergent : ajout de used_nonces, owner_certificate_id, recipient_certificate_id avec contraintes attendues, repris dans TC-NOM-05.
  • Invariants de sécurité cohérents : fail-closed, unicité nonce par LegalReKey, immutabilité des certificats, traçabilité Prolog, absence de nouveaux StatusEnum Legal* (matrice de couverture + tests dédiés).
  • Exigence d'atomicité/concurrence convergente : la spécification impose une exécution atomique et les tests couvrent la concurrence/rejeu simultané (ST-277-06, TC-NEG-02).
  • Contrôle Prolog convergent : obligation de régénération _generated-facts.pl puis run_audit. dans les deux documents (F3/F4, TC-NOM-03/04, TC-ERR-09).
  • Migration et non-régression convergentes : up/down obligatoires, stabilité des checks 1..22 et absence d'impact hors périmètre legal-pre (CA-277-09, TC-NR-01..03).

3. Divergences

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

  • DIV-01 : Origine du nonce incohérente entre contrat de génération et scénarios de tests.
  • Source A (Spécification, §4 Format du nonce) : nonce généré côté serveur uniquement via crypto.randomUUID(), jamais côté client.
  • Source B (Tests, TC-ERR-01, TC-ERR-02, TC-NEG-01) : les cas supposent un nonce fourni en entrée d'appel (absent, mal formé, variations de casse/espaces), donc piloté par le client/appelant.

  • Impact : ambiguïté d'architecture d'API (reEncrypt) et risque de verdict gate contestable sur une base de tests qui valident un mode d'entrée différent du mode de génération contractuel.

  • DIV-02 : Portée de vérification Prolog potentiellement contradictoire (exactement vs au minimum).

  • Source A (Spécification, §8) : les trois faits CHECK 23/24 sont obligatoires dans _generated-facts.pl avant audit.
  • Source B (Tests, TC-NOM-03) : exige que le fichier contienne exactement les faits attendus (les trois lignes listées).
  • Impact : un fichier Prolog valide contenant d'autres faits légitimes pourrait être déclaré en échec de test malgré conformité réelle, créant un faux négatif QA.

4. Zones d'ombre

  • Le mécanisme exact d'application de l'immutabilité des certificats n'est pas précisé (contrainte DB, garde service, subscriber TypeORM, combinaison), alors que les tests attendent un rejet explicite.
  • Le protocole probatoire de INV-277-06 n'est pas défini opérationnellement (format de preuve, source, seuil d'acceptation) malgré son caractère obligatoire pour la conformité.
  • La baseline de référence des StatusEnum Legal* (source canonique, commit/tag, artefact) n'est pas identifiée, alors que la comparaison avant/après est exigée.
  • La vérification "impact triggers/workers dépendants" est demandée par la spécification (stratégie migration) mais sans critères observables dédiés dans le plan de test.
  • Le périmètre exact de TC-NR-02 ("hors module legal-pre") n'énumère pas les composants cibles à contrôler, laissant un risque de couverture partielle.

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