# Plan de releases — SIOP V2

> **Rôle de ce document (playbook)** : découper le produit en releases **fermées** — chaque
> release a un périmètre figé, une définition de fini (DoD) et se termine par une recette
> formelle + un déploiement. On n'ouvre pas Rn+1 avant la clôture de Rn. C'est l'antidote
> à la dérive de périmètre constatée en v1.

## Définition de fini (DoD) commune à toutes les releases

1. Toutes les stories de la release recettées (critères d'acceptation × preuves).
2. CI verte : lint, typecheck, tests (couverture API ≥ 70 % bloquante), contrat OpenAPI à jour.
3. **Revue pixel** : les écrans livrés sont conformes aux maquettes validées.
4. Déployé en production (Dokploy) et vérifié en ligne.
5. Chapitre(s) de playbook de la release relus par le référent.
6. Journal + tag git `release/rX`.

## R0 — Fondations *(aucun écran métier)*

**But** : tout ce qui rend les releases suivantes rapides et propres.

- Playbook 00-vision, 01-cadrage, 02-design (charte + tokens + **maquettes HD validées**), 03-architecture (ADRs, C4, modèle de données).
- Monorepo pnpm/Turborepo, infra Docker locale (PostgreSQL + Redis + MinIO), CI (4 pipelines : node, contrat, python, e2e).
- `apps/api` : auth JWT, matrice de permissions (7 rôles × objets × droits, en base), seed réaliste (parc d'ascenseurs de démonstration).
- **Sélecteur de compte démo** (`DEMO_MODE=true`) : bascule de rôle en < 3 s, local et démo, jamais en prod réelle.
- `apps/web` : coquille applicative (login, layout, navigation, design system appliqué, page vitrine du design system).
- Déploiement Dokploy « hello SIOP » (l'app en ligne dès R0).

**Hors R0** : tout écran métier.

## R1 — Référentiel

Sites/emplacements (hiérarchie + carte), ascenseurs + organes (hiérarchie, statuts, QR
imprimable), catégories, personnes & équipes (invitation, activation, profils).
**Recette type** : créer un site → un ascenseur → ses organes → imprimer l'étiquette QR →
inviter un technicien.

## R2 — Exploitation

Ordres de travail (machine à états, priorités dont **« personne bloquée »**, assignation,
commentaires, pièces jointes), **bilan codé** (6 champs + référentiels administrables +
garde de clôture), portail de demandes (public via QR + interne) convergeant vers l'OT,
préventif (gabarits à périodicité, génération mensuelle idempotente, checklist, premier
contrôle), compteurs.
**Recette type** : demande gardien → approbation → OT → intervention → bilan codé →
clôture → suivi demandeur ; génération du préventif de juillet.

## R3 — Gestion

Stock (mouvements, seuils, alertes), consommation sur OT à prix figé, bons de commande,
tiers, main-d'œuvre valorisée (taux figé) et coût total OT, analytics (KPI + graphiques),
bibliothèque de fichiers (documents rattachables).
**Recette type** : consommer sous seuil → BC → réception → réappro ; coût complet d'un OT ;
tableau de bord direction.

## R4 — Mobile technicien

App Expo offline-first : OT assignés, fiche, scan QR → fiche ascenseur, checklist du mois
cochable hors-ligne, clôture terrain, synchro à verrou optimiste (patron validé en v1).
**Recette type** : mode avion en sous-sol → cocher la grille → retour réseau → synchro.

## R5 — IA

Assistant RAG (notices + historiques ingérés, réponses **citant leurs sources**), aide à
la saisie du bilan (suggestion de codes à partir d'une description libre). Si budget temps :
transcription vocale du bilan. Principe : l'IA propose, l'humain valide.
**Recette type** : « quel couple de serrage pour les guides du Gen2 ? » → réponse sourcée.

## Après v1 (backlog v2)

PV PDF signé hors-ligne, check-in/out géolocalisés, agent vocal, affectation géospatiale
automatique, multi-langue, exports comptables.