PD-16 — Acceptabilité¶
📚 Navigation User Story
| Document | | | ---------- | -- | | 📋 [Spécification](PD-16-specification.md) | | | 🛠️ [Plan d'implémentation](PD-16-plan.md) | | | ✅ **Critères d'acceptation** | *(ce document)* | | 📝 [Retour d'expérience](PD-16-rex.md) | | [← Retour à backend-core](../PD-186-epic.md) · [↑ Index User Story](index.md)Objectif¶
Vérifier que l’implémentation est conforme à la spécification, respecte l’ensemble des invariants ProbatioVault et ne présente aucune incohérence ou oubli critique.
Périmètre de vérification¶
La revue d’acceptabilité vérifie explicitement :
- la conformité stricte à la spécification fonctionnelle
- le respect de tous les invariants applicables
- la couverture des scénarios de test définis
- l’absence d’incohérences, oublis ou régressions
Écarts identifiés¶
Chaque écart constaté doit être documenté et classé selon sa gravité.
Classification des écarts¶
| Niveau | Définition |
|---|---|
| BLOQUANT | Violation d’un invariant, faille de sécurité, non-conformité majeure à la spec |
| MAJEUR | Fonction incomplète, comportement non conforme mais sans rupture de sécurité |
| MINEUR | Détail, dette acceptable, amélioration non critique |
Détail des écarts¶
| ID | Description | Référence | Gravité |
|---|---|---|---|
| E-01 | Suppression EXPIRED finalement interdite : la migration de normalisation (1733500700000-NormalizeDocumentStatusPolicy.ts) réécrit la policy DELETE en supprimant le cas EXPIRED introduit juste avant, alors que la spec/AC6 exigent la suppression autorisée après rétention. | Spec §RLS/Policies DELETE + AC6 ; src/database/migrations/1733500700000-NormalizeDocumentStatusPolicy.ts | MAJEUR |
| E-02 | Jobs lifecycle sans contexte RLS/role technique : les batchs (sealing/purge/expiration) s’appuient sur Repository/QueryBuilder sans SET LOCAL app.current_user_id ni rôle BYPASS RLS. Avec les policies actuelles (SELECT filtré sur current_user_id), les listes candidates sont vides, donc TA-2/TA-4 (transitions PENDING→SEALED→EXPIRED) ne sont pas réalisables. | Spec §Architecture RLS v2 + TA-2/TA-4 ; document-sealing.service.ts, document-purge.service.ts, document-scheduler.service.ts | MAJEUR |
| E-03 | Validation API incomplète : aucun contrôle ovh_path dans le DTO (format {user_id}/{document_id}/{version}.enc), seule la contrainte DB remonte une erreur tardive. | Spec §Validation API + AC5 ; create-document-secure-request.dto.ts, 1733500100000-AddOvhPathCheckConstraint.ts | MINEUR |
Conclusion d’acceptabilité¶
⚠️ ACCEPTÉ AVEC RÉSERVES — écarts MAJEURS/MINEUR documentés (E-01 à E-03).