Docs/t0003 strategie refonte

docs/ARCHITECTURE.md

@@ -61,12 +61,29 @@ Supabase
 ### Supabase
 
 - Identité et autorisation.
+- Ownership MVP limité côté serveur à un propriétaire par compagnie et au plus
+  une compagnie par utilisateur.
+- Identité de compagnie distincte de l'identité utilisateur, sans droit
+  collaboratif implicite.
 - Commandes sensibles transactionnelles et idempotentes.
 - Grand livre immuable et projections.
 - RLS défensive sur chaque table exposée.
 - Audit des changements sensibles.
 - Traitements passifs côté serveur, indépendants d'un client ouvert.
 
+## Stratégie de construction
+
+Conformément à `ADR-0002`, l'architecture cible sera construite par réécriture
+totale dans un nouveau dépôt et un historique Git neuf. Le dépôt actuel reste une
+référence en lecture seule pour les comportements, l'UX et la documentation
+jusqu'à validation de la parité du golden path, puis il est archivé.
+
+Il n'existe aucune coexistence en production, aucune double lecture/écriture et
+aucune compatibilité avec l'ancien schéma. Le nouveau dépôt utilise des branches
+courtes, une intégration fréquente et une CI obligatoire. Le premier vertical
+slice critique est le moteur de vol SimConnect rejouable jusqu'au rapport
+versionné.
+
 ## Organisation cible
 
 ```text
@@ -100,8 +117,10 @@ docs/
   templates/
 ```
 
-La migration vers cette organisation est progressive et pilotée par tickets.
-Aucun « big bang » de déplacement sans tests de caractérisation.
+Cette organisation appartient au nouveau dépôt. Aucun code n'y est déplacé
+depuis le dépôt actuel sans ticket de caractérisation et preuve de qualité,
+sécurité, provenance et licence. La réécriture reste pilotée par gates et tests
+de caractérisation malgré l'absence de migration de code.
 
 ## Données
 
@@ -130,9 +149,16 @@ Aucun « big bang » de déplacement sans tests de caractérisation.
 
 ## Décisions encore ouvertes
 
-- Solo connecté ou VA collaborative.
 - HTTP localhost renforcé ou named pipe Windows pour le bridge.
 - Cache SQLite local et données autorisées hors ligne.
 - Stratégie d'anti-triche proportionnée.
 - Fournisseur de crash reporting et consentement.
 
+## Décisions acceptées
+
+- `ADR-0001` : MVP solo connecté, un propriétaire unique et au plus une
+  compagnie par utilisateur ; modèle préparé pour une collaboration ultérieure,
+  sans membre ni rôle collaboratif dans le MVP.
+- `ADR-0002` : réécriture totale isolée dans un nouveau dépôt ; ancien dépôt
+  conservé comme référence en lecture seule, nouveau schéma sans migration des
+  données de développement et une seule bascule publique après parité.

docs/CURRENT_STATE.md

@@ -1,6 +1,6 @@
 # État actuel du dépôt
 
-Dernière revue documentaire : 24 juillet 2026 (ticket T0001).  
+Dernière revue documentaire : 24 juillet 2026 (ticket T0003).
 Statut : baseline locale vérifiée ; validations externes encore requises.
 
 ## Produit
@@ -139,7 +139,8 @@ explicite. Ces échecs sont classés comme environnement, pas comme défauts du
   atomiques.
 - Pas de pipeline complet de release signée/updater.
 - Versions répétées dans plusieurs manifestes.
-- Modèle solo ou VA collaborative non tranché.
+- Politique de suppression/récupération du propriétaire et durée de rétention à
+  définir avant toute suppression irréversible.
 
 ## Travail local à préserver
 
@@ -149,11 +150,29 @@ pendant T0001. Son empreinte SHA-256 avant et après validation est
 Les autres modifications utilisateur préexistantes n'ont pas été intégrées au
 ticket.
 
+## Décision produit
+
+`ADR-0001` retient un MVP solo connecté préparé pour une collaboration
+ultérieure : au plus une compagnie par utilisateur, un propriétaire humain
+unique, aucun membre ni rôle collaboratif dans le MVP. La collaboration probable
+après le MVP exigera une nouvelle ADR.
+
+## Décision de refonte
+
+`ADR-0002` retient une réécriture totale isolée dans un nouveau dépôt avec un
+historique Git neuf. Le dépôt actuel devient une référence en lecture seule pour
+l'UX, les comportements et la documentation jusqu'à parité du golden path, puis
+il sera archivé. Le nouveau produit utilise un schéma Supabase neuf : les données
+actuelles sont uniquement des données de développement et ne seront pas migrées.
+Il n'y aura ni coexistence en production, ni double écriture, ni ancien client
+connecté au nouveau backend. Une seule bascule publique est prévue après les
+gates de caractérisation, SimConnect, parité, restauration et distribution.
+
 ## Prochain ticket recommandé
 
