PD-298 — Plan d'implémentation¶

Projet cible : ProbatioVault-app (React Native + Expo SDK 54 + TypeScript) Backend consommé : ProbatioVault-backend via endpoints PD-287 (DONE) Dépendances natives validées PO : react-native-safe-area-context, @react-native-community/datetimepicker Traçabilité : spec PD-298-specification.md v2026-04-22, tests PD-298-tests.md, review step3 PD-298-review-step3.md.

1. Découpage en composants¶

La story est décomposée en 10 modules ; la liste correspond 1→1 aux entrées du fichier PD-298-code-contracts.yaml (un module = un agent step 6b).

1.1 i18n (transverse)¶

Toutes les chaînes sont introduites dans le bundle unique src/i18n/fr/sharing.json. Aucune chaîne literal n'est autorisée dans C07/C08/C09. Les clés sont typées via le générateur i18next existant.

1.2 Définitions de placeholders contractuels¶

Les textes normatifs absents (écarts bloquants review step 3 : A-01, A-04, A-05) sont injectés via clés i18n dédiées à valeurs placeholder ; la bascule vers le texte officiel se fait par simple update du bundle FR sans recompilation logique :

2. Flux techniques¶

F1 — Création d'un partage (F-298-01)¶

1. ProofDetailScreen passe proof.id, proof.owner_user_id au bouton « Partager ».
2. useOwnership(proofId) compare à auth.user.id ; si false, le CTA n'est jamais monté (INV-298-12).
3. Navigation vers ShareCreateScreen. useDrmWarning(userId) :
4. lit drmWarningSeen en AsyncStorage ;
5. si false, monte DrmWarningModal (contenu ARB-8) ; à l'acquittement, setDrmWarningSeen(true) ;
6. si true, rend le formulaire directement.
7. Formulaire ShareCreateForm :
8. email (validé via validateEmail) ;
9. ttlMinutes via TtlPicker (presets {15,60,1440,10080,43200} + custom datetimepicker, validation [15..43200]) ;
10. maxViews entier optionnel ≥1 ;
11. notificationsEnabled booléen ;
12. RgpdNotice monté au-dessus du CTA submit, visibilité vérifiée avant soumission par mesure measureInWindow > 0 (INV-298-06, ERR-298-10).
13. À la soumission :
14. validation locale ; si échec, aucun appel (INV-298-01, ERR-298-01, ERR-298-08).
15. génération idempotencyKey = uuidv4() ;
16. sharesApi.create({proofId, recipientEmail, ttlMinutes, maxViews?, notificationsEnabled}, {idempotencyKey}) ;
17. bouton submit disabled durant in-flight (anti double-tap, H-03) ;
18. validation Zod de la réponse 201 ; mapping vers ShareSummary ; invalidation queryClient.invalidateQueries(['proof-shares', proofId]).
19. Retour fiche preuve + toast succès + refresh liste locale via useProofShares.

F2 — Liste par preuve (F-298-02)¶

ProofShareListSection monte useProofShares(proofId) : - appelle GET /shares?proofId=... si endpoint PD-287 le supporte (HT-07) ; sinon filtre côté client à partir de GET /shares?offset=0&limit=20 paginé jusqu'à couverture (à défaut backend, documenté en §9). - pull-to-refresh re-exécute la query avec cacheTime: 0, staleTime: 0 → appel réseau frais garanti (INV-298-05).

F3 — Écran global « Mes partages » (F-298-03)¶

MyShareScreen : - Utilise useInfiniteQuery de @tanstack/react-query avec limit=20 fixe, getNextPageParam = pages.length * 20. - Tri serveur created_at desc (contract API) ; tri additionnel côté client si nécessaire pour stabilité. - Filtres d'état exposés via segmented control → passe state en query param si supporté, sinon filtre post-réponse et refetch. - cacheTime: 0 pour toutes les queries ['shares', ...] (INV-298-05).

F4 — Détail et révocation (F-298-04)¶

ShareDetailScreen(shareId) : 1. Validation UUID v4 au mount (rejet navigation si invalide, TC-NEG-01). 2. useShareDetail(shareId) → GET /shares/:id. À chaque focus écran, refetch forcé. 3. Matrice StateActions: | État | Révoquer | Voir journal | Partager à nouveau | Détails | |------|----------|-------------|--------------------|---------| | PENDING_ACTIVATION | ✅ | ✅ | ❌ | ✅ | | ACTIVE | ✅ | ✅ | ❌ | ✅ | | OTP_BLOCKED | ✅ | ✅ | ❌ | ✅ + message contextuel | | REVOKED | ❌ | ✅ | ❌ | ✅ lecture seule | | EXPIRED | ❌ | ✅ | ❌ | ✅ lecture seule | 4. Sur « Révoquer » : - monte RevokeConfirmModal avec sharing.arb7.revoke.body (i18n, HT-03) ; - confirmation explicite (bouton distinct du bouton de fermeture) ; - avant POST, re-fetch état courant (anti-race H-07) ; si état devenu terminal, abort + toast ; - sinon sharesApi.revoke(shareId, {idempotencyKey}).

F5 — Journal d'accès (F-298-05)¶

