PD-286 — Export multi-volumes pour dossiers > 1 GB¶

1. Contexte¶

Un dossier probatoire peut contenir plusieurs vidéos de 500 MB. Avec le hard limit actuel de 1 GB (MAX_BACKEND_EXPORT_BYTES = 1_073_741_824 dans export.constants.ts), un dossier de 2 vidéos + screenshots est inexportable : le backend renvoie 413 et l'app propose de réduire la sélection. C'est inacceptable — on ne peut pas demander à un utilisateur de retirer des preuves d'un dossier de plainte.

Détecté par la pipeline de cohérence inter-EB (Phase 2, décision D4) lors de l'analyse du conflit storage.export_max_bytes entre PD-283 (500 MB) et PD-85 (100 MB).

2. Besoin¶

En tant qu' utilisateur ProbatioVault, je veux que l'export de mon dossier probatoire fonctionne quelle que soit la taille totale, afin de pouvoir déposer un dossier complet (plainte, partage, archivage) sans être limité par une contrainte technique invisible.

3. Périmètre fonctionnel¶

3.1 Ce qui est inclus¶

3.2 Ce qui est exclu¶

• Pas de configuration utilisateur ou admin du seuil de split (contrainte technique hardcodée)
• Pas de changement sur le format .pvproof final (le résultat reste un seul fichier)
• Pas de changement sur les guards (OidcJwtAuthGuard, PremiumGuard) ni le rate limiting
• Pas de modification de la pipeline de validation des preuves (ProofValidatorPipeline)

4. Seuil de volume¶

Le seuil par volume est fixé à 768 MB (VOLUME_MAX_BYTES = 805_306_368).

Justification : - Hard limit backend actuel : 1 GB (1_073_741_824 bytes) - 768 MB laisse ~25% de marge pour le manifest, les métadonnées JSON, la chronologie et les overhead ZIP par volume - Suffisamment grand pour minimiser le nombre de volumes dans les cas courants (2 vidéos de 500 MB = 2 volumes seulement) - Compatible avec la recommandation mobile de 500 MB (MAX_MOBILE_EXPORT dans la description PD-286) : chaque volume reste sous le seuil mobile de 1 GB

La constante est définie dans export.constants.ts comme variable globale, figée au build.

5. Architecture de la solution¶

5.1 Backend — Split du manifest¶

ExportService.execute()
  ├── Steps 1-4 : inchangés (ownership, load, validate, size check)
  ├── Step 5 : SIZE CHECK MODIFIÉ
  │   ├── totalSize <= VOLUME_MAX_BYTES → single volume (comportement actuel)
  │   └── totalSize > VOLUME_MAX_BYTES → multi-volume split
  │       ├── Partitionner validProofs en N groupes (bin-packing par taille)
  │       ├── Chaque groupe <= VOLUME_MAX_BYTES
  │       └── Générer manifest + signed URLs par volume
  ├── Steps 6-9 : adaptés pour N volumes
  └── Step 10 : réponse avec volumes[]

5.2 App — Assemblage transparent¶

ExportOrchestrator.execute()
  ├── Appel API backend → response
  ├── IF response.volumes.length === 1
  │   └── Flux actuel inchangé
  ├── IF response.volumes.length > 1
  │   ├── Pour chaque volume (séquentiel) :
  │   │   ├── Télécharger les fichiers (signed URLs du volume)
  │   │   ├── Vérifier intégrité (hash partiel)
  │   │   └── Ajouter les entrées au PvproofAssembler
  │   ├── Générer pvproof.json avec metadata multi-volumes
  │   └── Finaliser le .pvproof unique
  └── Notification + cleanup

5.3 Contrat API (évolution ComplaintFileResponseDto)¶

// Nouveau : réponse multi-volumes
interface ComplaintFileResponseDto {
  exportId: string;
  // Champs existants conservés pour rétrocompatibilité (volume unique)
  manifest?: ExportManifest;
  chronology?: Chronology;
  signedUrls?: SignedUrlDto[];
  // Nouveau : tableau de volumes (présent si multi-volumes)
  volumes?: ExportVolumeDto[];
  // Communs
  guideUrl: string;
  readmeVerification: string;
  rejectedProofs: RejectedProofDto[];
  minorEvidence?: MinorEvidenceDto;
}

interface ExportVolumeDto {
  volumeIndex: number;       // 0-based
  totalVolumes: number;
  signedUrls: SignedUrlDto[];
  manifest: ExportManifest;  // manifest partiel de ce volume
  estimatedBytes: number;
  integrityHash: string;     // SHA3-256 du manifest partiel
}

6. Invariants¶

7. Critères d'acceptation¶

8. Risques et mitigations¶

9. Arbitrages et décisions¶

10. Stories liées¶

11. Learnings injectés¶