0.1.5-alpha.2

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 28 -->
+<!-- version: 29 -->
 
 # Project Governance Rules
 
@@ -11,7 +11,7 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`.
 
 ## Statut
 
-La stable autoritaire courante reste `0.1.4`. Le travail `0.1.5-alpha.1` ouvre maintenant l’audit transversal décidé par sa revue d’horizon : clarification de la force de `MUST / SHOULD / MAY`, autonomie des projets après instanciation/adoption et frontière PGR / SaseDev Knowledge. Cette tranche d’ouverture inventorie les ambiguïtés et fixe les owners à réconcilier sans modifier encore les règles normatives ; les adoptions Games `0.1.6`, KSP `0.1.7` et les audits Rust/Clippy `0.1.8` restent hors scope.
+La stable autoritaire courante reste `0.1.4`. Le travail `0.1.5-alpha.2` stabilise maintenant le premier contrat transversal décidé par sa revue d’horizon : `SHOULD / SHOULD NOT` est une forte recommandation non obligatoire, distincte des obligations `MUST / MUST NOT`, et son non-respect ne crée ni `FAIL` de gate ni `OVERRIDE` automatique. La tranche corrige uniquement les renforcements accidentels démontrés par l'inventaire `alpha.1` ; l'autonomie post-adoption reste réservée à `alpha.3`, la frontière PGR / SaseDev Knowledge à `alpha.4`, et les adoptions Games `0.1.6`, KSP `0.1.7` ainsi que les audits Rust/Clippy `0.1.8` restent hors scope.
 
 La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` établit la gouvernance normative et documentaire de PGR lui-même. La release `0.0.2` ajoute les premiers profils réutilisables Rust/Cargo, Java/Maven/Gradle et Android, ainsi que deux audits Markdown. La release `0.0.3` fournit les premiers modèles Rust/Cargo, deux audits de style Rust facultatifs, l'audit des headers Markdown et la spécification du message manuel de reprise. La release `0.0.4` définit le contrat transversal des skeleton specifications, ajoute une fondation composable de gouvernance locale et une première spécialisation Rust/Cargo workspace fondée sur les profils `500 + 510` et les cinq templates existants. La release `0.0.5` réconcilie PGR avec les baselines réelles de `khadhroony-solana-project` et `sasedev-games` : prompts versionnés, contrats documentaires locaux, lifecycle inter-release, profil Rust strict et audits monotâches, premier profil Tauri 2 et décision explicite de différer son skeleton complet jusqu'à matérialisation d'owners Web suffisants. La release `0.1.0` stabilise la première baseline réutilisable : adoption `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, skeletons/templates Rust/Cargo exercés par dry-run, clôture `rel.N`, handoff opérateur automatique et trajectoire `0.1.1` à `0.1.7` issue d'une revue d'horizon explicite. La release `0.1.1` stabilise la fondation frontend Web : owners indépendants TypeScript/package/Vite/CSS-Sass, déclarations de types externes conditionnelles, package manager neutre, validation frontend indépendante du host et skeleton Web composable, tout en conservant le skeleton Tauri en `DEFER` jusqu’à son réexamen `0.1.4`. La release `0.1.2` stabilise trois owners indépendants `520-JAVA`, `521-MAVEN` et `522-GRADLE`, clarifie JDK/source/bytecode et l'ownership Gradle, conserve Maven cohérent sans corpus artificiel et maintient les responsabilités Android dans `610-ANDROID.md` pour leur réévaluation distincte en `0.1.3`. La release `0.1.3` stabilise le profil Android générique : séparation des responsabilités SDK et identité applicative, contraintes natives conditionnelles, Android Lint explicite, niveaux de tests distincts, frontières APK/AAB et compatibilité 16 KB liée au code natif et au canal de distribution, sans imposer les versions ou ABI propres à Games. La release `0.1.4` stabilise le domaine Tauri : owner `710` recentré sur host/orchestration/ACL/plugins, skeleton `004` composable avec Rust/Cargo et Web, absence assumée de template technique générique ou de validation Tauri redondante, audit d’hygiène texte réutilisable et handoff vers `0.1.5` pour clarifier la sémantique normative et l’autonomie des projets.
 

RULES.md

@@ -1,5 +1,5 @@
 <!-- file: RULES.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # Index normatif Project Governance Rules
 
@@ -19,11 +19,11 @@ La gouvernance doit rester proportionnée au risque, à la portée du changement
 
 PGR utilise les termes suivants :
 
-- `MUST` / `MUST NOT` : obligation ou interdiction dans le scope de la règle, sauf override ou exception explicitement documenté ;
+- `MUST` / `MUST NOT` : obligation ou interdiction normative dans le scope de la règle ; une contradiction applicable doit être traitée par l'exception ou l'override autorisé, sinon elle constitue une non-conformité ;
-- `SHOULD` / `SHOULD NOT` : comportement attendu par défaut, avec dérogation possible lorsqu'une solution différente est mieux adaptée et justifiée ;
+- `SHOULD` / `SHOULD NOT` : forte recommandation non obligatoire. Un écart ne constitue pas à lui seul une non-conformité, ne fait pas échouer à lui seul une gate et n'exige pas automatiquement un `OVERRIDE` ; la raison MAY être documentée lorsqu'elle apporte une valeur durable de maintenance, architecture ou reprise ;
-- `MAY` : possibilité reconnue, sans obligation implicite.
+- `MAY` : possibilité neutre reconnue, sans obligation implicite.
 
-Une règle qualitative ne doit pas être artificiellement transformée en `MUST` lorsqu'elle n'est ni objectivement vérifiable ni raisonnablement révisable.
+Une règle qualitative ne doit pas être artificiellement transformée en `MUST` lorsqu'elle n'est ni objectivement vérifiable ni raisonnablement révisable. Une gate, un skeleton, un template ou un profil plus spécifique MUST conserver cette distinction de force normative au lieu de renforcer implicitement un `SHOULD`.
 
 ## Hiérarchie normative
 
