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
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.