DiddiFood — décisions à prendre avant le gel du code du 18 novembre 2026

Résolutions validées le 27 octobre 2026

Les décisions suivantes remplacent les questions historiques encore visibles plus bas dans ce document :

Courriel paiement : ne pas le rendre obligatoire à la commande. Le champ de préparation online est optionnel; Food utilise le téléphone du payeur authentifié et transmet une valeur technique <digits>@diddifree.com si aucun e-mail fiable n'est disponible.
Non-réponse restaurant : respond_by est fixé à cinq minutes par défaut; Food annule automatiquement une commande placed échue avec restaurant_unresponsive.
Suivi et échec de livraison : DiddiSend reste la source de vérité et décide de la suite. Food expose uniquement une projection client et ne décide pas de nouvelle tentative, d'annulation ou de remboursement.
Remboursement : tout remboursement approuvé passe par DiddiPay, y compris une commande initialement cash. Aucun règlement cash manuel dans Food.
Images, idempotence plat et lecture de note : inclus dans le MVP du lot du 27 octobre 2026.
Filtres avancés, rayon géographique et ventilation détaillée par commande : V1, pas un blocage MVP.

Relevé du 11 octobre 2026 : code relu et statuts Jira revérifiés ce jour. Même méthode et mêmes consignes de triage que le relevé Common et DiddiGo du 9 octobre.

Écart de classification, à signaler avant lecture. Les 31 use cases DiddiFood portent la phase Later sur les quatre axes du backlog du 14/09. Le planning du 09/10 place pourtant PAR-024 à PAR-027 au MVP, avec les livrables BE020 à BE023 en priorité P0 et P1 sur la fenêtre du 14 au 23 octobre, et PROD-001 énonce que Go, Send et Food lancent leurs parcours essentiels à Abidjan. Ce document suit le planning, source de spécification principale, et ne filtre donc pas sur la phase du backlog. La divergence elle-même est portée en question ci-dessous.

28 questions restent à trancher, sur 59 points relevés. Les trois critères du focus MVP :

une contradiction bloquante entre le code existant et le parcours utilisateur ;
un comportement métier qui bloque le déroulement d'une commande ou d'une course ;
un cas limite qui empêche d'aller au bout d'un parcours principal.

Le reste est fermé : 7 questions de valeur dont le défaut du code fait foi et part en variable d'environnement, 0 sujets légaux traités par procédure manuelle au support, 24 hors des trois critères. Tout est listé en fin de document, rien n'est écarté en silence.

Axe	Questions
Décisions produit	22
Décisions techniques	6
Total	28

Parcours	Attendu	Questions
`PAR-024`	Choisir et commander un repas	9
`PAR-025`	Livrer avec DiddiSend	12
`PAR-026`	Recevoir ses gains et retirer	3
`PAR-027`	Litiges Food	4

Décisions produit

`PAR-024` — Choisir et commander un repas

Ce que le planning attend. Trouve un restaurant, voit plats/prix/dispos, panier, adresse, détail plats vs livraison, paiement. Restaurant accepte ou refuse, cuisine suit la préparation et signale « prêt ». Managers gèrent dispos et accès du personnel ; la cuisine n'accède ni aux retraits ni à la finance.

Décisions produit applicables. PROD-023 restaurant · PROD-044 disponibilité Food · PROD-005 moyens de paiement visibles

Livrable backend BE020 — Restaurants, carte des plats et commande client. Priorité P1, fenêtre 2026-10-14 au 2026-10-23, état planning « À engager ». Publier disponibilité, panier, prix plats/livraison, paiement et reprise d’échec sur la même commande.

Tickets Jira, statuts relevés en direct le 11/10 — SCRUM-25 Terminé(e) · SCRUM-26 Terminé(e) · SCRUM-27 Terminé(e) · SCRUM-28 Terminé(e) · SCRUM-29 Terminé(e) · SCRUM-523 Terminé(e) · SCRUM-528 Terminé(e) · SCRUM-547 A tester

Livrable backend BE021 — Restaurant, cuisine, catalogue et temps de préparation. Priorité P0, fenêtre 2026-10-14 au 2026-10-23, état planning « À engager ». Finaliser images publiques catalogue, droits cuisine/manager, filtres commandes, ouvert/fermé et temps de préparation.

