0.1.4-alpha.3
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/skeletons/000-README.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# Index des skeleton specifications PGR
|
||||
|
||||
@@ -20,6 +20,7 @@ Une specification peut se composer avec une fondation plus générale, mais la c
|
||||
- [`001-PROJECT_GOVERNANCE_FOUNDATION.md`](001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation composable pour établir la gouvernance locale, la version, la documentation minimale, le workflow retenu et sa validation initiale sans imposer d'architecture applicative.
|
||||
- [`002-RUST_CARGO_WORKSPACE.md`](002-RUST_CARGO_WORKSPACE.md) — specialization composable d'un workspace Rust/Cargo fondée sur `001`, les profils `500 + 510`, les cinq templates Rust/Cargo et une validation réelle de la toolchain.
|
||||
- [`003-WEB_FRONTEND.md`](003-WEB_FRONTEND.md) — specialization composable d'un frontend Web contrôlé fondée sur les owners `530/540/550/560`, avec TypeScript/Vite recommandés, Sass conditionnel et validation indépendante du host.
|
||||
- [`004-TAURI.md`](004-TAURI.md) — specialization Tauri 2 contrôlée composant fondation, Rust/Cargo, frontend et owner `710`, avec décisions explicites sur layout, capabilities, plugins, versions, packaging et validation proportionnée.
|
||||
|
||||
Pour un projet existant, ces specifications servent de références de comparaison et non de recettes à recopier aveuglément. Le chemin canonique passe alors par [`../rules/230-ADOPTION.md`](../rules/230-ADOPTION.md) et son mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`.
|
||||
|
||||
@@ -27,8 +28,6 @@ Les familles Java/Android, JNI et autres domaines sans pièces suffisantes reste
|
||||
|
||||
Le skeleton Web `003` est matérialisé en `0.1.1-alpha.5` parce que les owners `530/540/550/560`, les guides d'adaptation et la validation frontend indépendante du host permettent désormais une composition sans ownership caché. Il ne fixe ni npm, ni Vite/Sass comme obligations, ni Bootstrap, ni un layout `frontend/` universel.
|
||||
|
||||
Le skeleton Tauri a fait l'objet d'une décision explicite en `0.0.5-alpha.9` : son host Rust/Tauri est cadré par `510` et `710`, mais sa promotion avait été différée tant que les owners Web nécessaires n'existaient pas. La décision `DEFER` et ses conditions de sortie restent enregistrées dans [`../studies/002-TAURI_SKELETON_DECISION.md`](../studies/002-TAURI_SKELETON_DECISION.md).
|
||||
|
||||
La création du skeleton Web ne lève pas automatiquement ce `DEFER`. `0.1.1-beta.1` doit encore réconcilier objectivement les conditions de sortie avant que `0.1.4` ne réexamine un éventuel skeleton Tauri, qui devra composer les owners Web au lieu de posséder leurs règles.
|
||||
Le skeleton Tauri avait été différé en `0.0.5-alpha.9` tant que les owners Web nécessaires n'existaient pas. `0.1.4-alpha.1` a confirmé les conditions de sortie, `alpha.2` a réconcilié l'owner `710`, puis `alpha.3` matérialise `004-TAURI.md` comme specification de composition sans reprendre l'ownership Web. L'étude historique et la levée du `DEFER` restent enregistrées dans [`../studies/002-TAURI_SKELETON_DECISION.md`](../studies/002-TAURI_SKELETON_DECISION.md).
|
||||
|
||||
Aucun fichier placeholder ne doit être ajouté pour réserver un skeleton futur.
|
||||
|
||||
217
docs/skeletons/004-TAURI.md
Normal file
217
docs/skeletons/004-TAURI.md
Normal file
@@ -0,0 +1,217 @@
|
||||
<!-- file: docs/skeletons/004-TAURI.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Skeleton — Tauri 2
|
||||
|
||||
## Objectif
|
||||
|
||||
Cette specification décrit une baseline organisationnelle composable pour une application Tauri 2 contrôlée par le projet, sans transformer les choix observés dans Games ou KSP en obligations universelles.
|
||||
|
||||
Elle compose les responsabilités déjà possédées par :
|
||||
|
||||
- [`001-PROJECT_GOVERNANCE_FOUNDATION.md`](001-PROJECT_GOVERNANCE_FOUNDATION.md) pour la gouvernance locale ;
|
||||
- [`002-RUST_CARGO_WORKSPACE.md`](002-RUST_CARGO_WORKSPACE.md) pour le workspace et le host Rust/Cargo ;
|
||||
- [`003-WEB_FRONTEND.md`](003-WEB_FRONTEND.md) lorsque le frontend Web est gouverné par cette baseline ;
|
||||
- [`../rules/710-TAURI.md`](../rules/710-TAURI.md) pour l'intégration Tauri elle-même.
|
||||
|
||||
Le contrat transversal des skeletons reste possédé par [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md). Le présent document sélectionne et ordonne des décisions ; il ne recopie pas les règles de ces owners.
|
||||
|
||||
## Applicabilité
|
||||
|
||||
Appliquer ce skeleton à un nouveau host Tauri 2 dont le projet contrôle l'organisation du dépôt et souhaite une baseline PGR composable.
|
||||
|
||||
Pour un projet Tauri existant, cette specification sert d'abord de référence de comparaison. L'adoption suit [`../rules/230-ADOPTION.md`](../rules/230-ADOPTION.md) et classe les écarts `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` au lieu de migrer mécaniquement vers le layout proposé.
|
||||
|
||||
Ne pas appliquer ce skeleton uniquement parce qu'un frontend Web existe, parce qu'une application desktop est envisagée ou parce que Tauri apparaît dans un autre projet. La présence effective d'un host Tauri 2 est la condition d'applicabilité.
|
||||
|
||||
## Composition de référence
|
||||
|
||||
Pour une nouvelle baseline contrôlée, l'ordre de composition est :
|
||||
|
||||
```text
|
||||
001 PROJECT_GOVERNANCE_FOUNDATION
|
||||
↓
|
||||
002 RUST_CARGO_WORKSPACE
|
||||
↓
|
||||
003 WEB_FRONTEND si le frontend est gouverné ici
|
||||
↓
|
||||
710 TAURI owner framework
|
||||
↓
|
||||
004 TAURI présente specification d'instanciation
|
||||
↓
|
||||
profils plateforme Android/iOS/autres uniquement s'ils sont ciblés
|
||||
```
|
||||
|
||||
Cette composition ne transfère aucun ownership. TypeScript, package manager, Vite, CSS/Sass et framework CSS restent possédés par leurs owners Web ; Cargo/Rust reste possédé par `510`; Android reste possédé par `610` lorsqu'il s'applique.
|
||||
|
||||
## Décisions obligatoires avant matérialisation
|
||||
|
||||
Le projet doit résoudre explicitement au minimum :
|
||||
|
||||
1. l'identité du host, sa place dans le workspace et les noms distincts de ses cibles `lib` et `bin` ;
|
||||
2. la version de Tauri 2 réellement retenue et sa stratégie de mise à jour ;
|
||||
3. la racine frontend et les owners Web réellement sélectionnés ;
|
||||
4. le package manager frontend lorsqu'un package JavaScript existe ;
|
||||
5. les commandes de développement et de build reliant Tauri au frontend ;
|
||||
6. la stratégie `devUrl` / `frontendDist` cohérente avec la chaîne frontend ;
|
||||
7. les capabilities réellement nécessaires et leur mode de sélection ;
|
||||
8. les permissions, commandes natives et scopes associés ;
|
||||
9. les plugins réellement requis et leurs modifications de configuration/ACL ;
|
||||
10. les fenêtres/webviews réellement nécessaires et leur répartition de privilèges ;
|
||||
11. la politique de version pour `tauri.conf.json` et le frontend conformément aux règles de gouvernance ;
|
||||
12. les ressources, icônes, bundle targets et cibles plateforme réellement distribuées ;
|
||||
13. la gate initiale capable de prouver les surfaces effectivement matérialisées.
|
||||
|
||||
Une décision encore inconnue reste une entrée ouverte ; elle ne doit pas être remplacée par une valeur copiée depuis Games, KSP ou un scaffold Tauri.
|
||||
|
||||
## Baseline organisationnelle recommandée
|
||||
|
||||
Pour un nouveau projet contrôlé, le host **SHOULD** rester une crate Cargo directement lisible et la surface Tauri **SHOULD** être visible à la racine de cette crate :
|
||||
|
||||
```text
|
||||
<tauri-crate>/
|
||||
├── Cargo.toml
|
||||
├── build.rs
|
||||
├── tauri.conf.json
|
||||
├── capabilities/
|
||||
├── src/
|
||||
│ ├── lib.rs
|
||||
│ ├── main.rs
|
||||
│ └── tauri.rs
|
||||
└── frontend/
|
||||
```
|
||||
|
||||
`frontend/` est la convention de cette baseline PGR lorsque le projet n'a pas déjà une autre racine frontend motivée. Un projet existant ou une contrainte externe peut conserver `src-tauri/`, une autre racine frontend ou une autre disposition supportée par la toolchain ; cet écart n'est pas à lui seul une raison de réécriture.
|
||||
|
||||
Le package Tauri contrôlé **SHOULD** utiliser une paire `lib + bin` conforme à `710-TAURI.md` : bibliothèque applicative/façade, launcher mince et module `src/tauri.rs` pour l'assemblage Tauri et les wrappers d'invocation.
|
||||
|
||||
## Frontend
|
||||
|
||||
Lorsque le projet ne possède pas déjà une stack frontend imposée ou motivée, la baseline Web de `003-WEB_FRONTEND.md` **SHOULD** être utilisée : TypeScript et Vite sont alors les choix recommandés, sans devenir des obligations Tauri universelles.
|
||||
|
||||
Le package manager est une décision du projet. npm, pnpm, yarn, Bun ou un autre outil supporté peuvent être retenus selon l'environnement et les contraintes réelles.
|
||||
|
||||
Sass et un framework CSS restent optionnels. Bootstrap, Tailwind CSS ou un autre framework ne sont jamais ajoutés par ce skeleton uniquement parce qu'ils existent dans un corpus historique.
|
||||
|
||||
WASM reste une unité séparée par défaut. Une chaîne WASM n'est intégrée dans le host que si l'architecture du produit l'exige explicitement.
|
||||
|
||||
## Capabilities, permissions et commandes
|
||||
|
||||
La baseline doit rendre visibles les trois niveaux distincts définis par `710-TAURI.md` :
|
||||
|
||||
```text
|
||||
commande native enregistrée
|
||||
permission ACL
|
||||
capability attribuée à une fenêtre/webview
|
||||
```
|
||||
|
||||
Pour une baseline simple à une capability, le projet peut conserver le comportement d'inclusion automatique supporté par sa version Tauri si cette décision est explicite et relue.
|
||||
|
||||
Dès que plusieurs capabilities, fenêtres/webviews ou niveaux de privilège apparaissent, une sélection explicite via `app.security.capabilities` **SHOULD** être préférée pour rendre la surface effective plus lisible.
|
||||
|
||||
Chaque ajout de plugin, permission, scope, origine distante ou capability doit être revu comme une modification de sécurité. Une commande enregistrée n'implique pas automatiquement qu'elle doit être accessible depuis toutes les fenêtres.
|
||||
|
||||
## Plugins
|
||||
|
||||
Aucun plugin n'est ajouté par défaut.
|
||||
|
||||
Lorsqu'un plugin est nécessaire, choisir sa version compatible, ajouter seulement les dépendances et bindings réellement utilisés, puis revoir les changements Rust, frontend, configuration et ACL associés.
|
||||
|
||||
Une commande de commodité comme `cargo tauri add` peut être utilisée si elle apporte une valeur réelle, mais la voie de validation reste la revue des fichiers effectivement modifiés. Le skeleton n'exige pas cette commande.
|
||||
|
||||
## Versions et métadonnées produit
|
||||
|
||||
`VERSION` reste la version canonique lorsque le projet adopte ce contrat de gouvernance.
|
||||
|
||||
La version du package Cargo du host suit la politique du workspace. `tauri.conf.json > version` et une éventuelle `package.json > version` doivent être classés explicitement, par exemple `MIRROR-STABLE` ou `MIRROR-EXACT`, selon le contrat de distribution réel.
|
||||
|
||||
Les identifiers d'application, noms de produit, bundle identifiers, publisher metadata et numéros plateforme sont des décisions produit/plateforme ; le skeleton ne fournit aucune identité fictive.
|
||||
|
||||
## Ordre d'initialisation
|
||||
|
||||
Une instanciation neuve suit normalement cet ordre :
|
||||
|
||||
1. appliquer la fondation locale et décider la version/unité de release ;
|
||||
2. matérialiser ou adapter le workspace Rust/Cargo ;
|
||||
3. créer le host Tauri et ses cibles `lib + bin` ;
|
||||
4. sélectionner puis matérialiser la baseline frontend ;
|
||||
5. raccorder `beforeDevCommand`, `beforeBuildCommand`, `devUrl` et `frontendDist` selon les outils réellement choisis ;
|
||||
6. créer `tauri.conf.json` avec uniquement les propriétés utiles ;
|
||||
7. créer les capability files et décider leur sélection ;
|
||||
8. ajouter uniquement les commandes et plugins nécessaires ;
|
||||
9. configurer fenêtres, ressources et bundle targets réellement requis ;
|
||||
10. composer les profils plateforme applicables ;
|
||||
11. exécuter la gate initiale proportionnée.
|
||||
|
||||
L'ordre peut être adapté lorsqu'une toolchain officielle crée certaines pièces automatiquement. Les fichiers générés doivent alors être relus et adaptés aux owners locaux avant d'être considérés comme baseline.
|
||||
|
||||
## Validation initiale
|
||||
|
||||
La gate minimale dépend des surfaces réellement créées. Elle **SHOULD** séparer les preuves :
|
||||
|
||||
```text
|
||||
Rust/Cargo
|
||||
→ fmt/check/clippy/tests sélectionnés par le projet
|
||||
|
||||
frontend
|
||||
→ restore/typecheck/build/styles selon 003 et 005-WEB_FRONTEND_VALIDATION
|
||||
|
||||
Tauri integration
|
||||
→ lancement Tauri ou smoke équivalent quand hooks/config/IPC/capabilities sont concernés
|
||||
|
||||
packaging
|
||||
→ tauri build uniquement lorsqu'un artefact packagé doit réellement être prouvé
|
||||
|
||||
plateforme mobile
|
||||
→ gates Android/iOS applicables en plus de Tauri
|
||||
```
|
||||
|
||||
Une nouvelle baseline qui possède `beforeDevCommand`, `beforeBuildCommand`, `devUrl`, `frontendDist`, des commands ou des capabilities doit au minimum exercer une commande Tauri supportée qui charge réellement cette configuration ; un simple `cargo check` ne prouve pas cette intégration.
|
||||
|
||||
Le projet doit également vérifier :
|
||||
|
||||
```text
|
||||
CHECK aucun placeholder ou identifiant fictif provenant de PGR/Games/KSP
|
||||
CHECK noms lib/bin non ambigus après normalisation Cargo
|
||||
CHECK frontend root et outputs cohérents avec tauri.conf.json
|
||||
CHECK capabilities intentionnelles et surface cumulée relue
|
||||
CHECK plugins présents uniquement s'ils sont utilisés
|
||||
CHECK artefacts générés exclus ou classifiés selon leur rôle réel
|
||||
CHECK secrets/signing credentials hors Git
|
||||
REVIEW fenêtres, bundles, ressources et targets réellement nécessaires
|
||||
```
|
||||
|
||||
## Templates techniques
|
||||
|
||||
Aucun template Tauri technique supplémentaire n'est requis pour matérialiser cette specification.
|
||||
|
||||
Le host dépend trop des décisions de nommage, de frontend, de capabilities, de plugins, de fenêtres, de plateformes et de versions pour qu'un `tauri.conf.json`, `Cargo.toml`, capability file ou `src/tauri.rs` universel apporte actuellement plus de valeur qu'il ne créerait de placeholders et de defaults arbitraires.
|
||||
|
||||
Les templates Rust/Cargo et Web existants restent utilisables pour leurs responsabilités propres. Un futur template Tauri ne sera justifié que si un besoin répétitif non correctement possédé par ces artefacts est démontré.
|
||||
|
||||
## Projet existant
|
||||
|
||||
Pour un projet existant :
|
||||
|
||||
- conserver son layout supporté lorsqu'une migration n'apporte pas de valeur démontrée ;
|
||||
- comparer les owners et décisions plutôt que les noms de fichiers ;
|
||||
- inventorier capabilities, plugins, commandes, hooks, fenêtres, bundles et plateformes ;
|
||||
- classer les écarts selon `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
|
||||
- introduire les changements par tranches validables plutôt qu'en remplaçant le scaffold complet.
|
||||
|
||||
L'objectif est l'autonomie locale du projet, pas sa ressemblance visuelle avec le skeleton PGR.
|
||||
|
||||
## Hors scope
|
||||
|
||||
Cette specification ne possède pas :
|
||||
|
||||
- un framework frontend ou CSS universel ;
|
||||
- un package manager universel ;
|
||||
- une version exacte de Tauri/CLI/plugin ;
|
||||
- un port de développement universel ;
|
||||
- un catalogue de plugins ;
|
||||
- une configuration de fenêtres ou bundles universelle ;
|
||||
- une chaîne WASM implicite ;
|
||||
- les règles Android/iOS ;
|
||||
- un CI/CD ou deployment universel ;
|
||||
- un template technique Tauri par symétrie.
|
||||
Reference in New Issue
Block a user