Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.0.5-alpha.6

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-25 09:16:06 +02:00
parent 81c7a720f5
commit 0f6a2e21eb
11 changed files with 602 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
RULES.md
View File

@@ -1,5 +1,5 @@
<!-- file: RULES.md -->
<!-- version: 10 -->
<!-- version: 11 -->
# Index normatif Project Governance Rules
@@ -84,6 +84,8 @@ Familles actuellement actives :
- [`docs/rules/520-JAVA_MAVEN_GRADLE.md`](docs/rules/520-JAVA_MAVEN_GRADLE.md) — profil Java et spécialisations Maven/Gradle : toolchain LTS, structure, dépendances, tests et validation de build.
- [`docs/rules/600-PLATFORMS.md`](docs/rules/600-PLATFORMS.md) — contrat commun des profils plateforme et de leur compatibilité de target/runtime.
- [`docs/rules/610-ANDROID.md`](docs/rules/610-ANDROID.md) — profil Android : structure, toolchain/SDK, compatibilité, packaging, configuration locale et validation plateforme.
- [`docs/rules/700-FRAMEWORKS.md`](docs/rules/700-FRAMEWORKS.md) — contrat commun des profils framework et de leur orchestration avec langages, plateformes et outils de build.
- [`docs/rules/710-TAURI.md`](docs/rules/710-TAURI.md) — profil Tauri 2 : host Rust, configuration/capabilities, hooks frontend, version produit, artefacts générés et validation d'intégration.
Le modèle de composition et d'ownership des profils est défini dans [`docs/architecture/003-RULE_PROFILE_MODEL.md`](docs/architecture/003-RULE_PROFILE_MODEL.md).

2
VERSION
View File

@@ -1 +1 @@
0.0.5-alpha.5.fix.1
0.0.5-alpha.6

189
deltas/0.0.5/alpha.6.md Normal file
View File

