diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md index 520132f..4493b1a 100644 --- a/docs/ARCHITECTURE.md +++ b/docs/ARCHITECTURE.md @@ -8,17 +8,17 @@ Statut : cible de refonte ; toute divergence durable nécessite un ADR. MSFS │ SimConnect (données non fiables) ▼ -Bridge .NET 8 +Bridge .NET 10 LTS │ événements de vol versionnés │ canal local authentifié ▼ -Tauri v2 / Rust +Tauri 2.11 / Rust stable épinglé │ capacités natives minimales ▼ -React / TypeScript +React 19 / TypeScript 6 │ lectures RLS + commandes HTTPS ▼ -Supabase +Supabase / PostgreSQL 17 ├─ Auth ├─ PostgreSQL + RLS ├─ RPC/Edge Functions transactionnelles @@ -54,6 +54,8 @@ Supabase - Connexion/reconnexion SimConnect. - Client hors processus self-contained Windows x64, limité à la session locale. +- SDK/API SimConnect officiel MSFS 2024 isolé derrière `ISimConnectAdapter` ; + aucun type SDK dans le domaine et aucune dépendance du domaine au wrapper. - Normalisation, validation et agrégation de la télémétrie. - Machine à états de vol déterministe et rejouable. - Rapport de vol versionné. @@ -71,6 +73,10 @@ Supabase - RLS défensive sur chaque table exposée. - Audit des changements sensibles. - Traitements passifs côté serveur, indépendants d'un client ouvert. +- PostgreSQL 17 fourni par la plateforme ; migrations et types générés depuis + le schéma neuf. +- RPC SQL préférée pour les commandes purement transactionnelles ; Edge + Functions réservées à l'orchestration réseau ou aux secrets serveur. ## Stratégie de construction @@ -166,3 +172,6 @@ de caractérisation malgré l'absence de migration de code. - `ADR-0003` : Windows 11 x64 maintenu et MSFS 2024 stable uniquement ; Store et Steam sont validés séparément, sans support Windows 10, ARM64, MSFS 2020, Insider ou Preview. WebView2 Evergreen et bridge .NET self-contained. +- `ADR-0004` : Node 24/pnpm 11/React 19/Tauri 2.11, bridge .NET 10 LTS avec SDK + SimConnect officiel abstrait et backend Supabase/PostgreSQL 17. Les versions + exactes et la politique mensuelle sont dans `docs/STACK.md`. diff --git a/docs/CURRENT_STATE.md b/docs/CURRENT_STATE.md index ca6666d..9b4705c 100644 --- a/docs/CURRENT_STATE.md +++ b/docs/CURRENT_STATE.md @@ -180,11 +180,25 @@ Une machine Ryzen 7 5800X, 32 Go et RX 6070 XT est disponible comme profil recommandé de validation. Elle ne prouve pas le minimum matériel. Aucun test MSFS réel n'a été exécuté dans T0004. +## Décision de stack cible + +`ADR-0004` retient Node 24 LTS avec pnpm 11, React 19/Vite 8, Tauri 2.11 sur +WebView2 Evergreen, Rust stable épinglé, un bridge .NET 10 LTS self-contained +`win-x64`, le SDK SimConnect officiel derrière une abstraction interne, et +Supabase/PostgreSQL 17. Firebase, Electron et le wrapper `SimConnect.NET` ne sont +pas les fondations de la refonte. + +Cette décision est documentaire : aucune version n'a été installée et aucun +manifest, lockfile, workflow ou code applicatif n'a été modifié. Les performances +et la compatibilité self-contained SimConnect restent à prouver par les tickets +d'adoption. + ## Prochain ticket recommandé -`T0005 — Budgets stabilité et performance`. Il doit mesurer et fixer les budgets -du profil minimum/recommandé. Les preuves Store/Steam et les replays SimConnect -seront réalisés lors du premier vertical slice bridge. +`T0006 — Épingler les runtimes et créer la source de versions`. Il doit créer +dans le nouveau dépôt les pins Node/pnpm/Rust/.NET/PowerShell, le bootstrap et +les contrôles de dérive, sans introduire encore le shell ou le frontend. Les +budgets du profil minimum/recommandé sont renumérotés `T0015`. ## Mise à jour de ce fichier diff --git a/docs/KNOWN_ISSUES.md b/docs/KNOWN_ISSUES.md index 29f5d3d..db7bb83 100644 --- a/docs/KNOWN_ISSUES.md +++ b/docs/KNOWN_ISSUES.md @@ -26,7 +26,10 @@ Statut : `Open`, `Accepted`, `Scheduled`, `Resolved`, `Invalid`. | 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 | | KI-011 | High | Support | Aucune preuve réelle distincte ne valide encore MSFS 2024 Microsoft Store/Xbox App et Steam ; une seule machine de test est disponible. | T0004 et proposition ADR-0003 | Validation plateformes / premier vertical slice SimConnect | Open | -| KI-012 | Medium | Support | Le profil matériel minimum Thrustline n'est pas mesuré ; la machine Ryzen 7 5800X, 32 Go, RX 6070 XT ne prouve que le profil recommandé cible. | Réponses Andy et ADR-0003 | T0005 | Open | +| KI-012 | Medium | Support | Le profil matériel minimum Thrustline n'est pas mesuré ; la machine Ryzen 7 5800X, 32 Go, RX 6070 XT ne prouve que le profil recommandé cible. | Réponses Andy et ADR-0003 | T0015 | Open | +| KI-013 | Medium | Desktop | Le gain réel de Tauri/WebView2 face à un shell .NET natif n'est pas mesuré sur le profil cible. | ADR-0004 : choix fondé sur l'architecture et l'absence de runtime Chromium embarqué | T0007 puis T0015 | Open | +| KI-014 | Medium | Backend | La stack Supabase locale n'est pas strictement identique au cloud et PostgreSQL 17 doit être confirmé sur chaque projet dev/staging/prod. | Documentation officielle Supabase consultée dans T0005 | T0012 | Open | +| KI-015 | High | Bridge | Le SDK managed SimConnect officiel documente .NET Framework et dépend de binaires/installation SDK ; sa publication self-contained .NET 10 reste à prouver. | Documentation MSFS 2024 SimConnect consultée dans T0005 | T0011 | Open | ## Règles diff --git a/docs/QUALITY.md b/docs/QUALITY.md index e1005ce..540d910 100644 --- a/docs/QUALITY.md +++ b/docs/QUALITY.md @@ -55,6 +55,9 @@ résultat. ## Budgets initiaux à fixer en phase 0 +Ticket cible : `T0015 — Fixer les budgets stabilité et performance`. T0005 +choisit la stack mais ne remplace aucune mesure sur le profil matériel cible. + - temps de démarrage sur machine cible ; - mémoire au repos et pendant un vol long ; - fréquence maximale de rendu de télémétrie ; @@ -63,6 +66,15 @@ résultat. - sessions sans crash ; - temps maximum de récupération après déconnexion. +## Validation des mises à niveau + +- Correctif : tests ciblés, audits et builds de tous les consommateurs. +- Mineure : contrôles précédents et smoke test du groupe de compatibilité. +- Majeure : ADR légère, fenêtre de test de deux semaines, matrice complète et + rollback vers les lockfiles précédents. +- Le socle mesure démarrage, mémoire, CPU, taille et reprise avant de promouvoir + un shell, un runtime ou une optimisation (trimming, ReadyToRun, Native AOT). + ## Vérification manuelle d'un ticket Elle doit tenir en 5–10 minutes quand le ticket est correctement découpé : diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index 463ce01..6cdc2d1 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -12,7 +12,9 @@ Objectif : rendre l'existant mesurable et décider ce que l'on reconstruit. ultérieure (`ADR-0001`, acceptée). - Matrice Windows/MSFS acceptée (`ADR-0003`) : Windows 11 x64 et MSFS 2024 stable, Store et Steam prouvés séparément. -- Budgets stabilité/performance et politique de données. +- Stack cible acceptée (`ADR-0004`) : Tauri/WebView2, React, .NET 10, + SimConnect officiel abstrait et Supabase/PostgreSQL 17. +- Budgets stabilité/performance (`T0015`) et politique de données. - 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. @@ -28,7 +30,7 @@ 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é. +- Versions/outils supportés selon `docs/STACK.md` et bootstrap automatisé. - Source de version unique. - CI consolidée et actions épinglées. - Lint/format/types/tests cohérents. diff --git a/docs/SECURITY.md b/docs/SECURITY.md index 6546d24..eb32581 100644 --- a/docs/SECURITY.md +++ b/docs/SECURITY.md @@ -70,11 +70,18 @@ Supposer qu'un attaquant peut : ### Supply chain et release - Lockfiles, audits npm/NuGet/Rust, scan de secrets et licences. +- Versions directes exactes ; restauration CI en mode verrouillé. +- Scripts d'installation pnpm refusés sauf allowlist et paquets nouveaux + différés de sept jours, hors correctif urgent revu. - Actions CI épinglées à des SHA immuables. - Secrets CI interdits aux PR de forks. - EXE, installateur et manifeste de mise à jour signés. - Checksum, SBOM et provenance publiés. - Vulnérabilité critique/haute bloque la release sauf exception écrite et limitée. +- Dépendance critique abandonnée ou sans licence claire refusée ; toute + exception nomme une alternative et expire sous 90 jours. +- Build, signature et publication sont trois étapes séparées ; aucun secret de + signature n'est exposé au job de build ni aux PR externes. ## Revue sécurité d'un ticket @@ -97,4 +104,3 @@ Tout ticket touchant auth, DB, fichiers, réseau, IPC, shell, update, télémét 4. Préparer une release signée. 5. Informer les utilisateurs affectés si nécessaire. 6. Consigner l'incident et l'action préventive. - diff --git a/docs/STACK.md b/docs/STACK.md new file mode 100644 index 0000000..85c53c2 --- /dev/null +++ b/docs/STACK.md @@ -0,0 +1,251 @@ +# Stack cible de la refonte + +Statut : proposition acceptée par ADR-0004 le 26 juillet 2026. +Date de consultation des sources : 26 juillet 2026. + +## Décision en bref + +Le nouveau dépôt conserve les frontières Tauri + React + bridge .NET + Supabase, +mais ne reprend aucun manifeste de l'ancien dépôt. Les versions initiales sont +figées exactement, avec lockfiles, puis les correctifs sont examinés chaque mois. + +- Node.js 24 LTS, pnpm 11 et TypeScript 6 ; +- React 19, Vite 8, Vitest 4 et Tailwind CSS 4 ; +- Tauri 2.11 sur WebView2 Evergreen, Rust stable épinglé ; +- bridge ASP.NET Core/SignalR en .NET 10 LTS, self-contained `win-x64` ; +- SDK SimConnect officiel MSFS 2024 derrière `ISimConnectAdapter` ; +- Supabase managé, PostgreSQL 17, RLS, Auth, Realtime ciblé et Edge Functions + seulement pour les commandes qui ne tiennent pas dans une RPC SQL. + +Firebase, Electron, une alternative à React et `SimConnect.NET` ne sont pas +retenus comme fondations. Ce sont des conclusions d'architecture, pas des +mesures de performance : les budgets et benchmarks restent à exécuter. + +## Réponses d'Andy + +| Question | Réponse retenue | +| --- | --- | +| LTS systématique | Non ; choisir selon stabilité et compatibilité. | +| Support sans changement majeur | 12 mois minimum. | +| Majeure pendant le MVP | Oui, après fenêtre de test. | +| Gestionnaire JS | pnpm autorisé. | +| Frontend | Alternative autorisée si plus stable et performante. | +| Backend | Supabase ou Firebase à déterminer. | +| Desktop | Choix le plus stable et économe ; Electron exclu. | +| Runtime .NET | Choix guidé par sécurité et performance. | +| SimConnect | SDK officiel autorisé, selon maintenance réelle. | +| Maintenance après lancement | Revue mensuelle. | + +## Matrice des versions + +« Ancien » sépare la plage déclarée de la version verrouillée observée. Une date +de fin absente signifie que le projet ne publie pas de LTS contractuelle. + +| Composant | Ancien dépôt | Dernière stable au 26/07/2026 | Recommandée | Support jusqu'à | Compatibilités | Décision | +| --- | --- | --- | --- | --- | --- | --- | +| Node.js | moteur `>=24.18.0 <25`; machine 24.14.1; CI 24.18.0 | 26.5.0 Current (08/07/2026) | **24.18.0 LTS** | avril 2028 | Vite 8 exige 20.19+ ou 22.12+; pnpm 11 exige 22.13+ | LTS ici : 26 reste Current jusqu'en octobre et n'apporte rien au runtime distribué. | +| pnpm | absent; npm 11.11.0 | 11.17.0 | **11.17.0** | sans LTS publiée | Node >=22.13; Corepack désactivé par défaut côté Node moderne | Remplace npm : lockfile strict, économie disque, contrôle des scripts et âge minimal des paquets. | +| TypeScript | `^5.6.2` → 5.9.3 | 7.0.2 | **6.0.3** | sans LTS publiée | React 19, Vite 8 et Testing Library; valider TS 7 séparément | TS 7 est une nouvelle majeure/native toolchain trop récente pour le socle; réévaluation mensuelle. | +| React / React DOM | `^18.3.1` → 18.3.1 | 19.2.8 | **19.2.8** | sans LTS publiée | types React 19, Testing Library 16, routeur 7 | Reste le choix le plus mature pour l'équipe et l'écosystème Tauri; pas de Server Components. | +| Routeur | `^6.27.0` → 6.30.4 | 7.18.1 (29/06/2026) | **7.18.1** | sans LTS publiée | React 19; Node >=20; mode SPA uniquement | Nouvelle base sans dette v6; ne pas activer les fonctions serveur du routeur. | +| Vite | `^8.1.5` → 8.1.5 | 8.1.5 | **8.1.5** | correctifs réguliers sur 8.1 | Node 24; plugin React 6; Tailwind Vite 4 | Retenu après stabilisation de Rolldown; version mineure exacte, pas `^`. | +| Vitest / couverture | `^4.1.10` → 4.1.10 | 4.1.10 | **4.1.10** | sans LTS publiée | Vite 6–8; Node 20+; couverture exactement alignée | Même pipeline que Vite; épingler `vitest` et `coverage-v8` à la même version. | +| jsdom | `^29.1.1` → 29.1.1 | 29.1.1 | **29.1.1** | sans LTS publiée | Node 20.19/22.13/24+ | Seulement en développement; tests UI, jamais embarqué. | +| Testing Library React | `^16.3.2` → 16.3.2 | 16.3.2 | **16.3.2** | sans LTS publiée | React/types 18 ou 19 | Conserver avec `jest-dom` 6.9.1 et `user-event` 14.6.1. | +| Tailwind CSS / plugin Vite | `^4.3.3` → 4.3.3 | 4.3.3 | **4.3.3** | sans LTS publiée | Vite 5.2–8; WebView2 Evergreen | Conserver; aucune contrainte de navigateur ancien pour Windows 11/WebView2. | +| Tauri core | plage Cargo `2` → 2.10.1 | 2.11.5 (01/07/2026) | **2.11.5** | série 2 maintenue, sans date contractuelle | Rust MSRV fournisseur >=1.77.2; WebView2; MSVC x64 | Conserver : shell web natif sans Chromium/Node embarqué. 2.11.1+ corrige deux failles ACL/origines. | +| Tauri CLI / API | `^2.0.4`/`^2.0.3` → 2.10.1 | CLI 2.11.4; API 2.11.1 | **2.11.4 / 2.11.1** | série 2 maintenue | même ligne Tauri 2.11 | Versions exactes et vérification de compatibilité croisée au bootstrap. | +| Plugins Tauri | shell 2.3.5 | shell 2.3.5; updater 2.10.1 | **aucun par défaut**; process/updater seulement au ticket dédié | selon plugin | capabilities explicites | Ne pas reprendre `plugin-shell`; le sidecar est déclaré/configuré, pas lancé par shell générique. | +| WebView2 | Evergreen système | Evergreen Stable | **Evergreen Stable** | cycle Edge stable | inclus normalement dans Windows 11; détection installateur obligatoire | Partagé, auto-corrigé et moins lourd qu'une Fixed Version. | +| Rust | machine 1.94.1; CI `stable` | 1.97.1 (16/07/2026) | **1.97.1** dans `rust-toolchain.toml` | six semaines environ par stable | cible `x86_64-pc-windows-msvc`; Tauri MSRV inférieur | Épingler le compilateur réel; MSRV projet = 1.97.1 au départ, révisée mensuellement. | +| .NET / ASP.NET Core | SDK local 10.0.201; projet/CI net8.0 | 10.0.10 LTS (14/07/2026) | **SDK/runtime 10.0.10, TFM net10.0** | 14/11/2028 | Windows 11 x64; SignalR 10; self-contained | .NET 8 finit le 10/11/2026; .NET 10 offre toute la fenêtre MVP. | +| SignalR JS | `^8.0.7` → 8.0.17 | 10.0.0 | **10.0.0** | ligne .NET 10 jusqu'au 14/11/2028 | serveur ASP.NET Core 10; Node LTS/browser courant | Aligner la majeure avec .NET; le package JS possède sa propre version de patch. | +| HTTP/résilience | `HttpClient` natif | .NET 10 | **`HttpClientFactory` + handlers maison bornés** | .NET 10 | pas de retry non idempotent | Pas de Polly au socle; l'ajouter seulement si un cas mesuré le justifie. | +| Sérialisation/validation | `System.Text.Json` implicite | .NET 10 | **System.Text.Json 10 + validation explicite** | .NET 10 | contrats versionnés TS/C# | Pas de dépendance runtime additionnelle initiale. | +| Tests .NET | aucun projet | xUnit v3 3.2.2; xUnit v4 encore preview | **xunit.v3 3.2.2** | sans LTS publiée | net10.0 | Refuser la preview v4; `Microsoft.NET.Test.Sdk` exact est relevé avec le ticket bridge et son runner MTP/VSTest. | +| SimConnect | `SimConnect.NET` 0.1.18 | wrapper 0.2.1 beta (12/05/2026); SDK MSFS 2024 courant | **SDK/API officiel MSFS 2024 + adaptateur interne** | cycle MSFS 2024 | x64, out-of-process, non thread-safe | Le wrapper reste beta et sans support Microsoft. L'officiel est la source d'API; tests via fake/replay. | +| Supabase JS | `^2.45.4` → 2.101.1 | 2.110.8 (23/07/2026) | **2.110.8** | sans LTS publiée | Node >=22; PostgreSQL/RLS/Auth/Realtime | Conserver; pin exact après audit et tests de contrat. | +| Supabase CLI | absent | 2.109.1 (24/07/2026) | **2.109.1** | sans LTS publiée | runtime Docker; stack locale non identique à 100 % au cloud | La CLI orchestre local, migrations, types et pgTAP; images par digest dans le nouveau dépôt. | +| PostgreSQL | cloud non relevé; 25 migrations | 18 amont; Supabase Platform 17 | **17 fourni par Supabase** | politique Supabase + PostgreSQL | Auth, RLS, Realtime, RPC | Ne pas viser 18 tant que la plateforme choisie ne le fournit pas officiellement. | +| Edge Functions / Deno | fonctions Supabase, version non épinglée | runtime Edge Supabase courant | **runtime fourni par CLI; Deno éditeur seulement** | politique Supabase | TypeScript/Deno; JWT vérifié | Une RPC SQL est préférée pour transaction DB; Edge Function pour orchestration réseau/secret serveur. | +| Tests SQL/RLS | aucun automatisé | pgTAP via CLI | **pgTAP + tests clients A/B/anonyme** | avec PostgreSQL 17 | `supabase test db` et intégration JS | Double preuve : structure/policies SQL et comportement API réel. | +| PowerShell | Windows PowerShell + `pwsh` CI | 7.6.0 LTS | **7.6.0 LTS** | 14/11/2028 | Windows 11, .NET 10 et runners GitHub | Aligne la fenêtre .NET; scripts en `pwsh`, `Set-StrictMode`, erreurs bloquantes; pas de dépendance à 5.1. | +| GitHub Actions | tags flottants `@v4`, `@v2`, `stable`, runners `latest` | versions maintenues courantes | **versions courantes épinglées par SHA** | revue mensuelle | `windows-2025` explicite, Node/.NET/Rust pins | Les tags servent seulement à documenter; exécution sur SHA immuable avec commentaire de version. | + +## Compatibilités par groupe + +### Groupe A — frontend + +**Compatible sous conditions.** Node 24.18.0 satisfait pnpm 11, Vite 8, Vitest 4 +et jsdom 29. React 19.2.8 est compatible avec Testing Library 16. TypeScript 6 +est préféré à 7 pendant le bootstrap. `pnpm-lock.yaml` est obligatoire et +`pnpm install --frozen-lockfile` est la seule restauration CI. + +Risques : Vite 8 remplace Rollup/esbuild par Rolldown; React 19 change quelques +API et comportements; React Router 7 est une majeure. Chacun exige un ticket +minimal et ses tests avant ajout de la couche suivante. + +### Groupe B — desktop + +**Compatible pour Windows 11 x64, à prouver par packaging.** Tauri utilise WRY et +WebView2 au lieu d'embarquer Chromium. Le toolchain est +`x86_64-pc-windows-msvc`, Rust 1.97.1, Visual Studio Build Tools maintenu et +WebView2 Evergreen. Le sidecar porte le suffixe de target Tauri attendu. + +Capabilities minimales : aucune permission shell générale, domaines externes +allowlistés, CSP restrictive, updater séparé et signatures obligatoires. Tester +le crash/restart WebView2 et la présence du runtime à l'installation. + +### Groupe C — bridge + +**Compatible avec réserve SimConnect.** ASP.NET Core et SignalR suivent .NET 10 +LTS. Le bridge est publié self-contained, single-file, `win-x64`. Le trimming et +Native AOT sont désactivés initialement : réflexion, sérialisation, ASP.NET et +interop SimConnect doivent être prouvés avant optimisation. + +L'API officielle SimConnect est non thread-safe et doit rester confinée à une +boucle dédiée. `ISimConnectAdapter` expose des événements de domaine, jamais des +types SDK. Une implémentation fake et un lecteur de traces versionnées sont +obligatoires avant le premier scénario MSFS réel. + +### Groupe D — backend + +**Compatible et préféré à Firebase.** Supabase fournit un PostgreSQL complet, +des transactions SQL, RLS, Auth et un workflow migrations/seed/pgTAP. Cela +correspond directement au grand livre append-only et aux commandes +transactionnelles. Firestore a des transactions atomiques mais un modèle +documentaire et des limites d'évaluation des règles; Firebase SQL Connect +ajouterait une nouvelle couche GraphQL/IAM et une migration d'architecture sans +bénéfice démontré. + +L'environnement local Supabase n'est pas entièrement équivalent au cloud : +chaque promotion exige migrations et tests de contrat sur staging. Realtime est +activé table par table; Storage reste hors socle jusqu'à besoin produit. + +### Groupe E — CI/release + +**Compatible sous contrôle de supply chain.** Runner Windows explicite, actions +épinglées par SHA, caches issus uniquement des lockfiles, permissions minimales, +aucun secret sur PR externe. Le build produit des artefacts non signés; un job +protégé séparé signe; un troisième publie l'updater et la provenance. + +Les scans minimaux sont `pnpm audit`, audit NuGet transitif, `cargo audit`, +licences, secret scan et SBOM. Les artefacts de build sont conservés 30 jours, +les releases et leur SBOM/provenance pendant toute la durée de support du +produit. + +## Revue sécurité et licences + +| Dépendance runtime | Licence / source | Maintenance et risque | Contrôle / alternative | +| --- | --- | --- | --- | +| React / React DOM | MIT, React Foundation/Meta | mature; failles RSC 2025 corrigées dans 19.2.1+, RSC inutilisé | 19.2.8 exacte; alternative Preact seulement après benchmark et test d'écosystème | +| Tauri | MIT ou Apache-2.0, Tauri Programme | actif; correctifs ACL/origines en 2.11.1 | >=2.11.5, capabilities minimales; alternative native .NET si benchmark Tauri échoue | +| Plugins Tauri | MIT/Apache-2.0, dépôt officiel | chaque plugin élargit l'autorité | aucun par défaut; revue permission et transitifs par plugin | +| SignalR JS | MIT, Microsoft | suit ASP.NET Core | aligner la majeure 10 avec le serveur; fallback REST/SSE local si hub inutile | +| Supabase JS | MIT, Supabase | actif, transitifs Auth/Realtime/PostgREST | pin exact, audit; client REST maison déconseillé | +| SimConnect officiel | SDK Microsoft sous termes MSFS | API officielle, binaire natif et SDK hors registre | checksum/provenance SDK, adaptateur; wrapper communautaire seulement en expérimentation | +| System.Text.Json / ASP.NET Core | MIT, Microsoft/.NET | support LTS Microsoft | patch mensuel .NET; aucune alternative externe initiale | + +Aucune vulnérabilité critique/haute connue ne doit rester dans le graphe au +moment de créer le socle. L'absence de résultat dans un registre n'est pas une +preuve d'innocuité : les audits sont répétés sur le lockfile réel. + +## Politique de versions + +- Manifests : versions exactes pour outils et dépendances directes; aucune plage + `^`, `~`, tag `latest` ou canal flottant. +- Lockfiles : `pnpm-lock.yaml` et `Cargo.lock` versionnés; NuGet utilise gestion + centrale avec lockfile en mode locked. +- Toolchains : `.node-version`, champ `packageManager`, `global.json` .NET et + `rust-toolchain.toml` exacts. Le MSRV du projet est la version Rust épinglée au + bootstrap; il ne descend que par décision explicite. +- Cadence : revue mensuelle; correctifs critiques/hauts immédiatement. Patchs + testés puis intégrés; mineures après CI complète; majeures avec ADR légère, + fenêtre de test de deux semaines et rollback lockfiles. +- Dependabot est autorisé pour GitHub Actions, NuGet et Cargo. Renovate est + préféré si pnpm nécessite un regroupement plus fin; un seul bot est activé. +- Une dépendance abandonnée, sans licence claire, à mainteneur unique critique + ou avec scripts d'installation injustifiés est refusée. Une exception indique + propriétaire, menace, alternative et date d'expiration maximale de 90 jours. +- `pnpm` refuse par défaut les scripts de build non allowlistés et impose un âge + minimal de publication de 7 jours, avec exception revue pour correctif urgent. +- Les builds candidats sont conservés 30 jours; releases, checksums, SBOM, + provenance et symboles nécessaires au diagnostic sont conservés pendant la + durée de support. + +## Ordre d'adoption + +1. **T0006 — runtimes et source de versions** : pins Node/pnpm/Rust/.NET/pwsh, + bootstrap et CI de version. +2. **T0007 — shell Tauri minimal** : fenêtre vide, CSP/capabilities, mesure + démarrage/mémoire et packaging `win-x64`. +3. **T0008 — frontend React minimal** : React/Vite/TS/Tailwind/Vitest, un écran + et un test. +4. **T0009 — bridge .NET minimal** : process self-contained, health check, + unit tests et arrêt propre. +5. **T0010 — contrat local** : lancement du sidecar, authentification + d'instance, REST/SignalR et récupération. +6. **T0011 — adaptateur SimConnect/replay** : interface, fake, traces et SDK + officiel sans logique métier liée aux types natifs. +7. **T0012 — Supabase local** : PostgreSQL 17, migration initiale, seed, types, + pgTAP et tests A/B/anonyme. +8. **T0013 — CI multi-stack** : runners explicites, SHA d'actions, audits, + licences, SBOM et artefacts. +9. **T0014 — packaging Windows non signé** : installation/upgrade/désinstallation + sur VM propre. +10. **Phase 6 — signature et updater** : jobs séparés, clés protégées, + provenance, rollback N-1. + +Les identifiants T0006–T0014 remplacent les sujets de backlog actuellement +numérotés; leur contenu détaillé doit être créé par lots de 3 à 8 tickets selon +`WORKFLOW.md`. + +## Sources officielles + +Toutes consultées le 26 juillet 2026. + +- [Node.js Releases](https://nodejs.org/en/about/previous-releases) — cycles + Current/LTS/EOL et dates des lignes 24/26. +- [Node.js 26.5.0](https://nodejs.org/en/blog/release/v26.5.0) — version Current + du 8 juillet 2026. +- [Registre npm : pnpm](https://registry.npmjs.org/pnpm/latest), + [TypeScript](https://registry.npmjs.org/typescript/latest) et + [React](https://registry.npmjs.org/react/latest) — métadonnées, moteurs, + licences et versions publiées. +- [Vite Releases](https://vite.dev/releases) et + [Vite 8](https://vite.dev/blog/announcing-vite8) — support et contraintes + Node/Rolldown. +- [Vitest migration v4](https://vitest.dev/guide/migration.html) — Node/Vite. +- [React versions](https://react.dev/versions) et + [advisory RSC](https://github.com/facebook/react/security/advisories/GHSA-fv66-9v8q-g76r). +- [Tauri releases](https://tauri.app/release/), + [changelog core](https://tauri.app/release/tauri/all-versions/) et + [dépôt officiel](https://github.com/tauri-apps/tauri) — versions, correctifs + sécurité, licences et WebView2/WRY. +- [Rust releases](https://blog.rust-lang.org/releases/) — stable 1.97.1. +- [.NET support policy](https://dotnet.microsoft.com/en-us/platform/support/policy) + et [single-file deployment](https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file/overview). +- [PowerShell support lifecycle](https://learn.microsoft.com/en-gb/powershell/scripting/install/powershell-support-lifecycle) + — version 7.6 LTS et fin de support. +- [SignalR supported platforms](https://learn.microsoft.com/en-us/aspnet/core/signalr/supported-platforms?view=aspnetcore-10.0). +- [WebView2 production guidance](https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/developer-guide) + et [distribution](https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution). +- [MSFS 2024 SimConnect SDK](https://docs.flightsimulator.com/msfs2024/html/6_Programming_APIs/SimConnect/SimConnect_SDK.htm), + [managed code](https://docs.flightsimulator.com/msfs2024/flighting/programming-apis/simconnect/programming-simconnect-clients-using-managed-code/) + et [SimConnect.NET 0.2.1](https://www.nuget.org/packages/SimConnect.NET). +- [Supabase database](https://supabase.com/docs/guides/database/overview), + [local workflow](https://supabase.com/docs/guides/local-development/cli-workflows), + [Edge Functions](https://supabase.com/docs/guides/functions) et + [database testing](https://supabase.com/docs/guides/database/testing). +- [Supabase PostgreSQL 17](https://supabase.com/changelog/35851-forthcoming-postgres-17-release-notes), + [supabase-js sur npm](https://www.npmjs.com/package/@supabase/supabase-js) et + [CLI sur npm](https://www.npmjs.com/package/supabase). +- [xUnit v3 sur NuGet](https://www.nuget.org/packages/xunit.v3) — stable 3.2.2, + v4 encore en préversion. +- [Firestore transactions](https://firebase.google.com/docs/firestore/manage-data/transactions), + [Security Rules](https://firebase.google.com/docs/rules) et + [Firebase release notes](https://firebase.google.com/support/releases). + +Les numéros futurs relevés dans les registres sont des faits de publication. +Les choix de version, la préférence Supabase et l'appréciation de performance +sont des inférences d'architecture à valider par les tickets d'adoption. diff --git a/docs/decisions/ADR-0004-stack-cible.md b/docs/decisions/ADR-0004-stack-cible.md new file mode 100644 index 0000000..426bf91 --- /dev/null +++ b/docs/decisions/ADR-0004-stack-cible.md @@ -0,0 +1,131 @@ +# ADR-0004 — Stack cible et politique de versions + +Date : 26 juillet 2026 +Statut : Accepted +Décideur : Andy +Ticket : T0005 + +## Contexte + +La réécriture vise Windows 11 x64 et MSFS 2024, doit laisser le maximum de +ressources au simulateur et rendre l'économie autoritaire. Andy autorise pnpm, +une alternative frontend, Firebase, un autre shell hors Electron et une majeure +pendant le MVP. Il demande douze mois sans majeure obligatoire et une revue +mensuelle après lancement. + +L'ancien dépôt mélange versions déclarées, verrouillées, locales et CI. .NET 8 +arrive en fin de support en novembre 2026; le wrapper SimConnect actuel est beta; +les dépendances npm utilisent des plages qui ont déjà produit une dérive forte. + +## Décision + +Adopter la stack et les pins décrits dans `docs/STACK.md` : + +1. Node 24 LTS + pnpm 11 + TypeScript 6; +2. React 19 + Vite 8 + Vitest 4 + Tailwind 4; +3. Tauri 2.11 + WebView2 Evergreen + Rust stable exact; +4. bridge .NET 10 LTS/ASP.NET Core/SignalR, self-contained `win-x64`; +5. SDK SimConnect officiel MSFS 2024 derrière une abstraction interne rejouable; +6. Supabase managé avec PostgreSQL 17, Auth, RLS, migrations, pgTAP et Realtime + limité aux besoins réels. + +Electron est exclu. Firebase/Firestore, Firebase SQL Connect, Preact/Svelte/Vue, +un shell .NET natif et `SimConnect.NET` ont été considérés mais ne sont pas +retenus pour le socle. + +## Raisons + +- Tauri réutilise WebView2 fourni et maintenu sur Windows 11; il évite de livrer + Chromium et Node avec l'application. Le shell actuel prouve déjà la faisabilité. +- React ne détermine pas l'essentiel de l'empreinte du runtime desktop. Changer + de framework créerait un coût d'apprentissage et un risque d'écosystème sans + preuve de gain utilisateur. Les gains doivent d'abord venir de la fréquence + de rendu, du découpage des vues et des mesures. +- Supabase/PostgreSQL correspond nativement aux transactions, contraintes, + grand livre append-only et RLS. Firestore est robuste mais documentaire; + SQL Connect ajouterait une nouvelle abstraction et ne simplifie pas les + invariants déjà conçus en SQL. +- .NET 10 LTS couvre le MVP jusqu'en novembre 2028; .NET 8 impose une migration + presque immédiate. Le runtime self-contained garantit le patch testé, au prix + d'un artefact plus lourd. +- Microsoft documente directement le client SimConnect managed et recommande un + exécutable out-of-process. Le wrapper communautaire 0.2.1 reste explicitement + beta. L'abstraction interne protège le domaine contre les deux options. + +## Politique + +- Versions directes et outils épinglés exactement; lockfiles obligatoires et + restauration CI figée. +- Revue mensuelle; correctifs critiques/hauts hors cycle. +- Majeure autorisée pendant le MVP avec ADR, deux semaines de validation et + rollback reproductible. +- Actions GitHub par SHA, permissions minimales, build/signature/publication + séparés, audits multi-écosystèmes, SBOM et provenance. +- Dépendance critique abandonnée ou sans licence claire refusée, sauf exception + écrite expirant sous 90 jours. +- Rust stable est épinglé dans `rust-toolchain.toml`; le MSRV initial du projet + est ce pin, même si le MSRV fournisseur Tauri est inférieur. +- Le trimming et Native AOT .NET sont désactivés jusqu'à preuve de compatibilité + SimConnect/ASP.NET; ReadyToRun est benchmarké, pas présumé. + +## Conséquences positives + +- Une seule matrice cohérente et supportée plus de douze mois. +- Faible empreinte desktop relative à Electron. +- Autorité transactionnelle et tests RLS locaux/staging. +- Bridge installable sans prérequis .NET machine. +- Remplacement possible de SimConnect sans contaminer le domaine. + +## Conséquences négatives et risques + +- WebView2 Evergreen peut changer hors release Thrustline; il faut tester les + canaux preview et gérer les pannes de processus. +- Le self-contained .NET augmente la taille de distribution. +- Supabase local n'est pas une copie exacte du cloud et demande Docker. +- Tauri, React, Vite, pnpm et Supabase ne publient pas tous une garantie LTS : + la cadence mensuelle et les lockfiles compensent, sans l'annuler. +- Les affirmations d'empreinte restent à confirmer sur le profil matériel; + aucune mesure Tauri contre shell natif n'a été exécutée dans T0005. + +## Options rejetées + +### Electron + +Rejeté par Andy et incompatible avec l'objectif d'éviter un runtime +Chromium/Node embarqué. + +### Shell natif .NET, WinUI/WPF/Avalonia + +Option de repli si les mesures Tauri échouent. Elle supprimerait Rust mais +imposerait une reconstruction UI complète et, selon le framework, un runtime ou +des dépendances supplémentaires. Aucun gain mesuré ne justifie cette divergence. + +### Preact, Svelte ou Vue + +Potentiellement plus petits en bundle, mais le bundle n'est pas le budget +dominant face à MSFS/WebView2/bridge. Le risque de migration et d'écosystème est +supérieur au gain non mesuré. Réouverture seulement par benchmark représentatif. + +### Firebase + +Firestore ne correspond pas au modèle relationnel et aux invariants SQL. SQL +Connect est plus récent et introduit GraphQL/Cloud SQL/IAM. Le coût de bascule +et de nouvelle ADR est injustifié sans défaut bloquant Supabase. + +### SimConnect.NET + +API agréable et active, licence MIT, mais beta, faible adoption et non supportée +par Microsoft. Peut servir de spike derrière l'adaptateur, jamais devenir la +frontière du domaine sans nouvelle décision. + +## Validation requise + +Cette ADR accepte une direction; elle ne prouve pas encore les performances. +Chaque ticket d'adoption doit mesurer build, démarrage, mémoire au repos et en +vol long, taille, reprise et compatibilité. Les canaux MSFS Store/Steam restent +non supportés jusqu'aux fiches réelles ADR-0003. + +## Remplacement + +Toute divergence majeure remplace cette ADR avec matrice actualisée, migration +et rollback vers les derniers manifests/lockfiles validés. diff --git a/docs/tickets/README.md b/docs/tickets/README.md index 68bb50c..1310f99 100644 --- a/docs/tickets/README.md +++ b/docs/tickets/README.md @@ -18,11 +18,18 @@ Créer un fichier par ticket à partir de `docs/templates/TICKET.md`. | T0002 | Choisir le modèle produit solo ou collaboratif | 0 | T0001 | Done | | T0003 | Choisir la stratégie de refonte | 0 | T0001–T0002 | Done | | T0004 | Définir la matrice de support Windows et MSFS | 0 | T0001–T0003 | Done | -| 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 | +| T0005 | Sélectionner la stack cible et ses versions compatibles | 0 | T0001–T0004 | Verify | +| T0006 | Épingler les runtimes et créer la source de versions | 1 | T0005 | Backlog | +| T0007 | Créer le shell Tauri minimal et mesurer son empreinte | 1 | T0006 | Backlog | +| T0008 | Créer le frontend React minimal | 1 | T0006–T0007 | Backlog | +| T0009 | Créer le bridge .NET minimal | 1 | T0006 | Backlog | +| T0010 | Établir le contrat local et le health check | 1 | T0007–T0009 | Backlog | +| T0011 | Créer l'adaptateur SimConnect et le replay | 1–3 | T0009–T0010 | Backlog | +| T0012 | Créer Supabase local et les tests RLS | 1 | T0006 | Backlog | +| T0013 | Consolider la CI multi-stack | 1 | T0006–T0012 | Backlog | +| T0014 | Valider le packaging Windows non signé | 1 | T0007–T0013 | Backlog | +| T0015 | Fixer les budgets stabilité et performance | 0–1 | T0007–T0011 | Backlog | -T0005 est le prochain ticket exécutable. Les premières preuves réelles Store et -Steam seront capturées avec le vertical slice SimConnect, avant toute promotion -vers `Supported`. +T0005 attend la vérification humaine de la matrice et des sources. Après +acceptation, T0006 est le prochain ticket exécutable. Les tickets détaillés sont +créés par lots de 3 à 8 selon `WORKFLOW.md`. diff --git a/docs/tickets/T0005-selection-stack-cible.md b/docs/tickets/T0005-selection-stack-cible.md new file mode 100644 index 0000000..94d1026 --- /dev/null +++ b/docs/tickets/T0005-selection-stack-cible.md @@ -0,0 +1,549 @@ +# T0005 — Sélectionner la stack cible et ses versions compatibles + +Status: Verify +Owner: Andy +Branch: `docs/t0005-stack-cible` +Phase: 0 +Risk: High +Security-sensitive: Yes + +## Goal + +Choisir la stack technique du nouveau dépôt Thrustline et figer un ensemble de +versions : + +- récentes ; +- stables ; +- officiellement supportées ; +- compatibles entre elles ; +- compatibles avec Windows 11 x64 et MSFS 2024 ; +- maintenables pendant toute la période visée pour le MVP ; +- sans vulnérabilité bloquante connue. + +Le ticket doit distinguer pour chaque composant : + +1. la version utilisée par l'ancien dépôt ; +2. la dernière version stable disponible au jour de l'étude ; +3. la version recommandée pour la refonte ; +4. la raison pour laquelle cette version est retenue ou écartée. + +La version ayant le numéro le plus élevé ne doit pas être choisie automatiquement. + +## Context + +ADR-0001 retient un MVP solo connecté préparé pour une collaboration ultérieure. +ADR-0002 retient une réécriture totale isolée dans un nouveau dépôt avec un +historique Git neuf et un backend Supabase neuf. + +ADR-0003 cible : + +- Windows 11 x64 sur une version publique encore maintenue ; +- MSFS 2024 stable ; +- Microsoft Store/Xbox App et Steam à valider séparément ; +- aucun support Windows 10, ARM64, MSFS 2020 ou Preview dans le MVP. + +L'ancien dépôt mélange actuellement plusieurs générations de versions et contient +des écarts entre environnement local, manifests et CI. Le nouveau dépôt ne doit +pas reproduire ces incohérences. + +T0005 est un ticket de recherche et de décision. Il ne crée pas encore le nouveau +dépôt et ne met aucune dépendance à jour. + +## Research requirement + +L'exécution nécessite une recherche web actualisée à la date du ticket. + +Utiliser en priorité : + +- documentation officielle et pages de releases des projets ; +- politiques officielles de support/LTS ; +- registres officiels npm, NuGet, crates.io et GitHub Releases du mainteneur ; +- Microsoft Learn pour .NET, ASP.NET Core, SignalR, WebView2 et Windows ; +- documentation officielle Tauri et Rust ; +- documentation officielle Supabase ; +- documentation officielle MSFS/SimConnect ; +- avis de sécurité GitHub, RustSec, npm et NuGet. + +Pour chaque décision conserver : + +- URL directe ; +- titre de la source ; +- date de consultation ; +- version et date de publication ; +- politique de support ; +- distinction entre information officielle et inférence. + +Un blog, une réponse Stack Overflow ou un commentaire communautaire ne peut pas +être l'unique source d'un choix structurant. + +## Components in scope + +### Outils et runtimes + +- Node.js ; +- npm ou autre gestionnaire de paquets si changement justifié ; +- TypeScript ; +- Rust toolchain et politique MSRV ; +- .NET SDK/runtime ; +- PowerShell requis pour les scripts ; +- GitHub Actions utilisées pour CI/release ; +- Supabase CLI ; +- Deno pour les Edge Functions si encore applicable. + +### Desktop et frontend + +- Tauri v2 et CLI ; +- plugins Tauri strictement nécessaires ; +- React ; +- React DOM ; +- Vite ; +- Vitest ; +- Testing Library ; +- Tailwind CSS ; +- routeur ; +- bibliothèque SignalR cliente ; +- SDK Supabase JavaScript. + +### Bridge et intégrations + +- ASP.NET Core ; +- SignalR serveur ; +- bibliothèque SimConnect .NET ou SDK officiel ; +- sérialisation et validation ; +- client HTTP/résilience ; +- framework de tests .NET ; +- outil de replay ou abstraction maison à décider. + +### Backend et données + +- version PostgreSQL fournie/supportée par Supabase ; +- Supabase Auth, Realtime, Storage si nécessaire ; +- Edge Functions ; +- génération des types ; +- framework de tests SQL/RLS ; +- migrations et environnement local. + +Les bibliothèques fonctionnelles non fondatrices — cartes, graphiques, icônes, +dates, formulaires — sont hors de la décision initiale sauf si elles imposent une +contrainte de compatibilité globale. + +## Inputs required from Andy + +1. Préfères-tu les versions LTS lorsqu'elles existent, même si une version stable + plus récente est disponible ? +2. Quelle durée minimale de support souhaites-tu couvrir sans changement majeur : + 12, 18, 24 ou 36 mois ? +3. Acceptes-tu une mise à niveau majeure pendant le développement du MVP ? +4. Veux-tu conserver npm ou autorises-tu l'étude de pnpm ? +5. Souhaites-tu rester sur React ou comparer une alternative frontend ? +6. Supabase reste-t-il un choix ferme pour le nouveau backend ? +7. Tauri v2 reste-t-il un choix ferme pour le desktop ? +8. Préfères-tu un runtime .NET embarqué autonome dans l'application ? +9. Acceptes-tu d'utiliser le SDK SimConnect officiel si le wrapper actuel n'offre + pas une maintenance ou une compatibilité suffisante ? +10. Quel rythme de mise à jour souhaites-tu après lancement : mensuel, + trimestriel ou seulement pour sécurité/compatibilité ? + +Une réponse qui remet en cause Tauri, Supabase, React ou .NET peut modifier +l'architecture ; dans ce cas, produire une ADR dédiée ou bloquer le ticket avant +de poursuivre. + +### Réponses reçues le 26 juillet 2026 + +1. Pas de préférence LTS systématique. +2. Douze mois minimum sans changement majeur. +3. Mise à niveau majeure autorisée pendant le MVP. +4. pnpm peut être étudié. +5. Une alternative à React peut être étudiée si elle est plus stable et + performante. +6. Firebase peut être comparé à Supabase. +7. Choisir le shell le plus stable et économe en ressources ; Electron exclu. +8. Choisir le mode .NET le plus sûr et performant. +9. SDK SimConnect officiel autorisé selon maintenance et compatibilité. +10. Revue mensuelle après lancement. + +## Dependencies + +- T0001 terminé. +- T0002 terminé. +- T0003 terminé. +- T0004 terminé sans conflit Git. +- ADR-0001, ADR-0002 et ADR-0003 acceptées. +- `docs/PRODUCT.md` +- `docs/ARCHITECTURE.md` +- `docs/SECURITY.md` +- `docs/QUALITY.md` +- `docs/SUPPORT.md` + +## Allowed areas + +- `docs/STACK.md` +- `docs/ARCHITECTURE.md` +- `docs/QUALITY.md` +- `docs/SECURITY.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 existants +- manifests et lockfiles +- installation locale des SDK/runtimes +- création du nouveau dépôt +- téléchargement ou installation d'une dépendance candidate + +## Requirements + +### 1. Inventorier l'ancien dépôt + +Pour chaque composant existant, relever depuis les manifests/lockfiles : + +- version déclarée ; +- version verrouillée réelle ; +- usage principal ; +- dépendances directes qui lui imposent une contrainte ; +- avertissements ou vulnérabilités déjà connus ; +- statut : conserver conceptuellement, remplacer ou réévaluer. + +Ne jamais afficher la valeur d'une variable secrète. + +### 2. Construire la matrice des versions + +Créer dans `docs/STACK.md` une table minimale : + +| Composant | Ancien dépôt | Dernière stable | Recommandée | Support jusqu'à | Compatibilités | Décision | +| --- | --- | --- | --- | --- | --- | --- | + +Chaque ligne doit expliquer : + +- pourquoi la version recommandée est adaptée ; +- pourquoi une version plus récente éventuelle est écartée ; +- les contraintes Windows 11 x64 ; +- les contraintes avec les autres composants ; +- les breaking changes pertinents ; +- les risques et inconnues. + +### 3. Valider les groupes de compatibilité + +Étudier au minimum les groupes suivants comme ensembles, pas composant par +composant : + +#### Groupe A — Frontend + +`Node → npm → TypeScript → React → Vite → Vitest → Tailwind` + +Vérifier engines, types React, plugin Vite, environnement jsdom et compatibilité +de build. + +#### Groupe B — Desktop + +`Windows 11 x64 → WebView2 → Rust → Tauri → plugins Tauri → sidecar` + +Vérifier toolchain MSVC, MSRV, format du sidecar, capabilities, updater et +signature. + +#### Groupe C — Bridge + +`.NET → ASP.NET Core → SignalR → SimConnect → packaging self-contained` + +Vérifier support Microsoft, architecture x64, dépendances natives, single-file, +trim/AOT éventuels et compatibilité MSFS 2024. + +#### Groupe D — Backend + +`Supabase CLI → PostgreSQL → Auth → RLS → Realtime → Edge Functions → SDK JS` + +Vérifier versions locales/cloud, Deno, génération de types, migrations et +compatibilité des clients. + +#### Groupe E — CI/release + +`GitHub Actions → Node/.NET/Rust → Tauri build → signature → updater` + +Vérifier runners Windows, actions épinglables, caches, provenance et secrets de +signature. + +### 4. Définir la politique de versions + +L'ADR doit décider : + +- LTS vs Current pour Node et .NET ; +- version exacte vs plage autorisée ; +- lockfiles obligatoires ; +- politique Rust stable et `rust-toolchain.toml` ; +- politique MSRV ; +- fréquence de mise à jour ; +- fenêtre de test avant mise à niveau majeure ; +- traitement des correctifs de sécurité ; +- outils automatiques autorisés, par exemple Dependabot ; +- règle d'acceptation d'une dépendance abandonnée ; +- durée de conservation d'une version de build. + +### 5. Évaluer SimConnect séparément + +Comparer au minimum : + +- wrapper `SimConnect.NET` actuel ; +- SDK/API SimConnect officiel Microsoft ; +- éventuel adaptateur interne autour de l'une de ces options. + +Évaluer : + +- maintenance et cadence de release ; +- compatibilité MSFS 2024 ; +- dépendances natives ; +- documentation ; +- licence ; +- capacité de simulation/mock/replay ; +- single-file/self-contained ; +- risque supply chain ; +- plan de remplacement. + +La décision doit privilégier une abstraction interne stable, même si une +bibliothèque externe est retenue. + +### 6. Effectuer une revue sécurité et licences + +Pour chaque dépendance runtime recommandée : + +- licence ; +- mainteneur/source ; +- historique de maintenance ; +- vulnérabilités connues ; +- scripts d'installation ; +- permissions/capabilities ; +- nombre et risque des dépendances transitives ; +- alternative si le composant est abandonné. + +Une dépendance critique non maintenue ou sans licence claire ne peut pas être +retenue sans exception écrite. + +### 7. Produire un ordre d'adoption + +Découper la création du nouveau socle en tickets indépendants, par exemple : + +1. runtimes et source de version ; +2. shell Tauri minimal ; +3. frontend React minimal ; +4. bridge .NET minimal ; +5. contrat local et health check ; +6. Supabase local ; +7. CI multi-stack ; +8. packaging Windows non signé ; +9. signature et updater. + +Chaque ticket doit avoir son propre build/test et ne pas introduire plusieurs +groupes majeurs sans validation intermédiaire. + +### 8. Propager la décision + +Après acceptation : + +- créer `docs/decisions/ADR-0004-stack-cible.md` ; +- créer `docs/STACK.md` ; +- mettre `ARCHITECTURE.md`, `QUALITY.md` et `SECURITY.md` en cohérence ; +- adapter `ROADMAP.md` ; +- ajouter les risques différés dans `KNOWN_ISSUES.md` ; +- actualiser `CURRENT_STATE.md` ; +- renuméroter l'ancien sujet « budgets stabilité et performance » dans un prochain + ticket disponible sans réutiliser T0005. + +## Non-goals + +- Installer les versions retenues. +- Modifier une dépendance de l'ancien dépôt. +- Créer le nouveau dépôt. +- Générer les nouveaux manifests ou lockfiles. +- Implémenter le frontend, le bridge ou Supabase. +- Choisir toutes les bibliothèques UI/métier. +- Résoudre une incompatibilité par du code. +- Utiliser automatiquement la toute dernière version. + +## Acceptance criteria + +- [x] Les dix questions d'Andy ont une réponse ou le ticket reste `Blocked`. +- [x] Toutes les informations évolutives sont sourcées et datées. +- [x] Chaque composant a une version actuelle, dernière stable et recommandée. +- [x] Les groupes A à E ont une conclusion de compatibilité explicite. +- [x] Node et .NET ont une décision LTS/Current justifiée. +- [x] La politique Rust/MSRV est définie. +- [x] Tauri/WebView2/sidecar sont compatibles avec Windows 11 x64. +- [x] Le choix SimConnect est documenté avec une stratégie d'abstraction. +- [x] Supabase local/cloud et Edge Functions ont des versions compatibles. +- [x] Les dépendances runtime ont une revue sécurité/licence. +- [x] L'ordre d'adoption est découpé en petits tickets vérifiables. +- [x] `ADR-0004-stack-cible.md` est accepté. +- [x] `docs/STACK.md` est exploitable pour créer les manifests du nouveau dépôt. +- [x] Aucun code, manifest, lockfile ou workflow n'est modifié. + +## Security review + +### Assets + +- chaîne de build ; +- dépendances et registres ; +- secrets CI/release ; +- binaire desktop et sidecar ; +- backend Supabase ; +- mécanisme de mise à jour. + +### Abuse and failure cases + +- typosquatting ou package compromis ; +- dépendance abandonnée ; +- script d'installation non nécessaire ; +- action GitHub flottante compromise ; +- versions locales différentes de la CI ; +- runtime en fin de support ; +- plugin Tauri demandant des capacités trop larges ; +- wrapper SimConnect distribuant un binaire natif non vérifié ; +- mise à niveau automatique cassant les lockfiles ; +- secret de signature exposé à une PR. + +### Required controls + +- lockfiles et versions reproductibles ; +- actions CI épinglées par SHA ; +- provenance et checksum des outils ; +- permissions minimales ; +- scans npm, NuGet et RustSec ; +- SBOM ; +- séparation build/signature/publication ; +- revue humaine des mises à niveau majeures ; +- exception documentée et datée pour toute dépendance à risque. + +## Automated validation + +Ticket documentaire : aucun build applicatif requis. + +```powershell +# Vérifier les livrables +Test-Path docs/STACK.md +Test-Path docs/decisions/ADR-0004-stack-cible.md + +# Vérifier les rubriques essentielles +rg -n "Node|React|Tauri|Rust|\\.NET|SimConnect|Supabase|PostgreSQL|LTS|MSRV" ` + docs/STACK.md docs/decisions/ADR-0004-stack-cible.md + +# Examiner strictement la portée du ticket +git diff --name-only +``` + +La validité des versions et de leurs compatibilités exige une revue humaine des +sources officielles. + +## Manual verification + +1. Choisir un composant, par exemple Node, Tauri ou .NET. +2. Retrouver sa version actuelle, dernière stable et recommandée. +3. Vérifier la source officielle et la date. +4. Suivre ses contraintes jusqu'aux composants dépendants. +5. Vérifier qu'un plan de test existe avant son adoption. +6. Choisir une dépendance critique et vérifier licence, maintenance et alternative. +7. Confirmer qu'aucune version n'est recommandée uniquement parce qu'elle est la + plus récente. + +Temps cible : 15 minutes. + +## Rollback + +Tant que le nouveau dépôt n'est pas créé, une nouvelle ADR peut remplacer ADR-0004. +Après création du socle, toute modification majeure de stack exige : + +- une ADR qui remplace ADR-0004 ; +- une matrice de compatibilité actualisée ; +- un plan de migration ; +- un rollback vers les derniers manifests/lockfiles validés. + +## Completion Report + +À remplir après décision. + +### Summary + +Stack de la réécriture sélectionnée et politique de versions définie. Les choix +ouverts par Andy ont été comparés; Tauri/React/Supabase restent retenus, avec +pnpm, .NET 10 LTS et le SDK SimConnect officiel abstrait. + +### Recommended stack + +Node 24/pnpm 11/TypeScript 6/React 19/Vite 8/Tauri 2.11/Rust stable/.NET 10/ +SimConnect officiel/Supabase PostgreSQL 17. Détails dans `docs/STACK.md`. + +### Versions selected + +Matrice complète dans `docs/STACK.md`; versions directes exactes et lockfiles +obligatoires, revue mensuelle. + +### Official sources consulted + +Sources Node, npm, React, Vite, Vitest, Tauri, Rust, Microsoft .NET/WebView2/ +SignalR/MSFS, Supabase, Firebase, NuGet et GitHub Advisory listées avec URL dans +`docs/STACK.md`, consultées le 26 juillet 2026. + +### Compatibility conclusions + +Groupes A à E compatibles sous les réserves consignées : TypeScript 7 différé, +packaging SimConnect/.NET 10 à prouver, parité Supabase local/cloud à tester, +actions et secrets de signature à isoler. + +### Security and license review + +Licences et maintenance des dépendances runtime fondatrices revues. Tauri +2.11.1+ requis pour les correctifs ACL/origines; React 19.2.8 est postérieur aux +correctifs RSC. Aucune exception de dépendance à risque n'est accordée. + +### Files changed + +`docs/STACK.md`, `docs/decisions/ADR-0004-stack-cible.md`, +`docs/ARCHITECTURE.md`, `docs/QUALITY.md`, `docs/SECURITY.md`, +`docs/CURRENT_STATE.md`, `docs/ROADMAP.md`, `docs/KNOWN_ISSUES.md`, +`docs/tickets/README.md` et ce ticket. + +### Commands and results + +Inventaire local des manifests/lockfiles et recherches `rg` réussis. +`Test-Path` des deux livrables : `True`/`True`. Recherche des rubriques +essentielles : réussie. Contrôle des zones interdites : aucune modification. +`git diff --check` : réussi, avec avertissements de normalisation LF/CRLF +seulement. Aucun build applicatif exécuté, conformément au ticket documentaire. + +### Manual verification result + +Revue agent effectuée sur Node, Tauri, .NET, SimConnect, Supabase et les +dépendances critiques. Revue humaine Andy encore requise avant `Done`. + +### Risks and limitations + +Aucun benchmark ni test MSFS/cloud/packaging n'a été exécuté. Les versions sans +LTS contractuelle exigent la revue mensuelle. Risques différés KI-013 à KI-015. + +### Follow-ups + +T0006 à T0015 dans `docs/tickets/README.md`; détails créés progressivement. + +### Documentation updated + +Architecture, qualité, sécurité, roadmap, état courant, problèmes connus, +matrice, ADR et index des tickets mis en cohérence. + +### Git handoff + +Branche : `docs/t0005-stack-cible`. Branche distante par défaut : +`origin/main`. Aucun upstream sur la branche. Message proposé : +`docs: select target stack for rebuild`. + +`AGENTS.md` et `docs/WORKFLOW.md` sont des modifications préexistantes hors +T0005. `docs/CURRENT_STATE.md` et `docs/tickets/README.md` contenaient déjà des +modifications préexistantes avant T0005 et ont aussi reçu des changements du +ticket : une revue/staging par hunks est nécessaire avant commit. Aucun commit, +push ou PR n'a été exécuté.