Aller au contenu

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

Ce rapport est produit par l'orchestrateur Claude avant la gate 3 PMO. Il confronte la spécification v3 et les tests v3 pour identifier convergences, divergences et zones d'ombre.

1. Sources confrontées

  • Spécification : PD-80-specification.md (v3) — étape 1
  • Tests : PD-80-tests.md (v3) — étape 2

2. Convergences

  • Machine d'états : les 7 états (RECEIVED, QUEUED_PRIORITY, TSA_PENDING, TSA_SEALED, ANCHOR_PENDING, SEALED, FAILED_TIMEOUT) et les transitions autorisées/interdites sont identiques dans les deux documents. TC-INV-01, TC-ERR-09, TC-ERR-10, TC-NOM-16, TC-NOM-17 couvrent exhaustivement §5.4.
  • SLA P95 < 60 min : fenêtre 24h glissante, N≥100, seuil INSUFFICIENT_DATA — concordance exacte entre §3/§5.2 (spec) et TC-NOM-03 (tests).
  • Timeout final ≥120 min : transition forcée FAILED_TIMEOUT + notification + escalade — concordance entre INV-80-04/§6 (spec) et TC-ERR-07 (tests).
  • Retries contractuels : délais [1, 5, 15, 30] min, même état, 4 retries max — concordance entre INV-80-06/§5.4 (spec) et TC-ERR-05/TC-ERR-06/TC-ERR-11 (tests).
  • Quotas et rate-limits : freemium 3/mois, premium 10/mois, enterprise 1000/mois, rate-limit standard 1/h, enterprise 10/h, mineur 2/h — concordance entre §5.2 (spec) et TC-ERR-02/TC-ERR-03/TC-ERR-12/TC-NEG-09/TC-NEG-10/TC-NEG-12 (tests).
  • Mini-batch prioritaire : bornes 1..20 éléments, flush ≤5 min, pas d'ancrage individuel — concordance entre INV-80-05 (spec) et TC-NOM-04 (tests).
  • Chiffrement at-rest : INV-80-09 (spec) et TC-NOM-09/TC-INV-09 (tests) convergent sur l'absence de secret en clair en base.
  • Worker réconciliation : critères de détection orphelin, lock distribué Redis, flag reconciled, seuil 30 min — concordance entre §5.10 (spec) et TC-NOM-11/TC-NOM-18 (tests).
  • Webhook policy : événements proof_sealed/proof_failed, retry [1, 5, 15] min, 3 retries max, webhook_delivery_failed — concordance entre §5.11 (spec) et TC-NOM-06/TC-NOM-12/TC-NOM-14 (tests).
  • Fallback push : email comme fallback primaire, log INFO, pas d'erreur push — concordance entre §5.12 (spec) et TC-NOM-13 (tests).
  • Anti-disclosure : corps 403/429 ne contient ni nom de plan ni quota restant — concordance entre §6 (spec) et TC-NEG-11 (tests).
  • Clamp logging : log WARN par paramètre clampé — concordance entre §5.2 (spec) et TC-NOM-15 (tests).
  • Non-starvation : seuil ≥16.7% du débit total sur fenêtre 10 min — concordance entre INV-80-11 (spec) et TC-NOM-08 (tests).
  • Atomicité multi-composant : ACID synchrone, async idempotent, rattrapage post-crash — concordance entre §5.7 (spec) et TC-NOM-10 (tests).
  • Transitions retour : TSA_PENDING→QUEUED_PRIORITY et TSA_SEALED→TSA_PENDING avec audit motif — concordance entre §5.4 (spec) et TC-NOM-16/TC-NOM-17 (tests).
  • Formats de données : regex UUID v4, hash SHA-256 lowercase 64 chars, enums — concordance entre §5.1 (spec) et TC-ERR-01/TC-NEG-01/TC-NEG-02 (tests).

