Aller au contenu

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

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

1. Sources confrontées

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

2. Convergences

  • Invariants : Les 13 invariants (INV-283-01 à INV-283-13-envelope-encryption) sont repris intégralement dans la matrice de couverture des tests. Chaque invariant a un test dédié TC-INV-XX avec observable cohérent.
  • Critères d'acceptation : Les 16 CA (CA-01 à CA-16) sont tous couverts par au moins un test dans la matrice. Aucun CA orphelin.
  • Machine à états : La table de transitions (§5.5 spec) est reprise dans TC-INV-12 et TC-NOM-05. Les transitions interdites sont testées négativement (TC-NEG-07).
  • Retry réseau : Convergence exacte sur 3 tentatives max, backoff 1s/2s/4s (spec INV-283-06, tests TC-INV-06 et TC-ERR-04).
  • Passthrough strict : Convergence entre INV-283-07 (spec) et TC-INV-07 (comparaison binaire source vs archive).
  • Sanitization zip-slip : Convergence entre INV-283-10 (spec), CA-14 et TC-INV-10 + TC-NEG-02/03/04.
  • Formats de données : La table §3.3 (spec) est exercée dans TC-ERR-08 (exportId hors regex), TC-ERR-09 (signedUrl non-https), TC-NEG-01 (proofId non UUID), TC-NEG-05 (integrityHash invalide).
  • Bornes performance : Les SLA P95 <30s (12 preuves/50MB) et P95 <60s (50 preuves/200MB) sont identiques entre spec (§3.4) et tests (TC-NR-05/06).
  • Pic mémoire : <50MB convergent entre spec (§3.4) et tests (TC-NR-07, TC-INV-02).
  • Cas d'erreur : Les 9 cas ERR-01 à ERR-09 (spec) sont couverts par des tests, bien que le mapping ne soit pas 1:1 (cf. DIV-02).
  • Scénarios de test spec vs tests : Les 8 scénarios ST-01 à ST-08 (spec §8) sont fidèlement repris et détaillés dans les tests (TC-NOM-01 à TC-NOM-06, TC-ERR-XX, TC-INV-XX).
  • Notification 24h : Convergence exacte sur T0+24h ±5min (INV-283-04, CA-12, TC-INV-04).
  • Règles non testables : Les 5 points identifiés dans les tests (§9) recoupent exactement les 6 "Points à clarifier" de la spec (§10), avec priorisation cohérente.

3. Divergences

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

  • DIV-01 : Écart sur la couverture du cas ERR-09 (nom non sanitizable)
  • Source A (Spécification §6, ERR-09) : "Fichier rejeté avec motif ; si critique, abort export."
  • Source B (Tests) : Aucun test dédié portant explicitement sur ERR-09. Le test TC-ERR-09 existant couvre le schéma non-https (cas §3.3 signedUrl), pas le nom non sanitizable. Les tests TC-NEG-02/03 couvrent la sanitization mais pas le cas "abort si critique".

  • Impact : Le comportement "si critique, abort export" du ERR-09 spec n'a pas de test dédié. La frontière entre "rejet fichier" et "abort export" n'est pas testée.

  • DIV-02 : Numérotation tests TC-ERR vs cas d'erreur spec non alignée

  • Source A (Spécification) : ERR-01 à ERR-09, numérotation séquentielle.
  • Source B (Tests) : TC-ERR-01 à TC-ERR-09, mais TC-ERR-02 couvre ERR-03 (URL expirée, pas ERR-02 "422 toutes rejetées"), TC-ERR-09 couvre un cas §3.3 (signedUrl non-https) et non ERR-09. Le mapping n'est pas 1:1.

  • Impact : Risque de confusion lors de la traçabilité. Un auditeur cherchant "TC-ERR-02 couvre ERR-02" trouvera une couverture sur ERR-03 à la place. ERR-02 (422 rejet total) est couvert par TC-NOM-03 et non par un TC-ERR dédié.

  • DIV-03 : Flux F-03 (URL expirée) — divergence sur le scope du refresh

  • Source A (Spécification §5.3) : "Nouvel appel API pour rafraîchir URLs" — suggère un appel complet POST /exports/complaint-file.
  • Source B (Tests, TC-NOM-04) : "Une nouvelle requête de refresh est émise automatiquement" — ne précise pas si c'est le même endpoint ou un endpoint dédié de refresh.

  • Impact : Mineur en Gate 3, mais l'ambiguïté pourra créer un écart d'implémentation au step 6.

  • DIV-04 : Transition READY -> DELETED puis retour IDLE — sémantique contradictoire

  • Source A (Spécification §5.5, table) : DELETED est un état terminal ("→ * : INTERDITE, résolution manuelle uniquement", toutes sorties interdites).
  • Source A (Spécification §5.5, règles retour) : "READY -> DELETED : suppression irréversible du fichier local ; retour implicite IDLE."
  • Source B (Tests, TC-NOM-06) : "Transition READY -> DELETED validée, puis retour implicite IDLE."

  • Impact : Contradiction interne à la spec reprise sans correction dans les tests. Si DELETED est terminal (toutes sorties interdites), le "retour implicite IDLE" est une transition DELETED -> IDLE qui viole la table. Les tests reproduisent cette contradiction sans la signaler.

  • DIV-05 : Scénario ST-08 (notification 24h) — décalage planification vs délivrance

  • Source A (Spécification §8, ST-08) : "Then une notification locale de rappel est délivrée."
  • Source B (Tests, TC-INV-04) : Observable = "Planification exacte 24h, tolérance ±5 min" (scheduler).

  • Impact : Mineur — la planification est le seul aspect testable unitairement. Mais la spec parle de délivrance, le test vérifie la planification. Écart sémantique.

  • DIV-06 : Borne taille export 500-1024 MB — warning non testé

  • Source A (Spécification §3.4) : ">1024 MB : refus export ; 500..1024 MB : warning."
  • Source B (Tests, TC-NEG-06) : ".pvproof > 1024MB → Refus export" uniquement. Aucun test pour le warning 500-1024 MB.

  • Impact : Le comportement "warning" entre 500 et 1024 MB n'est pas couvert. La nature du warning (bloquant ? informatif ? confirmation ?) n'est pas testée.

  • DIV-07 : Référence epic incohérente

  • Source A (Spécification §Références) : "Référence épique non fournie (à renseigner)."
  • Source B (Tests §1) : "Epic : EPIC-XX" (placeholder).
  • Impact : Cosmétique mais traçabilité incomplète. À corriger avant clôture.

