0.0.5-alpha.6.fix.1
This commit is contained in:
178
deltas/0.0.5/alpha.6.fix.1.md
Normal file
178
deltas/0.0.5/alpha.6.fix.1.md
Normal file
@@ -0,0 +1,178 @@
|
||||
<!-- file: deltas/0.0.5/alpha.6.fix.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.0.5-alpha.6.fix.1 — composition Tauri/Rust/frontend et gate corrigé
|
||||
|
||||
## Baseline et version
|
||||
|
||||
Baseline attendue : commit opérateur complet de `0.0.5-alpha.6`, réalisé après application de `history/0.0.5/alpha.6.md` avec statut `FAIL`.
|
||||
|
||||
Version avant application :
|
||||
|
||||
```text
|
||||
0.0.5-alpha.6
|
||||
```
|
||||
|
||||
Version après application :
|
||||
|
||||
```text
|
||||
0.0.5-alpha.6.fix.1
|
||||
```
|
||||
|
||||
## Cause du fix
|
||||
|
||||
Deux défauts appartiennent au scope exact de `alpha.6` :
|
||||
|
||||
1. le heredoc Python de la gate `alpha.6` contient une chaîne multilignes entre quotes simples et échoue avec `SyntaxError: unterminated string literal` ;
|
||||
2. le profil livré ne distingue pas encore assez explicitement le contrat Tauri universel des conventions de structure/stack retenues pour les projets Tauri que l'organisation contrôle.
|
||||
|
||||
La clarification opérateur confirme aussi un écart plus large dans le profil Rust strict PGR. Ce troisième sujet ne doit pas être absorbé par le présent fix : il est replanifié en `alpha.7`, puis la décision de skeleton Tauri passe à `alpha.8`.
|
||||
|
||||
## Scope
|
||||
|
||||
REPLACE :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
docs/architecture/003-RULE_PROFILE_MODEL.md
|
||||
docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
|
||||
docs/rules/700-FRAMEWORKS.md
|
||||
docs/rules/710-TAURI.md
|
||||
docs/studies/001-KSP_GAMES_RECONCILIATION.md
|
||||
```
|
||||
|
||||
ADD :
|
||||
|
||||
```text
|
||||
deltas/0.0.5/alpha.6.fix.1.md
|
||||
```
|
||||
|
||||
DELETE : aucun.
|
||||
|
||||
## Décisions corrigées
|
||||
|
||||
Le fix précise que :
|
||||
|
||||
- un host Tauri est un projet Rust/Cargo et n'obtient aucune exception implicite aux règles Rust sélectionnées ;
|
||||
- un projet externe/imposé peut conserver des règles différentes via le niveau project-specific ou des overrides explicites ;
|
||||
- le profil Tauri universel ne possède pas le choix `frontend/`, Vite, TypeScript, Sass, Bootstrap ou du package manager ;
|
||||
- ces choix forment un candidat de skeleton pour les futurs projets contrôlés ;
|
||||
- WASM n'est pas une composante implicite de Tauri et reste normalement une unité séparée avec ses propres owners ;
|
||||
- `cargo tauri add` est une commodité, pas une obligation : l'ajout explicite des dépendances et de l'initialisation à partir de la documentation officielle des plugins est valide et peut être préféré pour garder le contrôle des manifests ;
|
||||
- un POC mobile non concluant pour Games ne permet pas de rejeter Tauri Android/iOS pour d'autres produits.
|
||||
|
||||
## REPLAN borné
|
||||
|
||||
La clarification révèle qu'une décision Rust déjà retenue historiquement n'est pas complètement matérialisée dans `510-RUST_CARGO.md`. `alpha.7` devient donc une tranche normale de complétude du profil Rust strict, puis l'ancienne décision de skeleton Tauri devient `alpha.8`.
|
||||
|
||||
Le présent fix ne modifie pas `510-RUST_CARGO.md` et n'ajoute aucun nouvel audit Rust : cela constituerait un nouveau scope fonctionnel.
|
||||
|
||||
## Validation opérateur
|
||||
|
||||
Après application du history `FAIL` de `alpha.6`, commit/push de cette tranche, puis application du présent fix :
|
||||
|
||||
```bash
|
||||
test "$(cat VERSION)" = '0.0.5-alpha.6.fix.1'
|
||||
test -f history/0.0.5/alpha.6.md
|
||||
test -f deltas/0.0.5/alpha.6.fix.1.md
|
||||
test ! -e history/0.0.5/alpha.6.fix.1.md
|
||||
|
||||
grep -A2 '^## Statut$' history/0.0.5/alpha.6.md | grep -Fx 'FAIL'
|
||||
grep -Fx '<!-- version: 2 -->' docs/rules/700-FRAMEWORKS.md
|
||||
grep -Fx '<!-- version: 2 -->' docs/rules/710-TAURI.md
|
||||
grep -Fx '<!-- version: 5 -->' docs/architecture/003-RULE_PROFILE_MODEL.md
|
||||
grep -Fx '<!-- version: 5 -->' docs/studies/001-KSP_GAMES_RECONCILIATION.md
|
||||
grep -Fx '<!-- version: 6 -->' docs/plans/005-V0_0_5_RECONCILIATION_PLAN.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.6.md').read_text(encoding='utf-8')
|
||||
assert re.search(r'## Statut\s+FAIL\s', history)
|
||||
|
||||
frameworks = Path('docs/rules/700-FRAMEWORKS.md').read_text(encoding='utf-8')
|
||||
for phrase in (
|
||||
"Il n'annule pas silencieusement les conventions des owners qu'il compose.",
|
||||
'Un projet existant ou imposé de l'extérieur MAY conserver des contraintes différentes.',
|
||||
'## Profil framework et convention d'instanciation',
|
||||
):
|
||||
assert phrase in frameworks, phrase
|
||||
|
||||
tauri = Path('docs/rules/710-TAURI.md').read_text(encoding='utf-8')
|
||||
for phrase in (
|
||||
'## Héritage Rust du host Tauri',
|
||||
'Tauri ne crée aucune exception implicite aux règles Rust sélectionnées par le projet.',
|
||||
'PGR MUST NOT imposer universellement Vite, TypeScript, Sass, Bootstrap, Tailwind CSS',
|
||||
'WASM n'est pas une composante implicite d'un projet Tauri.',
|
||||
'PGR ne définit aucun catalogue de plugins Tauri obligatoires et ne rend pas `cargo tauri add` obligatoire.',
|
||||
'Un POC Tauri mobile non concluant pour un produit particulier ne constitue pas une preuve',
|
||||
):
|
||||
assert phrase in tauri, phrase
|
||||
|
||||
version_chain = '\n'.join((
|
||||
'VERSION',
|
||||
'↓',
|
||||
'workspace.package.version',
|
||||
'↓',
|
||||
'package Cargo du host',
|
||||
'↓',
|
||||
'version applicative Tauri',
|
||||
))
|
||||
assert version_chain in tauri
|
||||
|
||||
study = Path('docs/studies/001-KSP_GAMES_RECONCILIATION.md').read_text(encoding='utf-8')
|
||||
assert 'candidat de skeleton pour projets contrôlés' in study
|
||||
assert 'WASM n'est pas une dépendance implicite de Tauri' in study
|
||||
assert 'écart antérieur dans le profil Rust PGR' in study
|
||||
|
||||
plan = Path('docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md').read_text(encoding='utf-8')
|
||||
assert '### alpha.7 — complétude du profil Rust strict' in plan
|
||||
assert '### alpha.8 — décision de skeleton Tauri pour projets contrôlés' in plan
|
||||
|
||||
print('0.0.5 alpha.6.fix.1 Tauri composition audit: clean (Rust inherited, frontend/skeleton separated, WASM independent, gate valid)')
|
||||
PY
|
||||
|
||||
git diff --check
|
||||
|
||||
git add VERSION \
|
||||
docs/architecture/003-RULE_PROFILE_MODEL.md \
|
||||
docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md \
|
||||
docs/rules/700-FRAMEWORKS.md docs/rules/710-TAURI.md \
|
||||
docs/studies/001-KSP_GAMES_RECONCILIATION.md \
|
||||
deltas/0.0.5/alpha.6.fix.1.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.6.fix.1.md
|
||||
M docs/architecture/003-RULE_PROFILE_MODEL.md
|
||||
M docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
|
||||
M docs/rules/700-FRAMEWORKS.md
|
||||
M docs/rules/710-TAURI.md
|
||||
M docs/studies/001-KSP_GAMES_RECONCILIATION.md
|
||||
```
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Créer/appliquer `history/0.0.5/alpha.6.fix.1.md`, committer/pousser le fix, puis poursuivre à `0.0.5-alpha.7` pour réconcilier les conventions Rust strictes déjà décidées avant toute matérialisation d'un skeleton Tauri.
|
||||
|
||||
### FAIL
|
||||
|
||||
Rester dans `0.0.5-alpha.6.fix.M`. Aucun changement du profil Rust ni skeleton Tauri ne doit être absorbé tant que la frontière Tauri/Rust/frontend n'est pas correctement fermée.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/003-RULE_PROFILE_MODEL.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Modèle de profils de règles PGR
|
||||
|
||||
@@ -117,6 +117,16 @@ Cette relation interne ne modifie pas la hiérarchie globale. Une contrainte de
|
||||
|
||||
Lorsque langage et build tool sont pratiquement indissociables pour le scope visé, PGR peut les documenter dans un même profil si cette fusion évite une séparation artificielle. Le choix du découpage doit suivre les responsabilités réelles, pas une taxonomie rigide.
|
||||
|
||||
## Baseline contrôlée et projet imposé
|
||||
|
||||
La même combinaison de technologies peut être gouvernée avec des degrés de liberté différents.
|
||||
|
||||
Pour une baseline créée et contrôlée par le projet, les profils sélectionnés s'appliquent intégralement puis une skeleton specification MAY fixer des choix réutilisables supplémentaires : layout, stack frontend, conventions de manifests ou organisation des fichiers.
|
||||
|
||||
Pour un projet existant ou imposé par un tiers, PGR doit d'abord préserver les contraintes externes réellement obligatoires. Toute divergence avec le profil préféré devient une règle project-specific ou une exception explicite et bornée ; elle ne modifie pas automatiquement le profil général.
|
||||
|
||||
Cette distinction évite deux erreurs opposées : forcer le skeleton interne d'une organisation sur un dépôt qu'elle ne contrôle pas, ou affaiblir ses propres conventions sous prétexte qu'un framework accepte plusieurs formes.
|
||||
|
||||
## Profils composites
|
||||
|
||||
PGR ne crée pas automatiquement un profil composite pour chaque combinaison possible.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# Plan 0.0.5 — réconciliation réelle avec KSP et sasedev-games
|
||||
|
||||
@@ -96,13 +96,23 @@ Cette tranche ne réimporte pas `audit_rust_general_rules.py` en bloc et ne réi
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
La première livraison active `700-FRAMEWORKS.md` et `710-TAURI.md`, mais la gate opérateur est `FAIL` pour deux raisons : le contrôle Python ciblé du delta contient une chaîne multilignes invalide et la revue fonctionnelle exige de mieux distinguer le profil Tauri universel des conventions d'instanciation des projets contrôlés. `alpha.6.fix.1` corrige donc le gate et explicite que le host Tauri hérite intégralement des règles Rust sélectionnées, que WASM reste normalement une unité séparée et que l'ajout manuel de plugins à partir de leur documentation officielle est une stratégie valide.
|
||||
|
||||
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.
|
||||
Les préférences récurrentes de l'organisation — frontend sous `frontend/`, Vite, TypeScript, Sass, Bootstrap et contrôle explicite des dépendances — sont consignées comme **candidat de skeleton**, pas comme invariants de `710-TAURI.md`. Un projet imposé de l'extérieur peut conserver une structure différente via ses règles project-specific.
|
||||
|
||||
### alpha.7 — décision de skeleton Tauri
|
||||
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. L'échec du POC Tauri mobile Games ne constitue pas un rejet général de Tauri Android/iOS pour les autres produits.
|
||||
|
||||
Vérifier si le profil Tauri obtenu permet une skeleton specification utile sans créer de `tauri.conf.json` universel. Si oui, ajouter une specialization composable au-dessus de `001 + 002 + 700/710`. Sinon, consigner explicitement le report et ne pas matérialiser un skeleton décoratif.
|
||||
### alpha.7 — complétude du profil Rust strict
|
||||
|
||||
La clarification Tauri réexpose une divergence déjà visible dans l'historique de conception : le profil Rust strict retenu pour les projets contrôlés prévoit notamment l'absence de `use` non-trait, les chemins explicites les plus courts, les réexports `use self::...`, les blocs homogènes par type/visibilité, l'ordre alphabétique des blocs monolignes et la séparation des blocs, alors que `510-RUST_CARGO.md` reste partiellement plus permissif.
|
||||
|
||||
Cette tranche doit réconcilier les décisions historiques avec KSP/Games, attribuer chaque propriété au bon owner (`rustfmt`, Clippy, audit existant ou nouvel audit monotâche) et n'automatiser que ce qui peut être contrôlé de façon fiable. Elle ne doit pas réimporter `audit_rust_general_rules.py` en bloc.
|
||||
|
||||
### alpha.8 — décision de skeleton Tauri pour projets contrôlés
|
||||
|
||||
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 `frontend/`, Vite, TypeScript, Sass et Bootstrap, conserve WASM dans une unité séparée par défaut et privilégie l'ajout explicite des plugins à partir de leur documentation plutôt qu'une commande opaque.
|
||||
|
||||
Si les profils Web nécessaires ne sont pas encore assez matérialisés pour posséder proprement ces choix, consigner explicitement le report au lieu de fabriquer un skeleton décoratif ou de faire de `710-TAURI.md` un owner Web de substitution.
|
||||
|
||||
### beta.1 — réconciliation intégrée
|
||||
|
||||
@@ -150,8 +160,9 @@ Un REPLAN est requis si :
|
||||
- le lifecycle de clôture impose des documents ou versions futures sans valeur opérationnelle ;
|
||||
- la revue d'horizon devient un quota de versions à prévoir plutôt qu'un mécanisme de décision ;
|
||||
- l'audit de façade Rust ne peut pas être séparé proprement des conventions strictes KSP/Games ;
|
||||
- le profil Tauri exige de choisir arbitrairement Vite, WASM, des plugins ou un layout d'application ;
|
||||
- le skeleton Tauri n'apporte pas de décisions réutilisables au-delà du profil framework ;
|
||||
- le profil Tauri universel absorbe des choix de skeleton/frontend qui devraient rester project-specific ou appartenir à un owner Web ;
|
||||
- la réconciliation Rust stricte ne peut pas être séparée en owners fiables et audits monotâches ;
|
||||
- le skeleton Tauri n'apporte pas de décisions réutilisables au-delà du profil framework et des conventions explicites de projets contrôlés ;
|
||||
- une autre divergence des corpus apparaît comme un besoin commun critique non couvert par ce plan.
|
||||
|
||||
## Stratégie de validation
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/700-FRAMEWORKS.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Règles de profils framework
|
||||
|
||||
@@ -26,7 +26,7 @@ Un profil framework MUST NOT recopier les règles d'un langage, d'une plateforme
|
||||
|
||||
## Composition
|
||||
|
||||
Un framework s'ajoute aux profils réellement applicables au projet.
|
||||
Un framework s'ajoute aux profils réellement applicables au projet. Il n'annule pas silencieusement les conventions des owners qu'il compose.
|
||||
|
||||
Par exemple :
|
||||
|
||||
@@ -45,8 +45,28 @@ GENERAL
|
||||
+ Tauri
|
||||
```
|
||||
|
||||
Lorsque PGR gouverne la baseline du projet, les règles des profils hérités restent applicables dans leur scope complet tant qu'un override plus spécifique n'est pas documenté. Un framework ne constitue pas à lui seul une justification pour affaiblir une convention de langage, de plateforme ou de sécurité.
|
||||
|
||||
Un projet existant ou imposé de l'extérieur MAY conserver des contraintes différentes. Ces écarts appartiennent alors au niveau project-specific ou à une exception explicite et bornée ; ils ne doivent pas être remontés comme nouvelle règle générale du framework.
|
||||
|
||||
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.
|
||||
|
||||
## Profil framework et convention d'instanciation
|
||||
|
||||
Le profil framework décrit ce qui reste vrai pour toute adoption conforme du framework. Une skeleton specification ou une baseline locale MAY choisir en plus un layout, un bundler, un langage frontend, un package manager ou des bibliothèques préférées pour les projets que l'organisation contrôle.
|
||||
|
||||
Ces valeurs d'instanciation ne deviennent pas des invariants du framework :
|
||||
|
||||
```text
|
||||
profil framework
|
||||
→ responsabilités et contraintes propres au framework
|
||||
|
||||
skeleton / projet local
|
||||
→ choix réutilisables de structure et de stack
|
||||
```
|
||||
|
||||
Cette séparation permet d'appliquer PGR à un projet imposé sans lui forcer le skeleton préféré des nouveaux projets.
|
||||
|
||||
## 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.
|
||||
|
||||
@@ -1,27 +1,45 @@
|
||||
<!-- file: docs/rules/710-TAURI.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# 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.
|
||||
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 host 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.
|
||||
|
||||
## Héritage Rust du host Tauri
|
||||
|
||||
Un host Tauri est un projet Rust/Cargo. Tauri ne crée aucune exception implicite aux règles Rust sélectionnées par le projet.
|
||||
|
||||
Pour un projet dont PGR gouverne la baseline, le host Tauri MUST appliquer le profil Rust/Cargo et les conventions Rust locales retenues exactement comme une autre crate ou application Rust du même projet : édition, lints, safety, erreurs, formatage, façade, chemins canoniques, imports, organisation des sources et audits applicables restent possédés par leur owner Rust.
|
||||
|
||||
Un exemple généré par `create-tauri-app`, une documentation de plugin ou une macro Tauri MAY employer un style différent ; il doit être adapté aux règles Rust du projet lorsqu'il est intégré. La présence de Tauri ne justifie donc pas à elle seule `unwrap`, `expect`, `?`, un `use` non autorisé, un chemin interne non canonique ou un affaiblissement des lints si le profil Rust sélectionné les interdit.
|
||||
|
||||
Un projet Tauri existant ou imposé de l'extérieur MAY conserver d'autres conventions Rust. Ces différences doivent être traitées comme règles project-specific ou overrides explicites, pas comme un relâchement du profil Tauri général.
|
||||
|
||||
## Composition avec le frontend
|
||||
|
||||
Tauri ne détermine pas à lui seul le framework frontend, le bundler ou le package manager du projet.
|
||||
Tauri ne détermine pas à lui seul le framework frontend, le bundler, le langage de style 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é.
|
||||
PGR MUST NOT imposer universellement Vite, TypeScript, Sass, Bootstrap, Tailwind CSS, 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.
|
||||
Le frontend possède ses propres règles et peut être sélectionné par une skeleton specification ou par la baseline locale du projet. Le profil Tauri possède seulement le contrat d'intégration entre ce frontend et le host natif.
|
||||
|
||||
Pour les projets que l'organisation contrôle entièrement, une skeleton MAY choisir une stack frontend par défaut et un layout stable. Cette décision appartient au skeleton et aux futurs profils Web applicables, pas au présent owner Tauri.
|
||||
|
||||
## WASM
|
||||
|
||||
WASM n'est pas une composante implicite d'un projet Tauri. Un package ou projet WASM SHOULD être traité comme une unité distincte appliquant ses propres profils Rust/Web/WASM, même s'il partage le même dépôt ou certaines crates avec une application Tauri.
|
||||
|
||||
Une application Tauri MAY consommer explicitement un artefact WASM lorsqu'un besoin architectural réel le justifie. Cette composition doit alors être documentée comme telle ; elle ne transforme pas les règles WASM en règles Tauri et ne justifie pas de placer systématiquement une chaîne WASM dans les hooks Tauri.
|
||||
|
||||
## 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.
|
||||
PGR MUST NOT imposer universellement un répertoire `src-tauri/` ni recopier le layout de `create-tauri-app`. Le projet peut utiliser le layout standard de Tauri ou une intégration différente lorsque la toolchain la supporte clairement.
|
||||
|
||||
Les éléments suivants appartiennent néanmoins au scope Tauri lorsqu'ils existent :
|
||||
|
||||
@@ -32,7 +50,7 @@ Les éléments suivants appartiennent néanmoins au scope Tauri lorsqu'ils exist
|
||||
- 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.
|
||||
Leur emplacement exact reste une décision du projet ou du skeleton retenu tant qu'il est supporté par la toolchain.
|
||||
|
||||
## Ownership du build et hooks frontend
|
||||
|
||||
@@ -95,11 +113,17 @@ Les schémas générés référencés par les capability files servent à l'outi
|
||||
|
||||
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
|
||||
## Plugins
|
||||
|
||||
PGR ne définit aucun catalogue de plugins Tauri obligatoires.
|
||||
PGR ne définit aucun catalogue de plugins Tauri obligatoires et ne rend pas `cargo tauri add` obligatoire.
|
||||
|
||||
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.
|
||||
Les pages officielles des plugins peuvent décrire à la fois une commande d'ajout automatique et les étapes explicites correspondantes côté Cargo, initialisation Rust et bindings frontend. Un projet MAY préférer appliquer manuellement ces étapes afin que les modifications de `Cargo.toml`, du manifeste frontend et du code d'initialisation restent directement contrôlées et revues.
|
||||
|
||||
Si une commande de commodité telle que `tauri add` est utilisée, les fichiers qu'elle modifie MUST être relus comme toute autre génération avant validation. Le projet ne doit installer que les côtés réellement nécessaires du plugin : dépendance Rust, bindings frontend, capabilities/permissions ou configuration associée selon le cas.
|
||||
|
||||
## CSP, fenêtres et bundles
|
||||
|
||||
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.
|
||||
|
||||
@@ -109,6 +133,8 @@ Les dépendances frontend téléchargées et sorties de build reproductibles, te
|
||||
|
||||
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.
|
||||
|
||||
Un POC Tauri mobile non concluant pour un produit particulier ne constitue pas une preuve que Tauri Android/iOS est inadapté à tous les autres projets. Le support mobile doit être jugé selon le besoin, les ABI, plugins, intégrations natives et gates plateforme du projet concerné.
|
||||
|
||||
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
|
||||
@@ -131,11 +157,12 @@ 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 frontend Vite/TypeScript/Sass/Bootstrap obligatoire ;
|
||||
- de frontend WASM implicite ;
|
||||
- de plugin obligatoire ;
|
||||
- de nombre ou taille de fenêtres ;
|
||||
- de politique de bundle unique ;
|
||||
- de layout `src-tauri/` obligatoire ;
|
||||
- de layout `src-tauri/` ou `frontend/` 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.
|
||||
Ces décisions appartiennent au projet, à un profil plus spécifique ou à une skeleton specification seulement lorsqu'une valeur réutilisable est réellement démontrée.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/001-KSP_GAMES_RECONCILIATION.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Étude de réconciliation PGR / KSP / sasedev-games
|
||||
|
||||
@@ -157,15 +157,27 @@ Toutes les configurations observées omettent une version Tauri explicite tandis
|
||||
|
||||
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.
|
||||
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 à lui seul Vite, TypeScript, Sass, Bootstrap, WASM, le package manager, 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.
|
||||
La revue opérateur de `alpha.6` apporte deux clarifications importantes. Premièrement, dans les projets Tauri que l'organisation contrôle, le host est traité comme n'importe quel projet Rust du même ensemble et doit donc hériter sans exception implicite du profil Rust sélectionné ; un projet imposé de l'extérieur peut conserver d'autres conventions via des overrides project-specific. Deuxièmement, les choix récurrents `frontend/`, Vite, TypeScript, Sass, Bootstrap et ajout explicite des dépendances de plugins décrivent un **candidat de skeleton pour projets contrôlés**, pas le contrat universel de Tauri.
|
||||
|
||||
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.
|
||||
Le POC Tauri mobile de Games n'a pas été concluant pour les besoins Games observés, notamment l'objectif Android/ABI et les contraintes de monétisation envisagées. Cette expérience ne permet pas de rejeter Tauri mobile pour d'autres produits : la capacité reste à évaluer par projet avec les profils plateforme applicables.
|
||||
|
||||
La règle de validation commune reste 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.
|
||||
|
||||
Le CLI Tauri fournit une commande `add`, mais les documentations officielles des plugins détaillent également l'ajout explicite de la dépendance Cargo, l'initialisation Rust et, lorsqu'ils existent, les bindings frontend. PGR ne doit donc pas imposer la commande de commodité : un projet qui privilégie le contrôle manuel des manifests peut suivre explicitement ces étapes et revoir chaque modification.
|
||||
|
||||
### Web / Vite / WASM
|
||||
|
||||
Les deux corpus utilisent Vite dans leurs applications Tauri, mais le Web autonome et la chaîne WASM sont beaucoup plus développés dans Games. Cette preuve suffit à renseigner un futur profil, pas à créer maintenant une règle Web universelle. Classification : `DEFER`.
|
||||
Les corpus et la clarification opérateur permettent désormais de séparer trois choses :
|
||||
|
||||
- le frontend Tauri est un owner distinct du host Rust et du framework Tauri ;
|
||||
- Vite + TypeScript + Sass + Bootstrap constitue un candidat de stack par défaut pour les futurs skeletons de projets contrôlés, mais manque encore de profils Web dédiés dans PGR ;
|
||||
- WASM n'est pas une dépendance implicite de Tauri et doit généralement rester un projet/package séparé appliquant ses propres profils, sauf composition architecturale explicitement voulue.
|
||||
|
||||
La création de profils Web/Vite/TypeScript/Sass reste `DEFER` pour `0.0.5` : cette release peut cadrer la future composition sans matérialiser précipitamment toute la famille Web.
|
||||
|
||||
La même clarification révèle un écart antérieur dans le profil Rust PGR : la conception initiale avait retenu le profil strict sans `use` non-trait, chemins explicites et conventions d'organisation, alors que le `510-RUST_CARGO.md` matérialisé conserve encore une formulation plus permissive. Ce sujet ne doit pas être absorbé par un fix Tauri ; il devient une tranche Rust normale dédiée avant toute décision de skeleton Tauri.
|
||||
|
||||
### Android / JNI
|
||||
|
||||
|
||||
102
history/0.0.5/alpha.6.fix.1.md
Normal file
102
history/0.0.5/alpha.6.fix.1.md
Normal file
@@ -0,0 +1,102 @@
|
||||
<!-- file: history/0.0.5/alpha.6.fix.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.0.5-alpha.6.fix.1 — composition Tauri/Rust/frontend
|
||||
|
||||
## Statut
|
||||
|
||||
FAIL
|
||||
|
||||
La gate opérateur de `0.0.5-alpha.6.fix.1` exécutée le `2026-09-25` valide la suite Python globale, les trois audits Markdown et le scope Git attendu, mais le contrôle structurel ciblé du fix échoue encore avant ses assertions : une phrase contenant l'apostrophe de `l'extérieur` est placée dans une chaîne Python délimitée elle-même par des quotes simples, ce qui produit `SyntaxError: unterminated string literal`.
|
||||
|
||||
La revue opérateur associée apporte en outre une clarification plus complète du modèle Tauri/Rust attendu. Les règles réellement versionnées dans KSP et Games montrent que plusieurs conventions avaient été sous-estimées : layout Tauri direct sans `src-tauri/`, `frontend/` explicite, `lib.rs` façade, `main.rs` launcher mince, `tauri.rs` centralisant l'assemblage et les wrappers `#[tauri::command]`, séparation du WASM et, dans KSP, contrats frontend TS-RS générés depuis les DTO Rust.
|
||||
|
||||
Le statut global est donc `FAIL`. Le fix doit être corrigé sans absorber encore la réconciliation Rust générale ni la future matérialisation d'un skeleton Tauri complet.
|
||||
|
||||
## Baseline et version
|
||||
|
||||
La tranche part du commit opérateur de `0.0.5-alpha.6` :
|
||||
|
||||
```text
|
||||
0f6a2e2 0.0.5-alpha.6
|
||||
```
|
||||
|
||||
Le push vers `origin/master` a réussi avant l'application de `alpha.6.fix.1`.
|
||||
|
||||
La version contrôlée après application du delta est :
|
||||
|
||||
```text
|
||||
0.0.5-alpha.6.fix.1
|
||||
```
|
||||
|
||||
`history/0.0.5/alpha.6.md` est présent avec statut `FAIL`; `deltas/0.0.5/alpha.6.fix.1.md` est présent et `history/0.0.5/alpha.6.fix.1.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`, à `09:16:02`–`10:08:50`.
|
||||
|
||||
Les contrôles de présence, statut et révision ont réussi. La suite Python globale a exécuté `37` tests, tous réussis :
|
||||
|
||||
```text
|
||||
Ran 37 tests in 0.504s
|
||||
|
||||
OK
|
||||
```
|
||||
|
||||
Les audits documentaires affichent :
|
||||
|
||||
```text
|
||||
Markdown header audit: clean (148 file(s))
|
||||
Markdown table audit: clean (7 table(s), 148 file(s))
|
||||
Markdown link audit: clean (148 local link(s), 148 file(s))
|
||||
```
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
|
||||
|
||||
Le scope Git observé est exactement :
|
||||
|
||||
```text
|
||||
M VERSION
|
||||
A deltas/0.0.5/alpha.6.fix.1.md
|
||||
M docs/architecture/003-RULE_PROFILE_MODEL.md
|
||||
M docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
|
||||
M docs/rules/700-FRAMEWORKS.md
|
||||
M docs/rules/710-TAURI.md
|
||||
M docs/studies/001-KSP_GAMES_RECONCILIATION.md
|
||||
```
|
||||
|
||||
## Échec du contrôle ciblé
|
||||
|
||||
Le heredoc contient notamment une chaîne Python simple avec le texte `l'extérieur`. L'apostrophe ferme prématurément la chaîne et produit :
|
||||
|
||||
```text
|
||||
SyntaxError: unterminated string literal (detected at line 10)
|
||||
```
|
||||
|
||||
Le message de succès attendu du contrôle ciblé n'a donc pas été produit. Une gate obligatoire du fix reste en échec.
|
||||
|
||||
## Clarification issue de la revue KSP/Games
|
||||
|
||||
La relecture des règles et layouts réels confirme :
|
||||
|
||||
- les `6` applications Desk KSP et les `2` applications Tauri Games possèdent toutes directement à la racine de leur crate `Cargo.toml`, `build.rs`, `package.json`, `tsconfig.json` et `tauri.conf.json`, ainsi que `src/` et `frontend/`; aucune n'utilise `src-tauri/` ;
|
||||
- KSP formalise `lib.rs` comme façade, `main.rs` comme launcher mince et `tauri.rs` comme owner des wrappers `#[tauri::command]`; Games reprend la même séparation `lib.rs`/`tauri.rs` ;
|
||||
- KSP impose pour ses apps Desk les bindings TS-RS générés depuis les DTO Rust comme source de vérité frontend ; Games n'a pas encore ce contrat, ce qui en fait un candidat fort pour la convention stricte des projets contrôlés plutôt qu'un invariant universel de Tauri ;
|
||||
- Games formalise explicitement que WASM reste une crate distincte de la crate Tauri ;
|
||||
- les règles de noms de crates et la discipline Rust stricte sont plus larges que Tauri et doivent être traitées dans les tranches Rust suivantes.
|
||||
|
||||
## Résultat
|
||||
|
||||
`0.0.5-alpha.6.fix.1` est enregistré `FAIL`.
|
||||
|
||||
## Transition
|
||||
|
||||
Appliquer le présent history puis committer/pousser `0.0.5-alpha.6.fix.1`.
|
||||
|
||||
La correction suivante est :
|
||||
|
||||
```text
|
||||
0.0.5-alpha.6.fix.2
|
||||
```
|
||||
|
||||
Elle doit rendre la gate ciblée robuste et compléter le profil Tauri avec les conventions fortement éprouvées qui appartiennent réellement à ce scope, tout en replanifiant séparément les conventions Rust/nomenclature et les audits de style restants.
|
||||
Reference in New Issue
Block a user