Aller au contenu

PD-280 — Plan d'implementation : Revue

1. References

  • Specification : PD-280-specification.md
  • Tests contractuels : PD-280-tests.md
  • Plan d'implementation : PD-280-plan.md
  • Date de revue : 2026-03-01
  • Reviewer : OpenCode (auditeur technique independant)

2. Constatations (ecarts)

Type Reference (Spec/Test/Plan) Description Impact Gravite (BLOQUANT/MAJEUR/MINEUR)
Non-conformite Spec Spec §3, §4 (INV-280-06), §5.1 / Plan §1 C5 (DDL-02), §2.3 Le plan materialise verification_request_id uniquement quand un premier resultat DONE est produit, sans mecanisme contractuel explicite pour porter le meme identifiant sur la verification en phase PENDING. L'identifiant technique ne garantit pas l'identite d'une verification de bout en bout (PENDING -> DONE) telle que contractuellement imposee. BLOQUANT
Couverture manquante Spec §4 (INV-280-05) / Plan §2.2, §3 (INV-280-05), §11 Le plan est en lecture seule et delegue les mutations a des processus externes, sans mecanisme non contournable dans le perimetre pour empecher une transition terminal OK/KO/INDETERMINATE -> PENDING. L'invariant de monotonie des maillons n'est pas protege par design dans le perimetre implemente. MAJEUR
Test irrealisable Tests TC-INV-05, TC-NEG-06 / Plan §2.2, §5 (ligne TC-INV-05) Les tests demandent un "refus deterministe" d'une transition retour terminal -> PENDING, mais le plan ne decrit ni point d'ecriture sous controle du perimetre ni garde de persistance; le mapper de sortie ne porte pas d'historique de transition. Oracle de test non decidable de facon auditable avec les mecanismes explicitement planifies. BLOQUANT
Hypothese implicite Spec §5.2 / Plan §1 C5 (DDL-03), §8 (HT-06), §13 (CT-04) Le plan suppose qu'un processus externe renseigne pending_since a chaque passage en PENDING, mais ce producteur n'est pas contractualise comme dependance inter-PD avec statut explicite. Les transitions SLA lazy et les tests associes dependent d'une propriete externe implicite. MAJEUR
Risque secu/conformite Spec §6 (ERR-280-03/04), Tests §8 / Plan §2.2, §6 Le plan exige la correlation requestId/proofId pour erreurs 500, mais ne formalise pas le meme minimum probatoire pour l'evenement de reclassification SLA (PENDING -> INDETERMINATE) mentionne dans le flux lazy. Risque de rupture d'auditabilite sur un mecanisme contractuel central (preuve temporelle incomplete). MAJEUR
Code Contract — Invariant Code contracts proof-verification-domain, proof-verification-migration / Spec §4 (INV-280-*) Les champs invariants des code contracts contiennent des elements non strictement issus des invariants spec (ex. CA-10, CA-11, DDL-02, DDL-03). Base normative des code contracts non univoque pour audit tiers sur "invariant". MAJEUR

3. Synthese

  • Nombre d'ecarts par gravite : BLOQUANT = 2, MAJEUR = 4, MINEUR = 0
  • Points critiques :
  • Non-conformite sur la materialisation/identite de verificationRequestId vis-a-vis de la transition contractuelle PENDING -> DONE.
  • Irrealisabilite des tests de non-retour terminal -> PENDING avec les seuls mecanismes explicitement planifies.

4. Verdict de la revue

  • Statut : ⛔ Rejete
  • Motif synthetique : Le plan ne demontre pas une conformite contractuelle complete sur l'identite de verification (verificationRequestId) et ne rend pas auditables/realisables certains controles non negociables de transition d'etat.