0.0.5-alpha.9

This commit is contained in:
2026-09-25 17:59:25 +02:00
parent c331da5114
commit 9f596f30b2
7 changed files with 338 additions and 9 deletions

View File

@@ -1 +1 @@
0.0.5-alpha.8 0.0.5-alpha.9

178
deltas/0.0.5/alpha.9.md Normal file
View File

@@ -0,0 +1,178 @@
<!-- file: deltas/0.0.5/alpha.9.md -->
<!-- version: 1 -->
# Delta 0.0.5-alpha.9 — décision de skeleton Tauri contrôlé
## Baseline et version
Baseline attendue : commit opérateur complet de `0.0.5-alpha.8`, réalisé après application de `history/0.0.5/alpha.8.md` avec statut `PASS`.
Version après application :
```text
0.0.5-alpha.9
```
## Mission
Décider si les owners PGR réellement matérialisés permettent de créer un skeleton Tauri actionnable pour les projets contrôlés sans transformer ce skeleton en propriétaire implicite de règles Web encore absentes.
## Scope
REPLACE :
```text
VERSION
docs/000-README.md
docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
docs/skeletons/000-README.md
docs/studies/000-README.md
```
ADD :
```text
deltas/0.0.5/alpha.9.md
docs/studies/002-TAURI_SKELETON_DECISION.md
```
DELETE : aucun.
Aucun fichier `docs/skeletons/003-TAURI*.md` n'est créé.
## Décision
Résultat :
```text
DEFER
```
Le host Tauri est suffisamment cadré par les owners existants : Rust/Cargo, Tauri, plateformes applicables et règles générales de skeleton. La partie frontend candidate ne l'est pas encore : PGR ne possède aucun profil Web/Vite/TypeScript/Sass.
Créer maintenant le skeleton obligerait donc sa specification à posséder de fait la structure et la validation Web, alors qu'un skeleton doit composer des owners et non compenser leur absence.
## Candidat conservé
La décision ne rejette pas le skeleton organisationnel. Elle conserve comme hypothèse à réévaluer lorsque les owners Web existeront :
```text
host Cargo direct
+ frontend/
+ Vite
+ TypeScript
+ Sass
+ Bootstrap lorsque pertinent
+ TS-RS pour les DTO Rust partagés
+ tauri.rs comme owner Tauri
+ plugins/capabilities explicitement intégrés
+ WASM séparé par défaut
```
Aucune de ces lignes ne crée dans `0.0.5` un owner Web qui n'existe pas encore.
## Sources et vérification
La décision repose d'abord sur les baselines KSP `0.3.16` et Games `0.3.5` déjà autoritaires pour la réconciliation. La préparation a également vérifié la documentation Tauri 2 courante concernant la flexibilité du frontend, le scaffold `src-tauri/`, l'initialisation manuelle et l'installation explicite des plugins/capabilities.
L'étude détaillée est `docs/studies/002-TAURI_SKELETON_DECISION.md`.
## Hors scope
Cette tranche ne :
- crée pas un skeleton décoratif ;
- matérialise pas les futurs profils Web ;
- modifie pas `710-TAURI.md` ;
- choisit pas un package manager universel ;
- modifie pas les règles Rust fermées par `alpha.7/alpha.8` ;
- réserve pas une release pour le futur skeleton.
## Validation opérateur
Après application du history `PASS` de `alpha.8`, commit/push de cette tranche, puis application du présent delta :
```bash
test "$(cat VERSION)" = '0.0.5-alpha.9'
test -f history/0.0.5/alpha.8.md
test -f deltas/0.0.5/alpha.9.md
test -f docs/studies/002-TAURI_SKELETON_DECISION.md
test ! -e docs/skeletons/003-TAURI.md
test ! -e docs/skeletons/003-TAURI_CONTROLLED_PROJECT.md
test ! -e history/0.0.5/alpha.9.md
grep -A2 '^## Statut$' history/0.0.5/alpha.8.md | grep -Fx 'PASS'
grep -Fx '<!-- version: 15 -->' docs/000-README.md
grep -Fx '<!-- version: 12 -->' docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
grep -Fx '<!-- version: 4 -->' docs/skeletons/000-README.md
grep -Fx '<!-- version: 2 -->' docs/studies/000-README.md
grep -Fx '<!-- version: 1 -->' docs/studies/002-TAURI_SKELETON_DECISION.md
python3 -B -m unittest discover -s tests -v
python3 -B scripts/audit_markdown_headers.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
python3 -B scripts/audit_markdown_tables.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
python3 -B scripts/audit_markdown_links.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
python3 -B - <<'PY'
from pathlib import Path
import re
history = Path("history/0.0.5/alpha.8.md").read_text(encoding="utf-8")
assert re.search(r"## Statut\s+PASS\s", history)
study = Path("docs/studies/002-TAURI_SKELETON_DECISION.md").read_text(encoding="utf-8")
for phrase in (
"Décision `alpha.9` :",
"DEFER",
"Aucun des `8` hosts n'utilise `src-tauri/`.",
"PGR `0.0.5` **ne crée pas** de skeleton Tauri `003`.",
"PGR `0.0.5` ne possède aucun profil Web dédié",
"001-PROJECT_GOVERNANCE_FOUNDATION",
"002-RUST_CARGO_WORKSPACE",
"Bootstrap comme baseline de présentation lorsqu'un framework CSS généraliste est utile",
):
assert phrase in study, phrase
index = Path("docs/skeletons/000-README.md").read_text(encoding="utf-8")
assert "Aucun `003-TAURI...` n'est donc créé dans `0.0.5`." in index
assert "profils Web réellement matérialisés" in index
plan = Path("docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md").read_text(encoding="utf-8")
assert "### alpha.9 — décision de skeleton Tauri pour projets contrôlés — DEFER" in plan
assert "aucun skeleton Tauri `003` n'est créé dans `0.0.5`" in plan
assert "### beta.1 — réconciliation intégrée" in plan
assert not any(Path("docs/skeletons").glob("003-TAURI*.md"))
print("0.0.5 alpha.9 Tauri skeleton decision: clean (host ready, Web owners missing, decorative skeleton rejected, exit conditions recorded)")
PY
git diff --check
git add VERSION \
docs/000-README.md \
docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md \
docs/skeletons/000-README.md \
docs/studies/000-README.md \
docs/studies/002-TAURI_SKELETON_DECISION.md \
deltas/0.0.5/alpha.9.md
git diff --cached --check
git status --short
```
La sortie Git attendue avant ajout du history est exactement :
```text
M VERSION
A deltas/0.0.5/alpha.9.md
M docs/000-README.md
M docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
M docs/skeletons/000-README.md
M docs/studies/000-README.md
A docs/studies/002-TAURI_SKELETON_DECISION.md
```