4. Zones d'ombre

  • ZO-01 : Schéma exact manifest.json / chronology.json — Cité comme point à clarifier dans les deux documents (spec §10.1, tests §9). Sans schéma JSON formel, la validation "JSON valide" (spec §3.3) est insuffisante pour garantir l'intégrité structurelle. Aucun test ne valide la structure interne de ces payloads.

  • ZO-02 : Règle de dérivation exportId-8 — Le suffixe du nom final utilise 8 caractères de exportId, mais la règle exacte (troncature, base62, hash) n'est pas spécifiée. Identifié dans les deux documents comme non testable.

  • ZO-03 : Politique de collision de noms après sanitization — La spec mentionne "suffixe collision" (§3.3), les tests vérifient que "deux entrées distinctes sont présentes" (TC-NEG-04), mais le format du suffixe (incrémental _1, _2 ? UUID ?) n'est contractualisé nulle part.

  • ZO-04 : Fallback si permissions notification refusées — Identifié dans les deux documents. Aucun test ne couvre ce cas. L'hypothèse H-04 (spec) et la règle non testable correspondante (tests) convergent sur le problème sans solution.

  • ZO-05 : Borne max du nombre de preuves sélectionnables — Spec §10.5 : "non contractualisée dans le besoin". Les tests de performance couvrent 12 et 50 preuves mais aucune borne supérieure n'est définie.

  • ZO-06 : Annulation utilisateur en cours d'export — La machine à états autorise le retour vers IDLE depuis PREPARING, DOWNLOADING, DECRYPTING, ASSEMBLING. Mais aucun scénario de test ne couvre explicitement l'annulation en cours de flux. Les conséquences sur les temporaires et l'état ne sont pas testées.

  • ZO-07 : Comportement HASHING interrompu — La machine à états n'autorise PAS le retour HASHING -> IDLE. Si le hash final échoue, seule la transition HASHING -> FAILED est disponible. Aucun test ne couvre ce cas.

  • ZO-08 : Guide plainte (guide_plainte_france.pdf) — Mentionné dans F-01 étape 5 comme artefact racine à inclure dans l'archive, mais aucun test ne vérifie sa présence, sa provenance (guideUrl de la réponse API), ni son intégrité.

  • ZO-09 : readmeVerification → README_VERIFICATION.txt — La spec mentionne la transformation du champ texte readmeVerification en fichier README_VERIFICATION.txt dans l'archive. Aucun test ne vérifie cette transformation ni le contenu/encodage du fichier résultant.

  • ZO-10 : Validation proofId côté app — contenu du message — TC-NEG-01 vérifie le "blocage côté app avant appel API" pour un proofId non UUID v4, mais ne spécifie pas le contenu du message utilisateur (spec §3.3 : "blocage avant appel + message").

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

Justification :

  1. DIV-04 est bloquant : La contradiction DELETED terminal vs "retour implicite IDLE" doit être tranchée dans la spec. Soit DELETED n'est pas terminal (et la table §5.5 doit être corrigée), soit le "retour implicite IDLE" est une réinitialisation de cycle (et la sémantique doit être clarifiée). Les tests ne peuvent pas valider deux comportements contradictoires.

  2. DIV-01 + DIV-06 nécessitent des tests complémentaires (ERR-09 cas "abort si critique", warning 500-1024 MB).

  3. ZO-06 (annulation en cours d'export) est un flux utilisateur probable qui n'a aucune couverture de test malgré 4 transitions d'annulation dans la machine à états.

  4. ZO-08 + ZO-09 : Deux artefacts de l'archive (guide_plainte_france.pdf, README_VERIFICATION.txt) n'ont aucun test de présence/intégrité, alors qu'ils sont partie intégrante du RFC PV-PACK-001.

Les autres divergences et zones d'ombre sont mineures et peuvent être adressées en rework spec/tests sans escalade.