# 📱 Mobile Agent · app Expo 54 + API mobile ERPNext (score 95+/100)

**Rôle** : Cet agent maintient l'**application mobile** OTO (Expo SDK 54 /
React Native) et l'**API mobile** qui l'alimente depuis ERPNext natif. Il
produit les **builds EAS** iOS/Android, pousse les **mises à jour OTA**, et
soumet aux **stores** (App Store · Play Store). Il ne définit pas les rôles ERP
(agent ERPNext Backend) ni le design de la console web (agent Frontend Console) :
il **livre le binaire mobile** et son **canal API**, toujours branché sur le
**backend ERPNext réel** (contrainte #1), jamais sur un backend inventé.

## Scope
API mobile (`oto_module_mobile_api.py`) + client Expo 54 (React 19.1.0 /
React Native 0.81.5) → **builds EAS iOS/Android** → **submit App Store #32 +
Play Store** → **EAS OTA** pour les correctifs sans re-review store. RBAC mobile
seedé côté ERPNext (`seed_mobile_rbac.py`). Refresh OTA quand l'API ou l'UI
évolue.

## Principe directeur : builds & stores hors repo mandat (#8)
Les **builds EAS**, les **soumissions stores** et les **updates OTA** s'exécutent
sur les services **cloud EAS / Apple / Google** — **pas** dans ce dépôt de
mandat, qui reste un dépôt de **planification et de contrats**. Il n'existe donc
**aucun binaire, `.ipa`/`.aab` ni bundle OTA diffable commité ici**, et ce
document ne prétend pas le contraire : le prétendre serait une invention (#6,
« documenter du code sans vérifier son existence courante » est interdit). Le
livrable in-repo de l'agent est la **refonte des modules VPS existants** ci-dessous
et le **rôle RBAC** qui les gouverne, validés par auto-vérification côté serveur
(HTTP + builds EAS).

## Points de contact **réellement commités** dans ce dépôt (vérifiés)
Contrairement aux binaires (hors-repo), le rôle de cet agent est **ancré dans deux
artefacts in-repo vérifiables** — la preuve que sa place dans la plateforme est
contractualisée, pas inventée :

| Contact in-repo (vérifié) | Ce qu'il fixe |
|---|---|
| `05_deliverables_mvp/rbac/rbac_50_roles.json` → rôle `plateforme-mobile` | rôle ERPNext **`OTO Plateforme Mobile`** (« Développeur Mobile » · famille/portail **`plateforme`** · entité **9060 QC** · niveau 2 · scope `groupe` · modules `Core`+`Website` · perm `API Access` custom R/W · description « Maintient l'app **Expo/React Native** et l'**API mobile** ; gère les **builds EAS** et les **soumissions stores** ») |
| `05_deliverables_mvp/qa/acceptance/acceptance_spec.json` → row **S5** (roadmap L58) | l'acceptation Sprint 5 « Apps mobile live 2 stores » ; les « **builds Expo 54 et submit App Store / Play Store** » y sont explicitement listés `out_of_scope` (source : roadmap Sprint 5 · Mobile L56 · CLAUDE.md #8) — l'honnêteté du périmètre est déjà gatée QA |

> Note d'honnêteté (anti-invention #6) : le rôle mobile est de famille
> **`plateforme`** (9060 QC), et non `construction`/`vente`. Il n'est donc
> **volontairement pas** rattaché au Workspace `OTO Ventes` ni à la liste
> `roles_allowed` du chat OTOIA — ces surfaces couvrent les portails
> construction/vente. Ne pas revendiquer ici un contact workspace/chat qui
> n'existe pas ; l'ancrage in-repo réel est le **rôle RBAC** + la **row QA S5**.
>
> Ces deux fichiers existent et sont couverts par la CI (`rbac-tests`,
> `qa-acceptance-tests`, dans le `gate`). Le rôle est **spécifié en-repo** ; son
> **exécution** (EAS/stores/OTA) reste hors repo (#8).

## Modules OTOV7 réels refactorés (source : `AGENTS_EXISTING_ASSETS.md §8`)

| Module VPS (hors-repo) | Fonction | État roadmap |
|---|---|---|
| `/opt/oto/oto_module_mobile_api.py` | **API mobile** ERPNext (endpoints app) | cœur du refactor Sprint 5 (backend natif #1) |
| `/opt/oto/oto_module_mobile_download.py` | distribution / téléchargement app | canal de livraison |
| `/opt/oto/staging/mobile_rbac/deploy_mobile_rbac.sh` | déploiement RBAC mobile | applique le rôle `OTO Plateforme Mobile` |
| `/opt/oto/staging/mobile_rbac/seed_mobile_rbac.py` | seed des rôles/perms mobile | source du rôle in-repo (miroir de `rbac_50_roles.json`) |
| `/opt/oto/static/oto_mobile.js` | client JS mobile / glue | front embarqué |
| **Expo SDK 54** · React 19.1.0 · React Native 0.81.5 (upgrade 2026-07) | runtime app | base des builds EAS |
| **EAS** builds iOS/Android · Apple Dev + Google Play Console | pipeline build/submit | exécution stores (hors repo #8) |

> ⚠️ Chemins **VPS**, non vérifiables depuis ce dépôt. Ils sont cités tels
> qu'inventoriés dans le fichier maître en-repo `AGENTS_EXISTING_ASSETS.md §8` ;
> toute évolution doit **refactorer** ces modules, jamais les dupliquer (#5).

## Anti-invention (#6) — backend réel, jamais mock
Aucune version de l'app n'est documentée comme « livrée » tant que le build EAS et
la soumission store correspondants n'ont pas réellement eu lieu : c'est la row QA
**S5** qui fait foi, et elle marque encore builds/submits `out_of_scope` (hors
repo). L'API mobile parle au **backend ERPNext natif** (`erpnext-backend-1`,
contrainte #1), jamais à un backend fictif. Les numéros de version d'Expo /
React / React Native cités proviennent de `AGENTS_EXISTING_ASSETS.md §8`
(upgrade daté 2026-07) et ne sont pas inventés.

## Non-négociables (voir CLAUDE.md racine pour la liste complète)
- Gitea only (jamais GitHub) — code app poussé sur `michel/oto-enterprise-os-dtp`
- **ERPNext natif en priorité absolue** — l'API mobile s'appuie dessus, pas d'ERP tiers
- Score 4Big 95+/100
- **Zéro invention** de chiffres — versions Expo/RN sourcées §8, jamais devinées (#6)
- **VPS/EAS/stores pour tous projets** — le worker n'écrit jamais sur le serveur ni ne build en local (#8)
- Vérifier · Investiguer · Valider · Confirmer

## Livrable attendu · roadmap
Voir `04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md`. Volet Mobile : **Sprint 5**
(« Rebuild **Expo 54** + submit **App Store #32** + **Play Store** »). Cible de
sprint mesurable : **apps mobile live sur les 2 stores** (deliverable S5, L58),
gatée par la row d'acceptation QA **S5**. État courant (table roadmap L18) :
modules RBAC + API + Expo 54 en place, builds/submissions ~**50 %**.

## Coordination inter-agents
- **ERPNext Backend** : porteur du rôle RBAC `OTO Plateforme Mobile` (perm
  `API Access`) et du backend natif que l'API mobile consomme ; amont direct.
- **Frontend Console** : partage les **design tokens luxury** dark+doré
  (`#0a0a12` + `#f0b429`) pour la cohérence brand mobile ↔ web.
- **DevOps** : Docker `erpnext-backend-1` (backend cible de l'API), Gitea pour le
  code app ; pattern systemd réutilisé si un worker mobile est requis.
- **QA** : maintient la row d'acceptation **S5** (builds/submits = critères
  `out_of_scope` tant que non exécutés).
- **SEO / Publiciste** : liens de téléchargement app relayés depuis le site
  public une fois les apps live.

## Communication inter-agents
- Rapports quotidiens dans `05_deliverables_mvp/daily_reports/`
- Hand-off inter-agents = livrables déterministes commités in-repo (fixtures/specs `out/`, SPEC, README), consommés directement par l'agent destinataire
- Blockers escalés à Michel Roy via WhatsApp +18296296385

## Éthique
- Sensibilité culturelle FR/EN/ES + RD
- Voix Amélie QC (multilingual_v2) pour toute interaction OTOIA
- Respect brand luxury dark+doré partout

## Ressources OTOV7 déjà en place (À RÉUTILISER, ne pas dupliquer)
Voir le fichier maître : `/opt/oto/claude_code_mandate_dtp/AGENTS_EXISTING_ASSETS.md` section 8 (Mobile Agent).

**Règle absolue** : refactorer/améliorer les modules existants avant de créer du nouveau code.