@@ -45,7 +45,7 @@ project-specific
 explicit exception
 ```
 
-Une règle plus spécifique MAY raffiner, renforcer ou remplacer localement une règle générale dans son scope. Une contradiction intentionnelle MUST être déclarée comme override ou exception, avec scope et raison. Une contrainte locale ne se propage jamais automatiquement aux autres projets ou profils.
+Une règle plus spécifique MAY raffiner ou renforcer localement une règle générale dans son scope. Lorsqu'elle contredit intentionnellement un `MUST` / `MUST NOT` réellement applicable, cette contradiction MUST être déclarée comme override ou exception, avec scope et raison. Un choix différent d'un `SHOULD` / `SHOULD NOT` n'est pas, par lui-même, une contradiction normative exigeant un override. Une contrainte locale ne se propage jamais automatiquement aux autres projets ou profils.
 
 ## Principes fondamentaux
 

VERSION

@@ -1 +1 @@
-0.1.5-alpha.1.fix.1
+0.1.5-alpha.2

deltas/0.1.5/alpha.2.md

@@ -0,0 +1,196 @@
+<!-- file: deltas/0.1.5/alpha.2.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.5-alpha.2 — sémantique normative et conséquences de gate/adoption
+
+## Objet
+
+Stabiliser la force normative de `MUST / SHOULD / MAY` après le cadrage `alpha.1` et la récupération de preuve `alpha.1.fix.1`, puis corriger uniquement les renforcements accidentels démontrés par l'inventaire.
+
+La tranche ne convertit pas mécaniquement les `242` occurrences de `SHOULD / SHOULD NOT`. Elle fixe le contrat transversal, aligne adoption et validation, puis corrige les quelques owners/skeletons/templates où une recommandation était implicitement transformée en obligation de justification ou en `OVERRIDE`.
+
+## Précondition
+
+Le history `history/0.1.5/alpha.1.fix.1.md` doit être présent avec statut `PASS` avant application de ce delta.
+
+La séquence d'ouverture reste conservée telle qu'observée :
+
+```text
+alpha.1          PARTIAL
+alpha.1.fix.1    PASS
+```
+
+Le `PARTIAL` n'est pas réécrit : le fix a seulement acquis les preuves manquantes et autorise maintenant la progression vers la sémantique normative.
+
+## Contrat normatif stabilisé
+
+`RULES.md` devient l'owner primaire de la distinction :
+
+```text
+MUST / MUST NOT       obligation ou interdiction normative
+SHOULD / SHOULD NOT   forte recommandation non obligatoire
+MAY                   possibilité neutre
+```
+
+Un écart à un `SHOULD / SHOULD NOT` PGR :
+
+- ne constitue pas à lui seul une non-conformité ;
+- ne fait pas échouer à lui seul une gate ;
+- n'exige pas automatiquement un `OVERRIDE` ;
+- MAY être documenté lorsque la raison apporte une valeur durable de maintenance, architecture ou reprise.
+
+Une contradiction avec un `MUST / MUST NOT` réellement applicable reste distincte et continue d'utiliser l'exception ou l'override autorisé par le scope concerné.
+
+## Alignement adoption et validation
+
+`docs/rules/230-ADOPTION.md` passe en révision `2` : la classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ne renforce plus implicitement un `SHOULD`. Un simple choix différent d'une recommandation ne devient pas un `OVERRIDE` obligatoire.
+
+`docs/rules/400-VALIDATION.md` passe en révision `2` : une gate doit distinguer obligation et recommandation. Un `SHOULD` non suivi peut produire une observation, un diagnostic ou un point de revue, mais pas un `FAIL` par sa seule force PGR. Un projet peut rendre localement un choix obligatoire uniquement en matérialisant explicitement ce contrat local.
+
+## Réconciliation ciblée des effets `SHOULD`
+
+Les owners et artefacts suivants sont corrigés parce que `alpha.1` a démontré un renforcement concret :
+
+- `docs/rules/500-LANGUAGES.md` révision `2` : un override est requis pour une contradiction réelle avec un `MUST / MUST NOT`, pas pour un simple écart à un `SHOULD` ;
+- `docs/rules/530-TYPESCRIPT.md` révision `4` : choisir JavaScript malgré la recommandation TypeScript ne crée ni non-conformité, ni override, ni justification obligatoire ;
+- `docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` révision `4` : la politique de lockfile reste une recommandation lorsqu'elle est marquée `SHOULD`, et la référence vivante Games est corrigée de `0.1.5` vers `0.1.6` ;
+- `docs/rules/700-FRAMEWORKS.md` révision `3` : la composition conserve la force normative propre des règles héritées au lieu de traiter toute divergence comme override ;
+- `docs/skeletons/003-WEB_FRONTEND.md` révision `2` : un choix JavaScript n'impose plus de justification automatique ;
+- `docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md` révision `3` : une politique de lockfile différente n'exige plus automatiquement `OVERRIDE` + justification.
+
+Les `MUST` réellement applicables de ces documents restent inchangés dans leur intention.
+
+## Cohérence documentaire
+
+- `README.md` présente `0.1.5-alpha.2` comme la tranche active sans déclarer la stable `0.1.4` remplacée ;
+- `docs/000-README.md` marque les owners de sémantique comme réconciliés en `alpha.2` ;
+- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `2`, conserve les constats `alpha.1` comme observations historiques et enregistre la récupération `alpha.1.fix.1` ainsi que la mise en œuvre `alpha.2`.
+
+`ROADMAP.md` et `CHANGELOG.md` restent inchangés. Les histories `0.1.4`, les adoptions Games/KSP et les futurs audits Rust/Clippy restent hors scope.
+
+## Gate opérateur
+
+Appliquer le delta après commit/push de `alpha.1.fix.1`, puis exécuter depuis la racine du dépôt :
+
+```bash
+cat VERSION
+
+test -f history/0.1.5/alpha.1.md
+test -f history/0.1.5/alpha.1.fix.1.md
+test -f deltas/0.1.5/alpha.2.md
+test ! -e history/0.1.5/alpha.2.md
+
+grep -Fx '0.1.5-alpha.2' VERSION
+grep -A2 '^## Statut$' history/0.1.5/alpha.1.md | grep -Fx 'PARTIAL'
+grep -A2 '^## Statut$' history/0.1.5/alpha.1.fix.1.md | grep -Fx 'PASS'
+
+grep -Fx '<!-- version: 15 -->' RULES.md
+grep -F 'forte recommandation non obligatoire' RULES.md
+grep -F "n'exige pas automatiquement un \`OVERRIDE\`" RULES.md
+grep -F "ne fait pas échouer à lui seul une gate" RULES.md
+
+grep -Fx '<!-- version: 2 -->' docs/rules/230-ADOPTION.md
+grep -F "ne crée pas à lui seul un \`OVERRIDE\` obligatoire" docs/rules/230-ADOPTION.md
+grep -F 'MUST NOT exiger un override uniquement parce que la recommandation' docs/rules/230-ADOPTION.md
+
+grep -Fx '<!-- version: 2 -->' docs/rules/400-VALIDATION.md
+grep -F 'MUST NOT faire passer une tranche en `FAIL`' docs/rules/400-VALIDATION.md
+grep -F "la gate évalue alors ce contrat local, pas le \`SHOULD\` PGR d'origine" docs/rules/400-VALIDATION.md
+
+grep -Fx '<!-- version: 2 -->' docs/rules/500-LANGUAGES.md
+grep -F "Un choix différent d'un \`SHOULD / SHOULD NOT\` général ne nécessite pas, à lui seul, un override" docs/rules/500-LANGUAGES.md
+
+grep -Fx '<!-- version: 4 -->' docs/rules/530-TYPESCRIPT.md
+grep -F "n'exige pas automatiquement un \`OVERRIDE\` et ne crée pas une obligation de justification" docs/rules/530-TYPESCRIPT.md
+! grep -F 'sauf incompatibilité documentée' docs/rules/530-TYPESCRIPT.md
+
+grep -Fx '<!-- version: 4 -->' docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
+grep -F "Lors de l'adoption \`0.1.6\`" docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
+! grep -F "Lors de l'adoption \`0.1.5\`" docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
+grep -F "ne requiert pas à lui seul un \`OVERRIDE\`" docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
+
+grep -Fx '<!-- version: 3 -->' docs/rules/700-FRAMEWORKS.md
+grep -F "MAY choisir différemment d'un \`SHOULD / SHOULD NOT\`" docs/rules/700-FRAMEWORKS.md
+
+grep -Fx '<!-- version: 2 -->' docs/skeletons/003-WEB_FRONTEND.md
+grep -F "sans transformer un choix JavaScript en obligation de justification ou en \`OVERRIDE\`" docs/skeletons/003-WEB_FRONTEND.md
+
+grep -Fx '<!-- version: 3 -->' docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md
+grep -F "n'exige pas à lui seul un \`OVERRIDE\` ni une justification" docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md
+
+grep -Fx '<!-- version: 2 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'un écart à cette recommandation ne crée ni non-conformité, ni `FAIL` de gate, ni `OVERRIDE` automatique' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+
+grep -F -- '- `( ) 0.1.6`' ROADMAP.md
+grep -F -- '- `( ) 0.1.7`' ROADMAP.md
+grep -F -- '- `( ) 0.1.8`' ROADMAP.md
+! grep -F -- '- `( ) 0.1.9`' ROADMAP.md
+
+python3 -B -c "from pathlib import Path; expected={'0.0.1':12,'0.0.2':12,'0.0.3':10,'0.0.4':9,'0.0.5':19,'0.1.0':10,'0.1.1':11,'0.1.2':7,'0.1.3':6,'0.1.4':7}; assert all({p.name for p in Path('deltas',r).glob('*.md')} == {p.name for p in Path('history',r).glob('*.md')} and len(list(Path('deltas',r).glob('*.md'))) == n for r,n in expected.items()); assert {p.name for p in Path('deltas/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md'}; print('0.1.5 alpha.2 history boundary: clean (105 closed prior pairs, current alpha.2 pending)')"
+
+git diff --exit-code -- history/0.1.4
+
+python3 -B -m unittest discover -s tests -v
+
+python3 -B scripts/audit_text_hygiene.py \
+    README.md RULES.md ROADMAP.md CHANGELOG.md VERSION \
+    docs deltas history prompts scripts tests templates .gitignore .settings
+
+python3 -B scripts/audit_markdown_headers.py \
+    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
+
+python3 -B scripts/audit_markdown_tables.py \
+    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
+
+python3 -B scripts/audit_markdown_links.py \
+    README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
+
+git diff --check
+git status --short
+
+git add VERSION README.md RULES.md docs/000-README.md \
+    docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
+    docs/rules/230-ADOPTION.md docs/rules/400-VALIDATION.md \
+    docs/rules/500-LANGUAGES.md docs/rules/530-TYPESCRIPT.md \
+    docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md docs/rules/700-FRAMEWORKS.md \
+    docs/skeletons/003-WEB_FRONTEND.md docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md \
+    deltas/0.1.5/alpha.2.md
+
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history est exactement :
+
+```text
+M  README.md
+M  RULES.md
+M  VERSION
+A  deltas/0.1.5/alpha.2.md
+M  docs/000-README.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+M  docs/rules/230-ADOPTION.md
+M  docs/rules/400-VALIDATION.md
+M  docs/rules/500-LANGUAGES.md
+M  docs/rules/530-TYPESCRIPT.md
+M  docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
+M  docs/rules/700-FRAMEWORKS.md
+M  docs/skeletons/003-WEB_FRONTEND.md
+M  docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md
+```
+
+## Revue opérateur attendue
+
+La revue doit confirmer que la tranche clarifie la force de `SHOULD` sans affaiblir les obligations existantes ; qu'aucun `SHOULD` n'est transformé en `MUST` par une gate, un mapping d'adoption, un skeleton ou un template ; et que les corrections Web ciblées restent des conséquences de la sémantique générale plutôt qu'une réouverture de la fondation Web.
+
+Elle doit également confirmer que l'autonomie post-adoption n'est pas encore implémentée par `alpha.2`, que la frontière PGR / Knowledge n'est pas encore modifiée, et que les scopes `0.1.6` à `0.1.8` restent réservés.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.5/alpha.2.md` à partir des résultats réellement observés. Dans la même réponse, fournir les commandes commit/push de `0.1.5-alpha.2`, puis préparer séparément `0.1.5-alpha.3` consacré à l'autonomie locale et au réalignement PGR volontaire.
+
+### FAIL / PARTIAL / BLOCKED
+
+Enregistrer le résultat réel dans `history/0.1.5/alpha.2.md` puis ouvrir `alpha.2.fix.N` ou un REPLAN selon la cause. Aucun changement réservé à l'autonomie `alpha.3` ou à la frontière Knowledge `alpha.4` ne doit être absorbé silencieusement dans la correction.

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 47 -->
+<!-- version: 48 -->
 
 # Documentation PGR
 