ShareEventsScreen(shareId) : 1. GET /shares/:id/events sans cache. 2. Mapping eventType backend → label i18n via EVENT_TYPE_LABELS (HT-04). Valeur inconnue → UNKNOWN_EVENT (tests TC-NEG-06). 3. Chaque ligne : eventAt (format ISO local via Intl.DateTimeFormat), eventType i18n, recipientEmail, maskIp(eventIpRaw), deviceType. 4. EmptyJournalMessage si events.length === 0 : le message distingue « jamais activé » / « pas d'événement récent » via l'état courant du share (PENDING/ACTIVE sans event, OTP_BLOCKED, REVOKED/EXPIRED sans event). 3 clés i18n dédiées (A-10).

2bis. Diagramme de dépendances agents¶

graph LR
    subgraph "Wave 1 — Fondations (parallèle)"
        A01[agent-types<br/>C01 sharing-types]
        A02[agent-i18n<br/>i18n bundle FR]
        A03[agent-masking<br/>C03 sharing-masking]
        A04[agent-drm<br/>C04 sharing-drm-prefs]
        A05[agent-validation<br/>C02 sharing-validation]
    end

    subgraph "Wave 2 — Infra métier (parallèle)"
        A06[agent-api<br/>C05 sharing-api-client]
        A07[agent-telemetry<br/>C10 sharing-telemetry]
    end

    subgraph "Wave 3 — Composition (parallèle)"
        A08[agent-hooks<br/>C06 sharing-hooks]
        A09[agent-components<br/>C07 sharing-components]
        A10[agent-guards<br/>C09 sharing-guards]
    end

    subgraph "Wave 4 — Intégration"
        A11[agent-screens<br/>C08 sharing-screens]
    end

    subgraph "Wave 5 — Qualité"
        A12[agent-tests<br/>tests UT + integration]
    end

    A01 --> A06
    A01 --> A05
    A01 --> A08
    A05 --> A08
    A03 --> A09
    A02 --> A09
    A04 --> A08
    A06 --> A08
    A06 --> A07
    A08 --> A11
    A09 --> A11
    A10 --> A11
    A11 --> A12
    A07 --> A11

Parallélisation : Wave 1 (5 agents en parallèle), Wave 2 (2 agents en parallèle après Wave 1), Wave 3 (3 agents en parallèle après Wave 2), Wave 4 (1 agent), Wave 5 (1 agent). Temps de chemin critique : 5 waves séquentielles.

2ter. Diagramme de séquence enrichi (révocation, manquant dans la spec — C-07)¶

sequenceDiagram
    participant U as Propriétaire
    participant SD as ShareDetailScreen
    participant H as useRevokeShare
    participant M as RevokeConfirmModal
    participant API as sharing-api-client
    participant BE as Backend PD-287

    U->>SD: tap "Révoquer"
    SD->>M: monter modale + i18n(arb7)
    U->>M: lire ARB-7, confirmer explicitement
    M->>H: onConfirm()
    H->>API: getShare(shareId) (re-check anti-race)
    API->>BE: GET /shares/:id
    BE-->>API: {state}
    alt état terminal (REVOKED/EXPIRED)
        H->>SD: toast "État déjà modifié"
        SD->>SD: refetch forcé
    else état actif
        H->>API: revoke(shareId, idempotencyKey)
        API->>BE: POST /shares/:id/revoke
        BE-->>API: 204 | 409
        alt succès
            API-->>H: ok
            H->>SD: refetch + toast succès
        else 409
            H->>SD: toast "État déjà modifié"
            SD->>SD: refetch forcé
        end
    end

3. Mapping invariants → mécanismes¶

4. Mapping critères d'acceptation → mécanismes¶

5. Mapping tests (TC-*) → mécanismes + observables¶

Couverture : 17 TC-NOM, 12 TC-ERR, 8 TC-NR, 8 TC-NEG = 45 tests. Aucune exclusion.

6. Gestion des erreurs¶

7. Impacts sécurité¶

8. Hypothèses techniques¶

8.1 Plan de levée des hypothèses avant Gate 8¶

9. Points de vigilance¶

10. Hors périmètre¶

• Portail destinataire, deep-linking destinataire (spec §2).
• Push notifications (spec §2) — seul notificationsEnabled est transmis au backend.
• Mode hors-ligne / queue offline (INV-298-17).
• Modification des endpoints backend PD-287.
• RGAA complet (MVP sur i18n + a11y minimale).
• Qualification juridique RGPD (H-298-08).
• Partage multi-preuves.

Mécanismes cross-module (OBLIGATOIRE)¶

La story modifie 1 module externe : ProofDetailScreen (module preuves).

Périmètre de test (OBLIGATOIRE)¶

Stubs inter-PD : aucun. Toutes les dépendances externes (PD-287 backend) sont DONE et consommées via API. Les placeholders textuels (HT-02, HT-03) ne sont pas des stubs de code mais des valeurs de bundle i18n à mettre à jour ; STUB: PD-287-arb7-content n'est donc pas un stub inter-PD mais une dépendance éditoriale tracée dans §8.

Couverture minimale attendue : 80 % lignes / 80 % branches sur src/sharing/** + src/screens/proofs/ProofDetailScreen.tsx (bloc sharing uniquement). Les placeholders et les UNKNOWN_* fallback sont couverts.

Code contracts similaires (réutilisation décisions)¶

{{SIMILAR_CONTRACTS}}