2.6 KiB
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— versioning, lifecycle des releases, fixes, cadrage, replan et abandon/supersession.210-WORKFLOW.md— contrats des artefacts workflow, ordre delta/history/commit, reprise et baselines de release.300-DOCUMENTATION.md— rôles des documents, taxonomie, révisions internes, documents vivants et snapshots historiques.400-VALIDATION.md— matrice de validation, preuves proportionnelles, tests/audits/diagnostics, doubles de test et autorité du gate opérateur.500-LANGUAGES.md— contrat commun des profils langage/écosystème et de leurs spécialisations de build.600-PLATFORMS.md— contrat commun des profils plateforme.
Le modèle transversal d'ownership, d'applicabilité et de composition est décrit dans ../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 :
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 :
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.