PD-253 — Rapport de confrontation (Étape 3)¶

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

1. Sources confrontées¶

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

2. Convergences¶

14 invariants alignés : Les 14 invariants (INV-253-01 à INV-253-14) sont référencés dans la matrice de couverture des tests avec au moins un test dédié chacun.
12 critères d'acceptation couverts : Les CA-253-01 à CA-253-12 sont tous associés à au moins un test dans la matrice.
Codes d'erreur cohérents : Les 11 codes d'erreur de la spec (400, 401, 403, 409, 413, 422, 500, 504, 410×2) sont repris dans les tests TC-ERR-01 à TC-ERR-12.
Machine à états : Les tests TC-NOM-09 et TC-NEG-06 vérifient exactement les transitions autorisées/interdites listées en section 5.4 de la spec.
Format BagIt et dual manifests : Les tests TC-NOM-04, TC-ERR-12 et TC-NEG-04 vérifient les contraintes de format (chemins relatifs, séparateur /, absence de .., double manifeste).
Fail-closed audit : TC-ERR-07 reprend exactement le comportement spec INV-253-10 (aucun export créé, aucun job planifié).
Quota concurrence : TC-ERR-04 et TC-NEG-05 couvrent le rejet 409 conformément à INV-253-07.
Soft-deleted / destroyed : TC-NOM-08 vérifie la double règle inclusion/exclusion avec trace destruction-log.json, conforme à INV-253-09.
Anchor pending : TC-NOM-07 vérifie la conservation du statut pending sans upgrade implicite, conforme à INV-253-08.
Niveaux probatoires standard/strong : TC-NOM-05 et TC-NOM-06 couvrent les deux niveaux, cohérent avec INV-253-06.
Atomicité sync/async : TC-NOM-10 couvre les scénarios crash pré/post-commit de la section 5.6.
Modèle de données : Les tests TC-NEG-01 à TC-NEG-03 valident les contraintes de format (case-sensitivity enum, regex UUID, regex hash 64 chars) documentées en section 5.1.

3. Divergences¶

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

