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

0.0.5-alpha.6.fix.3

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-25 10:47:38 +02:00
parent b7e65d9100
commit 4e1c1cd6f0
7 changed files with 294 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1,5 +1,5 @@
<!-- file: docs/studies/001-KSP_GAMES_RECONCILIATION.md -->
<!-- version: 6 -->
<!-- version: 7 -->
# Étude de réconciliation PGR / KSP / sasedev-games
@@ -153,7 +153,7 @@ Tauri est réellement présent dans les deux corpus et n'est plus un exemple iso
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.
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.
Toutes les configurations observées omettent une version Tauri explicite tandis que leur package Cargo hérite de la version workspace. La relecture des règles montre que ce n'est pas un simple accident : KSP `VER-ID-015/016` et Games `VER-TAURI-001..004` ont tous deux utilisé l'omission de `tauri.conf.json > version` et la non-synchronisation systématique de `package.json` pour réduire le churn. La clarification opérateur de `alpha.6.fix.2` rejette toutefois la généralisation de cette solution : l'objectif durable est de **classifier la fréquence de synchronisation**, pas de supprimer les champs. PGR conserve donc la possibilité d'une version Tauri/frontend explicite et privilégie `MIRROR-STABLE` lorsque ces valeurs doivent seulement porter le jalon `X.Y.Z` cible.
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.
@@ -183,6 +183,21 @@ La clarification opérateur de `alpha.6.fix.1` déclenche une seconde lecture de
**Nomenclature des crates** : KSP encode explicitement le rôle (`ksp-<role>-lib`, `ksp-<domain>-api`, `ksp-app-<role>-<interface>`, workers/jobs), tandis que Games conserve lui aussi des noms révélant rôle et cible (`game-logging-lib`, `*-desktop`, `*-tauri`, `*-wasm`, `engine-v1-*`). PGR doit donc étudier une convention générale « préfixe projet + responsabilité + suffixe de rôle/cible » sans figer les vocabulaires propres à KSP ou Games.
#### Politique de version Tauri/frontend réconciliée
La baseline KSP `0.3.16` illustre le défaut de l'ancienne convention : les six `tauri.conf.json` n'ont pas de champ `version`, tandis que leurs `package.json` portent des versions historiques différentes (`0.2.6`, `0.2.12-pre.9`, `0.3.7`, `0.3.8` ou `0.3.15`) sans représenter uniformément la release courante. Games `0.3.5` suit la même famille de règles. Cette situation réduit les modifications mécaniques mais affaiblit la lisibilité des manifests.
La décision PGR est donc :
- `VERSION` = `CANONICAL` exact de la tranche ;
- version Cargo = `MIRROR-EXACT` lorsque le profil Rust du projet la synchronise ;
- `tauri.conf.json > version` et `package.json > version`, lorsqu'ils sont conservés pour le même produit, SHOULD normalement être `MIRROR-STABLE` et porter la cible `X.Y.Z` pendant tout le développement ;
- une distribution réelle de prereleases peut sélectionner une politique plus fine (`MIRROR-EXACT` ou jalons de packaging) ;
- l'absence du champ reste autorisée lorsque le projet n'en tire aucune valeur, mais n'est plus la recommandation PGR destinée à éviter le churn.
Cette décision est cohérente avec le principe PGR historique qui distingue déjà version canonique, miroirs techniques, compteurs et versions de schéma au lieu d'exiger `tous les champs == VERSION`.
### Web / Vite / WASM
Les corpus et la clarification opérateur permettent désormais de séparer trois choses :