0.0.5-alpha.6

docs/rules/700-FRAMEWORKS.md

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