pgr/docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md

Skeleton — Project governance foundation

Objectif

Cette specification décrit une fondation composable pour un projet qui choisit d'adopter la gouvernance PGR sans sélectionner encore de langage, plateforme, framework ou architecture applicative.

Elle permet d'établir une baseline locale cohérente : identité de version, point d'entrée normatif, documentation réellement utile, workflow de changement effectivement retenu et validation initiale proportionnée.

Le contrat commun des skeletons appartient à ../rules/220-SKELETONS.md. La présente specification sélectionne et adapte les owners généraux utiles ; elle n'en devient pas propriétaire.

Applicabilité

Appliquer cette fondation lorsqu'un dépôt ou release unit veut utiliser PGR comme source de gouvernance locale et qu'aucune specialization technologique n'est nécessaire pour définir cette base commune.

Elle MAY servir de fondation à un skeleton spécialisé, qui ajoute ensuite uniquement les profils, templates, décisions et validations propres à son scope.

Ne pas l'appliquer comme cérémonie à un dépôt qui ne souhaite pas adopter le lifecycle ou les règles PGR. Elle ne transforme pas PGR en dépendance du projet destinataire.

Owners sélectionnés

La fondation s'appuie sur les responsabilités PGR suivantes :

docs/rules/200-GOVERNANCE.md
    versioning, phases et discipline de changement

docs/rules/210-WORKFLOW.md
    plans, deltas, histories, commits de tranche et artefacts à la demande

docs/rules/300-DOCUMENTATION.md
    rôles documentaires, taxonomie, révisions et snapshots

docs/rules/400-VALIDATION.md
    preuves proportionnées, statuts de gate et autorité opérateur

docs/rules/220-SKELETONS.md gouverne l'instanciation elle-même. Il n'est pas automatiquement une règle à recopier dans le projet destinataire si ce projet ne maintient pas sa propre collection de skeletons.

Aucun profil 500+ ou 600+ n'est sélectionné par cette fondation. Un skeleton spécialisé les ajoute seulement lorsqu'ils sont réellement applicables.

Décisions destinataire avant matérialisation

Avant de considérer la fondation comme instanciée, résoudre explicitement les décisions suivantes :

1. identifier le release unit gouverné et sa version SemVer courante ;
2. décider si le projet utilise le fichier racine VERSION comme repère canonique simple ;
3. identifier les règles PGR réellement reprises et les adaptations locales nécessaires ;
4. déterminer quels documents vivants ont une responsabilité réelle dès la baseline ;
5. déterminer quels artefacts du workflow PGR sont effectivement utilisés et à partir de quel état gouverné ;
6. sélectionner les validations disponibles qui prouvent réellement cette baseline ;
7. consigner toute exception ou divergence intentionnelle dans le propriétaire local approprié.

Une décision non résolue MUST rester visible comme décision à prendre. Elle ne doit pas être remplacée par une valeur arbitraire provenant de PGR ou d'un autre projet.

Baseline locale à matérialiser

Point d'entrée normatif

Le projet destinataire MUST disposer d'un point d'entrée normatif local clairement identifiable. Lorsqu'il adopte la convention PGR, ce point d'entrée est RULES.md.

Ce document doit au minimum :

• déclarer le scope qu'il gouverne ;
• identifier les owners généraux ou spécialisés réellement applicables ;
• expliquer la priorité ou la spécialisation locale lorsqu'une adaptation existe ;
• renvoyer vers les documents détaillés au lieu de recopier leur contenu sans nécessité.

Le projet doit rester autonome : ses règles nécessaires vivent dans son dépôt ou dans un mécanisme de dépendance documentaire explicitement choisi par lui. Une URL vers PGR ne remplace pas à elle seule une baseline locale exploitable.

Version

Le release unit MUST posséder une version SemVer courante explicite conformément au contrat local retenu.

Si le fichier racine VERSION est choisi, l'instanciation doit le créer ou l'adapter selon ../rules/200-GOVERNANCE.md. Si l'écosystème possède un autre owner canonique, la relation avec VERSION doit être décidée explicitement plutôt que dupliquée par défaut.

La valeur de version initiale appartient au projet destinataire. Cette specification ne fournit pas de numéro universel.

Documentation minimale