View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md --> <!-- file: docs/000-README.md -->
<!-- version: 14 --> <!-- version: 15 -->
# Documentation PGR # Documentation PGR
@@ -24,6 +24,7 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
- [`plans/005-V0_0_5_RECONCILIATION_PLAN.md`](plans/005-V0_0_5_RECONCILIATION_PLAN.md) — cadrage, classification et trajectoire active de la réconciliation `0.0.5` ; - [`plans/005-V0_0_5_RECONCILIATION_PLAN.md`](plans/005-V0_0_5_RECONCILIATION_PLAN.md) — cadrage, classification et trajectoire active de la réconciliation `0.0.5` ;
- [`studies/001-KSP_GAMES_RECONCILIATION.md`](studies/001-KSP_GAMES_RECONCILIATION.md) — inventaire comparatif des baselines KSP/Games et décisions de généralisation, maintien local ou différé. - [`studies/001-KSP_GAMES_RECONCILIATION.md`](studies/001-KSP_GAMES_RECONCILIATION.md) — inventaire comparatif des baselines KSP/Games et décisions de généralisation, maintien local ou différé.
- [`studies/002-TAURI_SKELETON_DECISION.md`](studies/002-TAURI_SKELETON_DECISION.md) — décision `alpha.9` sur la maturité du skeleton Tauri contrôlé et ses prérequis Web encore manquants.
- [`templates/004-FILE_FAMILY_CONTRACTS.md`](templates/004-FILE_FAMILY_CONTRACTS.md) — pattern facultatif pour expliciter les responsabilités et règles de modification de familles de fichiers locales lorsque la complexité le justifie. - [`templates/004-FILE_FAMILY_CONTRACTS.md`](templates/004-FILE_FAMILY_CONTRACTS.md) — pattern facultatif pour expliciter les responsabilités et règles de modification de familles de fichiers locales lorsque la complexité le justifie.
- [`templates/005-RELEASE_PLAN.md`](templates/005-RELEASE_PLAN.md) — pattern de plan de release avec clôture/transition explicites et revue d'horizon proportionnée. - [`templates/005-RELEASE_PLAN.md`](templates/005-RELEASE_PLAN.md) — pattern de plan de release avec clôture/transition explicites et revue d'horizon proportionnée.
- [`validation/003-RUST_EXPORT_COMPLETENESS.md`](validation/003-RUST_EXPORT_COMPLETENESS.md) — contrat, provenance et limites de l'audit Rust facultatif de façade crate-root. - [`validation/003-RUST_EXPORT_COMPLETENESS.md`](validation/003-RUST_EXPORT_COMPLETENESS.md) — contrat, provenance et limites de l'audit Rust facultatif de façade crate-root.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md --> <!-- file: docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md -->
<!-- version: 11 --> <!-- version: 12 -->
# Plan 0.0.5 — réconciliation réelle avec KSP et sasedev-games # Plan 0.0.5 — réconciliation réelle avec KSP et sasedev-games
@@ -126,11 +126,15 @@ La mesure sur l'ensemble des sources `crates/**/*.rs` est propre pour les quatre
Le profil strict des nouvelles baselines contrôlées retient donc les règles mécaniques de lignes vides, séparation exacte des items distincts, modules production/tests, bloc de traits et blocs de réexports. PGR n'automatise pas un ordre global `enum → struct → impl → fn`, ni un tri visible/privé lorsque la structure métier peut être plus informative. Aucun parser Rust général ni audit composite n'est introduit. Le profil strict des nouvelles baselines contrôlées retient donc les règles mécaniques de lignes vides, séparation exacte des items distincts, modules production/tests, bloc de traits et blocs de réexports. PGR n'automatise pas un ordre global `enum → struct → impl → fn`, ni un tri visible/privé lorsque la structure métier peut être plus informative. Aucun parser Rust général ni audit composite n'est introduit.
### alpha.9 — décision de skeleton Tauri pour projets contrôlés ### alpha.9 — décision de skeleton Tauri pour projets contrôlés — DEFER
Vérifier si le profil Tauri obtenu et les owners Web disponibles permettent une skeleton specification utile pour les projets que l'organisation contrôle. Le candidat à évaluer utilise le host Cargo direct sans `src-tauri/`, `frontend/`, Vite, TypeScript, Sass et Bootstrap, centralise l'assemblage/les commandes dans `tauri.rs`, utilise TS-RS pour les DTO Rust partagés avec le frontend, conserve WASM dans une unité séparée par défaut et privilégie l'ajout explicite des plugins à partir de leur documentation. La revue de readiness confirme que le host est suffisamment cadré : `510-RUST_CARGO.md` possède les règles Rust et le packaging, `710-TAURI.md` possède le layout contrôlé, l'exception `lib + bin`, `tauri.rs`, TS-RS à la frontière host/frontend, les plugins/capabilities, les versions produit et les gates d'orchestration Tauri. Les `8` hosts observés confirment également le layout direct sans `src-tauri/`, `frontend/`, Vite et TypeScript.
Si les profils Web nécessaires ne sont pas encore assez matérialisés pour posséder proprement Vite/TypeScript/Sass/Bootstrap, consigner explicitement le report de ces choix tout en conservant les conventions Tauri déjà prouvées ; ne pas fabriquer un skeleton décoratif ni faire de `710-TAURI.md` un owner Web de substitution. En revanche, PGR ne possède encore aucun profil Web/Vite/TypeScript/Sass. Le candidat organisationnel Vite + TypeScript + Sass + Bootstrap ne peut donc pas être instancié sans que le skeleton devienne de fait propriétaire de règles frontend, ce qui contredirait `220-SKELETONS.md` et le modèle de profils. La décision `alpha.9` est donc `DEFER` : aucun skeleton Tauri `003` n'est créé dans `0.0.5`.
Le futur skeleton reste un candidat explicite et devra au minimum composer la fondation de gouvernance, le skeleton Rust/Cargo, le profil Tauri et les owners Web alors disponibles. Il pourra ensuite sélectionner le layout direct, `frontend/`, Vite + TypeScript + Sass, Bootstrap comme baseline de présentation lorsque pertinente, TS-RS pour les DTO Rust partagés, intégration explicite des plugins/capabilities et séparation de WASM par défaut. Ces choix ne deviennent pas des règles Web dans la présente release.
La condition de sortie du `DEFER` est la matérialisation d'owners Web suffisants pour posséder la structure des sources frontend, la chaîne Vite/TypeScript, Sass/CSS, les artefacts de build et leur validation sans duplication normative dans le skeleton. La décision détaillée est enregistrée dans `docs/studies/002-TAURI_SKELETON_DECISION.md`.
### beta.1 — réconciliation intégrée ### beta.1 — réconciliation intégrée

