Les deux happy paths couvrent les sens Yaoundé→Paris (Sc 1) et Paris→Yaoundé (Sc 2). Ils sont identiques en machine à états et en effets de bord, seules les coordonnées GPS et la devise diffèrent.Documentation Index
Fetch the complete documentation index at: https://docs.colismove.com/llms.txt
Use this file to discover all available pages before exploring further.
Sc 1 — Yaoundé → Paris
États traversés
Séquence détaillée
Acteurs et rôles
| Acteur | Rôle | Identification |
|---|---|---|
| Sender | Crée la réservation, paie, dépose le colis | Compte particulier KYC OK |
| Carrier | Annonce le trajet, transporte le colis | Compte verified user + Stripe Connect actif |
| Recipient | Reçoit le colis, scanne QR livraison | Pas de compte requis (page publique) |
| Backend | Orchestrateur, machine à états | Spring Boot 3.4 hexagonal |
| Stripe | Escrow + payout | Stripe Connect platform |
| PackSentry | Validation photos AVANT_DEPOT/DEPOT | Module hex colismove-packsentry |
Pré-requis carrier
- ✅ Compte vérifié (
ROLE_VERIFIED_USERvia Didit V2 ou Stripe Identity selon Pivot Flynanga) - ✅ Stripe Connect onboarding complet (
charges_enabled = true) - ✅ Pays supporté (whitelist
colismove-finances) - ✅ Trajet annoncé non expiré
Tests E2E
BookingFullJourneyIT— couverture intégration full path- Module :
colismove-app/src/test/java/.../scenarios/
Sc 2 — Paris → Yaoundé (sens inverse)
Identique à Sc 1 en logique métier. Différences :- Coordonnées GPS inversées (origine Paris, destination Yaoundé)
- Devise unique (EUR) — pas de conversion (carrier facture en EUR, sender paie en EUR)
- Pays expéditeur ≠ pays destinataire ne change rien (pas de logique douanière dans MVP ColisMove)
BookingFullJourneyIT avec les coordonnées inversées.
Effets de bord à chaque transition
| État cible | Effets backend | Notifications |
|---|---|---|
RESERVATION_PAYEE | Lock fonds Stripe, log PaymentLog | — |
EN_ATTENTE | Auto post-RESERVATION_PAYEE | Push carrier “nouvelle résa” |
ACCEPTEE | Génère QR dépôt (QrCodeService.generateDepot) | Push sender “QR prêt” |
EN_COURS_DE_LIVRAISON | Gate photos confirmerDepot (PackSentry), GPS tracking start | Push sender “Colis pris en charge” |
LIVREE | Stripe.transfers.create() 85% au carrier, WalletTransaction enregistrée | Push + email + WhatsApp recipient |
Variantes Sc 1
Si l’un des éléments suivants se produit, le scénario bascule :- Carrier refuse → Sc 4 (REFUSEE)
- Sender annule pré-dépôt → Sc 3 (ANNULEE refund)
- Sender annule post-dépôt → Sc 5 (forcé LITIGE)
- Stripe refuse 3DS → Sc 9 (ERREUR_PAIEMENT)
- Recipient absent → Sc 17 (3 tentatives max)
- Photo AVANT_DEPOT manquante → Sc 21 (HTTP 422)
- Photo DEPOT manquante au scan QR → Sc 22 (HTTP 422
PHOTO_DEPOT_MANQUANTE)