0.1.4-alpha.2

docs/studies/002-TAURI_SKELETON_DECISION.md

@@ -1,15 +1,15 @@
 <!-- file: docs/studies/002-TAURI_SKELETON_DECISION.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Décision de skeleton Tauri pour projets contrôlés
 
 ## Objet
 
-Cette étude enregistre la décision `0.0.5-alpha.9` sur la matérialisation d'un skeleton Tauri pour les nouveaux projets que l'organisation contrôle.
+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 et état observé
+## Corpus historique et état observé `0.0.5`
 
 Le corpus de réconciliation reste celui de `0.0.5` :
 
@@ -78,7 +78,7 @@ Références vérifiées le `2026-09-25` :
 - <https://v2.tauri.app/plugin/file-system/>
 - <https://v2.tauri.app/learn/security/using-plugin-permissions/>
 
-## Décision
+## Décision historique `0.0.5-alpha.9`
 
 Décision `alpha.9` :
 
@@ -232,3 +232,68 @@ 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`.
+