0.0.5-alpha.6.fix.1

This commit is contained in:
2026-09-25 10:19:35 +02:00
parent 0f6a2e21eb
commit 33bf835b7f
8 changed files with 389 additions and 29 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/700-FRAMEWORKS.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Règles de profils framework
@@ -26,7 +26,7 @@ Un profil framework MUST NOT recopier les règles d'un langage, d'une plateforme
## Composition
Un framework s'ajoute aux profils réellement applicables au projet.
Un framework s'ajoute aux profils réellement applicables au projet. Il n'annule pas silencieusement les conventions des owners qu'il compose.
Par exemple :
@@ -45,8 +45,28 @@ GENERAL
+ Tauri
```
Lorsque PGR gouverne la baseline du projet, les règles des profils hérités restent applicables dans leur scope complet tant qu'un override plus spécifique n'est pas documenté. Un framework ne constitue pas à lui seul une justification pour affaiblir une convention de langage, de plateforme ou de sécurité.
Un projet existant ou imposé de l'extérieur MAY conserver des contraintes différentes. Ces écarts appartiennent alors au niveau project-specific ou à une exception explicite et bornée ; ils ne doivent pas être remontés comme nouvelle règle générale du framework.
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.
## Profil framework et convention d'instanciation
Le profil framework décrit ce qui reste vrai pour toute adoption conforme du framework. Une skeleton specification ou une baseline locale MAY choisir en plus un layout, un bundler, un langage frontend, un package manager ou des bibliothèques préférées pour les projets que l'organisation contrôle.
Ces valeurs d'instanciation ne deviennent pas des invariants du framework :
```text
profil framework
→ responsabilités et contraintes propres au framework
skeleton / projet local
→ choix réutilisables de structure et de stack
```
Cette séparation permet d'appliquer PGR à un projet imposé sans lui forcer le skeleton préféré des nouveaux projets.
## 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.