# Décision de skeleton Tauri pour projets contrôlés ## Objet Cette étude conserve la décision historique `0.0.5-alpha.9` sur la matérialisation d'un skeleton Tauri pour les nouveaux projets que l'organisation contrôle, puis son réexamen formel pendant `0.1.4`. Elle ne redéfinit pas les règles Tauri. Leur owner normatif reste [`../rules/710-TAURI.md`](../rules/710-TAURI.md). Le contrat des skeletons reste possédé par [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md). ## Corpus historique et état observé `0.0.5` Le corpus de réconciliation reste celui de `0.0.5` : ```text KSP 0.3.16 6 hosts Tauri Games 0.3.5 2 hosts Tauri ``` Les `8` hosts possèdent le même socle structurel : ```text Cargo.toml build.rs package.json tsconfig.json tauri.conf.json vite.config.ts capabilities/ src/lib.rs src/main.rs src/tauri.rs frontend/ ``` Aucun des `8` hosts n'utilise `src-tauri/`. Tous utilisent Vite et TypeScript. Les `6` hosts KSP utilisent en plus Bootstrap et `sass-embedded`, tandis que les `2` POC Games ne constituent pas une preuve suffisante pour imposer ces deux choix au profil Tauri universel. KSP apporte également l'usage éprouvé de TS-RS pour les structures Rust partagées avec le frontend. Cette frontière est déjà cadrée par `710-TAURI.md` pour les projets contrôlés. Ces observations qualifient un **candidat de skeleton organisationnel** ; elles ne suffisent pas à créer des règles Web générales. ## Owners déjà suffisants Les responsabilités suivantes ont un owner PGR matérialisé : - gouvernance et composition des skeletons : `200`, `210`, `220` ; - Rust/Cargo et skeleton Rust : `510` + `002-RUST_CARGO_WORKSPACE.md` ; - plateformes déjà matérialisées lorsqu'elles s'appliquent, notamment Android : `610` ; - host Tauri, capabilities, plugins, hooks, version produit et frontière Rust/frontend : `710`. La partie native du candidat n'a donc pas besoin d'un nouveau propriétaire caché dans le skeleton. ## Owner manquant PGR `0.0.5` ne possède aucun profil Web dédié pour : - organisation des sources frontend ; - TypeScript comme langage frontend ; - Vite comme bundler/dev server ; - Sass/CSS et ownership des sorties générées ; - framework CSS généraliste tel que Bootstrap ; - validation Web proportionnée et artefacts de build correspondants. Créer immédiatement un skeleton qui configure ces éléments ferait du skeleton le propriétaire normatif implicite de la stack Web. Ce serait contraire au principe suivant : un skeleton sélectionne et compose des owners ; il ne remplace pas les owners manquants. ## Vérification externe Tauri 2 La documentation Tauri 2 courante confirme deux points utiles mais ne comble pas le manque d'owner Web : - `create-tauri-app` fournit plusieurs choix frontend et Tauri peut aussi être ajouté manuellement à un frontend existant ; le layout standard `src-tauri/` est donc un scaffold supporté, pas une obligation conceptuelle pour les projets PGR contrôlés ; - les documentations de plugins décrivent aussi l'installation explicite des dépendances Cargo, l'initialisation Rust, les bindings JavaScript lorsque nécessaires et les permissions/capabilities, ce qui reste compatible avec la convention PGR d'intégration explicite. Références vérifiées le `2026-09-25` : - - - - ## Décision historique `0.0.5-alpha.9` Décision `alpha.9` : ```text DEFER ``` PGR `0.0.5` **ne crée pas** de skeleton Tauri `003`. Le report est intentionnel : le profil Tauri est suffisamment mûr, mais le skeleton complet ne peut pas encore être instancié sans absorber prématurément les responsabilités Web. Ce `DEFER` ne remet pas en cause les conventions Tauri déjà normalisées dans `710-TAURI.md` et ne réouvre pas les décisions `alpha.6` à `alpha.8`. ## Candidat conservé Lorsque les owners Web seront suffisants, le skeleton candidat pour une nouvelle baseline contrôlée devra réévaluer puis, si toujours justifié, composer : ```text 001-PROJECT_GOVERNANCE_FOUNDATION + 002-RUST_CARGO_WORKSPACE + profil Tauri 710 + profils Web réellement applicables ``` Le candidat organisationnel conserve les choix suivants sans les promouvoir aujourd'hui en règles Web : - host Cargo direct sans `src-tauri/` ajouté uniquement pour reproduire le scaffold standard ; - `frontend/` pour les sources Web ; - Vite + TypeScript ; - Sass pour la chaîne de styles ; - Bootstrap comme baseline de présentation lorsqu'un framework CSS généraliste est utile ; - TS-RS pour les DTO Rust possédés par le host et partagés avec TypeScript ; - `tauri.rs` comme owner de l'assemblage et des wrappers `#[tauri::command]` ; - ajout explicite et revu des plugins, dépendances frontend et capabilities minimales ; - WASM dans une unité séparée par défaut ; - politique de versions classifiée `CANONICAL` / `MIRROR-EXACT` / `MIRROR-STABLE` selon les owners concernés. ## Conditions de sortie du report Un futur plan MAY promouvoir ce candidat lorsqu'il existe au minimum des owners suffisants pour : 1. TypeScript et conventions Web contrôlées ; 2. Vite et ownership des commandes/dev server/build outputs ; 3. Sass/CSS et statut des artefacts générés ; 4. validation frontend indépendante de la validation Tauri ; 5. choix Bootstrap ou alternative clairement classifié comme décision de skeleton plutôt que règle Tauri. Le futur travail devra alors réexaminer le corpus courant au lieu de supposer que les versions ou outils observés dans KSP/Games restent les bons choix. ## Hors scope Cette décision ne : - crée pas de profil Web placeholder ; - réserve pas un numéro de release futur ; - transforme pas Bootstrap en dépendance Tauri ; - impose pas npm plutôt qu'un autre package manager ; - intègre pas WASM dans le host ; - migre KSP ou Games vers PGR ; - modifie pas les règles Tauri déjà stabilisées. ## Réexamen de préparation 0.1.1-beta.1 Le `DEFER` décidé en `0.0.5-alpha.9` reste la décision active pendant `0.1.1`. La présente révision n'autorise ni création ni adoption d'un skeleton Tauri ; elle vérifie uniquement si les responsabilités Web dont l'absence motivait le report possèdent désormais des owners PGR suffisants pour que `0.1.4` puisse réexaminer le candidat sur des bases concrètes. ### Condition 1 — TypeScript et conventions Web contrôlées Couverture disponible : ```text docs/rules/530-TYPESCRIPT.md docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md templates/web-typescript/tsconfig.json templates/web-typescript/package.json docs/skeletons/003-WEB_FRONTEND.md ``` Le langage/type-check, les déclarations externes, le manifest minimal et les décisions laissées au projet ont désormais des owners explicites. TypeScript reste une recommandation `SHOULD`, pas une obligation Tauri universelle. État de préparation : **couvert**. ### Condition 2 — Vite et ownership des commandes/dev server/build outputs Couverture disponible : ```text docs/rules/550-VITE.md docs/templates/009-WEB_VITE.md docs/validation/005-WEB_FRONTEND_VALIDATION.md ``` Le dev server, le cache, `build.outDir`, `publicDir`, les scripts et la frontière source/généré sont possédés sans imposer de `vite.config.ts`, layout, port ou `base` universel. État de préparation : **couvert**. ### Condition 3 — Sass/CSS et statut des artefacts générés Couverture disponible : ```text docs/rules/560-CSS_SASS.md docs/templates/010-WEB_CSS_SASS.md docs/validation/005-WEB_FRONTEND_VALIDATION.md ``` CSS seul reste valide ; Sass est optionnel mais recommandé lorsque utile. Sources, compilation, outputs, entrypoints de packages et compatibilité `@import` sont distingués sans imposer Bootstrap ni un `main.scss` générique. État de préparation : **couvert**. ### Condition 4 — validation frontend indépendante de la validation Tauri Couverture disponible : ```text docs/validation/005-WEB_FRONTEND_VALIDATION.md docs/validation/001-VALIDATION_MATRIX.md docs/skeletons/003-WEB_FRONTEND.md ``` Restore, type-check, styles, build et smoke navigateur sont classifiés indépendamment du host. Un `PASS` frontend ne vaut explicitement pas `PASS` Tauri. État de préparation : **couvert**. ### Condition 5 — framework CSS classé comme décision de skeleton/projet Couverture disponible : ```text docs/rules/560-CSS_SASS.md docs/templates/010-WEB_CSS_SASS.md docs/skeletons/003-WEB_FRONTEND.md ``` Bootstrap, Tailwind CSS ou une alternative sont des choix locaux. Leur présence dans Games/KSP ne les élève pas en règle Tauri ni en règle Web universelle. État de préparation : **couvert**. ### Conclusion de préparation Les cinq conditions de sortie formulées en `0.0.5-alpha.9` possèdent désormais des owners PGR matérialisés et non redondants. Cela change le diagnostic de préparation, pas la décision de skeleton : ```text conditions Web requises couvertes skeleton Tauri dans 0.1.1 toujours DEFER réexamen autorisé 0.1.4 création automatique interdite ``` `0.1.4` devra réexaminer le corpus alors courant, les versions/outils réellement soutenus, le profil `710-TAURI.md` et la composition avec `003-WEB_FRONTEND.md`. Il pourra confirmer, modifier ou abandonner le candidat historique. La présente étude ne préjuge pas de cette décision. Le candidat historique `frontend/ + Vite + TypeScript + Sass + Bootstrap + TS-RS` reste donc une observation à réexaminer, pas une baseline déjà approuvée. En particulier, `frontend/`, Vite, Sass et Bootstrap ne deviennent pas des obligations Tauri du seul fait que les owners permettant de les encadrer existent désormais. ## Réexamen décisionnel `0.1.4-alpha.2` `0.1.4-alpha.1` a réaudité le corpus au lieu de prolonger le `DEFER` par inertie. Les baselines réellement fournies sont : ```text Games 0.3.6 1 host Tauri KSP 0.3.19 6 hosts Tauri ``` Les `7` hosts actuels convergent encore sur un host Cargo direct `lib + bin`, `build.rs`, `tauri.conf.json`, `capabilities/`, `src/tauri.rs`, une racine frontend dédiée, TypeScript et Vite, sans `src-tauri/`. Games n'exerce toutefois plus les deux hosts du corpus historique, et Bootstrap/Sass/TS-RS, plugins, fenêtres, ACL, ports, bundle/resources et WASM restent suffisamment variables pour ne pas former une baseline Tauri indivisible. Les cinq conditions de sortie historiques sont désormais couvertes par les owners Web `530/540/550/560`, `005-WEB_FRONTEND_VALIDATION.md` et `003-WEB_FRONTEND.md`. Le motif Web qui bloquait la matérialisation en `0.0.5` est donc levé. La réconciliation de `710-TAURI.md` en révision `7` précise en outre : - la distinction entre commande enregistrée, permission et capability ; - la nécessité de traiter la sélection des capability files comme une décision de sécurité explicite ; - la composition cumulative des droits lorsqu'une fenêtre/webview appartient à plusieurs capabilities ; - le statut de `src-tauri/` comme layout supporté, tandis que le host Cargo direct reste une convention PGR recommandée pour les nouvelles baselines contrôlées ; - l'ownership Web séparé : TypeScript, Vite, Sass/CSS, framework CSS, package manager et génération de bindings ne sont plus choisis par le profil Tauri lui-même ; - la validation proportionnée par owner plutôt qu'un `tauri build` systématique. ### Décision active La décision active de `0.1.4-alpha.2` est : ```text DEFER historique pour absence d'owners Web LIFT candidat organisationnel ADOPT FOR MATERIALIZATION skeleton à matérialiser docs/skeletons/004-TAURI.md matérialisation dans alpha.2 NO matérialisation visée alpha.3 ``` Le `DEFER` de `0.0.5-alpha.9` reste conservé comme décision historique ; il n'est plus la décision active du candidat courant. ### Composition retenue pour `alpha.3` La specification Tauri candidate devra composer, sans duplication normative : ```text 001-PROJECT_GOVERNANCE_FOUNDATION + 002-RUST_CARGO_WORKSPACE + 003-WEB_FRONTEND lorsque le projet possède le frontend contrôlé correspondant + profil Tauri 710 + profils plateforme réellement ciblés ``` Le skeleton pourra proposer `frontend/`, TypeScript et Vite comme baseline recommandée pour une nouvelle application contrôlée compatible, mais devra laisser visibles les décisions destinataire et ne pas convertir ces recommandations en obligations Tauri. Sass, Bootstrap, TS-RS, plugins, fenêtres, ports, CSP, bundle targets, ressources et valeurs plateforme restent conditionnels au besoin réel. La specification devra également rendre explicite la politique de sélection des capabilities et la revue de la surface de sécurité avant sa gate initiale. ### Artefacts toujours différés Le réexamen ne démontre toujours pas le besoin de créer en `alpha.2` : - un template technique Tauri copiable ; - un contrat de validation Tauri séparé ; - un catalogue de plugins ou permissions par défaut ; - un framework CSS universel ; - un owner iOS, serveur Rust ou deployment/operations par proximité. Ces décisions restent à réévaluer après matérialisation de la specification, conformément au plan `0.1.4`.