Blocage déclaré par le planning : Contrat/intégration à fermer sur staging ; voir tickets liés.

Tickets Jira, statuts relevés en direct le 11/10 — SCRUM-35 Terminé(e) · SCRUM-36 Terminé(e) · SCRUM-37 Terminé(e) · SCRUM-38 Terminé(e) · SCRUM-39 Terminé(e) · SCRUM-468 A tester · SCRUM-525 À faire · SCRUM-540 A tester · SCRUM-541 A tester · SCRUM-542 À faire · SCRUM-543 À faire · SCRUM-544 À faire · SCRUM-545 À faire · SCRUM-546 En cours · SCRUM-551 A tester · SCRUM-570 À faire

Confluence. Lot — DiddiFood / Client (753665) · Lot — DiddiFood / Restaurant (786433) · DiddiFood — Contrat API, proposition (720898)

État du code au 11/10, relu dans diddi-food. Partiel. Modules catalog, restaurants, ordering, payments présents, 57 opérations exposées : GET /restaurants, /menu, /dishes, PATCH /dishes/{id}/availability, POST /orders, GET /orders/{id}/payment. food_commission_bps = 1500 et restaurant_min_withdrawal_xof = 5000 (app/core/config.py:73,80) correspondent aux 15 % et aux 5 000 F du planning. delivery_time_minutes_default = 30 tient lieu de délai affiché faute de source par restaurant. PlaceOrderIn ne collecte toujours aucun courriel client, que le prestataire de paiement exige : la route de préparation du paiement le réclame donc dans son corps de requête. Nouveau depuis le 29/09 : l'adaptateur DiddiFiles est réellement implémenté (commit e8b8d3c) — DiddiFilesAdapter en S2S client_credentials, audience diddifiles, portées files:read et files:write ; confirm_upload à la création d'un plat et à l'enregistrement d'un restaurant ; photo_url et logo_url résolus par get_public_url sans jamais faire échouer la lecture ; colonne Restaurant.logo_file_id ajoutée par la migration 0020 et route PUT /restaurants/{id}/logo réservée au gérant.

1. Les use cases DiddiFood sont tous classés `Later` au backlog alors que le planning les met au MVP : quelle classification fait foi pour le gel du 18 novembre ?

Nature · Contradiction à arbitrer
Décideur désigné · Direction
Pourquoi retenue · Contradiction code / parcours
Contexte · Les 31 use cases Food portent Later sur les quatre axes du backlog du 14/09. Le planning du 09/10 place PAR-024 à PAR-027 au MVP avec BE020 à BE023 en priorité P0 et P1, et PROD-001 dit que Food lance ses parcours essentiels.
Source · Relevé dans les dépôts le 11/10/2026

Réponse :

2. Le courriel du client doit-il être collecté à la création de commande, dans le profil, ou rester demandé au moment du paiement ?

Nature · Décision à prendre
Décideur désigné · Produit
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Contexte · PlaceOrderIn ne le collecte pas, alors que le prestataire de paiement l'exige pour le paiement en ligne. La route de préparation du paiement le réclame donc dans son corps de requête.
Source · Relevé dans les dépôts le 11/10/2026

Réponse :

3. Quelle est la conséquence d'un refus de commande par un restaurant ?

Nature · Décision à prendre
Décideur désigné · Administration
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Concerne aussi · PAR-027
Rattachement et Jira · UC-230 Le restaurant reçoit une commande et peut l'accepter ou la refuser → SCRUM-35 Terminé(e) · phase backlog Later
Contexte · Le rôle cuisine reçoit une nouvelle commande dans sa file et l'accepte ou la refuse dans un délai décidé.
Source · Fiche UC-230 · section « Questions ouvertes » · corpus du 14/09/2026

Réponse :

4. Quelle est la fenêtre d'annulation d'une commande alimentaire ?

Nature · Décision à prendre
Décideur désigné · Administration
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Rattachement et Jira · UC-353 Le client annule sa commande dans la fenêtre autorisée → aucun ticket cité par le planning · phase backlog Later
Contexte · Un client food annule sa commande, gratuitement dans une fenêtre autorisée, ou en connaissant le coût au-delà.
Source · Fiche UC-353 · section « Questions ouvertes » · corpus du 14/09/2026