@@ -0,0 +1,189 @@
<!-- file: deltas/0.0.5/alpha.6.md -->
<!-- version: 1 -->
# Delta 0.0.5-alpha.6 — premier profil framework : Tauri 2
## Baseline et version
Baseline attendue : commit opérateur complet de `0.0.5-alpha.5.fix.1`, réalisé après application de `history/0.0.5/alpha.5.fix.1.md` avec statut `PASS`.
Version avant application :
```text
0.0.5-alpha.5.fix.1
```
Version après application :
```text
0.0.5-alpha.6
```
## Scope
REPLACE :
```text
VERSION
RULES.md
docs/000-README.md
docs/architecture/003-RULE_PROFILE_MODEL.md
docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
docs/rules/000-README.md
docs/studies/001-KSP_GAMES_RECONCILIATION.md
```
ADD :
```text
docs/rules/700-FRAMEWORKS.md
docs/rules/710-TAURI.md
deltas/0.0.5/alpha.6.md
```
DELETE : aucun.
Le history `alpha.5.fix.1` appartient au commit baseline et n'est pas inclus dans l'archive du présent delta.
## Preuve de généralisation
Les baselines autoritaires étudiées en `alpha.1` contiennent :
```text
KSP 0.3.16 6 applications Tauri
Games 0.3.5 2 applications Tauri
```
Les huit applications utilisent Tauri 2 avec un host Rust/Cargo, `tauri-build`, `tauri.conf.json`, des capability files, des hooks frontend et un `frontendDist`. Elles divergent en revanche sur fenêtres, ports, CSP, bundling, plugins, ressources et contenu réel des hooks.
Le profil normalise donc les responsabilités et l'orchestration communes, pas ces valeurs locales.
## Décisions matérialisées
### Famille `700 — frameworks`
`700-FRAMEWORKS.md` devient l'owner des règles communes aux frameworks : composition avec les owners langage/plateforme, ownership des commandes d'intégration, classification des artefacts générés, cohérence de version produit et validation proportionnée.
La famille interdit notamment de supposer qu'un framework absorbe automatiquement son frontend, sa plateforme ou son package manager.
### Profil `710 — Tauri 2`
Le profil Tauri :
- se compose au-dessus de Rust/Cargo et des plateformes réellement ciblées ;
- ne rend pas Vite, WASM, TypeScript ou npm obligatoires ;
- ne rend pas `src-tauri/` obligatoire lorsque la toolchain supporte clairement un autre layout ;
- possède l'orchestration via le CLI Tauri lorsque les hooks/config/capabilities/bundles sont concernés ;
- distingue un check Rust, un build frontend et une preuve d'intégration Tauri ;
- préfère une chaîne de version unique `VERSION → workspace Cargo → package host → Tauri` lorsque l'application partage le release train et que la configuration Tauri peut omettre sa propre version ;
- traite les capability files comme source de sécurité intentionnelle ;
- ne généralise ni plugins, CSP, fenêtres, bundles, ports ni ressources des corpus ;
- ne généralise pas l'ignorance de tout `gen/`, car un projet mobile généré peut recevoir des personnalisations intentionnelles ;
- sélectionne `tauri dev/build` ou leur équivalent seulement lorsque la propriété à prouver le justifie.
### Pas de skeleton dans cette tranche
`alpha.6` ne crée aucun `tauri.conf.json`, package frontend, template Tauri ou skeleton. La décision de matérialiser une specialization Tauri appartient explicitement à `alpha.7`.
## Validation opérateur
Après application du history `PASS` de `alpha.5.fix.1`, commit/push de cette tranche, puis application du présent delta :
```bash
test "$(cat VERSION)" = '0.0.5-alpha.6'
test -f history/0.0.5/alpha.5.fix.1.md
test -f deltas/0.0.5/alpha.6.md
test -f docs/rules/700-FRAMEWORKS.md
test -f docs/rules/710-TAURI.md
test ! -e history/0.0.5/alpha.6.md
grep -A2 '^## Statut$' history/0.0.5/alpha.5.fix.1.md | grep -Fx 'PASS'
grep -Fx '<!-- version: 11 -->' RULES.md
grep -Fx '<!-- version: 13 -->' docs/rules/000-README.md
grep -Fx '<!-- version: 4 -->' docs/architecture/003-RULE_PROFILE_MODEL.md
grep -Fx '<!-- version: 1 -->' docs/rules/700-FRAMEWORKS.md
grep -Fx '<!-- version: 1 -->' docs/rules/710-TAURI.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.5.fix.1.md').read_text(encoding='utf-8')
assert re.search(r'## Statut\s+PASS\s', history)
frameworks = Path('docs/rules/700-FRAMEWORKS.md').read_text(encoding='utf-8')
for phrase in (
'# Règles de profils framework',
"Ownership des commandes d'intégration",
'PGR MUST NOT appliquer une règle globale « tout `gen/` est ignoré »',
'Les profils spécifiques utilisent la plage `710` à `799`.',
):
assert phrase in frameworks, phrase
tauri = Path('docs/rules/710-TAURI.md').read_text(encoding='utf-8')
for phrase in (
'# Profil Tauri 2',
'PGR MUST NOT imposer Vite, TypeScript, npm, pnpm, yarn, Bun, WASM',
"le CLI Tauri est l'owner de l'orchestration",
'VERSION
↓
workspace.package.version
↓
package Cargo du host
↓
version applicative Tauri',
'PGR MUST NOT appliquer en revanche une exclusion universelle de tout répertoire `gen/`',
'## Validation proportionnée',
'de `tauri.conf.json` universel',
):
assert phrase in tauri, phrase
study = Path('docs/studies/001-KSP_GAMES_RECONCILIATION.md').read_text(encoding='utf-8')
assert 'KSP contient `6` applications Desk Tauri et Games `2` hôtes Tauri' in study
assert 'Décision `alpha.6` : classer Tauri `COMMON`' in study
plan = Path('docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md').read_text(encoding='utf-8')
assert '`6` applications Tauri KSP et `2` applications Tauri Games' in plan
assert 'La tranche active `700-FRAMEWORKS.md` et `710-TAURI.md`.' in plan
print('0.0.5 alpha.6 Tauri profile audit: clean (700 activated, Tauri 2 responsibilities bounded, no frontend/layout overreach)')
PY
git diff --check
git add VERSION RULES.md docs/000-README.md docs/architecture/003-RULE_PROFILE_MODEL.md docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md docs/rules/000-README.md docs/rules/700-FRAMEWORKS.md docs/rules/710-TAURI.md docs/studies/001-KSP_GAMES_RECONCILIATION.md deltas/0.0.5/alpha.6.md
git diff --cached --check
git status --short
```
La sortie Git attendue avant ajout du history `alpha.6` est exactement :
```text
M RULES.md
M VERSION
A deltas/0.0.5/alpha.6.md
M docs/000-README.md
M docs/architecture/003-RULE_PROFILE_MODEL.md
M docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
M docs/rules/000-README.md
A docs/rules/700-FRAMEWORKS.md
A docs/rules/710-TAURI.md
M docs/studies/001-KSP_GAMES_RECONCILIATION.md
```
## Transition
### PASS
Créer/appliquer `history/0.0.5/alpha.6.md`, committer/pousser `0.0.5-alpha.6`, puis poursuivre à `0.0.5-alpha.7` pour décider si une skeleton specification Tauri apporte réellement une valeur de composition au-dessus des profils existants.
### FAIL
Rester dans `0.0.5-alpha.6.fix.M` ou REPLAN si le profil exige encore une valeur applicative arbitraire. Aucun skeleton Tauri ne doit être créé tant que le profil framework n'est pas correctement fermé.

