5.9 KiB
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.
Elle ne redéfinit pas les règles Tauri. Leur owner normatif reste ../rules/710-TAURI.md. Le contrat des skeletons reste possédé par ../rules/220-SKELETONS.md.
Corpus et état observé
Le corpus de réconciliation reste celui de 0.0.5 :
KSP 0.3.16 6 hosts Tauri
Games 0.3.5 2 hosts Tauri
Les 8 hosts possèdent le même socle structurel :
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-appfournit plusieurs choix frontend et Tauri peut aussi être ajouté manuellement à un frontend existant ; le layout standardsrc-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 :
- https://v2.tauri.app/start/create-project/
- https://v2.tauri.app/start/project-structure/
- https://v2.tauri.app/plugin/file-system/
- https://v2.tauri.app/learn/security/using-plugin-permissions/
Décision
Décision alpha.9 :
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 :
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.rscomme 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-STABLEselon 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 :
- TypeScript et conventions Web contrôlées ;
- Vite et ownership des commandes/dev server/build outputs ;
- Sass/CSS et statut des artefacts générés ;
- validation frontend indépendante de la validation Tauri ;
- 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.