Réponse :

5. Qui paie un repas annulé après acceptation, et qui paie un plat refusé à la livraison ?

Nature · Décision à prendre
Décideur désigné · Administration
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Rattachement et Jira · UC-351 Le client paie sa commande alimentaire en espèces à la livraison → aucun ticket cité par le planning · phase backlog Later
Contexte · Un client food choisit de payer en espèces au moment de la livraison plutôt que via DiddiPay.
Source · Fiche UC-351 · section « Questions ouvertes » · corpus du 14/09/2026

Réponse :

6. Un temps de préparation annoncé engage-t-il le restaurant, et que se passe-t-il s'il est dépassé ?

Nature · Décision à prendre
Décideur désigné · Produit
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Rattachement et Jira · UC-231 Le restaurant indique un temps de préparation → SCRUM-36 Terminé(e) · phase backlog Later
Contexte · Le rôle cuisine annonce un temps de préparation, qui alimente l'heure d'arrivée estimée montrée au client.
Source · Fiche UC-231 · section « Questions ouvertes » · corpus du 14/09/2026

Réponse :

7. À quelle heure exactement un plat basculé en indisponible pour la journée est-il réactivé ?

Nature · Décision à prendre
Décideur désigné · Produit
Pourquoi retenue · Empêche d’aller au bout d’un parcours principal
Rattachement et Jira · UC-355 Le poste cuisine bascule un plat en indisponible pour la journée, avec réactivation automatique le lendemain → aucun ticket cité par le planning · phase backlog Later
Contexte · Le rôle cuisine bascule un plat en indisponible pour le reste de la journée, en un geste, sans devoir penser à le réactiver le lendemain.
Source · Fiche UC-355 · section « Questions ouvertes » · corpus du 14/09/2026

Réponse :

`PAR-025` — Livrer avec DiddiSend

Ce que le planning attend. La commande crée une livraison Send liée à la même référence. Contraintes véhicule et exclusivité. États remontés à Food. Timeout : pas de doublon de mission. Événement tardif ou répété : cohérence conservée. Restaurant fermé, refus, retard, pas de coursier, échec de remise : décision visible puis support / annulation / remboursement.

Décisions produit applicables. PROD-022 livraison Food exclusive · PROD-029 engagement Food et incidents

Livrable backend BE022 — Livraison repas exclusive, préparation et heure d’arrivée estimée. Priorité P0, fenêtre 2026-10-14 au 2026-10-23, état planning « À engager ». Lier commande et livraison unique ; coursier/véhicule compatible ; synchroniser préparation, collecte, remise et estimation.

Tickets Jira, statuts relevés en direct le 11/10 — SCRUM-44 Terminé(e) · SCRUM-45 Terminé(e) · SCRUM-46 Terminé(e) · SCRUM-47 À faire · SCRUM-54 À faire · SCRUM-55 À faire · SCRUM-404 A tester · SCRUM-414 A tester · SCRUM-469 Terminé(e) · SCRUM-552 A tester

Confluence. Lot — DiddiFood / Livreur (819201) · Lot — DiddiFood / Systeme (884737)

État du code au 11/10, relu dans diddi-food. Partiel. Module delivery avec l'adaptateur diddisend_adapter.py. La charge envoyée est complète au regard du schéma de DiddiSend : recipient_name, recipient_phone, sender_phone, package, delivery_mode = door_to_door, payment_method, quoted_price, origin_module = diddifood, order_reference, idempotency_key, ready_at, required_vehicle_type = motorcycle, exclusive = True, financial_breakdown (diddisend_adapter.py:69-104). Deux limites réelles : le déclenchement à l'acceptation est best-effort, enveloppé dans un try/except pour qu'une panne Send ne transforme pas une acceptation réussie en 503 — l'échec est journalisé delivery.request_failed_at_acceptance, GET /orders/{id}/delivery renvoie 404 et la reprise est manuelle par POST /orders/{id}/delivery/request ; et delivery_status_sync_enabled vaut False par défaut (app/core/config.py:68), donc la remontée des états de DiddiSend vers Food ne tourne pas tant qu'elle n'est pas activée.

