Aller au contenu

PD-280 — 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 fonctionnelle et contractuelle : PD-280 — Alignement canonique de l'etat PENDING... (origine workflow : Étape 1 — Specification)
  • Scénarios de tests contractuels : PD-280 — Scénarios de tests contractuels (origine workflow : Étape 2 — Tests & Validation)

2. Convergences

  • Les deux documents convergent sur le domaine à 4 états de CheckResult : OK | KO | INDETERMINATE | PENDING (Spec INV-280-01, CA-01 ; Tests TC-NOM-08).
  • Convergence sur la cohérence globale job/résultats : verificationStatus=PENDING en présence de maillon en cours, DONE quand tous les maillons sont résolus (Spec INV-280-02/CA-04 ; Tests TC-NOM-01, TC-NOM-02, TC-ERR-03).
  • Convergence sur la règle champs pending conditionnels : pendingReason et nextCheckAfterSeconds seulement en PENDING (Spec INV-280-03/CA-05 ; Tests TC-NOM-01, TC-NOM-02, TC-ERR-04).
  • Convergence sur l’invariant de finalisation : si proof_finalized=TRUE, aucun maillon PENDING/null (Spec INV-280-04/CA-07 ; Tests TC-NOM-06).
  • Convergence sur les transitions monotones : maillon PENDING -> {OK|KO|INDETERMINATE} uniquement, job DONE->PENDING interdit dans un cycle (Spec INV-280-05/06 ; Tests TC-NOM-03, TC-NOM-05, TC-INV-06, TC-NEG-06/07).
  • Convergence sur l’alignement formel TLA+ (RealStates = CheckResults) et blocage CI en cas d’écart (Spec INV-280-07, ERR-280-06 ; Tests TC-NOM-07, TC-ERR-06).
  • Convergence sur les erreurs API principales (INVALID_PROOF_ID, PROOF_NOT_FOUND, VERIFICATION_CONTRACT_BROKEN) et leurs statuts HTTP (Spec §6 ; Tests TC-ERR-01/02/03/04).

3. Divergences

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

  • DIV-01 : Traçabilité incohérente entre INV-280-08 et CA-08 dans la matrice de tests.
  • Source A (Spécification) : INV-280-08-envelope-encryption traite du chiffrement at-rest ; CA-08 traite de non-régression de la vérification existante.
  • Source B (Tests) : la matrice associe INV-280-08 à CA-08 et TC-INV-08 (chiffrement), alors que CA-08 ne porte pas sur le chiffrement.

  • Impact : rupture de traçabilité invariant/critère/test ; ambiguïté sur ce qui est réellement validé en gate.

  • DIV-02 : Comportement attendu pour nextCheckAfterSeconds hors bornes non strictement aligné.

  • Source A (Spécification) : clamp contractuel [1..86400] + “hors borne interdite en sortie”, avec rejet 500 si sortie hors bornes.
  • Source B (Tests) : TC-NEG-05 accepte “500 ou clamp contractuel (selon règle explicite du flux testé)”.

  • Impact : oracle de test non déterministe ; risque de verdict QA variable selon implémentation.

  • DIV-03 : Exposition API de l’état “en cours” (null vs PENDING) non alignée de façon stricte.

  • Source A (Spécification) : API publique expose null pour “en cours” (5.1), tout en listant PENDING comme valeur possible de linkResults[*] dans le domaine.
  • Source B (Tests) : couverture explicite de null en nominal, rejet de PENDING seulement en cas DONE (TC-NEG-04), sans interdiction explicite de PENDING en payload public quand status=PENDING.

  • Impact : contrat de sortie potentiellement interprétable de deux façons ; risque de divergence d’implémentation et de validation.

  • DIV-04 : Référence Epic non alignée entre documents.

  • Source A (Spécification) : Epic “NON FOURNIE”.
  • Source B (Tests) : Epic “EPIC-XX” (valeur de travail).
  • Impact : traçabilité gouvernance/Jira incomplète ; fragilise l’audit formel de la gate.

4. Zones d'ombre

  • Politique officielle de versionnement API pour ajout d’une valeur enum (PENDING) non contractualisée de bout en bout.
  • Comportement requis des clients legacy face à PENDING non défini (tolérance, fallback, compatibilité stricte).
  • Taxonomie de pendingReason : périmètre actuel donné, mais statut exhaustif vs extensible non tranché.
  • Autorité/circuit de validation de CA-09 (diff RFC PV-PROOF) non défini (rôle signataire, règle d’approbation).
  • Validation opérationnelle complète de l’invariant sécurité INV-280-08 dépendante de prérequis infra (HSM/KMS/stockage) non fournis.
  • Stratégie de down migration en présence de données PENDING mentionnée mais sans décision opérationnelle finale.

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