0.1.5-alpha.4

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 49 -->
+<!-- version: 50 -->
 
 # Documentation PGR
 
@@ -22,11 +22,11 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
 
 ## Points d'entrée de 0.1.5
 
-- [`plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan actif de `0.1.5` : inventaire `alpha.1`, récupération de preuve `alpha.1.fix.1`, sémantique normative `alpha.2`, autonomie locale `alpha.3`, frontière PGR / Knowledge, réconciliation puis freeze.
+- [`plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan actif de `0.1.5` : inventaire `alpha.1`, récupération de preuve `alpha.1.fix.1`, sémantique normative `alpha.2`, autonomie locale `alpha.3`, frontière PGR / Knowledge `alpha.4`, réconciliation puis freeze.
 - [`studies/004-V0_1_4_HORIZON_REVIEW.md`](studies/004-V0_1_4_HORIZON_REVIEW.md) — décision autoritaire de fermeture `0.1.4` qui place la release de gouvernance/autonomie avant les adoptions Games/KSP.
 - [`../RULES.md`](../RULES.md), [`rules/230-ADOPTION.md`](rules/230-ADOPTION.md) et [`rules/400-VALIDATION.md`](rules/400-VALIDATION.md) — owners primaires réconciliés en `alpha.2` : `SHOULD / SHOULD NOT` est une forte recommandation non obligatoire, sans `FAIL` de gate ni `OVERRIDE` automatique pour un simple écart.
 - [`rules/220-SKELETONS.md`](rules/220-SKELETONS.md), [`rules/230-ADOPTION.md`](rules/230-ADOPTION.md), [`skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) et [`templates/007-EXISTING_PROJECT_ADOPTION.md`](templates/007-EXISTING_PROJECT_ADOPTION.md) — owners réconciliés en `alpha.3` : baseline locale autoritaire, absence d'upstream PGR implicite et réalignement volontaire fondé sur un snapshot choisi.
-- [`objectives/001-PROJECT_OBJECTIVES.md`](objectives/001-PROJECT_OBJECTIVES.md), [`architecture/002-GOVERNANCE_ARCHITECTURE.md`](architecture/002-GOVERNANCE_ARCHITECTURE.md) et [`rules/300-DOCUMENTATION.md`](rules/300-DOCUMENTATION.md) — owners proposés pour formaliser la frontière PGR / SaseDev Knowledge sans dépendance externe.
+- [`objectives/001-PROJECT_OBJECTIVES.md`](objectives/001-PROJECT_OBJECTIVES.md), [`architecture/002-GOVERNANCE_ARCHITECTURE.md`](architecture/002-GOVERNANCE_ARCHITECTURE.md) et [`rules/300-DOCUMENTATION.md`](rules/300-DOCUMENTATION.md) — owners réconciliés en `alpha.4` : PGR reste auto-suffisant pour ses contrats normatifs ; les contenus pratiques externes restent complémentaires, sans dépendance PGR vers Knowledge ni déplacement automatique.
 - [`../prompts/011-V0_1_5_START_PROMPT.md`](../prompts/011-V0_1_5_START_PROMPT.md) — contrat de reprise exécuté pour ouvrir `0.1.5-alpha.1` à partir de la stable `v0.1.4` vérifiée.
 
 ## Points d'entrée de 0.1.4

docs/architecture/002-GOVERNANCE_ARCHITECTURE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/architecture/002-GOVERNANCE_ARCHITECTURE.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Architecture de gouvernance PGR
 
@@ -23,7 +23,7 @@ Après instanciation, le projet possède sa copie et ne dépend plus de PGR.
 
 ### Skeleton specification
 
-Un skeleton est une recette Markdown décrivant comment initialiser un type de projet ou composer plusieurs profils.
+Un skeleton est une spécification Markdown composable décrivant comment initialiser un type de projet ou composer plusieurs profils.
 
 Il décrit notamment les profils applicables, la structure requise ou optionnelle, les templates à utiliser, les points de décision, la politique de version et la validation de base. Le contrat transversal de sélection et de composition appartient à [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md) ; les spécifications concrètes sont indexées sous [`../skeletons/`](../skeletons/000-README.md).
 
@@ -37,6 +37,16 @@ Les scripts `audit_*.py` sont read-only : ils ne modifient, ne formatent, ne gé
 
 Les audits PGR sont ajoutés progressivement à partir de besoins réels et de contrôles éprouvés. PGR ne cherche pas à anticiper un catalogue exhaustif d'audits.
 
+## Frontière avec les contenus pratiques externes
+
+PGR doit rester auto-suffisant pour comprendre et appliquer ses contrats normatifs. Les règles, owners, objectifs, décisions architecturales, skeleton specifications, templates nécessaires à un contrat réutilisable et validations directement liées aux règles restent possédés par PGR lorsqu'ils sont nécessaires à cette compréhension.
+
+Les howtos détaillés, recettes pratiques, snippets, exemples d'intégration, dépannage, comparatifs et variantes d'implémentation MAY vivre dans une base de connaissances séparée. SaseDev Knowledge est une destination possible pour cette famille de contenus, mais sa disponibilité n'est pas une précondition d'utilisation de PGR.
+
+Un contenu pratique externe MAY compléter PGR, mais MUST NOT devenir la source nécessaire pour déterminer ce qu'une règle PGR exige. PGR MUST NOT dépendre d'un dépôt Knowledge pour être interprétable ou applicable.
+
+Cette frontière est sémantique avant d'être physique : classifier un contenu comme pratique ne déclenche pas automatiquement son déplacement. Une extraction future exige une destination autoritaire explicitement fournie et doit préserver dans PGR tout contrat nécessaire à son auto-suffisance.
+
 ## Instanciation d'un projet
 
 Le flux conceptuel est :

docs/objectives/001-PROJECT_OBJECTIVES.md

@@ -1,5 +1,5 @@
 <!-- file: docs/objectives/001-PROJECT_OBJECTIVES.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Objectifs de Project Governance Rules
 
@@ -18,9 +18,11 @@ PGR doit permettre de :
 - favoriser des validations ciblées pendant le développement et des gates plus larges aux jalons appropriés ;
 - automatiser les contrôles déterministes et fiables sans automatiser artificiellement les décisions nécessitant du jugement ;
 - fournir des templates techniques éprouvés sans créer de dépendance vers PGR après instanciation ;
-- décrire des skeletons de projets sous forme de recettes Markdown composables plutôt que de générateurs rigides ;
+- décrire des skeletons de projets sous forme de spécifications Markdown composables plutôt que de générateurs rigides ;
 - supporter plusieurs langages, plateformes et frameworks sans chercher une uniformité artificielle ;
 - conserver une traçabilité historique utile tout en gardant les documents vivants lisibles ;
+- rester auto-suffisant pour comprendre et appliquer les contrats normatifs PGR, sans dépendre d’un howto, snippet ou dépôt documentaire externe ;
+- permettre que les howtos détaillés, recettes pratiques, snippets, exemples d’intégration, dépannage, comparatifs et variantes d’implémentation vivent dans une base de connaissances séparée lorsqu’une telle séparation apporte une valeur réelle ;
 - permettre des règles project-specific et des exceptions explicites sans contaminer les règles générales ;
 - privilégier la sécurité, l'explicité, la maintenabilité et la proportionnalité.
 
@@ -45,6 +47,7 @@ PGR n'a pas pour objectif de :
 - créer des audits regex pour remplacer le jugement architectural ;
 - réimplémenter les fonctionnalités des toolchains officielles sans bénéfice réel ;
 - maintenir automatiquement les projets créés à partir de PGR ;
+- devenir une base exhaustive de howtos, recettes, snippets ou dépannage lorsque ces contenus ne sont pas nécessaires pour comprendre ou appliquer un contrat PGR ;
 - imposer une stratégie Git complexe ou une topologie universelle de branches.
 
 ## Critères de succès à terme

docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge
 
@@ -214,7 +214,7 @@ frontière PGR / Knowledge
 
 Aucun nouveau owner Knowledge n’est prévu par défaut.
 
-## Progression acquise avant `alpha.3`
+## Progression acquise avant `alpha.4`
 
 La première gate `alpha.1` a acquis les tests et audits principaux mais n'a pas exécuté toutes les assertions contractuelles prévues par son delta. Son history conserve donc le résultat réel `PARTIAL`.
 
@@ -240,6 +240,17 @@ Décisions de mise en œuvre `alpha.3` :
 - `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent `KEEP` : leur contrat de reprise depuis la baseline autoritaire du projet est déjà compatible ;
 - la frontière PGR / SaseDev Knowledge reste réservée à `alpha.4`.
 
+La gate opérateur de `alpha.3` du `2026-10-01` est `PASS` avec `55/55` tests, les audits documentaires propres et le scope Git attendu. Le contrat d'autonomie locale est donc acquis avant ouverture de `alpha.4`.
+
+Décisions de mise en œuvre `alpha.4` :
+
+- remplacer les formulations « recette Markdown » des skeletons par « spécification Markdown composable » afin de ne pas confondre contrat structurel PGR et recette pratique ;
+- formaliser dans `300-DOCUMENTATION.md` une frontière documentaire où PGR possède les éléments nécessaires à ses contrats normatifs et où les howtos détaillés, recettes, snippets, exemples, dépannage, comparatifs et variantes MAY vivre dans une base de connaissances séparée ;
+- mentionner SaseDev Knowledge uniquement comme destination pratique possible, jamais comme owner normatif ni dépendance requise ;
+- imposer l'auto-suffisance de PGR : aucun howto/snippet externe ne peut être nécessaire pour déterminer la force, le scope ou les exigences d'une règle PGR ;
+- conserver toute migration physique hors scope de `0.1.5` tant qu'une destination Knowledge autoritaire n'est pas explicitement fournie et vérifiée ;
+- ne créer aucun nouvel owner Knowledge et ne modifier aucun history antérieur.
+
 ## Trajectoire de release
 
 ### `alpha.1` — intake, audit transversal et plan

docs/rules/300-DOCUMENTATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/300-DOCUMENTATION.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Documentation rules
 
@@ -145,6 +145,27 @@ Un répertoire générique tel que `misc/` SHOULD NOT devenir la destination par
 
 Une technologie ou un projet MAY introduire des familles supplémentaires lorsqu'elles représentent une responsabilité documentaire stable.
 
+## Frontière normative et pratique
+
+La documentation gouvernée par PGR distingue les informations nécessaires au contrat PGR des contenus pratiques complémentaires.
+
+Restent possédés par PGR lorsqu'ils sont nécessaires à la compréhension ou à l'application du référentiel :
+
+- règles et contrats de gouvernance ;
+- objectifs et architecture qui définissent le sens durable du référentiel ;
+- owners normatifs ;
+- skeleton specifications minimales ;
+- templates nécessaires à un contrat réutilisable ;
+- matrices, validations et preuves directement liées aux règles.
+
+Les howtos détaillés, recettes pratiques, snippets, exemples d'intégration, dépannage, comparatifs et variantes d'implémentation MAY être maintenus dans une base de connaissances séparée lorsqu'une destination réelle et autoritaire existe. SaseDev Knowledge MAY jouer ce rôle, sans devenir un owner normatif de PGR.
+
+PGR MUST rester auto-suffisant : une règle PGR MUST être compréhensible et applicable sans consulter un howto ou snippet externe. Un contenu externe MAY fournir des exemples ou une aide opérationnelle, mais MUST NOT être requis pour déterminer la force, le scope ou les exigences d'une règle PGR.
+
+Classifier un contenu comme pratique ne crée pas une obligation de déplacement. Une migration physique vers une base de connaissances externe MUST être une opération explicitement décidée, fondée sur une destination autoritaire fournie et vérifiée. Tant que cette condition n'est pas remplie, le contenu existant MAY rester dans PGR s'il conserve une utilité réelle.
+
+Cette séparation MUST NOT créer de dépendance de PGR vers SaseDev Knowledge ou vers un autre dépôt documentaire externe.
+
 ## Idées, études et décisions
 
 Une idée est une possibilité non engagée. Elle ne doit pas être présentée comme une décision ou une promesse de roadmap.