1. Comment le temps d'arrivée estimé total se compose-t-il, et que voit le client si l'un des termes est inconnu ?

Nature · Décision à prendre
Décideur désigné · Produit
Pourquoi retenue · Empêche d’aller au bout d’un parcours principal
Use cases que la source dit bloqués · UC-238
Source · management/specs/etat/a-trancher.md · section « Portée Later » · 14/09/2026

Réponse :

2. L'engagement de délai d'arrivée du coursier est figé à la commande et jamais recalculé. Est-ce acceptable pour le lancement, ou faut-il un recalcul minimal quand le restaurant met à jour son estimation de préparation ?

Nature · Décision à prendre
Décideur désigné · Produit
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Contexte · Deux défaillances en découlent : une préparation plus longue laisse le coursier attendre à vide, une préparation plus courte laisse le plat prêt avant son arrivée.
Source · Relevé dans les dépôts le 11/10/2026

Réponse :

3. La preuve de remise d'un repas est-elle une photo, comme pour un colis, ou un geste plus léger ?

Nature · Décision à prendre
Décideur désigné · Produit
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Rattachement et Jira · UC-237 Le livreur livre la commande au client avec confirmation de remise → SCRUM-46 Terminé(e) · phase backlog Later
Contexte · Le livreur remet la commande au client, avec une preuve, et encaisse en espèces si c'est le mode de paiement choisi.
Source · Fiche UC-237 · section « Questions ouvertes » · corpus du 14/09/2026

Réponse :

4. Pour un paiement en ligne, l'attribution du coursier attend-elle le succès du paiement, ou part-elle en parallèle avec annulation en cas d'échec ?

Nature · Décision à prendre
Décideur désigné · Produit
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Contexte · L'attribution se déclenche à l'acceptation du restaurant. En ligne, acceptation et création de l'intention de paiement arrivent au même instant : si la recherche démarre et que le paiement échoue, un coursier est en route pour une commande à annuler.
Source · Relevé dans les dépôts le 11/10/2026

Réponse :

5. Que fait le livreur d'un repas qu'il n'a pas pu remettre ?

Nature · Décision à prendre
Décideur désigné · Administration
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course · Empêche d’aller au bout d’un parcours principal
Rattachement et Jira · UC-237 Le livreur livre la commande au client avec confirmation de remise → SCRUM-46 Terminé(e) · phase backlog Later
Contexte · Le livreur remet la commande au client, avec une preuve, et encaisse en espèces si c'est le mode de paiement choisi.
Source · Fiche UC-237 · section « Questions ouvertes » · corpus du 14/09/2026

Réponse :

6. Que se passe-t-il quand un restaurant est en retard sur son temps annoncé et que le livreur attend ?

Nature · Décision à prendre
Décideur désigné · Produit
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Rattachement et Jira · UC-236 Le livreur confirme son arrivée au restaurant et la récupération de la commande → SCRUM-45 Terminé(e) · phase backlog Later
Contexte · Le livreur confirme son arrivée au restaurant, patiente si la commande n'est pas prête, puis confirme la récupération.
Source · Fiche UC-236 · section « Questions ouvertes » · corpus du 14/09/2026

Réponse :

7. Que se passe-t-il si aucun livreur n'est disponible au moment où la commande est prête ?

Nature · Décision à prendre
Décideur désigné · Produit
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Rattachement et Jira · UC-239 Le système crée ou réserve une livraison quand la commande est acceptée, ou quand elle approche d'être prête → SCRUM-55 À faire · phase backlog Later
Contexte · Le système déclenche la création ou la réservation d'une livraison au bon moment, ni trop tôt (coursier immobilisé) ni trop tard (aucun livreur trouvé).
Source · Fiche UC-239 · section « Questions ouvertes » · corpus du 14/09/2026

Réponse :

8. Une acceptation de commande doit-elle rester valide quand la demande de livraison échoue, ou faut-il la refuser pour éviter une commande sans coursier ?

Nature · Décision à prendre
Décideur désigné · Produit
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Contexte · Le déclenchement est best-effort : une panne DiddiSend ne transforme pas une acceptation réussie en 503. L'échec est journalisé et GET /orders/{id}/delivery renvoie 404, avec reprise manuelle.
Source · Relevé dans les dépôts le 11/10/2026