3. Divergences

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

  • DIV-01 : Cycle de vie DEK (§5.14) non testé
  • Spec (§5.14) : définit un cycle de vie complet de la DEK — génération via crypto.randomBytes(32), wrapping HSM immédiat, IV unique par opération, destruction synchrone à la transition terminale. Invariant explicite : "aucune DEK en clair n'est persistée en base, en log, ou sur disque".
  • Tests : TC-NOM-09/TC-INV-09 testent l'absence de secret en clair en base (INV-80-09), mais aucun test ne vérifie spécifiquement (a) la génération d'une DEK unique par scellement, (b) le wrapping HSM immédiat, © la destruction synchrone dans la transaction terminale, (d) l'unicité de l'IV par opération.

  • Impact : le cycle de vie DEK est contractualisé dans la spec mais pas couvert au-delà du test statique d'absence de clair. Un bug sur la destruction ou le wrapping ne serait pas détecté.

  • DIV-02 : Synchronisation NTP (§5.13) non testée

  • Spec (§5.13) : synchronisation NTP obligatoire, tolérance ±1s, alerte CRITICAL au démarrage si non respectée.
  • Tests (§8 observabilité) : mentionnent "NTP ±1s" dans l'observabilité et "CRITICAL pour dérive NTP >1s" dans les logs démarrage, mais aucun TC ne vérifie explicitement la détection de dérive NTP ni l'alerte CRITICAL au démarrage.

  • Impact : la détection de dérive NTP pourrait être absente sans que les tests ne le signalent.

  • DIV-03 : Erreur 422 — formulation ambiguë dans le test

  • Spec (§6) : "réponse de dépendance externe invalide (token TSA non parseable reçu du TSA, Merkle proof invalide retourné par le worker Merkle, tx hash invalide retourné par le service blockchain). Ces erreurs sont internes au pipeline et déclenchent un retry, pas un rejet API vers l'utilisateur."
  • Tests (TC-ERR-04) : teste correctement les 3 sous-cas (a, b, c) et vérifie le retry + journalisation. Mais le THEN stipule "L'artefact invalide est rejeté" — le terme "rejeté" peut créer une ambiguïté avec la spec qui dit explicitement "pas un rejet API vers l'utilisateur".

  • Impact : mineur — le test est fonctionnellement correct, mais la formulation pourrait induire un développeur en erreur sur la nature du rejet (interne pipeline vs API).

  • DIV-04 : Épuisement retries — contenu de l'événement retries_exhausted non vérifié

  • Spec (§5.4, point 3) : l'événement retries_exhausted doit inclure seal_id, état courant, nombre de tentatives.
  • Tests (TC-ERR-11) : vérifie qu'un événement retries_exhausted est journalisé mais ne précise pas la vérification du contenu (seal_id, état, nombre de tentatives).
  • Impact : mineur — le contenu de l'événement pourrait ne pas être conforme au contrat sans être détecté.

4. Zones d'ombre

  • ZO-01 : Schéma du proof package — identifié comme "majeur" dans le verdict QA des tests (§9) et comme point à clarifier (§10.2.4 spec). Aucun des deux documents ne définit le format canonique du proof package. Les tests TC-NOM-05/TC-NOM-06 vérifient des champs individuels (hash, tx blockchain, etc.) mais pas un schéma de package structuré.

  • ZO-02 : Escalade opérationnelle — identifié comme "majeur" dans le verdict QA des tests (§9) et comme point à clarifier (§10.2.5 spec). Les destinataires, le délai d'acquittement et la criticité de l'escalade ne sont définis dans aucun document. TC-ERR-07 vérifie qu'un "événement d'escalade opérationnelle" est tracé, mais le contenu de cet événement n'est pas contractualisé.

  • ZO-03 : Confirmation repo cible — §10.2.8 (spec) pose la question "backend uniquement ou backend + app pour API de déclenchement manuel". Aucune réponse dans les tests. Le périmètre d'implémentation reste ambigu pour le plan.

  • ZO-04 : Politique de rétention des artefacts FAILED_TIMEOUT — §10.2.6 (spec) identifie ce point comme donnée manquante. Aucun test ne couvre la conservation ou la purge des artefacts d'échec.

  • ZO-05 : SLO pour priority_queue_depth — §10.2.7 (spec) note l'absence de seuils d'alerte pour la profondeur de queue prioritaire. TC-NOM-07 vérifie l'existence de la métrique mais pas de seuil d'alerte.

  • ZO-06 : Politique paiement freemium hors Stripe — §10.2.2 (spec) demande clarification sur le comportement en absence de paiement confirmé. Non couvert par les tests.

  • ZO-07 : Référence épique manquante — la spec indique "Référence épique non fournie". Les tests référencent "EPIC-XX" (placeholder). L'épique parent n'est documenté dans aucun des deux documents.

5. Recommandation

  • Procéder — convergence confirmée, aucun conflit bloquant

Justification : les 11 invariants sont couverts par au moins un test dédié. Les 18 critères d'acceptation sont tous mappés dans la matrice de couverture. Les 4 divergences identifiées sont de gravité mineure à modérée (tests existants mais incomplètement granulaires). Les zones d'ombre sont identifiées comme données PO manquantes (proof package, escalade, rétention) — elles n'invalident pas la conformité spec↔tests mais devront être résolues avant le plan (étape 4).