README.md SHOULD fournir l'onboarding et les points d'entrée de premier niveau du projet.

Créer docs/000-README.md uniquement si une documentation structurée sous docs/ existe réellement. Créer ensuite uniquement les collections possédant un premier contenu utile. Une collection vide ou un document placeholder n'est pas requis par cette fondation.

Selon la réalité du projet :

• ROADMAP.md est utile lorsqu'une trajectoire macro doit être rendue explicite ;
• CHANGELOG.md est utile lorsque des changements de release doivent être communiqués aux utilisateurs ou intégrateurs ;
• docs/objectives/ est utile lorsqu'une mission durable, des contraintes ou non-objectifs méritent un owner distinct ;
• docs/architecture/ est utile lorsqu'un état architectural ou un profil local doit être possédé durablement ;
• docs/validation/ est utile lorsqu'une matrice ou un contrat de preuve mérite un document séparé.

Pour un projet où plusieurs fichiers ou familles durables ont des responsabilités ou règles de modification difficiles à déduire, la fondation MAY aussi instancier un registre local selon ../templates/004-FILE_FAMILY_CONTRACTS.md. Ce registre reste facultatif : un projet simple ou déjà explicite n'a rien à matérialiser.

Ne pas créer ces fichiers uniquement pour reproduire l'arborescence du dépôt PGR.

Workflow retenu

Si le projet adopte le workflow de tranches PGR, il doit préserver la séquence définie par ../rules/210-WORKFLOW.md : intention prospective dans le delta, gate réelle, preuve rétrospective dans le history, puis commit de tranche avant application du delta suivant.

Les répertoires deltas/, history/, prompts/, handoffs/ et manifests/ sont créés à la demande lorsqu'un artefact réel les justifie. Ils ne constituent pas un layout obligatoire à précréer.

Un projet qui n'adopte qu'une partie du workflow PGR doit l'indiquer dans ses règles locales et ne pas présenter les artefacts omis comme s'ils étaient encore obligatoires.

Validation initiale

La validation de la fondation doit prouver seulement les propriétés réellement matérialisées. Elle SHOULD combiner selon le scope :

CHECK  version courante conforme au mécanisme choisi
CHECK  git diff --check ou équivalent du VCS retenu
AUDIT  chemins et rôles documentaires réellement créés
AUDIT  liens locaux principaux si la navigation Markdown a été modifiée
AUDIT  owners sélectionnés et exceptions locales explicites
REVIEW absence de collections, profils ou placeholders non justifiés

Si le projet possède déjà des audits fiables pour ses headers, liens, structure ou règles, ils MAY être ajoutés. Cette fondation n'impose pas de copier les scripts du dépôt PGR sans décision explicite de réutilisation.

La prévalidation qui accompagne une instanciation ou un delta ne remplace pas la gate opérateur autoritaire du projet destinataire.

Ordre de composition

Cette fondation SHOULD être appliquée avant une specialization qui la déclare comme base.

Une specialization technologique peut ensuite :

• sélectionner ses familles et profils applicables ;
• copier ou adapter les templates techniques correspondants ;
• ajouter ses décisions spécifiques ;
• étendre la validation initiale avec la toolchain réellement concernée.

Elle MUST NOT redéfinir les responsabilités générales déjà possédées par la fondation sauf specialization ou override explicitement justifié.

Overrides et exceptions

Un projet MAY adapter la structure documentaire, le mécanisme de version, le VCS, le workflow ou une convention PGR lorsqu'une contrainte réelle le justifie et que l'owner local reste clair.

Une exception doit identifier son scope et sa raison. Elle ne devient pas une règle générale PGR et ne doit pas être masquée par la simple copie d'un fichier provenant de PGR.

Hors scope

Cette fondation ne définit pas :

• l'architecture applicative ou les crates/modules/packages du produit ;
• un langage, une plateforme, un framework ou une toolchain ;
• des noms de package, versions de dépendances ou chemins de build ;
• des templates techniques génériques inexistants ;
• un CI/CD universel ;
• une politique de branching universelle ;
• une obligation de recopier la structure complète du dépôt PGR ;
• la migration rétroactive des anciennes releases ou anciens commits du projet destinataire.

Les spécialisations futures doivent rester indépendantes et composables au-dessus de cette fondation.