Réponse :

`PAR-026` — Recevoir ses gains et retirer

Ce que le planning attend. Commission restaurant 15 % (livraison à part). Voit écritures, montants en attente / disponibles / réservés. Gain numérique dispo après paiement confirmé + collecte confirmée par Send. Cash : régularisation Send confirmée. Retrait : minimum, frais, net, montant réservé pendant le payout ; pas de double dépense du même solde.

Limite que le planning déclare. Minimum 5 000 XOF à maintenir ou changer explicitement.

Décisions produit applicables. PROD-004 commission restaurant sur les plats · PROD-003 socle financier · PROD-032 retraits

Livrable backend BE023 — Wallet restaurant et demande de retrait par le manager. Priorité P0, fenêtre 2026-10-14 au 2026-10-23, état planning « À engager ». Vérifier 15 %, minimum 5 000 F, fonds en attente/disponibles/réservés, bénéficiaire et transfert ; cash confirmé avant disponibilité.

Blocage déclaré par le planning : Contrat/intégration à fermer sur staging ; voir tickets liés.

Tickets Jira, statuts relevés en direct le 11/10 — SCRUM-456 À faire · SCRUM-471 A tester · SCRUM-472 À faire · SCRUM-484 Terminé(e) · SCRUM-500 A tester · SCRUM-522 A tester · SCRUM-525 À faire

Confluence. Lot — DiddiFood / Partenaire (950273) · Décision — Wallet restaurant, commission et retraits DiddiFood (5537793)

État du code au 11/10, relu dans diddi-food. Présent. Modules wallets et payouts : /entries, /withdrawals, /withdrawal-quote, /withdrawals/{id}. Le partage financier est contrôlé par invariant : courier_earning + send_commission == delivery_fee et customer_total == order_total + delivery_fee (ordering/domain/entities.py:95-97). Or delivery_fee_xof et send_commission_bps valent 0 par défaut (app/core/config.py:74,78) : la livraison d'une commande Food est donc gratuite et le coursier touche zéro tant que ces valeurs ne sont pas posées. restaurant_advance_limit_xof = 25000, restaurant_withdrawal_fee_xof = 0.

1. Le backlog introduit un partenaire alimentaire que le glossaire de la section 3 ne définit pas, et qui ne correspond ni au pro ni au partenaire

Nature · Contradiction à arbitrer
Décideur désigné · Produit
Pourquoi retenue · Contradiction code / parcours
Rattachement et Jira · UC-243 Le partenaire consulte ses ventes, commissions, reversements et performances de préparation → aucun ticket cité par le planning · phase backlog Later
Contexte · Un partenaire alimentaire consulte ses ventes, ses commissions, ses reversements et ses performances de préparation, par point de vente et consolidés.
Source · Fiche UC-243 · section « Questions ouvertes » · corpus du 14/09/2026

Réponse :

2. Le tarif de livraison d'une commande Food est-il porté par DiddiFood ou par le devis de DiddiSend ?

Nature · Décision à prendre
Décideur désigné · Produit
Pourquoi retenue · Contradiction code / parcours · Bloque le déroulement d’une commande ou d’une course
Contexte · Food impose courier_earning + send_commission == delivery_fee et pose delivery_fee_xof = 0 et send_commission_bps = 0 par défaut ; DiddiSend calcule de son côté un prix complet et une commission de 10 %. Les deux chemins coexistent sans règle de préséance.
Source · Relevé dans les dépôts le 11/10/2026

Réponse :

3. Par quel mécanisme le restaurant est-il payé sur une commande encaissée en espèces ?

Nature · Décision à prendre
Décideur désigné · Produit
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Contexte · La première moitié de la question est tranchée par le code depuis le 10/10 : le coursier reverse à la plateforme, DiddiSend suivant son encours cash en brut. Reste à dire si la part du restaurant suit le même circuit de versement DiddiPay qu'une commande en ligne, et à quel moment elle devient disponible.
Source · Relevé dans les dépôts le 11/10/2026

Réponse :

`PAR-027` — Litiges Food

Ce que le planning attend. Plat manquant, erreur, retard, restaurant fermé → support + décision humaine tracée.

