pgr/docs/studies/002-TAURI_SKELETON_DECISION.md

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

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

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

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

État de préparation : **couvert**.

### Condition 2 — Vite et ownership des commandes/dev server/build outputs

Couverture disponible :

```text
docs/rules/550-VITE.md
docs/templates/009-WEB_VITE.md
docs/validation/005-WEB_FRONTEND_VALIDATION.md
```

Le dev server, le cache, `build.outDir`, `publicDir`, les scripts et la frontière source/généré sont possédés sans imposer de `vite.config.ts`, layout, port ou `base` universel.

État de préparation : **couvert**.

### Condition 3 — Sass/CSS et statut des artefacts générés

Couverture disponible :

```text
docs/rules/560-CSS_SASS.md
docs/templates/010-WEB_CSS_SASS.md
docs/validation/005-WEB_FRONTEND_VALIDATION.md
```

CSS seul reste valide ; Sass est optionnel mais recommandé lorsque utile. Sources, compilation, outputs, entrypoints de packages et compatibilité `@import` sont distingués sans imposer Bootstrap ni un `main.scss` générique.

État de préparation : **couvert**.

### Condition 4 — validation frontend indépendante de la validation Tauri

Couverture disponible :

```text
docs/validation/005-WEB_FRONTEND_VALIDATION.md
docs/validation/001-VALIDATION_MATRIX.md
docs/skeletons/003-WEB_FRONTEND.md
```

Restore, type-check, styles, build et smoke navigateur sont classifiés indépendamment du host. Un `PASS` frontend ne vaut explicitement pas `PASS` Tauri.

État de préparation : **couvert**.

### Condition 5 — framework CSS classé comme décision de skeleton/projet

Couverture disponible :

```text
docs/rules/560-CSS_SASS.md
docs/templates/010-WEB_CSS_SASS.md
docs/skeletons/003-WEB_FRONTEND.md
```

Bootstrap, Tailwind CSS ou une alternative sont des choix locaux. Leur présence dans Games/KSP ne les élève pas en règle Tauri ni en règle Web universelle.

État de préparation : **couvert**.

### Conclusion de préparation

Les cinq conditions de sortie formulées en `0.0.5-alpha.9` possèdent désormais des owners PGR matérialisés et non redondants.

Cela change le diagnostic de préparation, pas la décision de skeleton :

```text
conditions Web requises      couvertes
skeleton Tauri dans 0.1.1    toujours DEFER
réexamen autorisé            0.1.4
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.