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