-`T0002 — Choisir le modèle produit solo ou collaboratif`. Cette décision précède
-le schéma cible, les rôles, les politiques RLS et la stratégie de refonte. La
-matrice Windows/MSFS sera traitée ensuite dans T0004.
+Créer et exécuter un ticket borné de caractérisation du golden path et des traces
+SimConnect avant le nouveau socle. La matrice Windows/MSFS reste planifiée dans
+T0004.
 
 ## Mise à jour de ce fichier
 

docs/KNOWN_ISSUES.md

@@ -21,12 +21,14 @@ Statut : `Open`, `Accepted`, `Scheduled`, `Resolved`, `Invalid`.
 | KI-004 | Medium | Bridge | Pas de projet de tests .NET/replay SimConnect constaté. | Audit initial | Phase 3 | Open |
 | KI-005 | Medium | Frontend | Plusieurs pages mélangent UI, règles et accès aux données. | Audit initial | Phase 4 | Open |
 | KI-006 | Medium | Docs | Documentation historique partiellement désynchronisée. | Audit initial | T0001 | Open |
-| KI-007 | Medium | Product | Mode solo ou VA collaborative non tranché. | Audit initial | T0002 | Open |
+| KI-007 | Medium | Product | Mode solo ou VA collaborative non tranché. | ADR-0001 : MVP solo préparé pour collaboration ultérieure | T0002 | Resolved |
+| KI-008 | High | Rebuild | Une réécriture totale peut omettre des comportements actuels non caractérisés. | ADR-0002 : couverture automatisée faible face au périmètre existant | Caractérisation du golden path | Open |
+| KI-009 | High | Bridge | Aucun corpus de traces SimConnect rejouables n'est fourni pour prouver la parité du moteur de vol. | T0001 et ADR-0002 | Premier vertical slice SimConnect | Open |
+| KI-010 | High | Release | Après création de données réelles dans le nouveau schéma, aucun retour vers l'ancien produit ne sera possible. | ADR-0002 : nouveau schéma sans compatibilité descendante | Phase 6 | Accepted |
 
 ## Règles
 
 - Ajouter une preuve reproductible.
 - Lier à un ticket lorsqu'il devient planifié.
 - Ne pas résoudre discrètement un problème hors scope.
 - Retirer une entrée uniquement si son historique reste traçable dans un ticket.
-

docs/PRODUCT.md

@@ -23,15 +23,22 @@ compagnie sans perdre les données ni pouvoir falsifier facilement son économie
 Un passionné de simulation qui gère sa propre compagnie et effectue lui-même des
 vols dans MSFS.
 
-## Décision produit requise
+## Modèle produit retenu
 
-Avant le schéma final, choisir explicitement :
+Le MVP est **solo connecté, préparé pour une collaboration ultérieure**,
+conformément à `ADR-0001`.
 
-- **Solo connecté** : une compagnie appartient à un utilisateur ;
-- **VA collaborative** : plusieurs membres, rôles, invitations et pilotes.
+- Un utilisateur possède au plus une compagnie.
+- Une compagnie a exactement un propriétaire humain.
+- Le propriétaire est le seul à voir et gérer les vols, finances, flotte et
+  horaires de sa compagnie.
+- Aucun membre, rôle supplémentaire, invitation, partage ou transfert de
+  propriété n'est livré dans le MVP.
+- L'identité de la compagnie reste distincte de celle du propriétaire afin de ne
+  pas bloquer une évolution future.
 
-La phase de fondation part du mode solo tant qu'une ADR n'adopte pas le mode
-collaboratif. Ne pas ajouter partiellement du multi-utilisateur.
+La collaboration est probable après le MVP, mais elle nécessitera une nouvelle
+ADR. Ne pas ajouter partiellement du multi-utilisateur.
 
 ## Parcours essentiels
 
@@ -60,6 +67,9 @@ collaboratif. Ne pas ajouter partiellement du multi-utilisateur.
 ## Hors MVP
 
 - Réseau social, marketplace communautaire et mods.
+- Membres de compagnie, rôles collaboratifs, invitations et transfert de
+  propriété.
+- Vols, finances, flotte ou horaires partagés entre plusieurs humains.
 - Application mobile.
 - Tableau de bord web public.
 - Multi-VA complexe.