3
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 13 -->
<!-- version: 14 -->
# Documentation PGR
@@ -27,6 +27,7 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
- [`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.
- [`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.
- [`rules/700-FRAMEWORKS.md`](rules/700-FRAMEWORKS.md) et [`rules/710-TAURI.md`](rules/710-TAURI.md) — activation de la famille framework et premier profil Tauri 2 issu de la réconciliation KSP/Games.
## Points d'entrée de 0.0.4

10
docs/architecture/003-RULE_PROFILE_MODEL.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/003-RULE_PROFILE_MODEL.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Modèle de profils de règles PGR
@@ -194,6 +194,14 @@ Aucune contradiction non résolue de même niveau n'a été identifiée entre le
La revue beta n'a pas justifié l'activation d'une famille `700 — frameworks` ou `800 — architecture`. Les règles réellement transversales rencontrées restent déjà possédées par `RULES.md`, les familles existantes ou le présent modèle architectural.
## Activation de la famille framework en `0.0.5`
La réconciliation indépendante de KSP et Games apporte le premier framework suffisamment répété pour activer la famille `700` : Tauri 2. Le profil `710-TAURI.md` se compose au-dessus de Rust/Cargo et, selon les targets, des profils plateforme applicables.
Cette activation ne change pas la hiérarchie : Tauri ne devient propriétaire ni des règles Rust générales, ni d'Android, ni du choix du frontend. Il possède uniquement l'orchestration Tauri, sa configuration/capabilities, ses hooks, sa version applicative et les gates d'intégration propres au framework.
La famille `800 — architecture` reste réservée : aucune règle nouvelle n'en justifie encore la matérialisation.
La réconciliation a également confirmé qu'une règle générale ne doit pas être recopiée comme si le profil spécifique en devenait propriétaire. Un profil peut rappeler une conséquence spécifique au contexte, mais doit référencer l'owner général lorsque le contrat lui-même n'est pas spécialisé.
## Instanciation par skeleton

8
docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Plan 0.0.5 — réconciliation réelle avec KSP et sasedev-games
@@ -94,9 +94,11 @@ Cette tranche ne réimporte pas `audit_rust_general_rules.py` en bloc et ne réi
### alpha.6 — premier profil framework : Tauri
Si la revue de `alpha.1` reste confirmée, activer la famille `700 — frameworks` et créer un profil Tauri fondé uniquement sur les invariants communs aux deux corpus : composition avec Rust/Cargo, ownership du build Tauri, hooks frontend, version produit, artefacts générés, configuration sensible et gates de développement/build.
La preuve commune est confirmée : `6` applications Tauri KSP et `2` applications Tauri Games partagent Tauri 2, un host Rust/Cargo, `tauri-build`, `tauri.conf.json`, des capability files, des hooks frontend et un `frontendDist`. Les valeurs applicatives divergent suffisamment pour exclure toute copie de ports, fenêtres, CSP, bundles, plugins ou commandes frontend particulières.
Les versions exactes de dépendances, ports, fenêtres, plugins, bundles et chemins applicatifs restent des décisions destinataire. Vite/Web/WASM n'entrent pas automatiquement dans ce profil.
La tranche active `700-FRAMEWORKS.md` et `710-TAURI.md`. Le profil Tauri possède l'orchestration du build/intégration, la configuration et les capabilities, la relation de version produit et la sélection des gates Tauri. Il impose qu'une preuve d'intégration passe par le CLI Tauri lorsque la propriété dépend de ses hooks ou de son bundling ; `cargo check` et le build frontend direct restent des preuves ciblées, pas des substituts.
Vite/Web/WASM et le package manager frontend ne deviennent pas des profils implicites. La politique `gen/` n'est pas généralisée : les sorties purement reproductibles restent générées, mais les projets mobiles modifiés intentionnellement doivent être classifiés selon leur rôle réel.
### alpha.7 — décision de skeleton Tauri

4
docs/rules/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/000-README.md -->
<!-- version: 12 -->
<!-- version: 13 -->
# Index des règles PGR
@@ -21,6 +21,8 @@ Les règles générales actuellement nécessaires restent dans `RULES.md`. La fa
- [`520-JAVA_MAVEN_GRADLE.md`](520-JAVA_MAVEN_GRADLE.md) — profil Java et spécialisations de build Maven/Gradle.
- [`600-PLATFORMS.md`](600-PLATFORMS.md) — contrat commun des profils plateforme.
- [`610-ANDROID.md`](610-ANDROID.md) — profil plateforme Android et règles réutilisables de compatibilité, packaging et validation.
- [`700-FRAMEWORKS.md`](700-FRAMEWORKS.md) — contrat commun des profils framework et de leur composition avec les owners déjà applicables.
- [`710-TAURI.md`](710-TAURI.md) — profil Tauri 2 et règles réutilisables d'orchestration native/frontend, sécurité et validation.
Le modèle transversal d'ownership, d'applicabilité et de composition est décrit dans [`../architecture/003-RULE_PROFILE_MODEL.md`](../architecture/003-RULE_PROFILE_MODEL.md).

105
docs/rules/700-FRAMEWORKS.md Normal file
View File

@@ -0,0 +1,105 @@
<!-- file: docs/rules/700-FRAMEWORKS.md -->
<!-- version: 1 -->
# Règles de profils framework
## Scope
Cette famille définit le contrat commun des profils liés à un framework réellement utilisé par le projet.
Un framework peut combiner plusieurs owners déjà applicables — langage/écosystème, plateforme, frontend, packaging ou runtime — sans devenir propriétaire de leurs règles générales. Son profil possède uniquement les contraintes et l'orchestration ajoutées par le framework lui-même.
## Responsabilités de la famille
Un profil framework MAY posséder les règles spécifiques concernant notamment :
- les fichiers de configuration réellement possédés par le framework ;
- la relation entre plusieurs toolchains que le framework orchestre ;
- les commandes de développement, build, packaging ou génération qui passent par son CLI ;
- les hooks exécutés par ce CLI et leur ordre de responsabilité ;
- les permissions, capabilities, manifests ou métadonnées propres au framework ;
- les artefacts générés par le framework et leur classification source/généré ;
- la cohérence de version lorsque le framework possède une version applicative distincte ou dérivée ;
- les gates d'intégration que les outils sous-jacents ne prouvent pas isolément.
Un profil framework MUST NOT recopier les règles d'un langage, d'une plateforme ou d'un build tool lorsqu'elles restent valides sans spécialisation.
## Composition
Un framework s'ajoute aux profils réellement applicables au projet.
Par exemple :
```text
GENERAL
+ Rust / Cargo
+ Tauri
```
ou, pour une cible Android :
```text
GENERAL
+ Rust / Cargo
+ Android
+ Tauri
```
La présence d'un frontend WebView n'active pas automatiquement un futur profil Web/Vite/WASM. Ces technologies restent sélectionnées selon les faits du projet et leurs propres owners.
## Ownership des commandes d'intégration
Lorsqu'un framework possède un CLI qui orchestre plusieurs étapes, la validation de l'intégration SHOULD utiliser ce CLI plutôt que rejouer manuellement ses sous-commandes comme si elles prouvaient le même contrat.
Une commande sous-jacente reste utile pour une preuve ciblée : compiler le backend ne prouve pas les hooks frontend ; construire le frontend seul ne prouve pas l'intégration native ; un build framework complet n'est pas requis pour une modification purement documentaire qui n'invalide aucune de ces propriétés.
La gate sélectionnée reste proportionnée au scope et à la maturité conformément à [`400-VALIDATION.md`](400-VALIDATION.md).
## Sources, générés et configuration locale
Un framework MAY produire des répertoires générés, projets de plateforme, schémas, bindings ou artefacts de build. Leur simple origine framework ne suffit pas à décider leur politique Git.
Le profil spécifique doit distinguer :
```text
source intentionnelle
configuration durable
artefact reproductible
généré modifié intentionnellement
généré purement transitoire
secret / configuration locale
```
PGR MUST NOT appliquer une règle globale « tout `gen/` est ignoré » ou « tout généré est versionné » sans examiner le rôle réel de l'artefact.
Les secrets et valeurs locales restent possédés par les règles générales et les profils plateforme applicables.
## Version du framework et version produit
La version du framework/de ses dépendances et la version du produit sont deux contrats distincts.
Un projet MAY utiliser une plage compatible, un pin ou une politique de mise à jour adaptée au framework ; PGR ne copie pas une version observée dans un projet source comme règle générale.
Lorsqu'un framework expose une version applicative qui représente la même unité de release que `VERSION`, le profil spécifique doit définir une source de vérité ou une synchronisation explicite afin d'éviter plusieurs valeurs indépendantes.
## Validation spécialisée
Un profil framework doit expliquer ce que prouvent ses commandes propres et ce qu'elles ne prouvent pas.
Selon le scope, la preuve peut être :
- un check du langage/backend ;
- un build/test frontend ;
- un lancement framework avec smoke ciblé ;
- un build/package framework ;
- une validation de plateforme réelle lorsque le framework cible Android, iOS ou une autre plateforme.
Aucune de ces catégories n'est obligatoire à chaque tranche par simple présence du framework.
## Nomenclature documentaire
Le document `700-FRAMEWORKS.md` possède le contrat commun de la famille.
Les profils spécifiques utilisent la plage `710` à `799`. Leur numéro sert à la navigation et ne représente ni priorité normative, ni version du framework.
La résolution avec les autres profils suit [`../architecture/003-RULE_PROFILE_MODEL.md`](../architecture/003-RULE_PROFILE_MODEL.md).

141
docs/rules/710-TAURI.md Normal file
View File

@@ -0,0 +1,141 @@
<!-- file: docs/rules/710-TAURI.md -->
<!-- version: 1 -->
# Profil Tauri 2
## Rôle et applicabilité
Ce document possède les règles réutilisables propres à une application utilisant Tauri 2 comme host natif et orchestrateur d'intégration entre un backend Rust et un frontend WebView.
Il complète [`700-FRAMEWORKS.md`](700-FRAMEWORKS.md) et [`510-RUST_CARGO.md`](510-RUST_CARGO.md). Les profils plateforme réellement ciblés, par exemple [`610-ANDROID.md`](610-ANDROID.md), restent applicables et possèdent leurs contraintes de SDK, packaging et smoke de plateforme.
Le profil est volontairement borné à Tauri 2. Une future génération incompatible du framework doit être réévaluée avant d'hériter automatiquement de ces règles.
## Composition avec le frontend
Tauri ne détermine pas à lui seul le framework frontend, le bundler ou le package manager du projet.
PGR MUST NOT imposer Vite, TypeScript, npm, pnpm, yarn, Bun, WASM ou une arborescence frontend particulière uniquement parce que Tauri est utilisé.
Le frontend peut être possédé par son propre profil ou par les règles locales du projet. Le profil Tauri possède seulement le contrat d'intégration entre ce frontend et le host natif.
## Layout et fichiers possédés par Tauri
PGR MUST NOT imposer universellement un répertoire `src-tauri/` ni recopier le layout d'un corpus source. Le projet peut utiliser le layout standard de Tauri ou une intégration colocalisée différente lorsque la toolchain la supporte clairement.
Les éléments suivants appartiennent néanmoins au scope Tauri lorsqu'ils existent :
- le manifeste Cargo du host natif ;
- l'intégration build-time Tauri, généralement via `tauri-build` ;
- la configuration Tauri supportée par la version du framework, par exemple `tauri.conf.json` ;
- les capability files et permissions Tauri ;
- les icônes, ressources ou métadonnées de bundle référencées par la configuration ;
- les projets ou fichiers de plateforme produits/consommés par la toolchain Tauri.
Leur emplacement exact reste une décision du projet tant qu'il est supporté par la toolchain retenue.
## Ownership du build et hooks frontend
Lorsqu'une validation concerne l'intégration Tauri complète, le CLI Tauri est l'owner de l'orchestration.
Si `beforeDevCommand`, `beforeBuildCommand` ou un hook Tauri équivalent est configuré, la gate d'intégration SHOULD invoquer le CLI Tauri afin que ce hook soit exécuté dans le contexte prévu.
Ainsi :
```text
cargo check / cargo clippy
→ preuve Rust ciblée
frontend build/test direct
→ preuve frontend ciblée
Tauri CLI dev/build
→ preuve d'orchestration Tauri + hooks correspondants
```
Un projet MUST NOT considérer `npm run build`, `cargo build` ou une autre sous-commande isolée comme équivalente à un build Tauri lorsque la propriété à valider dépend des hooks, de `frontendDist`, des capabilities, du contexte Tauri ou du bundling.
Le CLI MAY être invoqué via `cargo tauri`, un script du package manager frontend ou une autre forme officiellement supportée. PGR n'impose pas le package manager qui sert de lanceur.
## `devUrl`, `frontendDist` et sorties frontend
`devUrl` et `frontendDist` doivent pointer vers les entrées/sorties réellement possédées par la chaîne frontend du projet.
PGR ne fixe ni port, ni nom de répertoire de distribution, ni profondeur relative universelle.
Le répertoire produit par le frontend est un artefact de build lorsqu'il est reproductible ; il SHOULD rester hors du source control sauf besoin explicite contraire. La configuration Tauri qui le référence reste, elle, source durable.
## Version produit
Lorsque l'application Tauri appartient au même release train que le projet, `VERSION` reste la version canonique de cette unité de release.
Pour Tauri 2, une configuration qui omet la propriété applicative `version` peut utiliser la version du package Cargo du host. Lorsqu'un workspace PGR hérite déjà `workspace.package.version`, cette chaîne SHOULD être préférée si elle évite une duplication sans perdre d'information :
```text
VERSION
↓
workspace.package.version
↓
package Cargo du host
↓
version applicative Tauri
```
Si une version Tauri explicite est conservée dans la configuration, elle MUST représenter la même release ou documenter clairement pourquoi elle constitue une unité indépendante.
Les numéros de version propres aux plateformes, par exemple Android `versionCode`, restent possédés par le profil plateforme concerné et ne sont pas assimilés au SemVer produit.
## Capabilities, permissions et frontière WebView/native
Les capability files et permissions Tauri sont du source de sécurité et SHOULD être versionnés lorsqu'ils définissent intentionnellement la surface exposée au frontend.
Le projet SHOULD accorder uniquement les permissions nécessaires aux fenêtres/webviews concernées. Ajouter un plugin ou une commande native ne justifie pas automatiquement une capability globale plus large.
Les schémas générés référencés par les capability files servent à l'outillage et à la validation de configuration ; ils ne deviennent pas pour autant la source normative de la politique de permissions.
Toute permission distante, origine distante ou extension de scope sensible doit être explicitement justifiée et validée comme frontière de sécurité.
## Plugins, CSP, fenêtres et bundles
PGR ne définit aucun catalogue de plugins Tauri obligatoires.
Plugins, CSP, nombre de fenêtres, labels, tailles, ports, `bundle.active`, targets de bundle, icônes et ressources restent des décisions du produit ou de la plateforme tant qu'aucun invariant plus général ne les impose.
Une règle locale MAY renforcer ces choix. Elle ne doit pas être remontée dans le profil Tauri uniquement parce qu'elle apparaît dans plusieurs applications d'un même projet.
## Artefacts générés et projets mobiles
Les dépendances frontend téléchargées et sorties de build reproductibles, telles que `node_modules/` ou le `frontendDist`, SHOULD rester hors Git.
PGR MUST NOT appliquer en revanche une exclusion universelle de tout répertoire `gen/`. Tauri peut générer des projets de plateforme qui deviennent ensuite le lieu de personnalisations Android/iOS intentionnelles. Le projet doit classifier chaque sous-arbre : reproductible/transitoire, configuration durable ou généré modifié volontairement.
Les secrets de signature, keystores, credentials et fichiers locaux restent hors Git conformément aux règles générales et aux profils plateforme applicables.
## Validation proportionnée
| Scope modifié | Preuve Tauri normalement pertinente | Ce que cette preuve ne remplace pas |
|-------------------------------------------------|------------------------------------------------------------------------|------------------------------------------------------|
| backend Rust uniquement | gates Rust/Cargo sélectionnées | frontend, hooks, WebView ou packaging |
| frontend uniquement | build/tests/smoke du frontend selon son owner | host natif ou packaging Tauri |
| hooks, config, capabilities, IPC ou intégration | `tauri dev` ou équivalent + smoke ciblé | package release de plateforme |
| bundling, ressources ou version packagée | `tauri build` ou équivalent + inspection/smoke de l'artefact | exigences d'un store ou d'une plateforme non exercée |
| Android/iOS | commande mobile Tauri applicable + gates du profil plateforme concerné | autres plateformes |
La syntaxe exacte de la commande dépend du lanceur choisi (`cargo`, npm, pnpm, etc.) et de la plateforme. Le delta/plan du projet doit fournir la commande concrète.
Un `cargo check` direct MAY rester utile pour une modification Rust ciblée, mais il ne constitue pas un smoke Tauri complet. Inversement, un full `tauri build` n'est pas requis lorsqu'aucune propriété d'intégration ou de packaging n'a été invalidée.
## Ce que le profil n'impose pas
Ce profil ne crée pas :
- de `tauri.conf.json` universel ;
- de port de développement par défaut PGR ;
- de frontend Vite/WASM obligatoire ;
- de plugin obligatoire ;
- de nombre ou taille de fenêtres ;
- de politique de bundle unique ;
- de layout `src-tauri/` obligatoire ;
- de version exacte de Tauri, `tauri-build` ou du CLI.
Ces décisions appartiennent au projet, à un profil plus spécifique ou à une future skeleton specification seulement lorsqu'une valeur réutilisable est réellement démontrée.

16
docs/studies/001-KSP_GAMES_RECONCILIATION.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/studies/001-KSP_GAMES_RECONCILIATION.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Étude de réconciliation PGR / KSP / sasedev-games
@@ -149,13 +149,19 @@ L'orchestrateur `audit_rust_workspace_rules.py` est un pattern d'ergonomie utile
### Tauri
Tauri est réellement présent dans les deux corpus et n'est plus un exemple isolé : KSP contient plusieurs applications Desk Tauri, Games contient plusieurs hôtes Tauri. Les deux familles observées utilisent Tauri 2 avec un package Rust, `tauri-build`, un frontend privé, des hooks `beforeDevCommand` / `beforeBuildCommand`, un `frontendDist` dédié et une validation qui doit passer par la commande Tauri lorsque l'intégration complète est concernée.
Tauri est réellement présent dans les deux corpus et n'est plus un exemple isolé : KSP contient `6` applications Desk Tauri et Games `2` hôtes Tauri. Les `8` applications observées utilisent Tauri 2, un package Rust avec `tauri-build`, une configuration `tauri.conf.json`, des capability files, des hooks frontend et un `frontendDist` dédié.
Cette répétition indépendante justifie de classer Tauri `COMMON` et de rouvrir la famille framework `700` jusque-là différée. Une tranche dédiée de `0.0.5` peut créer un profil Tauri si elle reste limitée aux responsabilités réellement communes : ownership du build Tauri, relation avec Rust/Cargo, hooks frontend, version produit, generated outputs, secrets/resources et gates `cargo tauri dev/build`.
Les différences sont tout aussi importantes que les points communs : KSP possède deux fenêtres par Desk, active le bundling et utilise des hooks npm simples ; Games utilise une fenêtre, désactive le bundling dans les POC observés et l'un de ses hooks construit d'abord un frontend WASM via un script Python. Les CSP, ports, identifiants, ressources et plugins ne sont pas uniformes.
Le profil ne doit pas imposer les ports, fenêtres, bundles, assets, plugins, packages npm ni chemins de ressources propres aux applications observées.
Toutes les configurations observées omettent une version Tauri explicite tandis que leur package Cargo hérite de la version workspace. Cette pratique est compatible avec le mécanisme Tauri 2 qui peut utiliser la version du package Cargo lorsque `tauri.conf` n'en fournit pas ; elle donne une base commune utile pour éviter une duplication de version dans un projet à release train unique.
Une skeleton specification Tauri peut être créée dans une tranche suivante seulement si le profil obtenu suffit à définir des décisions destinataire réutilisables sans fabriquer un `tauri.conf.json` universel.
Les deux corpus versionnent leurs capability files et ignorent les dépendances/sorties frontend reproductibles. Ils ignorent également `gen/`, mais ce dernier point n'est pas généralisé : les projets mobiles Tauri peuvent contenir sous leur projet généré des personnalisations de plateforme intentionnelles qui doivent être classifiées avant toute politique Git.
Décision `alpha.6` : classer Tauri `COMMON`, activer `700-FRAMEWORKS.md` et créer `710-TAURI.md`. Le profil possède l'orchestration Tauri : host Rust, configuration/capabilities, hooks frontend, version produit et gates d'intégration. Il ne possède pas Vite, WASM, npm, les ports, fenêtres, CSP, bundles ou plugins particuliers.
La règle de validation commune est également confirmée : lorsqu'une propriété dépend de `beforeDevCommand`, `beforeBuildCommand`, `frontendDist`, des capabilities ou du bundling, une sous-commande directe telle que `npm run build` ou `cargo build` ne prouve pas l'intégration Tauri complète. La gate doit passer par le CLI Tauri ou une forme officiellement équivalente ; les sous-commandes restent pertinentes pour leurs preuves ciblées.
Une skeleton specification Tauri reste reportée à `alpha.7`, où elle doit démontrer une valeur de composition réelle sans fabriquer un `tauri.conf.json` universel.
### Web / Vite / WASM

133
history/0.0.5/alpha.6.md Normal file
View File

@@ -0,0 +1,133 @@
<!-- file: history/0.0.5/alpha.6.md -->
<!-- version: 1 -->
# History 0.0.5-alpha.6 — premier profil framework Tauri 2
## Statut
FAIL
La gate opérateur de `0.0.5-alpha.6` exécutée le `2026-09-25` valide la présence du profil Tauri, la suite Python globale, les trois audits Markdown et le scope Git, mais le contrôle structurel ciblé fourni par le delta ne s'exécute pas : son heredoc contient une chaîne multilignes entre quotes simples et Python termine avec `SyntaxError: unterminated string literal`.
La revue fonctionnelle immédiatement associée apporte en plus une clarification de scope nécessaire : pour les projets Tauri que l'organisation contrôle, le host doit hériter intégralement des règles Rust sélectionnées tandis que le frontend et ses choix de stack appartiennent à un owner/skeleton distinct. Le profil livré ne sépare pas encore assez explicitement cette convention d'instanciation du contrat Tauri universel.
Le statut global est donc `FAIL`. Les preuves mécaniques réussies restent valides, mais la gate complète n'est pas passée et le contrat doit être précisé avant de continuer.
## Baseline et version
La tranche part du commit opérateur de `0.0.5-alpha.5.fix.1` :
```text
81c7a72 0.0.5-alpha.5.fix.1
```
Le push vers `origin/master` a réussi avant l'application de `alpha.6`.
La version contrôlée après application du delta est :
```text
0.0.5-alpha.6
```
`history/0.0.5/alpha.5.fix.1.md`, `deltas/0.0.5/alpha.6.md`, `docs/rules/700-FRAMEWORKS.md` et `docs/rules/710-TAURI.md` sont présents. `history/0.0.5/alpha.6.md` était absent pendant la gate.
## Validation opérateur observée
L'opérateur a fourni les sorties du `2026-09-25` depuis `~/Projects/pgr`, à `08:15:06`–`08:42:54`.
Les contrôles de présence, statut et révision ont réussi :
```text
history/0.0.5/alpha.5.fix.1.md PASS
RULES.md version 11
docs/rules/000-README.md version 13
docs/architecture/003-RULE_PROFILE_MODEL.md version 4
docs/rules/700-FRAMEWORKS.md version 1
docs/rules/710-TAURI.md version 1
```
La suite Python globale a exécuté `37` tests, tous réussis :
```text
Ran 37 tests in 0.505s
OK
```
Les audits documentaires affichent :
```text
Markdown header audit: clean (146 file(s))
Markdown table audit: clean (7 table(s), 146 file(s))
Markdown link audit: clean (148 local link(s), 146 file(s))
```
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
Le scope Git observé est exactement :
```text
M RULES.md
M VERSION
A deltas/0.0.5/alpha.6.md
M docs/000-README.md
M docs/architecture/003-RULE_PROFILE_MODEL.md
M docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
M docs/rules/000-README.md
A docs/rules/700-FRAMEWORKS.md
A docs/rules/710-TAURI.md
M docs/studies/001-KSP_GAMES_RECONCILIATION.md
```
## Échec du contrôle ciblé
Le heredoc de validation contient cette valeur sous forme de chaîne Python délimitée par des quotes simples sur plusieurs lignes :
```text
VERSION
↓
workspace.package.version
↓
package Cargo du host
↓
version applicative Tauri
```
Python l'interprète comme une chaîne non terminée et produit :
```text
SyntaxError: unterminated string literal (detected at line 21)
```
Le message de succès `0.0.5 alpha.6 Tauri profile audit: clean (...)` n'a donc pas été produit. Une gate obligatoire du delta n'est pas passée.
## Clarification fonctionnelle
La revue opérateur précise le modèle attendu pour les projets contrôlés par l'organisation :
- une application Tauri est d'abord un host Rust/Cargo et doit hériter des mêmes conventions Rust que les autres crates/applications du projet ;
- les exemples générés par Tauri ne justifient pas d'exceptions implicites aux règles Rust locales ;
- le frontend est un scope distinct ; pour les projets contrôlés, le layout `frontend/`, Vite, TypeScript, Sass et Bootstrap constituent des préférences de skeleton, pas des invariants universels de Tauri ;
- `cargo tauri add` n'est pas la voie obligatoire d'intégration des plugins : l'ajout explicite des dépendances Cargo/frontend et du code d'initialisation à partir de la documentation du plugin est une pratique volontaire ;
- WASM doit normalement rester une unité séparée et n'hérite pas des règles Tauri simplement parce qu'il partage éventuellement le même dépôt ;
- le POC Tauri mobile Games non concluant ne permet pas de conclure que Tauri Android/iOS est inadapté à d'autres projets.
Cette clarification révèle en parallèle un écart plus ancien du profil Rust PGR : plusieurs conventions strictes déjà retenues dans la conception initiale ne sont pas encore toutes matérialisées dans `510-RUST_CARGO.md`. Ce sujet dépasse le fix Tauri et doit devenir une tranche normale distincte.
## Résultat
`0.0.5-alpha.6` est enregistré `FAIL`.
Le profil framework/Tauri est une base utile et les preuves mécaniques générales sont propres, mais le gate ciblé doit être corrigé et la frontière entre profil Tauri universel, héritage Rust et conventions de skeleton doit être explicitée.
## Transition
Appliquer le présent history puis committer/pousser `0.0.5-alpha.6`.
La correction suivante est :
```text
0.0.5-alpha.6.fix.1
```
Elle doit corriger le heredoc de validation et la composition Tauri/Rust/frontend sans modifier encore `510-RUST_CARGO.md` ni créer de skeleton. Le plan doit ensuite réserver une tranche normale à la complétude du profil Rust strict avant la décision de skeleton Tauri.