pgr/docs/studies/002-TAURI_SKELETON_DECISION.md

<!-- file: docs/studies/002-TAURI_SKELETON_DECISION.md -->
<!-- version: 1 -->

# 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`](../rules/710-TAURI.md). Le contrat des skeletons reste possédé par [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md).

## Corpus et état observé

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

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

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