docs(r0): kickoff SIOP V2 — vision, cadrage, charte graphique, maquettes HD

Refondation design-first du projet SIOP (v1 gelée) :
- Playbook 00-vision (charte projet, personas, benchmark Atlas)
- Playbook 01-cadrage (releases R0→R5 + DoD, user-story map, exigences, risques)
- Playbook 02-design : charte graphique, tokens.css bi-thème (palettes
  analytics validées CVD/contraste par script), maquettes HD navigables
  (7 écrans dont démo-login DEMO_MODE, bilan codé, portail QR, mobile)

Prochaine étape : validation des maquettes par le référent avant tout code.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/00-vision/benchmark-atlas.md

@@ -0,0 +1,55 @@
+# Benchmark — Atlas CMMS et adaptation ascenseurs
+
+> **Rôle de ce document (playbook)** : avant de concevoir, on étudie l'état de l'art. Ici,
+> [Atlas CMMS](https://github.com/grashjs/cmms) (GMAO open source, Spring Boot + React) est
+> notre référence fonctionnelle : on liste ce qu'on **reprend**, ce qu'on **adapte** au
+> métier ascenseur, ce qu'on **écarte**, et nos **différenciateurs**.
+
+## 1. Ce qu'Atlas fait bien (repris tel quel, réimplémenté dans notre stack)
+
+| Module Atlas | Reprise SIOP | Release |
+| --- | --- | --- |
+| Work Orders (statuts, priorités, assignés, coûts) | Ordres de travail, machine à états stricte | R2 |
+| Requests (portail + approbation → WO) | Demandes convergeant vers l'OT (lien 1-1) | R2 |
+| Preventive Maintenance (triggers) | Génération périodique d'OT avec checklist | R2 |
+| Assets + hiérarchie | Ascenseurs + **organes** (hiérarchie 2 niveaux) | R1 |
+| Locations | Sites/emplacements + carte | R1 |
+| Parts & Inventory / Purchase Orders | Stock dérivé des mouvements, BC, seuils | R3 |
+| People & Teams, rôles/permissions | Matrice rôles × objets × droits, en base | R0 |
+| Vendors & Customers | Tiers unifiés | R3 |
+| Files | Bibliothèque de documents rattachables | R3 |
+| Analytics | Tableau de bord KPI + agrégations SQL | R3 |
+| Mobile app | App technicien Expo offline-first | R4 |
+
+## 2. Ce qu'on adapte au métier ascenseur (le cœur de la valeur)
+
+| Spécificité métier (source : carnet SPELEV) | Traduction produit |
+| --- | --- |
+| **Bilan d'intervention codé** (6 champs à valeurs codifiées : état portes, position cabine, anomalie, cause extérieure, action, élément) | Référentiels administrables + garde de clôture : pas d'OT terminé sans bilan valide |
+| **Périodicités réglementaires** calées calendrier (mensuel → annuel, ancrage au mois — ex. parachute en juillet) | Gabarits de tâches à périodicité + génération mensuelle idempotente + « premier contrôle = tout » |
+| **Grille du mois** cochée en cabine | Checklist embarquée sur l'OT préventif, cochable hors-ligne sur mobile |
+| **PV contradictoire signé** (technicien + client) | Signatures tactiles + PDF fidèle au carnet, générable hors connexion (post-v1 : R5+) |
+| **Urgence « personne bloquée »** | Priorité dédiée, circuit court (alerte immédiate, pas de validation préalable) |
+| **Étiquette QR en cabine** | QR = URL canonique de la fiche → signalement prérempli (public) et fiche technicien (mobile) |
+
+## 3. Ce qu'on écarte (v1)
+
+- Multi-tenant SaaS, facturation, abonnements (Atlas est un produit commercial hébergé).
+- Workflows configurables génériques — nos flux métier sont fixés par le métier.
+- Intégrations tierces (SAP, IoT…) — hors périmètre v1.
+
+## 4. Nos différenciateurs (au-delà d'Atlas)
+
+1. **IA** (R5) : assistant RAG citant ses sources (notices, historiques), aide à la saisie
+   du bilan ; principe « l'IA propose, l'humain valide ».
+2. **Design métier** : interface pensée pour les personas ascensoristes (gros statuts,
+   urgences visibles, terminologie du carnet) — pas une GMAO générique habillée.
+3. **DX/démo** : sélecteur de compte démo 1 clic (`DEMO_MODE`) — essentiel pour la
+   démonstration commerciale ET le développement.
+
+## 5. Choix de stack face à Atlas
+
+Atlas = Java Spring Boot + React (MUI). Nous **ne clonons pas la stack**, seulement le
+fonctionnel : notre stack TypeScript de bout en bout (NestJS/React/Expo) + FastAPI pour
+l'IA est plus cohérente pour une équipe unique et l'enseignement (un seul langage principal).
+Décision motivée en ADR-001.