0.0.5-alpha.6.fix.2
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/001-KSP_GAMES_RECONCILIATION.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# Étude de réconciliation PGR / KSP / sasedev-games
|
||||
|
||||
@@ -167,6 +167,22 @@ La règle de validation commune reste confirmée : lorsqu'une propriété dépen
|
||||
|
||||
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.
|
||||
|
||||
#### Seconde passe de réconciliation des conventions Tauri/Rust
|
||||
|
||||
La clarification opérateur de `alpha.6.fix.1` déclenche une seconde lecture des règles versionnées plutôt qu'une simple extrapolation depuis les fichiers de configuration. Cette passe confirme plusieurs niveaux de preuve.
|
||||
|
||||
**Commun aux `8` hosts Tauri observés** : les `6` Desk KSP et les `2` hosts Games placent directement à la racine de leur crate `Cargo.toml`, `build.rs`, `package.json`, `tsconfig.json` et `tauri.conf.json`; tous possèdent `src/lib.rs`, `src/main.rs`, `src/tauri.rs` et `frontend/`; aucun ne possède `src-tauri/`. Cette convergence justifie une forte recommandation PGR pour les nouveaux projets contrôlés sans imposer une migration mécanique aux projets externes.
|
||||
|
||||
**Commun et déjà normatif dans les corpus** : KSP `KSP-APP-010..013` et Games `GAME-PLATFORM-010` convergent vers une bibliothèque applicative avec façade `lib.rs`, un launcher `main.rs` mince et un `tauri.rs` qui assemble Tauri et expose les wrappers de commandes. Games `GAME-PLATFORM-009` confirme aussi que l'adaptation WASM réutilisable reste distincte de la crate Tauri.
|
||||
|
||||
**KSP plus strict mais réutilisable** : `KSP-APP-023` place les sources Web sous `frontend/`, TypeScript sous `frontend/ts/`, Sass sous `frontend/sass/` et les bindings TS-RS sous `frontend/ts/bindings/`, les DTO Rust restant la source de vérité. La baseline KSP `0.3.16` contient `41` fichiers Rust applicatifs utilisant TS-RS dans les apps Desk. Games n'a pas encore ce contrat TS-RS : PGR le classe donc comme convention stricte des projets contrôlés, pas comme invariant universel de Tauri.
|
||||
|
||||
**Fortement recommandé mais pas universel** : le préfixe KSP `tw_`, le splashscreen commun, les paires de ports fixes, le plugin tracing précis et les détails de shell sont locaux. En revanche, un module cohérent par fenêtre/responsabilité, des helpers communs séparés et l'ajout explicite/revu des plugins sont des patterns réutilisables.
|
||||
|
||||
**Rust au-delà de Tauri** : `RULES_RUST.md` KSP contient un profil beaucoup plus complet que Games : `use` non-traits interdits, chemins externes explicites les plus courts, réexports `self::`, alias interdits, blocs de visibilité/ordre, contrôle de flux explicite et façade stricte. Games confirme le noyau façade/chemins/erreurs mais pas toutes les contraintes de style. Ces écarts doivent être traités en tranches Rust dédiées, avec KSP comme référence stricte et Games comme pression pour classifier correctement `MUST`/`SHOULD`/override.
|
||||
|
||||
**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.
|
||||
|
||||
### Web / Vite / WASM
|
||||
|
||||
Les corpus et la clarification opérateur permettent désormais de séparer trois choses :
|
||||
@@ -189,7 +205,7 @@ Les responsabilités suivantes sont utiles dans leurs projets mais ne fournissen
|
||||
|
||||
- firewall de dépendances, protocoles Solana, transports, Store, workers/jobs, tracing targets et materialization de KSP ;
|
||||
- générations de moteur, assets de jeux, Uroburas, serveurs temps réel, distribution Android/Web et politiques de hosting de Games ;
|
||||
- choix de noms de crates, répertoires de config, schémas, routes, plugins et ressources propres à chaque application ;
|
||||
- noms métier exacts des crates, répertoires de config, schémas, routes, plugins et ressources propres à chaque application ; la convention générique de noms exprimant préfixe projet, responsabilité et rôle reste à réconcilier en `alpha.7` ;
|
||||
- seuils Clippy, identifiants courts autorisés, ports de développement et paramètres de fenêtres lorsqu'ils n'expriment aucun invariant réutilisable.
|
||||
|
||||
Ces éléments servent à tester que PGR permet des règles locales spécifiques ; ils ne doivent pas être aspirés dans le référentiel central.
|
||||
|
||||
Reference in New Issue
Block a user