106 lines
4.7 KiB
Markdown
106 lines
4.7 KiB
Markdown
<!-- 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).
|