@@ -22,9 +22,9 @@ 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`, sémantique normative, autonomie locale, 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, frontière PGR / Knowledge, 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éconcilier pour la force de `SHOULD`, les conséquences de gate et la distinction entre recommandation, choix local et `OVERRIDE`.
+- [`../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), [`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) — propagation du contrat d'autonomie après instanciation/adoption.
 - [`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.
 - [`../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.

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: 1 -->
+<!-- version: 2 -->
 
 # Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge
 
@@ -126,30 +126,30 @@ L’inventaire a recherché les formulations `SHOULD / SHOULD NOT`, les contrats
 
 Sur le corpus normatif/documentaire courant analysé, `29` fichiers contiennent au moins un `SHOULD` ou `SHOULD NOT`, pour `242` occurrences textuelles brutes. Ce volume interdit une conversion mécanique : la majorité de ces recommandations sont légitimes et doivent seulement hériter d’une sémantique globale claire.
 
-### Ambiguïtés normatives confirmées
+### Ambiguïtés normatives observées en `alpha.1`
 
-`RULES.md` décrit actuellement `SHOULD / SHOULD NOT` comme un comportement attendu avec dérogation lorsque l’alternative est « mieux adaptée et justifiée ». Cette formulation peut rendre la justification obligatoire et doit devenir l’owner primaire de la clarification.
+Avant `alpha.2`, `RULES.md` décrivait `SHOULD / SHOULD NOT` comme un comportement attendu avec dérogation lorsque l’alternative était « mieux adaptée et justifiée ». Cette formulation pouvait rendre la justification obligatoire et a désigné `RULES.md` comme owner primaire de la clarification.
 
-`RULES.md` exige aussi un override pour une contradiction intentionnelle. Le texte doit distinguer explicitement une contradiction à une obligation d’un simple choix différent d’une recommandation.
+Avant `alpha.2`, `RULES.md` exigeait aussi un override pour toute contradiction intentionnelle sans distinguer explicitement une contradiction à une obligation d’un simple choix différent d’une recommandation.
 
-`docs/rules/400-VALIDATION.md` ne précise pas encore qu’un écart à un `SHOULD` ne peut pas, à lui seul, faire échouer une gate.
+Avant `alpha.2`, `docs/rules/400-VALIDATION.md` ne précisait pas qu’un écart à un `SHOULD` ne peut pas, à lui seul, faire échouer une gate.
 
-`docs/rules/230-ADOPTION.md` définit `OVERRIDE` comme le remplacement ou raffinement d’une règle PGR applicable. Sans clarification de la force normative, cette définition peut pousser à créer un override pour une simple recommandation non suivie.
+Avant `alpha.2`, `docs/rules/230-ADOPTION.md` définissait `OVERRIDE` comme le remplacement ou raffinement d’une règle PGR applicable. Sans clarification de la force normative, cette définition pouvait pousser à créer un override pour une simple recommandation non suivie.
 
-`docs/rules/500-LANGUAGES.md` et `docs/rules/700-FRAMEWORKS.md` utilisent des formulations d’exception/override qui doivent être relues après stabilisation de la sémantique globale afin de ne pas renforcer accidentellement un `SHOULD`.
+`docs/rules/500-LANGUAGES.md` et `docs/rules/700-FRAMEWORKS.md` utilisaient des formulations d’exception/override pouvant renforcer accidentellement un `SHOULD` ; `alpha.2` les a donc inclus dans la réconciliation ciblée.
 
-Des cas concrets confirment que l’ambiguïté n’est pas théorique :
+Les cas concrets observés pendant `alpha.1` confirmaient que l’ambiguïté n’était pas théorique :
 
 - `docs/rules/530-TYPESCRIPT.md` associe une recommandation à une incompatibilité documentée ;
-- `docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` demande actuellement, pour la politique de lockfile, soit l’adoption de la recommandation soit un `OVERRIDE` ;
+- `docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` demandait alors, pour la politique de lockfile, soit l’adoption de la recommandation soit un `OVERRIDE` ;
-- `docs/skeletons/003-WEB_FRONTEND.md` exige une justification lorsqu’une nouvelle baseline durable n’adopte pas la recommandation TypeScript ;
+- `docs/skeletons/003-WEB_FRONTEND.md` exigeait une justification lorsqu’une nouvelle baseline durable n’adoptait pas la recommandation TypeScript ;
-- `docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md` impose une décision locale ou un `OVERRIDE` avec justification pour une politique de lockfile différente.
+- `docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md` imposait une décision locale ou un `OVERRIDE` avec justification pour une politique de lockfile différente.
 
-Ces cas doivent être corrigés de façon ciblée après la définition centrale, sans affaiblir les `MUST` réellement applicables.
+Ces cas ont été retenus pour une correction ciblée en `alpha.2`, sans affaiblir les `MUST` réellement applicables.
 
-### Ambiguïté de trajectoire confirmée
+### Ambiguïté de trajectoire observée en `alpha.1`
 
-`docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` conserve une référence vivante à « l’adoption `0.1.5` de Games ». La revue d’horizon `0.1.4` a déplacé cette adoption en `0.1.6`. Cette référence est donc obsolète et doit être corrigée comme cohérence documentaire vivante, sans modifier les plans, études, prompts ou histories qui décrivent correctement l’ancien horizon dans leur contexte historique.
+Avant `alpha.2`, `docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` conservait une référence vivante à « l’adoption `0.1.5` de Games ». La revue d’horizon `0.1.4` avait déplacé cette adoption en `0.1.6`. `alpha.2` corrige cette référence vivante sans modifier les plans, études, prompts ou histories qui décrivent correctement l’ancien horizon dans leur contexte historique.
 
 ### Autonomie — acquis à conserver
 
@@ -179,41 +179,58 @@ Ces acquis doivent être consolidés plutôt que réécrits en bloc.
 
 `docs/rules/300-DOCUMENTATION.md` est l’owner naturel pour formaliser la frontière documentaire sans créer un owner Knowledge artificiel. PGR ne doit pas créer une règle ou une collection dédiée uniquement parce que Knowledge existe comme produit séparé.
 
-## Owners proposés
+## Owners issus de l'inventaire
 
-Les modifications ne sont engagées qu’après validation de cet inventaire.
+L'inventaire `alpha.1` a fixé les owners ci-dessous. Leur modification reste répartie par tranche afin de ne pas mélanger sémantique normative, autonomie et frontière Knowledge.
 
 ```text
 sémantique primaire
-  RULES.md                                      MODIFY
+  RULES.md                                      MODIFY alpha.2
-  docs/rules/230-ADOPTION.md                    MODIFY
+  docs/rules/230-ADOPTION.md                    MODIFY alpha.2 puis alpha.3
-  docs/rules/400-VALIDATION.md                  MODIFY
+  docs/rules/400-VALIDATION.md                  MODIFY alpha.2
 
 réconciliation ciblée des effets SHOULD
-  docs/rules/500-LANGUAGES.md                   REVIEW / MODIFY IF NEEDED
+  docs/rules/500-LANGUAGES.md                   MODIFY alpha.2
-  docs/rules/530-TYPESCRIPT.md                  MODIFY
+  docs/rules/530-TYPESCRIPT.md                  MODIFY alpha.2
-  docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md MODIFY
+  docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md MODIFY alpha.2
-  docs/rules/700-FRAMEWORKS.md                  REVIEW / MODIFY IF NEEDED
+  docs/rules/700-FRAMEWORKS.md                  MODIFY alpha.2
-  docs/skeletons/003-WEB_FRONTEND.md            MODIFY
+  docs/skeletons/003-WEB_FRONTEND.md            MODIFY alpha.2
-  docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md  MODIFY
+  docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md  MODIFY alpha.2
 
 autonomie
-  RULES.md                                      MODIFY
+  RULES.md                                      MODIFY alpha.3
-  docs/rules/220-SKELETONS.md                   MODIFY
+  docs/rules/220-SKELETONS.md                   MODIFY alpha.3
-  docs/rules/230-ADOPTION.md                    MODIFY
+  docs/rules/230-ADOPTION.md                    MODIFY alpha.3
-  docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md MODIFY
+  docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md MODIFY alpha.3
-  docs/templates/007-EXISTING_PROJECT_ADOPTION.md MODIFY
+  docs/templates/007-EXISTING_PROJECT_ADOPTION.md MODIFY alpha.3
   docs/rules/210-WORKFLOW.md                    KEEP / REVIEW
   docs/templates/003-NEW_SESSION_PROMPT.md      KEEP / REVIEW
 
 frontière PGR / Knowledge
-  docs/objectives/001-PROJECT_OBJECTIVES.md     MODIFY
+  docs/objectives/001-PROJECT_OBJECTIVES.md     MODIFY alpha.4
-  docs/architecture/002-GOVERNANCE_ARCHITECTURE.md MODIFY
+  docs/architecture/002-GOVERNANCE_ARCHITECTURE.md MODIFY alpha.4
-  docs/rules/300-DOCUMENTATION.md               MODIFY
+  docs/rules/300-DOCUMENTATION.md               MODIFY alpha.4
 ```
 
 Aucun nouveau owner Knowledge n’est prévu par défaut.
 
+## Progression acquise avant `alpha.2`
+
+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`.
+
+`alpha.1.fix.1` a été limité à l'acquisition des preuves manquantes : trajectoire ROADMAP, frontière delta/history, assertions du prompt `011`, assertions du présent plan et audits documentaires. Cette récupération est `PASS` et n'a modifié aucun owner normatif.
+
+La tranche `alpha.2` peut donc appliquer la sémantique centrale sans réécrire les `242` occurrences de recommandations. Les modifications sont bornées aux owners et artefacts où l'inventaire a démontré un renforcement accidentel ou une référence vivante obsolète : `RULES.md`, `230`, `400`, `500`, `530`, `540`, `700`, le skeleton Web `003` et le guide `008`.
+
+Décisions de mise en œuvre `alpha.2` :
+
+- `SHOULD / SHOULD NOT` devient explicitement une forte recommandation non obligatoire ;
+- un écart à cette recommandation ne crée ni non-conformité, ni `FAIL` de gate, ni `OVERRIDE` automatique ;
+- un projet MAY documenter la raison d'un écart lorsqu'elle apporte une valeur durable ;
+- les contradictions avec des obligations `MUST / MUST NOT` restent soumises aux contrats d'exception/override applicables ;
+- la référence vivante à l'adoption Games est corrigée de `0.1.5` vers `0.1.6` ;
+- l'autonomie post-adoption reste réservée à `alpha.3` et la frontière Knowledge à `alpha.4`.
+
 ## Trajectoire de release
 
 ### `alpha.1` — intake, audit transversal et plan
@@ -278,9 +295,9 @@ Aucun nouveau owner Knowledge n’est prévu par défaut.
 - une migration physique vers SaseDev Knowledge ;
 - une conversion globale de tous les `SHOULD` en `MUST` ou `MAY`.
 
-## Gate de planification
+## Gate de planification `alpha.1` — historique
 
-`alpha.1` est prête à validation opérateur lorsque :
+`alpha.1` était prête à validation opérateur lorsque :
 
 - la baseline `0.1.4` a été rejouée proprement ;
 - l’historique `0.1.4` reste intact, y compris `alpha.2 FAIL` puis `alpha.2.fix.1 PASS` ;

docs/rules/230-ADOPTION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/230-ADOPTION.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Existing project adoption rules
 
@@ -50,6 +50,8 @@ OVERRIDE
 DEFER
 ```
 
+Ces classifications n'augmentent pas la force normative d'une règle. En particulier, choisir une solution différente d'un `SHOULD` / `SHOULD NOT` ne crée pas à lui seul un `OVERRIDE` obligatoire ; le projet MAY conserver ce choix comme décision locale et documenter sa raison lorsque cette trace apporte une valeur durable.
+
 ### ADOPT
 
 `ADOPT` signifie que le projet retient le contrat PGR applicable et migre son état local lorsque nécessaire.
@@ -64,9 +66,9 @@ Cette classification ne crée pas une exception : elle reconnaît qu’un choix
 
 ### OVERRIDE
 
-`OVERRIDE` signifie qu’une règle PGR applicable est volontairement remplacée ou raffinée dans un scope local.
+`OVERRIDE` signifie qu'une obligation PGR réellement applicable, ou un contrat localement rendu obligatoire, est volontairement remplacé ou raffiné dans un scope local.
 
-L’override MUST identifier la règle concernée, le scope, la raison et le contrat local retenu. Il ne doit pas être utilisé pour masquer une migration incomplète ou faire disparaître une violation non résolue.
+L'override MUST identifier la règle concernée, le scope, la raison et le contrat local retenu. Il ne doit pas être utilisé pour masquer une migration incomplète ou faire disparaître une violation non résolue. Un simple écart à une recommandation `SHOULD` / `SHOULD NOT` MUST NOT exiger un override uniquement parce que la recommandation n'est pas suivie.
 
 ### DEFER
 
@@ -119,7 +121,7 @@ Une adoption PGR réussie laisse :
 - un projet autonome ;
 - uniquement les owners PGR réellement applicables ;
 - les choix locaux légitimes préservés ;
-- les overrides explicites ;
+- les overrides explicites lorsqu'une obligation applicable est volontairement remplacée ;
 - les domaines différés clairement identifiés ;
 - un historique non falsifié ;
 - une validation proportionnée au changement réellement effectué.

docs/rules/400-VALIDATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/400-VALIDATION.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Validation rules
 
@@ -27,6 +27,12 @@ Une preuve déjà acquise MAY être réutilisée tant qu'aucun changement pertin
 
 Les gates de `beta`, `rc` et promotion stable MAY élargir volontairement la validation pour démontrer l'intégration ou la cohérence de release.
 
+## Force normative et résultat des gates
+
+Une gate MUST distinguer une obligation `MUST / MUST NOT` d'une recommandation `SHOULD / SHOULD NOT`. Un écart à un `SHOULD` ou `SHOULD NOT` PGR ne constitue pas à lui seul une preuve en échec et MUST NOT faire passer une tranche en `FAIL`.
+
+Une gate MAY signaler un écart à une recommandation comme observation, diagnostic ou point de revue. Si un projet décide de rendre cette recommandation obligatoire dans un scope local, il doit matérialiser ce contrat local explicitement ; la gate évalue alors ce contrat local, pas le `SHOULD` PGR d'origine.
+
 ## Matrice de validation
 
 Un projet suffisamment structuré SHOULD posséder une matrice de validation canonique, par défaut sous :

docs/rules/500-LANGUAGES.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/500-LANGUAGES.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Règles de profils langage et écosystème
 
@@ -31,7 +31,7 @@ Les profils de cette famille héritent des règles générales PGR et ne doivent
 
 Une règle générale comme l'interdiction de versionner des secrets reste applicable sans être répétée dans chaque profil langage.
 
-Lorsqu'un langage ou un build tool impose une exception réelle à une règle générale, le profil spécifique doit déclarer l'override et sa justification.
+Lorsqu'un langage ou un build tool impose une contradiction réelle avec un `MUST / MUST NOT` général applicable, le profil spécifique MUST déclarer l'override ou l'exception et sa justification. Un choix différent d'un `SHOULD / SHOULD NOT` général ne nécessite pas, à lui seul, un override.
 
 ## Langage et build tool
 

docs/rules/530-TYPESCRIPT.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/530-TYPESCRIPT.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Profil TypeScript
 
@@ -15,7 +15,7 @@ Le profil s'applique lorsqu'une partie du source contrôlé est écrite en TypeS
 
 Pour un frontend que l'organisation contrôle, TypeScript **SHOULD** être préféré à du JavaScript non typé dès que le frontend porte une logique durable non triviale.
 
-Cette préférence n'est pas une obligation universelle. Du JavaScript direct MAY rester approprié pour un artefact très petit, un script isolé, une contrainte externe ou un environnement où l'introduction de TypeScript n'apporte pas une valeur proportionnée.
+Cette préférence n'est pas une obligation universelle. Du JavaScript direct MAY rester approprié pour un artefact très petit, un script isolé, une contrainte externe ou un environnement où l'introduction de TypeScript n'apporte pas une valeur proportionnée. Choisir JavaScript ne constitue donc pas à lui seul une non-conformité, n'exige pas automatiquement un `OVERRIDE` et ne crée pas une obligation de justification ; la décision MAY être documentée lorsqu'elle apporte une valeur durable.
 
 La justification de la recommandation est fonctionnelle : TypeScript ajoute une vérification statique avant exécution et permet de détecter une partie des incohérences de types pendant la validation plutôt qu'au runtime.
 
@@ -61,7 +61,7 @@ noEmit = true
 
 `strict` exprime la volonté d'utiliser le contrôle de types renforcé de TypeScript. `noEmit` sépare le type-check de la production des artefacts JavaScript lorsque cette production appartient à un bundler ou à un autre outil.
 
-Pour une baseline stricte, PGR `SHOULD` également activer les contrôles simples suivants sauf incompatibilité documentée :
+Pour une baseline stricte, PGR `SHOULD` également activer les contrôles simples suivants lorsqu'ils sont pertinents pour le package :
 
 ```text
 noUnusedLocals = true

docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md -->
-<!-- version: 3 -->
+<!-- version: 4 -->
 
 # Profil écosystème de packages JavaScript
 
@@ -67,7 +67,7 @@ Un package **SHOULD NOT** conserver simultanément plusieurs lockfiles concurren
 
 Lorsqu'un lockfile est versionné, la CI **SHOULD** utiliser le mode de résolution gelé, immutable ou clean-install fourni par le package manager sélectionné. Le nom exact de cette commande reste local à l'outil ; PGR MUST NOT transformer `npm ci` en commande universelle.
 
-L'absence actuelle de lockfiles dans Games reste historique. Lors de l'adoption `0.1.5`, chaque package concerné devra soit `ADOPT` cette recommandation, soit documenter un `OVERRIDE` si une autre politique reste préférable.
+L'absence actuelle de lockfiles dans Games reste historique. Lors de l'adoption `0.1.6`, chaque package concerné devra décider sa politique de lockfile selon son rôle et ses contraintes. Versionner le lockfile reste une recommandation `SHOULD` pour les applications privées, frontends déployables et outils livrés ; conserver une autre politique ne requiert pas à lui seul un `OVERRIDE`, même si la décision locale MAY être documentée lorsqu'elle apporte une valeur durable.
 
 ## Validation
 

docs/rules/700-FRAMEWORKS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/700-FRAMEWORKS.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Règles de profils framework
 
@@ -45,7 +45,7 @@ GENERAL
 + Tauri
 ```
 
-Lorsque PGR gouverne la baseline du projet, les règles des profils hérités restent applicables dans leur scope complet tant qu'un override plus spécifique n'est pas documenté. Un framework ne constitue pas à lui seul une justification pour affaiblir une convention de langage, de plateforme ou de sécurité.
+Lorsque PGR gouverne la baseline du projet, les règles des profils hérités restent applicables dans leur scope avec leur force normative propre. Un framework MUST NOT contredire silencieusement un `MUST / MUST NOT` hérité ; une telle contradiction exige l'override ou l'exception applicable. Un framework MAY choisir différemment d'un `SHOULD / SHOULD NOT` sans que cet écart constitue à lui seul un override ou une non-conformité.
 
 Un projet existant ou imposé de l'extérieur MAY conserver des contraintes différentes. Ces écarts appartiennent alors au niveau project-specific ou à une exception explicite et bornée ; ils ne doivent pas être remontés comme nouvelle règle générale du framework.
 

docs/skeletons/003-WEB_FRONTEND.md

@@ -1,5 +1,5 @@
 <!-- file: docs/skeletons/003-WEB_FRONTEND.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Skeleton — Web frontend
 
@@ -65,7 +65,7 @@ Le nom `frontend/` est une convention possible, pas un chemin imposé par ce ske
 Résoudre explicitement au minimum :
 
 1. la racine et le scope exacts du frontend ;
-2. TypeScript ou JavaScript, avec justification si une nouvelle baseline durable n'adopte pas la recommandation TypeScript ;
+2. TypeScript ou JavaScript ; pour une nouvelle baseline durable, considérer explicitement la recommandation TypeScript sans transformer un choix JavaScript en obligation de justification ou en `OVERRIDE` ;
 3. le package manager réel et la politique de lockfile adaptée au rôle du package ;
 4. les versions réelles de TypeScript et des dépendances, ainsi que les déclarations `@types/*` réellement nécessaires ;
 5. Vite ou un build tool alternatif, avec ses chemins `root`, cache, outputs, `base`, ports, plugins et assets lorsqu'ils s'appliquent ;

docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md

@@ -1,5 +1,5 @@
 <!-- file: docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Templates de package Web TypeScript
 
@@ -135,7 +135,7 @@ Ces lignes sont des exemples, pas une sélection de package manager par PGR.
 
 Pour une application privée/deployable issue de ce template, le lockfile du package manager sélectionné SHOULD normalement être versionné.
 
-Si le projet conserve volontairement une autre politique, l'écart doit être traité comme décision locale ou `OVERRIDE` lors d'une adoption PGR, avec justification proportionnée.
+Si le projet conserve volontairement une autre politique, l'écart reste une décision locale. Ne pas suivre ce `SHOULD` n'exige pas à lui seul un `OVERRIDE` ni une justification ; documenter la raison reste utile lorsqu'elle apporte une valeur durable de maintenance, reproductibilité ou reprise.
 
 PGR MUST NOT conserver plusieurs lockfiles concurrents uniquement pour rendre le template compatible avec plusieurs package managers.
 

history/0.1.5/alpha.2.md

@@ -0,0 +1,120 @@
+<!-- file: history/0.1.5/alpha.2.md -->
+<!-- version: 1 -->
+
+# History 0.1.5-alpha.2 — sémantique normative stabilisée
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.5-alpha.2` exécutée le `2026-10-01` est propre. La tranche stabilise `MUST / SHOULD / MAY`, aligne adoption et validation sur cette force normative et corrige les renforcements accidentels ciblés sans convertir mécaniquement les recommandations existantes.
+
+## Baseline opérateur
+
+Le correctif `0.1.5-alpha.1.fix.1` et son history `PASS` ont été committés puis publiés avant application de `alpha.2` :
+
+```text
+commit alpha.1.fix.1   32433ca
+push                   90ca422..32433ca  master -> master
+```
+
+La version observée pendant la gate est :
+
+```text
+0.1.5-alpha.2
+```
+
+`history/0.1.5/alpha.1.md` conserve `PARTIAL` et `history/0.1.5/alpha.1.fix.1.md` conserve `PASS`. Le history `alpha.2` était absent pendant la gate.
+
+## Sémantique normative acquise
+
+Les assertions opérateur ont confirmé dans `RULES.md` révision `15` :
+
+- `SHOULD / SHOULD NOT` est une forte recommandation non obligatoire ;
+- un simple écart ne fait pas échouer à lui seul une gate ;
+- un simple écart n'exige pas automatiquement un `OVERRIDE`.
+
+`docs/rules/230-ADOPTION.md` révision `2` confirme qu'un choix différent d'un `SHOULD / SHOULD NOT` ne crée pas à lui seul un `OVERRIDE` obligatoire et qu'un override ne peut pas être exigé uniquement parce qu'une recommandation n'est pas suivie.
+
+`docs/rules/400-VALIDATION.md` révision `2` confirme qu'un écart à un `SHOULD / SHOULD NOT` PGR ne peut pas, par sa seule force, faire passer une tranche en `FAIL`. Si un projet rend localement ce choix obligatoire, la gate évalue le contrat local explicite et non la recommandation PGR d'origine.
+
+## Réconciliation ciblée
+
+Les assertions ont confirmé la réconciliation prévue de :
+
+- `500-LANGUAGES.md` révision `2` ;
+- `530-TYPESCRIPT.md` révision `4` ;
+- `540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` révision `4` ;
+- `700-FRAMEWORKS.md` révision `3` ;
+- `003-WEB_FRONTEND.md` révision `2` ;
+- `008-WEB_TYPESCRIPT_PACKAGE.md` révision `3`.
+
+La référence vivante de l'adoption Games est désormais `0.1.6` et l'ancienne référence `0.1.5` est absente du contrat courant `540`. Les choix JavaScript ou de lockfile différents d'une recommandation ne sont plus transformés en justification ou override obligatoire.
+
+Le plan `011` révision `2` confirme qu'un écart à une recommandation ne crée ni non-conformité, ni `FAIL` de gate, ni `OVERRIDE` automatique.
+
+## Frontières et historique
+
+La ROADMAP conserve :
+
+```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   non réservé
+```
+
+Le contrôle d'appariement a affiché :
+
+```text
+0.1.5 alpha.2 history boundary: clean (105 closed prior pairs, current alpha.2 pending)
+```
+
+`git diff --exit-code -- history/0.1.4` n'a produit aucun écart : les histories de la stable précédente restent inchangés.
+
+## Tests et audits
+
+La suite Python complète est propre :
+
+```text
+Ran 55 tests in 0.855s
+OK
+```
+
+Les audits documentaires sont également propres :
+
+```text
+Text hygiene audit: clean (315 file(s))
+Markdown header audit: clean (288 file(s))
+Markdown table audit: clean (11 table(s), 288 file(s))
+Markdown link audit: clean (370 local link(s), 288 file(s))
+```
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+## Scope Git observé
+
+Avant indexation, le dépôt contenait uniquement les modifications prévues par le delta `alpha.2`. Après indexation explicite, le scope observé est exactement :
+
+```text
+M  README.md
+M  RULES.md
+M  VERSION
+A  deltas/0.1.5/alpha.2.md
+M  docs/000-README.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+M  docs/rules/230-ADOPTION.md
+M  docs/rules/400-VALIDATION.md
+M  docs/rules/500-LANGUAGES.md
+M  docs/rules/530-TYPESCRIPT.md
+M  docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md
+M  docs/rules/700-FRAMEWORKS.md
+M  docs/skeletons/003-WEB_FRONTEND.md
+M  docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md
+```
+
+## Décision
+
+`0.1.5-alpha.2` est validée `PASS`.
+
+La tranche suivante peut ouvrir `alpha.3`, strictement consacrée à l'autonomie de la baseline locale après instanciation/adoption et au réalignement PGR volontaire fondé sur un snapshot explicitement choisi. La frontière PGR / SaseDev Knowledge reste réservée à `alpha.4`.