0.0.5-alpha.3

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 10 -->
+<!-- version: 11 -->
 
 # Documentation PGR
 
@@ -24,6 +24,7 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
 
 - [`plans/005-V0_0_5_RECONCILIATION_PLAN.md`](plans/005-V0_0_5_RECONCILIATION_PLAN.md) — cadrage, classification et trajectoire active de la réconciliation `0.0.5` ;
 - [`studies/001-KSP_GAMES_RECONCILIATION.md`](studies/001-KSP_GAMES_RECONCILIATION.md) — inventaire comparatif des baselines KSP/Games et décisions de généralisation, maintien local ou différé.
+- [`templates/004-FILE_FAMILY_CONTRACTS.md`](templates/004-FILE_FAMILY_CONTRACTS.md) — pattern facultatif pour expliciter les responsabilités et règles de modification de familles de fichiers locales lorsque la complexité le justifie.
 
 ## Points d'entrée de 0.0.4
 

docs/rules/300-DOCUMENTATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/300-DOCUMENTATION.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Documentation rules
 
@@ -76,6 +76,26 @@ Un document sous `docs/objectives/` décrit la mission durable, les objectifs, c
 
 Il MUST NOT être remplacé par `ROADMAP.md` : les objectifs expliquent pourquoi le projet existe et ce qu'il cherche à garantir ; la roadmap décrit comment sa trajectoire est découpée.
 
+## Registre local de contrats de fichiers ou familles
+
+Un projet MAY maintenir un registre local lorsque plusieurs fichiers ou familles durables ont des responsabilités, sources de vérité ou règles de modification qui ne sont pas suffisamment évidentes depuis leur nom, leur écosystème ou leurs owners existants.
+
+Ce registre est un outil de désambiguïsation, pas un inventaire exhaustif de l'arborescence. Il MUST NOT être créé uniquement pour recopier les rôles déjà définis par PGR, un manifeste, une toolchain ou une documentation locale plus appropriée. Un petit projet dont les responsabilités sont déjà claires SHOULD ne pas créer ce document.
+
+Chaque entrée utile SHOULD identifier au minimum :
+
+- le fichier, motif de chemin ou famille concernée ;
+- sa responsabilité durable ;
+- la règle ou le déclencheur pertinent de modification.
+
+Selon le besoin, une entrée MAY aussi préciser une source de vérité, le caractère généré/versionné, un owner local ou une validation associée. Ces champs supplémentaires ne doivent être ajoutés que s'ils réduisent réellement une ambiguïté.
+
+Le nom, l'emplacement et la forme du registre appartiennent au projet destinataire. PGR n'impose ni `FILE_CONTRACTS.md`, ni une table Markdown, ni un catalogue de chaque fichier. Une liste courte, une table ou une autre forme lisible sont équivalentes si le contrat reste explicite.
+
+Lorsqu'un owner existant possède déjà la règle détaillée, le registre SHOULD le référencer plutôt que dupliquer son contenu. Il est mis à jour lorsque le contrat d'une famille change réellement ; l'ajout d'un fichier conforme à une famille déjà décrite ne force pas une nouvelle entrée.
+
+[`../templates/004-FILE_FAMILY_CONTRACTS.md`](../templates/004-FILE_FAMILY_CONTRACTS.md) fournit un pattern documentaire court pour les projets qui choisissent d'adopter ce registre.
+
 ## Taxonomie documentaire
 
 La taxonomie doit rester sémantique et proportionnée. Les familles communes comprennent notamment :

docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Skeleton — Project governance foundation
 
