Ce fichier décrit la sécurisation du parcours cuisine livrée le 20 octobre 2026. Il s'adresse aux équipes frontend, backend et QA.

2026-10-20 — Sécurisation du parcours cuisine

Modifications

• Les actions restaurant accept, reject, ready, pickup/complete et substitution choisissent maintenant leur réponse selon le rôle appelant.
• Un membre kitchen reçoit OrderKitchenOut, sans prix, total, méthode de paiement ni ventilation financière.
• Un manager conserve OrderOut pour piloter le restaurant et ses finances.
• Le contrat OpenAPI décrit désormais les deux représentations possibles.

Validation

• Ruff : OK.
• Tests : 140 réussis.
• Compilation Python : OK.

Décision S2S des remboursements Backoffice

• Ajout de POST /food/v1/internal/backoffice/refund-requests/{id}/approve et /reject, avec scope food:payments:write, motif obligatoire, idempotence et reçu dans backoffice.admin_actions.
• L'approbation en ligne appelle DiddiPay avec une clé stable ; le cash reste approuvé pour règlement manuel. Le rejet ne déplace aucun argent.
• Le manifeste, le contrat Backoffice, l'OpenAPI et les tests couvrent ces deux commandes.

Validation après cette évolution : Ruff OK, 143 tests réussis, compilation Python OK.

Contexte métier DiddiSupport

• Ajout de GET /internal/v1/support/order/{order_id}/context, lecture seule, conforme à diddi.context.v1.
• Le contexte retourne l'état Food, le paiement et la projection Send avec montants XOF, sans données client sensibles ni identifiant d'intention Pay.
• Authentification S2S dédiée : aud=diddifood, scope diddifood:support-context:read et X-Support-Context-Scope.
• La configuration staging attend encore le vrai DIDDISUPPORT_CLIENT_ID.

Prochaines validations externes

• Recette DiddiSend complète et événement delivery.cash_remitted.
• Activation contrôlée du worker de synchronisation et du consommateur wallet.
• Recette DiddiPay online, remboursements et retraits.
• Validation staging DiddiFiles et FCM.