DiddiFood — Plan d’implémentation Phase 2 MVP
Date de démarrage : 2026-11-03
Périmètre
Cette phase traite les gaps MVP remontés par le frontend. La Phase 1 (préparation et recette Google Review) reste volontairement en attente.
Tâches
| Statut | Tâche | Responsable | Notes |
|---|---|---|---|
| Fait | Définir et documenter les statuts/erreurs de livraison côté client | Food | DeliveryOut expose failed, failure_code, failure_reason et failed_at; /delivery/refresh relit DiddiSend |
| Fait | Clarifier annulation client avant acceptation et commande déjà payée | Food + Pay | Intent non confirmé annulé ; paiement capturé → demande de remboursement durable |
| Fait | Vérifier le remboursement après refus restaurant | Food + Pay | Même orchestration ; Pay confirme le remboursement effectif |
| Fait | Documenter les routes et codes de remboursement | Food | Routes de demande/liste et statuts exposés dans OpenAPI ; contrat frontend couvert |
| Fait | Vérifier les erreurs de devis/retrait wallet | Food | Quote expirée/invalide, montant incohérent, bénéficiaire absent et conflit d’idempotence sont gérés |
| Fait côté Food / dépendance Send | Documenter le passage pending → available |
Food + Send | Send génère delivery.cash_remitted dans son outbox Redis, avec payload financier et clé stable ; Food le consomme idempotemment |
| Fait | Vérifier les notifications restaurant | Food + Comms | Nouvelle commande, acceptation, annulation/refus et événements associés utilisent NotificationService en best-effort |
| Fait | Ajouter les tests MVP manquants | Food | Couverture existante validée pour annulation/refus, livraison échouée, remboursement et rejeu |
Décisions retenues pour l’implémentation
- Une commande ne peut être annulée par le client que tant que le restaurant ne l’a pas acceptée.
- Un remboursement ne sera jamais marqué réussi localement sans confirmation du contrat DiddiPay.
- Une livraison échouée reste sous la décision Send/Support ; Food expose son état et ne fabrique pas une livraison réussie.
- Les notifications restent best-effort ; les routes HTTP restent la source d’état après reconnexion.
Journal
- 2026-11-03 — fichier créé ; Phase 2 ouverte.
- 2026-11-03 — catalogue MVP des erreurs ajouté ; validation route par route restante.
- 2026-11-03 — annulation client et refus restaurant reliés au contrat Payment : annulation d’intention ou création d’une demande de remboursement.
- 2026-11-03 — incidents de livraison vérifiés : Food expose la projection d’échec et le rafraîchissement ; aucune logique de retry/annulation ajoutée, car elle relève de DiddiSend/Support.
- 2026-11-03 — wallet vérifié : devis expiré/invalide et montant incohérent refusés ; retrait idempotent ; bénéficiaire manquant et conflit de clé exposés par codes métier.
- 2026-11-03 — notifications vérifiées : les notifications restaurant passent par
notify_user, avec WebSocket et FCM indépendants ; une panne de notification ne bloque pas la commande. - 2026-11-03 — tests MVP rejoués : livraison/status, contrats frontend, wallet, remboursements et notifications passent ; aucune extension de code nécessaire.
- 2026-11-03 — API DiddiSend vérifiée : la remise complète crée l’événement outbox
delivery.cash_remitted, clédiddisend:delivery:<id>:cash_remitted:v1, avecorder_reference, version/hash financier, montant restaurant et devise. Publication via stream Redis ; recette interservices encore nécessaire.