DIV-01 : État FAILED_TIMEOUT absent de la machine à états
Spécification section 5.4 : les états listés sont REQUESTED, ASSEMBLING, READY_FOR_DOWNLOAD, DOWNLOADED, EXPIRED, FAILED, CANCELLED. FAILED_TIMEOUT n'apparaît pas.
Spécification section 5.2 : le paramètre export_job_timeout mentionne FAILED_TIMEOUT comme état résultant en cas de dépassement.
Tests TC-ERR-09 : vérifie un état final FAILED_TIMEOUT distinct de FAILED.
Impact : Contradiction interne à la spec. FAILED_TIMEOUT est-il un sous-état de FAILED ou un état distinct ? Si distinct, la machine à états section 5.4 est incomplète. Si sous-état, les tests TC-ERR-09 et la section 5.2 doivent être reformulés.
DIV-02 : Ambiguïté synchrone/asynchrone pour 422 PROOF_ENVELOPE_INCOMPLETE
Spécification section 6 : liste 422 PROOF_ENVELOPE_INCOMPLETE comme code d'erreur, sans préciser si retourné synchronement (à la création) ou détecté pendant l'assemblage async.
Tests TC-ERR-06 : indique « Rejet 422 PROOF_ENVELOPE_INCOMPLETE (ou FAILED selon point d'échec contractuel) ». Le test admet deux comportements possibles sans trancher.
Impact : Le comportement contractuel est indéterminé. L'implémentation pourrait choisir soit une vérification préalable (422 synchrone), soit une détection à l'assemblage (état FAILED), sans que le contrat ne l'impose.
DIV-03 : Confirmation de téléchargement — mécanisme non testé
Spécification section 5.5 étape 3 : « Passage DOWNLOADED à confirmation de téléchargement réussi. »
Tests : Aucun test ne couvre le mécanisme de confirmation ni la transition READY_FOR_DOWNLOAD → DOWNLOADED.
Impact : Le déclencheur de la transition vers DOWNLOADED est absent des tests. La couverture de la machine à états (CA-253-10) est incomplète sur cette transition nominale.
DIV-04 : Comportement si export.sig présent mais signature invalide
Spécification INV-253-06 : « L'absence de export.sig n'invalide pas la réversibilité (standard), sa présence qualifie un niveau strong. »
Tests TC-NOM-06 THEN : « Le package reste au minimum standard si verification strong indisponible. »
Impact : La spec ne contractualise pas le cas « signature présente mais invalide ». Le test introduit un fallback strong → standard non documenté dans la spécification. Ce comportement est-il souhaité ou la signature invalide doit-elle générer une erreur ?
DIV-05 : READY_FOR_DOWNLOAD bloquant le quota — granularité de test insuffisante
Spécification section 3 : définit « Export actif » comme REQUESTED ou ASSEMBLING ou READY_FOR_DOWNLOAD.
Tests TC-ERR-04 : le GIVEN mentionne les trois états possibles mais ne paramètre qu'un seul scénario.
Impact : Le cas spécifique READY_FOR_DOWNLOAD bloquant une nouvelle demande n'est pas testé isolément. Un bug de quota ne détectant pas cet état passerait inaperçu.

4. Zones d'ombre¶

ZO-01 : Pas de test nominal dédié aux scopes VAULT, PERIOD, SELECTION. TC-NOM-01 couvre uniquement GLOBAL. TC-NR-01 mentionne les 4 scopes comme non-régression mais sans scénario Given/When/Then détaillé. Les règles de filtrage par vault_id, par période (from/to), et par liste document_id[] ne sont pas testées individuellement.
ZO-02 : Schéma complet de destruction-log.json non défini. La spec mentionne destruction_act_hash (section 5.1) et l'exclusion des documents détruits (INV-253-09). Le test TC-NOM-08 vérifie la présence + hash valide. Mais le schéma complet du fichier (champs obligatoires, structure JSON, lien avec les actes de destruction PD-250) n'est contractualisé dans aucun des deux documents.
ZO-03 : Structure interne du package BagIt non détaillée. La spec mentionne BagIt RFC 8493 + extensions probatoires ProbatioVault. Les tests vérifient les manifests et la présence de ProofEnvelope. Mais l'arborescence interne du package (data/, bagit.txt, bag-info.txt, emplacement des metadata JSON par document) n'est pas contractualisée.
ZO-04 : Mécanisme d'estimation de taille pour le rejet 413. La spec mentionne 413 EXPORT_SIZE_LIMIT_EXCEEDED avec une limite max de 100 GB (section 5.2). Le test TC-ERR-05 vérifie le rejet. Mais le mode de calcul de l'estimation (pré-calcul avant assemblage ? somme des tailles documents ? overhead manifests inclus ?) n'est pas spécifié.
ZO-05 : Régénération d'URL signée après expiration. La spec section 6 mentionne 410 DOWNLOAD_URL_EXPIRED. Le test TC-ERR-10 vérifie le rejet. Mais aucun flux de régénération n'est documenté : l'utilisateur peut-il obtenir une nouvelle URL tant que le package est en READY_FOR_DOWNLOAD et non expiré ? Aucun endpoint de régénération n'est spécifié.
ZO-06 : Format export.sig non défini. PC-253-01 (point à clarifier) mentionne « signature du digest SHA3-256 du package final ». Mais l'algorithme HSM, le format de sortie (DER, PEM, raw), et le périmètre exact signé (digest de quel contenu ?) restent ouverts. TC-NOM-06 est marqué « Partielle » pour cette raison.
ZO-07 : Événements d'audit contractuels non listés. INV-253-10 impose le fail-closed audit. La section 8 « Observabilité » des tests mentionne « événement de création obligatoire, traces transitions d'état ». Mais la liste exhaustive des événements d'audit (création, chaque transition, téléchargement, expiration, purge, annulation) n'est contractualisée dans aucun document.
ZO-08 : Annulation d'export — flux et conditions non couverts. La machine à états autorise REQUESTED → CANCELLED et ASSEMBLING → CANCELLED. Mais aucun endpoint d'annulation, aucun critère d'autorisation d'annulation, et aucun test nominal ne couvrent ce flux. Seul TC-NOM-09 vérifie que la transition est techniquement acceptée.

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 : DIV-01 (état FAILED_TIMEOUT contradictoire avec la machine à états) est une incohérence interne factuelle à trancher. DIV-03 (transition DOWNLOADED non testée) et ZO-01 (3 scopes sur 4 sans test nominal) représentent des lacunes de couverture significatives. Les 5 divergences et 8 zones d'ombre identifiées justifient un rework ciblé avant soumission à la gate.