# Chantier — Alignement mobile ⇄ backends (coolcare + missioflow)

> Rédigé le 2026-06-06. Faits vérifiés dans le code réel (chemins:lignes cités), pas spéculés.
> Côté **client mobile**. Pendants backend : `coolcare-app/CHANTIER_ALIGNEMENT_MOBILE.md` et `missioflow-app/CHANTIER_ALIGNEMENT_MOBILE.md`.

## TL;DR — correction d'un malentendu

Les deux points de départ étaient :
1. « Endpoints backend manquants / non implémentés à aligner sur les deux backends. »
2. « Dérive thin-client : port manuel qui diverge. »

Après vérification :
- **Point 1 est FAUX dans sa formulation.** Les endpoints existent ET sont commités dans les deux backends. Le `404` que le mobile tolère n'est pas « pas implémenté » → c'est de la **compat pour instances en retard de déploiement**. Le vrai sujet est le **déploiement**, pas le code.
- **Point 2 est VRAI mais plus ciblé qu'annoncé.** Le rendu des étapes est déjà piloté backend. Ce qui diverge encore = le **vocabulaire métier dupliqué** (statuts, mots-clés « problème »).

---

## Point 1 — Tolérance 404 : c'est de la compat, pas un manque

Le mobile dégrade proprement quand un endpoint répond 404, pour rester fonctionnel sur une instance dont le backend déployé est antérieur à l'ajout de l'endpoint :

- Bouteilles → `{ available: false }` : [src/services/bottlesApi.ts:5-9](src/services/bottlesApi.ts#L5-L9), [src/services/bottlesApi.ts:35-36](src/services/bottlesApi.ts#L35-L36)
- mobile-config → config de fallback : [src/services/mobileConfigApi.ts:88](src/services/mobileConfigApi.ts#L88)
- auth (login/me/refresh) → cascade `.php` puis sans extension : [src/services/authApi.ts:18-29](src/services/authApi.ts#L18-L29)

### Réalité vérifiée côté backends
Les endpoints appelés existent et sont commités des **deux** côtés :

| Endpoint appelé par le mobile | coolcare-app | missioflow-app |
|---|---|---|
| `/mobile/bottles.php` | `public/api/mobile/bottles.php` (commit `ec8e93f`) | `public/api/mobile/bottles.php` (commit `9d0743ff`) |
| `/mobile/bottle_action.php` | `public/api/mobile/bottle_action.php` (commit `7bd9eff`) | `public/api/mobile/bottle_action.php` (commit `d2530a45`) |
| `/mobile-config(.php)` | `public/api/mobile-config.php` (commit `88d8940`) | `public/api/mobile-config.php` (commit `b5928c43`) |

Les chemins concordent : le mobile appelle `${baseUrl}/mobile/X.php`, `baseUrl` inclut déjà `/api`, et les fichiers vivent en `public/api/mobile/X.php`.

### Action mobile
- **Ne rien créer / ne rien modifier sur la tolérance 404** : elle est correcte et utile en multi-instances.
- Côté terrain : si une instance renvoie 404, le problème est un **déploiement en retard** (voir markdowns backend). Garder la tolérance comme filet, pas comme palliatif permanent.
- *(Optionnel)* logguer/remonter quelle instance répond 404 sur quel endpoint, pour repérer les instances sous-déployées au lieu de masquer silencieusement.

---

## Point 2 — Ce qui diverge réellement : le vocabulaire métier dupliqué

### Déjà bon (piloté backend, ne pas toucher)
Le rendu et la visibilité des étapes sont dirigés par le serveur :
- `display_only` (flag serveur prioritaire) : [src/shared/workflowUtils.ts:359-365](src/shared/workflowUtils.ts#L359-L365)
- règles de visibilité `visible_if_in_parent` / `visible_if_not_parent` venant de `rules_json` (→ `constraints`) : [src/shared/workflowUtils.ts:99-126](src/shared/workflowUtils.ts#L99-L126)
- dispatch sur `input_kind` brut serveur, miroir assumé du PWA : [src/features/missions/WorkflowInterventionScreen.tsx:1330-1333](src/features/missions/WorkflowInterventionScreen.tsx#L1330-L1333)

### Ce qui dérive

1. **Mots-clés « problème »** — déjà centralisés en une source unique côté mobile :
   [src/shared/workflowUtils.ts:74-80](src/shared/workflowUtils.ts#L74-L80)
   `['probleme','panne','ko','defaut','non conforme','a revoir']`
   (copie assumée du JS coolcare `public/js/workflow-utils.js:28-36`). Rien à dédoublonner
   côté mobile ; reste à le faire servir par le backend si on veut tuer la copie cross-projet.

2. **Statuts d'intervention** — ✅ **centralisés (2026-06-06)**. Les sets `TODO_STATUSES`/
   `DONE_STATUSES`, jusque-là copiés à l'identique dans StatsScreen / MissionsDashboard /
   PlanningScreen + check inline dans MissionDetailScreen, sont désormais une source unique :
   [src/shared/interventionUtils.ts:16-32](src/shared/interventionUtils.ts#L16-L32)
   (`TODO_STATUSES`, `DONE_STATUSES`, helpers `isTodoStatus` / `isDoneStatus`).
   Ces valeurs **viennent du backend** (enum `statut`) : le mobile recopie le vocabulaire
   backend, la centralisation interne ne fait que réduire 3 copies à 1.

### Direction
⚠️ **C'est au mobile de s'aligner sur les backends, pas l'inverse.** Le backend (coolcare + missioflow) est la source de vérité des statuts ; on ne demande PAS aux backends d'exposer un format pensé pour le mobile. Le mobile suit leur enum `statut` existant.

### Action mobile — ✅ fait ET vérifié aligné (2026-06-06)
- Vocabulaire centralisé en un point unique ([interventionUtils.ts:16-32](src/shared/interventionUtils.ts#L16-L32)).
- **Vérification contre l'enum backend réel** (`planifiee, en_cours, terminee, reportee, annulee` — identique coolcare/missioflow, cf. `src/database/schema.sql:749`) : les 5 valeurs sont toutes correctement traitées (3 en TODO, `terminee` en DONE, `annulee` volontairement hors onglets — comportement **testé**). → le mobile est fidèle au backend, rien à corriger sur les valeurs.
- `en_attente` / `cloturee` présents dans les sets = **superset défensif volontaire et testé** (valeurs impossibles pour une intervention, hors enum) ; inoffensifs car jamais produits. Ne pas les retirer (tests dédiés `MissionsDashboard.test.tsx:115,133`, `MissionDetailScreen.test.tsx:159`).
- Le mobile lit déjà le `statut` brut servi (le contrat suffit) ; aucun champ à réclamer côté serveur.
- `isProblemValue` : déjà source unique côté mobile, miroir assumé du JS coolcare.
- **Responsabilité continue** (légère) : si le backend fait évoluer son enum `statut`, le mobile suit (1 seul point à toucher désormais).

---

## Récap actions
| # | Quoi | Où | État |
|---|---|---|---|
| 1 | Garder la tolérance 404 (ne pas la traiter comme un TODO endpoint) | mobile | rien à faire (volontaire) |
| 2 | Centraliser statuts dans un module unique | mobile | ✅ fait 2026-06-06 (`interventionUtils.ts`) |
| 3 | Aligner les statuts mobile sur l'enum backend réel | mobile | ✅ vérifié aligné 2026-06-06 (5 valeurs enum OK, extras défensifs testés) |