# Index des règles PGR Les règles détaillées de Project Governance Rules sont organisées ici progressivement par scope. `RULES.md` reste le point d'entrée normatif du dépôt et définit les principes fondamentaux, la force normative et la hiérarchie générale. Les règles générales actuellement nécessaires restent dans `RULES.md`. La famille `100 — general` demeure réservée et n'est pas matérialisée tant qu'un document dédié n'apporte pas une meilleure séparation de responsabilités. ## Familles actives - [`200-GOVERNANCE.md`](200-GOVERNANCE.md) — versioning, lifecycle des releases, fixes, cadrage, replan et abandon/supersession. - [`210-WORKFLOW.md`](210-WORKFLOW.md) — contrats des artefacts workflow, ordre delta/history/commit, prompts versionnés, reprise et baselines de release. - [`220-SKELETONS.md`](220-SKELETONS.md) — contrat commun des skeleton specifications, sélection des profils/templates, décisions, overrides et validation. - [`230-ADOPTION.md`](230-ADOPTION.md) — contrat d’adoption PGR pour un dépôt existant, classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` et migration incrémentale. - [`300-DOCUMENTATION.md`](300-DOCUMENTATION.md) — rôles des documents, taxonomie, révisions internes, documents vivants et snapshots historiques. - [`400-VALIDATION.md`](400-VALIDATION.md) — matrice de validation, preuves proportionnelles, tests/audits/diagnostics, doubles de test et autorité du gate opérateur. - [`500-LANGUAGES.md`](500-LANGUAGES.md) — contrat commun des profils langage/écosystème et de leurs spécialisations de build. - [`510-RUST_CARGO.md`](510-RUST_CARGO.md) — profil Rust/Cargo et règles réutilisables propres à cet écosystème. - [`520-JAVA.md`](520-JAVA.md) — profil Java et règles réutilisables propres au langage. - [`521-MAVEN.md`](521-MAVEN.md) — spécialisation Maven, applicable uniquement aux projets qui utilisent Maven. - [`522-GRADLE.md`](522-GRADLE.md) — spécialisation Gradle, applicable uniquement aux projets qui utilisent Gradle. - [`530-TYPESCRIPT.md`](530-TYPESCRIPT.md) — profil TypeScript, recommandation pour les frontends contrôlés, type-check et frontières typées. - [`540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md`](540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md) — package manager, `package.json`, dépendances, scripts et responsabilité du lockfile. - [`550-VITE.md`](550-VITE.md) — profil Vite, build tool/dev server recommandé et ownership de son cache et de ses outputs. - [`560-CSS_SASS.md`](560-CSS_SASS.md) — profil CSS/Sass, styles sources, prétraitement conditionnel et intégration de dépendances de styles. - [`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). ## Organisation prévue Les autres familles seront créées uniquement lorsqu'elles disposent d'un contenu réel. La trajectoire actuelle prévoit conceptuellement : ```text 100 — general 200 — governance 300 — documentation 400 — validation 500 — languages / ecosystems 600 — platforms 700 — frameworks 800 — architecture 900 — project-specific ``` Les numéros réservent des familles de navigation ; ils ne constituent pas des identifiants de règles individuelles. Les règles issues d'un langage, framework ou projet particulier ne doivent pas être élevées au niveau général sans justification réellement transversale. ## Enforcement Une règle doit s'appuyer d'abord sur le mécanisme officiel le plus fiable disponible : ```text compiler / language ↓ official linter or tool ↓ manifest / build system ↓ read-only structural audit ↓ test, uniquement pour une propriété comportementale ``` Les décisions architecturales qui ne peuvent pas être automatisées de manière fiable restent des points de revue.