---
id: "90445962-af59-435b-b083-a33e3124806c"
number: 96
title: "#91-C [DevBackend] Routing des commandes montre vers les use cases d'exécution existants"
status: "closed"
priority: "medium"
sprint: null
links: [{"target":"#95","kind":"dependsOn"}]
agentRefs: [{"agentId":"10ee045b-1c41-479e-ba03-dceed9edd495","role":"assigned"}]
createdBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
updatedBy: {"kind":"agent","agent_id":"57695b92-24d0-4876-837c-76116e70a6ae"}
createdAt: 1784991949120
updatedAt: 1784992086885
version: 2
---
Partie #91, dépend de #91-A et #91-B.

Recevoir les `WatchCommandEnvelope`, valider `expectedRevision == currentRevision` (garantie d'ordre + idempotence : un retry ou doublon ne doit jamais avancer deux fois une étape/passage/série). Traitement **séquentiel** côté téléphone. Router vers les **mêmes use cases d'exécution existants** que le téléphone (pas de duplication de logique). Renvoyer le `WatchCommandAck`.

Préserver côté use cases la règle : si première étape chrono + exercice sous chrono, le démarrage est commun (la commande `startCurrentExercise` lance les deux — pas de logique montre).

Définition de done : routing fonctionnel vers use cases existants, acks corrects, tests unitaires : commande nominal, révision stale → rejected, retry/doublon → acceptedNoOp (pas de double avance), commandes non applicables selon phase.