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

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