# Plan de travail — missioflow-mobile

Application mobile multi-tenant React Native / Expo pour CoolCare et MissioFlow SaaS.  
Un seul codebase, un seul binaire, connectable à n'importe quelle instance via URL ou QR code.

---

## Phase 1 - Fondations

Nettoyage et structure du projet.

- Renommer le repo en `missioflow-mobile`, mettre à jour `app.json` (slug, name)
- Supprimer `axios`, remplacer par `fetch` natif dans `apiClient.ts`
  - Réécrire les interceptors auth + refresh token sans dépendance externe
- Restructurer les dossiers selon l'arborescence cible
  - `src/core/` — services singleton (env, auth, sync, api)
  - `src/features/` — onboarding, dashboard, missions, intervention, profil
  - `src/shared/` — composants réutilisables, hooks, utils
  - `src/types/` — tous les types TypeScript
- Configurer le pipeline GitLab CI
  - Build APK debug déclenché sur push `develop` — artefact téléchargeable directement depuis GitLab
  - Build AAB release signé déclenché sur tag

---

## Phase 2 - Multi-tenant

Onboarding et configuration dynamique.

Reference du contrat backend/mobile : voir API_CONTRACT.md (reference officielle).

- Remplacer `api.ts` hardcodé par un `EnvironmentService`
  - URL stockée dans `expo-secure-store`, chargée au runtime
  - Plus aucune URL compilée dans le binaire
- Écran onboarding — saisie URL manuelle ou scan QR code
  - QR code généré depuis le panel admin de chaque instance
  - Peut embarquer URL + token d'invitation pour pré-remplir le login
- Endpoint `/api/mobile-config` à ajouter sur les deux backends
  - Retourne : nom app, couleur primaire, URL logo, tenant_id (null pour CoolCare)
- Chargement dynamique de l'identité visuelle au démarrage
- Injection automatique du `tenant_id` dans tous les appels API
  - Null pour CoolCare, présent pour MissioFlow SaaS

---

## Phase 3 - Auth

Login, session et navigation.

- Écran login avec gestion d'erreurs
- Adapter `authApi.ts` et `apiClient.ts` au nouveau fetch natif
  - Refresh token automatique sur 401
- Navigation conditionnelle — onboarding / login / app principale
- Option "Changer d'instance" depuis l'écran profil
  - Reset complet : SecureStore + SQLite local

---

## Phase 4 - Offline

SQLite, sync queue et reconnexion.

Reference des etapes de workflow : voir STEP_WORKFLOW_CONTRACT.md (reference officielle).

- Intégrer `expo-sqlite` — schéma de la base locale
  - Tables : `missions`, `interventions`, `steps`, `sync_queue`
- Full sync au login et à chaque reconnexion réseau
  - Toutes les missions assignées au technicien embarquées localement
- Toute action hors ligne écrite dans `sync_queue` avec timestamp + payload
- `SyncService` — détection reconnexion via plugin `expo-network`
  - Push queue vers `POST /api/sync/push`
  - Pull delta via `GET /api/sync/pull?since={timestamp}`
  - Conflit : version serveur gagne, log local conservé
- Indicateur online/offline visible dans l'UI (dashboard)

---

## Phase 5 - Fonctionnalités

Missions et workflow intervention.

Reference des etapes de workflow : voir STEP_WORKFLOW_CONTRACT.md (types, validations, sync).

- Dashboard — missions du jour, statuts, badge online/offline
- Écran mission — détail, informations site/machine, historique interventions précédentes
- Workflow intervention complet — étapes, checklist, saisie de valeurs
  - Démarre immédiatement sans réseau grâce au SQLite local (résout le problème PWA)
- Photos via plugin `expo-image-picker` / `expo-camera`
- Signature technicien + client
  - Évaluer si `react-native-signature-canvas` reste justifié ou remplacement par canvas natif

---

## Phase 6 - Notifications push

FCM intégré dès la v1.

- Intégrer `expo-notifications` + Firebase Cloud Messaging
- Endpoint backend — enregistrement du token FCM au login
- Notifications déclenchées côté backend :
  - Nouvelle mission assignée au technicien
  - Rappel d'intervention planifiée
  - (extensible en v2 selon les besoins)

---

## Phase 7 - Release

Build et déploiement stores.

- Pipeline GitLab — build AAB release signé sur tag
- Play Store — publication Android
- Build iOS sur Mac — distribution TestFlight en premier
  - App Store (99$/an) non prioritaire, TestFlight suffit pour la phase de test

---

## Dépendances retenues

| Package | Justification |
|---|---|
| `expo` + plugins officiels | Coeur du projet, incontournable |
| `expo-secure-store` | Stockage sécurisé tokens + URL instance |
| `expo-sqlite` | Base locale offline |
| `expo-notifications` | Notifications push FCM |
| `expo-network` | Détection état connexion |
| `expo-camera` / `expo-image-picker` | Photos pendant intervention |
| `react-native-signature-canvas` | À réévaluer en phase 5 |

Aucune autre dépendance externe sans décision explicite.  
Pas d'axios, pas de librairie HTTP tierce — fetch natif uniquement.

---

## Contrat d'API commun (backends)

Les deux backends (CoolCare PHP et MissioFlow SaaS) doivent exposer ces endpoints de manière identique :

```
GET    /api/mobile-config
POST   /api/auth/login
POST   /api/auth/refresh
POST   /api/auth/logout
GET    /api/auth/me
GET    /api/missions
GET    /api/missions/{id}
POST   /api/missions/{id}/start
POST   /api/missions/{id}/steps/{sid}/complete
POST   /api/missions/{id}/finish
POST   /api/sync/push
GET    /api/sync/pull?since={timestamp}
POST   /api/devices/fcm-token
```

Seule différence : MissioFlow SaaS scope toutes les requêtes par `tenant_id` (via JWT ou sous-domaine). CoolCare l'ignore.