@@ -92,6 +92,8 @@ Selon la réalité du projet :
 - `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`](../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

docs/templates/004-FILE_FAMILY_CONTRACTS.md

@@ -0,0 +1,80 @@
+<!-- file: docs/templates/004-FILE_FAMILY_CONTRACTS.md -->
+<!-- version: 1 -->
+
+# Pattern — contrats locaux de fichiers ou familles
+
+## Objectif
+
+Ce pattern aide un projet à expliciter quelques responsabilités de fichiers ou familles durables lorsqu'elles deviennent difficiles à déduire de l'arborescence, de la toolchain ou des règles déjà existantes.
+
+Il complète le contrat documentaire de [`../rules/300-DOCUMENTATION.md`](../rules/300-DOCUMENTATION.md). Il n'impose aucun fichier particulier au projet destinataire.
+
+## Quand l'utiliser
+
+Créer un registre local seulement lorsqu'il réduit une ambiguïté réelle, par exemple lorsque :
+
+- plusieurs familles voisines ont des rôles différents qui provoquent régulièrement des erreurs de placement ;
+- un fichier est une source de vérité tandis qu'un autre est généré ou dérivé ;
+- une famille possède une règle de modification ou de synchronisation non évidente ;
+- des contributeurs doivent savoir quel owner modifier sans relire plusieurs documents spécialisés.
+
+Ne pas l'utiliser pour inventorier chaque fichier d'un petit dépôt, recopier les rôles standards déjà décrits par PGR ou dupliquer un manifeste/build system qui possède déjà l'information.
+
+## Forme minimale
+
+Le nom et l'emplacement appartiennent au projet destinataire. `docs/rules/FILE_CONTRACTS.md` est un nom possible, pas une convention PGR obligatoire.
+
+Une entrée utile contient au minimum :
+
+```text
+file or family
+responsibility
+modification rule
+```
+
+Lorsque ces informations sont utiles, le projet MAY ajouter :
+
+```text
+source of truth / generated status
+local owner or reference
+validation or synchronization requirement
+```
+
+Une table Markdown convient aux registres structurés :
+
+```markdown
+| Fichier ou famille | Responsabilité | Règle de modification |
+|--------------------|----------------|------------------------|
+| `<path-or-pattern>` | `<rôle durable>` | `<quand/comment modifier>` |
+```
+
+Une liste courte est préférable lorsqu'elle reste plus lisible. La forme n'est pas normative ; la clarté de la responsabilité l'est pour le projet qui choisit d'adopter ce contrat.
+
+## Règles d'adaptation
+
+Lors de l'instanciation :
+
+1. sélectionner uniquement les fichiers ou familles dont le contrat local apporte une information non évidente ;
+2. référencer l'owner détaillé existant au lieu de recopier ses règles ;
+3. regrouper les chemins qui partagent réellement le même contrat plutôt que créer une entrée par fichier ;
+4. distinguer explicitement source de vérité et artefact généré lorsque cette distinction existe ;
+5. supprimer ou fusionner une entrée devenue redondante lorsque son rôle est désormais évident ailleurs.
+
+Le registre SHOULD évoluer lorsqu'une responsabilité ou règle de modification change réellement. Il SHOULD NOT être modifié uniquement parce qu'un nouveau fichier respecte déjà une famille décrite.
+
+## Exemple abstrait
+
+```markdown
+| Fichier ou famille | Responsabilité | Règle de modification |
+|--------------------|----------------|------------------------|
+| `config/*.example` | Décrire les exemples versionnés de configuration locale. | Mettre à jour lorsqu'une option utilisateur versionnée est ajoutée ou retirée ; ne jamais y placer de secret réel. |
+| `generated/**` | Contenir les sorties reconstruisibles produites par la toolchain choisie. | Ne pas modifier manuellement ; régénérer depuis la source de vérité documentée. |
+```
+
+Cet exemple illustre la forme uniquement. Il ne crée aucune règle universelle sur les chemins `config/` ou `generated/`.
+
+## Critère de sortie
+
+Le pattern est utile si un nouveau contributeur peut déterminer plus vite où une responsabilité vit et quand modifier une famille sans devoir maintenir un catalogue parallèle du dépôt.
+
+S'il ajoute davantage de cérémonie que d'information, ne pas l'instancier ou le retirer.