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. Le contrat des skeletons reste possédé par ../rules/220-SKELETONS.md.

Corpus historique et état observé `0.0.5`

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-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 :

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.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 :

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.

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 :

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.