View File

@@ -1,5 +1,5 @@
<!-- file: docs/skeletons/000-README.md --> <!-- file: docs/skeletons/000-README.md -->
<!-- version: 3 --> <!-- version: 4 -->
# Index des skeleton specifications PGR # Index des skeleton specifications PGR
@@ -20,6 +20,10 @@ 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. - [`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. - [`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.
Les familles Java/Android, Web, JNI, Tauri et autres domaines sans pièces suffisantes restent différées selon le plan [`../plans/004-V0_0_4_SKELETONS_PLAN.md`](../plans/004-V0_0_4_SKELETONS_PLAN.md). Les familles Java/Android, Web, JNI et autres domaines sans pièces suffisantes restent différées tant que leurs owners normatifs et artefacts d'instanciation ne permettent pas une baseline réellement actionnable.
Le skeleton Tauri a fait l'objet d'une décision explicite en `0.0.5-alpha.9` : le host Rust/Tauri est suffisamment cadré par `510` et `710`, mais PGR ne possède pas encore les owners Web/Vite/TypeScript/Sass nécessaires pour matérialiser proprement la stack frontend candidate des projets contrôlés. Aucun `003-TAURI...` n'est donc créé dans `0.0.5`. La décision et ses conditions de sortie sont enregistrées dans [`../studies/002-TAURI_SKELETON_DECISION.md`](../studies/002-TAURI_SKELETON_DECISION.md).
Un futur skeleton Tauri devra composer les owners existants avec les profils Web réellement matérialisés ; il ne devra pas faire du skeleton lui-même le propriétaire des règles Vite, TypeScript, Sass, Bootstrap ou du package manager.
Aucun fichier placeholder ne doit être ajouté pour réserver un skeleton futur. Aucun fichier placeholder ne doit être ajouté pour réserver un skeleton futur.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/studies/000-README.md --> <!-- file: docs/studies/000-README.md -->
<!-- version: 1 --> <!-- version: 2 -->
# Index des études PGR # Index des études PGR
@@ -10,3 +10,4 @@ Une étude peut comparer des projets sources, des technologies ou plusieurs opti
## Études actives ## Études actives
- [`001-KSP_GAMES_RECONCILIATION.md`](001-KSP_GAMES_RECONCILIATION.md) — première réconciliation explicite de PGR avec les baselines autoritaires fournies de `khadhroony-solana-project` et `sasedev-games`. - [`001-KSP_GAMES_RECONCILIATION.md`](001-KSP_GAMES_RECONCILIATION.md) — première réconciliation explicite de PGR avec les baselines autoritaires fournies de `khadhroony-solana-project` et `sasedev-games`.
- [`002-TAURI_SKELETON_DECISION.md`](002-TAURI_SKELETON_DECISION.md) — étude de readiness `alpha.9` déterminant si les owners existants suffisent à matérialiser un skeleton Tauri contrôlé sans transférer au skeleton la propriété normative du frontend.

View File

@@ -0,0 +1,141 @@
<!-- 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.