@@ -82,4 +92,3 @@ collaboratif. Ne pas ajouter partiellement du multi-utilisateur.
 - Reprise après coupure testée sur chaque parcours essentiel.
 - Temps de démarrage et consommation mémoire budgétés.
 - Mise à jour N-1 → N et rollback validés sur VM propre.
-

docs/ROADMAP.md

@@ -8,18 +8,23 @@ détails d'exécution appartiennent aux tickets.
 Objectif : rendre l'existant mesurable et décider ce que l'on reconstruit.
 
 - Inventaire reproductible, tests/builds et matrice de dépendances.
-- Décision solo connecté vs VA collaborative.
+- Décision du modèle produit : MVP solo connecté préparé pour une collaboration
+  ultérieure (`ADR-0001`, acceptée).
 - Matrice Windows/MSFS supportée.
 - Budgets stabilité/performance et politique de données.
-- Choix : réécriture incrémentale ou remplacement par strangler pattern.
+- Stratégie acceptée : réécriture totale isolée dans un nouveau dépôt
+  (`ADR-0002`), sans migration des données de développement.
 - Environnements dev/staging/prod documentés.
 
-Gate : baseline verte ou écarts connus, ADR majeures acceptées, périmètre MVP gelé.
+Gate : baseline verte ou écarts connus, ADR majeures acceptées, périmètre MVP
+gelé et golden path à caractériser identifié.
 
 ## Phase 1 — Socle reproductible
 
-Objectif : pouvoir reconstruire et tester le produit à tout moment.
+Objectif : créer dans le nouveau dépôt un socle reconstruisible et testable à
+tout moment.
 
+- Nouveau dépôt, historique neuf, règles de branches courtes et CI obligatoire.
 - Versions/outils supportés et bootstrap automatisé.
 - Source de version unique.
 - CI consolidée et actions épinglées.
@@ -37,21 +42,22 @@ Objectif : empêcher corruption, doubles opérations et calculs client autoritai
 - Commandes transactionnelles/idempotentes.
 - RLS A/B/anonyme.
 - Concurrence optimiste et audit.
-- Migration/reconciliation des données existantes.
+- Nouveau schéma créé depuis zéro avec seeds synthétiques et restauration testée.
 
 Gate : aucune mutation sensible directe depuis un composant client.
 
 ## Phase 3 — Bridge et moteur de vol stables
 
 Objectif : rendre la détection de vol déterministe et récupérable.
 
+- Premier vertical slice critique de la réécriture.
 - Domaine indépendant de SimConnect.
 - Replays de traces et projet de tests .NET.
 - Reconnexion, pause, slew, go-around, touch-and-go et crash.
 - Canal local durci et cycle de vie robuste.
 - Rapport de vol versionné et outbox de reprise.
 
-Gate : parcours critiques reproductibles sans lancer MSFS.
+Gate : traces représentatives rejouées sans MSFS jusqu'à un rapport versionné.
 
 ## Phase 4 — Application cliente maintenable
 
@@ -64,7 +70,8 @@ Objectif : reconstruire l'UX sur des fondations testables.
 - États offline/pending/rejected explicites.
 - Accessibilité et design system.
 
-Gate : golden path E2E stable et aucun écran critique monolithique.
+Gate : golden path E2E auth → compagnie → flotte → dispatch → vol → rapport →
+grand livre stable et aucun écran critique monolithique.
 
 ## Phase 5 — Opérations passives et progression
 
@@ -100,11 +107,18 @@ Objectif : mesurer en conditions réelles sans ajouter de fonctionnalités.
 
 Gate : deux releases consécutives respectent les objectifs de stabilité.
 
+## Bascule et archivage de l'ancien dépôt
+
+Il n'y a qu'une bascule publique, après validation des gates de caractérisation,
+socle, SimConnect, parité du golden path, recréation/restauration des données et
+distribution signée. L'ancien client n'accède jamais au nouveau backend. Le dépôt
+actuel est archivé seulement après acceptation de cette parité par Andy.
+
 ## Phase 8 — Après stabilité
 
-- Collaboration multi-rôle si décidée.
+- Nouvelle ADR puis collaboration multi-rôle si le besoin probable est confirmé ;
+  aucun parcours collaboratif ne fait partie du MVP.
 - Tableau de bord web.
 - Import/export avancé.
 - Administration et audit étendu.
 - Modding avec permissions/signatures dédiées.
-