diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md index 41bab5c..ec4d90c 100644 --- a/docs/ARCHITECTURE.md +++ b/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é. diff --git a/docs/CURRENT_STATE.md b/docs/CURRENT_STATE.md index 4cf6e9d..7fceb57 100644 --- a/docs/CURRENT_STATE.md +++ b/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 diff --git a/docs/KNOWN_ISSUES.md b/docs/KNOWN_ISSUES.md index fdbfd81..564a818 100644 --- a/docs/KNOWN_ISSUES.md +++ b/docs/KNOWN_ISSUES.md @@ -21,7 +21,10 @@ 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 @@ -29,4 +32,3 @@ Statut : `Open`, `Accepted`, `Scheduled`, `Resolved`, `Invalid`. - 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. - diff --git a/docs/PRODUCT.md b/docs/PRODUCT.md index 9f9f7e3..1c60256 100644 --- a/docs/PRODUCT.md +++ b/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. - diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index e97e510..4e29907 100644 --- a/docs/ROADMAP.md +++ b/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,7 +42,7 @@ 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. @@ -45,13 +50,14 @@ Gate : aucune mutation sensible directe depuis un composant client. 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. - diff --git a/docs/decisions/ADR-0001-modele-produit.md b/docs/decisions/ADR-0001-modele-produit.md new file mode 100644 index 0000000..27c456b --- /dev/null +++ b/docs/decisions/ADR-0001-modele-produit.md @@ -0,0 +1,211 @@ +# ADR-0001 — Modèle produit solo préparé pour une collaboration ultérieure + +Status: Accepted +Date: 2026-07-24 +Deciders: Andy (Product Owner) +Supersedes: — +Superseded by: — + +## Context + +Thrustline doit choisir son modèle de propriété avant de figer son schéma cible, +ses politiques RLS et son parcours d'onboarding. L'application actuelle est +principalement solo, tandis qu'une VA collaborative imposerait dès le MVP des +adhésions, rôles, invitations, révocations, conflits d'édition et audits +supplémentaires. + +Andy considère la collaboration future comme probable, mais donne la priorité à +la stabilité. Après clarification, le MVP ne doit accueillir qu'un humain par +compagnie. Il ne doit exposer aucun parcours collaboratif, tout en évitant un +modèle de données qui rendrait une migration future inutilement destructive. + +## Decision drivers + +Les poids suivants ont été approuvés par Andy : + +| Critère | Poids | +| --- | ---: | +| Adéquation à la vision d'Andy | 20 % | +| Rapidité jusqu'à une bêta stable | 20 % | +| Simplicité et fiabilité | 15 % | +| Sécurité et maîtrise des permissions | 15 % | +| Expérience solo | 10 % | +| Potentiel communautaire | 5 % | +| Coût d'hébergement et de support | 5 % | +| Capacité d'évolution | 10 % | + +La stabilité prime sur la collaboration en cas de conflit. + +## Options considered + +### Option 1 — Solo connecté sans préparation collaborative + +Un utilisateur crée, possède et gère seul une compagnie. Le MVP ne contient ni +membre, ni rôle, ni invitation. Toutes les ressources sont rattachées directement +à ce propriétaire. + +- **MVP et UX** : onboarding court et aucune administration de membres. +- **Propriété et permissions** : un propriétaire unique ; données visibles par + lui seul ; RLS principalement fondée sur son identité. +- **Audit, concurrence et exploitation** : surface minimale, sans concurrence + entre humains sur une même compagnie. +- **Sécurité** : moindre risque d'élévation de rôle ou de fuite entre membres ; + l'isolation entre propriétaires reste obligatoire. +- **Coût et délai** : option la moins coûteuse et la plus rapide. +- **Migration** : une collaboration ultérieure risque d'exiger une migration + intrusive si l'identité utilisateur est utilisée partout comme clé de + propriété. + +### Option 2 — VA collaborative dès le MVP + +Plusieurs utilisateurs partagent une compagnie. Le MVP doit alors fournir +membres, invitations, révocations, transfert de propriété et rôles tels que +propriétaire, administrateur, dispatcher et pilote. + +- **MVP et UX** : onboarding solo plus administration complète d'une VA. +- **Propriété et permissions** : compagnie distincte de ses membres, permissions + par rôle et appartenance vérifiée côté serveur. +- **Audit, concurrence et exploitation** : journal des actions sensibles, + notifications, révocation immédiate et résolution des modifications + concurrentes. +- **Sécurité** : risques supplémentaires d'élévation de rôle, d'invitation ou de + transfert forgé, d'accès persistant d'un ancien membre et d'exposition de + données. +- **Coût et délai** : tests RLS et scénarios d'exploitation nettement plus + nombreux avant une bêta fiable. +- **Migration** : offre immédiatement le meilleur potentiel communautaire, au + prix d'une complexité non nécessaire au parcours principal actuel. + +### Option 3 — Solo connecté, structure préparée pour une extension collaborative + +Le comportement du MVP reste strictement solo : un utilisateur possède une +compagnie et aucun autre humain ne peut la rejoindre. Le modèle persistant doit +cependant distinguer l'identité de la compagnie de celle du propriétaire et +permettre d'ajouter plus tard une relation d'appartenance sans réécrire les +ressources métier. + +- **MVP et UX** : mêmes parcours visibles que l'option solo ; aucune invitation, + liste de membres ou permission par rôle. +- **Propriété et permissions** : un propriétaire unique et une seule compagnie + par utilisateur dans le MVP. Les contraintes serveur doivent faire respecter + ces cardinalités. +- **Audit, concurrence et exploitation** : pas de concurrence multi-humain dans + le MVP ; commandes sensibles toujours transactionnelles et auditables. +- **Sécurité** : l'autorisation reste strictement limitée au propriétaire. Une + structure extensible ne doit jamais créer de droits collaboratifs implicites. +- **Coût et délai** : léger coût de modélisation supplémentaire, sans le coût des + fonctionnalités collaboratives. +- **Migration** : une future ADR pourra ajouter membres et rôles autour de + l'identité stable de la compagnie, avec migrations append-only. + +## Decision matrix + +Notes de 1 (défavorable) à 5 (très favorable). Le total est la moyenne pondérée +sur 5. + +| Critère | Poids | Solo direct | VA collaborative | Solo préparé | +| --- | ---: | ---: | ---: | ---: | +| Adéquation à la vision | 20 % | 4 | 3 | 5 | +| Rapidité vers une bêta stable | 20 % | 5 | 2 | 4 | +| Simplicité et fiabilité | 15 % | 5 | 2 | 4 | +| Sécurité et permissions | 15 % | 5 | 2 | 4 | +| Expérience solo | 10 % | 5 | 3 | 5 | +| Potentiel communautaire | 5 % | 1 | 5 | 3 | +| Coût d'hébergement et de support | 5 % | 5 | 2 | 4 | +| Capacité d'évolution | 10 % | 2 | 5 | 5 | +| **Total pondéré** | **100 %** | **4,30** | **2,75** | **4,35** | + +Le solo direct est légèrement plus simple à court terme, mais sa faible capacité +d'évolution le place derrière le solo préparé. La VA collaborative maximise le +potentiel communautaire, mais dégrade les critères prioritaires de stabilité, +sécurité et délai. + +## Decision + +**Thrustline livrera un MVP solo connecté dans lequel un utilisateur possède et +gère exactement une compagnie, avec un modèle de données préparé pour une +collaboration ultérieure mais aucune fonctionnalité collaborative exposée.** + +Règles du MVP : + +- cardinalité utilisateur ↔ compagnie : `0..1` compagnie possédée par utilisateur + et exactement `1` propriétaire humain par compagnie ; +- seul rôle disponible : `owner` ; +- seul le propriétaire voit et modifie les vols, finances, flotte et horaires de + sa compagnie ; +- aucun autre humain ne peut préparer ou effectuer un vol pour cette compagnie ; +- aucune invitation, adhésion, liste de membres, exclusion, suspension ou + transfert de propriété ; +- le produit reste entièrement jouable seul, sans gestion de membres ; +- l'identité stable de la compagnie est distincte de l'identité du propriétaire ; +- toute structure interne préparant l'avenir reste contrainte à un propriétaire + unique et ne confère aucun accès supplémentaire. + +Si le propriétaire demande la suppression de son compte, la compagnie entre dans +le futur processus de suppression et de récupération des données. Elle est +supprimée après un délai, mais la durée, les données auditables conservées et les +obligations de rétention seront définies dans un ticket ultérieur de politique de +données. Aucune suppression irréversible ne doit être implémentée avant cette +décision. + +Sont explicitement reportés après le MVP : + +- membres humains supplémentaires ; +- rôles administrateur, dispatcher et pilote ; +- vols préparés ou effectués par un autre membre ; +- finances, flotte et horaires partagés en temps réel ; +- invitations, demandes d'adhésion et annuaire de membres ; +- exclusion, suspension et révocation de membre ; +- transfert de propriété ; +- appartenance d'un utilisateur à plusieurs compagnies. + +Une future collaboration nécessitera une nouvelle ADR. Elle devra définir les +cardinalités, rôles, permissions, invitations, révocations, transfert de +propriété, concurrence, audit, notifications et rétention avant toute +implémentation. + +## Consequences + +### Positive + +- Le golden path reste centré sur l'utilisateur principal décrit dans la vision. +- La surface d'autorisation et de tests inter-utilisateurs du MVP reste bornée. +- Le risque d'une collaboration partielle et incohérente est éliminé. +- Les ressources métier peuvent conserver une identité de compagnie stable lors + d'une future extension. + +### Negative + +- Le produit ne peut pas servir de VA multi-pilotes dans son MVP. +- La structure préparatoire ajoute un faible coût sans bénéfice visible immédiat. +- La politique exacte de suppression du propriétaire reste à décider avant son + implémentation. + +### Risks and mitigations + +- **Accès à une autre compagnie** : identité déduite du JWT, ownership vérifié + côté serveur, RLS et tests utilisateur A/utilisateur B/anonyme. +- **Élévation de rôle côté client** : aucun rôle fourni par le client ne fait + autorité ; seul `owner` existe dans le MVP. +- **Faux support collaboratif** : aucune ligne ou relation préparatoire ne doit + permettre un second humain ; contrainte serveur et tests négatifs obligatoires. +- **Compagnie orpheline** : aucune suppression ou désactivation du propriétaire + sans processus transactionnel conforme à la future politique de données. +- **Fraude financière ou de vol** : les commandes sensibles restent + transactionnelles, idempotentes et calculées côté serveur. +- **Migration future risquée** : identité de compagnie stable, migrations + append-only et déploiement de la collaboration seulement après une nouvelle + ADR et des tests RLS dédiés. + +## Validation + +- Reformuler la section `Decision` comme : « un compte peut posséder au plus une + compagnie et en est l'unique humain ; aucune collaboration n'est livrée dans le + MVP ». +- Vérifier que seul le propriétaire peut voir les finances, préparer et effectuer + un vol, ou acheter et vendre un avion. +- Vérifier qu'aucun écran ou contrat MVP ne suppose invitation, membre ou rôle + supplémentaire. +- Lors de l'implémentation du schéma, tester anonyme, propriétaire A et + propriétaire B, ainsi que le rejet d'un second propriétaire. +- Faire approuver une nouvelle ADR avant d'introduire toute collaboration. diff --git a/docs/decisions/ADR-0002-strategie-de-refonte.md b/docs/decisions/ADR-0002-strategie-de-refonte.md new file mode 100644 index 0000000..5b6e560 --- /dev/null +++ b/docs/decisions/ADR-0002-strategie-de-refonte.md @@ -0,0 +1,267 @@ +# ADR-0002 — Réécriture totale isolée + +Status: Accepted +Date: 2026-07-24 +Deciders: Andy (Product Owner) +Supersedes: — +Superseded by: — + +## Context + +Thrustline possède une alpha active couvrant déjà une part importante du produit, +mais sa couverture automatisée est faible au regard de ce périmètre. Aucun projet +de tests .NET ni test RLS A/B/anonyme n'a été constaté, plusieurs mutations +sensibles partent encore du client et les frontières métier sont mêlées à l'UI. + +Les données Supabase actuelles sont exclusivement des données de développement. +Il n'existe aucun utilisateur externe ni donnée de production à préserver. Andy +accepte leur suppression, une indisponibilité pendant la bascule, un gel des +fonctionnalités sans limite de durée prédéfinie et une livraison publique unique. +L'application actuelle n'a pas à rester utilisable pendant la refonte. Le nouveau +produit ne doit conserver ni le dépôt ni l'historique Git actuels. + +ADR-0001 impose toujours un MVP solo connecté, un propriétaire humain unique par +compagnie et au plus une compagnie par utilisateur. SimConnect reste le cœur du +produit et doit recevoir la priorité de caractérisation et de validation. + +## Decision drivers + +Andy a approuvé les poids suivants. Les notes vont de 1 (défavorable) à 5 (très +favorable). Pour « risque de double maintenance », une note élevée signifie un +risque faible. + +| Critère | Poids | +| --- | ---: | +| Stabilité pendant la refonte | 20 % | +| Conservation des données | 15 % | +| Sécurité | 15 % | +| Testabilité | 10 % | +| Capacité de rollback | 10 % | +| Vitesse de livraison | 10 % | +| Réduction de dette | 8 % | +| Faible risque de double maintenance | 5 % | +| Compréhension du système | 4 % | +| Compatibilité avec ADR-0001 | 3 % | + +La sécurité, le déterminisme du moteur de vol et l'absence de perte silencieuse +restent des conditions bloquantes indépendamment du score. + +## Options considered + +### Option 1 — Réécriture totale isolée + +Un nouveau dépôt et un historique Git neuf accueillent le produit cible. L'ancien +dépôt reste une référence en lecture seule jusqu'à la validation de la parité du +golden path, puis est archivé. Il n'existe qu'une implémentation destinée à la +production et une seule bascule publique. + +- **Dépôt et branches** : nouveau dépôt ; branches courtes et intégration + fréquente sur sa branche principale ; aucune branche de refonte longue dans + l'ancien dépôt. +- **Coexistence** : coexistence de développement seulement, sans exploitation + simultanée ni double maintenance fonctionnelle. +- **Régressions** : risque élevé d'oubli fonctionnel, compensé par des tests de + caractérisation, des replays SimConnect et une checklist de parité. +- **Données** : nouveau projet et nouveau schéma Supabase ; aucune migration de + production puisque les données actuelles sont jetables. +- **Dépendances** : liberté de construire un socle reproductible sans compatibilité + structurelle avec l'ancien dépôt. +- **Release** : une bascule après atteinte des gates ; retour possible au dernier + artefact candidat avant ouverture à des utilisateurs, mais aucun retour de + données vers l'ancien schéma. +- **Critère d'arrêt** : réévaluer la stratégie si la caractérisation ne permet pas + de définir le golden path ou si un actif irremplaçable sans preuve est découvert. + +### Option 2 — Refonte incrémentale dans la structure actuelle + +Le code est restructuré composant par composant dans le dépôt courant. + +- **Dépôt et branches** : historique conservé, branches courtes et migrations + internes successives. +- **Coexistence** : frontières anciennes et nouvelles mélangées pendant une + période longue. +- **Régressions** : comparaison locale plus facile, mais couplages cachés et + modifications opportunistes plus probables. +- **Données** : évolution du schéma existant par migrations append-only. +- **Dépendances** : mises à niveau contraintes par le socle courant. +- **Release** : rollback par petits incréments théoriquement plus simple, mais les + migrations et contrats doivent rester compatibles. +- **Critère d'arrêt** : abandon si les frontières ne peuvent être isolées sans + maintenir durablement deux modèles métier. + +### Option 3 — Remplacement progressif par tranches verticales + +Une nouvelle implémentation remplace les parcours un à un, avec routage ou +feature flags entre ancien et nouveau système. + +- **Dépôt et branches** : même dépôt ou dépôts coordonnés ; intégrations fréquentes. +- **Coexistence** : deux implémentations actives jusqu'à extinction de l'ancienne. +- **Régressions** : comparaison en conditions réelles efficace. +- **Données** : compatibilité, migration progressive ou double lecture/écriture + nécessaires. +- **Dépendances** : nouveau socle possible, mais contrats de transition coûteux. +- **Release** : rollback par tranche et kill switch possibles. +- **Critère d'arrêt** : abandon de la coexistence si le serveur ne peut garantir + une autorité unique ou si la double écriture menace l'intégrité. + +## Decision matrix + +| Critère | Poids | Totale isolée | Incrémentale | Strangler | +| --- | ---: | ---: | ---: | ---: | +| Stabilité pendant la refonte | 20 % | 3 | 3 | 4 | +| Conservation des données | 15 % | 5 | 4 | 5 | +| Sécurité | 15 % | 5 | 3 | 4 | +| Testabilité | 10 % | 5 | 3 | 4 | +| Capacité de rollback | 10 % | 2 | 4 | 5 | +| Vitesse de livraison | 10 % | 2 | 4 | 3 | +| Réduction de dette | 8 % | 5 | 3 | 4 | +| Faible risque de double maintenance | 5 % | 5 | 3 | 1 | +| Compréhension du système | 4 % | 4 | 3 | 5 | +| Compatibilité avec ADR-0001 | 3 % | 5 | 5 | 5 | +| **Total pondéré / 5** | **100 %** | **3,96** | **3,41** | **4,07** | + +Le strangler obtient le meilleur score brut grâce à son rollback et à sa +stabilité en production. Il n'est toutefois pas retenu : sans utilisateurs ni +données de production, ses mécanismes de coexistence, de compatibilité et de +double maintenance ne réduisent aucun risque utilisateur réel. Ils augmentent en +revanche la surface opérationnelle et prolongent l'exposition au modèle actuel. + +La réécriture totale isolée correspond aux contraintes explicites d'Andy et +maximise sécurité, testabilité et réduction de dette. Son risque principal est +la perte de comportements utiles ; les gates ci-dessous sont obligatoires pour +le maîtriser. + +## Existing assets disposition + +| Ensemble | Référence | Réutiliser | Adapter | Réécrire | Archiver | Preuve requise | +| --- | :---: | :---: | :---: | :---: | :---: | --- | +| UI et design | Oui | Non | Oui | Oui | Après parité | Inventaire d'écrans, captures et revue du golden path | +| Domaine/économie | Oui | Non | Non | Oui | Après tests équivalents | Tests de caractérisation puis invariants serveur | +| Bridge SimConnect | Oui | Non | Non | Oui | Après replays réussis | Traces représentatives et machine à états testée | +| Contrats REST/SignalR | Oui | Non | Non | Oui | Après tests de contrat | Schémas versionnés et tests des deux extrémités | +| Schéma et données Supabase | Oui | Non | Non | Oui | Oui | Nouveau schéma jetable, tests RLS A/B/anonyme | +| RLS/RPC/Edge Functions | Oui | Non | Non | Oui | Après équivalence | Tests négatifs, transactionnels et idempotents | +| Tests | Oui | Non | Oui | Oui | Avec l'ancien dépôt | Rejouer ou porter uniquement un test démontré pertinent | +| CI/release | Oui | Non | Oui | Oui | Après pipeline neuf | Clone propre et artefacts signés reproductibles | +| Assets et catalogues | Oui | Non | Oui | Si provenance absente | Après vérification | Licence, provenance, exactitude et format validés | +| Documentation | Oui | Non | Oui | Oui | Historique conservé | Revue contre le code et les décisions acceptées | +| `legacy/` | Oui | Non | Non | Non | Avec l'ancien dépôt | Consultation ponctuelle uniquement | + +« Non » à réutiliser signifie qu'aucun code n'est copié par défaut. Une exception +exige un ticket de caractérisation, une preuve de qualité, une provenance claire +et une revue sécurité/licence. + +## Decision + +Thrustline sera réécrit intégralement dans un nouveau dépôt avec un historique Git +neuf. Le dépôt actuel devient une référence fonctionnelle, visuelle et +documentaire en lecture seule ; il ne sert ni de socle, ni de dépendance, ni de +branche longue de refonte. + +Le nouveau dépôt utilise des branches courtes et une intégration fréquente avec +CI obligatoire. Il construit un nouveau projet Supabase et un schéma neuf. Les +données actuelles sont des données de développement jetables : elles ne sont ni +migrées, ni copiées, ni restaurées. Aucune double lecture, double écriture, +compatibilité ascendante avec l'ancien schéma ou feature flag entre les deux +applications n'est prévu. + +Il n'existe aucune coexistence en production. Une seule bascule publique aura +lieu lorsque les gates sont franchies. Avant cette bascule, les environnements, +domaines, secrets et identifiants de projet restent séparés. L'ancien client ne +doit jamais recevoir d'accès au nouveau backend. + +Le golden path minimal est : + +1. authentification et création atomique d'une compagnie solo ; +2. acquisition et consultation d'une flotte minimale ; +3. création d'un dispatch et préparation du vol ; +4. connexion à MSFS, suivi déterministe des phases et télémétrie bornée ; +5. reprise après déconnexion ou crash ; +6. génération d'un rapport et clôture unique du vol ; +7. écriture financière autoritaire dans un grand livre minimal ; +8. installation et mise à jour signées sans perte de données. + +SimConnect est le premier vertical slice critique. L'UI et le design actuels sont +adaptés comme référence d'expérience ; leur code n'est pas présumé réutilisable. +Les opérations passives, l'équipage avancé, les événements et la profondeur +économique reviennent après stabilité du golden path. + +## Data and rollback strategy + +- Les données actuelles sont jetables et aucune donnée externe n'existe. +- La suppression réelle des données ou du projet actuels n'appartient pas à + T0003 et nécessite une action explicitement autorisée dans un ticket futur. +- Le nouveau schéma est créé depuis zéro par migrations forward-only, + reproductibles et testées sur environnement jetable. +- Aucune fenêtre de migration, double écriture ou conservation de l'ancien format + n'est requise. +- Avant la première ouverture à des utilisateurs externes, les sauvegardes et une + restauration du nouveau backend doivent être testées. +- Avant la bascule publique, une régression ramène au dernier artefact candidat + sain et le backend de test peut être recréé. +- Après création de données réelles, aucun rollback vers l'ancien schéma n'est + possible. Les releases du nouveau produit devront utiliser des changements + compatibles et un rollback applicatif vers N-1, ou une correction forward. +- Une régression découverte après publication bloque les nouvelles commandes, + préserve les données du nouveau backend et déclenche rollback applicatif N-1 + seulement si son contrat reste compatible ; sinon, correction forward. + +## Gates + +| Gate | Preuves | Validation | Rollback | +| --- | --- | --- | --- | +| 1. Baseline de caractérisation | Golden path documenté, inventaire UI, traces SimConnect et invariants métier | Andy + reviewer | Compléter la caractérisation ; aucun nouveau socle dépendant | +| 2. Nouveau socle reproductible | Clone propre, builds/tests/CI et Supabase local jetable | Reviewer technique | Revenir au dernier commit vert du nouveau dépôt | +| 3. Premier vertical slice | Replay SimConnect déterministe jusqu'à un rapport versionné, sans MSFS | Reviewer bridge + Andy | Désactiver la slice ; aucun utilisateur externe | +| 4. Parité du golden path | E2E auth → compagnie → flotte → dispatch → vol → rapport → grand livre | Andy + reviewer | Refuser la bascule et corriger dans le nouveau dépôt | +| 5. Données répétées | Recréation complète du schéma, seeds et restauration d'une sauvegarde du nouveau backend | Reviewer données | Recréer l'environnement jetable | +| 6. Distribution signée | Installation propre, upgrade N-1 → N, signature, checksums et rollback applicatif | Andy sur VM + reviewer release | Conserver le dernier candidat signé sain | +| 7. Extinction de l'ancien | Gates 1–6 vertes, checklist de parité acceptée, nouvelle application seule autorisée sur le nouveau backend | Andy | Ne pas archiver tant qu'un écart bloquant subsiste | + +## Consequences + +### Positive + +- Le nouveau socle ne porte pas les couplages ni l'historique accidentel actuels. +- Les frontières de confiance et l'autorité serveur sont conçues avant les + fonctionnalités. +- L'absence de données réelles élimine le risque et le coût d'une migration de + production. +- Il n'y a ni double écriture, ni routage hybride, ni ancien client connecté au + nouveau backend. +- SimConnect et la reprise deviennent testables par replay avant reconstruction + de l'UI complète. + +### Negative + +- Aucune livraison fonctionnelle publique n'a lieu avant la parité du golden path. +- Les comportements non caractérisés peuvent être oubliés. +- Le nouveau dépôt perd la traçabilité Git directe de l'implémentation actuelle. +- Une réutilisation opportuniste est interdite tant qu'elle n'est pas justifiée. +- Après la bascule et l'arrivée de données réelles, le retour à l'ancien produit + est exclu. + +### Risks and mitigations + +- **Oubli fonctionnel** : inventaire, captures, tests de caractérisation et + validation manuelle de chaque étape du golden path. +- **Moteur de vol incorrect** : traces versionnées, replays déterministes et tests + de reconnexion, pause, slew, go-around, touch-and-go et crash. +- **Ancien client dangereux** : environnements séparés ; aucun secret du nouveau + backend dans l'ancien client ; révocation avant ouverture publique. +- **Copie de données sensibles** : aucune copie de l'ancien projet ; seeds + synthétiques uniquement. +- **Régression après bascule** : contrats compatibles, kill switch serveur pour + commandes sensibles, sauvegarde restaurée et rollback N-1 testé. +- **Divergence documentaire** : ancien dépôt figé comme référence datée ; le + nouveau dépôt devient l'unique source de vérité de l'implémentation. + +## Follow-ups + +1. Créer le ticket de caractérisation du golden path et des traces SimConnect. +2. Définir la matrice Windows/MSFS supportée. +3. Fixer les budgets de stabilité et de performance. +4. Créer explicitement le nouveau dépôt, ses règles de branches et son socle + reproductible ; T0003 n'autorise pas cette création. +5. Définir avant toute bêta la sauvegarde, la restauration, la rétention et le + rollback N-1 du nouveau produit. diff --git a/docs/tickets/README.md b/docs/tickets/README.md index 9e39daf..ec3fae8 100644 --- a/docs/tickets/README.md +++ b/docs/tickets/README.md @@ -15,14 +15,15 @@ Créer un fichier par ticket à partir de `docs/templates/TICKET.md`. | ID | Titre | Phase | Dépend de | Statut | | --- | --- | --- | --- | --- | | T0001 | Baseline reproductible et inventaire | 0 | — | Done | -| T0002 | Choisir le modèle produit solo ou collaboratif | 0 | T0001 | Ready | -| T0003 | ADR stratégie de refonte | 0 | T0001–T0002 | Draft | +| T0002 | Choisir le modèle produit solo ou collaboratif | 0 | T0001 | Done | +| T0003 | Choisir la stratégie de refonte | 0 | T0001–T0002 | Done | | T0004 | Matrice de support Windows/MSFS | 0 | T0001 | Draft | | T0005 | Budgets stabilité et performance | 0 | T0001 | Draft | | T0006 | Consolider CI et versions d'outils | 1 | T0003 | Backlog | | T0007 | Supabase local et tests RLS | 1 | T0003 | Backlog | | T0008 | Source de version unique | 1 | T0003 | Backlog | -T0002 est le prochain ticket exécutable. Les tickets suivants doivent être -affinés après sa décision pour éviter de figer une architecture fondée sur une -hypothèse produit. +T0003 a retenu par `ADR-0002` une réécriture totale isolée dans un nouveau dépôt. +Le prochain ticket à rendre Ready doit caractériser le golden path et constituer +les traces SimConnect avant toute création du nouveau socle. T0004 reste le +prochain ticket déjà répertorié dans ce backlog. diff --git a/docs/tickets/T0002-modele-produit-solo-ou-collaboratif.md b/docs/tickets/T0002-modele-produit-solo-ou-collaboratif.md index ff98fb5..90afe23 100644 --- a/docs/tickets/T0002-modele-produit-solo-ou-collaboratif.md +++ b/docs/tickets/T0002-modele-produit-solo-ou-collaboratif.md @@ -1,6 +1,6 @@ # T0002 — Choisir le modèle produit solo ou collaboratif -Status: Ready +Status: Done Owner: Andy Branch: `docs/t0002-modele-produit` Phase: 0 @@ -163,17 +163,17 @@ Après acceptation : ## Acceptance criteria -- [ ] Les dix questions produit ont reçu une réponse explicite ou sont marquées +- [x] Les dix questions produit ont reçu une réponse explicite ou sont marquées comme bloquantes. -- [ ] Les trois options sont comparées selon les mêmes critères. -- [ ] Les poids de la matrice sont approuvés par Andy. -- [ ] L'option retenue est formulée en une phrase sans ambiguïté. -- [ ] Les cardinalités, rôles, permissions et reports après MVP sont définis. -- [ ] Les principaux abus et risques de chaque option sont décrits. -- [ ] `ADR-0001` est `Accepted` et indique qui a pris la décision. -- [ ] `PRODUCT.md`, `ARCHITECTURE.md` et `ROADMAP.md` ne se contredisent plus. -- [ ] Aucun fichier applicatif, migration ou dépendance n'est modifié. -- [ ] Le prochain ticket recommandé est identifié. +- [x] Les trois options sont comparées selon les mêmes critères. +- [x] Les poids de la matrice sont approuvés par Andy. +- [x] L'option retenue est formulée en une phrase sans ambiguïté. +- [x] Les cardinalités, rôles, permissions et reports après MVP sont définis. +- [x] Les principaux abus et risques de chaque option sont décrits. +- [x] `ADR-0001` est `Accepted` et indique qui a pris la décision. +- [x] `PRODUCT.md`, `ARCHITECTURE.md` et `ROADMAP.md` ne se contredisent plus. +- [x] Aucun fichier applicatif, migration ou dépendance n'est modifié. +- [x] Le prochain ticket recommandé est identifié. ## Security review @@ -256,19 +256,88 @@ qui la marque `Superseded`. Ne pas réécrire silencieusement une décision acce À remplir après décision. +### Product answers recorded + +Réponses initiales d'Andy, puis clarification du 24 juillet 2026 : + +1. Plusieurs humains dès le MVP : réponse initiale oui, remplacée après + clarification par **non** ; choix final de l'option solo préparée. +2. Appartenance à plusieurs compagnies : non. +3. Rôles initiaux : propriétaire uniquement. +4. Vol préparé par un autre membre : réponse initiale oui, reportée après le MVP + par le choix final strictement solo. +5. Données partagées en temps réel : réponse initiale oui, reportée après le MVP. +6. Invitation, exclusion, suspension et transfert dans le MVP : non. +7. Jeu entièrement solo : oui. +8. Collaboration future : probable. +9. Surcoût maximal déclaré avant bêta : aucune limite imposée. +10. Priorité en cas de conflit : stabilité. +11. Nombre de compagnies possédées : une pour le moment. +12. Visibilité collaborative future envisagée : tous les membres. +13. Départ du propriétaire : suppression après un délai. +14. Aucun parcours de membre dans le MVP : oui. +15. Préparer le modèle interne pour une migration future : oui. +16. Poids proposés pour la matrice : approuvés. + +La durée de récupération/rétention après le départ du propriétaire est +explicitement renvoyée à un futur ticket. Les réponses initiales 1, 4 et 5 +étaient incompatibles avec l'absence de membres ; Andy a tranché en faveur du +MVP solo préparé. + ### Summary +Les trois modèles produit ont été comparés avec les poids approuvés par Andy. +ADR-0001 retient un MVP strictement solo dont le modèle persistant distingue la +compagnie de son propriétaire pour préparer une collaboration ultérieure. + ### Decision selected +MVP solo connecté : un utilisateur possède au plus une compagnie, une compagnie +a un propriétaire humain unique et aucune fonctionnalité collaborative n'est +livrée. Une future collaboration nécessitera une nouvelle ADR. + ### Files changed +- `docs/decisions/ADR-0001-modele-produit.md` +- `docs/PRODUCT.md` +- `docs/ARCHITECTURE.md` +- `docs/ROADMAP.md` +- `docs/KNOWN_ISSUES.md` +- `docs/CURRENT_STATE.md` +- `docs/tickets/README.md` +- `docs/tickets/T0002-modele-produit-solo-ou-collaboratif.md` + ### Commands and results +- `Test-Path docs/decisions/ADR-0001-modele-produit.md` : réussi (`True`). +- Recherche des références produit avec `rg` : réussie. +- Contrôle du périmètre avec `git diff --name-only` et `git status --short` : + uniquement documentation autorisée, y compris la nouvelle ADR. +- Revue de cohérence automatisée des termes structurants : réussie. +- Aucun build applicatif exécuté, conformément au ticket documentaire. + ### Manual verification result +Réalisée le 24 juillet 2026 : la section `Decision` définit sans ambiguïté un +propriétaire unique. Lui seul voit les finances, prépare et effectue les vols, +et achète ou vend les avions. Aucun rôle ou parcours différé n'est inclus dans le +MVP. Les contrôles d'autorisation futurs restent côté serveur. + ### Risks and limitations +- La durée de récupération et la rétention après suppression du propriétaire + restent volontairement à définir dans un futur ticket de politique de données. +- La structure préparatoire devra être validée lors du ticket de schéma ; elle ne + doit conférer aucun accès à un second humain. + ### Follow-ups +- Affiner puis exécuter T0003, ADR de stratégie de refonte. +- Créer ultérieurement un ticket de politique de suppression, récupération et + rétention des données. +- Toute collaboration future exige une nouvelle ADR. + ### Documentation updated +`PRODUCT.md`, `ARCHITECTURE.md`, `ROADMAP.md`, `CURRENT_STATE.md`, +`KNOWN_ISSUES.md` et l'index des tickets ont été alignés sur ADR-0001. diff --git a/docs/tickets/T0003-strategie-de-refonte.md b/docs/tickets/T0003-strategie-de-refonte.md new file mode 100644 index 0000000..e2d2a20 --- /dev/null +++ b/docs/tickets/T0003-strategie-de-refonte.md @@ -0,0 +1,414 @@ +# T0003 — Choisir la stratégie de refonte + +Status: Done +Owner: Andy +Branch: `docs/t0003-strategie-refonte` +Phase: 0 +Risk: High +Security-sensitive: Yes + +## Goal + +Choisir et documenter la manière de reconstruire Thrustline sans perdre les +comportements utiles, les données existantes ni la capacité de revenir en arrière. + +Le ticket doit décider entre : + +1. une **réécriture totale isolée** ; +2. une **refonte incrémentale dans la structure actuelle** ; +3. un **remplacement progressif par tranches verticales** — stratégie de type + strangler ; +4. une variante hybride clairement définie si aucune des trois options ne répond + aux contraintes. + +La décision finale doit être enregistrée dans +`docs/decisions/ADR-0002-strategie-de-refonte.md`. + +## Context + +T0001 a établi que l'application actuelle compile et contient déjà une couverture +fonctionnelle importante, mais aussi : + +- très peu de tests automatisés par rapport au périmètre ; +- aucun projet de tests .NET dédié ; +- aucun test RLS automatisé constaté ; +- des mutations métier directes depuis le client ; +- plusieurs pages React monolithiques ; +- une chaîne de distribution encore incomplète ; +- des versions et documents partiellement désynchronisés. + +ADR-0001 a retenu un MVP solo connecté, préparé pour une collaboration ultérieure, +sans rôles collaboratifs dans le MVP. + +L'expression « refonte totale » ne doit pas automatiquement conduire à supprimer +l'existant. Le dépôt actuel constitue à la fois une source de comportements +métier, une référence UX, un outil de comparaison et un risque de dette. T0003 +doit déterminer précisément ce qui est conservé comme référence, réutilisé, +migré, remplacé ou archivé. + +## Inputs required from Andy + +Le ticket doit obtenir des réponses explicites aux questions suivantes : + +1. Les données Supabase existantes doivent-elles être conservées en production, + migrées vers un nouveau schéma ou peuvent-elles être supprimées ? +2. Existe-t-il déjà des utilisateurs externes ou uniquement des données de + développement ? +3. L'application actuelle doit-elle continuer à fonctionner pendant la refonte ? +4. Acceptes-tu une période sans nouvelles fonctionnalités pour stabiliser le + nouveau socle ? +5. Souhaites-tu conserver le même dépôt et le même historique Git ? +6. Quelles fonctionnalités actuelles sont indispensables pour déclarer la + nouvelle version équivalente au MVP ? +7. Quelles parties sont considérées comme suffisamment fiables pour être + réutilisées : UI, calculs métier, migrations, bridge SimConnect, assets ? +8. Préfères-tu une première version plus rapide avec migration progressive ou + une attente plus longue pour remplacer l'ensemble ? +9. Quelle durée maximale de coexistence entre ancienne et nouvelle architecture + est acceptable ? +10. Quel niveau de rollback est requis après le premier déploiement de la refonte ? + +Une réponse manquante concernant les données existantes, la coexistence ou le +rollback est bloquante. + +## Dependencies + +- T0001 terminé. +- T0002 terminé. +- `docs/decisions/ADR-0001-modele-produit.md` accepté. +- `docs/CURRENT_STATE.md` +- `docs/PRODUCT.md` +- `docs/ARCHITECTURE.md` +- `docs/SECURITY.md` +- `docs/QUALITY.md` + +## Allowed areas + +- `docs/ARCHITECTURE.md` +- `docs/CURRENT_STATE.md` +- `docs/ROADMAP.md` +- `docs/KNOWN_ISSUES.md` +- `docs/decisions/` +- `docs/tickets/README.md` +- ce ticket + +## Do not touch + +- `app/` +- `sim-bridge/` +- `supabase/` +- `legacy/` +- `.github/` +- scripts de build ou de déploiement +- manifests, lockfiles et dépendances +- données ou migrations existantes +- modification utilisateur existante dans `app/src-tauri/Cargo.toml` + +## Requirements + +### 1. Inventorier les actifs à traiter + +Créer une matrice classant chaque grand ensemble : + +| Ensemble | Conserver comme référence | Réutiliser | Adapter | Réécrire | Archiver | Preuve requise | +| --- | --- | --- | --- | --- | --- | --- | +| UI et design | | | | | | | +| Domaine/économie | | | | | | | +| Bridge SimConnect | | | | | | | +| Contrats REST/SignalR | | | | | | | +| Schéma et données Supabase | | | | | | | +| RLS/RPC/Edge Functions | | | | | | | +| Tests | | | | | | | +| CI/release | | | | | | | +| Assets et catalogues | | | | | | | +| Documentation | | | | | | | +| `legacy/` | | | | | | | + +Un choix « réutiliser » exige une preuve de qualité ou un ticket préalable de +caractérisation. La seule présence de code ne suffit pas. + +### 2. Comparer les stratégies + +Pour chaque option, documenter : + +- organisation du dépôt et des branches ; +- durée pendant laquelle deux implémentations coexistent ; +- risque de régression fonctionnelle ; +- risque de corruption ou perte de données ; +- capacité à tester les comportements avant remplacement ; +- facilité de mise à niveau des dépendances ; +- coût de migration Supabase ; +- vitesse jusqu'à une bêta stable ; +- complexité cognitive et opérationnelle ; +- stratégie de release et rollback ; +- critères d'arrêt ou de changement de stratégie. + +### 3. Produire une matrice pondérée + +Noter chaque option de 1 à 5 avec justification pour : + +- stabilité pendant la refonte ; +- conservation des données ; +- vitesse de livraison ; +- testabilité ; +- sécurité ; +- capacité de rollback ; +- réduction de dette ; +- risque de double maintenance ; +- compréhension du système ; +- compatibilité avec ADR-0001. + +Andy valide les poids avant le score final. La stratégie ayant le meilleur score +ne devient pas automatiquement la décision si un risque bloquant subsiste. + +### 4. Définir le plan de coexistence + +L'ADR doit préciser : + +- emplacement du nouveau code ; +- branche longue ou intégration fréquente ; +- règle d'accès à l'ancien code ; +- mécanisme de comparaison ancien/nouveau ; +- propriété du schéma et des données pendant la transition ; +- compatibilité ascendante/descendante nécessaire ; +- feature flags éventuels ; +- conditions permettant d'arrêter l'ancienne implémentation ; +- procédure d'archivage finale. + +Éviter une branche de refonte isolée pendant plusieurs mois sans intégration ni CI. +Si une branche longue est retenue, documenter les synchronisations, propriétaires +et critères de sortie qui limitent ce risque. + +### 5. Définir la stratégie de données + +Documenter séparément : + +- données jetables et données à préserver ; +- sauvegarde avant migration ; +- migrations forward-only ou réversibles ; +- double lecture/écriture éventuellement nécessaire ; +- validation d'intégrité avant et après ; +- stratégie de rehearsal sur staging ; +- fenêtre de migration ; +- rollback de l'application et du schéma ; +- durée de conservation de l'ancien format. + +Aucune migration destructrice ne doit être planifiée sans sauvegarde restaurée +avec succès sur un environnement de test. + +### 6. Définir les gates + +La stratégie retenue doit avoir des gates mesurables : + +1. baseline de caractérisation ; +2. nouveau socle reproductible ; +3. premier vertical slice fonctionnel ; +4. parité du golden path ; +5. migration des données répétée ; +6. distribution signée ; +7. extinction de l'ancienne implémentation. + +Chaque gate doit indiquer preuves, responsable de validation et rollback. + +### 7. Propager la décision + +Après acceptation : + +- créer `docs/decisions/ADR-0002-strategie-de-refonte.md` ; +- mettre `docs/ARCHITECTURE.md` en cohérence ; +- ajuster les phases et gates de `docs/ROADMAP.md` ; +- ajouter les risques différés dans `docs/KNOWN_ISSUES.md` ; +- mettre à jour `docs/CURRENT_STATE.md` ; +- identifier le prochain ticket Ready. + +## Non-goals + +- Créer le nouveau socle. +- Déplacer, supprimer ou réécrire du code. +- Mettre à jour Node, React, Tauri, .NET, Rust ou Supabase. +- Choisir les versions finales de la stack. +- Modifier ou appliquer une migration. +- Supprimer `legacy/`. +- Concevoir tous les tickets de la refonte. +- Implémenter des feature flags. + +## Acceptance criteria + +- [x] Les dix questions d'Andy ont une réponse ou le ticket est `Blocked`. +- [x] Les actifs existants sont classés avec une justification. +- [x] Les trois stratégies principales sont comparées équitablement. +- [x] Les poids de la matrice sont validés par Andy. +- [x] Une stratégie est retenue et décrite sans ambiguïté. +- [x] Le traitement du dépôt, des branches et de l'ancien code est défini. +- [x] La conservation, migration et restauration des données sont définies. +- [x] Les gates de remplacement et d'extinction sont mesurables. +- [x] Les risques de coexistence et de rollback sont explicités. +- [x] `ADR-0002` est acceptée et cohérente avec `ADR-0001`. +- [x] Aucun fichier applicatif, migration ou dépendance n'est modifié. +- [x] Le prochain ticket recommandé est identifié. + +## Security review + +### Assets and data + +- comptes et identités ; +- compagnies, flotte, finances et rapports de vol ; +- tokens/sessions et configuration ; +- migrations, sauvegardes et ancien schéma ; +- binaires distribués et mécanisme de mise à jour. + +### Trust boundaries + +- ancienne application vers ancien/nouveau schéma ; +- nouvelle application vers APIs/RPC de transition ; +- processus de migration vers données de production ; +- staging, CI et production ; +- ancienne et nouvelle version installées chez les utilisateurs. + +### Abuse and failure cases + +- ancien client contournant une nouvelle règle serveur ; +- double écriture créant deux transactions ; +- migration partielle ou rejouée ; +- rollback applicatif incompatible avec le nouveau schéma ; +- données sensibles copiées dans un environnement non protégé ; +- feature flag modifiable côté client ; +- ancienne version restant utilisable après révocation ; +- divergence silencieuse entre ancien et nouveau calcul métier. + +### Required controls + +- sauvegarde chiffrée et restauration testée ; +- migrations idempotentes ou protégées contre le rejeu ; +- compatibilité explicitement versionnée ; +- serveur autoritaire pendant toute coexistence ; +- journal de migration sans secret ; +- kill switch serveur si un ancien client devient dangereux ; +- comparaison d'intégrité avant bascule ; +- séparation des environnements et moindre privilège. + +## Automated validation + +Ticket documentaire : aucun build applicatif requis. + +```powershell +# Vérifier l'ADR produite +Test-Path docs/decisions/ADR-0002-strategie-de-refonte.md + +# Vérifier les références à la stratégie dans les sources de vérité +rg -n "réécriture|incrémental|progressif|strangler|coexistence|rollback|migration" ` + docs/ARCHITECTURE.md docs/ROADMAP.md ` + docs/decisions/ADR-0002-strategie-de-refonte.md + +# Vérifier qu'aucun fichier applicatif n'appartient au ticket +git diff --name-only +``` + +La revue humaine de la matrice, des gates et du rollback reste obligatoire. + +## Manual verification + +1. Lire uniquement `Decision` et `Consequences` de l'ADR. +2. Expliquer où sera développé le nouveau code. +3. Expliquer comment un comportement actuel sera comparé à son remplacement. +4. Simuler une migration qui échoue à 50 % et vérifier le plan de récupération. +5. Simuler la découverte d'une régression après publication et vérifier le rollback. +6. Vérifier que l'on sait précisément quand l'ancienne implémentation pourra être + archivée. + +Temps cible : 10–15 minutes. + +## Rollback + +Tant qu'aucune implémentation ne dépend de la décision, une nouvelle ADR peut +remplacer ADR-0002. Après démarrage de la refonte, tout changement de stratégie +doit inventorier le travail déjà engagé, les données créées et le coût de retour. + +## Completion Report + +### Summary + +ADR-0002 documente le choix accepté par Andy d'une réécriture totale isolée. +L'ancien dépôt reste une référence en lecture seule ; le produit cible sera créé +dans un nouveau dépôt et un nouveau projet Supabase, sans coexistence en +production ni migration des données de développement. + +### Strategy selected + +Réécriture totale isolée, nouveau dépôt et historique Git neuf, branches courtes, +intégration fréquente, une seule bascule publique après parité du golden path. + +### Existing assets disposition + +L'UI et le design servent de référence à adapter. Tous les autres ensembles +servent au plus de référence ou de matière à caractérisation ; aucun code n'est +réutilisé par défaut. Le bridge SimConnect et le domaine sont réécrits avec +replays et tests. Le dépôt actuel et `legacy/` seront archivés après les gates. + +### Data migration approach + +Les données Supabase existantes sont exclusivement des données de développement +et sont jetables. Le nouveau schéma est créé depuis zéro avec seeds synthétiques. +Il n'y a ni migration, ni double lecture/écriture, ni ancien format à conserver. +La suppression réelle des anciennes données reste hors périmètre et n'a pas été +effectuée. + +### Files changed + +- `docs/decisions/ADR-0002-strategie-de-refonte.md` +- `docs/ARCHITECTURE.md` +- `docs/ROADMAP.md` +- `docs/KNOWN_ISSUES.md` +- `docs/CURRENT_STATE.md` +- `docs/tickets/README.md` +- `docs/tickets/T0003-strategie-de-refonte.md` + +### Commands and results + +- Lecture des sources de vérité, du ticket, d'ADR-0001 et inventaire des grands + ensembles : réussi. +- `Test-Path docs/decisions/ADR-0002-strategie-de-refonte.md` : `True`. +- `rg -n "réécriture|incrémental|progressif|strangler|coexistence|rollback|migration" ...` : + références présentes dans l'ADR, l'architecture et la roadmap. +- `git diff --check -- ` : réussi après correction d'une espace + finale. +- Contrôle de `git status --short`, `git diff --name-only` et des fichiers non + suivis : aucun fichier de `app/`, `sim-bridge/`, `supabase/`, `legacy/`, + `.github/`, manifeste, lockfile ou dépendance modifié par T0003. +- Aucun build applicatif requis pour ce ticket documentaire. + +### Manual verification result + +Revue documentaire effectuée : la décision et ses conséquences identifient le +nouveau dépôt comme lieu de développement, les tests de caractérisation comme +comparaison, la recréation de l'environnement neuf comme récupération d'un échec +avant bascule et le rollback N-1/correctif forward après apparition de données +réelles. L'ancienne implémentation n'est archivable qu'après les sept gates. + +### Risks and limitations + +- Risque d'oublier des comportements non caractérisés. +- Aucun corpus de traces SimConnect rejouables n'existe encore. +- Aucun rollback vers l'ancien produit après création de données réelles. +- La création du nouveau dépôt et la suppression des anciennes données ne font + pas partie de T0003. + +### Follow-ups + +- Caractériser le golden path et constituer des traces SimConnect. +- Exécuter T0004 pour la matrice Windows/MSFS. +- Fixer les budgets de stabilité et de performance. +- Créer ensuite le nouveau dépôt et son socle reproductible par ticket dédié. + +### Documentation updated + +ADR-0002 créée ; architecture, roadmap, état courant, problèmes connus et index +des tickets mis en cohérence. +### Git handoff + +Branche constatée avant exécution : `docs/t0002-modele-produit`. Le ticket +demande `docs/t0003-strategie-refonte` ; aucune branche n'a été créée ou changée +et aucun commit, push ou PR n'a été effectué. Les modifications préexistantes +hors ticket doivent rester exclues du staging. Le bloc PowerShell final est +fourni dans le rapport de l'agent après contrôle de l'état Git, de la branche +distante par défaut et de l'upstream.