Limite que le planning déclare. Exclus du MVP : retrait sur place, remplacement de plat, recharge du wallet restaurant.

Décisions produit applicables. PROD-029 incidents Food · PROD-034 autorité de remboursement · PROD-017 support

Livrable backend BE010 — Reprise humaine et suivi des tickets. Priorité P0, fenêtre 2026-10-14 au 2026-10-23, état planning « À engager ». Créer et relier ticket, mission et conversation ; notifier agent ; suivre traitement et réouverture.

Tickets Jira, statuts relevés en direct le 11/10 — SCRUM-58 V2 · SCRUM-383 À faire · SCRUM-385 À faire · SCRUM-527 En cours · SCRUM-532 À faire · SCRUM-535 À faire

Confluence. Lot — DiddiFood / Support (917505) · Lot — DiddiAdmin (1114113)

État du code au 11/10, relu dans diddi-food. Partiel, et au-delà de la limite déclarée. POST /orders/{id}/refund-requests puis POST /admin/refund-requests/{id}/approve|reject et GET /admin/refund-requests : la forme en deux temps est réelle et appliquée. Mais aucun acteur « support » n'est autorisé à soumettre — le code le dit lui-même : « DiddiFreeID's roles are strictly global (user/admin) with no support role today » (payments/presentation/router.py:297-299). Et le retrait sur place est désormais codé alors que la limite du planning l'exclut : PickupMode.PICKUP (ordering/domain/entities.py:64), champ pickup_mode dans PlaceOrderIn, frais de livraison mis à zéro quand le mode est pickup (entities.py:173), et complete_pickup_order avec sa route de complétion (commit 6e84484).

1. Le retrait sur place est codé alors que la limite du planning l'exclut du MVP : on l'ouvre au lancement, ou on le ferme par configuration ?

Nature · Contradiction à arbitrer
Décideur désigné · Produit
Pourquoi retenue · Contradiction code / parcours
Contexte · La limite de PAR-027 énonce « Exclus du MVP : retrait sur place, remplacement de plat, recharge du wallet restaurant ». Or PickupMode.PICKUP existe, PlaceOrderIn porte pickup_mode, les frais de livraison tombent à zéro en mode retrait et complete_pickup_order expose sa route (commit 6e84484 du 01/10).
Source · Relevé dans les dépôts le 11/10/2026

Réponse :

2. Quelle preuve un client doit-il fournir pour un plat manquant ou impropre ?

Nature · Décision à prendre
Décideur désigné · Administration
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Rattachement et Jira · UC-242 Le support traite les litiges food : plat manquant, erreur de commande, retard, restaurant fermé → SCRUM-58 V2 · phase backlog Later
Contexte · Un agent de support traite un litige sur une commande alimentaire (plat manquant, erreur, retard, restaurant fermé), dans la même file qu'un litige de course ou de livraison.
Source · Fiche UC-242 · section « Questions ouvertes » · corpus du 14/09/2026

Réponse :

3. Qui peut soumettre une demande de remboursement, tant qu'aucun acteur support n'existe dans DiddiFood ?

Nature · Décision à prendre
Décideur désigné · Produit
Pourquoi retenue · Empêche d’aller au bout d’un parcours principal
Contexte · La forme en deux temps — soumission puis approbation — est réelle et appliquée. Seul qui est autorisé à soumettre reste un emplacement réservé, en attente d'une capacité support locale ou d'une intégration DiddiAdmin.
Source · Relevé dans les dépôts le 11/10/2026

Réponse :

4. Qui supporte le coût d'un repas non livré, et celui d'un plat refusé à la livraison ?

Nature · Décision à prendre
Décideur désigné · Administration
Pourquoi retenue · Bloque le déroulement d’une commande ou d’une course
Rattachement et Jira · UC-359 L'administrateur arbitre qui supporte le coût d'un repas non livré ou refusé → aucun ticket cité par le planning · phase backlog Later
Contexte · Un administrateur décide qui supporte le coût d'un repas non livré ou refusé — plateforme, restaurant, livreur ou client — et produit un mouvement d'argent réel.
Source · Fiche UC-359 · section « Questions ouvertes » · corpus du 14/09/2026

Réponse :

Décisions techniques