0.1.5-rc.1

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 51 -->
+<!-- version: 52 -->
 
 # Documentation PGR
 
@@ -22,12 +22,14 @@ 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 `alpha.4`, puis réconciliation transversale `beta.1` avant freeze RC.
+- [`plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan actif de la candidate `0.1.5` : contrats normatifs/autonomie/Knowledge acquis, réconciliation `beta.1` validée et freeze `rc.1` avec revue d’horizon/handoff.
 - [`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 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.
 - `beta.1` réconcilie les trois contrats sans nouvel owner normatif : les renforcements `SHOULD` connus restent corrigés, `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent compatibles avec l’autonomie locale, et les références vivantes Games/KSP/audits restent respectivement réservées à `0.1.6`, `0.1.7` et `0.1.8`.
+- [`studies/005-V0_1_5_HORIZON_REVIEW.md`](studies/005-V0_1_5_HORIZON_REVIEW.md) — revue limitée `rc.1` confirmant que l’adoption Games `0.1.6` reste la prochaine dépendance réelle sans nouveau prérequis transversal ni réservation de `0.1.9`.
+- [`../prompts/012-V0_1_6_START_PROMPT.md`](../prompts/012-V0_1_6_START_PROMPT.md) — handoff préparé vers l’adoption réelle de `sasedev-games` en `0.1.6-alpha.1`, à utiliser uniquement après publication et vérification post-tag de `v0.1.5` avec un corpus Games autoritaire explicitement fourni.
 - [`../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/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: 5 -->
+<!-- version: 6 -->
 
 # Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge
 
@@ -270,6 +270,25 @@ La réconciliation confirme également :
 
 Décision `beta.1` : **KEEP des owners normatifs acquis**. La tranche documente et valide la réconciliation ; elle n'ajoute aucun owner, ne modifie aucune règle normative et ne commence aucun scope futur.
 
+La gate opérateur de `beta.1` du `2026-10-01` est `PASS` avec `55/55` tests, l'audit d'hygiène texte propre sur `321` fichiers, les audits Markdown propres et le scope Git attendu. La phase de réconciliation est donc acquise avant ouverture de `rc.1`.
+
+## Freeze et revue d’horizon préparés en `rc.1`
+
+`rc.1` gèle les owners normatifs acquis : aucune règle, skeleton, template ou validation stabilisés pendant `alpha.2` à `alpha.4` n'est réouvert sans défaut démontré.
+
+La revue d'horizon limitée matérialisée dans `docs/studies/005-V0_1_5_HORIZON_REVIEW.md` conclut qu'aucun nouveau prérequis transversal ne doit précéder l'adoption Games. La trajectoire reste :
+
+```text
+0.1.6   adoption sasedev-games
+0.1.7   adoption khadhroony-solana-project
+0.1.8   audits Rust/Clippy read-only
+0.1.9   NOT RESERVED
+```
+
+Le prompt `012-V0_1_6_START_PROMPT.md` prépare donc une reprise `0.1.6-alpha.1` à partir d'une future stable PGR `v0.1.5` réellement publiée et d'une archive Games récente explicitement autoritaire. Il impose un intake/cartographie avant toute migration et conserve le contrat d'autonomie locale après adoption.
+
+La RC ne commence ni l'adoption Games, ni KSP, ni les audits `0.1.8`.
+
 ## Trajectoire de release
 
 ### `alpha.1` — intake, audit transversal et plan

docs/studies/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/000-README.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Index des études PGR
 
@@ -13,3 +13,4 @@ Une étude peut comparer des projets sources, des technologies ou plusieurs opti
 - [`002-TAURI_SKELETON_DECISION.md`](002-TAURI_SKELETON_DECISION.md) — décision historique `DEFER` du skeleton Tauri, complétée en `0.1.1-beta.1` par la preuve que ses cinq prérequis Web disposent désormais d'owners PGR, sans lever le report avant `0.1.4`.
 - [`003-V0_1_0_HORIZON_REVIEW.md`](003-V0_1_0_HORIZON_REVIEW.md) — revue d'horizon `0.1.0-beta.1` engageant les prochaines releases `0.1.x` suffisamment décidées et conservant les autres axes sans numéro.
 - [`004-V0_1_4_HORIZON_REVIEW.md`](004-V0_1_4_HORIZON_REVIEW.md) — revue de fermeture `0.1.4` clarifiant le besoin d’une release `0.1.5` dédiée à la sémantique normative, à l’autonomie des projets et à la frontière PGR / SaseDev Knowledge avant les adoptions Games/KSP.
+- [`005-V0_1_5_HORIZON_REVIEW.md`](005-V0_1_5_HORIZON_REVIEW.md) — revue de fermeture `0.1.5` confirmant qu’aucun nouveau prérequis transversal ne précède l’adoption réelle de `sasedev-games` en `0.1.6`, puis KSP `0.1.7` et les audits Rust/Clippy `0.1.8`.

docs/studies/005-V0_1_5_HORIZON_REVIEW.md

@@ -0,0 +1,105 @@
+<!-- file: docs/studies/005-V0_1_5_HORIZON_REVIEW.md -->
+<!-- version: 1 -->
+
+# Revue d’horizon 0.1.5 — adoption Games après stabilisation des contrats transversaux
+
+## Objet
+
+Cette étude clôt la revue d’horizon limitée exigée par le plan `0.1.5`. Elle vérifie si la stabilisation de la sémantique normative, de l’autonomie locale et de la frontière PGR / SaseDev Knowledge révèle un nouveau prérequis avant l’adoption réelle de `sasedev-games`.
+
+La revue ne cherche pas à prolonger artificiellement la roadmap. Elle réévalue uniquement les dépendances déjà engagées et les faits démontrés pendant `0.1.5`.
+
+## Contrats acquis en 0.1.5
+
+La release candidate s’appuie sur trois contrats désormais réconciliés :
+
+```text
+SHOULD / SHOULD NOT   forte recommandation non obligatoire
+baseline locale       autorité des sessions/releases suivantes
+PGR / Knowledge       PGR normatif auto-suffisant, Knowledge pratique complémentaire
+```
+
+La gate `beta.1` confirme qu’aucun nouveau renforcement accidentel de `SHOULD`, aucune dépendance implicite à une version PGR plus récente et aucune dépendance normative vers SaseDev Knowledge ne restent démontrés dans les owners relus.
+
+## Vérification du prochain prérequis réel
+
+La trajectoire précédente réserve :
+
+```text
+0.1.6   adoption sasedev-games
+0.1.7   adoption khadhroony-solana-project
+0.1.8   audits Rust/Clippy read-only
+```
+
+`0.1.5` n’a révélé aucun owner transversal supplémentaire qui devrait obligatoirement précéder l’adoption Games.
+
+Les contrats maintenant disponibles suffisent pour engager une adoption proportionnée :
+
+- classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
+- distinction explicite entre obligations `MUST` et recommandations `SHOULD` ;
+- baseline locale autonome après adoption ;
+- réalignement futur uniquement explicite et fondé sur un snapshot PGR choisi ;
+- validation proportionnée au scope réellement applicable ;
+- absence de dépendance normative vers Knowledge.
+
+Décision : **conserver `0.1.6` comme prochaine release et y effectuer l’adoption réelle de `sasedev-games`**.
+
+## Corpus requis pour 0.1.6
+
+La future session `0.1.6` doit disposer de deux baselines autoritaires distinctes :
+
+1. la stable PGR `v0.1.5` réellement publiée et vérifiée post-tag ;
+2. une archive récente et explicitement autoritaire de `sasedev-games`, fournie comme corpus d’adoption.
+
+Aucun numéro de version Games n’est figé par cette étude. Le corpus Games doit être celui réellement fourni au démarrage de la session ; ne pas reconstruire ou supposer une baseline à partir d’un ancien historique PGR.
+
+L’absence d’un corpus Games autoritaire empêche de commencer l’adoption réelle, mais n’autorise pas à inventer ses décisions, son architecture ou son applicabilité technologique.
+
+## Méthode attendue pour l’adoption Games
+
+`0.1.6` doit commencer par un audit, pas par une réécriture globale.
+
+Pour chaque règle, profil, skeleton, template ou validation PGR potentiellement applicable, la session doit décider explicitement :
+
+```text
+ADOPT        intégré dans la baseline locale Games
+KEEP-LOCAL   décision Games conservée comme autorité locale
+OVERRIDE     contradiction réelle avec un MUST PGR applicable, documentée et bornée
+DEFER        applicable potentiellement mais non justifié dans le scope courant
+N/A          non applicable au corpus Games observé
+```
+
+Un simple écart à un `SHOULD / SHOULD NOT` ne constitue pas à lui seul un `OVERRIDE`.
+
+L’adoption doit préserver les décisions produit et architectures locales qui ne relèvent pas de PGR. Les anciens POCs, technologies historiques ou artefacts expérimentaux ne doivent pas devenir des surfaces applicables uniquement parce qu’ils existent dans l’historique : leur applicabilité doit être démontrée par la baseline Games fournie.
+
+## Autorité après adoption
+
+`0.1.6` doit exercer le contrat stabilisé en `0.1.5` : une fois l’adoption matérialisée, les règles, plans, architecture, histories et autres owners locaux de Games deviennent l’autorité des sessions/releases suivantes du projet.
+
+PGR ne devient pas un upstream documentaire à suivre. Un futur réalignement Games/PGR doit rester une opération explicitement décidée à partir d’un snapshot PGR précis.
+
+## Trajectoire conservée
+
+Aucune dépendance nouvelle ne justifie un changement d’ordre :
+
+```text
+0.1.5   sémantique normative + autonomie + frontière PGR/Knowledge
+0.1.6   adoption sasedev-games
+0.1.7   adoption khadhroony-solana-project
+0.1.8   audits Rust/Clippy read-only
+```
+
+`0.1.7` reste séparée afin que l’adoption KSP soit instruite contre son propre corpus et son propre scope applicable.
+
+`0.1.8` reste postérieure aux deux adoptions : les audits Rust/Clippy statiques doivent être dérivés de besoins effectivement éprouvés et ne pas être inventés avant les retours d’adoption.
+
+Aucun `0.1.9` n’est réservé par cette revue.
+
+## Hors scope de la présente RC
+
+Cette étude ne commence pas l’adoption Games et ne modifie aucune règle Games.
+
+Elle ne commence ni l’adoption KSP, ni les audits Rust/Clippy `0.1.8`, ni une migration de contenu vers SaseDev Knowledge.
+
+Elle ne transforme pas PGR en dépendance des projets adoptés et ne crée aucun mécanisme automatique de suivi de la dernière version PGR.