0.1.5

CHANGELOG.md

@@ -1,5 +1,5 @@
 <!-- file: CHANGELOG.md -->
-<!-- version: 15 -->
+<!-- version: 22 -->
 
 # Changelog Project Governance Rules
 
@@ -7,6 +7,34 @@ Ce fichier décrit les changements utiles aux utilisateurs ou intégrateurs des
 
 Les tranches `alpha`, `beta`, `rc`, fixes, validations, audits et détails de développement appartiennent aux plans, deltas et historiques. Ils ne sont pas recopiés ici par défaut.
 
+## 0.1.5
+
+- clarifie la sémantique normative de PGR : `MUST / MUST NOT` restent obligatoires, `SHOULD / SHOULD NOT` expriment explicitement une forte recommandation non obligatoire et `MAY` reste une possibilité neutre ;
+- aligne l’adoption et la validation afin qu’un simple écart à un `SHOULD / SHOULD NOT` ne crée à lui seul ni non-conformité, ni `FAIL` de gate, ni `OVERRIDE` ou justification obligatoire ;
+- formalise l’autonomie après instanciation/adoption : la baseline locale et ses owners deviennent l’autorité des sessions/releases suivantes, tandis qu’un réalignement PGR futur reste une opération explicite et bornée fondée sur un snapshot choisi ;
+- fixe la frontière PGR / SaseDev Knowledge : PGR reste auto-suffisant pour ses contrats normatifs, tandis que howtos, recettes, snippets, exemples, dépannage et variantes pratiques peuvent vivre dans une base de connaissances séparée sans devenir une dépendance de PGR ;
+- réconcilie transversalement les owners concernés sans réécriture mécanique des recommandations existantes et corrige la référence vivante à l’adoption Games vers `0.1.6` ;
+- confirme par revue d’horizon que l’adoption réelle de `sasedev-games` reste la cible `0.1.6`, suivie de KSP `0.1.7` puis des audits Rust/Clippy `0.1.8`, sans réserver `0.1.9`.
+
+## 0.1.4
+
+- réexamine le `DEFER` historique du skeleton Tauri contre les corpus Games/KSP fournis, confirme les prérequis Web désormais couverts et lève le blocage sans généraliser les choix locaux de ces projets ;
+- recentre l’owner `710-TAURI` sur le host, l’orchestration, la configuration, les commandes, permissions et capabilities, les plugins et la frontière d’intégration, tandis que TypeScript, Vite, CSS/Sass, package manager et bindings restent possédés par leurs owners dédiés ;
+- matérialise `docs/skeletons/004-TAURI.md` comme specification organisationnelle composable avec la fondation, Rust/Cargo et Web, en laissant identifiants, capabilities, plugins, fenêtres, bundles et plateformes au projet destinataire ;
+- confirme qu’aucun template technique Tauri générique, contrat `006-TAURI_VALIDATION.md` ni dry-run de faux projet n’est justifié tant qu’aucune responsabilité réutilisable non couverte n’est démontrée ;
+- ajoute un audit réutilisable d’hygiène texte imposant LF, absence de whitespace terminal et exactement une newline finale, et durcit le contrat des archives delta/history pour interdire un répertoire englobant autour des chemins du dépôt ;
+- effectue une revue d’horizon de fermeture : la clarification de `SHOULD`, l’autonomie des projets après adoption et la frontière future avec SaseDev Knowledge deviennent la cible `0.1.5`, avant les adoptions Games `0.1.6`, KSP `0.1.7` et les audits Rust `0.1.8`.
+
+## 0.1.3
+
+- réévalue le profil Android contre le corpus Games réel tout en conservant Android neutre vis-à-vis du langage applicatif et en composant Java/Gradle uniquement lorsqu'ils sont réellement présents ;
+- clarifie les responsabilités `compileSdk` / `targetSdk` / `minSdk`, l'identité `namespace` / `applicationId`, la configuration locale, le signing et les manifests/resources sans promouvoir les valeurs particulières de Games ;
+- borne NDK, ABI et code natif aux projets réellement concernés, distingue compilation native, packaging et preuve runtime, et conserve les choix Rust/JNI/SDL de Games hors du profil Android générique ;
+- rend Android Lint explicite, sépare tests JVM, tests instrumentés et smokes device/AVD, et distingue APK/AAB des preuves d'installation ou d'exécution ;
+- normalise la compatibilité pages mémoire 16 KB uniquement comme contrainte conditionnelle au code natif, au package et au canal de distribution applicables, sans imposer une version AGP/NDK, un `targetSdk` ou une liste d'ABI universels ;
+- confirme que les owners existants `400 + 600 + 610`, complétés par `520` et `522` lorsqu'ils s'appliquent, suffisent sans créer de skeleton Android, template, audit Python, owner JNI/Rust/SDL ou contrat de validation redondant ;
+- prépare le réexamen Tauri distinct de `0.1.4` sans lever son `DEFER` par anticipation et conserve l'adoption Games comme cible séparée `0.1.5`.
+
 ## 0.1.2
 
 - sépare l'ancien profil combiné Java/Maven/Gradle en trois owners indépendants et composables : `520-JAVA`, `521-MAVEN` et `522-GRADLE`, afin qu'un build tool ne devienne pas implicitement applicable à tout projet Java ;

README.md

@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 22 -->
+<!-- version: 34 -->
 
 # Project Governance Rules
 
@@ -11,9 +11,9 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`.
 
 ## Statut
 
-PGR a clôturé sa phase de fondation `0.0.x`, dispose avec `0.1.0` de sa première baseline réutilisable stable, avec `0.1.1` d’une fondation frontend Web stable et avec `0.1.2` d’owners Java, Maven et Gradle séparés et composables après réévaluation du corpus Games. Le scope Android reste réservé à `0.1.3`.
+La stable autoritaire courante est `0.1.5`. Elle stabilise les trois contrats transversaux réconciliés : `SHOULD / SHOULD NOT` est une forte recommandation non obligatoire, la baseline locale d’un projet devient son autorité après instanciation/adoption avec réalignement PGR uniquement explicite, et PGR reste auto-suffisant face aux contenus pratiques externes possibles de SaseDev Knowledge. La revue d’horizon de clôture confirme qu’aucun nouveau prérequis transversal ne doit précéder l’adoption Games : `0.1.6` reste la prochaine release, suivie de KSP `0.1.7` puis des audits Rust/Clippy `0.1.8`, sans réservation de `0.1.9`.
 
-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 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. La release `0.1.5` stabilise la sémantique `MUST / SHOULD / MAY`, l’autorité de la baseline locale après adoption et le réalignement PGR volontaire, ainsi que la frontière PGR / SaseDev Knowledge ; elle conserve Games `0.1.6`, KSP `0.1.7` et les audits Rust/Clippy `0.1.8` comme scopes distincts.
 
 ## Entrées principales
 
@@ -32,6 +32,10 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
 - [`docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md`](docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md) — plan historique de la première baseline réutilisable `0.1.0` ;
 - [`docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md`](docs/plans/007-V0_1_1_WEB_FRONTEND_FOUNDATION_PLAN.md) — plan historique de la fondation frontend Web stable `0.1.1` ;
 - [`docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md`](docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md) — plan historique de la stable `0.1.2` : réévaluation Games, scission Java/Maven/Gradle et maintien d'Android hors scope ;
+- [`docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`](docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md) — plan historique de la stable Android `0.1.3`, fondée sur Games avec classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
+- [`docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md`](docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md) — plan historique de la stable Tauri `0.1.4`, du réexamen Games/KSP au skeleton `004`, à la décision d’artefacts et à la revue d’horizon ;
+- [`docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan historique de la stable `0.1.5` : sémantique normative, autonomie locale, frontière PGR / Knowledge, réconciliation transversale et handoff vers l’adoption Games `0.1.6` ;
+- [`docs/skeletons/004-TAURI.md`](docs/skeletons/004-TAURI.md) — specialization Tauri 2 composable, sans template technique universel ni defaults de capabilities/plugins/fenêtres/bundles ;
 - [`docs/studies/001-KSP_GAMES_RECONCILIATION.md`](docs/studies/001-KSP_GAMES_RECONCILIATION.md) — étude de réconciliation et classification des écarts entre PGR, KSP et Games ;
 - [`docs/skeletons/000-README.md`](docs/skeletons/000-README.md) — index des skeleton specifications et de leur contrat de composition ;
 - [`docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation composable de gouvernance locale pour un projet adoptant PGR ;

ROADMAP.md

@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 14 -->
+<!-- version: 19 -->
 
 # Roadmap Project Governance Rules
 
@@ -25,22 +25,22 @@ La revue d'horizon de `0.1.0-beta.1` engage les releases suivantes, chacune avec
 
 - `(x) 0.1.1` — fondation frontend Web : TypeScript, Vite, Sass/CSS, package/build outputs et validation frontend indépendante ;
 - `(x) 0.1.2` — réévaluation pratique de Java/Maven/Gradle, séparation des owners lorsque leurs applicabilités divergent et matérialisation uniquement des artefacts génériques réellement nécessaires ;
-- `( ) 0.1.3` — réévaluation pratique du profil Android existant à partir de Games, sans absorber les décisions propres aux jeux ou à SDL ;
-- `( ) 0.1.4` — domaine Tauri : réexamen du `DEFER` et matérialisation du skeleton contrôlé seulement si les owners Web issus de `0.1.1` satisfont réellement les conditions de sortie ;
-- `( ) 0.1.5` — adoption réelle de PGR par `sasedev-games` avec mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
-- `( ) 0.1.6` — adoption réelle de PGR par `khadhroony-solana-project`, principalement sur Rust/Cargo + Tauri et sans dépendance aux profils non applicables ;
-- `( ) 0.1.7` — audits Python read-only d'un sous-ensemble statique des conventions Rust/Clippy, après les deux adoptions, sans prétendre remplacer `cargo clippy`.
+- `(x) 0.1.3` — réévaluation pratique du profil Android existant à partir de Games, sans absorber les décisions propres aux jeux ou à SDL ;
+- `(x) 0.1.4` — domaine Tauri : réexamen du `DEFER`, consolidation de l’owner `710`, matérialisation du skeleton contrôlé `004` et décision explicite de ne pas créer d’artefacts techniques redondants ;
+- `(x) 0.1.5` — sémantique normative et autonomie : clarifier `MUST / SHOULD / MAY`, rendre explicite l’autorité locale d’un projet après instanciation/adoption et fixer la frontière durable entre PGR et SaseDev Knowledge ;
+- `( ) 0.1.6` — adoption réelle de PGR par `sasedev-games` avec mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, après stabilisation du contrat d’autonomie ;
+- `( ) 0.1.7` — adoption réelle de PGR par `khadhroony-solana-project`, principalement sur Rust/Cargo + Tauri et sans dépendance aux profils non applicables ;
+- `( ) 0.1.8` — audits Python read-only d’un sous-ensemble statique des conventions Rust/Clippy, après les deux adoptions, sans prétendre remplacer `cargo clippy`.
 
 Le détail et les conditions de cette séquence sont conservés dans [`docs/studies/003-V0_1_0_HORIZON_REVIEW.md`](docs/studies/003-V0_1_0_HORIZON_REVIEW.md).
 
 ## Trajectoires différées ou non numérotées
 
-- `(d) skeleton Tauri jusqu'au réexamen 0.1.4` — le `DEFER` de `0.0.5-alpha.9` a été maintenu pendant `0.1.1`; `0.1.1-beta.1` confirme que ses cinq prérequis Web disposent désormais d'owners PGR, mais seul `0.1.4` peut réexaminer le candidat à partir du corpus alors courant ;
 - `WASM` — candidat séparé à réévaluer pendant l'adoption Games si un owner PGR apporte une valeur immédiate ;
 - `serveur Web Rust / Actix Web ou alternative` — candidat à partir d'un corpus d'implémentation réel, pas sur la seule base d'une trajectoire roadmap ;
 - `saselang-bible`, projets documentaires/spécifications et généricité hors logiciel — candidats d'une trajectoire ultérieure `0.2.x` / `0.3.x` à décider ;
 - `deployment & operations` — famille future pour reverse proxies, bases de données, Docker/Compose, services Linux, secrets, migrations/backups, health et observabilité ; un horizon `0.4.x` ou `0.5.x` est plausible mais aucun numéro précis n'est réservé.
 
-Une nouvelle revue d'horizon doit intervenir si un prérequis réel invalide l'ordre engagé, notamment si `0.1.1` doit être scindée, si `0.1.4` ne peut pas lever le `DEFER` Tauri ou si Games exige un owner WASM/serveur avant une adoption proportionnée.
+La revue d’horizon `0.1.4-rc.1` remplace l’ordre initial `0.1.5` Games / `0.1.6` KSP / `0.1.7` audits par le contrat ci-dessus. La revue limitée `0.1.5-rc.1` confirme que les contrats transversaux sont suffisamment stabilisés et qu’aucun nouveau prérequis ne doit précéder l’adoption Games : l’ordre `0.1.6` Games, `0.1.7` KSP, `0.1.8` audits est conservé et aucun `0.1.9` n’est réservé.
 
 Le contenu détaillé et le nombre de tranches de chaque release sont définis par son plan actif, créé ou consolidé pendant `alpha.1`.

RULES.md

@@ -1,5 +1,5 @@
 <!-- file: RULES.md -->
-<!-- version: 14 -->
+<!-- version: 16 -->
 
 # 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é ;
-- `SHOULD` / `SHOULD NOT` : comportement attendu par défaut, avec dérogation possible lorsqu'une solution différente est mieux adaptée et justifiée ;
-- `MAY` : possibilité reconnue, sans obligation implicite.
+- `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` : 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é 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,12 +45,13 @@ 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
 
-- Les projets instanciés depuis PGR MUST rester autonomes et posséder leurs propres copies des règles et configurations applicables.
-- PGR MUST NOT devenir une dépendance runtime ou build des projets qu'il aide à initialiser.
+- Les projets instanciés depuis PGR MUST rester autonomes et posséder leurs propres copies des règles et configurations applicables. Après établissement de la baseline locale, cette baseline et ses owners locaux deviennent l'autorité des sessions et releases suivantes.
+- PGR MUST NOT devenir une dépendance runtime, build ou documentaire implicite des projets qu'il aide à initialiser ou adopter. Un projet gouverné localement MUST NOT rechercher automatiquement « la dernière version de PGR » ni traiter PGR comme un upstream à suivre.
+- Un réalignement futur avec PGR MAY être engagé comme opération explicite et bornée : le projet choisit un snapshot PGR précis, compare ce snapshot à sa baseline locale, décide les écarts applicables et conserve ses historiques. Le réalignement ne constitue jamais une mise à jour automatique de la gouvernance locale.
 - Les skeletons PGR sont des spécifications Markdown et MUST NOT devenir un générateur qui fige l'architecture d'un projet.
 - Les audits `audit_*.py` MUST être read-only, déterministes autant que raisonnablement possible et sans effets de bord sur le dépôt inspecté.
 - Une propriété déjà correctement contrôlée par le compilateur, le linter ou le build system SHOULD NOT être dupliquée par un test ou audit maison sans besoin réel.

VERSION

@@ -1 +1 @@
-0.1.2
+0.1.5

deltas/0.1.3/alpha.1.md

@@ -0,0 +1,247 @@
+<!-- file: deltas/0.1.3/alpha.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.3-alpha.1 — audit de stable et cadrage Android
+
+## Baseline et sources
+
+Baseline PGR autoritaire : archive source téléchargée depuis le tag Gitea `v0.1.2`, accompagnée du rapport externe `pgr-0.1.2-publish.001-report.md` avec statut `PASS`.
+
+SHA-256 vérifiés sur les fichiers réellement fournis :
+
+```text
+pgr-v0.1.2(1).zip                  0ef8facab0c6f92ca427f5f13d38d6c4a4c1cc16174a20ecdab48991bd88d0e6
+pgr-0.1.2-publish.001-report.md    0f6b4e2a685a957fa647a7db009320ada0fc67948737d8344cc3773bcaeb6a9c
+games-v0.3.6(2).zip                ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
+```
+
+Les archives locales PGR et Games comportent respectivement `(1)` et `(2)` dans leur nom, mais leurs empreintes correspondent exactement aux baselines canoniques `pgr-v0.1.2.zip` et `games-v0.3.6.zip` attendues par le rapport/prompt.
+
+Version avant application :
+
+```text
+0.1.2
+```
+
+Version après application :
+
+```text
+0.1.3-alpha.1
+```
+
+## Objet
+
+Exécuter `prompts/009-V0_1_3_START_PROMPT.md` : vérifier intégralement la stable `v0.1.2` et son rapport post-tag, auditer le corpus Games autoritaire sur Android et ses preuves historiques, relire `610-ANDROID.md`, `520-JAVA.md`, `522-GRADLE.md`, `600-PLATFORMS.md`, la validation générale et la revue d'horizon, puis créer le plan `0.1.3` avant toute normalisation Android importante.
+
+`alpha.1` reste un gate de cadrage. Aucune règle Android, règle Java/Gradle, validation spécialisée, template, skeleton ou audit nouveau n'est encore créé ou modifié.
+
+## Résultat de l'audit d'intake
+
+La stable PGR et son rapport post-tag concordent : SHA-256 attendu, CRC propre, racine unique `pgr/`, `316` entrées, `276` fichiers, `40` répertoires, aucun symlink, absence normale de `.git` et `VERSION=0.1.2`.
+
+Le rapport `publish.001` est `PASS` et confirme le commit stable `585b508578aae337f6940110d4ca47c694a052d5`, l'objet tag annoté `cea2c7a06cde844ffa7411f73bb22685a3214414` et la déréférence de `v0.1.2` vers le commit stable.
+
+La suite PGR donne `48/48` tests `PASS`. Les audits Markdown sont propres : `250` fichiers pour les headers, `10` tables sur `250` fichiers et `307` liens locaux sur `250` fichiers. Les templates TOML Rust/Cargo et JSON Web contrôlés sont parsables.
+
+Les `90` couples delta/history de `0.0.1` à `0.1.2` sont complets. Les sept histories `0.1.2` sont tous `PASS`, y compris `alpha.2.fix.1` qui conserve la récupération historique de contamination inter-projet.
+
+Le corpus Games fourni possède exactement le SHA canonique attendu, `652` entrées, `502` fichiers, `150` répertoires et aucun symlink. Ses audits statiques principaux sont propres : règles Rust, exports, workspace, tableaux Markdown et layout de distribution.
+
+Le sous-projet Android natif exerce un build Gradle multi-module sous `Android/` avec `common`, `game-reflex-poc` et `game-snake-poc`, quatre sources Java, manifests/resources, namespaces/application IDs, configuration locale ignorée et scripts Gradle communs.
+
+La baseline Games utilise AGP `9.4.0`, Gradle système `>= 9.6.0`, JDK de build compatible `>= 17`, niveau Java source/target `17`, `compileSdk 36`, `targetSdk 36`, `minSdk 21`, NDK `28.2.13676358` et SDL3 `3.4.16`. Ces valeurs restent des décisions et preuves Games, pas des minima PGR.
+
+Les histories Games démontrent le passage d'une preuve initiale Wrapper/JDK 17 vers un Gradle système avec minimum exécutable et JDK courant, puis des builds réels avec Temurin `25.0.4.1 LTS` + Gradle `9.7.1` tout en conservant Java `17` comme niveau source/target.
+
+Le pipeline natif Games exerce `cargo ndk`, JNI, SDL3 et quatre ABI (`arm64-v8a`, `armeabi-v7a`, `x86_64`, `x86`). Les histories prouvent APK Debug, AAB Release, contenu natif packagé, smokes AVD x86_64 et appareil ARM64 réel, runtime API 21 ainsi qu'une preuve `PAGE_SIZE=16384` sur Android 15/API 35 x86_64.
+
+Ces responsabilités spécialisées ne sont pas copiées dans PGR. Le plan classe les décisions avec `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, conserve Tauri en `DEFER` jusqu'à `0.1.4`, l'adoption Games jusqu'à `0.1.5` et prévoit une vérification des exigences Android officielles courantes avant toute normalisation de contraintes évolutives telles que 16 KB.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+README.md
+docs/000-README.md
+```
+
+ADD :
+
+```text
+docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+deltas/0.1.3/alpha.1.md
+```
+
+DELETE : aucun.
+
+`RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, `docs/rules/610-ANDROID.md`, `docs/rules/520-JAVA.md`, `docs/rules/522-GRADLE.md`, `docs/rules/600-PLATFORMS.md`, les autres règles, templates, skeletons, validations, scripts, studies, prompts et histories existants restent inchangés dans `alpha.1`.
+
+Aucun `history/0.1.3/alpha.1.md` n'est anticipé avant la gate opérateur.
+
+## Validation opérateur
+
+Après application sur la stable `0.1.2`, depuis la racine du dépôt :
+
+```bash
+test "$(cat VERSION)" = '0.1.3-alpha.1'
+test -f docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+test -f deltas/0.1.3/alpha.1.md
+test ! -e history/0.1.3/alpha.1.md
+
+grep -Fx '<!-- version: 23 -->' README.md
+grep -Fx '<!-- version: 37 -->' docs/000-README.md
+grep -F '009-V0_1_3_ANDROID_REEVALUATION_PLAN.md' README.md docs/000-README.md
+
+python3 -B -m unittest discover -s tests -v
+
+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
+
+python3 -B - <<'PY'
+from pathlib import Path
+import re
+
+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,
+}
+for release, count in expected.items():
+    deltas = {path.name for path in Path('deltas', release).glob('*.md')}
+    histories = {path.name for path in Path('history', release).glob('*.md')}
+    assert len(deltas) == count, (release, len(deltas))
+    assert deltas == histories, (release, sorted(deltas ^ histories))
+
+statuses = {}
+for path in Path('history/0.1.2').glob('*.md'):
+    text = path.read_text(encoding='utf-8')
+    match = re.search(r'## Statut\s+(?:`?)(PASS|FAIL|PARTIAL|BLOCKED)', text)
+    assert match is not None, path
+    statuses[path.name] = match.group(1)
+assert len(statuses) == 7, statuses
+assert set(statuses.values()) == {'PASS'}, statuses
+assert statuses['alpha.2.fix.1.md'] == 'PASS'
+assert statuses['rel.1.md'] == 'PASS'
+
+roadmap = Path('ROADMAP.md').read_text(encoding='utf-8')
+assert '- `(x) 0.1.2`' in roadmap
+for release in range(3, 8):
+    assert f'- `( ) 0.1.{release}`' in roadmap, release
+assert '0.1.8' not in roadmap
+assert 'skeleton Tauri jusqu\'au réexamen 0.1.4' in roadmap
+
+prompt = Path('prompts/009-V0_1_3_START_PROMPT.md').read_text(encoding='utf-8')
+for phrase in (
+    'Version cible : `0.1.3`',
+    'Première tranche attendue : `0.1.3-alpha.1`',
+    'ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8',
+    'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER',
+    'structure `Android/`',
+    'compileSdk`, `targetSdk` et `minSdk',
+    'alignement mémoire/16 KB',
+    'skeleton Tauri, réservé à `0.1.4`',
+    "démarrer l'adoption Games `0.1.5`",
+):
+    assert phrase in prompt, phrase
+
+android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
+assert android.startswith('<!-- file: docs/rules/610-ANDROID.md -->\n<!-- version: 3 -->')
+for phrase in (
+    'Android n\'implique pas à lui seul l\'applicabilité du profil Java.',
+    'Matrice AGP / Gradle / JDK',
+    '`compileSdk`, `targetSdk` et `minSdk`',
+    'ABI et code natif',
+    'Niveaux de tests Android',
+    'APK, AAB et artefacts de distribution',
+):
+    assert phrase in android, phrase
+
+assert Path('docs/rules/520-JAVA.md').read_text(encoding='utf-8').startswith(
+    '<!-- file: docs/rules/520-JAVA.md -->\n<!-- version: 4 -->'
+)
+assert Path('docs/rules/522-GRADLE.md').read_text(encoding='utf-8').startswith(
+    '<!-- file: docs/rules/522-GRADLE.md -->\n<!-- version: 1 -->'
+)
+assert Path('docs/rules/600-PLATFORMS.md').read_text(encoding='utf-8').startswith(
+    '<!-- file: docs/rules/600-PLATFORMS.md -->\n<!-- version: 1 -->'
+)
+
+plan = Path('docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
+for phrase in (
+    'Classification initiale des décisions Games',
+    '`ADOPT`',
+    '`KEEP-LOCAL`',
+    '`OVERRIDE`',
+    '`DEFER`',
+    'alpha.2 — structure, composition et contrats Android de base',
+    'alpha.3 — natif, packaging, distribution et validation',
+    'beta.1 — réconciliation et décision d\'artefacts',
+    'AGP `9.4.0`',
+    'Gradle système `>= 9.6.0`',
+    'NDK `r28c`',
+    'PAGE_SIZE=16384',
+    'documentation Android officielle courante',
+    '0.1.4 — domaine Tauri',
+    '0.1.5',
+):
+    assert phrase in plan, phrase
+
+assert not Path('docs/validation/006-ANDROID_VALIDATION.md').exists()
+assert not Path('history/0.1.3/alpha.1.md').exists()
+
+print('0.1.3 alpha.1 structural audit: clean (90 prior pairs, Games Android classified, Tauri/adoption boundaries preserved)')
+PY
+
+git diff --check
+git add VERSION README.md docs/000-README.md \
+    docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
+    deltas/0.1.3/alpha.1.md
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history est :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.3/alpha.1.md
+M  docs/000-README.md
+A  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+```
+
+La revue opérateur doit également confirmer que :
+
+- `alpha.1` n'a pas modifié `610-ANDROID.md` avant validation du cadrage ;
+- les versions exactes Games (AGP/Gradle/JDK/SDK/NDK/SDL3) restent des preuves ou choix locaux, pas des contraintes PGR universelles ;
+- `Android/` reste une convention de séparation multi-plateforme et n'est pas imposé artificiellement à un dépôt Android-only ;
+- Java reste un owner composé seulement lorsqu'il existe réellement du code Java ;
+- les quatre ABI, JNI, `cargo ndk`, SDL3, Activities et assets Games restent des responsabilités produit/framework/spécialisation ;
+- aucune exigence 16 KB n'est normalisée sans vérification des sources Android officielles courantes ;
+- aucun nouveau template, audit, skeleton ou contrat de validation Android n'est créé par symétrie ;
+- Games reste un corpus externe non modifié et son adoption reste réservée à `0.1.5` ;
+- le skeleton Tauri reste `DEFER` jusqu'à `0.1.4` ;
+- aucun nouveau numéro au-delà de `0.1.7` n'est réservé.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.3/alpha.1.md` à partir des résultats réellement observés. Dans la même réponse, si aucune décision nouvelle n'est ouverte, préparer séparément le delta `0.1.3-alpha.2` consacré à la structure, la composition et aux contrats Android de base définis par le plan, sans absorber encore les détails natifs/packaging de `alpha.3`.
+
+Après remise du history, fournir automatiquement le bloc opérateur exact pour appliquer le history, committer/pusher `0.1.3-alpha.1`, puis seulement appliquer le delta suivant conformément à `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`.
+
+### FAIL
+
+Consigner le résultat réel dans le history, puis ouvrir `0.1.3-alpha.1.fix.1` ou un REPLAN selon la cause. Aucun changement prévu pour `alpha.2` ne doit être absorbé silencieusement dans le fix.

deltas/0.1.3/alpha.2.md

@@ -0,0 +1,198 @@
+<!-- file: deltas/0.1.3/alpha.2.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.3-alpha.2 — contrats Android de base
+
+## Baseline
+
+Ce delta s'applique après :
+
+```text
+0.1.3-alpha.1
++ history/0.1.3/alpha.1.md PASS
++ commit/push complet de la tranche alpha.1
+```
+
+Il ne doit pas être appliqué avant l'intégration du history `alpha.1`.
+
+## Objet
+
+Réviser le profil Android uniquement sur les contrats de base démontrés par le corpus Games et confirmés par la documentation Android officielle courante : structure Android-only versus multi-plateforme, composition langage/build, matrice AGP/Gradle/JDK, niveaux SDK, identité applicative, versioning, configuration locale et signing.
+
+Cette tranche ne couvre pas encore NDK/ABI/native packaging, APK/AAB, Android Lint, tests instrumentés, installation/smokes device/AVD ni exigences 16 KB ; ces responsabilités restent réservées à `alpha.3`.
+
+## Modifications
+
+### Version
+
+`VERSION` devient :
+
+```text
+0.1.3-alpha.2
+```
+
+### Plan Android
+
+`docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md` passe en révision interne `2` et enregistre :
+
+- le `PASS` opérateur réel de `alpha.1` ;
+- l'absence de fix avant `alpha.2` ;
+- les sources Android officielles vérifiées le `2026-09-28` ;
+- la confirmation que les valeurs Games AGP `9.4.0`, Gradle `>= 9.6.0` et JDK observé restent des preuves locales et non des minima PGR ;
+- le scope exact de `alpha.2` ;
+- le maintien du détail 16 KB dans `alpha.3`.
+
+### Profil Android
+
+`docs/rules/610-ANDROID.md` passe en révision interne `4`.
+
+La révision :
+
+- conserve `Android/` comme convention conditionnelle d'un dépôt multi-plateforme, mais retire `gradlew*` du layout d'exemple afin de ne plus présenter le Wrapper comme structure obligatoire ;
+- rend le profil Android neutre quant au langage applicatif et applique `520-JAVA.md` uniquement lorsque du Java est réellement présent ;
+- distingue le JDK qui exécute Gradle/AGP du niveau Java du code applicatif ;
+- conserve la matrice AGP/Gradle/JDK sans recopier les règles générales possédées par `522-GRADLE.md` ;
+- clarifie `compileSdk`, `targetSdk` et `minSdk` comme trois contrats distincts ;
+- remplace l'objectif implicite « `minSdk` aussi bas que possible » par une décision de compatibilité produit explicitement justifiée ;
+- introduit la séparation explicite entre `namespace` et `applicationId` ;
+- conserve `VERSION`, `versionName` et `versionCode` comme contrats distincts selon le release train réellement possédé ;
+- précise que `local.properties` est réservé à l'environnement local Android/AGP et ne doit pas devenir une source de configuration partagée ou un fourre-tout de propriétés produit ;
+- consolide le traitement des keystores, clés et mots de passe de signing sans recopier l'interdiction générale des secrets ;
+- clarifie que le manifest possède composants/permissions/capabilities tandis que les identités `namespace` / `applicationId` restent dans la configuration Android du module.
+
+Aucun template, skeleton, audit Python ou contrat de validation Android n'est créé.
+
+## Vérification officielle utilisée
+
+La vérification courante effectuée avant préparation du delta couvre :
+
+```text
+Android Gradle plugin 9.4.0 release notes
+Configure your build
+Java versions in Android builds
+Configure the app module
+Sign your app
+```
+
+Elle confirme notamment la matrice AGP/Gradle/JDK, la distinction du JDK de build et du niveau Java, les responsabilités `compileSdk` / `targetSdk` / `minSdk`, la séparation `namespace` / `applicationId`, le rôle local de `local.properties` et le caractère secret des clés de signing.
+
+Elle n'est pas utilisée pour normaliser encore la contrainte 16 KB.
+
+## Validation opérateur
+
+Après application du history `PASS`, commit/push de `alpha.1`, puis application du présent delta :
+
+```bash
+test "$(cat VERSION)" = '0.1.3-alpha.2'
+git cat-file -e HEAD:history/0.1.3/alpha.1.md
+test -f history/0.1.3/alpha.1.md
+test -f deltas/0.1.3/alpha.2.md
+test ! -e history/0.1.3/alpha.2.md
+
+grep -A2 '^## Statut$' history/0.1.3/alpha.1.md | grep -Fx 'PASS'
+grep -Fx '<!-- version: 2 -->' docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+grep -Fx '<!-- version: 4 -->' docs/rules/610-ANDROID.md
+
+python3 -B -m unittest discover -s tests -v
+
+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
+
+python3 -B - <<'PYGATE'
+from pathlib import Path
+import re
+
+history = Path('history/0.1.3/alpha.1.md').read_text(encoding='utf-8')
+assert re.search(r'## Statut\s+PASS\s', history)
+
+android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
+assert android.startswith('<!-- file: docs/rules/610-ANDROID.md -->\n<!-- version: 4 -->')
+
+for phrase in (
+    'Android ne sélectionne pas à lui seul le langage applicatif du projet.',
+    'JDK qui exécute Gradle / AGP',
+    'Le choix de `minSdk` MUST être justifié par le contrat produit',
+    '## Identité applicative et namespace',
+    '`applicationId` identifie l\'application installée et distribuée.',
+    '`local.properties` appartient à l\'environnement local du build Android/AGP',
+    'release / upload keystore',
+    '`AndroidManifest.xml` MUST déclarer uniquement les composants',
+):
+    assert phrase in android, phrase
+
+structure = android.split('## Structure du projet', 1)[1].split('## Langage applicatif et logique de build', 1)[0]
+assert 'gradlew' not in structure
+assert 'settings.gradle(.kts)' in structure
+assert '<module>/' in structure
+
+assert 'Java est le langage applicatif Android par défaut du profil PGR' not in android
+assert '`minSdk` SHOULD rester aussi bas que raisonnablement supportable' not in android
+
+plan = Path('docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
+for phrase in (
+    '## Décision après `alpha.1`',
+    'La gate opérateur de `alpha.1` est `PASS`',
+    '### Vérification Android officielle courante pour `alpha.2`',
+    'AGP `9.4.0` requiert actuellement au minimum Gradle `9.6.0` et JDK `17`',
+    'La vérification 16 KB n\'est pas absorbée ici',
+    '### Scope arrêté pour `alpha.2`',
+):
+    assert phrase in plan, phrase
+
+assert not Path('docs/validation/006-ANDROID_VALIDATION.md').exists()
+assert not Path('history/0.1.3/alpha.2.md').exists()
+
+for path in (
+    'docs/rules/520-JAVA.md',
+    'docs/rules/522-GRADLE.md',
+    'docs/rules/600-PLATFORMS.md',
+):
+    assert Path(path).is_file(), path
+
+print('0.1.3 alpha.2 Android base-contract audit: clean (language/build ownership, SDK contracts, app identity, local config and signing clarified)')
+PYGATE
+
+git diff --check
+git add VERSION \
+    docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
+    docs/rules/610-ANDROID.md \
+    deltas/0.1.3/alpha.2.md
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history est :
+
+```text
+M  VERSION
+A  deltas/0.1.3/alpha.2.md
+M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+M  docs/rules/610-ANDROID.md
+```
+
+La revue qualitative doit confirmer que :
+
+- aucun choix Games n'est devenu une règle Android générale par copie de valeur ;
+- Android n'impose plus Java par défaut et ne confond pas JDK de build avec niveau Java applicatif ;
+- l'exemple structurel ne rend ni Wrapper ni Gradle système obligatoire ;
+- `minSdk` est une décision de compatibilité produit et non un concours vers la valeur la plus basse ;
+- `namespace` et `applicationId` sont distingués sans imposer un schéma de nommage propriétaire ;
+- `local.properties` ne devient pas une configuration partagée et les secrets de signing restent hors Git ;
+- aucun contenu NDK/ABI/16 KB, Tauri ou adoption Games n'a été absorbé prématurément ;
+- aucun artefact supplémentaire n'a été créé uniquement pour remplir la release.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.3/alpha.2.md`, puis préparer `0.1.3-alpha.3` pour les responsabilités conditionnelles NDK/ABI/native packaging, APK/AAB, Android Lint, niveaux de tests, install/smokes device/AVD et contraintes de distribution modernes réellement applicables.
+
+Avant toute règle 16 KB, vérifier explicitement les exigences Android officielles courantes et borner le contrat au canal de distribution et aux artefacts natifs réellement concernés.
+
+### FAIL
+
+Consigner le diagnostic réel dans `history/0.1.3/alpha.2.md` et rester dans `alpha.2.fix.N` sauf REPLAN justifié. Le fix MUST rester borné aux contrats Android de base et ne doit pas absorber le scope natif/distribution de `alpha.3`, Tauri `0.1.4` ou l'adoption Games `0.1.5`.

deltas/0.1.3/alpha.3.md

@@ -0,0 +1,211 @@
+<!-- file: deltas/0.1.3/alpha.3.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.3-alpha.3 — natif, packaging, distribution et validation Android
+
+## Baseline
+
+Ce delta s'applique après :
+
+```text
+0.1.3-alpha.2
++ history/0.1.3/alpha.2.md PASS
++ commit/push complet de la tranche alpha.2
+```
+
+Il ne doit pas être appliqué avant l'intégration du history `alpha.2`.
+
+## Objet
+
+Réviser le profil Android uniquement sur les responsabilités conditionnelles démontrées par Games et confirmées par la documentation Android officielle courante : NDK/ABI/code natif, Android Lint, niveaux de tests, APK/AAB, installation/smokes device/AVD et compatibilité 16 KB lorsque le package ou le canal de distribution l'exigent réellement.
+
+Cette tranche ne crée aucun owner JNI/Rust/SDL, skeleton Android, audit Python ou contrat `docs/validation/` séparé. Elle ne modifie ni Tauri `0.1.4`, ni Games `0.1.5`.
+
+## Modifications
+
+### Version
+
+`VERSION` devient :
+
+```text
+0.1.3-alpha.3
+```
+
+### Plan Android
+
+`docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md` passe en révision interne `3` et enregistre :
+
+- le `PASS` opérateur réel de `alpha.2` ;
+- l'absence de fix avant `alpha.3` ;
+- les sources Android officielles vérifiées le `2026-09-28` pour native/ABI, Lint, tests, packaging, Google Play et 16 KB ;
+- le caractère évolutif des exigences de canal telles que `targetSdk` et les échéances de publication ;
+- la cohérence de la preuve Games 16 KB sans la transformer en gate PGR locale ;
+- le scope exact de `alpha.3` ;
+- le maintien de la décision finale d'artefacts supplémentaires dans `beta.1`.
+
+### Profil Android
+
+`docs/rules/610-ANDROID.md` passe en révision interne `5`.
+
+La révision :
+
+- rend NDK et ABI conditionnels à la présence de bibliothèques natives directes ou transitives ;
+- refuse toute version NDK ou liste d'ABI universelle et distingue compilation native, présence dans le package et preuve runtime ;
+- inclut les SDK/bibliothèques natives précompilés dans le contrat de compatibilité du package final ;
+- garde JNI, Rust, SDL, `cargo ndk` et les choix Games hors du profil Android général ;
+- introduit une section Android Lint qui impose une exécution explicite et ciblée lorsqu'elle est applicable, sans supposer qu'un build ordinaire l'exécute ;
+- précise les frontières JVM unit / instrumented / smoke device-AVD et la sélection proportionnée des matrices ;
+- distingue l'APK installable de l'AAB de distribution et interdit d'utiliser un AAB seul comme preuve runtime ;
+- impose de revalider les politiques évolutives du canal de distribution au moment de la release concernée ;
+- normalise la compatibilité 16 KB uniquement lorsqu'il existe du code natif et qu'elle est requise par la plateforme ou le canal ;
+- demande alors une preuve adaptée sur les bibliothèques 64 bits, le package APK/AAB et, lorsque nécessaire, un environnement runtime 16 KB ;
+- conserve les versions AGP/NDK et les commandes précises comme moyens de preuve/toolchain, non comme minima PGR génériques.
+
+## Vérification officielle utilisée
+
+La vérification courante effectuée avant préparation du delta couvre :
+
+```text
+Support 16 KB page sizes
+Android ABIs
+Improve your code with lint checks
+Test from the command line
+Build your app from the command line
+Meet Google Play's target API level requirement
+```
+
+Elle confirme notamment, au `2026-09-28` :
+
+- Google Play demande depuis le `2026-08-31` API `36+` pour les nouvelles applications et mises à jour Android ordinaires, avec des règles distinctes pour certains form factors ; cette valeur reste une politique Play datée, pas un default Android PGR ;
+- les applications Google Play ciblant API `35+` doivent supporter les pages `16 KB` sur appareils 64 bits et la documentation courante annonce le `2027-02-01` comme échéance à partir de laquelle les mises à jour non compatibles ne pourront plus être publiées ;
+- une application sans code natif direct ou transitif n'a pas de réalignement ELF à effectuer ; une application native doit vérifier aussi ses bibliothèques tierces précompilées ;
+- les moyens officiels de preuve couvrent les segments ELF, `zipalign -P 16` pour l'APK, l'alignement déclaré dans l'AAB via `bundletool` et, lorsque pertinent, un test sur environnement 16 KB ;
+- AGP `8.5.1+` et NDK `r28+` facilitent le chemin standard actuel mais ne deviennent pas des minima PGR universels ;
+- Lint doit être lancé explicitement ; les tests locaux JVM et instrumentés ont des environnements et des responsabilités distincts ;
+- un APK est directement installable, tandis qu'un AAB sert à la distribution et n'est pas une preuve runtime par lui-même.
+
+## Validation opérateur
+
+Après application du history `PASS`, commit/push de `alpha.2`, puis application du présent delta :
+
+```bash
+test "$(cat VERSION)" = '0.1.3-alpha.3'
+git cat-file -e HEAD:history/0.1.3/alpha.2.md
+test -f history/0.1.3/alpha.2.md
+test -f deltas/0.1.3/alpha.3.md
+test ! -e history/0.1.3/alpha.3.md
+
+grep -A2 '^## Statut$' history/0.1.3/alpha.2.md | grep -Fx 'PASS'
+grep -Fx '<!-- version: 3 -->' docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+grep -Fx '<!-- version: 5 -->' docs/rules/610-ANDROID.md
+
+python3 -B -m unittest discover -s tests -v
+
+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
+
+python3 -B - <<'PYGATE'
+from pathlib import Path
+import re
+
+history = Path('history/0.1.3/alpha.2.md').read_text(encoding='utf-8')
+assert re.search(r'## Statut\s+PASS\s', history)
+
+android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
+assert android.startswith('<!-- file: docs/rules/610-ANDROID.md -->\n<!-- version: 5 -->')
+
+for phrase in (
+    '## NDK, ABI et code natif',
+    'bibliothèques natives précompilées ou apportées par un SDK',
+    'compilation native',
+    'packaging',
+    'runtime',
+    '## Android Lint',
+    'PGR MUST NOT supposer qu\'un build Gradle ordinaire exécute Lint automatiquement.',
+    'JVM unit',
+    'instrumented / integration',
+    'smoke device / AVD',
+    'Un AAB n\'est pas directement une preuve d\'installation ou d\'exécution sur device.',
+    '## Pages mémoire 16 KB et packaging natif',
+    'Google Play',
+    'API `35` ou supérieur',
+    '`zipalign -P 16`',
+    '`bundletool`',
+):
+    assert phrase in android, phrase
+
+assert 'PGR ne fixe ni version NDK ni liste universelle d\'ABI.' in android
+assert 'PGR MUST NOT imposer une version AGP/NDK globale uniquement pour cette raison.' in android
+assert 'targetSdk` minimal' in android
+
+plan = Path('docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
+for phrase in (
+    '## Décision après `alpha.2`',
+    'La gate opérateur de `alpha.2` est `PASS`',
+    '### Vérification Android officielle courante pour `alpha.3`',
+    'depuis le `2026-08-31`',
+    'à partir du `2027-02-01`',
+    '### Scope arrêté pour `alpha.3`',
+    'Aucun owner JNI/Rust/SDL, skeleton Android, audit Python ou contrat `docs/validation/` n\'est créé.',
+):
+    assert phrase in plan, phrase
+
+assert not Path('docs/validation/006-ANDROID_VALIDATION.md').exists()
+assert not Path('history/0.1.3/alpha.3.md').exists()
+
+for forbidden in (
+    'NDK MUST être r28',
+    'MUST supporter arm64-v8a, armeabi-v7a, x86_64 et x86',
+    'targetSdk MUST être 36',
+):
+    assert forbidden not in android, forbidden
+
+print('0.1.3 alpha.3 Android native/distribution audit: clean (conditional native ownership, lint/tests/package boundaries and 16 KB policy verified)')
+PYGATE
+
+git diff --check
+git add VERSION \
+    docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
+    docs/rules/610-ANDROID.md \
+    deltas/0.1.3/alpha.3.md
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history est :
+
+```text
+M  VERSION
+A  deltas/0.1.3/alpha.3.md
+M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+M  docs/rules/610-ANDROID.md
+```
+
+La revue qualitative doit confirmer que :
+
+- aucune valeur Games (NDK `r28c`, quatre ABI, SDL3, Rust/JNI) n'est devenue une règle Android générale ;
+- une application sans code natif n'hérite d'aucune gate NDK/ABI/ELF artificielle ;
+- une dépendance native précompilée est couverte par la même preuve package que le code natif du projet ;
+- Android Lint, tests JVM, tests instrumentés, package, install et smoke restent des preuves distinctes et proportionnées ;
+- un AAB n'est pas traité comme un artefact directement installable ;
+- la règle 16 KB est conditionnelle, fondée sur la politique officielle courante et ne fige ni date ni version d'outil comme default PGR durable ;
+- le profil exige de revalider les politiques de distribution évolutives plutôt que de conserver aveuglément une valeur `targetSdk` datée ;
+- PGR ne prétend pas avoir reconstruit les APK/AAB Games pendant cette tranche documentaire ;
+- aucun contrat Android séparé, skeleton, audit ou owner spécialisé n'a été créé uniquement pour remplir la release ;
+- Tauri `0.1.4` et l'adoption Games `0.1.5` restent hors scope.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.3/alpha.3.md`, puis préparer `0.1.3-beta.1` pour la réconciliation du profil Android révisé contre Games, `520-JAVA.md`, `522-GRADLE.md`, `600-PLATFORMS.md` et `400-VALIDATION.md`.
+
+La beta doit décider explicitement si `610-ANDROID.md` et les owners existants suffisent. Si un artefact fonctionnel supplémentaire devient réellement nécessaire, déclencher un REPLAN vers une tranche alpha dédiée au lieu de l'ajouter en beta.
+
+### FAIL
+
+Consigner le diagnostic réel dans `history/0.1.3/alpha.3.md` et rester dans `alpha.3.fix.N` sauf REPLAN justifié. Le fix MUST rester borné au natif, packaging, distribution et validation Android et ne doit pas absorber Tauri `0.1.4` ou l'adoption Games `0.1.5`.

deltas/0.1.3/beta.1.md

@@ -0,0 +1,266 @@
+<!-- file: deltas/0.1.3/beta.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.3-beta.1 — réconciliation Android et décision finale d'artefacts
+
+## Baseline et version
+
+Baseline attendue : commit opérateur de `0.1.3-alpha.3`, réalisé après application de `history/0.1.3/alpha.3.md` avec statut `PASS`.
+
+Version avant application :
+
+```text
+0.1.3-alpha.3
+```
+
+Version après application :
+
+```text
+0.1.3-beta.1
+```
+
+## Objet
+
+Cette tranche exécute la réconciliation prévue après les révisions Android `alpha.2` et `alpha.3`. Elle ne crée aucune nouvelle règle fonctionnelle et ne modifie pas `610-ANDROID.md`.
+
+La beta vérifie que le profil révisé reste générique face au corpus Games, se compose correctement avec `400-VALIDATION.md`, `520-JAVA.md`, `522-GRADLE.md` et `600-PLATFORMS.md`, puis tranche explicitement la question des artefacts Android supplémentaires.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+README.md
+docs/000-README.md
+docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+```
+
+ADD :
+
+```text
+deltas/0.1.3/beta.1.md
+```
+
+DELETE : aucun.
+
+Aucun `history/0.1.3/beta.1.md` n'est anticipé.
+
+## Réconciliation contre les owners PGR
+
+La revue confirme la composition suivante :
+
+```text
+400-VALIDATION.md    sélection et autorité générales des preuves
+520-JAVA.md          Java uniquement lorsqu'il est présent
+522-GRADLE.md        Gradle uniquement lorsqu'il est utilisé
+600-PLATFORMS.md     contrat commun des plateformes
+610-ANDROID.md       spécialisation Android
+```
+
+Le profil Android ne recopie donc pas les contrats Java/Gradle généraux et ne transforme pas la présence d'AGP ou d'un JDK de build en applicabilité automatique du profil Java.
+
+`400-VALIDATION.md` possède déjà la validation proportionnée et les catégories de preuves. `610-ANDROID.md` ajoute uniquement les responsabilités Android nécessaires pour choisir Lint, tests, packaging, installation et smokes selon le risque.
+
+## Réconciliation contre Games
+
+Les choix réutilisables démontrés par Games sont intégrés comme contrats génériques sans reprendre ses valeurs concrètes.
+
+Restent explicitement locaux à Games :
+
+```text
+chemin concret Android/
+Groovy DSL
+Gradle système sans Wrapper
+AGP 9.4.0
+Gradle 9.7.1 / contrainte système >= 9.6.0
+JDK 25.0.4.1
+Java source/target 17
+compileSdk 36 / targetSdk 36 / minSdk 21
+NDK r28c
+arm64-v8a / armeabi-v7a / x86_64 / x86
+cargo ndk / bridge JNI / SDL3 / staging jniLibs
+modules, Activities, labels et assets Games
+```
+
+Aucune de ces valeurs n'est promue comme minimum Android PGR.
+
+Les deux corrections `OVERRIDE` initiales sont résolues : le Wrapper n'est plus présenté comme élément structurel obligatoire et `minSdk` est un contrat produit explicitement justifié.
+
+Le sujet 16 KB, initialement `DEFER`, a été vérifié pendant `alpha.3` puis normalisé uniquement de manière conditionnelle au code natif, au package et au canal de distribution concerné. Les versions d'outils et échéances observées restent des informations datées, pas des defaults universels.
+
+## Décision finale d'artefacts
+
+Aucun artefact technique supplémentaire n'est justifié pour `0.1.3`.
+
+Ne sont donc pas créés :
+
+```text
+docs/validation/006-ANDROID_VALIDATION.md
+skeleton Android
+template de build Android générique
+audit Python Android
+owner JNI / Rust Android / SDL
+```
+
+`400 + 600 + 610`, complétés par `520` et `522` lorsqu'ils sont applicables, couvrent déjà les responsabilités réutilisables démontrées. PGR ne possède en outre aucun build Android exécutable qui fournirait aujourd'hui un sujet légitime pour un skeleton, template ou audit spécialisé.
+
+Si un nouvel artefact fonctionnel devenait réellement nécessaire, il exigerait un REPLAN vers une tranche alpha dédiée. La beta ne doit pas ajouter opportunément du contenu fonctionnel nouveau.
+
+## Documentation durable
+
+La tranche actualise :
+
+- le statut racine de la release ;
+- l'index documentaire `0.1.3` ;
+- le plan actif avec le `PASS` réel de `alpha.3`, la résolution des classifications et la décision finale d'artefacts.
+
+`610-ANDROID.md` reste en révision `5`. `ROADMAP.md`, `CHANGELOG.md`, `RULES.md`, les owners `400/520/522/600`, les skeletons, templates, validations et scripts restent inchangés.
+
+Tauri demeure strictement réservé à `0.1.4` et l'adoption Games à `0.1.5`.
+
+## Validation opérateur
+
+Après application du history `PASS` de `alpha.3`, commit/push de `alpha.3`, puis application du présent delta :
+
+```bash
+test "$(cat VERSION)" = '0.1.3-beta.1'
+git cat-file -e HEAD:history/0.1.3/alpha.3.md
+test -f history/0.1.3/alpha.3.md
+test -f deltas/0.1.3/beta.1.md
+test ! -e history/0.1.3/beta.1.md
+
+grep -A2 '^## Statut$' history/0.1.3/alpha.3.md | grep -Fx 'PASS'
+
+grep -Fx '<!-- version: 24 -->' README.md
+grep -Fx '<!-- version: 38 -->' docs/000-README.md
+grep -Fx '<!-- version: 4 -->' docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+grep -Fx '<!-- version: 5 -->' docs/rules/610-ANDROID.md
+
+grep -Fx '<!-- version: 1 -->' docs/rules/400-VALIDATION.md
+grep -Fx '<!-- version: 4 -->' docs/rules/520-JAVA.md
+grep -Fx '<!-- version: 1 -->' docs/rules/522-GRADLE.md
+grep -Fx '<!-- version: 1 -->' docs/rules/600-PLATFORMS.md
+
+python3 -B -m unittest discover -s tests -v
+
+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
+
+python3 -B - <<'PYGATE'
+from pathlib import Path
+import re
+
+history = Path('history/0.1.3/alpha.3.md').read_text(encoding='utf-8')
+assert re.search(r'## Statut\s+PASS\s', history)
+
+validation = Path('docs/rules/400-VALIDATION.md').read_text(encoding='utf-8')
+java = Path('docs/rules/520-JAVA.md').read_text(encoding='utf-8')
+gradle = Path('docs/rules/522-GRADLE.md').read_text(encoding='utf-8')
+platforms = Path('docs/rules/600-PLATFORMS.md').read_text(encoding='utf-8')
+android = Path('docs/rules/610-ANDROID.md').read_text(encoding='utf-8')
+plan = Path('docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
+
+for phrase in (
+    'La validation existe pour fournir une preuve utile proportionnée au changement.',
+    'BUILD, PACKAGE et PUBLISH',
+    '## Autorité du gate opérateur',
+):
+    assert phrase in validation, phrase
+
+assert '# Profil Java' in java
+assert '# Profil Gradle' in gradle
+assert '# Règles de profils plateforme' in platforms
+
+for phrase in (
+    'Android ne sélectionne pas à lui seul le langage applicatif du projet.',
+    'Le choix de `minSdk` MUST être justifié par le contrat produit',
+    'PGR ne fixe ni version NDK ni liste universelle d\'ABI.',
+    'PGR MUST NOT supposer qu\'un build Gradle ordinaire exécute Lint automatiquement.',
+    'Un AAB n\'est pas directement une preuve d\'installation ou d\'exécution sur device.',
+    '## Pages mémoire 16 KB et packaging natif',
+    'PGR MUST NOT imposer une version AGP/NDK globale uniquement pour cette raison.',
+):
+    assert phrase in android, phrase
+
+for forbidden in (
+    'targetSdk MUST être 36',
+    'minSdk MUST être 21',
+    'NDK MUST être r28',
+    'MUST supporter arm64-v8a, armeabi-v7a, x86_64 et x86',
+    'Gradle MUST être 9.7.1',
+    'AGP MUST être 9.4.0',
+    'JDK MUST être 25',
+):
+    assert forbidden not in android, forbidden
+
+for phrase in (
+    '## Décision après `alpha.3` et réconciliation `beta.1`',
+    'La gate opérateur de `alpha.3` est `PASS`',
+    '### Résolution de la classification initiale',
+    '### Décision finale d\'artefacts Android',
+    'Aucun artefact technique supplémentaire n\'est justifié pour `0.1.3`.',
+    'docs/validation/006-ANDROID_VALIDATION.md',
+    '### Frontières après réconciliation',
+    'Tauri                    0.1.4',
+    'adoption Games           0.1.5',
+):
+    assert phrase in plan, phrase
+
+assert not Path('docs/validation/006-ANDROID_VALIDATION.md').exists()
+assert not Path('history/0.1.3/beta.1.md').exists()
+
+for forbidden_path in (
+    'templates/android',
+    'docs/skeletons/004-ANDROID.md',
+    'docs/rules/620-JNI.md',
+):
+    assert not Path(forbidden_path).exists(), forbidden_path
+
+print('0.1.3 beta.1 reconciliation audit: clean (Android profile generic, Games-local choices preserved, existing owners sufficient, no extra artifacts justified)')
+PYGATE
+
+git diff --check
+
+git add README.md VERSION \
+    docs/000-README.md \
+    docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
+    deltas/0.1.3/beta.1.md
+
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history est exactement :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.3/beta.1.md
+M  docs/000-README.md
+M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+```
+
+La revue qualitative doit confirmer que :
+
+- aucun choix local Games n'est devenu une règle Android générale ;
+- les contraintes NDK/ABI/16 KB restent conditionnelles et n'imposent aucune toolchain universelle ;
+- Java et Gradle restent des profils composés uniquement lorsqu'ils sont applicables ;
+- `400 + 600 + 610` expriment déjà la validation Android sans contrat séparé redondant ;
+- aucun skeleton, template, audit ou owner spécialisé n'est ajouté pour satisfaire une structure théorique ;
+- Tauri `0.1.4` n'est pas commencé et l'adoption Games `0.1.5` reste hors scope ;
+- aucun `0.1.8` n'est réservé.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.3/beta.1.md`, puis préparer `0.1.3-rc.1` pour geler le scope Android, préparer le changelog candidat et le prompt de reprise `0.1.4`, puis rejouer le release gate complet sans commencer Tauri.
+
+### FAIL
+
+Consigner le diagnostic réel dans `history/0.1.3/beta.1.md`, puis produire `beta.1.fix.N` ou effectuer un REPLAN uniquement si un défaut d'ownership, de généricité ou de frontière ne peut pas être corrigé localement sans nouvelle matière fonctionnelle.

deltas/0.1.3/rc.1.md

@@ -0,0 +1,312 @@
+<!-- file: deltas/0.1.3/rc.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.3-rc.1 — gel du scope Android et gate de release candidate
+
+## Baseline et version
+
+Baseline attendue : commit opérateur de `0.1.3-beta.1`, réalisé après application de `history/0.1.3/beta.1.md` avec statut `PASS`.
+
+Le hash de ce commit n'est pas anticipé.
+
+Version avant application :
+
+```text
+0.1.3-beta.1
+```
+
+Version après application :
+
+```text
+0.1.3-rc.1
+```
+
+## Objet et gel
+
+La RC gèle le scope fonctionnel de `0.1.3` sur :
+
+- Android comme spécialisation de `600-PLATFORMS.md`, neutre vis-à-vis du langage applicatif et composant Java/Gradle uniquement lorsqu'ils sont réellement applicables ;
+- les responsabilités distinctes de `compileSdk`, `targetSdk` et `minSdk`, avec `minSdk` justifié par le contrat produit plutôt que minimisé cérémoniellement ;
+- `namespace`, `applicationId`, manifests/resources, configuration locale et signing comme responsabilités Android clairement bornées ;
+- NDK, ABI et bibliothèques natives uniquement pour les projets réellement concernés, sans version NDK ni liste d'ABI universelles ;
+- la séparation entre compilation native, packaging et preuve runtime ;
+- Android Lint comme gate explicite, avec tests JVM, tests instrumentés et smokes device/AVD sélectionnés proportionnellement au changement ;
+- la distinction APK/AAB versus preuve d'installation/exécution ;
+- la compatibilité pages mémoire 16 KB comme contrat conditionnel au code natif, au package et au canal de distribution concernés, sans minimum AGP/NDK/SDK universel ;
+- les choix spécifiques Games — versions d'outils, niveaux SDK, quatre ABI, Rust/JNI/SDL, modules et assets — conservés comme décisions locales ;
+- la décision beta qu'aucun skeleton Android, template de build, audit Python, owner JNI/Rust/SDL ni contrat de validation Android séparé n'est justifié ;
+- la frontière suivante : réexamen Tauri `0.1.4`, adoption Games `0.1.5`, adoption KSP `0.1.6`.
+
+Le changelog reçoit une entrée candidate `0.1.3` orientée utilisateurs. Le prompt `010-V0_1_4_START_PROMPT.md` est préparé pour le réexamen Tauri après publication vérifiée de `v0.1.3`.
+
+Aucune nouvelle règle fonctionnelle Android n'entre dans cette RC. Les owners, skeletons, templates, validations et scripts sont vérifiés mais non modifiés.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+CHANGELOG.md
+docs/000-README.md
+docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+```
+
+ADD :
+
+```text
+deltas/0.1.3/rc.1.md
+prompts/010-V0_1_4_START_PROMPT.md
+```
+
+DELETE : aucun.
+
+Le history `beta.1` est livré séparément et MUST être appliqué/committé avant ce delta.
+
+## Gate opérateur de release candidate
+
+Après application du history `PASS` de `beta.1`, commit/push de `beta.1`, puis application du présent delta :
+
+```bash
+test "$(cat VERSION)" = '0.1.3-rc.1'
+git cat-file -e HEAD:history/0.1.3/beta.1.md
+test -f history/0.1.3/beta.1.md
+test -f deltas/0.1.3/rc.1.md
+test -f prompts/010-V0_1_4_START_PROMPT.md
+test ! -e history/0.1.3/rc.1.md
+
+grep -A2 '^## Statut$' history/0.1.3/beta.1.md | grep -Fx 'PASS'
+grep -Fx '<!-- version: 16 -->' CHANGELOG.md
+grep -Fx '## 0.1.3 (candidate)' CHANGELOG.md
+grep -Fx '<!-- version: 39 -->' docs/000-README.md
+grep -Fx '<!-- version: 5 -->' docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+grep -Fx '<!-- version: 14 -->' ROADMAP.md
+grep -Fx '<!-- version: 1 -->' prompts/010-V0_1_4_START_PROMPT.md
+
+grep -Fx '<!-- version: 5 -->' docs/rules/610-ANDROID.md
+grep -Fx '<!-- version: 6 -->' docs/rules/710-TAURI.md
+grep -Fx '<!-- version: 2 -->' docs/studies/002-TAURI_SKELETON_DECISION.md
+grep -Fx '<!-- version: 1 -->' docs/skeletons/003-WEB_FRONTEND.md
+grep -Fx '<!-- version: 1 -->' docs/validation/005-WEB_FRONTEND_VALIDATION.md
+```
+
+Contrôle d'intégration de la RC :
+
+```bash
+python3 -B - <<'PYGATE'
+from pathlib import Path
+import re
+
+expected = {
+    "alpha.1.md": "PASS",
+    "alpha.2.md": "PASS",
+    "alpha.3.md": "PASS",
+    "beta.1.md": "PASS",
+}
+
+histories = {path.name for path in Path("history/0.1.3").glob("*.md")}
+assert histories == set(expected), histories
+for name, status in expected.items():
+    text = Path("history/0.1.3", name).read_text(encoding="utf-8")
+    assert re.search(rf"## Statut\s+{status}\s", text), (name, status)
+
+deltas = {path.name for path in Path("deltas/0.1.3").glob("*.md")}
+assert deltas == set(expected) | {"rc.1.md"}, deltas
+
+changelog = Path("CHANGELOG.md").read_text(encoding="utf-8")
+assert "## 0.1.3 (candidate)" in changelog
+section = changelog.split("## 0.1.3 (candidate)", 1)[1].split("## 0.1.2", 1)[0]
+for phrase in (
+    "profil Android",
+    "compileSdk",
+    "targetSdk",
+    "minSdk",
+    "namespace",
+    "applicationId",
+    "NDK",
+    "Android Lint",
+    "tests instrumentés",
+    "APK/AAB",
+    "16 KB",
+    "0.1.4",
+    "0.1.5",
+):
+    assert phrase in section, phrase
+for forbidden in (
+    "alpha.1",
+    "alpha.2",
+    "alpha.3",
+    "beta.1",
+    "rc.1",
+):
+    assert forbidden not in section, forbidden
+
+android = Path("docs/rules/610-ANDROID.md").read_text(encoding="utf-8")
+for phrase in (
+    "Android ne sélectionne pas à lui seul le langage applicatif du projet.",
+    "Le choix de `minSdk` MUST être justifié par le contrat produit",
+    "PGR ne fixe ni version NDK ni liste universelle d'ABI.",
+    "PGR MUST NOT supposer qu'un build Gradle ordinaire exécute Lint automatiquement.",
+    "Un AAB n'est pas directement une preuve d'installation ou d'exécution sur device.",
+    "## Pages mémoire 16 KB et packaging natif",
+    "PGR MUST NOT imposer une version AGP/NDK globale uniquement pour cette raison.",
+):
+    assert phrase in android, phrase
+for forbidden in (
+    "targetSdk MUST être 36",
+    "minSdk MUST être 21",
+    "NDK MUST être r28",
+    "MUST supporter arm64-v8a, armeabi-v7a, x86_64 et x86",
+    "Gradle MUST être 9.7.1",
+    "AGP MUST être 9.4.0",
+    "JDK MUST être 25",
+):
+    assert forbidden not in android, forbidden
+
+plan = Path("docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md").read_text(encoding="utf-8")
+for phrase in (
+    "### beta.1 — réconciliation et décision d'artefacts\n\nRelire",
+    "Statut opérateur : **PASS**.",
+    "### rc.1 — release candidate\n\nStatut opérateur : **à valider**.",
+    "prompts/010-V0_1_4_START_PROMPT.md",
+    "Aucune nouvelle fonctionnalité normative Android ne doit apparaître en RC.",
+):
+    assert phrase in plan, phrase
+
+prompt = Path("prompts/010-V0_1_4_START_PROMPT.md").read_text(encoding="utf-8")
+for phrase in (
+    "archive source téléchargée depuis le tag Gitea `v0.1.3`",
+    "pgr-0.1.3-publish.001-report.md",
+    "0.1.4-alpha.1",
+    "2a9cabcb9f147a348dcf8d24df8bc6c5029089b6d49feb17bd4a42b4293c329a",
+    "ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8",
+    "002-TAURI_SKELETON_DECISION.md",
+    "710-TAURI.md",
+    "003-WEB_FRONTEND",
+    "ADOPT / KEEP-LOCAL / OVERRIDE / DEFER",
+    "conditions de sortie",
+    "créer le skeleton Tauri parce que la roadmap le mentionne",
+    "adoption Games `0.1.5`",
+    "adoption KSP `0.1.6`",
+):
+    assert phrase in prompt, phrase
+
+study = Path("docs/studies/002-TAURI_SKELETON_DECISION.md").read_text(encoding="utf-8")
+for phrase in (
+    "DEFER",
+    "Condition 1 — TypeScript et conventions Web contrôlées",
+    "Condition 2 — Vite et ownership des commandes/dev server/build outputs",
+    "Condition 3 — Sass/CSS et statut des artefacts générés",
+    "Condition 4 — validation frontend indépendante de la validation Tauri",
+    "Condition 5 — framework CSS classé comme décision de skeleton/projet",
+    "réexamen autorisé            0.1.4",
+    "création automatique         interdite",
+):
+    assert phrase in study, phrase
+
+roadmap = Path("ROADMAP.md").read_text(encoding="utf-8")
+for version in ("0.1.3", "0.1.4", "0.1.5", "0.1.6", "0.1.7"):
+    assert f"- `( ) {version}`" in roadmap, version
+assert "- `( ) 0.1.8`" not in roadmap
+assert "skeleton Tauri jusqu'au réexamen 0.1.4" in roadmap
+
+for forbidden_path in (
+    "docs/validation/006-ANDROID_VALIDATION.md",
+    "docs/skeletons/004-ANDROID.md",
+    "docs/rules/620-JNI.md",
+    "docs/skeletons/004-TAURI.md",
+):
+    assert not Path(forbidden_path).exists(), forbidden_path
+
+index = Path("docs/000-README.md").read_text(encoding="utf-8")
+assert "../prompts/010-V0_1_4_START_PROMPT.md" in index
+
+print("0.1.3 rc.1 integration audit: clean (4 prior histories, frozen Android profile, candidate changelog and prompt 010 verified)")
+PYGATE
+```
+
+Rejouer ensuite les preuves PGR :
+
+```bash
+python3 -B -m unittest discover -s tests -v
+
+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
+```
+
+Vérifier également l'hygiène texte/templates sans simuler une toolchain Android ou Tauri absente du dépôt PGR :
+
+```bash
+python3 -B - <<'PYHYGIENE'
+from pathlib import Path
+import json
+import tomllib
+
+for path in sorted(Path("templates/rust-cargo").rglob("*.toml")):
+    tomllib.loads(path.read_text(encoding="utf-8"))
+
+json.loads(Path("templates/web-typescript/package.json").read_text(encoding="utf-8"))
+json.loads(Path("templates/web-typescript/tsconfig.json").read_text(encoding="utf-8"))
+
+roots = (
+    Path("VERSION"), Path("README.md"), Path("RULES.md"), Path("ROADMAP.md"), Path("CHANGELOG.md"),
+    Path("docs"), Path("deltas"), Path("history"), Path("prompts"), Path("templates"),
+)
+files = []
+for root in roots:
+    if root.is_file():
+        files.append(root)
+    elif root.is_dir():
+        files.extend(path for path in root.rglob("*") if path.is_file())
+for path in files:
+    try:
+        data = path.read_bytes()
+        text = data.decode("utf-8")
+    except UnicodeDecodeError:
+        continue
+    assert b"\r" not in data, path
+    assert text.endswith("\n"), path
+    for number, line in enumerate(text.splitlines(), 1):
+        assert line == line.rstrip(" \t"), (path, number)
+print("0.1.3 rc.1 text/template hygiene: clean")
+PYHYGIENE
+
+git diff --check
+git add VERSION CHANGELOG.md docs/000-README.md \
+    docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
+    deltas/0.1.3/rc.1.md prompts/010-V0_1_4_START_PROMPT.md
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history est exactement :
+
+```text
+M  CHANGELOG.md
+M  VERSION
+A  deltas/0.1.3/rc.1.md
+M  docs/000-README.md
+M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+A  prompts/010-V0_1_4_START_PROMPT.md
+```
+
+La revue qualitative doit confirmer que :
+
+- aucune règle fonctionnelle Android nouvelle n'entre en RC ;
+- `610-ANDROID.md` reste en révision `5` et aucun choix Games n'est généralisé ;
+- aucun artefact Android supplémentaire n'est créé ;
+- le changelog candidat décrit la valeur utilisateur de `0.1.3` sans recopier la chronologie alpha/beta/RC ;
+- le prompt `010` exige une future stable `v0.1.3` réellement publiée et son rapport post-tag `PASS` ;
+- le `DEFER` Tauri n'est pas levé par le prompt : `0.1.4` doit le réexaminer objectivement contre les corpus courants ;
+- l'adoption Games `0.1.5` et l'adoption KSP `0.1.6` ne sont pas commencées ;
+- aucune preuve Android/Tauri exécutable n'est simulée dans PGR.
+
+## Transition
+
+### PASS
+
+Produire séparément `history/0.1.3/rc.1.md`, puis préparer la promotion mécanique `0.1.3-rel.1` sans rouvrir le scope fonctionnel.

deltas/0.1.3/rel.1.md

@@ -0,0 +1,288 @@
+<!-- file: deltas/0.1.3/rel.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.3 rel.1 — promotion stable pré-tag
+
+## Baseline et version
+
+Baseline : `0.1.3-rc.1`, avec `history/0.1.3/rc.1.md` appliqué et committé. Ce delta MUST NOT être appliqué avant ce commit.
+
+Version avant application :
+
+```text
+0.1.3-rc.1
+```
+
+Version après application :
+
+```text
+0.1.3
+```
+
+`rel.1` identifie la clôture opérationnelle ; il ne fait pas partie de la version SemVer du produit.
+
+## Objet
+
+Promouvoir mécaniquement la RC validée vers la stable `0.1.3` sans rouvrir le scope fonctionnel.
+
+La tranche finalise uniquement la présentation et les métadonnées de release : version stable, roadmap terminée, changelog sans marqueur `candidate`, README/index en état stable et plan `009` historique. Aucun owner Android/Java/Gradle/Tauri, template, skeleton, validation, étude technique ou script d'audit n'est modifié.
+
+La validation de cette tranche est **pré-tag**. Le tag `v0.1.3`, son archive source Gitea et le rapport `pgr-0.1.3-publish.001-report.md` ne sont pas déclarés existants par ce delta. Ils suivent uniquement un history `rel.1` `PASS`, le commit stable `0.1.3` et la publication réelle du tag.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+README.md
+ROADMAP.md
+CHANGELOG.md
+docs/000-README.md
+docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+```
+
+ADD :
+
+```text
+deltas/0.1.3/rel.1.md
+```
+
+DELETE : aucun.
+
+Le history `rc.1` est livré séparément. Le history `rel.1` sera produit uniquement après la gate opérateur.
+
+## Validation opérateur pré-tag
+
+Après application sur le commit contenant `history/0.1.3/rc.1.md` :
+
+```bash
+test "$(cat VERSION)" = '0.1.3'
+git cat-file -e HEAD:history/0.1.3/rc.1.md
+test -f history/0.1.3/rc.1.md
+test -f deltas/0.1.3/rel.1.md
+test -f prompts/010-V0_1_4_START_PROMPT.md
+test ! -e history/0.1.3/rel.1.md
+
+grep -A2 '^## Statut$' history/0.1.3/rc.1.md | grep -Fx 'PASS'
+grep -Fx '<!-- version: 25 -->' README.md
+grep -Fx '<!-- version: 15 -->' ROADMAP.md
+grep -Fx '<!-- version: 17 -->' CHANGELOG.md
+grep -Fx '<!-- version: 40 -->' docs/000-README.md
+grep -Fx '<!-- version: 6 -->' docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+grep -F -- '- `(x) 0.1.3`' ROADMAP.md
+grep -Fx '## 0.1.3' CHANGELOG.md
+grep -F 'avec `0.1.3` d’un profil Android réévalué contre Games' README.md
+grep -F 'plan historique de la stable `0.1.3`' docs/000-README.md
+
+python3 -B - <<'PYGATE'
+from pathlib import Path
+import re
+
+expected = {
+    "alpha.1.md": "PASS",
+    "alpha.2.md": "PASS",
+    "alpha.3.md": "PASS",
+    "beta.1.md": "PASS",
+    "rc.1.md": "PASS",
+}
+
+for name, status in expected.items():
+    delta = Path("deltas/0.1.3", name)
+    history = Path("history/0.1.3", name)
+    assert delta.is_file(), name
+    assert history.is_file(), name
+    text = history.read_text(encoding="utf-8")
+    assert re.search(rf"## Statut\s+{status}\s", text), (name, status)
+
+pending = {path.name for path in Path("deltas/0.1.3").glob("*.md")} - {
+    path.name for path in Path("history/0.1.3").glob("*.md")
+}
+assert pending == {"rel.1.md"}, pending
+
+roadmap = Path("ROADMAP.md").read_text(encoding="utf-8")
+assert "- `(x) 0.1.3`" in roadmap
+for version in ("0.1.4", "0.1.5", "0.1.6", "0.1.7"):
+    assert f"- `( ) {version}`" in roadmap, version
+assert "- `( ) 0.1.8`" not in roadmap
+assert "skeleton Tauri jusqu'au réexamen 0.1.4" in roadmap
+
+changelog = Path("CHANGELOG.md").read_text(encoding="utf-8")
+assert "## 0.1.3" in changelog.splitlines()
+assert "## 0.1.3 (candidate)" not in changelog
+section = changelog.split("## 0.1.3", 1)[1].split("## 0.1.2", 1)[0]
+for phrase in (
+    "profil Android",
+    "compileSdk",
+    "targetSdk",
+    "minSdk",
+    "namespace",
+    "applicationId",
+    "NDK",
+    "Android Lint",
+    "tests instrumentés",
+    "APK/AAB",
+    "16 KB",
+    "0.1.4",
+    "0.1.5",
+):
+    assert phrase in section, phrase
+for forbidden in ("alpha.1", "alpha.2", "alpha.3", "beta.1", "rc.1", "rel.1"):
+    assert forbidden not in section, forbidden
+
+readme = Path("README.md").read_text(encoding="utf-8")
+assert "avec `0.1.3` d’un profil Android réévalué contre Games" in readme
+assert "plan historique de la stable Android `0.1.3`" in readme
+
+index = Path("docs/000-README.md").read_text(encoding="utf-8")
+assert "plan historique de la stable `0.1.3`" in index
+assert "à exécuter uniquement après publication et vérification post-tag de `v0.1.3`" in index
+
+plan = Path("docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md").read_text(encoding="utf-8")
+assert "Plan 0.1.3 — réévaluation pratique Android" in plan
+assert "### rc.1 — release candidate\n\nStatut opérateur : **PASS**." in plan
+assert "history/0.1.3/rel.1.md" in plan
+assert "pgr-0.1.3-publish.001-report.md" in plan
+assert "commit `0.1.3` avant le tag `v0.1.3`" in plan
+assert "plan historique de la stable `0.1.3`" in plan
+
+prompt = Path("prompts/010-V0_1_4_START_PROMPT.md").read_text(encoding="utf-8")
+for phrase in (
+    "tag Gitea `v0.1.3`",
+    "pgr-0.1.3-publish.001-report.md",
+    "0.1.4-alpha.1",
+    "002-TAURI_SKELETON_DECISION.md",
+    "710-TAURI.md",
+    "003-WEB_FRONTEND",
+    "ADOPT / KEEP-LOCAL / OVERRIDE / DEFER",
+    "adoption Games `0.1.5`",
+    "adoption KSP `0.1.6`",
+):
+    assert phrase in prompt, phrase
+
+for path, version in (
+    ("docs/rules/400-VALIDATION.md", 1),
+    ("docs/rules/520-JAVA.md", 4),
+    ("docs/rules/522-GRADLE.md", 1),
+    ("docs/rules/600-PLATFORMS.md", 1),
+    ("docs/rules/610-ANDROID.md", 5),
+    ("docs/rules/710-TAURI.md", 6),
+    ("docs/studies/002-TAURI_SKELETON_DECISION.md", 2),
+    ("docs/skeletons/003-WEB_FRONTEND.md", 1),
+    ("docs/validation/005-WEB_FRONTEND_VALIDATION.md", 1),
+):
+    lines = Path(path).read_text(encoding="utf-8").splitlines()
+    assert lines[1] == f"<!-- version: {version} -->", (path, lines[1])
+
+android = Path("docs/rules/610-ANDROID.md").read_text(encoding="utf-8")
+for phrase in (
+    "Android ne sélectionne pas à lui seul le langage applicatif du projet.",
+    "Le choix de `minSdk` MUST être justifié par le contrat produit",
+    "PGR ne fixe ni version NDK ni liste universelle d'ABI.",
+    "PGR MUST NOT supposer qu'un build Gradle ordinaire exécute Lint automatiquement.",
+    "Un AAB n'est pas directement une preuve d'installation ou d'exécution sur device.",
+    "## Pages mémoire 16 KB et packaging natif",
+    "PGR MUST NOT imposer une version AGP/NDK globale uniquement pour cette raison.",
+):
+    assert phrase in android, phrase
+for forbidden in (
+    "targetSdk MUST être 36",
+    "minSdk MUST être 21",
+    "NDK MUST être r28",
+    "MUST supporter arm64-v8a, armeabi-v7a, x86_64 et x86",
+    "Gradle MUST être 9.7.1",
+    "AGP MUST être 9.4.0",
+    "JDK MUST être 25",
+):
+    assert forbidden not in android, forbidden
+
+for forbidden_path in (
+    "docs/validation/006-ANDROID_VALIDATION.md",
+    "docs/skeletons/004-ANDROID.md",
+    "docs/rules/620-JNI.md",
+    "docs/skeletons/004-TAURI.md",
+):
+    assert not Path(forbidden_path).exists(), forbidden_path
+
+workflow = Path("docs/rules/210-WORKFLOW.md").read_text(encoding="utf-8")
+assert "history rel.1 FAIL / PARTIAL / BLOCKED" in workflow
+assert "premier history rel.N[/fix.M] PASS qui établit réellement la stable" in workflow
+assert "commit X.Y.Z" in workflow
+
+print("0.1.3 rel.1 stable gate audit: clean (5 prior histories, rel.1 pending, stable Android presentation and post-tag Tauri handoff coherent)")
+PYGATE
+
+python3 -B -m unittest discover -s tests -v
+
+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
+
+python3 -B - <<'PYHYGIENE'
+from pathlib import Path
+import json
+import tomllib
+
+for path in sorted(Path("templates/rust-cargo").rglob("*.toml")):
+    tomllib.loads(path.read_text(encoding="utf-8"))
+
+json.loads(Path("templates/web-typescript/package.json").read_text(encoding="utf-8"))
+json.loads(Path("templates/web-typescript/tsconfig.json").read_text(encoding="utf-8"))
+
+roots = (
+    Path("VERSION"), Path("README.md"), Path("RULES.md"), Path("ROADMAP.md"), Path("CHANGELOG.md"),
+    Path("docs"), Path("deltas"), Path("history"), Path("prompts"), Path("templates"),
+)
+files = []
+for root in roots:
+    if root.is_file():
+        files.append(root)
+    elif root.is_dir():
+        files.extend(path for path in root.rglob("*") if path.is_file())
+for path in files:
+    try:
+        data = path.read_bytes()
+        text = data.decode("utf-8")
+    except UnicodeDecodeError:
+        continue
+    assert b"\r" not in data, path
+    assert text.endswith("\n"), path
+    for number, line in enumerate(text.splitlines(), 1):
+        assert line == line.rstrip(" \t"), (path, number)
+print("0.1.3 rel.1 text/template hygiene: clean")
+PYHYGIENE
+
+git diff --check
+git add VERSION README.md ROADMAP.md CHANGELOG.md docs/000-README.md \
+    docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md \
+    deltas/0.1.3/rel.1.md
+git diff --cached --check
+git status --short
+```
+
+Le scope attendu avant ajout du history est exactement :
+
+```text
+M  CHANGELOG.md
+M  README.md
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.3/rel.1.md
+M  docs/000-README.md
+M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+```
+
+La RC a déjà reconfirmé le profil Android gelé, les frontières Tauri/Games/KSP, le contrat du prompt `010` et l'absence d'artefacts Android supplémentaires. Comme `rel.1` ne modifie aucun artefact technique, la promotion stable rejoue les tests PGR, les audits documentaires et l'hygiène des templates sans simuler une toolchain Android absente du dépôt.
+
+## Revue opérateur complémentaire
+
+Confirmer que :
+
+- `0.1.3` est bien présenté comme stable partout où la RC était auparavant candidate ;
+- aucun changement fonctionnel Android n'est entré dans `rel.1` ;
+- `0.1.4` reste le réexamen Tauri, sans création anticipée du skeleton ;
+- `0.1.5` et `0.1.6` restent respectivement les adoptions Games et KSP ;
+- le tag et le rapport post-tag ne sont pas anticipés dans le dépôt pré-tag.

deltas/0.1.4/alpha.1.md

@@ -0,0 +1,207 @@
+<!-- file: deltas/0.1.4/alpha.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.4-alpha.1 — intake et cadrage du réexamen Tauri
+
+## Objet
+
+Ouvrir `0.1.4` conformément à `prompts/010-V0_1_4_START_PROMPT.md`, conserver une preuve locale de l'audit des baselines réellement fournies et matérialiser le plan avant toute modification normative ou création d'un skeleton Tauri.
+
+La tranche ne crée pas `docs/skeletons/004-TAURI.md`, ne modifie pas `710-TAURI.md` et ne commence aucune adoption Games/KSP.
+
+## Sources vérifiées avant préparation
+
+```text
+pgr-v0.1.3(1).zip
+SHA-256  f3a7dffd5fe0fd3542e6b5207fda0b94bca2bd05bd5a54542d0a08d635a5d6ee
+CRC      PASS
+
+pgr-0.1.3-publish.001-report.md
+SHA-256  5405a1d6c216a5882c4638c07d573d50d440ce9e4e892d97f425e99054245544
+status   PASS
+
+games-v0.3.6(3).zip
+SHA-256  ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
+CRC      PASS
+
+khadhroony-solana-project-v0.3.19(1).zip
+SHA-256  64a3813620925fa4f8914cdf74113399cfdd78ad51d60bbeff9bafbddcf4b253
+CRC      PASS
+```
+
+La baseline PGR correspond exactement au SHA canonique publié. La baseline Games correspond exactement à la référence `0.3.6` du prompt. KSP `0.3.19` est le corpus courant explicitement fourni et remplace, pour cette étude, la référence historique `0.3.17` sans prétendre posséder une preuve post-tag non fournie.
+
+## Résultats d'intake
+
+La stable PGR rejoue `48/48` tests Python et ses trois audits Markdown propres.
+
+Games `0.3.6` rejoue ses audits Rust/workspace, Markdown tables et distribution layout propres. KSP `0.3.19` rejoue ses audits Rust/workspace et Markdown tables propres.
+
+L'inventaire Tauri courant comporte `7` hosts : un sous Games et six sous KSP. Les sept convergent sur un host Cargo direct, `build.rs`, `tauri.conf.json`, `capabilities/`, `src/tauri.rs`, `frontend/`, TypeScript et Vite, sans `src-tauri/`.
+
+Les choix Bootstrap/Sass/TS-RS, plugins, windows, ACL, ports, identifiers, bundle/resources et WASM ne convergent pas suffisamment pour devenir des obligations générales.
+
+La relecture des owners Web confirme les cinq conditions historiques de sortie du `DEFER`. La vérification Tauri 2 officielle confirme que le layout standard et les commandes de commodité restent des possibilités supportées, tandis que capabilities/permissions doivent être traitées comme une surface de sécurité explicite.
+
+## Modifications de la tranche
+
+- `VERSION` passe à `0.1.4-alpha.1` ;
+- `README.md` annonce l'ouverture du réexamen Tauri et référence son plan actif ;
+- `docs/000-README.md` ajoute les points d'entrée actifs de `0.1.4` ;
+- `docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md` consigne audits, inventaire, classification et trajectoire ;
+- le présent delta conserve le contrat de gate opérateur.
+
+`ROADMAP.md` et `CHANGELOG.md` restent inchangés pendant cette tranche d'ouverture. Leur mise à jour est volontairement réservée aux phases de fermeture lorsque l'état réellement atteint est connu.
+
+## Décision de tranche
+
+```text
+conditions Web historiques              SATISFIED
+ancien motif Web du DEFER                LIFT
+skeleton Tauri organisationnel           ADOPT FOR MATERIALIZATION
+création pendant alpha.1                 NO
+prochaine tranche                        alpha.2 — réconciliation normative 710 + étude 002
+```
+
+Cette décision autorise la matérialisation future du candidat ; elle ne présume pas que sa forme historique est correcte en bloc.
+
+## Gate opérateur
+
+Appliquer le delta puis exécuter depuis la racine du dépôt :
+
+```bash
+cat VERSION
+
+test -f docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+test -f deltas/0.1.4/alpha.1.md
+test ! -e history/0.1.4/alpha.1.md
+test ! -e docs/skeletons/004-TAURI.md
+
+python3 -B -m unittest discover -s tests -v
+
+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
+
+python3 -B - <<'PY'
+from pathlib import Path
+import re
+
+assert Path('VERSION').read_text(encoding='utf-8').strip() == '0.1.4-alpha.1'
+
+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,
+}
+for release, count in expected.items():
+    deltas = {path.name for path in Path('deltas', release).glob('*.md')}
+    histories = {path.name for path in Path('history', release).glob('*.md')}
+    assert len(deltas) == count, (release, len(deltas))
+    assert deltas == histories, (release, sorted(deltas ^ histories))
+
+statuses = {}
+for path in Path('history/0.1.3').glob('*.md'):
+    text = path.read_text(encoding='utf-8')
+    match = re.search(r'## Statut\s+(?:`?)(PASS|FAIL|PARTIAL|BLOCKED)', text)
+    assert match is not None, path
+    statuses[path.name] = match.group(1)
+assert len(statuses) == 6, statuses
+assert set(statuses.values()) == {'PASS'}, statuses
+assert statuses['rel.1.md'] == 'PASS'
+
+roadmap = Path('ROADMAP.md').read_text(encoding='utf-8')
+assert '- `(x) 0.1.3`' in roadmap
+for release in range(4, 8):
+    assert f'- `( ) 0.1.{release}`' in roadmap, release
+assert '0.1.8' not in roadmap
+
+prompt = Path('prompts/010-V0_1_4_START_PROMPT.md').read_text(encoding='utf-8')
+for phrase in (
+    'Version cible : `0.1.4`',
+    'Première tranche attendue : `0.1.4-alpha.1`',
+    'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER',
+    'conditions de sortie du report historique',
+    'skeleton Tauri',
+    'adoption Games `0.1.5`',
+    'adoption KSP `0.1.6`',
+):
+    assert phrase in prompt, phrase
+
+plan = Path('docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
+for phrase in (
+    '7` hosts',
+    'conditions historiques de sortie     SATISFIED',
+    'Classification initiale `alpha.1`',
+    '### `ADOPT`',
+    '### `KEEP-LOCAL`',
+    '### `OVERRIDE`',
+    '### `DEFER`',
+    'ADOPT FOR MATERIALIZATION',
+    '`alpha.2` — réconciliation normative Tauri',
+    '`alpha.3` — skeleton Tauri contrôlé',
+    '`beta.1` — réconciliation et décision d\'artefacts',
+    '`rc.1` — freeze et handoff',
+    '`rel.1` — stable',
+    '0.1.5',
+    '0.1.6',
+):
+    assert phrase in plan, phrase
+
+assert Path('docs/rules/710-TAURI.md').read_text(encoding='utf-8').startswith(
+    '<!-- file: docs/rules/710-TAURI.md -->\n<!-- version: 6 -->'
+)
+assert Path('docs/studies/002-TAURI_SKELETON_DECISION.md').read_text(encoding='utf-8').startswith(
+    '<!-- file: docs/studies/002-TAURI_SKELETON_DECISION.md -->\n<!-- version: 2 -->'
+)
+assert Path('docs/skeletons/003-WEB_FRONTEND.md').exists()
+assert not Path('docs/skeletons/004-TAURI.md').exists()
+assert not Path('history/0.1.4/alpha.1.md').exists()
+
+print('0.1.4 alpha.1 structural audit: clean (96 prior pairs, 7 current Tauri hosts classified, no premature skeleton/adoption)')
+PY
+
+git diff --check
+git add VERSION README.md docs/000-README.md \
+    docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md \
+    deltas/0.1.4/alpha.1.md
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history est :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.4/alpha.1.md
+M  docs/000-README.md
+A  docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+```
+
+## Revue opérateur attendue
+
+La revue doit confirmer que `alpha.1` ne modifie ni `710-TAURI.md` ni l'étude historique avant validation du cadrage ; que les sept hosts réellement fournis sont utilisés comme preuves et non comme modèles à recopier ; que Bootstrap/Sass/TS-RS/WASM/plugins/windows/ports/identifiers restent correctement classifiés ; et que ni Games ni KSP ne sont adoptés pendant `0.1.4`.
+
+Elle doit aussi confirmer que le candidat de skeleton est **autorisé à être matérialisé plus tard**, et non déjà créé par cette tranche.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.4/alpha.1.md` à partir des résultats réellement observés. Dans la même réponse, préparer séparément le delta `0.1.4-alpha.2` consacré à la réconciliation normative de `710-TAURI.md` et de `002-TAURI_SKELETON_DECISION.md`, sans créer encore `004-TAURI.md`.
+
+Après remise du history, fournir automatiquement le bloc opérateur exact pour appliquer le history, committer/pusher `0.1.4-alpha.1`, puis seulement appliquer le delta suivant conformément à `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`.
+
+### FAIL
+
+Consigner le résultat réel dans le history, puis ouvrir `0.1.4-alpha.1.fix.1` ou un REPLAN selon la cause. Aucun changement prévu pour `alpha.2` ne doit être absorbé silencieusement dans le fix.

deltas/0.1.4/alpha.2.fix.1.md

@@ -0,0 +1,209 @@
+<!-- file: deltas/0.1.4/alpha.2.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.4-alpha.2.fix.1 — hygiène EOF et prévention automatique
+
+## Diagnostic
+
+La gate opérateur de `0.1.4-alpha.2` a validé les `48/48` tests Python, les trois audits Markdown et le contrôle normatif Tauri, puis a échoué sur les deux contrôles Git d'hygiène :
+
+```text
+docs/studies/002-TAURI_SKELETON_DECISION.md:299: new blank line at EOF.
+```
+
+Le même défaut a été signalé par :
+
+```text
+git diff --check
+git diff --cached --check
+```
+
+`history/0.1.4/alpha.2.md` enregistre donc `FAIL`. Le contenu normatif Tauri de `alpha.2` reste conservé ; le présent fix corrige uniquement l'hygiène mécanique et la lacune de prévention qui a permis la réapparition d'un défaut déjà rencontré historiquement.
+
+Version après application :
+
+```text
+0.1.4-alpha.2.fix.1
+```
+
+## Objet
+
+Corriger la ligne vide surnuméraire à EOF de l'étude Tauri et faire de cette classe de défaut une propriété automatiquement contrôlée avant les futures livraisons PGR.
+
+Le correctif introduit un audit monotâche read-only au lieu d'ajouter une vérification ad hoc dans chaque delta.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+docs/rules/210-WORKFLOW.md
+docs/studies/002-TAURI_SKELETON_DECISION.md
+docs/validation/001-VALIDATION_MATRIX.md
+```
+
+ADD :
+
+```text
+deltas/0.1.4/alpha.2.fix.1.md
+scripts/audit_text_hygiene.py
+tests/test_text_hygiene.py
+```
+
+Les autres décisions de `alpha.2`, notamment `docs/rules/710-TAURI.md`, le plan `010` et `docs/000-README.md`, MUST rester inchangées.
+
+## Correction EOF
+
+`docs/studies/002-TAURI_SKELETON_DECISION.md` conserve son contenu et sa révision interne `3`. La seule modification de ce fichier est mécanique : sa terminaison passe de deux caractères LF successifs à exactement un LF final.
+
+Aucune décision Tauri n'est modifiée par cette correction.
+
+## Audit `text_hygiene`
+
+`scripts/audit_text_hygiene.py` possède quatre propriétés mécaniques sur les fichiers texte sélectionnés :
+
+```text
+LF uniquement
+aucun whitespace terminal
+newline finale obligatoire
+exactement une newline finale, donc aucune ligne vide supplémentaire à EOF
+```
+
+L'audit reste read-only, accepte des fichiers ou répertoires explicites et ignore les répertoires générés usuels. Il ne remplace pas un formatter, un parser Markdown ou `git diff --check`.
+
+`tests/test_text_hygiene.py` couvre au minimum :
+
+- fichier propre avec exactement un LF final ;
+- ligne vide supplémentaire à EOF ;
+- newline finale absente ;
+- CRLF ;
+- espace ou tabulation terminale ;
+- exclusion d'un répertoire généré ;
+- sélection invalide.
+
+## Contrat de workflow
+
+`docs/rules/210-WORKFLOW.md` passe de la révision `7` à `8` et rend explicite que le générateur doit contrôler l'hygiène mécanique avant livraison, plutôt que déléguer sa découverte à la gate opérateur.
+
+`docs/validation/001-VALIDATION_MATRIX.md` passe de la révision `14` à `15` et ajoute `PGR-TEXT-HYGIENE-001` comme audit faible coût déclenché lorsqu'un fichier texte gouverné est modifié.
+
+Le contrôle Git reste conservé comme filet indépendant.
+
+## Gate opérateur
+
+Après application puis commit/push du history `FAIL` de `alpha.2`, appliquer ce delta et exécuter :
+
+```bash
+cat VERSION
+
+test -f history/0.1.4/alpha.2.md
+grep -A2 '^## Statut$' history/0.1.4/alpha.2.md | grep -Fx 'FAIL'
+test -f deltas/0.1.4/alpha.2.fix.1.md
+test ! -e history/0.1.4/alpha.2.fix.1.md
+
+test -f scripts/audit_text_hygiene.py
+test -f tests/test_text_hygiene.py
+
+python3 -B -m unittest discover -s tests -v
+
+python3 -B scripts/audit_text_hygiene.py \
+    VERSION README.md RULES.md ROADMAP.md CHANGELOG.md \
+    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
+
+python3 -B - <<'PY'
+from pathlib import Path
+import re
+
+assert Path('VERSION').read_text(encoding='utf-8').strip() == '0.1.4-alpha.2.fix.1'
+
+history = Path('history/0.1.4/alpha.2.md').read_text(encoding='utf-8')
+assert re.search(r'## Statut\s+FAIL', history)
+
+study_path = Path('docs/studies/002-TAURI_SKELETON_DECISION.md')
+study = study_path.read_bytes()
+assert study.endswith(b'\n')
+assert not study.endswith(b'\n\n')
+assert study_path.read_text(encoding='utf-8').startswith(
+    '<!-- file: docs/studies/002-TAURI_SKELETON_DECISION.md -->\n'
+    '<!-- version: 3 -->'
+)
+
+workflow = Path('docs/rules/210-WORKFLOW.md').read_text(encoding='utf-8')
+assert workflow.startswith(
+    '<!-- file: docs/rules/210-WORKFLOW.md -->\n'
+    '<!-- version: 8 -->'
+)
+for phrase in (
+    '## Hygiène mécanique des artefacts texte',
+    'exactement une seule newline finale',
+    'scripts/audit_text_hygiene.py',
+    'Un générateur MUST corriger un défaut mécanique détectable avant livraison',
+):
+    assert phrase in workflow, phrase
+
+matrix = Path('docs/validation/001-VALIDATION_MATRIX.md').read_text(encoding='utf-8')
+assert matrix.startswith(
+    '<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->\n'
+    '<!-- version: 15 -->'
+)
+assert '`PGR-TEXT-HYGIENE-001`' in matrix
+assert 'exactement une seule newline finale' in matrix
+
+assert Path('scripts/audit_text_hygiene.py').exists()
+assert Path('tests/test_text_hygiene.py').exists()
+
+for path, version in (
+    ('docs/rules/710-TAURI.md', '7'),
+    ('docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md', '2'),
+    ('docs/000-README.md', '42'),
+):
+    lines = Path(path).read_text(encoding='utf-8').splitlines()
+    assert lines[1] == f'<!-- version: {version} -->', (path, lines[1])
+
+assert not Path('docs/skeletons/004-TAURI.md').exists()
+assert not Path('history/0.1.4/alpha.2.fix.1.md').exists()
+
+print(
+    '0.1.4 alpha.2.fix.1 hygiene audit: clean '
+    '(EOF corrected, reusable text hygiene audit active, Tauri decisions preserved)'
+)
+PY
+
+git diff --check
+
+git add -A
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu est :
+
+```text
+M  VERSION
+A  deltas/0.1.4/alpha.2.fix.1.md
+M  docs/rules/210-WORKFLOW.md
+M  docs/studies/002-TAURI_SKELETON_DECISION.md
+M  docs/validation/001-VALIDATION_MATRIX.md
+A  scripts/audit_text_hygiene.py
+A  tests/test_text_hygiene.py
+```
+
+L'ordre d'affichage peut varier ; l'ensemble des chemins doit être identique.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.4/alpha.2.fix.1.md`, commit/push sous l'identité `0.1.4-alpha.2.fix.1`, puis poursuivre avec `alpha.3` sur cette baseline propre. Les gates suivantes de `0.1.4` doivent sélectionner `PGR-TEXT-HYGIENE-001` pour les fichiers texte modifiés.
+
+### FAIL
+
+Enregistrer le résultat réel dans `history/0.1.4/alpha.2.fix.1.md` et poursuivre sous `alpha.2.fix.N`. Ne pas commencer `alpha.3` tant que l'hygiène texte et le scope du correctif ne sont pas `PASS`.

deltas/0.1.4/alpha.2.md

@@ -0,0 +1,214 @@
+<!-- file: deltas/0.1.4/alpha.2.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.4-alpha.2 — réconciliation normative Tauri
+
+## Objet
+
+Réconcilier l'owner Tauri `710` et l'étude historique `002` à partir du cadrage `alpha.1` validé, sans matérialiser encore le skeleton `004-TAURI.md`.
+
+La tranche sépare explicitement les responsabilités Tauri des choix Web déjà possédés par les owners `530/540/550/560`, précise la frontière commande / permission / capability et rend la politique de sélection des capability files visible comme décision de sécurité.
+
+## Précondition
+
+Le history `history/0.1.4/alpha.1.md` doit être présent avec statut `PASS` avant application de ce delta.
+
+`alpha.1` a validé :
+
+```text
+48 / 48 tests PASS
+Markdown headers: clean (266 file(s))
+Markdown tables:  clean (11 table(s), 266 file(s))
+Markdown links:   clean (343 local link(s), 266 file(s))
+0.1.4 alpha.1 structural audit: clean (96 prior pairs, 7 current Tauri hosts classified, no premature skeleton/adoption)
+```
+
+## Réconciliation de `710-TAURI.md`
+
+La révision interne passe de `6` à `7`.
+
+La convention contrôlée est recentrée sur ce que Tauri possède réellement :
+
+- host Cargo direct `lib + bin` recommandé pour une nouvelle baseline PGR contrôlée ;
+- `src-tauri/` reste un layout Tauri supporté et n'est pas déclaré invalide ;
+- `build.rs`, configuration Tauri, capabilities, assemblage Rust, hooks et packaging restent dans le scope Tauri ;
+- la racine frontend est un point de composition, pas un choix possédé par `710` ;
+- TypeScript, Vite, CSS/Sass, framework CSS et package manager restent possédés par leurs owners Web ;
+- TS-RS devient un choix conditionnel de frontière typée plutôt qu'une obligation Tauri générale ;
+- aucun template technique n'est créé.
+
+La frontière de sécurité distingue désormais :
+
+```text
+commande enregistrée
+permission ACL + scopes
+capability assignant les permissions aux fenêtres/webviews
+```
+
+La tranche exige une décision explicite sur la sélection des capabilities. Elle enregistre le comportement Tauri 2 courant : si `app.security.capabilities` est absent ou vide, les capability files du répertoire `capabilities/` sont inclus par défaut ; une liste explicite permet de sélectionner ceux qui participent au build.
+
+L'ajout d'un capability file sous auto-inclusion devient donc explicitement une modification de surface de sécurité. La revue doit également considérer le cumul des droits lorsqu'une fenêtre/webview appartient à plusieurs capabilities.
+
+## Révision de l'étude `002`
+
+La révision interne passe de `2` à `3`.
+
+La décision `DEFER` de `0.0.5-alpha.9` reste conservée comme preuve historique mais n'est plus la décision active :
+
+```text
+motif Web historique                         LIFT
+candidat organisationnel                     ADOPT FOR MATERIALIZATION
+matérialisation pendant alpha.2              NO
+matérialisation visée                         alpha.3
+```
+
+Le corpus courant reste `1` host Games `0.3.6` + `6` hosts KSP `0.3.19`. La future specification doit composer fondation + Rust/Cargo + Web applicable + Tauri + plateformes ciblées, sans recopier les owners.
+
+## Mise à jour du plan et de l'index
+
+`docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md` passe en révision `2` et enregistre :
+
+- la gate `alpha.1 PASS` ;
+- les décisions normatives préparées pour `alpha.2` ;
+- l'autorisation conditionnelle de matérialiser `004-TAURI.md` en `alpha.3` ;
+- le point transversal découvert lors de l'utilisation de PGR avec SaseDev Knowledge : sémantique `SHOULD`, autonomie post-adoption et future séparation PGR/Knowledge ;
+- l'obligation de reprendre ce point lors de la revue d'horizon de fermeture avant de générer le prompt suivant.
+
+`docs/000-README.md` passe en révision `42` pour refléter l'état réconcilié du profil et de l'étude.
+
+`ROADMAP.md` et `CHANGELOG.md` restent inchangés. La trajectoire publiée `0.1.5` Games / `0.1.6` KSP / `0.1.7` audits Rust n'est pas réécrite avant la revue d'horizon prévue en fermeture de `0.1.4`.
+
+## Frontières
+
+Cette tranche MUST NOT :
+
+- créer `docs/skeletons/004-TAURI.md` ;
+- créer un template `tauri.conf.json`, `build.rs` ou capability générique ;
+- créer un contrat `docs/validation/*TAURI*` séparé ;
+- modifier `RULES.md` ou `230-ADOPTION.md` pour traiter dès maintenant le point transversal `SHOULD`/autonomie ;
+- modifier `ROADMAP.md` ou `CHANGELOG.md` ;
+- commencer l'adoption Games ou KSP.
+
+## Gate opérateur
+
+Après application du history `alpha.1`, commit/push de `alpha.1`, puis application du présent delta, exécuter depuis la racine du dépôt :
+
+```bash
+cat VERSION
+
+test -f history/0.1.4/alpha.1.md
+test -f deltas/0.1.4/alpha.2.md
+test ! -e history/0.1.4/alpha.2.md
+test ! -e docs/skeletons/004-TAURI.md
+
+grep -A4 '^## Statut$' history/0.1.4/alpha.1.md
+
+python3 -B -m unittest discover -s tests -v
+
+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
+
+python3 -B - <<'PY'
+from pathlib import Path
+import re
+
+assert Path('VERSION').read_text(encoding='utf-8').strip() == '0.1.4-alpha.2'
+
+history = Path('history/0.1.4/alpha.1.md').read_text(encoding='utf-8')
+assert re.search(r'## Statut\s+PASS', history)
+
+assert {p.name for p in Path('deltas/0.1.4').glob('*.md')} == {'alpha.1.md', 'alpha.2.md'}
+assert {p.name for p in Path('history/0.1.4').glob('*.md')} == {'alpha.1.md'}
+
+rule = Path('docs/rules/710-TAURI.md').read_text(encoding='utf-8')
+assert rule.startswith('<!-- file: docs/rules/710-TAURI.md -->\n<!-- version: 7 -->')
+for phrase in (
+    '## Commandes, permissions et capabilities',
+    'commande enregistrée  → handler natif connu du système d\'invocation',
+    'app.security.capabilities',
+    'inclut par défaut les capability files du répertoire `capabilities/`',
+    'droits cumulés',
+    'Le choix ou le renforcement de TS-RS appartient au projet ou au futur skeleton Tauri',
+    'host SHOULD être une crate Cargo mixte directement lisible',
+):
+    assert phrase in rule, phrase
+for phrase in (
+    'TypeScript et Vite sont fortement recommandés',
+    'Bootstrap est la baseline de présentation privilégiée',
+    'MUST utiliser TS-RS',
+):
+    assert phrase not in rule, phrase
+
+study = Path('docs/studies/002-TAURI_SKELETON_DECISION.md').read_text(encoding='utf-8')
+assert study.startswith('<!-- file: docs/studies/002-TAURI_SKELETON_DECISION.md -->\n<!-- version: 3 -->')
+for phrase in (
+    '## Réexamen décisionnel `0.1.4-alpha.2`',
+    'DEFER historique pour absence d\'owners Web    LIFT',
+    'candidat organisationnel                      ADOPT FOR MATERIALIZATION',
+    'matérialisation visée                          alpha.3',
+    'Le `DEFER` de `0.0.5-alpha.9` reste conservé comme décision historique',
+):
+    assert phrase in study, phrase
+
+plan = Path('docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
+assert plan.startswith('<!-- file: docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md -->\n<!-- version: 2 -->')
+for phrase in (
+    '## Gate `alpha.1` acquise',
+    '## Réconciliation normative préparée en `alpha.2`',
+    '## Point transversal découvert pendant la gate `alpha.1`',
+    'forte recommandation non obligatoire',
+    'sans rechercher automatiquement une version PGR plus récente',
+    'howtos, recettes et snippets pratiques vivent dans Knowledge',
+    'revue d\'horizon',
+):
+    assert phrase in plan, phrase
+
+index = Path('docs/000-README.md').read_text(encoding='utf-8')
+assert index.startswith('<!-- file: docs/000-README.md -->\n<!-- version: 42 -->')
+assert 'owner Tauri 2 réconcilié en `alpha.2`' in index
+assert 'candidat organisationnel retenu pour matérialisation contrôlée en `alpha.3`' in index
+
+roadmap = Path('ROADMAP.md').read_text(encoding='utf-8')
+for phrase in (
+    '`( ) 0.1.4`',
+    '`( ) 0.1.5` — adoption réelle de PGR par `sasedev-games`',
+    '`( ) 0.1.6` — adoption réelle de PGR par `khadhroony-solana-project`',
+    '`( ) 0.1.7` — audits Python read-only',
+):
+    assert phrase in roadmap, phrase
+assert '0.1.8' not in roadmap
+
+assert not Path('docs/skeletons/004-TAURI.md').exists()
+assert not Path('history/0.1.4/alpha.2.md').exists()
+
+print(
+    '0.1.4 alpha.2 Tauri normative audit: clean '
+    '(ACL boundaries explicit, Web ownership separated, historical DEFER lifted, skeleton still deferred to alpha.3)'
+)
+PY
+
+git diff --check
+git add VERSION \
+    deltas/0.1.4/alpha.2.md \
+    docs/000-README.md \
+    docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md \
+    docs/rules/710-TAURI.md \
+    docs/studies/002-TAURI_SKELETON_DECISION.md
+git diff --cached --check
+git status --short
+```
+
+Le scope attendu du delta `alpha.2` est :
+
+```text
+M  VERSION
+A  deltas/0.1.4/alpha.2.md
+M  docs/000-README.md
+M  docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+M  docs/rules/710-TAURI.md
+M  docs/studies/002-TAURI_SKELETON_DECISION.md
+```

deltas/0.1.4/alpha.3.md

@@ -0,0 +1,202 @@
+<!-- file: deltas/0.1.4/alpha.3.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.4-alpha.3 — skeleton Tauri contrôlé
+
+## Précondition
+
+`0.1.4-alpha.2.fix.1` doit être committée avec son history `PASS` avant application de ce delta.
+
+Version après application :
+
+```text
+0.1.4-alpha.3
+```
+
+## Objet
+
+Matérialiser le skeleton Tauri 2 autorisé par les gates précédentes, sans créer de template technique universel ni absorber les owners Rust/Web/plateforme.
+
+La tranche corrige également le contrat de packaging des archives delta/history après l'observation opérateur d'un répertoire englobant `pgr/` dans deux ZIP remis : les entrées doivent désormais être directement relatives à la racine du dépôt.
+
+## Scope
+
+ADD :
+
+```text
+deltas/0.1.4/alpha.3.md
+docs/skeletons/004-TAURI.md
+```
+
+REPLACE :
+
+```text
+VERSION
+docs/000-README.md
+docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+docs/rules/210-WORKFLOW.md
+docs/skeletons/000-README.md
+```
+
+Aucun template Tauri, contrat de validation Tauri séparé, changement de roadmap ou adoption Games/KSP n'appartient à cette tranche.
+
+## Skeleton `004-TAURI`
+
+La nouvelle specification :
+
+- compose `001-PROJECT_GOVERNANCE_FOUNDATION`, `002-RUST_CARGO_WORKSPACE`, `003-WEB_FRONTEND` et `710-TAURI` ;
+- conserve `src-tauri/` comme layout valide pour un projet existant tout en recommandant une crate Cargo directement lisible pour une nouvelle baseline contrôlée ;
+- rend obligatoires les décisions de version, frontend, package manager, hooks, `devUrl`, `frontendDist`, capabilities, permissions, plugins, fenêtres, bundles et plateformes ;
+- distingue recommandations de baseline et options locales ;
+- garde WASM séparé par défaut ;
+- définit un ordre d'initialisation ;
+- définit une gate initiale séparant preuves Rust, frontend, intégration Tauri, packaging et plateforme ;
+- conclut qu'aucun template Tauri technique supplémentaire n'est actuellement justifié.
+
+## Packaging delta/history
+
+`docs/rules/210-WORKFLOW.md` passe en révision `9` et rend explicite que :
+
+```text
+archive.delta/history.zip
+├── VERSION          # si présent dans le delta
+├── docs/...
+├── deltas/...
+└── history/...
+```
+
+est valide, tandis que :
+
+```text
+archive.zip
+└── pgr/
+    ├── docs/...
+    └── history/...
+```
+
+est invalide pour le handoff canonique `unzip -o <archive> -d .`.
+
+Le générateur doit vérifier la liste des entrées du ZIP avant remise.
+
+## Gate opérateur
+
+Après commit/push du history `PASS` de `alpha.2.fix.1`, appliquer ce delta puis exécuter :
+
+```bash
+cat VERSION
+
+test -f history/0.1.4/alpha.2.fix.1.md
+grep -A2 '^## Statut$' history/0.1.4/alpha.2.fix.1.md | grep -Fx 'PASS'
+test -f deltas/0.1.4/alpha.3.md
+test -f docs/skeletons/004-TAURI.md
+test ! -e history/0.1.4/alpha.3.md
+
+python3 -B -m unittest discover -s tests -v
+
+python3 -B scripts/audit_text_hygiene.py \
+    VERSION README.md RULES.md ROADMAP.md CHANGELOG.md \
+    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
+
+python3 -B - <<'PY'
+from pathlib import Path
+import re
+
+assert Path('VERSION').read_text(encoding='utf-8').strip() == '0.1.4-alpha.3'
+
+history = Path('history/0.1.4/alpha.2.fix.1.md').read_text(encoding='utf-8')
+assert re.search(r'## Statut\s+PASS', history)
+
+skeleton = Path('docs/skeletons/004-TAURI.md').read_text(encoding='utf-8')
+assert skeleton.startswith(
+    '<!-- file: docs/skeletons/004-TAURI.md -->\n'
+    '<!-- version: 1 -->'
+)
+for phrase in (
+    '## Décisions obligatoires avant matérialisation',
+    '## Baseline organisationnelle recommandée',
+    '## Capabilities, permissions et commandes',
+    '## Ordre d\'initialisation',
+    '## Validation initiale',
+    '## Templates techniques',
+    'Aucun template Tauri technique supplémentaire n\'est requis',
+    'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER',
+):
+    assert phrase in skeleton, phrase
+
+for path, version in (
+    ('docs/rules/210-WORKFLOW.md', '9'),
+    ('docs/skeletons/000-README.md', '7'),
+    ('docs/000-README.md', '43'),
+    ('docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md', '3'),
+    ('docs/rules/710-TAURI.md', '7'),
+    ('docs/studies/002-TAURI_SKELETON_DECISION.md', '3'),
+):
+    lines = Path(path).read_text(encoding='utf-8').splitlines()
+    assert lines[1] == f'<!-- version: {version} -->', (path, lines[1])
+
+workflow = Path('docs/rules/210-WORKFLOW.md').read_text(encoding='utf-8')
+for phrase in (
+    'Les entrées des archives delta/history MUST utiliser directement les chemins relatifs à la racine du dépôt',
+    'MUST NOT ajouter un répertoire englobant portant le nom du projet',
+    'vérifier la liste des entrées du ZIP avant remise',
+):
+    assert phrase in workflow, phrase
+
+index = Path('docs/skeletons/000-README.md').read_text(encoding='utf-8')
+assert '[`004-TAURI.md`](004-TAURI.md)' in index
+
+doc_index = Path('docs/000-README.md').read_text(encoding='utf-8')
+assert '[`skeletons/004-TAURI.md`](skeletons/004-TAURI.md)' in doc_index
+
+assert not Path('history/0.1.4/alpha.3.md').exists()
+assert not Path('docs/templates/011-TAURI.md').exists()
+assert not Path('docs/validation/006-TAURI_VALIDATION.md').exists()
+
+print(
+    '0.1.4 alpha.3 skeleton audit: clean '
+    '(004 materialized, owners composed, no premature template/validation artifact, ZIP root contract explicit)'
+)
+PY
+
+git diff --check
+
+git add VERSION \
+    deltas/0.1.4/alpha.3.md \
+    docs/000-README.md \
+    docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md \
+    docs/rules/210-WORKFLOW.md \
+    docs/skeletons/000-README.md \
+    docs/skeletons/004-TAURI.md
+
+git diff --cached --check
+git status --short
+```
+
+Le scope attendu est :
+
+```text
+M  VERSION
+A  deltas/0.1.4/alpha.3.md
+M  docs/000-README.md
+M  docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+M  docs/rules/210-WORKFLOW.md
+M  docs/skeletons/000-README.md
+A  docs/skeletons/004-TAURI.md
+```
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.4/alpha.3.md`, commit/push sous l'identité `0.1.4-alpha.3`, puis ouvrir `beta.1` pour la réconciliation globale et la décision explicite sur les artefacts Tauri supplémentaires.
+
+### FAIL
+
+Enregistrer le résultat réel dans `history/0.1.4/alpha.3.md` et poursuivre sous `alpha.3.fix.N`. Ne pas ouvrir `beta.1` tant que la composition du skeleton et le scope ne sont pas propres.

deltas/0.1.4/beta.1.md

@@ -0,0 +1,189 @@
+<!-- file: deltas/0.1.4/beta.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.4-beta.1 — réconciliation des artefacts Tauri
+
+## Objet
+
+Fermer la phase de conception Tauri de `0.1.4` en réconciliant les artefacts matérialisés, en vérifiant leurs owners et en décidant explicitement de ne pas créer de template technique Tauri, de contrat de validation Tauri séparé ou de dry-run factice en l'absence de lacune démontrée.
+
+## Préconditions
+
+- `0.1.4-alpha.3` est validée `PASS` et son history est présent ;
+- `docs/skeletons/004-TAURI.md` est matérialisé ;
+- `docs/rules/710-TAURI.md` reste l'owner Tauri en révision interne `7` ;
+- aucun `docs/templates/011-TAURI.md` ni `docs/validation/006-TAURI_VALIDATION.md` n'existe ;
+- les archives delta/history restent relatives directement à la racine du dépôt.
+
+## Modifications
+
+- `VERSION` passe à `0.1.4-beta.1` ;
+- `docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md` passe en révision `4` et enregistre la gate `alpha.3` ainsi que les décisions d'artefacts de `beta.1` ;
+- `docs/studies/002-TAURI_SKELETON_DECISION.md` passe en révision `4` et ferme explicitement la décision sur template, validation séparée et dry-run ;
+- `docs/000-README.md` passe en révision `44` et indexe l'état `beta.1` ;
+- aucun nouvel owner, template ou contrat de validation Tauri n'est créé.
+
+## Décision attendue
+
+```text
+004-TAURI.md                                  KEEP
+template technique Tauri générique           DO NOT CREATE
+006-TAURI_VALIDATION.md                       DO NOT CREATE
+dry-run exécutable d'un faux projet           NOT REQUIRED
+audit statique de composition                 REQUIRED
+```
+
+L'absence d'artefact supplémentaire est une décision positive : un fichier nouveau n'est justifié que s'il possède une responsabilité réutilisable non déjà couverte.
+
+## Gate opérateur
+
+```bash
+cat VERSION
+
+test -f history/0.1.4/alpha.3.md
+grep -A2 '^## Statut$' history/0.1.4/alpha.3.md | grep -Fx 'PASS'
+
+test -f docs/skeletons/004-TAURI.md
+test ! -e docs/templates/011-TAURI.md
+test ! -e docs/validation/006-TAURI_VALIDATION.md
+test ! -e history/0.1.4/beta.1.md
+
+python3 -B -m unittest discover -s tests -v
+
+python3 -B scripts/audit_text_hygiene.py \
+    VERSION README.md RULES.md ROADMAP.md CHANGELOG.md \
+    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
+
+python3 -B - <<'PY'
+from pathlib import Path
+import re
+
+assert Path('VERSION').read_text(encoding='utf-8').strip() == '0.1.4-beta.1'
+
+history = Path('history/0.1.4/alpha.3.md').read_text(encoding='utf-8')
+assert re.search(r'## Statut\s+PASS', history)
+
+expected_deltas = {
+    'alpha.1.md',
+    'alpha.2.md',
+    'alpha.2.fix.1.md',
+    'alpha.3.md',
+    'beta.1.md',
+}
+expected_histories = {
+    'alpha.1.md',
+    'alpha.2.md',
+    'alpha.2.fix.1.md',
+    'alpha.3.md',
+}
+assert {p.name for p in Path('deltas/0.1.4').glob('*.md')} == expected_deltas
+assert {p.name for p in Path('history/0.1.4').glob('*.md')} == expected_histories
+
+plan = Path('docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
+assert plan.startswith(
+    '<!-- file: docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md -->\n'
+    '<!-- version: 4 -->'
+)
+for phrase in (
+    '## Gate `alpha.3` acquise',
+    "## Réconciliation d'artefacts préparée en `beta.1`",
+    'template technique Tauri générique           DO NOT CREATE',
+    '006-TAURI_VALIDATION.md                       DO NOT CREATE',
+    "dry-run exécutable d'un faux projet           NOT REQUIRED",
+    'audit statique de composition                 REQUIRED',
+):
+    assert phrase in plan, phrase
+
+study = Path('docs/studies/002-TAURI_SKELETON_DECISION.md').read_text(encoding='utf-8')
+assert study.startswith(
+    '<!-- file: docs/studies/002-TAURI_SKELETON_DECISION.md -->\n'
+    '<!-- version: 4 -->'
+)
+for phrase in (
+    '## Réconciliation finale des artefacts `0.1.4-beta.1`',
+    'Décision : **DO NOT CREATE**.',
+    'Décision : **NOT REQUIRED** pour `0.1.4-beta.1`.',
+    '004-TAURI.md                                  KEEP',
+    'template Tauri générique                     DO NOT CREATE',
+    'validation Tauri séparée                     DO NOT CREATE',
+    'artefact supplémentaire sans lacune réelle   FORBIDDEN BY DEFAULT',
+):
+    assert phrase in study, phrase
+
+skeleton = Path('docs/skeletons/004-TAURI.md').read_text(encoding='utf-8')
+for ref in (
+    '001-PROJECT_GOVERNANCE_FOUNDATION',
+    '002-RUST_CARGO_WORKSPACE',
+    '003-WEB_FRONTEND',
+    '710 TAURI',
+):
+    assert ref in skeleton, ref
+
+for path in (
+    'docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md',
+    'docs/skeletons/002-RUST_CARGO_WORKSPACE.md',
+    'docs/skeletons/003-WEB_FRONTEND.md',
+    'docs/rules/710-TAURI.md',
+    'docs/validation/005-WEB_FRONTEND_VALIDATION.md',
+):
+    assert Path(path).is_file(), path
+
+assert not Path('docs/templates/011-TAURI.md').exists()
+assert not Path('docs/validation/006-TAURI_VALIDATION.md').exists()
+assert not Path('history/0.1.4/beta.1.md').exists()
+
+index = Path('docs/000-README.md').read_text(encoding='utf-8')
+assert index.startswith(
+    '<!-- file: docs/000-README.md -->\n'
+    '<!-- version: 44 -->'
+)
+assert '`004-TAURI.md` suffit' in index
+
+roadmap = Path('ROADMAP.md').read_text(encoding='utf-8')
+for phrase in (
+    '`( ) 0.1.4`',
+    '`( ) 0.1.5` — adoption réelle de PGR par `sasedev-games`',
+    '`( ) 0.1.6` — adoption réelle de PGR par `khadhroony-solana-project`',
+    '`( ) 0.1.7` — audits Python read-only',
+):
+    assert phrase in roadmap, phrase
+assert '0.1.8' not in roadmap
+
+print(
+    '0.1.4 beta.1 artifact audit: clean '
+    '(004 sufficient, ownership composed, no redundant template/validation contract, no fake dry-run)'
+)
+PY
+
+git diff --check
+
+git add VERSION \
+    deltas/0.1.4/beta.1.md \
+    docs/000-README.md \
+    docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md \
+    docs/studies/002-TAURI_SKELETON_DECISION.md
+
+git diff --cached --check
+git status --short
+```
+
+## Scope Git attendu
+
+```text
+M  VERSION
+A  deltas/0.1.4/beta.1.md
+M  docs/000-README.md
+M  docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+M  docs/studies/002-TAURI_SKELETON_DECISION.md
+```
+
+## Suite
+
+Si la gate est `PASS`, produire `history/0.1.4/beta.1.md`, committer/pousser la tranche puis préparer `rc.1` avec freeze Tauri, changelog candidate et revue d'horizon transversale avant génération du prochain start prompt.

deltas/0.1.4/rc.1.md

@@ -0,0 +1,203 @@
+<!-- file: deltas/0.1.4/rc.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.4-rc.1 — freeze Tauri et revue d’horizon
+
+## Objet
+
+Geler le scope Tauri validé par `beta.1`, préparer le changelog candidat et exécuter la revue d’horizon transversale exigée par le plan avant de générer le prochain start prompt.
+
+La RC ne corrige pas encore la sémantique `SHOULD`, le contrat d’autonomie ou la frontière PGR / Knowledge : elle décide explicitement qu’ils forment la prochaine release `0.1.5` et décale les adoptions Games/KSP afin qu’elles utilisent ensuite ce contrat stabilisé.
+
+## Préconditions
+
+- `0.1.4-beta.1` est validée `PASS` et son history est présent ;
+- `710-TAURI.md` reste en révision `7` et `004-TAURI.md` en révision `1` ;
+- aucun template technique Tauri ni `006-TAURI_VALIDATION.md` n’est requis ;
+- les trois questions transversales enregistrées dans le plan doivent être décidées avant création du prompt suivant ;
+- les archives delta/history restent relatives directement à la racine du dépôt.
+
+## Modifications
+
+- `VERSION` passe à `0.1.4-rc.1` ;
+- `CHANGELOG.md` reçoit l’entrée `0.1.4 (candidate)` sans chronologie de tranches ;
+- `ROADMAP.md` enregistre la revue d’horizon : `0.1.5` gouvernance/autonomie, `0.1.6` Games, `0.1.7` KSP, `0.1.8` audits Rust ;
+- `docs/studies/004-V0_1_4_HORIZON_REVIEW.md` matérialise la décision et ses limites ;
+- `prompts/011-V0_1_5_START_PROMPT.md` prépare la prochaine release à partir d’une future stable `v0.1.4` réellement publiée ;
+- le plan et les index sont mis à jour pour refléter le freeze et le handoff ;
+- aucun owner normatif transversal n’est encore modifié en RC.
+
+## Gate opérateur
+
+```bash
+cat VERSION
+
+test -f history/0.1.4/beta.1.md
+grep -A2 '^## Statut$' history/0.1.4/beta.1.md | grep -Fx 'PASS'
+
+test -f docs/studies/004-V0_1_4_HORIZON_REVIEW.md
+test -f prompts/011-V0_1_5_START_PROMPT.md
+test ! -e history/0.1.4/rc.1.md
+
+grep -Fx '<!-- version: 18 -->' CHANGELOG.md
+grep -Fx '<!-- version: 16 -->' ROADMAP.md
+grep -Fx '<!-- version: 45 -->' docs/000-README.md
+grep -Fx '<!-- version: 5 -->' docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+grep -Fx '<!-- version: 5 -->' docs/studies/000-README.md
+grep -Fx '<!-- version: 1 -->' docs/studies/004-V0_1_4_HORIZON_REVIEW.md
+grep -Fx '<!-- version: 1 -->' prompts/011-V0_1_5_START_PROMPT.md
+
+python3 -B - <<'PYGATE'
+from pathlib import Path
+import re
+
+assert Path('VERSION').read_text(encoding='utf-8').strip() == '0.1.4-rc.1'
+
+expected_statuses = {
+    'alpha.1.md': 'PASS',
+    'alpha.2.md': 'FAIL',
+    'alpha.2.fix.1.md': 'PASS',
+    'alpha.3.md': 'PASS',
+    'beta.1.md': 'PASS',
+}
+for name, status in expected_statuses.items():
+    delta = Path('deltas/0.1.4', name)
+    history = Path('history/0.1.4', name)
+    assert delta.is_file(), name
+    assert history.is_file(), name
+    text = history.read_text(encoding='utf-8')
+    assert re.search(rf'## Statut\s+{status}\s', text), (name, status)
+
+pending = {p.name for p in Path('deltas/0.1.4').glob('*.md')} - {
+    p.name for p in Path('history/0.1.4').glob('*.md')
+}
+assert pending == {'rc.1.md'}, pending
+
+for path, version in (
+    ('docs/rules/710-TAURI.md', 7),
+    ('docs/skeletons/004-TAURI.md', 1),
+    ('docs/studies/002-TAURI_SKELETON_DECISION.md', 4),
+    ('RULES.md', 14),
+    ('docs/rules/230-ADOPTION.md', 1),
+    ('docs/rules/400-VALIDATION.md', 1),
+):
+    lines = Path(path).read_text(encoding='utf-8').splitlines()
+    assert lines[1] == f'<!-- version: {version} -->', (path, lines[1])
+
+changelog = Path('CHANGELOG.md').read_text(encoding='utf-8')
+assert '## 0.1.4 (candidate)' in changelog
+section = changelog.split('## 0.1.4 (candidate)', 1)[1].split('## 0.1.3', 1)[0]
+for phrase in (
+    'skeleton Tauri',
+    'commandes, permissions et capabilities',
+    '004-TAURI.md',
+    'audit réutilisable d’hygiène texte',
+    '0.1.5',
+    '0.1.8',
+):
+    assert phrase in section, phrase
+for forbidden in ('alpha.1', 'alpha.2', 'alpha.3', 'beta.1', 'rc.1', 'rel.1'):
+    assert forbidden not in section, forbidden
+
+roadmap = Path('ROADMAP.md').read_text(encoding='utf-8')
+for phrase in (
+    '`( ) 0.1.4` — domaine Tauri',
+    '`( ) 0.1.5` — sémantique normative et autonomie',
+    '`( ) 0.1.6` — adoption réelle de PGR par `sasedev-games`',
+    '`( ) 0.1.7` — adoption réelle de PGR par `khadhroony-solana-project`',
+    '`( ) 0.1.8` — audits Python read-only',
+):
+    assert phrase in roadmap, phrase
+assert '`( ) 0.1.9`' not in roadmap
+assert "skeleton Tauri jusqu'au réexamen 0.1.4" not in roadmap
+
+study = Path('docs/studies/004-V0_1_4_HORIZON_REVIEW.md').read_text(encoding='utf-8')
+for phrase in (
+    'forte recommandation',
+    'MUST NOT faire échouer à lui seul une gate',
+    'baseline locale du projet',
+    'règles locales = autorité des sessions/releases suivantes',
+    'PGR MUST rester auto-suffisant',
+    'une release de gouvernance/autonomie doit précéder les adoptions Games/KSP',
+    '0.1.8   audits Rust/Clippy read-only',
+):
+    assert phrase in study, phrase
+
+prompt = Path('prompts/011-V0_1_5_START_PROMPT.md').read_text(encoding='utf-8')
+for phrase in (
+    'tag Gitea `v0.1.4`',
+    'pgr-0.1.4-publish.001-report.md',
+    '0.1.5-alpha.1',
+    '004-V0_1_4_HORIZON_REVIEW.md',
+    'forte recommandation non obligatoire',
+    'ne doivent ni rechercher automatiquement « la dernière version de PGR »',
+    'SaseDev Knowledge',
+    'réservée à `0.1.6`',
+    'réservée à `0.1.7`',
+    'réservés à `0.1.8`',
+):
+    assert phrase in prompt, phrase
+
+plan = Path('docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
+for phrase in (
+    '## Gate `beta.1` acquise',
+    '## Revue d’horizon préparée en `rc.1`',
+    '0.1.5   sémantique normative + autonomie + frontière PGR/Knowledge',
+    'Le prompt `011` transmet explicitement leur réexamen à `0.1.5-alpha.1`.',
+):
+    assert phrase in plan, phrase
+
+assert not Path('docs/templates/011-TAURI.md').exists()
+assert not Path('docs/validation/006-TAURI_VALIDATION.md').exists()
+assert not Path('history/0.1.4/rc.1.md').exists()
+
+print(
+    '0.1.4 rc.1 integration audit: clean '
+    '(beta PASS, Tauri frozen, horizon reordered to governance 0.1.5 before Games/KSP, prompt 011 verified)'
+)
+PYGATE
+
+python3 -B -m unittest discover -s tests -v
+
+python3 -B scripts/audit_text_hygiene.py \
+    VERSION README.md RULES.md ROADMAP.md CHANGELOG.md \
+    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 add VERSION CHANGELOG.md ROADMAP.md \
+    deltas/0.1.4/rc.1.md \
+    docs/000-README.md \
+    docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md \
+    docs/studies/000-README.md \
+    docs/studies/004-V0_1_4_HORIZON_REVIEW.md \
+    prompts/011-V0_1_5_START_PROMPT.md
+
+git diff --cached --check
+git status --short
+```
+
+## Scope Git attendu
+
+```text
+M  CHANGELOG.md
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.4/rc.1.md
+M  docs/000-README.md
+M  docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+M  docs/studies/000-README.md
+A  docs/studies/004-V0_1_4_HORIZON_REVIEW.md
+A  prompts/011-V0_1_5_START_PROMPT.md
+```
+
+## Transition
+
+Si la gate est `PASS`, produire `history/0.1.4/rc.1.md`, committer/pousser `0.1.4-rc.1`, puis préparer la promotion mécanique `rel.1` sans rouvrir le scope Tauri ni commencer `0.1.5`.

deltas/0.1.4/rel.1.md

@@ -0,0 +1,233 @@
+<!-- file: deltas/0.1.4/rel.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.4 rel.1 — promotion stable pré-tag
+
+## Baseline et version
+
+Baseline : `0.1.4-rc.1`, avec `history/0.1.4/rc.1.md` appliqué et committé. Ce delta MUST NOT être appliqué avant ce commit.
+
+Version avant application :
+
+```text
+0.1.4-rc.1
+```
+
+Version après application :
+
+```text
+0.1.4
+```
+
+`rel.1` identifie la clôture opérationnelle ; il ne fait pas partie de la version SemVer du produit.
+
+## Objet
+
+Promouvoir mécaniquement la RC validée vers la stable `0.1.4` sans rouvrir le scope Tauri et sans commencer `0.1.5`.
+
+La tranche finalise uniquement la présentation et les métadonnées de release : version stable, roadmap terminée, changelog sans marqueur `candidate`, README/index en état stable et plan `010` historique. Aucun owner Tauri, skeleton, étude technique, audit Python ou règle normative réservée à `0.1.5` n'est modifié.
+
+La validation de cette tranche est **pré-tag**. Le tag `v0.1.4`, son archive source Gitea et le rapport `pgr-0.1.4-publish.001-report.md` ne sont pas déclarés existants par ce delta. Ils suivent uniquement un history `rel.1` `PASS`, le commit stable `0.1.4` et la publication réelle du tag.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+README.md
+ROADMAP.md
+CHANGELOG.md
+docs/000-README.md
+docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+```
+
+ADD :
+
+```text
+deltas/0.1.4/rel.1.md
+```
+
+DELETE : aucun.
+
+Le history `rc.1` est livré séparément. Le history `rel.1` sera produit uniquement après la gate opérateur.
+
+## Validation opérateur pré-tag
+
+Après application sur le commit contenant `history/0.1.4/rc.1.md` :
+
+```bash
+test "$(cat VERSION)" = '0.1.4'
+git cat-file -e HEAD:history/0.1.4/rc.1.md
+test -f history/0.1.4/rc.1.md
+test -f deltas/0.1.4/rel.1.md
+test -f prompts/011-V0_1_5_START_PROMPT.md
+test ! -e history/0.1.4/rel.1.md
+
+grep -A2 '^## Statut$' history/0.1.4/rc.1.md | grep -Fx 'PASS'
+grep -Fx '<!-- version: 27 -->' README.md
+grep -Fx '<!-- version: 17 -->' ROADMAP.md
+grep -Fx '<!-- version: 19 -->' CHANGELOG.md
+grep -Fx '<!-- version: 46 -->' docs/000-README.md
+grep -Fx '<!-- version: 6 -->' docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+grep -F -- '- `(x) 0.1.4`' ROADMAP.md
+grep -Fx '## 0.1.4' CHANGELOG.md
+grep -F 'La stable `0.1.4` réexamine le domaine Tauri' README.md
+grep -F 'plan historique de la stable `0.1.4`' docs/000-README.md
+
+python3 -B - <<'PYGATE'
+from pathlib import Path
+import re
+
+expected = {
+    'alpha.1.md': 'PASS',
+    'alpha.2.md': 'FAIL',
+    'alpha.2.fix.1.md': 'PASS',
+    'alpha.3.md': 'PASS',
+    'beta.1.md': 'PASS',
+    'rc.1.md': 'PASS',
+}
+
+for name, status in expected.items():
+    delta = Path('deltas/0.1.4', name)
+    history = Path('history/0.1.4', name)
+    assert delta.is_file(), name
+    assert history.is_file(), name
+    text = history.read_text(encoding='utf-8')
+    assert re.search(rf'## Statut\s+{status}\s', text), (name, status)
+
+pending = {path.name for path in Path('deltas/0.1.4').glob('*.md')} - {
+    path.name for path in Path('history/0.1.4').glob('*.md')
+}
+assert pending == {'rel.1.md'}, pending
+
+roadmap = Path('ROADMAP.md').read_text(encoding='utf-8')
+assert '- `(x) 0.1.4`' in roadmap
+for version in ('0.1.5', '0.1.6', '0.1.7', '0.1.8'):
+    assert f'- `( ) {version}`' in roadmap, version
+assert '- `( ) 0.1.9`' not in roadmap
+
+changelog = Path('CHANGELOG.md').read_text(encoding='utf-8')
+assert '## 0.1.4' in changelog.splitlines()
+assert '## 0.1.4 (candidate)' not in changelog
+section = changelog.split('## 0.1.4', 1)[1].split('## 0.1.3', 1)[0]
+for phrase in (
+    'skeleton Tauri',
+    'commandes, permissions et capabilities',
+    '004-TAURI.md',
+    'audit réutilisable d’hygiène texte',
+    '0.1.5',
+    '0.1.8',
+):
+    assert phrase in section, phrase
+for forbidden in ('alpha.1', 'alpha.2', 'alpha.3', 'beta.1', 'rc.1', 'rel.1'):
+    assert forbidden not in section, forbidden
+
+readme = Path('README.md').read_text(encoding='utf-8')
+for phrase in (
+    'La stable `0.1.4` réexamine le domaine Tauri',
+    'skeleton organisationnel `004-TAURI.md`',
+    'audit réutilisable d’hygiène texte',
+    '0.1.5',
+    '0.1.6',
+    '0.1.7',
+):
+    assert phrase in readme, phrase
+
+index = Path('docs/000-README.md').read_text(encoding='utf-8')
+assert 'plan historique de la stable `0.1.4`' in index
+assert 'handoff de la stable `0.1.4` vers `0.1.5-alpha.1`' in index
+
+plan = Path('docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md').read_text(encoding='utf-8')
+for phrase in (
+    'Plan historique de la stable `0.1.4`',
+    '## Gate `rc.1` acquise et promotion stable',
+    'history/0.1.4/rel.1.md',
+    'pgr-0.1.4-publish.001-report.md',
+    'commit stable `0.1.4`',
+):
+    assert phrase in plan, phrase
+
+prompt = Path('prompts/011-V0_1_5_START_PROMPT.md').read_text(encoding='utf-8')
+for phrase in (
+    'tag Gitea `v0.1.4`',
+    'pgr-0.1.4-publish.001-report.md',
+    '0.1.5-alpha.1',
+    '004-V0_1_4_HORIZON_REVIEW.md',
+    'forte recommandation non obligatoire',
+    'SaseDev Knowledge',
+    'réservée à `0.1.6`',
+    'réservée à `0.1.7`',
+    'réservés à `0.1.8`',
+):
+    assert phrase in prompt, phrase
+
+for path, version in (
+    ('docs/rules/710-TAURI.md', 7),
+    ('docs/skeletons/004-TAURI.md', 1),
+    ('docs/studies/002-TAURI_SKELETON_DECISION.md', 4),
+    ('docs/studies/004-V0_1_4_HORIZON_REVIEW.md', 1),
+    ('RULES.md', 14),
+    ('docs/rules/230-ADOPTION.md', 1),
+    ('docs/rules/400-VALIDATION.md', 1),
+):
+    lines = Path(path).read_text(encoding='utf-8').splitlines()
+    assert lines[1] == f'<!-- version: {version} -->', (path, lines[1])
+
+assert not Path('docs/templates/011-TAURI.md').exists()
+assert not Path('docs/validation/006-TAURI_VALIDATION.md').exists()
+
+print(
+    '0.1.4 rel.1 stable gate audit: clean '
+    '(6 prior histories including expected alpha.2 FAIL/fix PASS, rel.1 pending, stable Tauri presentation and 0.1.5 handoff coherent)'
+)
+PYGATE
+
+python3 -B -m unittest discover -s tests -v
+
+python3 -B scripts/audit_text_hygiene.py \
+    VERSION README.md RULES.md ROADMAP.md CHANGELOG.md \
+    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 add VERSION README.md ROADMAP.md CHANGELOG.md \
+    deltas/0.1.4/rel.1.md \
+    docs/000-README.md \
+    docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+
+git diff --cached --check
+git status --short
+```
+
+## Scope Git attendu
+
+```text
+M  CHANGELOG.md
+M  README.md
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.4/rel.1.md
+M  docs/000-README.md
+M  docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+```
+
+## Transition après PASS
+
+Si cette gate pré-tag est `PASS` :
+
+1. produire `history/0.1.4/rel.1.md` avec les preuves opérateur réelles ;
+2. appliquer ce history ;
+3. `git add -A`, `git diff --cached --check`, puis committer **`0.1.4`** sans suffixe `rel.1` ;
+4. pousser `master` ;
+5. vérifier un workspace propre ;
+6. créer et pousser le tag annoté `v0.1.4` ;
+7. télécharger l'archive Gitea du tag et produire `pgr-0.1.4-publish.001-report.md` après vérification indépendante ;
+8. seulement après `publish.001 PASS`, ouvrir la session `0.1.5` avec `prompts/011-V0_1_5_START_PROMPT.md`.

deltas/0.1.5/alpha.1.fix.1.md

@@ -0,0 +1,125 @@
+<!-- file: deltas/0.1.5/alpha.1.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.5-alpha.1.fix.1 — acquisition des preuves manquantes de la gate d'ouverture
+
+## Baseline
+
+Version attendue avant application :
+
+```text
+0.1.5-alpha.1
+```
+
+Le history `history/0.1.5/alpha.1.md` avec statut `PARTIAL` MUST avoir été appliqué, committé et poussé avant ce delta.
+
+Version après application :
+
+```text
+0.1.5-alpha.1.fix.1
+```
+
+## Objet
+
+Résoudre uniquement le résultat `PARTIAL` de `alpha.1` en exécutant les preuves exigées par sa gate mais absentes du transcript opérateur.
+
+Aucun défaut normatif, documentaire ou structurel n'est établi par `alpha.1`. Le présent fix ne réécrit donc pas son contenu, ne modifie aucun owner et ne commence pas `alpha.2`.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+```
+
+ADD :
+
+```text
+deltas/0.1.5/alpha.1.fix.1.md
+```
+
+DELETE : aucun.
+
+## Preuves à acquérir
+
+Le fix doit confirmer dans l'environnement opérateur :
+
+- la trajectoire vivante `0.1.4` terminé puis `0.1.5` à `0.1.8`, sans réservation `0.1.9` ;
+- les `103` couples delta/history historiques de `0.0.1` à `0.1.4`, plus le couple `0.1.5-alpha.1` désormais clôturé et le delta courant encore sans history ;
+- les contrats du prompt `011` sur `SHOULD`, l'autonomie post-adoption et les scopes réservés ;
+- les constats structurants du plan `011` et la séparation des tranches `alpha.2`, `alpha.3` et `alpha.4` ;
+- l'hygiène du nouveau delta et le scope Git strictement limité au fix.
+
+Les `55/55` tests Python, l'hygiène texte et les audits Markdown complets de `alpha.1` sont déjà des preuves opérateur acquises. Le fix ne modifie aucun code ni script ; il ne rejoue donc pas la suite Python par simple répétition. Les audits texte/Markdown sont toutefois rejoués pour valider le nouvel artefact documentaire.
+
+## Validation opérateur
+
+Exécuter depuis la racine du dépôt après commit/push de `alpha.1` puis application du présent delta :
+
+```bash
+cat VERSION
+
+test -f history/0.1.5/alpha.1.md
+test -f deltas/0.1.5/alpha.1.fix.1.md
+test ! -e history/0.1.5/alpha.1.fix.1.md
+
+grep -Fx '0.1.5-alpha.1.fix.1' VERSION
+grep -A2 '^## Statut$' history/0.1.5/alpha.1.md | grep -Fx 'PARTIAL'
+
+grep -F -- '- `(x) 0.1.4`' ROADMAP.md
+grep -F -- '- `( ) 0.1.5`' ROADMAP.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'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md'}; print('0.1.5 alpha.1.fix.1 history boundary: clean (104 closed prior pairs, current fix pending)')"
+
+grep -F 'forte recommandation non obligatoire' prompts/011-V0_1_5_START_PROMPT.md
+grep -F 'ne doivent ni rechercher automatiquement « la dernière version de PGR »' prompts/011-V0_1_5_START_PROMPT.md
+grep -F 'réservée à `0.1.6`' prompts/011-V0_1_5_START_PROMPT.md
+grep -F 'réservée à `0.1.7`' prompts/011-V0_1_5_START_PROMPT.md
+grep -F 'réservés à `0.1.8`' prompts/011-V0_1_5_START_PROMPT.md
+
+grep -F '29` fichiers' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F '242` occurrences' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F '### `alpha.2` — sémantique normative et conséquences de gate/adoption' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F '### `alpha.3` — autonomie locale et réalignement volontaire' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F '### `alpha.4` — frontière PGR / SaseDev Knowledge' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+
+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 deltas/0.1.5/alpha.1.fix.1.md
+
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history du fix est :
+
+```text
+M  VERSION
+A  deltas/0.1.5/alpha.1.fix.1.md
+```
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.5/alpha.1.fix.1.md`, appliquer ce history puis committer/pusher `0.1.5-alpha.1.fix.1`. Préparer ensuite `0.1.5-alpha.2` conformément au plan, sans réouvrir les scopes autonomie `alpha.3` ou Knowledge `alpha.4`.
+
+### FAIL / PARTIAL / BLOCKED
+
+Consigner le résultat réellement observé dans `history/0.1.5/alpha.1.fix.1.md` et rester dans `alpha.1.fix.M` tant que les preuves d'ouverture ne sont pas complètement acquises, sauf REPLAN si un défaut plus large est démontré.

deltas/0.1.5/alpha.1.md

@@ -0,0 +1,222 @@
+<!-- file: deltas/0.1.5/alpha.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.5-alpha.1 — intake, audit transversal et plan d’autonomie
+
+## Objet
+
+Ouvrir `0.1.5` conformément à `prompts/011-V0_1_5_START_PROMPT.md`, rejouer la stable `0.1.4`, conserver son histoire réelle et matérialiser l’inventaire des ambiguïtés avant toute modification normative.
+
+La tranche ne modifie aucune règle, aucun skeleton ni template normatif. Elle ne commence ni l’adoption Games `0.1.6`, ni l’adoption KSP `0.1.7`, ni les audits Rust/Clippy `0.1.8`.
+
+## Sources vérifiées avant préparation
+
+```text
+pgr-v0.1.4(1).zip
+SHA-256  9f85ac16a5ad9fd788df51883b6ebf592602c5189d94e338a86edab2288b8f77
+CRC      PASS
+contenu  310 fichiers + 44 répertoires sous pgr/
+
+pgr-0.1.4-publish.001-report.md
+SHA-256  bb0c27a69e78037328d13c7be8df255d17f55e1392f1bc1b6121dd32b6fb07da
+status   PASS
+stable   c41b69badfd10ef9500d4cc4061fc6f66644352c
+```
+
+Le SHA de l’archive reçue correspond au SHA canonique vérifié lors de la publication post-tag. L’absence de `.git` dans l’archive est normale pour l’export du tag et n’est pas interprétée comme un défaut.
+
+## Replay de la stable
+
+La baseline extraite a été vérifiée avant toute préparation de delta :
+
+```text
+VERSION                           0.1.4
+tests Python                      55/55 PASS
+hygiène texte                     309 fichiers PASS
+headers Markdown                  282 fichiers PASS
+tables Markdown                   11 tables / 282 fichiers PASS
+liens Markdown                    357 liens locaux / 282 fichiers PASS
+JSON                              2 fichiers parsés
+TOML                              5 fichiers parsés
+deltas                            103
+histories                         103
+appariement historique            exact
+```
+
+La séquence `0.1.4` publiée est explicitement conservée :
+
+```text
+alpha.1          PASS
+alpha.2          FAIL
+alpha.2.fix.1    PASS
+alpha.3          PASS
+beta.1           PASS
+rc.1             PASS
+rel.1            PASS
+```
+
+Aucun history n’est réécrit pour rendre la chronologie artificiellement linéaire.
+
+## Résultats de l’audit transversal
+
+Le corpus courant contient `29` fichiers avec au moins un `SHOULD` ou `SHOULD NOT`, pour `242` occurrences brutes. Cette volumétrie confirme qu’une conversion mécanique serait incorrecte : la majorité des recommandations restent valides et doivent hériter d’un contrat global clarifié.
+
+Les ambiguïtés confirmées sont consignées dans `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`.
+
+### Force normative
+
+- `RULES.md` peut faire comprendre qu’un écart à `SHOULD` doit être systématiquement justifié ;
+- `230-ADOPTION.md` peut faire comprendre qu’un choix différent d’un `SHOULD` nécessite automatiquement `OVERRIDE` ;
+- `400-VALIDATION.md` ne protège pas encore explicitement une gate contre l’échec fondé sur le seul écart à une recommandation ;
+- plusieurs owners Web matérialisent cette ambiguïté par une justification ou un `OVERRIDE` rendu obligatoire autour d’une recommandation.
+
+### Autonomie
+
+Les objectifs, l’architecture, les skeletons et les patterns d’adoption contiennent déjà le principe d’autonomie, mais le contrat « baseline locale = autorité des sessions/releases suivantes » n’est pas encore propagé explicitement partout. PGR doit aussi cesser d’être interprétable comme upstream documentaire vivant après l’adoption.
+
+`210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` sont classés `KEEP / REVIEW` à ce stade : ils utilisent déjà la baseline autoritaire du projet courant plutôt qu’une version PGR externe.
+
+### Frontière PGR / Knowledge
+
+`001-PROJECT_OBJECTIVES.md` et `002-GOVERNANCE_ARCHITECTURE.md` parlent encore de skeletons comme de « recettes Markdown ». Cette terminologie brouille la frontière décidée en `0.1.4`, où les recettes pratiques deviennent des candidats à Knowledge tandis qu’un skeleton PGR reste une spécification de composition.
+
+`300-DOCUMENTATION.md` est proposé comme owner de la taxonomie ; aucun nouvel owner Knowledge n’est créé pendant `alpha.1`.
+
+### Cohérence d’horizon
+
+`docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` contient encore une référence vivante à l’adoption Games `0.1.5`. La trajectoire autoritaire issue de la revue `0.1.4` réserve maintenant Games à `0.1.6`, KSP à `0.1.7` et les audits Rust/Clippy à `0.1.8`.
+
+La correction appartient à la réconciliation normative suivante. Les références historiques qui décrivent correctement un horizon antérieur ne doivent pas être réécrites.
+
+## Modifications de la tranche
+
+- `VERSION` passe à `0.1.5-alpha.1` ;
+- `README.md` annonce l’ouverture de l’audit transversal et référence le plan actif ;
+- `docs/000-README.md` ajoute les points d’entrée actifs de `0.1.5` ;
+- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` consigne preuves, ambiguïtés, owners et trajectoire ;
+- le présent delta décrit la gate opérateur.
+
+`ROADMAP.md`, `CHANGELOG.md`, `RULES.md`, `docs/rules/`, `docs/skeletons/` et `docs/templates/` restent normativement inchangés pendant cette tranche d’ouverture.
+
+## Décision de tranche
+
+```text
+baseline 0.1.4                         VERIFIED
+history 0.1.4 alpha.2 FAIL             PRESERVED
+inventaire transversal                 COMPLETE
+conversion mécanique des SHOULD        REJECTED
+owners ciblés                          IDENTIFIED
+règles modifiées en alpha.1             NO
+Games / KSP / audits Rust commencés     NO
+prochaine tranche                       alpha.2 — sémantique normative et gates/adoption
+```
+
+## Trajectoire retenue
+
+```text
+alpha.1   intake + audit transversal + plan
+alpha.2   sémantique MUST/SHOULD/MAY + gates/adoption + cas concrets
+alpha.3   autonomie locale + réalignement PGR volontaire
+alpha.4   frontière PGR / SaseDev Knowledge
+beta.1    réconciliation transversale
+rc.1      freeze + handoff
+rel.1     promotion stable
+```
+
+Le découpage peut être ajusté uniquement si une gate révèle un défaut réel ou si deux owners ne peuvent pas être corrigés proprement dans la même tranche.
+
+## Gate opérateur
+
+Appliquer le delta puis exécuter depuis la racine du dépôt :
+
+```bash
+cat VERSION
+
+test -f docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+test -f deltas/0.1.5/alpha.1.md
+test ! -e history/0.1.5/alpha.1.md
+
+grep -Fx '0.1.5-alpha.1' VERSION
+grep -A2 '^## Statut$' history/0.1.4/alpha.2.md | grep -Fx 'FAIL'
+grep -A2 '^## Statut$' history/0.1.4/alpha.2.fix.1.md | grep -Fx 'PASS'
+grep -A2 '^## Statut$' history/0.1.4/rel.1.md | grep -Fx 'PASS'
+
+grep -F -- '- `(x) 0.1.4`' ROADMAP.md
+grep -F -- '- `( ) 0.1.5`' ROADMAP.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 -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
+
+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 Path('deltas/0.1.5/alpha.1.md').is_file(); assert not Path('history/0.1.5/alpha.1.md').exists(); print('0.1.5 alpha.1 history boundary: clean (103 prior pairs, current delta pending)')"
+
+grep -F 'forte recommandation non obligatoire' prompts/011-V0_1_5_START_PROMPT.md
+grep -F 'ne doivent ni rechercher automatiquement « la dernière version de PGR »' prompts/011-V0_1_5_START_PROMPT.md
+grep -F 'réservée à `0.1.6`' prompts/011-V0_1_5_START_PROMPT.md
+grep -F 'réservée à `0.1.7`' prompts/011-V0_1_5_START_PROMPT.md
+grep -F 'réservés à `0.1.8`' prompts/011-V0_1_5_START_PROMPT.md
+
+grep -F '29` fichiers' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F '242` occurrences' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'alpha.2` — sémantique normative' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'alpha.3` — autonomie locale' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'alpha.4` — frontière PGR / SaseDev Knowledge' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+
+git diff --check
+git status --short
+
+git add VERSION README.md docs/000-README.md \
+    docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
+    deltas/0.1.5/alpha.1.md
+
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history est :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.5/alpha.1.md
+M  docs/000-README.md
+A  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+```
+
+Aucun fichier sous `docs/rules/`, `docs/skeletons/` ou `docs/templates/` ne doit être indexé pour `alpha.1`.
+
+## Revue opérateur attendue
+
+La revue doit confirmer que l’inventaire distingue bien :
+
+- un `SHOULD` réellement recommandatoire d’une obligation `MUST` ;
+- un choix local face à une recommandation d’un véritable `OVERRIDE` ;
+- l’autonomie documentaire du projet d’une simple absence de dépendance runtime/build ;
+- une skeleton specification normative d’une recette pratique candidate à Knowledge ;
+- les références vivantes à corriger des références historiques à préserver.
+
+Elle doit également confirmer qu’aucune adoption Games/KSP, aucun audit Rust futur et aucune réouverture Tauri ne sont introduits par la tranche.
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.5/alpha.1.md` à partir des résultats réellement observés. Dans la même réponse, préparer séparément le delta `0.1.5-alpha.2` consacré à la sémantique normative, aux conséquences de gate/adoption et aux cas concrets déjà identifiés, sans absorber l’autonomie `alpha.3` ni la frontière Knowledge `alpha.4`.
+
+Après remise du history, fournir automatiquement le bloc opérateur exact pour appliquer le history, committer/pusher `0.1.5-alpha.1`, puis seulement appliquer le delta suivant conformément à `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`.
+
+### FAIL
+
+Consigner le résultat réel dans le history, puis ouvrir `0.1.5-alpha.1.fix.1` ou un REPLAN selon la cause. Aucun changement prévu pour `alpha.2` ne doit être absorbé silencieusement dans le fix.

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.

deltas/0.1.5/alpha.3.md

@@ -0,0 +1,185 @@
+<!-- file: deltas/0.1.5/alpha.3.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.5-alpha.3 — autonomie locale et réalignement PGR volontaire
+
+## Objet
+
+Stabiliser le contrat d'autonomie après instanciation ou adoption : une fois la baseline locale établie, le projet gouverne ses sessions et releases suivantes depuis ses propres owners, sans dépendance documentaire implicite vers PGR ni recherche automatique d'une version plus récente du référentiel.
+
+La tranche définit également le seul mécanisme prévu pour revenir volontairement vers PGR : un réalignement explicite, borné, fondé sur un snapshot PGR précis choisi par le projet puis comparé à la baseline locale.
+
+## Précondition
+
+Le history `history/0.1.5/alpha.2.md` doit être présent avec statut `PASS` avant application de ce delta.
+
+La séquence acquise reste conservée :
+
+```text
+alpha.1          PARTIAL
+alpha.1.fix.1    PASS
+alpha.2          PASS
+```
+
+Le `PARTIAL` initial n'est pas réécrit et les histories précédents restent inchangés.
+
+## Contrat d'autonomie
+
+Après instanciation ou adoption :
+
+```text
+snapshot PGR explicitement choisi
+        ↓
+instanciation / adoption / adaptation
+        ↓
+baseline locale du projet
+        ↓
+autorité locale des sessions et releases suivantes
+```
+
+Le projet possède alors ses règles, plans, architecture, décisions et historiques applicables. PGR ne devient ni dépendance runtime/build, ni upstream documentaire implicite.
+
+Le projet MUST NOT rechercher automatiquement « la dernière version de PGR » pour reprendre une session ou ouvrir une release suivante.
+
+## Réalignement futur
+
+Un réalignement PGR reste possible lorsqu'il est explicitement décidé. Il ne constitue pas une mise à jour continue.
+
+L'opération doit :
+
+1. identifier un snapshot PGR précis — version, tag, commit ou archive ;
+2. repartir de la baseline locale autoritaire ;
+3. comparer les owners PGR réellement applicables ;
+4. classifier les écarts utiles selon `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
+5. définir un scope et des validations proportionnés ;
+6. préserver les histories et snapshots historiques du projet.
+
+Entre deux réalignements explicitement décidés, la baseline locale reste suffisante et autoritaire.
+
+## Owners réconciliés
+
+- `RULES.md` révision `16` : autonomie générale, absence d'upstream PGR implicite et réalignement borné ;
+- `docs/rules/220-SKELETONS.md` révision `2` : la baseline locale devient autoritaire dès l'instanciation et aucune version PGR plus récente n'est recherchée automatiquement ;
+- `docs/rules/230-ADOPTION.md` révision `3` : contrat complet d'autorité locale et procédure de réalignement futur ;
+- `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` révision `5` : propagation du contrat au point d'entrée normatif local ;
+- `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` révision `2` : snapshot PGR choisi, baseline locale de sortie et pattern de réalignement explicite.
+
+`docs/rules/210-WORKFLOW.md` révision `9` et `docs/templates/003-NEW_SESSION_PROMPT.md` révision `2` restent `KEEP` : leur reprise part déjà de la baseline autoritaire du projet courant et aucune contradiction n'a été démontrée.
+
+## Cohérence documentaire
+
+- `README.md` présente `0.1.5-alpha.3` comme tranche active ;
+- `docs/000-README.md` identifie les owners d'autonomie réconciliés ;
+- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `3`, enregistre `alpha.2 PASS` et la mise en œuvre `alpha.3`.
+
+`ROADMAP.md` et `CHANGELOG.md` restent inchangés. La frontière PGR / SaseDev Knowledge reste réservée à `alpha.4` ; Games `0.1.6`, KSP `0.1.7` et les audits Rust/Clippy `0.1.8` restent hors scope.
+
+## Gate opérateur
+
+Après commit/push de `alpha.2` avec son history `PASS`, appliquer ce delta puis exécuter :
+
+```bash
+cat VERSION
+
+test -f history/0.1.5/alpha.2.md
+test -f deltas/0.1.5/alpha.3.md
+test ! -e history/0.1.5/alpha.3.md
+
+grep -Fx '0.1.5-alpha.3' 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 -A2 '^## Statut$' history/0.1.5/alpha.2.md | grep -Fx 'PASS'
+
+grep -Fx '<!-- version: 16 -->' RULES.md
+grep -F 'cette baseline et ses owners locaux deviennent l'autorité des sessions et releases suivantes' RULES.md
+grep -F 'MUST NOT rechercher automatiquement « la dernière version de PGR »' RULES.md
+grep -F 'réalignement futur avec PGR MAY être engagé comme opération explicite et bornée' RULES.md
+
+grep -Fx '<!-- version: 2 -->' docs/rules/220-SKELETONS.md
+grep -F 'Cette baseline locale devient l'autorité de ses sessions et releases suivantes' docs/rules/220-SKELETONS.md
+grep -F 'MUST NOT rechercher automatiquement une version PGR plus récente' docs/rules/220-SKELETONS.md
+grep -F "snapshot PGR précis choisi par le projet" docs/rules/220-SKELETONS.md
+
+grep -Fx '<!-- version: 3 -->' docs/rules/230-ADOPTION.md
+grep -F 'elle devient l'autorité des sessions et releases suivantes du projet' docs/rules/230-ADOPTION.md
+grep -F 'MUST NOT rechercher automatiquement « la dernière version de PGR »' docs/rules/230-ADOPTION.md
+grep -F '## Autorité locale et réalignement futur' docs/rules/230-ADOPTION.md
+grep -F 'identifier le snapshot PGR choisi' docs/rules/230-ADOPTION.md
+grep -F 'Le réalignement ne doit pas être présenté comme une mise à jour automatique' docs/rules/230-ADOPTION.md
+
+grep -Fx '<!-- version: 5 -->' docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+grep -F "la baseline locale et ses owners deviennent l'autorité des sessions et releases suivantes" docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+grep -F 'MUST NOT rechercher automatiquement « la dernière version de PGR »' docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+
+grep -Fx '<!-- version: 2 -->' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
+grep -F 'snapshot PGR choisi' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
+grep -F '## Autorité après adoption' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
+grep -F 'réalignement PGR automatique : non' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
+grep -F 'Elles ne recherchent pas automatiquement « la dernière version de PGR »' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
+
+grep -Fx '<!-- version: 9 -->' docs/rules/210-WORKFLOW.md
+grep -Fx '<!-- version: 2 -->' docs/templates/003-NEW_SESSION_PROMPT.md
+
+grep -Fx '<!-- version: 3 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'Sa gate opérateur du `2026-10-01` est `PASS`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'Décisions de mise en œuvre `alpha.3`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'la frontière Knowledge reste réservée à `alpha.4`' 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','alpha.3.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md'}; print('0.1.5 alpha.3 history boundary: clean (106 closed prior pairs, current alpha.3 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/220-SKELETONS.md docs/rules/230-ADOPTION.md \
+    docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md \
+    docs/templates/007-EXISTING_PROJECT_ADOPTION.md \
+    deltas/0.1.5/alpha.3.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.3.md
+M  docs/000-README.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+M  docs/rules/220-SKELETONS.md
+M  docs/rules/230-ADOPTION.md
+M  docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+M  docs/templates/007-EXISTING_PROJECT_ADOPTION.md
+```
+
+## Revue opérateur attendue
+
+La revue doit confirmer qu'un projet adopté reste effectivement gouvernable sans consulter PGR, que le réalignement futur est une opération explicite et non un abonnement implicite, et qu'aucune règle n'oblige un projet à suivre automatiquement les nouvelles releases PGR.
+
+Elle doit aussi confirmer que `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent corrects sans modification et que `alpha.3` ne commence ni la frontière Knowledge ni les adoptions Games/KSP.

deltas/0.1.5/alpha.4.md

@@ -0,0 +1,186 @@
+<!-- file: deltas/0.1.5/alpha.4.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.5-alpha.4 — frontière PGR / SaseDev Knowledge
+
+## Objet
+
+Stabiliser la frontière durable entre le référentiel normatif PGR et les contenus pratiques qui peuvent vivre dans une base de connaissances séparée.
+
+PGR doit rester auto-suffisant pour comprendre et appliquer ses règles. SaseDev Knowledge MAY accueillir des howtos détaillés, recettes pratiques, snippets, exemples d'intégration, dépannage, comparatifs et variantes d'implémentation, mais ne devient ni owner normatif de PGR ni dépendance nécessaire à son interprétation.
+
+La tranche ne déplace aucun contenu vers Knowledge et ne crée aucun lien de dépendance vers un dépôt externe.
+
+## Précondition
+
+Le history `history/0.1.5/alpha.3.md` doit être présent avec statut `PASS` avant application de ce delta.
+
+La séquence acquise reste conservée :
+
+```text
+alpha.1          PARTIAL
+alpha.1.fix.1    PASS
+alpha.2          PASS
+alpha.3          PASS
+```
+
+Les histories précédents ne sont pas réécrits.
+
+## Taxonomie stabilisée
+
+PGR conserve les informations nécessaires à son propre contrat :
+
+```text
+PGR
+  règles et contrats de gouvernance
+  objectifs et architecture
+  owners normatifs
+  skeleton specifications minimales
+  templates nécessaires à un contrat réutilisable
+  validations directement liées aux règles
+```
+
+Les contenus suivants sont pratiques et MAY vivre dans une base de connaissances séparée :
+
+```text
+contenus pratiques complémentaires
+  howtos détaillés
+  recettes pratiques
+  snippets
+  exemples d'intégration
+  dépannage
+  comparatifs
+  variantes d'implémentation
+```
+
+Cette classification est sémantique. Elle ne déclenche aucun déplacement automatique.
+
+## Auto-suffisance
+
+Une règle PGR doit rester interprétable depuis PGR lui-même. Un document pratique externe MAY aider à l'implémentation, mais MUST NOT être nécessaire pour déterminer la force, le scope ou les exigences d'une règle PGR.
+
+SaseDev Knowledge est une destination possible pour les contenus pratiques, pas un upstream normatif. PGR MUST NOT dépendre de sa disponibilité.
+
+Une extraction physique future exige une destination autoritaire explicitement fournie et vérifiée. `0.1.5-alpha.4` ne réalise aucune migration.
+
+## Owners réconciliés
+
+- `docs/objectives/001-PROJECT_OBJECTIVES.md` révision `2` : remplace « recette Markdown » par « spécification Markdown composable », ajoute l'auto-suffisance PGR et sépare les contenus pratiques externes ;
+- `docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` révision `5` : clarifie la nature du skeleton et formalise la frontière architecturale avec les contenus pratiques externes ;
+- `docs/rules/300-DOCUMENTATION.md` révision `5` : devient l'owner documentaire de la taxonomie normative/pratique, de l'auto-suffisance et du caractère non automatique d'une extraction future.
+
+Aucun owner Knowledge supplémentaire n'est créé.
+
+## Cohérence documentaire
+
+- `README.md` présente `0.1.5-alpha.4` comme tranche active ;
+- `docs/000-README.md` présente les trois owners comme réconciliés en `alpha.4` ;
+- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `4`, enregistre `alpha.3 PASS` et les décisions de mise en œuvre `alpha.4`.
+
+`RULES.md`, `ROADMAP.md` et `CHANGELOG.md` restent inchangés. Les adoptions Games `0.1.6`, KSP `0.1.7` et les audits Rust/Clippy `0.1.8` restent hors scope.
+
+## Gate opérateur
+
+Après commit/push de `alpha.3` avec son history `PASS`, appliquer ce delta puis exécuter :
+
+```bash
+cat VERSION
+
+test -f history/0.1.5/alpha.3.md
+test -f deltas/0.1.5/alpha.4.md
+test ! -e history/0.1.5/alpha.4.md
+
+grep -Fx '0.1.5-alpha.4' 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 -A2 '^## Statut$' history/0.1.5/alpha.2.md | grep -Fx 'PASS'
+grep -A2 '^## Statut$' history/0.1.5/alpha.3.md | grep -Fx 'PASS'
+
+grep -Fx '<!-- version: 2 -->' docs/objectives/001-PROJECT_OBJECTIVES.md
+grep -F 'spécifications Markdown composables' docs/objectives/001-PROJECT_OBJECTIVES.md
+grep -F 'rester auto-suffisant pour comprendre et appliquer les contrats normatifs PGR' docs/objectives/001-PROJECT_OBJECTIVES.md
+grep -F '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' docs/objectives/001-PROJECT_OBJECTIVES.md
+! grep -F 'recettes Markdown composables' docs/objectives/001-PROJECT_OBJECTIVES.md
+
+grep -Fx '<!-- version: 5 -->' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+grep -F 'Un skeleton est une spécification Markdown composable' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+grep -F '## Frontière avec les contenus pratiques externes' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+grep -F 'PGR doit rester auto-suffisant pour comprendre et appliquer ses contrats normatifs' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+grep -F 'SaseDev Knowledge est une destination possible' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+grep -F "MUST NOT dépendre d'un dépôt Knowledge" docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+! grep -F 'Un skeleton est une recette Markdown' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+
+grep -Fx '<!-- version: 5 -->' docs/rules/300-DOCUMENTATION.md
+grep -F '## Frontière normative et pratique' docs/rules/300-DOCUMENTATION.md
+grep -F 'SaseDev Knowledge MAY jouer ce rôle, sans devenir un owner normatif de PGR' docs/rules/300-DOCUMENTATION.md
+grep -F 'PGR MUST rester auto-suffisant' docs/rules/300-DOCUMENTATION.md
+grep -F "MUST NOT être requis pour déterminer la force, le scope ou les exigences d'une règle PGR" docs/rules/300-DOCUMENTATION.md
+grep -F 'Classifier un contenu comme pratique ne crée pas une obligation de déplacement' docs/rules/300-DOCUMENTATION.md
+grep -F 'MUST NOT créer de dépendance de PGR vers SaseDev Knowledge' docs/rules/300-DOCUMENTATION.md
+
+grep -Fx '<!-- version: 4 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'La gate opérateur de `alpha.3` du `2026-10-01` est `PASS`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'Décisions de mise en œuvre `alpha.4`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'ne créer aucun nouvel owner Knowledge' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+
+grep -Fx '<!-- version: 16 -->' RULES.md
+grep -Fx '<!-- version: 9 -->' docs/rules/210-WORKFLOW.md
+grep -Fx '<!-- version: 3 -->' docs/rules/230-ADOPTION.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','alpha.3.md','alpha.4.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md'}; print('0.1.5 alpha.4 history boundary: clean (107 closed prior pairs, current alpha.4 pending)')"
+
+git diff --exit-code -- history/0.1.4
+git diff --exit-code -- RULES.md ROADMAP.md CHANGELOG.md docs/rules/210-WORKFLOW.md docs/rules/230-ADOPTION.md
+
+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 docs/000-README.md \
+    docs/objectives/001-PROJECT_OBJECTIVES.md \
+    docs/architecture/002-GOVERNANCE_ARCHITECTURE.md \
+    docs/rules/300-DOCUMENTATION.md \
+    docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
+    deltas/0.1.5/alpha.4.md
+
+git diff --cached --check
+git status --short
+```
+
+Le scope indexé attendu avant ajout du history est exactement :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.5/alpha.4.md
+M  docs/000-README.md
+M  docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+M  docs/objectives/001-PROJECT_OBJECTIVES.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+M  docs/rules/300-DOCUMENTATION.md
+```
+
+## Revue opérateur attendue
+
+La revue doit confirmer que la frontière est sémantique et non une dépendance entre dépôts : PGR reste utilisable seul, Knowledge reste une destination pratique possible, aucun contenu n'est déplacé et aucun owner externe n'est requis pour interpréter une règle.
+
+Elle doit aussi confirmer que la tranche ne modifie pas les contrats d'autonomie acquis en `alpha.3` et ne commence pas les adoptions Games/KSP.

deltas/0.1.5/beta.1.md

@@ -0,0 +1,169 @@
+<!-- file: deltas/0.1.5/beta.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.5-beta.1 — réconciliation transversale
+
+## Objet
+
+Fermer la phase alpha de `0.1.5` en réconciliant transversalement les trois contrats acquis : sémantique `MUST / SHOULD / MAY`, autonomie de la baseline locale et frontière PGR / SaseDev Knowledge.
+
+Le rescan préparatoire ne démontre aucun nouveau défaut normatif nécessitant une correction. `beta.1` est donc une tranche d'intégration et de preuve : elle documente les décisions de `KEEP`, rejoue les validations complètes et conserve les scopes futurs hors de la release courante.
+
+## Préconditions
+
+Le history `history/0.1.5/alpha.4.md` doit être présent avec statut `PASS` avant application de ce delta.
+
+La séquence acquise doit rester :
+
+```text
+alpha.1          PARTIAL
+alpha.1.fix.1    PASS
+alpha.2          PASS
+alpha.3          PASS
+alpha.4          PASS
+```
+
+Les histories antérieurs ne sont pas réécrits.
+
+## Réconciliation `SHOULD / SHOULD NOT`
+
+Le rescan relit les owners vivants où une recommandation cohabite avec un `MUST`, une justification ou une contrainte conditionnelle.
+
+Les clauses conservées ne renforcent pas le simple écart à `SHOULD / SHOULD NOT` : elles portent une propriété distincte de sécurité, identité, hygiène d'output ou maintenabilité. Les corrections ciblées d'`alpha.2` restent donc suffisantes et aucun owner normatif supplémentaire n'est modifié en `beta.1`.
+
+Les contrats centraux restent :
+
+```text
+SHOULD / SHOULD NOT
+  forte recommandation non obligatoire
+  écart seul != non-conformité
+  écart seul != FAIL de gate
+  écart seul != OVERRIDE obligatoire
+  justification MAY être documentée si elle apporte une valeur durable
+```
+
+## Autonomie et snapshots
+
+La réconciliation confirme que :
+
+- la baseline locale et ses owners sont l'autorité des sessions/releases suivantes après instanciation/adoption ;
+- PGR n'est pas un upstream documentaire implicite ;
+- aucun mécanisme ne recherche automatiquement « la dernière version de PGR » ;
+- un réalignement futur est une opération explicite et bornée, fondée sur un snapshot PGR choisi ;
+- `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent `KEEP`.
+
+## Frontière PGR / Knowledge
+
+PGR reste auto-suffisant pour déterminer la force, le scope et les exigences de ses règles. SaseDev Knowledge MAY accueillir des contenus pratiques complémentaires, mais ne devient ni owner normatif, ni source requise, ni dépendance de PGR.
+
+Aucune migration physique n'est réalisée en `beta.1`.
+
+## Trajectoire réconciliée
+
+La référence vivante Games dans `540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` reste corrigée vers `0.1.6`.
+
+Les références historiques qui décrivent un ancien horizon restent inchangées lorsqu'elles sont exactes dans leur contexte.
+
+```text
+0.1.6   adoption sasedev-games       RESERVED
+0.1.7   adoption KSP                 RESERVED
+0.1.8   audits Rust/Clippy           RESERVED
+0.1.9                               NOT RESERVED
+```
+
+`beta.1` ne commence aucun de ces scopes.
+
+## Modifications
+
+- `VERSION` passe à `0.1.5-beta.1` ;
+- `README.md` passe en révision `32` et présente la réconciliation bêta ;
+- `docs/000-README.md` passe en révision `51` et indexe `beta.1` ;
+- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `5`, enregistre `alpha.4 PASS` et les résultats du rescan préparatoire ;
+- aucun owner normatif, skeleton, template, validation, study ou history antérieur n'est modifié.
+
+## Gate opérateur
+
+Après commit/push de `alpha.4` avec son history `PASS`, appliquer ce delta puis exécuter :
+
+```bash
+cat VERSION
+
+test -f history/0.1.5/alpha.4.md
+test -f deltas/0.1.5/beta.1.md
+test ! -e history/0.1.5/beta.1.md
+
+grep -Fx '0.1.5-beta.1' 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 -A2 '^## Statut$' history/0.1.5/alpha.2.md | grep -Fx 'PASS'
+grep -A2 '^## Statut$' history/0.1.5/alpha.3.md | grep -Fx 'PASS'
+grep -A2 '^## Statut$' history/0.1.5/alpha.4.md | grep -Fx 'PASS'
+
+grep -Fx '<!-- version: 16 -->' RULES.md
+grep -F 'forte recommandation non obligatoire' RULES.md
+grep -F "n'exige pas automatiquement un \`OVERRIDE\`" RULES.md
+
+grep -Fx '<!-- version: 3 -->' docs/rules/230-ADOPTION.md
+grep -F 'MUST NOT rechercher automatiquement « la dernière version de PGR »' docs/rules/230-ADOPTION.md
+grep -F 'identifier le snapshot PGR choisi' 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 -Fx '<!-- version: 5 -->' docs/rules/300-DOCUMENTATION.md
+grep -F 'PGR MUST rester auto-suffisant' docs/rules/300-DOCUMENTATION.md
+grep -F 'SaseDev Knowledge MAY jouer ce rôle, sans devenir un owner normatif de PGR' docs/rules/300-DOCUMENTATION.md
+
+grep -Fx '<!-- version: 9 -->' docs/rules/210-WORKFLOW.md
+grep -Fx '<!-- version: 2 -->' docs/templates/003-NEW_SESSION_PROMPT.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 -Fx '<!-- version: 5 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'La gate opérateur de `alpha.4` du `2026-10-01` est `PASS`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'Réconciliation transversale préparée en `beta.1`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'KEEP des owners normatifs acquis' 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','alpha.3.md','alpha.4.md','beta.1.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md','alpha.4.md'}; print('0.1.5 beta.1 history boundary: clean (108 closed prior pairs, current beta.1 pending)')"
+
+git diff --exit-code -- history/0.1.4
+git diff --exit-code -- RULES.md ROADMAP.md CHANGELOG.md     docs/objectives/001-PROJECT_OBJECTIVES.md     docs/architecture/002-GOVERNANCE_ARCHITECTURE.md     docs/rules/210-WORKFLOW.md docs/rules/220-SKELETONS.md     docs/rules/230-ADOPTION.md docs/rules/300-DOCUMENTATION.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/001-PROJECT_GOVERNANCE_FOUNDATION.md     docs/skeletons/003-WEB_FRONTEND.md     docs/templates/003-NEW_SESSION_PROMPT.md     docs/templates/007-EXISTING_PROJECT_ADOPTION.md     docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md
+
+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 docs/000-README.md     docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md     deltas/0.1.5/beta.1.md
+
+git diff --cached --check
+git status --short
+```
+
+## Scope Git attendu
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.5/beta.1.md
+M  docs/000-README.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+```
+
+## Suite
+
+Si la gate est `PASS`, produire `history/0.1.5/beta.1.md`, committer/pousser la tranche puis préparer `rc.1` : freeze des contrats stabilisés, présentation candidate, revue d'horizon bornée et préparation du handoff `0.1.6` uniquement si la trajectoire reste valide.

deltas/0.1.5/rc.1.fix.1.md

@@ -0,0 +1,165 @@
+<!-- file: deltas/0.1.5/rc.1.fix.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.5-rc.1.fix.1 — alignement des assertions documentaires RC
+
+## Diagnostic
+
+La gate opérateur de `0.1.5-rc.1` a validé le freeze fonctionnel, les `55/55` tests Python, les audits d'hygiène/Markdown et le scope Git, mais trois assertions exactes prévues par `rc.1` n'ont produit aucune correspondance :
+
+```text
+grep -F 'forte recommandation non obligatoire' CHANGELOG.md
+grep -F 'aucun numéro de version Games n’est figé' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+grep -F 'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+```
+
+`history/0.1.5/rc.1.md` enregistre donc `FAIL`.
+
+Le diagnostic est strictement documentaire : les contrats normatifs, la décision d'horizon, le prompt `012` et les validations techniques restent acquis.
+
+## Objet
+
+Aligner les formulations de présentation avec les chaînes canoniques exigées par la gate RC sans rouvrir aucun owner normatif et sans commencer `rel.1` ou `0.1.6`.
+
+Version après application :
+
+```text
+0.1.5-rc.1.fix.1
+```
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+CHANGELOG.md
+docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+```
+
+ADD :
+
+```text
+deltas/0.1.5/rc.1.fix.1.md
+```
+
+DELETE : aucun.
+
+`README.md`, `ROADMAP.md`, `docs/000-README.md`, le prompt `012`, tous les owners normatifs, skeletons, templates, validations et histories antérieurs MUST rester inchangés.
+
+## Corrections
+
+`CHANGELOG.md` passe en révision `21` et emploie la formulation canonique `forte recommandation non obligatoire` pour `SHOULD / SHOULD NOT`.
+
+`docs/studies/005-V0_1_5_HORIZON_REVIEW.md` passe en révision `2` et :
+
+- contient explicitement la sous-chaîne `aucun numéro de version Games n’est figé` ;
+- expose explicitement la classification canonique `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A` avant son détail ligne par ligne.
+
+`docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `7` et conserve la vérité opérateur `rc.1 FAIL` ainsi que le scope borné du présent fix.
+
+Aucune décision d'horizon n'est modifiée.
+
+## Gate opérateur
+
+Après commit/push de `rc.1` avec son history `FAIL`, appliquer ce delta puis exécuter :
+
+```bash
+cat VERSION
+
+test -f history/0.1.5/rc.1.md
+test -f deltas/0.1.5/rc.1.fix.1.md
+test ! -e history/0.1.5/rc.1.fix.1.md
+
+grep -Fx '0.1.5-rc.1.fix.1' VERSION
+grep -A2 '^## Statut$' history/0.1.5/rc.1.md | grep -Fx 'FAIL'
+
+grep -Fx '<!-- version: 21 -->' CHANGELOG.md
+grep -F 'forte recommandation non obligatoire' CHANGELOG.md
+
+grep -Fx '<!-- version: 2 -->' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+grep -F 'aucun numéro de version Games n’est figé' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+grep -F 'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+grep -F 'conserver `0.1.6` comme prochaine release' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+grep -F 'Aucun `0.1.9` n’est réservé' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+
+grep -Fx '<!-- version: 7 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'Gate `rc.1` en échec documentaire et correctif `rc.1.fix.1`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'history/0.1.5/rc.1.md` enregistre donc le résultat réel `FAIL`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F '`rel.1` reste bloqué tant que `rc.1.fix.1` n’est pas validé `PASS`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+
+grep -Fx '<!-- version: 33 -->' README.md
+grep -Fx '<!-- version: 18 -->' ROADMAP.md
+grep -Fx '<!-- version: 52 -->' docs/000-README.md
+grep -Fx '<!-- version: 1 -->' prompts/012-V0_1_6_START_PROMPT.md
+
+grep -Fx '<!-- version: 16 -->' RULES.md
+grep -Fx '<!-- version: 9 -->' docs/rules/210-WORKFLOW.md
+grep -Fx '<!-- version: 3 -->' docs/rules/230-ADOPTION.md
+grep -Fx '<!-- version: 5 -->' docs/rules/300-DOCUMENTATION.md
+grep -Fx '<!-- version: 2 -->' docs/rules/400-VALIDATION.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','alpha.3.md','alpha.4.md','beta.1.md','rc.1.md','rc.1.fix.1.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md','alpha.4.md','beta.1.md','rc.1.md'}; print('0.1.5 rc.1.fix.1 history boundary: clean (110 closed prior pairs, current rc.1.fix.1 pending)')"
+
+git diff --exit-code -- history/0.1.4
+
+git diff --exit-code -- README.md ROADMAP.md docs/000-README.md \
+    prompts/012-V0_1_6_START_PROMPT.md RULES.md \
+    docs/objectives/001-PROJECT_OBJECTIVES.md \
+    docs/architecture/002-GOVERNANCE_ARCHITECTURE.md \
+    docs/rules/210-WORKFLOW.md docs/rules/220-SKELETONS.md \
+    docs/rules/230-ADOPTION.md docs/rules/300-DOCUMENTATION.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/001-PROJECT_GOVERNANCE_FOUNDATION.md \
+    docs/skeletons/003-WEB_FRONTEND.md \
+    docs/templates/003-NEW_SESSION_PROMPT.md \
+    docs/templates/007-EXISTING_PROJECT_ADOPTION.md \
+    docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md
+
+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 CHANGELOG.md \
+    docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
+    docs/studies/005-V0_1_5_HORIZON_REVIEW.md \
+    deltas/0.1.5/rc.1.fix.1.md
+
+git diff --cached --check
+git status --short
+```
+
+## Scope Git attendu
+
+```text
+M  CHANGELOG.md
+M  VERSION
+A  deltas/0.1.5/rc.1.fix.1.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+M  docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+```
+
+## Transition
+
+### PASS
+
+Produire `history/0.1.5/rc.1.fix.1.md`, committer/pousser `0.1.5-rc.1.fix.1`, puis préparer `rel.1` comme promotion stable mécanique sans nouveau scope.
+
+### FAIL
+
+Enregistrer le résultat réel dans `history/0.1.5/rc.1.fix.1.md` et poursuivre sous `rc.1.fix.N`. Ne pas commencer `rel.1` tant que le correctif RC n'est pas `PASS`.

deltas/0.1.5/rc.1.md

@@ -0,0 +1,207 @@
+<!-- file: deltas/0.1.5/rc.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.5-rc.1 — freeze, revue d’horizon et handoff Games
+
+## Objet
+
+Geler les trois contrats transversaux réconciliés par `beta.1`, préparer la présentation candidate de `0.1.5`, effectuer la revue d’horizon limitée prévue par le plan et préparer le handoff vers `0.1.6` uniquement puisque l’adoption Games reste la prochaine dépendance réelle.
+
+La RC n’ajoute aucun nouveau contrat normatif et ne commence aucune adoption.
+
+## Préconditions
+
+Le history `history/0.1.5/beta.1.md` doit être présent avec statut `PASS` avant application de ce delta.
+
+La séquence réelle doit rester :
+
+```text
+alpha.1          PARTIAL
+alpha.1.fix.1    PASS
+alpha.2          PASS
+alpha.3          PASS
+alpha.4          PASS
+beta.1           PASS
+```
+
+Les owners stabilisés pendant `alpha.2` à `alpha.4` sont gelés sauf défaut démontré. Aucun défaut nouveau n’est introduit par la préparation RC.
+
+## Revue d’horizon
+
+`docs/studies/005-V0_1_5_HORIZON_REVIEW.md` confirme qu’aucun nouveau prérequis transversal ne doit précéder l’adoption réelle de `sasedev-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
+```
+
+La revue impose pour `0.1.6` une stable PGR `v0.1.5` réellement publiée/vérifiée et une archive Games récente explicitement autoritaire. Elle ne fige volontairement aucun numéro Games.
+
+## Handoff 0.1.6
+
+`prompts/012-V0_1_6_START_PROMPT.md` prépare `0.1.6-alpha.1` comme tranche d’intake et de cartographie avant migration.
+
+Le prompt exige une classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A`, conserve la sémantique non obligatoire de `SHOULD / SHOULD NOT`, préserve les décisions locales Games et rappelle que la baseline Games devient l’autorité du projet après adoption.
+
+Il interdit de généraliser automatiquement un ancien POC ou artefact historique sans applicabilité démontrée par le corpus Games fourni.
+
+## Modifications
+
+- `VERSION` passe à `0.1.5-rc.1` ;
+- `README.md` passe en révision `33` et présente la candidate/freeze ;
+- `CHANGELOG.md` passe en révision `20` et reçoit l’entrée `0.1.5 (candidate)` sans chronologie de tranches ;
+- `ROADMAP.md` passe en révision `18` et enregistre la confirmation de trajectoire issue de la revue `0.1.5-rc.1` ;
+- `docs/000-README.md` passe en révision `52` et indexe la revue d’horizon et le handoff `012` ;
+- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `6`, enregistre `beta.1 PASS` et le freeze RC ;
+- `docs/studies/000-README.md` passe en révision `6` ;
+- `docs/studies/005-V0_1_5_HORIZON_REVIEW.md` est créé ;
+- `prompts/012-V0_1_6_START_PROMPT.md` est créé ;
+- aucun owner normatif, skeleton, template ou contrat de validation stabilisé par les alphas n’est modifié.
+
+## Gate opérateur
+
+Après commit/push de `beta.1` avec son history `PASS`, appliquer ce delta puis exécuter :
+
+```bash
+cat VERSION
+
+test -f history/0.1.5/beta.1.md
+test -f deltas/0.1.5/rc.1.md
+test -f docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+test -f prompts/012-V0_1_6_START_PROMPT.md
+test ! -e history/0.1.5/rc.1.md
+
+grep -Fx '0.1.5-rc.1' 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 -A2 '^## Statut$' history/0.1.5/alpha.2.md | grep -Fx 'PASS'
+grep -A2 '^## Statut$' history/0.1.5/alpha.3.md | grep -Fx 'PASS'
+grep -A2 '^## Statut$' history/0.1.5/alpha.4.md | grep -Fx 'PASS'
+grep -A2 '^## Statut$' history/0.1.5/beta.1.md | grep -Fx 'PASS'
+
+grep -Fx '<!-- version: 33 -->' README.md
+grep -F 'candidate `0.1.5-rc.1`' README.md
+grep -F '`0.1.6` reste la prochaine release' README.md
+
+grep -Fx '<!-- version: 20 -->' CHANGELOG.md
+grep -Fx '## 0.1.5 (candidate)' CHANGELOG.md
+grep -F 'forte recommandation non obligatoire' CHANGELOG.md
+grep -F 'baseline locale et ses owners deviennent l’autorité' CHANGELOG.md
+grep -F 'SaseDev Knowledge' CHANGELOG.md
+grep -F 'adoption réelle de `sasedev-games` reste la cible `0.1.6`' CHANGELOG.md
+
+python3 -B -c "from pathlib import Path; s=Path('CHANGELOG.md').read_text(encoding='utf-8').split('## 0.1.5 (candidate)',1)[1].split('## 0.1.4',1)[0]; assert all(x not in s for x in ('alpha.1','alpha.2','alpha.3','alpha.4','beta.1','rc.1','rel.1')); print('0.1.5 candidate changelog: clean')"
+
+grep -Fx '<!-- version: 18 -->' ROADMAP.md
+grep -F -- '- `( ) 0.1.5`' ROADMAP.md
+grep -F -- '- `( ) 0.1.6`' ROADMAP.md
+grep -F -- '- `( ) 0.1.7`' ROADMAP.md
+grep -F -- '- `( ) 0.1.8`' ROADMAP.md
+grep -F 'La revue limitée `0.1.5-rc.1` confirme' ROADMAP.md
+! grep -F -- '- `( ) 0.1.9`' ROADMAP.md
+
+grep -Fx '<!-- version: 52 -->' docs/000-README.md
+grep -F 'studies/005-V0_1_5_HORIZON_REVIEW.md' docs/000-README.md
+grep -F 'prompts/012-V0_1_6_START_PROMPT.md' docs/000-README.md
+
+grep -Fx '<!-- version: 6 -->' docs/studies/000-README.md
+grep -F '005-V0_1_5_HORIZON_REVIEW.md' docs/studies/000-README.md
+
+grep -Fx '<!-- version: 1 -->' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+grep -F 'conserver `0.1.6` comme prochaine release' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+grep -F 'aucun numéro de version Games n’est figé' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+grep -F 'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+grep -F 'Aucun `0.1.9` n’est réservé' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+
+grep -Fx '<!-- version: 1 -->' prompts/012-V0_1_6_START_PROMPT.md
+grep -F 'tag Gitea `v0.1.5`' prompts/012-V0_1_6_START_PROMPT.md
+grep -F 'pgr-0.1.5-publish.001-report.md' prompts/012-V0_1_6_START_PROMPT.md
+grep -F 'archive récente et explicitement autoritaire de `sasedev-games`' prompts/012-V0_1_6_START_PROMPT.md
+grep -F '0.1.6-alpha.1' prompts/012-V0_1_6_START_PROMPT.md
+grep -F 'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A' prompts/012-V0_1_6_START_PROMPT.md
+grep -F 'ne doivent pas rechercher automatiquement « la dernière version de PGR »' prompts/012-V0_1_6_START_PROMPT.md
+grep -F 'réservée à `0.1.7`' prompts/012-V0_1_6_START_PROMPT.md
+grep -F 'réservés à `0.1.8`' prompts/012-V0_1_6_START_PROMPT.md
+
+grep -Fx '<!-- version: 6 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'La gate opérateur de `beta.1` du `2026-10-01` est `PASS`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'Freeze et revue d’horizon préparés en `rc.1`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F '0.1.9   NOT RESERVED' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F '012-V0_1_6_START_PROMPT.md' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+
+grep -Fx '<!-- version: 16 -->' RULES.md
+grep -Fx '<!-- version: 9 -->' docs/rules/210-WORKFLOW.md
+grep -Fx '<!-- version: 3 -->' docs/rules/230-ADOPTION.md
+grep -Fx '<!-- version: 5 -->' docs/rules/300-DOCUMENTATION.md
+grep -Fx '<!-- version: 2 -->' docs/rules/400-VALIDATION.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','alpha.3.md','alpha.4.md','beta.1.md','rc.1.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md','alpha.4.md','beta.1.md'}; print('0.1.5 rc.1 history boundary: clean (109 closed prior pairs, current rc.1 pending)')"
+
+git diff --exit-code -- history/0.1.4
+
+git diff --exit-code -- RULES.md \
+    docs/objectives/001-PROJECT_OBJECTIVES.md \
+    docs/architecture/002-GOVERNANCE_ARCHITECTURE.md \
+    docs/rules/210-WORKFLOW.md docs/rules/220-SKELETONS.md \
+    docs/rules/230-ADOPTION.md docs/rules/300-DOCUMENTATION.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/001-PROJECT_GOVERNANCE_FOUNDATION.md \
+    docs/skeletons/003-WEB_FRONTEND.md \
+    docs/templates/003-NEW_SESSION_PROMPT.md \
+    docs/templates/007-EXISTING_PROJECT_ADOPTION.md \
+    docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md
+
+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 CHANGELOG.md ROADMAP.md \
+    deltas/0.1.5/rc.1.md \
+    docs/000-README.md \
+    docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
+    docs/studies/000-README.md \
+    docs/studies/005-V0_1_5_HORIZON_REVIEW.md \
+    prompts/012-V0_1_6_START_PROMPT.md
+
+git diff --cached --check
+git status --short
+```
+
+## Scope Git attendu
+
+```text
+M  CHANGELOG.md
+M  README.md
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.5/rc.1.md
+M  docs/000-README.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+M  docs/studies/000-README.md
+A  docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+A  prompts/012-V0_1_6_START_PROMPT.md
+```
+
+## Transition
+
+Si la gate est `PASS`, produire `history/0.1.5/rc.1.md`, committer/pousser `0.1.5-rc.1`, puis préparer `rel.1` comme promotion mécanique vers la stable `0.1.5`, sans rouvrir les contrats acquis ni commencer `0.1.6`.

deltas/0.1.5/rel.1.md

@@ -0,0 +1,156 @@
+<!-- file: deltas/0.1.5/rel.1.md -->
+<!-- version: 1 -->
+
+# Delta 0.1.5 rel.1 — promotion stable pré-tag
+
+## Baseline et version
+
+Baseline : `0.1.5-rc.1.fix.1`, avec `history/0.1.5/rc.1.fix.1.md` appliqué et committé. Ce delta MUST NOT être appliqué avant ce commit.
+
+Version avant application :
+
+```text
+0.1.5-rc.1.fix.1
+```
+
+Version après application :
+
+```text
+0.1.5
+```
+
+`rel.1` identifie la clôture opérationnelle ; il ne fait pas partie de la version SemVer du produit.
+
+## Objet
+
+Promouvoir mécaniquement la RC corrigée vers la stable `0.1.5` sans rouvrir les trois contrats stabilisés et sans commencer `0.1.6`.
+
+La tranche finalise uniquement la présentation et les métadonnées de release : version stable, roadmap terminée, changelog sans marqueur `candidate`, README/index en état stable et plan `011` historique.
+
+Aucun owner normatif, skeleton, template, audit Python, étude d'horizon ou prompt de reprise n'est modifié par `rel.1`.
+
+La validation de cette tranche est **pré-tag**. Le tag `v0.1.5`, son archive source Gitea et le rapport `pgr-0.1.5-publish.001-report.md` ne sont pas déclarés existants par ce delta. Ils suivent uniquement un history `rel.1` `PASS`, le commit stable `0.1.5` et la publication réelle du tag.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+README.md
+ROADMAP.md
+CHANGELOG.md
+docs/000-README.md
+docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+```
+
+ADD :
+
+```text
+deltas/0.1.5/rel.1.md
+```
+
+DELETE : aucun.
+
+Le history `rc.1.fix.1` est livré séparément. Le history `rel.1` sera produit uniquement après la gate opérateur.
+
+## Validation opérateur pré-tag
+
+Après application sur le commit contenant `history/0.1.5/rc.1.fix.1.md` :
+
+```bash
+cat VERSION
+
+test -f history/0.1.5/rc.1.fix.1.md
+test -f deltas/0.1.5/rel.1.md
+test -f prompts/012-V0_1_6_START_PROMPT.md
+test -f docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+test ! -e history/0.1.5/rel.1.md
+
+grep -Fx '0.1.5' VERSION
+grep -A2 '^## Statut$' history/0.1.5/rc.1.md | grep -Fx 'FAIL'
+grep -A2 '^## Statut$' history/0.1.5/rc.1.fix.1.md | grep -Fx 'PASS'
+
+grep -Fx '<!-- version: 34 -->' README.md
+grep -F 'La stable autoritaire courante est `0.1.5`' README.md
+grep -F 'La release `0.1.5` stabilise la sémantique `MUST / SHOULD / MAY`' README.md
+grep -F 'plan historique de la stable `0.1.5`' README.md
+
+grep -Fx '<!-- version: 22 -->' CHANGELOG.md
+grep -Fx '## 0.1.5' CHANGELOG.md
+! grep -Fx '## 0.1.5 (candidate)' CHANGELOG.md
+grep -F 'forte recommandation non obligatoire' CHANGELOG.md
+
+grep -Fx '<!-- version: 19 -->' ROADMAP.md
+grep -F -- '- `(x) 0.1.5`' ROADMAP.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
+
+grep -Fx '<!-- version: 53 -->' docs/000-README.md
+grep -F 'plan historique de la stable `0.1.5`' docs/000-README.md
+grep -F 'prompts/012-V0_1_6_START_PROMPT.md' docs/000-README.md
+
+grep -Fx '<!-- version: 8 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'Gate `rc.1.fix.1` acquise et promotion stable' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'Le plan devient historique avec la stable `0.1.5`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+grep -F 'pgr-0.1.5-publish.001-report.md' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+
+grep -Fx '<!-- version: 16 -->' RULES.md
+grep -Fx '<!-- version: 9 -->' docs/rules/210-WORKFLOW.md
+grep -Fx '<!-- version: 3 -->' docs/rules/230-ADOPTION.md
+grep -Fx '<!-- version: 5 -->' docs/rules/300-DOCUMENTATION.md
+grep -Fx '<!-- version: 2 -->' docs/rules/400-VALIDATION.md
+grep -Fx '<!-- version: 2 -->' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+grep -Fx '<!-- version: 1 -->' prompts/012-V0_1_6_START_PROMPT.md
+
+python3 -B -c "from pathlib import Path; import re; expected={'alpha.1.md':'PARTIAL','alpha.1.fix.1.md':'PASS','alpha.2.md':'PASS','alpha.3.md':'PASS','alpha.4.md':'PASS','beta.1.md':'PASS','rc.1.md':'FAIL','rc.1.fix.1.md':'PASS'}; assert all(Path('deltas/0.1.5',n).is_file() and Path('history/0.1.5',n).is_file() and re.search(rf'## Statut\s+{st}\s',Path('history/0.1.5',n).read_text(encoding='utf-8')) for n,st in expected.items()); assert {p.name for p in Path('deltas/0.1.5').glob('*.md')} - {p.name for p in Path('history/0.1.5').glob('*.md')} == {'rel.1.md'}; print('0.1.5 rel.1 stable gate audit: clean (8 prior histories including alpha.1 PARTIAL and rc.1 FAIL/fix PASS, rel.1 pending)')"
+
+python3 -B -c "from pathlib import Path; s=Path('CHANGELOG.md').read_text(encoding='utf-8').split('## 0.1.5',1)[1].split('## 0.1.4',1)[0]; assert all(x not in s for x in ('alpha.1','alpha.2','alpha.3','alpha.4','beta.1','rc.1','rc.1.fix.1','rel.1')); print('0.1.5 stable changelog: clean')"
+
+git diff --exit-code -- history/0.1.4
+
+git diff --exit-code -- RULES.md     docs/objectives/001-PROJECT_OBJECTIVES.md     docs/architecture/002-GOVERNANCE_ARCHITECTURE.md     docs/rules/210-WORKFLOW.md docs/rules/220-SKELETONS.md     docs/rules/230-ADOPTION.md docs/rules/300-DOCUMENTATION.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/001-PROJECT_GOVERNANCE_FOUNDATION.md     docs/skeletons/003-WEB_FRONTEND.md     docs/templates/003-NEW_SESSION_PROMPT.md     docs/templates/007-EXISTING_PROJECT_ADOPTION.md     docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md     docs/studies/005-V0_1_5_HORIZON_REVIEW.md     prompts/012-V0_1_6_START_PROMPT.md
+
+python3 -B -m unittest discover -s tests -v
+
+python3 -B scripts/audit_text_hygiene.py     VERSION README.md RULES.md ROADMAP.md CHANGELOG.md     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 ROADMAP.md CHANGELOG.md     deltas/0.1.5/rel.1.md     docs/000-README.md     docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+
+git diff --cached --check
+git status --short
+```
+
+## Scope Git attendu
+
+```text
+M  CHANGELOG.md
+M  README.md
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.5/rel.1.md
+M  docs/000-README.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+```
+
+## Transition après PASS
+
+Si cette gate pré-tag est `PASS` :
+
+1. produire `history/0.1.5/rel.1.md` avec les preuves opérateur réelles ;
+2. appliquer ce history ;
+3. `git add -A`, `git diff --cached --check`, puis committer **`0.1.5`** sans suffixe `rel.1` ;
+4. pousser `master` ;
+5. vérifier un workspace propre ;
+6. créer et pousser le tag annoté `v0.1.5` ;
+7. télécharger l'archive Gitea du tag et produire `pgr-0.1.5-publish.001-report.md` après vérification indépendante ;
+8. seulement après `publish.001 PASS`, ouvrir `0.1.6` avec `prompts/012-V0_1_6_START_PROMPT.md` et une archive Games récente explicitement autoritaire.

docs/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 36 -->
+<!-- version: 53 -->
 
 # Documentation PGR
 
@@ -20,6 +20,39 @@ D'autres collections telles que `ideas/`, `studies/`, `reference/` ou `formats/`
 
 Les templates techniques copiables sous `templates/` restent séparés des instructions documentaires sous `docs/templates/`. Les répertoires workflow de racine (`deltas/`, `history/`, `handoffs/`, `manifests/`, `prompts/`, `scripts/`) restent séparés de `docs/` parce qu'ils portent le processus de développement et de livraison lui-même.
 
+## 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 historique de la stable `0.1.5` : sémantique normative, autonomie locale, frontière PGR / Knowledge, réconciliation, correctif RC documentaire et handoff vers `0.1.6`.
+- [`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
+
+- [`plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md`](plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md) — plan historique de la stable `0.1.4` : réexamen Tauri, skeleton `004`, décision d’artefacts, freeze RC et revue d’horizon.
+- [`rules/710-TAURI.md`](rules/710-TAURI.md) — owner Tauri 2 réconcilié en `alpha.2` : host/orchestration, frontière commandes-permissions-capabilities, sélection des capabilities, plugins, version produit et validation proportionnée, sans absorber les choix Web.
+- [`skeletons/003-WEB_FRONTEND.md`](skeletons/003-WEB_FRONTEND.md) — specialization Web composable dont l'existence satisfait les prérequis historiques sans rendre Vite, TypeScript, Sass, Bootstrap ou `frontend/` universels à Tauri.
+- [`skeletons/004-TAURI.md`](skeletons/004-TAURI.md) — skeleton Tauri 2 matérialisé en `alpha.3`, composant fondation, Rust/Cargo, Web et owner `710` sans template technique universel ni copie des choix Games/KSP.
+- [`studies/002-TAURI_SKELETON_DECISION.md`](studies/002-TAURI_SKELETON_DECISION.md) — décision historique `DEFER`, levée du motif Web puis décision `beta.1` : `004-TAURI.md` suffit ; aucun template technique ni contrat de validation Tauri séparé n'est justifié.
+- [`studies/004-V0_1_4_HORIZON_REVIEW.md`](studies/004-V0_1_4_HORIZON_REVIEW.md) — revue de fermeture `rc.1` décidant de stabiliser en `0.1.5` la sémantique `SHOULD`, l’autonomie après adoption et la frontière PGR / SaseDev Knowledge avant Games/KSP.
+- [`../prompts/011-V0_1_5_START_PROMPT.md`](../prompts/011-V0_1_5_START_PROMPT.md) — handoff de la stable `0.1.4` vers `0.1.5-alpha.1`, à exécuter uniquement après publication et vérification post-tag de `v0.1.4`.
+- [`../prompts/010-V0_1_4_START_PROMPT.md`](../prompts/010-V0_1_4_START_PROMPT.md) — contrat de reprise exécuté pour ouvrir `0.1.4-alpha.1` après publication vérifiée de `v0.1.3`.
+
+## Points d'entrée de 0.1.3
+
+- [`plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`](plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md) — plan historique de la stable `0.1.3`, de l'audit Games à la stabilisation du profil Android générique et au handoff Tauri `0.1.4`.
+- [`rules/610-ANDROID.md`](rules/610-ANDROID.md) — owner Android révisé : contrats SDK/identité/signing, natif/ABI, Lint, niveaux de tests, packaging/distribution et 16 KB conditionnel, sans absorber les choix propres à Games.
+- [`rules/520-JAVA.md`](rules/520-JAVA.md) et [`rules/522-GRADLE.md`](rules/522-GRADLE.md) — owners composés uniquement lorsqu'un projet Android contient réellement du Java ou utilise Gradle.
+- [`rules/600-PLATFORMS.md`](rules/600-PLATFORMS.md) et [`rules/400-VALIDATION.md`](rules/400-VALIDATION.md) — contrats généraux de plateforme et de preuve auxquels la spécialisation Android doit rester conforme.
+- [`studies/003-V0_1_0_HORIZON_REVIEW.md`](studies/003-V0_1_0_HORIZON_REVIEW.md) — revue ayant engagé Android `0.1.3`, Tauri `0.1.4` puis l'adoption Games `0.1.5` comme scopes distincts.
+- [`../prompts/009-V0_1_3_START_PROMPT.md`](../prompts/009-V0_1_3_START_PROMPT.md) — contrat de reprise exécuté pour ouvrir `0.1.3-alpha.1` après publication vérifiée de `v0.1.2`.
+- [`../prompts/010-V0_1_4_START_PROMPT.md`](../prompts/010-V0_1_4_START_PROMPT.md) — prompt préparé par la RC pour le réexamen Tauri `0.1.4`, à exécuter uniquement après publication et vérification post-tag de `v0.1.3`.
+
 ## Points d'entrée de 0.1.2
 
 - [`plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md`](plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md) — plan historique de la stable `0.1.2`, de la réévaluation Games à la scission `520/521/522`, avec frontière Android explicite.

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/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md

@@ -0,0 +1,617 @@
+<!-- file: docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md -->
+<!-- version: 6 -->
+
+# Plan 0.1.3 — réévaluation pratique Android
+
+## Statut et sources
+
+Plan actif de `0.1.3`, créé pendant `0.1.3-alpha.1` conformément à `prompts/009-V0_1_3_START_PROMPT.md`, après audit indépendant de la stable taggée `v0.1.2`, de son rapport post-tag `PASS` et du corpus Games autoritaire réellement fourni.
+
+Sources autoritaires de reprise PGR réellement fournies :
+
+```text
+pgr-v0.1.2(1).zip                  0ef8facab0c6f92ca427f5f13d38d6c4a4c1cc16174a20ecdab48991bd88d0e6
+pgr-0.1.2-publish.001-report.md    0f6b4e2a685a957fa647a7db009320ada0fc67948737d8344cc3773bcaeb6a9c
+```
+
+Le nom local de l'archive PGR comporte `(1)`, mais son SHA-256 correspond exactement à l'archive canonique `pgr-v0.1.2.zip` enregistrée par le rapport `publish.001`. Le rapport est `PASS`, porte sur cette même archive et confirme le commit stable `585b508578aae337f6940110d4ca47c694a052d5`. Le tag annoté `v0.1.2` possède l'objet tag `cea2c7a06cde844ffa7411f73bb22685a3214414` et se déréférence vers ce commit stable.
+
+Corpus principal réellement fourni pour instruire Android :
+
+```text
+games-v0.3.6(2).zip                ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
+```
+
+Le nom local comporte `(2)`, mais son SHA-256 correspond exactement à la baseline canonique `games-v0.3.6.zip` prévue par le prompt `009` et par le rapport de publication `0.1.2`. Games est donc le corpus Android autoritaire de cette réévaluation.
+
+## Audit de la stable `v0.1.2`
+
+### Intégrité de l'archive et preuve post-tag
+
+L'archive stable contient `316` entrées sous une racine unique `pgr/`, soit `276` fichiers et `40` répertoires. Son CRC est propre, aucun lien symbolique n'est présent et `.git` est absent comme attendu pour une archive de tag Gitea.
+
+`VERSION` vaut exactement `0.1.2`. `CHANGELOG.md` contient l'entrée stable `0.1.2`, `ROADMAP.md` marque `0.1.2` terminé et conserve `0.1.3` à `0.1.7` engagés sans réserver `0.1.8`.
+
+La publication observée suit le workflow courant :
+
+```text
+tranche de clôture  rel.1
+history             rel.1 PASS
+commit stable       0.1.2
+tag                  v0.1.2
+publish.001          preuve externe post-tag PASS
+```
+
+Le SHA de l'objet tag annoté reste distinct du commit stable ; la référence distante déréférencée pointe sur le même commit que `HEAD` et `origin/master` observés dans le rapport.
+
+### Tests, audits et hygiène
+
+La suite Python de la stable a été rejouée dans l'environnement d'analyse :
+
+```text
+48 / 48 tests PASS
+```
+
+Les audits documentaires donnent :
+
+```text
+Markdown header audit: clean (250 file(s))
+Markdown table audit:  clean (10 table(s), 250 file(s))
+Markdown link audit:   clean (307 local link(s), 250 file(s))
+```
+
+Les cinq templates TOML Rust/Cargo et les deux fichiers JSON Web contrôlés restent parsables.
+
+### Chaîne delta/history et vérité opérateur
+
+Les `90` deltas publiés de `0.0.1` à `0.1.2` disposent tous d'un history portant la même identité.
+
+Pour `0.1.2`, la vérité opérateur est :
+
+```text
+alpha.1          PASS
+alpha.2          PASS
+alpha.2.fix.1    PASS
+alpha.3          PASS
+beta.1           PASS
+rc.1             PASS
+rel.1            PASS
+```
+
+La récupération de contamination inter-projet de `alpha.2.fix.1` reste conservée historiquement ; aucun des quatre chemins Knowledge accidentels n'est présent dans la stable publiée.
+
+### Owners applicables avant réévaluation
+
+La stable `0.1.2` possède des owners désormais séparés et composables :
+
+```text
+520  Java
+521  Maven
+522  Gradle
+600  plateformes
+610  Android
+710  Tauri 2
+```
+
+`610-ANDROID.md` est en révision interne `3`. Il compose déjà `522-GRADLE.md` lorsqu'un projet Android utilise Gradle et `520-JAVA.md` lorsqu'il contient du Java ; Android n'implique donc pas à lui seul l'applicabilité du profil Java.
+
+La présente release réévalue les responsabilités Android elles-mêmes. Elle ne rouvre Java/Maven/Gradle que si un défaut transversal réellement démontré l'exige.
+
+## Audit du corpus Games `0.3.6`
+
+### Intégrité et portée
+
+L'archive Games contient `652` entrées sous une racine unique `games/`, soit `502` fichiers et `150` répertoires. Son CRC est propre et aucun lien symbolique n'est présent.
+
+La version produit du workspace est `0.3.6` dans `Cargo.toml`. Games n'a pas encore effectué son adoption PGR réservée à `0.1.5` ; l'absence d'un fichier racine PGR `VERSION` n'est donc pas interprétée comme un défaut de la baseline.
+
+Les audits statiques rejoués sur l'archive donnent :
+
+```text
+General Rust rule audit: clean
+Rust export completeness audit: 0 candidate(s)
+games.sasedev workspace audit: clean
+Markdown table audit: clean (6 table(s), 319 file(s))
+Distribution layout audit: clean (55 required path(s), 11 forbidden path(s) absent)
+```
+
+Ces contrôles attestent l'intégrité structurelle du corpus. Ils ne remplacent pas les preuves Gradle/Android historiques consignées par Games.
+
+### Structure Android observée
+
+Le sous-projet Android natif contient `20` fichiers versionnés sous `Android/` et forme un build Gradle multi-module séparé du workspace Cargo :
+
+```text
+Android/
+├── common/
+├── game-reflex-poc/
+├── game-snake-poc/
+├── gradle/
+├── libs/
+├── build.gradle
+├── gradle.properties
+├── settings.gradle
+└── .gitignore
+```
+
+Le choix `Android/` répond ici à une architecture réellement multi-plateforme. Il ne prouve pas qu'un dépôt exclusivement Android devrait ajouter artificiellement ce niveau.
+
+Les modules exercent deux responsabilités différentes :
+
+```text
+common            Android Library partagée
+game-*-poc        applications Android indépendantes
+```
+
+Les noms exacts `common`, `game-reflex-poc` et `game-snake-poc` restent des décisions produit Games.
+
+### Composition Java et Gradle
+
+Le corpus contient quatre sources Java sous `src/main/java/` :
+
+```text
+Android/common/src/main/java/com/sasedev/games/common/NativeBridge.java
+Android/common/src/main/java/com/sasedev/games/common/SaseGameActivity.java
+Android/game-reflex-poc/src/main/java/com/sasedev/games/reflex/ReflexActivity.java
+Android/game-snake-poc/src/main/java/com/sasedev/games/snake/SnakeActivity.java
+```
+
+Java est donc réellement applicable à Games, mais son usage est une composition du projet Android et non une propriété universelle d'Android.
+
+Le build Android utilise Gradle en Groovy DSL. L'ownership observé est cohérent avec `522-GRADLE.md` :
+
+- `settings.gradle` possède modules, repositories et contrainte minimale Gradle ;
+- le `build.gradle` root possède la version AGP partagée ;
+- `gradle.properties` possède des propriétés partagées non secrètes ;
+- les modules possèdent leur configuration Android et leurs dépendances ;
+- les scripts sous `Android/gradle/` possèdent la logique commune d'assets et de build natif devenue trop importante pour être dupliquée.
+
+### Matrice AGP / Gradle / JDK et niveau Java
+
+La baseline courante déclare ou documente :
+
+```text
+AGP                9.4.0
+Gradle             >= 9.6.0
+JDK de build       >= 17, non épinglé par le projet
+niveau Java        source/target 17
+```
+
+L'histoire Games exerce deux politiques successives : une preuve initiale avec Wrapper Gradle `9.6.0` et JDK `17`, puis une décision durable utilisant Gradle système avec minimum exécutable `>= 9.6.0` et le JDK courant de l'environnement.
+
+Les gates ultérieures ont réellement utilisé Temurin `25.0.4.1 LTS` et Gradle `9.7.1` tout en conservant `source/target 17` pour la glue Java.
+
+Cette trajectoire confirme la séparation entre JDK de build et niveau Java. Les valeurs exactes restent des preuves Games et ne deviennent pas des minima PGR universels.
+
+### SDK Android et compatibilité produit
+
+Les modules exercent :
+
+```text
+compileSdk          36
+targetSdk           36
+minSdk              21
+```
+
+`compileSdk`, `targetSdk` et `minSdk` remplissent des responsabilités distinctes dans le corpus. Games ne fournit aucune raison de coupler mécaniquement leur évolution.
+
+Le `minSdk 21` est lié au contrat produit/toolchain de Games, notamment au support SDL3 retenu. Sa preuve historique inclut l'installation et le démarrage de Snake sur un AVD Android 5.0/API 21 x86.
+
+Ces valeurs ne sont donc pas copiées comme defaults PGR ; elles servent à éprouver la nécessité de justifier les niveaux selon build, distribution, dépendances et compatibilité utilisateur.
+
+### NDK, ABI, JNI et frontière native
+
+Games exerce réellement un pipeline natif Rust/SDL3 :
+
+```text
+NDK                28.2.13676358 / r28c
+cargo-ndk          build Rust Android
+JNI                bridge Java/Rust spécifique Games
+SDL3               AAR externe non vendorizé
+```
+
+Les applications déclarent quatre ABI :
+
+```text
+arm64-v8a
+armeabi-v7a
+x86_64
+x86
+```
+
+Les preuves historiques montrent le build et le packaging des quatre ABI, mais cette liste répond au produit Games et à sa toolchain Rust/SDL3. PGR ne doit pas en déduire une liste universelle d'ABI Android.
+
+La responsabilité Android générique porte sur la déclaration et la preuve des ABI supportées lorsqu'un projet possède du natif. Les détails JNI, `cargo ndk`, extraction SDL3, noms de bibliothèques, features Rust et staging généré restent des responsabilités de spécialisation ou du produit tant qu'aucun owner séparé n'est justifié.
+
+### Manifests, resources, namespaces et identités applicatives
+
+Les deux applications possèdent chacune :
+
+```text
+src/main/AndroidManifest.xml
+src/main/res/values/strings.xml
+namespace
+applicationId
+```
+
+Les manifests déclarent les Activities launcher réellement utilisées et aucune permission Android additionnelle n'est observée dans ces deux fichiers.
+
+Les `namespace` et `applicationId` sont propres à chaque application. Leur forme concrète `com.sasedev.games.*`, les Activities et les labels appartiennent au produit Games ; la séparation de responsabilité entre namespace de code, identité applicative, manifest et resources est en revanche réutilisable.
+
+### Version applicative
+
+Les deux applications Games utilisent actuellement :
+
+```text
+versionCode         2
+versionName         0.2.0
+```
+
+alors que le workspace global vaut `0.3.6`.
+
+Cette différence est légitime dans ce corpus : les applications Android ont leur propre identité de version produit. Elle confirme le caractère conditionnel de la règle PGR actuelle qui ne synchronise `VERSION` et `versionName` que lorsque l'application appartient réellement au même release train.
+
+`versionCode` reste un compteur Android distinct dont la monotonie appartient à l'application publiée concernée.
+
+### Configuration locale, outputs et signing
+
+`Android/.gitignore` exclut explicitement :
+
+```text
+.gradle/
+**/build/
+local.properties
+libs/*.aar
+**/src/main/jniLibs/
+```
+
+La baseline ne versionne ni `local.properties`, ni keystore, ni credentials de signing. Les AAR SDL3 sont également exclus et apportés localement.
+
+Les builds `bundleRelease` historiques ne nécessitent aucun secret versionné ; sans configuration de signature externe ils produisent des AAB de validation qui ne sont pas présentés comme artefacts directement publiables sur un store.
+
+Cette pratique corrobore la séparation entre configuration partagée, état machine local, outputs générés, dépendances locales non vendorizées et secrets de release.
+
+### Packaging APK / AAB et preuves runtime
+
+Les histories `0.3.3` fournissent des preuves opérateur successives :
+
+- APK Debug Snake puis Snake/Reflex construits et inspectés ;
+- AAB Release Snake/Reflex produits ;
+- contenu natif vérifié sous `lib/<abi>/` dans les APK et `base/lib/<abi>/` dans les AAB ;
+- installation et démarrage sur AVD x86_64 ;
+- installation et démarrage sur appareil ARM64 réel ;
+- preuve API 21/x86 pour le minimum supporté ;
+- preuve Android 15/API 35 x86_64 avec `PAGE_SIZE=16384` ;
+- répétition large en beta puis RC après stabilisation.
+
+Ces preuves montrent qu'un build natif ou une cross-compilation ne suffit pas à prouver à lui seul le package final ou le comportement runtime.
+
+### Contrainte 16 KB observée
+
+Games a vérifié pour ses bibliothèques natives 64 bits `arm64-v8a` et `x86_64` des segments ELF `LOAD` alignés au moins à `2**14`, puis un `zipalign -P 16` réussi sur les APK. Un AVD `ps16k` a fourni une preuve runtime avec `getconf PAGE_SIZE=16384`.
+
+Cette preuve est importante, mais elle reste liée à un besoin de distribution Android réel et à la présence de bibliothèques natives. `0.1.3` doit vérifier la forme générique et actuelle de cette exigence auprès des sources Android officielles avant d'en faire une règle normative PGR. Elle ne doit pas devenir une gate universelle pour un projet Android sans code natif ou sans canal de distribution concerné.
+
+## Classification initiale des décisions Games
+
+La classification initiale guide la réévaluation ; elle n'est pas une adoption de Games.
+
+| Observation ou décision                                                         | Classification | Traitement prévu                                                                                                                                |
+|---------------------------------------------------------------------------------|----------------|-------------------------------------------------------------------------------------------------------------------------------------------------|
+| Dépôt multi-plateforme avec zone Android distincte                              | `ADOPT`        | conserver un contrat conditionnel : racine Android dédiée lorsque l'architecture en a réellement besoin, sans l'imposer à un dépôt Android-only |
+| Composition Android + Gradle + Java seulement lorsqu'applicables                | `ADOPT`        | maintenir la composition explicite `600 + 610 + 522 [+ 520]`                                                                                    |
+| Matrice AGP / Gradle / JDK explicitement compatible                             | `ADOPT`        | conserver le principe et vérifier que la contrainte choisie reste la moins restrictive réellement démontrée                                     |
+| Séparation JDK de build / niveau Java                                           | `ADOPT`        | réutiliser les owners `520/522`, sans copier les versions Games                                                                                 |
+| Distinction `compileSdk` / `targetSdk` / `minSdk`                               | `ADOPT`        | conserver trois contrats séparés et justifier leurs changements selon leur responsabilité                                                       |
+| `VERSION` distinct du `versionName` de produits indépendants                    | `ADOPT`        | conserver la synchronisation uniquement lorsqu'un même release train la justifie                                                                |
+| État local, outputs Gradle et secrets hors Git                                  | `ADOPT`        | consolider `local.properties`, caches, build outputs et signing au bon owner                                                                    |
+| ABI déclarées et prouvées lorsqu'il existe du code natif                        | `ADOPT`        | garder le contrat conditionnel sans liste universelle                                                                                           |
+| APK/AAB, install et smoke sélectionnés selon le risque                          | `ADOPT`        | intégrer à la validation Android proportionnée, sans full matrix systématique                                                                   |
+| Chemin exact `Android/` de Games                                                | `KEEP-LOCAL`   | preuve d'un layout multi-plateforme valide, pas layout obligatoire de tout dépôt Android                                                        |
+| Groovy DSL                                                                      | `KEEP-LOCAL`   | `522-GRADLE.md` reste neutre Groovy/Kotlin DSL                                                                                                  |
+| Gradle système `>= 9.6.0` sans Wrapper                                          | `KEEP-LOCAL`   | choix Games compatible avec `522`; ne pas interdire ni imposer le Wrapper                                                                       |
+| AGP `9.4.0`, Gradle `9.7.1`, JDK `25.0.4.1`, Java `17`                          | `KEEP-LOCAL`   | valeurs de preuve, jamais minima PGR génériques                                                                                                 |
+| SDK `36/36/21`, NDK `r28c`, SDL3 `3.4.16`                                       | `KEEP-LOCAL`   | contraintes Games/framework/produit                                                                                                             |
+| Quatre ABI et cibles Rust correspondantes                                       | `KEEP-LOCAL`   | matrice produit/toolchain, pas contrat Android universel                                                                                        |
+| `cargo ndk`, bridge JNI, extraction SDL3 et staging `jniLibs`                   | `KEEP-LOCAL`   | spécialisation Rust/SDL/JNI hors du profil Android général                                                                                      |
+| Modules `common` / `game-*`, Activities, labels et assets                       | `KEEP-LOCAL`   | architecture produit Games                                                                                                                      |
+| Exemple PGR de layout contenant systématiquement `gradlew*`                     | `OVERRIDE`     | réviser l'exemple pour ne pas présenter le Wrapper comme élément structurel obligatoire                                                         |
+| Formulation PGR poussant `minSdk` « aussi bas que raisonnablement supportable » | `OVERRIDE`     | réexaminer vers un choix de compatibilité produit explicitement justifié, sans préférence artificielle vers le minimum le plus bas              |
+| Détail normatif 16 KB / page size                                               | `DEFER`        | vérifier les exigences Android/distribution officielles courantes avant normalisation ciblée                                                    |
+| Création d'un owner JNI/Rust Android                                            | `DEFER`        | aucun owner nouveau sans besoin générique démontré ; Games reste un corpus spécialisé                                                           |
+| Skeleton ou contrat de validation Android dédié                                 | `DEFER`        | décider seulement après révision de `610` et analyse des lacunes restantes                                                                      |
+| Skeleton Tauri                                                                  | `DEFER`        | réservé à `0.1.4`                                                                                                                               |
+| Adoption réelle de Games                                                        | `DEFER`        | réservée à `0.1.5`                                                                                                                              |
+
+## Décision après `alpha.1`
+
+La gate opérateur de `alpha.1` est `PASS`. Les `48/48` tests Python, les trois audits Markdown, l'audit structurel de la tranche et les contrôles Git sont propres ; aucun `alpha.1.fix.N` n'est requis.
+
+`alpha.2` peut donc appliquer les décisions déjà classifiées `ADOPT` / `OVERRIDE` pour les contrats Android de base, sans ouvrir le natif, le packaging de distribution ou les smokes réservés à `alpha.3`.
+
+### Vérification Android officielle courante pour `alpha.2`
+
+La documentation Android officielle courante a été vérifiée le `2026-09-28` sur les responsabilités touchées par cette tranche :
+
+```text
+https://developer.android.com/build/releases/agp-9-4-0-release-notes
+https://developer.android.com/build
+https://developer.android.com/build/jdks
+https://developer.android.com/build/configure-app-module
+https://developer.android.com/studio/publish/app-signing
+```
+
+Cette vérification confirme notamment :
+
+- AGP possède une matrice de compatibilité explicite avec Gradle et le JDK de build ; AGP `9.4.0` requiert actuellement au minimum Gradle `9.6.0` et JDK `17`, ce qui confirme la cohérence du corpus Games sans transformer ces valeurs en minima PGR ;
+- le JDK qui exécute Gradle/AGP est distinct du niveau de langage ou bytecode du code Java ; cette séparation reste nécessaire même lorsqu'un projet Android ne contient aucun source Java ;
+- `compileSdk`, `targetSdk` et `minSdk` ont des responsabilités distinctes : APIs disponibles à la compilation, comportements/runtime ciblés et plus ancien niveau Android réellement supporté ;
+- `namespace` et `applicationId` sont deux propriétés distinctes ; les garder identiques est le cas courant, mais leur divergence peut être volontaire et doit rester explicite ;
+- `local.properties` est réservé aux propriétés locales de l'environnement Android/AGP et doit rester hors du contrôle de version ; des propriétés locales propres au projet doivent utiliser un mécanisme séparé ;
+- les clés et mots de passe de signing sont des secrets ; le debug keystore généré par les outils reste un état local et ne constitue pas une identité de release à versionner.
+
+La vérification 16 KB n'est pas absorbée ici : elle reste explicitement réservée à `alpha.3`, avec sa propre confrontation aux exigences de distribution officielles courantes.
+
+### Scope arrêté pour `alpha.2`
+
+La tranche révise uniquement `610-ANDROID.md` pour :
+
+1. retirer du layout d'exemple toute présentation implicite du Wrapper comme élément obligatoire ;
+2. rendre Android neutre quant au langage applicatif et composer `520-JAVA.md` seulement lorsque du Java est réellement présent ;
+3. séparer clairement JDK de build AGP/Gradle et niveau Java du code ;
+4. reformuler `minSdk` comme contrat produit explicite, sans objectif artificiel de valeur la plus basse ;
+5. expliciter la séparation `namespace` / `applicationId` ;
+6. consolider le rôle de `local.properties`, des propriétés partagées et du signing sans recopier les owners généraux.
+
+Aucun template, skeleton, audit Python ou contrat `docs/validation/` n'est créé par cette tranche.
+
+## Décision après `alpha.2`
+
+La gate opérateur de `alpha.2` est `PASS`. Les `48/48` tests Python, les trois audits Markdown, l'audit Android de base et les contrôles Git sont propres ; aucun `alpha.2.fix.N` n'est requis.
+
+`alpha.3` peut donc traiter le natif, le packaging, la distribution et la validation Android sans rouvrir les contrats de base validés en `alpha.2`.
+
+### Vérification Android officielle courante pour `alpha.3`
+
+La documentation Android officielle courante a été vérifiée le `2026-09-28` sur les responsabilités touchées par cette tranche :
+
+```text
+https://developer.android.com/guide/practices/page-sizes
+https://developer.android.com/ndk/guides/abis
+https://developer.android.com/studio/write/lint
+https://developer.android.com/studio/test/command-line
+https://developer.android.com/build/building-cmdline
+https://developer.android.com/google/play/requirements/target-sdk
+```
+
+Cette vérification confirme notamment :
+
+- les politiques de distribution sont évolutives : depuis le `2026-08-31`, Google Play demande pour les applications Android ordinaires nouvelles ou mises à jour un `targetSdk` Android 16 / API `36` ou supérieur, mais cette valeur appartient au canal Play courant et ne devient pas un default PGR universel ;
+- Android 15 introduit les devices configurés avec pages mémoire `16 KB` ; une application composée uniquement de code Java/Kotlin est déjà compatible du point de vue de l'alignement natif, tandis que toute bibliothèque native directe ou transitive impose de vérifier le package réellement livré ;
+- pour Google Play, les applications ciblant Android 15 / API `35` ou supérieur doivent supporter les pages `16 KB` sur les appareils 64 bits ; la documentation courante annonce qu'à partir du `2027-02-01`, les mises à jour non compatibles ne pourront plus être publiées ;
+- pour une application native concernée, la preuve officielle couvre les segments ELF des bibliothèques 64 bits, l'alignement ZIP de l'APK et, pour un AAB, la configuration d'alignement du bundle ; les dépendances natives précompilées font partie du même contrat ;
+- AGP `8.5.1+` et NDK `r28+` rendent aujourd'hui le chemin 16 KB standard plus direct, mais PGR n'en déduit pas de minimum global : le projet doit choisir une toolchain compatible avec ses contraintes et prouver l'artefact final ;
+- Android Lint n'est pas exécuté automatiquement par un build ordinaire : lorsqu'il est applicable, il doit être appelé explicitement sur le module/variant pertinent ;
+- les tests JVM locaux et les tests instrumentés constituent des niveaux distincts ; l'instrumentation s'exécute sur device/émulateur et ne remplace pas à elle seule l'installation/smoke d'un package final lorsque le packaging ou le runtime sont dans le scope ;
+- l'APK reste l'artefact installable adapté aux smokes directs, tandis que l'AAB est un artefact de distribution qui entraîne la génération d'APK par le canal ; un AAB seul ne constitue donc pas une preuve runtime.
+
+La preuve Games `PAGE_SIZE=16384`, `align 2**14` et `zipalign -P 16` est cohérente avec ces exigences actuelles. Elle reste une preuve historique du corpus et n'est pas rejouée dans PGR, qui ne possède aucun build Android exécutable.
+
+### Scope arrêté pour `alpha.3`
+
+La tranche révise uniquement `610-ANDROID.md` pour :
+
+1. rendre NDK et ABI strictement conditionnels à la présence de code natif et séparer sélection de toolchain, ABI déclarées et preuve du package ;
+2. inclure les bibliothèques natives précompilées ou transitives dans les preuves de compatibilité ;
+3. clarifier le rôle d'Android Lint comme gate explicite et ciblée, non implicite au build ;
+4. préciser la frontière entre tests JVM, tests instrumentés et smokes device/AVD ;
+5. distinguer APK installable et AAB de distribution sans imposer un full packaging à chaque tranche ;
+6. normaliser le contrat 16 KB de manière conditionnelle au code natif et au canal de distribution, avec revalidation obligatoire des politiques évolutives ;
+7. conserver les détails JNI, Rust, SDL3, `cargo ndk`, les quatre ABI Games et les commandes spécifiques Games hors du profil Android général.
+
+Aucun owner JNI/Rust/SDL, skeleton Android, audit Python ou contrat `docs/validation/` n'est créé. La décision finale sur l'absence d'artefact supplémentaire reste réservée à `beta.1` après réconciliation.
+
+## Décision après `alpha.3` et réconciliation `beta.1`
+
+La gate opérateur de `alpha.3` est `PASS`. Les `48/48` tests Python, les trois audits Markdown, l'audit Android natif/distribution et les contrôles Git sont propres ; aucun `alpha.3.fix.N` n'est requis.
+
+La réconciliation beta relit le profil Android révisé contre le corpus Games, [`400-VALIDATION.md`](../rules/400-VALIDATION.md), [`520-JAVA.md`](../rules/520-JAVA.md), [`522-GRADLE.md`](../rules/522-GRADLE.md), [`600-PLATFORMS.md`](../rules/600-PLATFORMS.md) et la revue d'horizon. Elle ne rouvre aucun contrat fonctionnel déjà validé en `alpha.2` / `alpha.3`.
+
+### Résolution de la classification initiale
+
+Les décisions `ADOPT` sont couvertes par les owners existants : structure Android conditionnelle, composition de profils, compatibilité AGP/Gradle/JDK, séparation des niveaux SDK, versioning Android, configuration locale/signing, ABI conditionnelles et validation package/runtime proportionnée.
+
+Les décisions `KEEP-LOCAL` restent locales à Games : chemin concret `Android/`, Groovy DSL, Gradle système sans Wrapper, versions AGP/Gradle/JDK/Java, niveaux SDK, NDK `r28c`, quatre ABI, `cargo ndk`, bridge JNI, SDL3, modules, Activities, labels et assets. Aucune de ces valeurs ou stacks n'est devenue un `MUST` Android général.
+
+Les deux `OVERRIDE` initiaux sont résolus par `alpha.2` : l'exemple structurel ne présente plus `gradlew*` comme élément obligatoire et `minSdk` est désormais un contrat produit explicitement justifié plutôt qu'une course vers la valeur la plus basse.
+
+Le `DEFER` 16 KB a été levé en `alpha.3` après vérification des sources Android officielles courantes, sous forme d'un contrat conditionnel au code natif, au package et au canal de distribution ; aucune version d'outil ni échéance datée n'est transformée en default PGR universel.
+
+Les autres `DEFER` restent bornés : aucun owner JNI/Rust Android n'est justifié, Tauri reste réservé à `0.1.4` et l'adoption Games à `0.1.5`.
+
+### Décision finale d'artefacts Android
+
+Aucun artefact technique supplémentaire n'est justifié pour `0.1.3`.
+
+Ne sont donc pas ajoutés :
+
+```text
+docs/validation/006-ANDROID_VALIDATION.md
+skeleton Android
+template de build Android générique
+audit Python Android
+owner JNI / Rust Android / SDL
+```
+
+La raison est positive et vérifiable :
+
+- `400-VALIDATION.md` possède déjà la sélection proportionnée des preuves, les catégories `LINT`, `TEST`, `PACKAGE` et `SMOKE`, ainsi que l'autorité du gate opérateur ;
+- `600-PLATFORMS.md` possède la composition et la validation spécialisées des plateformes sans rendre chaque smoke obligatoire ;
+- `520-JAVA.md` et `522-GRADLE.md` restent composés uniquement lorsqu'ils sont applicables et évitent de recopier leurs contrats dans Android ;
+- `610-ANDROID.md` possède désormais les responsabilités spécifiques de SDK, identité applicative, signing, NDK/ABI, Android Lint, niveaux de tests, packaging APK/AAB, distribution et 16 KB ;
+- PGR ne contient aucun build Android exécutable qui justifierait aujourd'hui un skeleton, template ou audit spécialisé supplémentaire.
+
+Créer un artefact seulement pour refléter la structure de Games ou pour dupliquer `400 + 610` augmenterait la maintenance sans apporter de nouvelle preuve. Si un futur corpus démontre une lacune réutilisable, elle devra être traitée dans une tranche qui possède réellement ce scope.
+
+### Frontières après réconciliation
+
+La beta confirme donc :
+
+```text
+Android générique        600 + 610
+Gradle si utilisé        + 522
+Java si présent          + 520
+validation générale      400
+JNI / Rust / SDL         hors 610
+Tauri                    0.1.4
+adoption Games           0.1.5
+```
+
+La prochaine tranche peut être `rc.1` si la gate opérateur de `beta.1` confirme cette réconciliation. La RC devra geler le scope Android et préparer le prompt de reprise `0.1.4` sans commencer le réexamen Tauri.
+
+## Réévaluation initiale de `610-ANDROID.md`
+
+Le profil courant contient déjà une part importante des contrats démontrés par Games : structure conditionnelle, matrice AGP/Gradle/JDK, niveaux SDK séparés, version Android, configuration locale, signing, modules, dépendances, ABI conditionnelles, niveaux de tests, validation proportionnée, manifests/resources et artefacts APK/AAB.
+
+`0.1.3` ne doit donc pas réécrire ce profil pour produire du volume. La révision doit se concentrer sur les écarts réellement démontrés :
+
+1. rendre les exemples de structure neutres vis-à-vis du choix Wrapper/système déjà possédé par `522-GRADLE.md` ;
+2. confirmer qu'Android reste neutre quant au langage applicatif et n'active `520-JAVA.md` que lorsque Java est réellement présent ;
+3. rendre la politique `minSdk` explicitement orientée contrat produit/compatibilité plutôt que « minimum le plus bas » comme objectif en soi ;
+4. clarifier ownership Android versus build tool pour AGP, Gradle, JDK et propriétés locales ;
+5. mieux séparer NDK/ABI/package Android des détails JNI/Rust/SDL spécifiques ;
+6. intégrer uniquement les contraintes de distribution modernes réellement vérifiées et applicables, notamment 16 KB si les sources officielles courantes le justifient ;
+7. déterminer si le profil suffit à exprimer la validation Android ou si un contrat `docs/validation/` apporte une réduction réelle de duplication.
+
+## Mission de `0.1.3`
+
+La release doit produire un profil Android pratiquement éprouvé contre Games tout en restant utilisable par un projet Android qui ne ressemble pas à Games.
+
+Elle MUST :
+
+- conserver Android comme spécialisation de `600-PLATFORMS.md` ;
+- composer explicitement `522-GRADLE.md` et `520-JAVA.md` uniquement lorsqu'ils sont réellement applicables ;
+- distinguer build tool, SDK Android, compatibilité utilisateur et contraintes de distribution ;
+- traiter NDK et ABI uniquement pour les projets natifs ;
+- séparer les responsabilités Android des détails JNI, Rust, SDL, Tauri et produit ;
+- conserver manifests, resources, application identity, configuration locale, signing, packaging et validation chez le bon owner ;
+- sélectionner Android Lint, tests, package, install et smokes proportionnellement au changement ;
+- vérifier toute contrainte de distribution évolutive contre une source Android officielle courante avant de la figer dans PGR ;
+- ne créer un template, skeleton, audit ou contrat de validation supplémentaire que s'il matérialise un contrat réutilisable absent et démontré.
+
+Elle MUST NOT :
+
+- modifier ou adopter Games ;
+- transformer SDL3, `cargo ndk`, les Activities Games ou leur architecture produit en règles Android générales ;
+- rouvrir Java/Maven/Gradle `0.1.2` sans défaut transversal démontré ;
+- réexaminer ou créer le skeleton Tauri avant `0.1.4` ;
+- absorber les contraintes Tauri Android dans `610` sans preuve indépendante ;
+- démarrer l'adoption Games `0.1.5` ;
+- créer un owner WASM, serveur Rust, JNI ou deployment par proximité ;
+- réserver une release au-delà de `0.1.7` sans nouvelle revue d'horizon justifiée.
+
+## Artefacts candidats
+
+Owner normatif principal :
+
+```text
+docs/rules/610-ANDROID.md
+```
+
+Artefacts à décider, non promis par le plan :
+
+```text
+docs/validation/006-ANDROID_VALIDATION.md    seulement si 400 + 610 ne suffisent pas à éviter une duplication réelle
+docs/skeletons/...                           aucun skeleton Android par défaut
+scripts/audit_*.py                           aucun audit Android par symétrie
+templates/android/...                        aucun template de build sans sujet générique réellement éprouvé
+```
+
+Un skeleton Android n'est pas justifié par le seul fait que Games possède un projet Android. Il ne devient candidat que si la révision révèle un ensemble minimal, stable et réutilisable de décisions qu'un projet nouveau ne peut pas simplement obtenir des outils Android officiels et des owners PGR existants.
+
+## Trajectoire prévisionnelle de `0.1.3`
+
+### alpha.1 — audit de stable, corpus et plan
+
+Vérifier `v0.1.2`, son rapport `publish.001`, le corpus Games, ses preuves Android historiques, les owners `520`, `522`, `600`, `610` et la revue d'horizon. Créer le présent plan et la classification initiale sans modifier encore `610-ANDROID.md`.
+
+### alpha.2 — structure, composition et contrats Android de base
+
+Réviser `610-ANDROID.md` sur les points démontrés par le corpus : structure Android-only versus multi-plateforme, composition avec Gradle/Java, matrice AGP/Gradle/JDK sans duplication de `522`, responsabilités `compileSdk`/`targetSdk`/`minSdk`, versioning Android, namespaces/application IDs, manifests/resources, configuration locale et signing.
+
+Les valeurs exactes Games restent des exemples de preuve, pas des defaults PGR.
+
+### alpha.3 — natif, packaging, distribution et validation
+
+Réviser les responsabilités conditionnelles NDK/ABI/native packaging, APK/AAB, Android Lint, tests JVM/instrumentés, install/smoke device/AVD et contraintes de distribution applicables.
+
+Avant toute règle évolutive telle que 16 KB, confronter la preuve Games à la documentation Android officielle courante et rédiger le contrat de manière conditionnelle au canal de distribution et au type d'artefact réellement concernés.
+
+Ne pas créer d'owner JNI/Rust/SDL. Si un contrat de validation séparé apparaît réellement nécessaire, déclencher un REPLAN avant la beta plutôt que l'ajouter opportunément.
+
+### beta.1 — réconciliation et décision d'artefacts
+
+Relire le profil Android révisé contre Games, `520-JAVA.md`, `522-GRADLE.md`, `600-PLATFORMS.md`, `400-VALIDATION.md` et la revue d'horizon.
+
+Vérifier qu'aucun choix Games n'est devenu un `MUST` général, que les contraintes natives restent conditionnelles, et que le futur réexamen Tauri dispose d'une frontière Android stable sans avoir été commencé.
+
+Décider explicitement qu'aucun artefact supplémentaire n'est nécessaire si `610` et les owners existants suffisent. Un artefact nouveau qui exigerait du contenu fonctionnel supplémentaire entraîne un REPLAN vers une tranche alpha dédiée.
+
+Statut opérateur : **PASS**.
+
+La gate beta confirme `48/48` tests Python, les trois audits Markdown, la réconciliation des owners et l'absence d'artefact Android supplémentaire justifié. Aucun fix ni REPLAN n'est requis.
+
+### rc.1 — release candidate
+
+Statut opérateur : **PASS**.
+
+La gate RC a confirmé les quatre histories antérieurs `PASS`, le profil Android gelé en révision `5`, le changelog candidat, le prompt `010`, les `48/48` tests, les trois audits Markdown et l'hygiène texte/templates. Aucun owner Android/Java/Gradle/Tauri, template, skeleton, validation, étude technique ou script n'a été modifié pendant la RC.
+
+Le prompt `010-V0_1_4_START_PROMPT.md` conserve la frontière de release : le réexamen Tauri démarre en `0.1.4` seulement depuis une stable `v0.1.3` réellement taggée et son rapport post-tag `PASS`; l'adoption Games reste `0.1.5` et l'adoption KSP `0.1.6`.
+
+### rel.1 — promotion stable
+
+Première clôture stable de `0.1.3`. La promotion est strictement mécanique : `VERSION = 0.1.3`, `ROADMAP.md` marque `0.1.3` terminée, le `CHANGELOG` perd son marqueur `candidate`, README/index décrivent la réévaluation Android comme stable et le présent plan devient historique. Aucun owner Android/Java/Gradle/Tauri, template, skeleton, validation, étude technique ou script n'est modifié.
+
+Le résultat opérateur de cette tranche appartient à `history/0.1.3/rel.1.md`, créé seulement après exécution de la gate. Si `rel.1` échoue, son history est conservé et un `rel.1.fix.N` corrige uniquement la fermeture ; la première tranche qui établit réellement la stable est incluse dans le commit `0.1.3` avant le tag `v0.1.3`.
+
+La vérification post-tag reste séparée : `pgr-0.1.3-publish.001-report.md` ne peut être produit qu'à partir de l'archive du tag réellement publiée et des preuves Git observées. Le prompt `010` ne devient le point de départ effectif de `0.1.4` qu'après cette preuve post-tag `PASS`.
+
+## Stratégie de validation
+
+`alpha.1` reste documentaire et structurel : tests Python PGR, audits Markdown, contrôle des couples delta/history, vérification du prompt `009`, des owners `520/522/600/610`, du plan et du scope Git.
+
+PGR lui-même ne contient aucun projet Android exécutable. Une modification de `610-ANDROID.md` ne doit donc pas simuler un build AGP/Gradle/SDK absent du dépôt PGR.
+
+Les preuves Games historiques servent à démontrer des responsabilités et des frontières ; elles ne deviennent pas une gate PGR locale et ne doivent pas être présentées comme si les APK/AAB avaient été reconstruits pendant `0.1.3`.
+
+Lorsqu'une propriété relève d'un build Android réel, les outils officiels restent autoritaires : Gradle/AGP, Android Lint, SDK/NDK, outils de packaging, installation et device/AVD selon le contrat à prouver. Un audit Python read-only ne remplace aucun de ces outils.
+
+La validation reste proportionnée : pas de `clean` systématique, pas de full matrix ABI/device pour un changement documentaire, pas de signing release pour une tranche qui ne valide pas la distribution signée.
+
+## Déclencheurs de REPLAN
+
+Un REPLAN est requis notamment si :
+
+- la révision montre qu'une responsabilité aujourd'hui dans `610` appartient en réalité à un owner séparé nécessaire immédiatement ;
+- un contrat de validation Android séparé apporte une valeur concrète que `400 + 610` ne peuvent pas exprimer sans duplication ;
+- un skeleton Android réellement réutilisable devient nécessaire et peut être démontré sans copier Games ;
+- une contrainte supposée Android générale dépend en réalité de SDL, Rust, JNI, Tauri ou d'un canal de distribution particulier ;
+- une exigence Android officielle courante contredit une règle `610` existante ;
+- la release ne peut pas rester bornée sans absorber le scope Tauri `0.1.4` ou l'adoption Games `0.1.5`.
+
+Un REPLAN ne sert pas à ajouter des artefacts pour remplir la release ; il corrige le découpage lorsqu'une responsabilité réelle l'exige.
+
+## Clôture et transition
+
+La roadmap possède déjà un horizon suffisant jusqu'à `0.1.7`. Aucune nouvelle release n'est réservée par `0.1.3-alpha.1`.
+
+Le présent document devient le plan historique de la stable `0.1.3`. La publication du tag et sa vérification post-tag restent séparées de cette clôture pré-tag.
+
+La prochaine release après publication vérifiée de `0.1.3` reste :
+
+```text
+0.1.4 — domaine Tauri : réexamen du DEFER et matérialisation du skeleton contrôlé seulement si les conditions de sortie sont réellement satisfaites
+```
+
+L'adoption réelle de Games reste ensuite réservée à `0.1.5`, afin qu'elle puisse comparer son état local avec une stable Android et une stable Tauri réellement publiées.

docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md

@@ -0,0 +1,433 @@
+<!-- file: docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md -->
+<!-- version: 6 -->
+
+# Plan 0.1.4 — réexamen Tauri et skeleton contrôlé
+
+## Statut et sources
+
+Plan historique de la stable `0.1.4`, créé pendant `0.1.4-alpha.1` conformément à `prompts/010-V0_1_4_START_PROMPT.md`, après audit indépendant de la stable taggée `v0.1.3`, de son rapport post-tag `PASS` et des corpus Games/KSP réellement fournis.
+
+Sources autoritaires de reprise PGR réellement fournies :
+
+```text
+pgr-v0.1.3(1).zip                  f3a7dffd5fe0fd3542e6b5207fda0b94bca2bd05bd5a54542d0a08d635a5d6ee
+pgr-0.1.3-publish.001-report.md    5405a1d6c216a5882c4638c07d573d50d440ce9e4e892d97f425e99054245544
+```
+
+Le nom local de l'archive PGR comporte `(1)`, mais son SHA-256 correspond exactement à l'archive canonique `pgr-v0.1.3.zip` enregistrée par le rapport `publish.001`. Le rapport est `PASS`, porte sur cette même archive et confirme le commit stable `fe80dbbb737390a7ea99df27d979bd59ccfb86e3`. Le tag annoté `v0.1.3` possède l'objet tag `9b3667f622ab6ef86c1301f8cfa2301b561a0124` et se déréférence vers ce commit stable.
+
+Corpus externes réellement fournis pour instruire Tauri :
+
+```text
+games-v0.3.6(3).zip                        ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
+khadhroony-solana-project-v0.3.19(1).zip   64a3813620925fa4f8914cdf74113399cfdd78ad51d60bbeff9bafbddcf4b253
+```
+
+Le SHA-256 Games correspond exactement à la baseline canonique `games-v0.3.6.zip` déjà enregistrée par le prompt de reprise. KSP `0.3.19` est plus récent que la référence historique `0.3.17` citée par le prompt ; il est donc le corpus KSP courant de cette session. L'archive KSP fournie ne possède pas de rapport post-tag associé dans les sources de cette reprise : elle est utilisée comme corpus autoritaire fourni, sans lui attribuer de preuve Git absente.
+
+## Audit de la stable `v0.1.3`
+
+### Intégrité et publication
+
+L'archive PGR contient `332` entrées sous une racine unique `pgr/`, soit `290` fichiers et `42` répertoires. Son CRC est propre, aucun lien symbolique n'est présent et `.git` est absent comme attendu pour une archive de tag Gitea.
+
+`VERSION` vaut exactement `0.1.3`. Le rapport post-tag confirme la cohérence de la stable, la présence du prompt `010`, la clôture de `0.1.3` par `rel.1` et le maintien de `0.1.4` à `0.1.7` sans réservation supplémentaire.
+
+### Gates rejouées
+
+La suite Python et les audits documentaires ont été rejoués directement depuis l'archive extraite :
+
+```text
+48 / 48 tests PASS
+Markdown header audit: clean (264 file(s))
+Markdown table audit:  clean (11 table(s), 264 file(s))
+Markdown link audit:   clean (337 local link(s), 264 file(s))
+```
+
+La stable fournie est donc une base saine pour ouvrir `0.1.4-alpha.1`.
+
+## Préconditions PGR du réexamen
+
+Le report historique de `docs/studies/002-TAURI_SKELETON_DECISION.md` demandait cinq familles de responsabilités avant tout nouveau jugement sur un skeleton Tauri :
+
+1. TypeScript et conventions Web contrôlées ;
+2. Vite et ownership des commandes, du dev server et des outputs ;
+3. Sass/CSS et statut des artefacts générés ;
+4. validation frontend indépendante de la validation Tauri ;
+5. framework CSS classé comme décision de skeleton/projet et non comme règle Tauri.
+
+La préparation effectuée en `0.1.1-beta.1` avait déjà constaté ces cinq conditions couvertes. La relecture de la stable `0.1.3` confirme qu'elles le restent au travers des owners `530/540/550/560`, de `005-WEB_FRONTEND_VALIDATION.md` et de `003-WEB_FRONTEND.md`.
+
+Conclusion `alpha.1` :
+
+```text
+conditions historiques de sortie     SATISFIED
+réexamen du candidat                  autorisé
+création automatique                  interdite
+ancien motif Web du DEFER             levé
+jugement sur le skeleton              à instruire par le corpus courant
+```
+
+Le `DEFER` historique n'est donc pas reconduit par inertie. Son motif bloquant Web est levé, mais cette levée ne suffit pas à elle seule à créer le skeleton.
+
+## Audit du corpus Tauri courant
+
+### Intégrité des archives
+
+Les trois archives PGR, Games et KSP sont CRC-propres et ne contiennent aucun lien symbolique.
+
+Games `0.3.6` contient `652` entrées sous `games/`, soit `502` fichiers et `150` répertoires. Ses audits statiques rejoués sont propres :
+
+```text
+General Rust rule audit: clean
+Rust export completeness audit: 0 candidate(s)
+games.sasedev workspace audit: clean
+Markdown table audit: clean (6 table(s), 317 file(s))
+Distribution layout audit: clean (55 required path(s), 11 forbidden path(s) absent)
+```
+
+KSP `0.3.19` contient `2369` entrées sous `khadhroony-solana-project/`, soit `2146` fichiers et `223` répertoires. Ses audits statiques rejoués sont propres :
+
+```text
+General Rust rule audit: clean
+Rust export completeness audit: 0 candidate(s)
+KSP workspace Rust rule audit: clean
+Markdown table audit: clean (353 table(s), 1029 file(s))
+```
+
+Ces audits attestent la cohérence structurelle des corpus fournis. Ils ne constituent pas une adoption PGR de Games ou KSP.
+
+### Inventaire des hosts actuels
+
+Games `0.3.6` possède désormais un seul host Tauri courant :
+
+```text
+crates/apps/game-snake-poc-tauri
+```
+
+KSP `0.3.19` possède six hosts Tauri courants :
+
+```text
+crates/ksp-app-backfill-desk
+crates/ksp-app-config-desk
+crates/ksp-app-raw-transaction-ingest-desk
+crates/ksp-app-solprices-desk
+crates/ksp-app-store-desk
+crates/ksp-app-wallet-desk
+```
+
+Le corpus courant contient donc `7` hosts, contre `8` dans l'étude historique `0.0.5` : Games est passé de deux hosts observés à un seul. Le réexamen ne doit donc pas recopier mécaniquement l'inventaire historique.
+
+### Convergences structurelles observées
+
+Les sept hosts actuels convergent sur une ossature directe à la racine de la crate :
+
+```text
+Cargo.toml
+build.rs
+package.json
+tsconfig.json
+tauri.conf.json
+vite.config.ts
+capabilities/
+src/lib.rs
+src/main.rs
+src/tauri.rs
+frontend/
+```
+
+Aucun de ces sept hosts n'utilise `src-tauri/`. Tous sont des crates Cargo mixtes `lib + bin`, utilisent un frontend privé TypeScript/Vite et raccordent le dev/build frontend au host Tauri.
+
+Cette convergence justifie une convention organisationnelle PGR pour les nouveaux projets contrôlés. Elle ne démontre pas que `src-tauri/` serait invalide ou non supporté par Tauri, ni que toute application Tauri existante devrait migrer.
+
+### Divergences significatives
+
+KSP exerce communément Bootstrap, Sass et TS-RS dans ses desks actuels. Games ne les exerce pas comme bloc équivalent dans son host courant et possède en plus une chaîne WASM spécifique au jeu.
+
+Les corpus divergent également sur les plugins, fenêtres, identifiers, ports de dev server, ressources/bundles et détails de capabilities. Le Store Desk KSP possède notamment un contrat de commandes/permissions plus riche que les autres hosts.
+
+Ces divergences empêchent de transformer le bloc historique `frontend/ + Vite + TypeScript + Sass + Bootstrap + TS-RS` en baseline Tauri universelle.
+
+## Vérification officielle Tauri 2 courante
+
+La documentation Tauri 2 officielle a été réexaminée pendant `alpha.1` sur les points susceptibles d'avoir évolué.
+
+Constats retenus :
+
+- la structure documentée par Tauri présente `src-tauri/` comme layout typique/scaffold, tandis que la configuration Tauri et le projet Rust restent les éléments fonctionnels déterminants ; PGR peut donc conserver une convention différente pour ses projets contrôlés sans déclarer le layout standard invalide ;
+- les capabilities et permissions sont une frontière de sécurité active ; l'enregistrement d'une commande native et l'autorisation de son appel depuis le frontend ne doivent pas être confondus ;
+- lorsque la sélection explicite des capabilities n'est pas configurée, les fichiers de capability du répertoire de capabilities peuvent être activés automatiquement selon la configuration Tauri courante ; un skeleton contrôlé doit donc rendre cette surface visible et revue ;
+- le CLI Tauri supporte plusieurs launchers/package managers et possède toujours des commandes de commodité, dont l'ajout de plugins et les workflows mobiles ; PGR n'a aucune raison d'imposer npm ni `cargo tauri add` ;
+- les templates mobiles Tauri évoluent avec l'écosystème plateforme ; les versions Gradle/Kotlin/SDK observées dans une release Tauri ne doivent pas devenir des constantes PGR universelles.
+
+Références officielles vérifiées le `2026-09-29` :
+
+- <https://v2.tauri.app/start/project-structure/>
+- <https://v2.tauri.app/security/capabilities/>
+- <https://v2.tauri.app/security/permissions/>
+- <https://v2.tauri.app/reference/cli/>
+- <https://v2.tauri.app/blog/tauri-2-12-0/>
+
+## Classification initiale `alpha.1`
+
+### `ADOPT`
+
+Sont retenus pour le candidat organisationnel PGR :
+
+- composition explicite avec `001-PROJECT_GOVERNANCE_FOUNDATION`, `002-RUST_CARGO_WORKSPACE`, `003-WEB_FRONTEND` et `710-TAURI` au lieu de dupliquer leurs règles ;
+- host Cargo direct `lib + bin` sans couche `src-tauri/` ajoutée uniquement pour reproduire un scaffold, pour les nouveaux projets que PGR contrôle entièrement ;
+- `build.rs`, `tauri.conf.json`, `capabilities/` et `src/tauri.rs` comme surface Tauri visible de cette convention ;
+- `frontend/` comme layout recommandé du skeleton contrôlé, sans en faire une obligation Tauri universelle ;
+- TypeScript + Vite comme baseline Web recommandée du skeleton lorsque le projet ne possède pas déjà un autre choix frontend motivé ;
+- validation frontend indépendante avant preuve d'intégration Tauri lorsque la modification touche les deux surfaces ;
+- revue explicite des capabilities, permissions, commandes natives et plugins comme surface de sécurité ;
+- ajout manuel/revu des plugins comme voie canonique du skeleton contrôlé, tout en autorisant les commandes de commodité lorsqu'elles apportent une valeur réelle et que leurs modifications sont relues ;
+- WASM séparé du host Tauri par défaut ;
+- composition des owners Android/iOS applicables pour les cibles mobiles au lieu de transférer ces responsabilités à `710`.
+
+### `KEEP-LOCAL`
+
+Restent des décisions de projet ou de produit :
+
+- ports `devUrl`, identifiers, titres et dimensions de fenêtres ;
+- CSP, icônes, bundle targets, resources et chemins spécifiques imposés par un produit ;
+- Bootstrap et Sass lorsque réellement utiles ;
+- TS-RS uniquement lorsqu'une frontière DTO Rust/TypeScript possédée par le host existe, conformément au profil strict ;
+- plugins concrets tels que tracing, filesystem ou autres ;
+- chaîne WASM Games et ses scripts ;
+- fenêtres auxiliaires, splash screens et ACL spécifiques comme celles exercées par certains desks KSP ;
+- versions concrètes Tauri, Vite, TypeScript, Bootstrap, Sass, plugins et toolchains plateforme.
+
+### `OVERRIDE`
+
+Le candidat historique est corrigé sur les points suivants :
+
+- le bloc `frontend/ + Vite + TypeScript + Sass + Bootstrap + TS-RS` n'est plus traité comme une seule baseline indivisible ; seuls les éléments justifiés par le skeleton et les owners applicables sont sélectionnés ;
+- l'absence de champ `version` dans des `tauri.conf.json` observés n'annule pas la politique PGR `CANONICAL / MIRROR-EXACT / MIRROR-STABLE` ; la stratégie de version reste explicite ;
+- une capability présente dans le dépôt n'est pas considérée comme suffisamment sûre par sa seule existence : sélection, fenêtres/webviews, permissions et commandes doivent être revues comme un contrat de sécurité ;
+- l'absence de `src-tauri/` devient une convention organisationnelle des nouvelles baselines PGR contrôlées, pas une règle prétendant que Tauri exige cette absence.
+
+### `DEFER`
+
+Restent différés faute de besoin démontré :
+
+- template technique Tauri copiable contenant `tauri.conf.json`, `build.rs` ou des capabilities génériques ;
+- contrat de validation Tauri séparé de `400-VALIDATION.md`, `005-WEB_FRONTEND_VALIDATION.md` et `710-TAURI.md` ;
+- framework CSS universel ;
+- catalogue de plugins, fenêtres ou permissions par défaut ;
+- owner serveur Rust, deployment/operations ou iOS créé par proximité ;
+- valeurs Android/Gradle/Kotlin/SDK/ABI dérivées des templates Tauri courants ;
+- migration ou adoption de Games/KSP, réservées respectivement à `0.1.5` et `0.1.6`.
+
+## Décision de cadrage `alpha.1`
+
+Le corpus courant démontre une convergence suffisante pour retenir **un skeleton Tauri organisationnel comme candidat à matérialiser pendant `0.1.4`**, sous réserve de la réconciliation normative préalable de `710-TAURI.md` et de l'étude historique.
+
+La décision est donc :
+
+```text
+ancien DEFER pour absence d'owners Web     LIFT
+candidat de skeleton organisationnel        ADOPT FOR MATERIALIZATION
+création dans alpha.1                       NO
+normalisation des choix locaux              NO
+```
+
+`alpha.1` ne crée volontairement pas `docs/skeletons/004-TAURI.md`. La tranche suivante doit d'abord consolider le contrat Tauri actuel, notamment la frontière commandes/capabilities/permissions et la formulation des conventions organisationnelles face aux possibilités officiellement supportées.
+
+## Gate `alpha.1` acquise
+
+La gate opérateur exécutée le `2026-09-29` est `PASS` : `48/48` tests Python, `266` fichiers Markdown propres, `343` liens locaux propres, audit structurel `96` couples antérieurs / `7` hosts Tauri propre et scope Git exactement conforme au delta.
+
+Le history `history/0.1.4/alpha.1.md` enregistre cette preuve. Aucun `alpha.1.fix.N` n'est requis.
+
+## Réconciliation normative préparée en `alpha.2`
+
+La tranche `alpha.2` resserre le profil `710` sur les responsabilités Tauri réellement possédées : host, orchestration, configuration, ACL/capabilities, plugins, intégration frontend et packaging. Elle retire du profil Tauri le choix direct de la stack Web déjà possédée par les owners `530/540/550/560` et par `003-WEB_FRONTEND.md`.
+
+Décisions préparées pour la gate :
+
+```text
+710-TAURI.md                              version 7
+002-TAURI_SKELETON_DECISION.md           version 3
+commande / permission / capability       séparées
+sélection des capabilities               décision de sécurité explicite
+src-tauri/                                supporté, non imposé
+host Cargo direct                         SHOULD pour nouvelle baseline contrôlée
+TypeScript / Vite / Sass / Bootstrap     owners Web / skeleton, pas owner Tauri
+TS-RS                                     conditionnel à la frontière typée réelle
+template Tauri                            DEFER
+validation Tauri séparée                  DEFER
+004-TAURI.md                              toujours absent pendant alpha.2
+```
+
+La décision historique `DEFER` de `0.0.5-alpha.9` reste conservée comme preuve historique, mais son motif Web est levé. L'étude révisée autorise donc `alpha.3` à matérialiser la specification `004-TAURI.md` si la présente gate reste propre.
+
+## Gates `alpha.2` et `alpha.2.fix.1` acquises
+
+`alpha.2` a validé la réconciliation normative Tauri mais a été enregistrée `FAIL` à cause d'une ligne vide surnuméraire à EOF. `alpha.2.fix.1` a corrigé ce défaut et ajouté `PGR-TEXT-HYGIENE-001` ; sa gate opérateur est `PASS` avec `55/55` tests, audit texte propre sur `297` fichiers et audits Markdown propres.
+
+Après cette gate, un défaut distinct de livraison a été identifié : deux archives remises contenaient un répertoire englobant `pgr/` au lieu d'entrées directement relatives à la racine. Le contenu du dépôt validé n'est pas affecté, mais `alpha.3` durcit `210-WORKFLOW.md` afin d'interdire ce packaging et impose au générateur de vérifier la liste des entrées avant remise.
+
+## Matérialisation préparée en `alpha.3`
+
+`alpha.3` matérialise `docs/skeletons/004-TAURI.md` comme specification organisationnelle. Elle compose les skeletons `001/002/003` et l'owner `710`, rend explicites versions, frontend, package manager, capabilities, permissions, plugins, fenêtres, bundles et cibles plateforme, puis définit un ordre d'initialisation et une validation proportionnée.
+
+Aucun template technique Tauri n'est créé : `tauri.conf.json`, les manifests, capability files et sources Tauri restent trop dépendants des décisions du projet pour justifier une baseline copiable universelle à ce stade. Cette décision sera réexaminée en `beta.1` conformément au plan.
+
+## Gate `alpha.3` acquise
+
+La gate opérateur de `alpha.3` est `PASS` : `55/55` tests, audit d'hygiène texte propre sur `300` fichiers, audits Markdown propres, audit structurel du skeleton propre et scope Git conforme. `docs/skeletons/004-TAURI.md` est donc la specification Tauri active pour la suite de `0.1.4`.
+
+Aucun template technique Tauri ni contrat `006-TAURI_VALIDATION.md` n'a été créé. Le contrat ZIP racine est désormais explicite dans `210-WORKFLOW.md`.
+
+## Réconciliation d'artefacts préparée en `beta.1`
+
+Le réexamen de l'ensemble `710 + 004 + 003 + 005` ne met en évidence aucune responsabilité Tauri sans owner :
+
+```text
+host / orchestration / ACL / plugins          710-TAURI.md
+instanciation et décisions de composition     004-TAURI.md
+frontend                                      003-WEB_FRONTEND.md + owners Web
+validation frontend                           005-WEB_FRONTEND_VALIDATION.md
+validation Rust / plateforme                  owners correspondants
+workflow de gate                              400-VALIDATION.md + matrice 001
+```
+
+Décisions préparées pour la gate `beta.1` :
+
+```text
+004-TAURI.md                                  KEEP
+template technique Tauri générique           DO NOT CREATE
+006-TAURI_VALIDATION.md                       DO NOT CREATE
+catalogue plugins/capabilities                DO NOT CREATE
+dry-run exécutable d'un faux projet           NOT REQUIRED
+audit statique de composition                 REQUIRED
+```
+
+Un template technique créerait nécessairement des identifiants, hooks frontend, capabilities, plugins, fenêtres, bundle targets ou valeurs de plateforme arbitraires. Le skeleton possède précisément ces décisions afin de les laisser au projet destinataire.
+
+Un contrat de validation Tauri séparé dupliquerait `710`, `004`, `005` et les owners Rust/plateforme. Une nouvelle famille de validation ne sera justifiée que lorsqu'une preuve Tauri répétitive non correctement possédée par ces documents apparaîtra dans un corpus réel.
+
+Le dry-run exécutable d'un projet factice n'est pas requis pour valider une specification qui ne fournit volontairement aucun scaffold technique. La preuve pertinente en `beta.1` est une vérification statique de composition : références existantes, ownership non dupliqué, décisions visibles, absence de placeholders et absence d'artefacts créés par symétrie.
+
+## Gate `beta.1` acquise
+
+La gate opérateur de `beta.1` est `PASS` : `55/55` tests, audit d’hygiène texte propre sur `302` fichiers, audits Markdown propres, audit structurel d’artefacts propre et scope Git conforme. `004-TAURI.md` est confirmé suffisant ; aucun template technique Tauri, contrat `006-TAURI_VALIDATION.md` ou dry-run factice n’est ajouté.
+
+## Revue d’horizon préparée en `rc.1`
+
+La revue exigée par le point transversal est matérialisée dans `docs/studies/004-V0_1_4_HORIZON_REVIEW.md`. Elle conclut qu’une release de gouvernance/autonomie doit précéder les adoptions Games/KSP afin de ne pas propager une sémantique `SHOULD` ambiguë ni une relation implicite d’upstream avec PGR.
+
+Trajectoire décidée :
+
+```text
+0.1.5   sémantique normative + autonomie + frontière PGR/Knowledge
+0.1.6   adoption Games
+0.1.7   adoption KSP
+0.1.8   audits Rust/Clippy read-only
+```
+
+La RC ne modifie pas encore les owners normatifs concernés : `RULES.md`, `230-ADOPTION.md`, `400-VALIDATION.md`, le skeleton de fondation et les templates de reprise restent gelés pour `0.1.4`. Le prompt `011` transmet explicitement leur réexamen à `0.1.5-alpha.1`.
+
+## Gate `rc.1` acquise et promotion stable
+
+La gate opérateur de `rc.1` est `PASS` : `55/55` tests, audit d’hygiène texte propre sur `306` fichiers, audits Markdown propres, audit d’intégration RC propre et scope Git conforme. La trajectoire `0.1.5` à `0.1.8` et le prompt `011` sont donc gelés pour la clôture.
+
+`rel.1` effectue uniquement la promotion mécanique vers `0.1.4` : version stable, roadmap terminée, changelog sans marqueur `candidate`, README/index en état stable et présent plan classé historique. Aucun owner Tauri, skeleton, étude technique, audit ou contrat de la future `0.1.5` n’est modifié.
+
+Le history `history/0.1.4/rel.1.md` sera créé uniquement après la gate pré-tag. Après son `PASS`, le commit stable `0.1.4`, le tag annoté `v0.1.4`, l’archive Gitea et le rapport externe `pgr-0.1.4-publish.001-report.md` pourront être produits conformément au workflow.
+
+## Point transversal découvert pendant la gate `alpha.1`
+
+L'utilisation de PGR pour initialiser SaseDev Knowledge a fait apparaître trois questions de gouvernance qui dépassent le domaine Tauri :
+
+1. `SHOULD / SHOULD NOT` doit exprimer une forte recommandation non obligatoire, distincte d'un `MUST`, sans transformer automatiquement son écart en échec de gate ou en `OVERRIDE` ;
+2. une adoption/instanciation PGR doit produire un projet autonome dont les sessions suivantes utilisent ses propres règles comme autorité, sans rechercher automatiquement une version PGR plus récente ;
+3. lorsque SaseDev Knowledge sera suffisamment fonctionnel, PGR devra pouvoir rester concentré sur les contrats de gouvernance réutilisables tandis que howtos, recettes et snippets pratiques vivent dans Knowledge, sans rendre PGR dépendant de Knowledge pour comprendre une règle.
+
+Ces constats ne constituent pas un défaut du cadrage Tauri `alpha.1` et ne sont donc pas absorbés dans `alpha.2`. Ils MUST être repris dans la revue d'horizon de fermeture de `0.1.4` avant de générer le prompt de la release suivante, afin de décider explicitement si la trajectoire `0.1.5+` doit être réordonnée avant les adoptions Games/KSP.
+
+## Trajectoire de `0.1.4`
+
+### `alpha.1` — intake, audit et décision de cadrage
+
+Objectifs :
+
+- auditer la stable `v0.1.3` et le rapport post-tag `PASS` ;
+- auditer les corpus Games/KSP fournis et inventorier leurs hosts Tauri actuels ;
+- rejouer les audits statiques disponibles ;
+- vérifier les préconditions historiques du report ;
+- confronter le corpus à la documentation Tauri 2 courante ;
+- classifier `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
+- décider si le skeleton reste un candidat justifié, sans le créer.
+
+Sortie attendue : présent plan et cadrage validé par la gate opérateur.
+
+### `alpha.2` — réconciliation normative Tauri
+
+Réexaminer `docs/rules/710-TAURI.md` et `docs/studies/002-TAURI_SKELETON_DECISION.md` à partir du cadrage validé.
+
+La tranche doit notamment :
+
+- distinguer clairement commande enregistrée, permission et capability ;
+- rendre explicite la politique de sélection/revue des capability files ;
+- conserver `src-tauri/` comme possibilité supportée et l'absence de `src-tauri/` comme convention organisationnelle PGR contrôlée ;
+- maintenir TypeScript/Vite/frontend/Sass/Bootstrap/TS-RS dans leurs owners appropriés ;
+- conserver une validation proportionnée plutôt qu'un `tauri build` systématique ;
+- ne créer encore aucun template ou owner par symétrie.
+
+### `alpha.3` — skeleton Tauri contrôlé
+
+Si `alpha.2` confirme l'absence de défaut bloquant, créer `docs/skeletons/004-TAURI.md` comme specification organisationnelle composable.
+
+Le skeleton devra :
+
+- composer la fondation, Rust/Cargo, Web et Tauri sans recopier les règles ;
+- séparer décisions obligatoires, recommandations de baseline et options ;
+- rendre visibles versions, package manager, frontend, capabilities, plugins, fenêtres/bundle et cibles plateforme ;
+- définir un ordre d'initialisation et une gate initiale proportionnée ;
+- ne créer de template technique supplémentaire que si un besoin non couvert est démontré pendant l'instanciation de la specification.
+
+### `beta.1` — réconciliation et décision d'artefacts
+
+Rejouer le plan contre l'ensemble des artefacts `0.1.4`, rechercher doublons et ownership caché, puis décider explicitement :
+
+- si un template technique Tauri apporte une valeur nette ;
+- si un contrat de validation Tauri séparé est nécessaire ;
+- si la documentation Tauri et les skeletons existants suffisent ;
+- si un dry-run local de la specification est nécessaire et réalisable avec les toolchains présentes.
+
+Par défaut, l'absence de lacune démontrée signifie **ne pas créer** d'artefact supplémentaire.
+
+### `rc.1` — freeze et handoff
+
+Effectuer la gate RC, geler le scope de `0.1.4` et préparer le `CHANGELOG.md` candidate. Avant de générer le prompt de la release suivante, effectuer une revue d'horizon qui traite explicitement le point transversal découvert après `alpha.1`.
+
+Si cette revue confirme la trajectoire existante, le prompt suivant ouvre `0.1.5` pour l'adoption Games. Si elle démontre qu'une release de gouvernance/autonomie doit précéder les adoptions, le roadmap et les numéros suivants sont réordonnés explicitement à ce moment-là plutôt que contournés silencieusement.
+
+### `rel.1` — stable
+
+Promouvoir `0.1.4`, finaliser `README.md`, `ROADMAP.md`, `CHANGELOG.md` et les index concernés, puis suivre le workflow commit stable, tag annoté et rapport post-tag externe.
+
+## Frontières de release
+
+`0.1.4` ne migre ni Games ni KSP et ne modifie pas leurs archives. Les observations de ces corpus servent uniquement à éprouver les abstractions PGR.
+
+La release ne rouvre pas Android `0.1.3` en l'absence de défaut transversal démontré. Les détails générés des projets Android/iOS Tauri restent composés avec leurs owners de plateforme lorsqu'ils sont applicables.
+
+La revue d’horizon de fermeture confirme que le besoin transversal est prioritaire et réordonne explicitement la trajectoire : `0.1.5` gouvernance/autonomie, `0.1.6` Games, `0.1.7` KSP et `0.1.8` audits Rust. Aucun numéro au-delà de `0.1.8` n’est réservé. Le `CHANGELOG.md` candidat et le `ROADMAP.md` sont mis à jour en RC parce qu’ils décrivent désormais une décision de fermeture acquise, pas une hypothèse prématurée.
+
+## Gate de sortie du plan
+
+Le passage de `alpha.1` à `alpha.2` exige :
+
+- intégrité de la baseline PGR et correspondance avec `publish.001 PASS` confirmées ;
+- corpus Games/KSP identifiés par leurs SHA-256 réels ;
+- inventaire des sept hosts courants vérifié ;
+- conditions historiques de sortie explicitement confirmées couvertes ;
+- classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` relue ;
+- aucune matérialisation prématurée de `004-TAURI.md` ;
+- aucune adoption Games/KSP commencée ;
+- audits PGR de la tranche propres.
+
+Un `FAIL` sur une de ces propriétés ouvre un `alpha.1.fix.N` ou un REPLAN ; il ne doit pas être absorbé silencieusement par `alpha.2`.

docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md

@@ -0,0 +1,397 @@
+<!-- file: docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md -->
+<!-- version: 8 -->
+
+# Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge
+
+## Objet
+
+`0.1.5` stabilise trois contrats transversaux décidés par la revue d’horizon `0.1.4` avant toute nouvelle adoption réelle : la force de `MUST / SHOULD / MAY`, l’autonomie d’un projet après instanciation ou adoption, et la frontière entre le référentiel normatif PGR et les contenus pratiques candidats à SaseDev Knowledge.
+
+La release ne doit ni réécrire mécaniquement toutes les recommandations existantes, ni traiter PGR comme un upstream vivant des projets déjà adoptés, ni déplacer du contenu vers Knowledge sans corpus de destination autoritaire.
+
+## Baseline et preuves d’ouverture
+
+La baseline autoritaire est l’archive du tag Gitea `v0.1.4`.
+
+```text
+archive canonique     pgr-v0.1.4.zip
+archive reçue         pgr-v0.1.4(1).zip
+SHA-256               9f85ac16a5ad9fd788df51883b6ebf592602c5189d94e338a86edab2288b8f77
+CRC                    PASS
+VERSION                0.1.4
+racine ZIP             pgr/
+fichiers               310
+répertoires            44
+symlink                 0
+.git dans l'archive     absent — attendu pour une archive de tag
+```
+
+La publication post-tag associée a été clôturée `PASS` sous `pgr-0.1.4-publish.001-report.md`. Sa preuve établit le SHA canonique ci-dessus, la publication de la stable `0.1.4` et l’autorisation du handoff vers `prompts/011-V0_1_5_START_PROMPT.md`.
+
+Le replay indépendant de la baseline avant préparation de `alpha.1` confirme :
+
+```text
+tests Python                     55/55 PASS
+audit hygiène texte              309 fichiers PASS
+audit headers Markdown           282 fichiers PASS
+audit tables Markdown            11 tables / 282 fichiers PASS
+audit liens Markdown             357 liens locaux / 282 fichiers PASS
+JSON                             2 fichiers parsés
+TOML                             5 fichiers parsés
+deltas historiques              103
+histories historiques           103
+appariement delta/history        exact pour 0.0.1 à 0.1.4
+```
+
+La séquence `0.1.4` est conservée telle que publiée :
+
+```text
+alpha.1          PASS
+alpha.2          FAIL
+alpha.2.fix.1    PASS
+alpha.3          PASS
+beta.1           PASS
+rc.1             PASS
+rel.1            PASS
+```
+
+Le `FAIL` de `alpha.2` et son correctif restent des faits historiques ; `0.1.5` ne les réécrit pas.
+
+## Sources de cadrage
+
+La release part au minimum de :
+
+- `RULES.md` ;
+- `docs/rules/200-GOVERNANCE.md` ;
+- `docs/rules/210-WORKFLOW.md` ;
+- `docs/rules/220-SKELETONS.md` ;
+- `docs/rules/230-ADOPTION.md` ;
+- `docs/rules/400-VALIDATION.md` ;
+- `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` ;
+- `docs/templates/003-NEW_SESSION_PROMPT.md` ;
+- `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` ;
+- `docs/studies/004-V0_1_4_HORIZON_REVIEW.md` ;
+- `prompts/011-V0_1_5_START_PROMPT.md`.
+
+Les owners et artefacts adjacents ne sont modifiés que lorsqu’une ambiguïté transversale réelle les concerne.
+
+## Contrats cibles
+
+### Force normative
+
+La release doit rendre non ambigu le contrat suivant :
+
+```text
+MUST / MUST NOT       obligation ou interdiction normative
+SHOULD / SHOULD NOT   forte recommandation non obligatoire
+MAY                   possibilité neutre
+```
+
+Un écart à un `SHOULD` ou `SHOULD NOT` :
+
+- ne constitue pas à lui seul une non-conformité ;
+- ne fait pas échouer à lui seul une gate ;
+- n’exige pas automatiquement un `OVERRIDE` ;
+- peut être documenté lorsque la raison apporte une valeur durable de maintenance, architecture ou reprise.
+
+Une contradiction avec un `MUST` réellement applicable reste distincte et continue d’exiger le traitement prévu par l’owner concerné, l’exception ou l’override autorisé.
+
+### Autonomie après instanciation ou adoption
+
+Le cycle cible est :
+
+```text
+snapshot PGR explicitement choisi
+        ↓
+instanciation / adoption / adaptation
+        ↓
+baseline locale du projet
+        ↓
+autorité locale pour les sessions et releases suivantes
+```
+
+Après établissement de la baseline locale, le projet destinataire ne recherche pas automatiquement une version PGR plus récente et ne traite pas PGR comme une dépendance documentaire implicite. Un réalignement futur reste possible uniquement comme opération explicite et bornée, à partir d’un nouveau snapshot PGR choisi et d’une nouvelle comparaison des écarts.
+
+### Frontière PGR / SaseDev Knowledge
+
+PGR reste auto-suffisant pour comprendre et appliquer ses exigences.
+
+PGR conserve notamment les contrats normatifs et de gouvernance, les owners, les skeleton specifications minimales, les templates nécessaires à un contrat réutilisable et les validations 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 sont des candidats à Knowledge. Cette classification n’autorise aucun déplacement automatique pendant `0.1.5` et ne crée aucune dépendance de PGR vers Knowledge.
+
+## Inventaire transversal `alpha.1`
+
+L’inventaire a recherché les formulations `SHOULD / SHOULD NOT`, les contrats d’override, l’autonomie post-adoption et les termes qui confondent spécification normative et recette pratique.
+
+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 observées en `alpha.1`
+
+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.
+
+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.
+
+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.
+
+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` utilisaient des formulations d’exception/override pouvant renforcer accidentellement un `SHOULD` ; `alpha.2` les a donc inclus dans la réconciliation ciblée.
+
+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` demandait alors, pour la politique de lockfile, soit l’adoption de la recommandation soit un `OVERRIDE` ;
+- `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` imposait une décision locale ou un `OVERRIDE` avec justification pour une politique de lockfile différente.
+
+Ces cas ont été retenus pour une correction ciblée en `alpha.2`, sans affaiblir les `MUST` réellement applicables.
+
+### Ambiguïté de trajectoire observée en `alpha.1`
+
+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
+
+Plusieurs contrats sont déjà compatibles avec la cible :
+
+- `docs/objectives/001-PROJECT_OBJECTIVES.md` interdit de créer une dépendance vers PGR après instanciation et exclut la maintenance automatique des projets créés ;
+- `docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` dit déjà que le projet possède sa copie et qu’une évolution ultérieure de PGR ne le modifie pas automatiquement ;
+- `docs/rules/220-SKELETONS.md` attribue les fichiers, décisions et règles locales au projet après instanciation ;
+- `docs/templates/003-NEW_SESSION_PROMPT.md` repart de la baseline stable du projet lui-même et ne reconstruit pas une source absente ;
+- `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` conclut déjà sur un projet autonome.
+
+Ces acquis doivent être consolidés plutôt que réécrits en bloc.
+
+### Autonomie — gaps à fermer
+
+`RULES.md` interdit seulement la dépendance runtime/build et doit expliciter l’absence d’upstream documentaire PGR implicite.
+
+`docs/rules/230-ADOPTION.md` doit établir clairement que la baseline locale devient l’autorité des sessions/releases suivantes et qu’un réalignement PGR ultérieur est une opération explicite.
+
+`docs/rules/220-SKELETONS.md`, `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` et `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` doivent propager ce contrat au point d’instanciation/adoption. Une éventuelle dépendance documentaire externe explicitement choisie par un projet reste sa décision locale ; elle ne transforme pas PGR en upstream implicite.
+
+`docs/rules/210-WORKFLOW.md` et `docs/templates/003-NEW_SESSION_PROMPT.md` sont, à ce stade, classés `KEEP` sauf contradiction découverte pendant la réconciliation : leur notion de baseline autoritaire est déjà celle du projet courant.
+
+### Frontière Knowledge — ambiguïtés confirmées
+
+`docs/objectives/001-PROJECT_OBJECTIVES.md` et `docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` qualifient encore un skeleton de « recette Markdown ». Or `0.1.5` réserve précisément les recettes pratiques à la famille de contenus candidats à Knowledge. Le terme doit être remplacé par une formulation de type « spécification Markdown composable » afin de préserver la nature normative/structurelle du skeleton.
+
+`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 issus de l'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 alpha.2
+  docs/rules/230-ADOPTION.md                    MODIFY alpha.2 puis alpha.3
+  docs/rules/400-VALIDATION.md                  MODIFY alpha.2
+
+réconciliation ciblée des effets SHOULD
+  docs/rules/500-LANGUAGES.md                   MODIFY alpha.2
+  docs/rules/530-TYPESCRIPT.md                  MODIFY alpha.2
+  docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md MODIFY alpha.2
+  docs/rules/700-FRAMEWORKS.md                  MODIFY alpha.2
+  docs/skeletons/003-WEB_FRONTEND.md            MODIFY alpha.2
+  docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md  MODIFY alpha.2
+
+autonomie
+  RULES.md                                      MODIFY alpha.3
+  docs/rules/220-SKELETONS.md                   MODIFY alpha.3
+  docs/rules/230-ADOPTION.md                    MODIFY alpha.3
+  docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md MODIFY alpha.3
+  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 alpha.4
+  docs/architecture/002-GOVERNANCE_ARCHITECTURE.md MODIFY alpha.4
+  docs/rules/300-DOCUMENTATION.md               MODIFY alpha.4
+```
+
+Aucun nouveau owner Knowledge n’est prévu par défaut.
+
+## Progression acquise avant `beta.1`
+
+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` a ensuite appliqué la sémantique centrale sans réécrire les `242` occurrences de recommandations. Les modifications ont été bornées aux owners et artefacts où l'inventaire avait 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`. Sa gate opérateur du `2026-10-01` est `PASS` avec `55/55` tests et les audits documentaires propres.
+
+Décisions acquises en `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 est mise en œuvre par `alpha.3` ; la frontière Knowledge reste réservée à `alpha.4`.
+
+Décisions de mise en œuvre `alpha.3` :
+
+- après instanciation ou adoption, la baseline locale et ses owners deviennent l'autorité des sessions/releases suivantes ;
+- PGR ne devient ni dépendance documentaire implicite ni upstream à suivre et aucun mécanisme ne doit rechercher automatiquement « la dernière version de PGR » ;
+- un réalignement futur exige une opération explicitement décidée et bornée, fondée sur un snapshot PGR précis choisi par le projet ;
+- ce réalignement compare le snapshot choisi à la baseline locale, reclassifie les écarts utiles et préserve les histories au lieu de mettre à jour silencieusement la gouvernance ;
+- `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.
+
+La gate opérateur de `alpha.4` du `2026-10-01` est `PASS` avec `55/55` tests, les audits documentaires propres, les owners hors scope inchangés et le scope Git attendu. La frontière PGR / Knowledge est donc acquise avant ouverture de `beta.1`.
+
+## Réconciliation transversale préparée en `beta.1`
+
+Le rescan préparatoire de la baseline post-`alpha.4` n'a démontré aucun nouveau défaut normatif exigeant une modification d'owner.
+
+Les formulations `SHOULD / SHOULD NOT` des owners vivants ont été relues avec attention lorsqu'un `MUST`, une justification ou une contrainte conditionnelle apparaissait dans le même contexte. Les cas conservés portent des responsabilités distinctes et ne transforment pas le simple écart à la recommandation en non-conformité : outputs/caches générés à ignorer lorsqu'ils restent dans l'arbre, ouverture réseau/CORS à borner, identité Android à rendre explicite, dépendance Sass interne à garder visible/révisable et surface de sécurité Tauri à décider explicitement.
+
+La réconciliation confirme également :
+
+- `RULES.md`, `230-ADOPTION.md` et `400-VALIDATION.md` portent une sémantique cohérente : un écart à `SHOULD / SHOULD NOT` ne crée à lui seul ni `FAIL`, ni `OVERRIDE`, ni justification obligatoire ;
+- `220-SKELETONS.md`, `230-ADOPTION.md`, `001-PROJECT_GOVERNANCE_FOUNDATION.md` et `007-EXISTING_PROJECT_ADOPTION.md` conservent la baseline locale comme autorité et le réalignement PGR comme opération explicite sur snapshot choisi ;
+- `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent `KEEP` : aucune recherche automatique de version PGR plus récente n'y est introduite ;
+- `001-PROJECT_OBJECTIVES.md`, `002-GOVERNANCE_ARCHITECTURE.md` et `300-DOCUMENTATION.md` maintiennent PGR auto-suffisant et Knowledge strictement complémentaire ;
+- la référence vivante Games dans `540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` pointe bien vers `0.1.6` ; les anciennes mentions `0.1.5` conservées dans des études/index historiques restent des descriptions de l'horizon de leur époque et ne sont pas réécrites ;
+- les scopes Games `0.1.6`, KSP `0.1.7` et audits Rust/Clippy `0.1.8` restent réservés et aucun `0.1.9` n'est créé.
+
+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`.
+
+## Gate `rc.1` en échec documentaire et correctif `rc.1.fix.1`
+
+La gate opérateur de `rc.1` du `2026-10-01` conserve les `55/55` tests `PASS`, les audits documentaires propres, le freeze des owners et le scope Git attendu, mais trois assertions textuelles exactes du delta n'ont produit aucune correspondance. Le history `history/0.1.5/rc.1.md` enregistre donc le résultat réel `FAIL`.
+
+Le correctif `rc.1.fix.1` est borné à la présentation documentaire :
+
+- employer dans `CHANGELOG.md` la formule canonique `forte recommandation non obligatoire` attendue par la gate ;
+- rendre explicite dans la revue d'horizon que `aucun numéro de version Games n’est figé` ;
+- matérialiser la classification canonique `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A` dans cette même étude ;
+- ne modifier aucun owner normatif, skeleton, template, contrat de validation, roadmap, handoff `012` ou history antérieur.
+
+`rel.1` reste bloqué tant que `rc.1.fix.1` n’est pas validé `PASS`.
+
+## Gate `rc.1.fix.1` acquise et promotion stable
+
+La gate opérateur de `rc.1.fix.1` du `2026-10-01` est `PASS` : les trois assertions documentaires qui avaient fait échouer `rc.1` correspondent désormais, les `55/55` tests passent, les audits d'hygiène/Markdown sont propres et le scope Git est exactement celui du correctif.
+
+Le history `history/0.1.5/rc.1.fix.1.md` conserve ce `PASS` sans modifier le `FAIL` historique de `rc.1`.
+
+`rel.1` peut donc promouvoir mécaniquement la candidate vers la stable `0.1.5`. Cette promotion :
+
+- fixe `VERSION` à `0.1.5` ;
+- retire le marqueur `candidate` du changelog ;
+- marque `0.1.5` terminé dans la roadmap ;
+- présente `README.md`, l'index documentaire et le présent plan comme état stable/historique ;
+- conserve `0.1.6` Games, `0.1.7` KSP et `0.1.8` audits comme trajectoire engagée ;
+- ne commence aucun scope `0.1.6` et ne réserve aucun `0.1.9`.
+
+Après un history `rel.1` `PASS`, le commit produit MUST être `0.1.5` sans suffixe `rel.1`, puis le tag annoté `v0.1.5` et son archive doivent être publiés et vérifiés indépendamment. Le rapport `pgr-0.1.5-publish.001-report.md` ne peut être produit qu'après cette publication réelle.
+
+Le plan devient historique avec la stable `0.1.5`.
+
+## Trajectoire de release
+
+### `alpha.1` — intake, audit transversal et plan
+
+- vérifier la baseline stable `0.1.4` et sa chaîne delta/history ;
+- relire le handoff `011` et la revue d’horizon `004` ;
+- inventorier les ambiguïtés normatives, d’autonomie et de frontière Knowledge ;
+- proposer les owners exacts ;
+- ne modifier aucune règle normative.
+
+### `alpha.2` — sémantique normative et conséquences de gate/adoption
+
+- stabiliser `MUST / SHOULD / MAY` dans l’owner primaire ;
+- aligner `230-ADOPTION.md` et `400-VALIDATION.md` ;
+- corriger les cas concrets où une recommandation est transformée en justification/override obligatoire ;
+- corriger la référence vivante obsolète à l’adoption Games `0.1.5` ;
+- conserver les obligations réelles et les histories inchangées.
+
+### `alpha.3` — autonomie locale et réalignement volontaire
+
+- expliciter la baseline locale comme autorité après instanciation/adoption ;
+- interdire la recherche automatique de « la dernière PGR » dans le contrat d’adoption ;
+- définir le réalignement futur comme scope explicite fondé sur un snapshot choisi ;
+- propager le contrat aux skeleton/patterns concernés sans réécriture des documents déjà corrects.
+
+### `alpha.4` — frontière PGR / SaseDev Knowledge
+
+- clarifier la taxonomie normative/pratique ;
+- remplacer les formulations « recette Markdown » qui brouillent la nature des skeleton specifications ;
+- maintenir PGR auto-suffisant ;
+- ne déplacer aucun contenu vers Knowledge sans destination autoritaire fournie.
+
+### `beta.1` — réconciliation transversale
+
+- rescanner toutes les formulations `SHOULD / SHOULD NOT` pour détecter les renforcements accidentels restants ;
+- vérifier les références à l’autonomie, aux snapshots et aux overrides ;
+- rechercher les références vivantes devenues obsolètes après la revue d’horizon ;
+- vérifier que Games `0.1.6`, KSP `0.1.7` et les audits Rust `0.1.8` n’ont pas été commencés ;
+- exécuter les validations PGR complètes et proportionnées.
+
+### `rc.1` — freeze et handoff
+
+- figer les contrats stabilisés ;
+- mettre à jour la présentation stable/candidate et la roadmap selon l’état réellement atteint ;
+- préparer le prompt de reprise suivant uniquement si la trajectoire vers `0.1.6` reste valide ;
+- effectuer une revue d’horizon limitée aux dépendances réellement révélées par `0.1.5`.
+
+### `rel.1` — promotion stable
+
+- promouvoir la RC validée sans nouveau scope fonctionnel ;
+- produire le history réel de clôture ;
+- préparer la publication/tag stable puis sa vérification post-tag selon le workflow PGR.
+
+## Hors scope maintenu
+
+`0.1.5` ne commence pas :
+
+- l’adoption réelle de `sasedev-games`, réservée à `0.1.6` ;
+- l’adoption réelle de `khadhroony-solana-project`, réservée à `0.1.7` ;
+- les audits Rust/Clippy read-only, réservés à `0.1.8` ;
+- une réouverture du domaine Tauri sans défaut transversal démontré ;
+- une migration physique vers SaseDev Knowledge ;
+- une conversion globale de tous les `SHOULD` en `MUST` ou `MAY`.
+
+## Gate de planification `alpha.1` — historique
+
+`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` ;
+- les ambiguïtés ci-dessus sont traçables à des owners existants ;
+- aucune règle normative n’est modifiée par la tranche ;
+- le plan conserve une séparation explicite entre sémantique, autonomie et frontière Knowledge ;
+- les scopes `0.1.6`, `0.1.7` et `0.1.8` restent réservés.

docs/rules/210-WORKFLOW.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/210-WORKFLOW.md -->
-<!-- version: 7 -->
+<!-- version: 9 -->
 
 # Workflow artifact rules
 
@@ -149,6 +149,8 @@ L'archive delta contient uniquement les fichiers à ajouter ou remplacer pour la
 
 L'archive history contient uniquement le ou les fichiers history à appliquer pour clôturer l'état validé, sauf besoin explicitement documenté.
 
+Les entrées des archives delta/history MUST utiliser directement les chemins relatifs à la racine du dépôt. Elles MUST NOT ajouter un répertoire englobant portant le nom du projet, par exemple `pgr/`, lorsque l'application canonique attend `unzip -o <archive> -d .`. Le générateur MUST vérifier la liste des entrées du ZIP avant remise afin qu'un chemin annoncé comme `docs/...`, `history/...` ou `VERSION` soit réellement présent à ce niveau dans l'archive.
+
 Delta et history MUST rester des livraisons séparées afin que la preuve observée ne soit pas confondue avec l'intention prospective.
 
 Lorsque la gate courante est `PASS` et que la tranche suivante est déjà déterminée par le plan sans décision ouverte, le générateur SHOULD préparer et remettre dans la même réponse :
@@ -163,6 +165,16 @@ Les deux archives restent séparées. Cette optimisation de flux n'autorise jama
 
 Le delta suivant SHOULD NOT être anticipé lorsqu'une décision opérateur, un REPLAN non résolu, un abandon/supersession, une preuve externe post-tag ou toute autre dépendance peut encore modifier sa baseline ou son scope.
 
+## Hygiène mécanique des artefacts texte
+
+Les fichiers texte de gouvernance ajoutés ou remplacés MUST être livrés avec des fins de ligne LF, sans whitespace terminal et avec exactement une seule newline finale. Une ligne vide supplémentaire à EOF constitue un défaut de livraison même si le contenu sémantique du document est inchangé.
+
+Avant remise d'un delta ou d'un history, le générateur MUST contrôler cette propriété sur les fichiers texte concernés. Le dépôt PGR fournit `scripts/audit_text_hygiene.py` comme audit read-only monotâche réutilisable ; il contrôle les CR, le whitespace terminal, l'absence de newline finale et les lignes vides terminales surnuméraires.
+
+`git diff --check` et `git diff --cached --check` restent obligatoires lorsqu'ils sont sélectionnés par la gate Git applicable. Ils constituent un filet indépendant et ne remplacent pas l'audit d'hygiène lorsque celui-ci est disponible dans le projet.
+
+Un générateur MUST corriger un défaut mécanique détectable avant livraison plutôt que compter sur la gate opérateur pour le découvrir. Si la gate opérateur détecte malgré tout ce défaut, le résultat réel reste `FAIL` et la correction suit le workflow `.fix.N`.
+
 ## Commit de tranche
 
 Le commit d'une tranche doit représenter l'état complet de cette tranche, y compris son history.

docs/rules/220-SKELETONS.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/220-SKELETONS.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Skeleton specification rules
 
@@ -23,7 +23,9 @@ Un skeleton MUST NOT devenir :
 - un moyen de figer une architecture au-delà du scope qu'il déclare ;
 - un catalogue de technologies ou de fichiers créés par anticipation.
 
-Après instanciation, le projet destinataire possède ses fichiers, ses décisions et ses règles locales. Une évolution ultérieure de PGR ne modifie pas automatiquement ce projet.
+Après instanciation, le projet destinataire possède ses fichiers, ses décisions et ses règles locales. Cette baseline locale devient l'autorité de ses sessions et releases suivantes. Une évolution ultérieure de PGR ne modifie pas automatiquement ce projet et le projet MUST NOT rechercher automatiquement une version PGR plus récente.
+
+Un réalignement futur MAY être décidé explicitement. Il doit alors partir d'un snapshot PGR précis choisi par le projet, comparer ce snapshot à la baseline locale et appliquer uniquement les écarts explicitement retenus. Ce réalignement est une nouvelle opération bornée ; il ne transforme pas PGR en upstream documentaire permanent.
 
 ## Applicabilité
 

docs/rules/230-ADOPTION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/230-ADOPTION.md -->
-<!-- version: 1 -->
+<!-- version: 3 -->
 
 # Existing project adoption rules
 
@@ -17,7 +17,7 @@ PGR s’adapte au besoin réel du projet existant ; il ne cherche pas à effacer
 
 Une adoption MUST partir d’une baseline autoritaire réellement observée : commit, tag, archive de release ou autre état explicitement accepté par le projet. Le travail d’adoption MUST distinguer ce qui existe déjà de ce que PGR propose d’ajouter ou de modifier.
 
-Une migration réussie produit un projet autonome gouverné localement. Le projet destinataire ne devient pas dépendant runtime ou build du dépôt PGR.
+Une migration réussie produit un projet autonome gouverné localement. Une fois la baseline locale établie, elle devient l'autorité des sessions et releases suivantes du projet. Le projet destinataire ne devient pas dépendant runtime, build ou documentaire implicite du dépôt PGR et MUST NOT rechercher automatiquement « la dernière version de PGR ».
 
 ## Audit initial de la baseline
 
@@ -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
 
@@ -96,6 +98,22 @@ Les conventions nouvelles s’appliquent à partir du point d’adoption explici
 
 Une adoption MAY documenter des écarts hérités comme dette, exception temporaire ou contexte historique sans modifier les snapshots qui les ont produits.
 
+## Autorité locale et réalignement futur
+
+Après clôture du scope d'adoption, les règles, plans, décisions, validations et historiques locaux gouvernent les travaux suivants. Les sessions et releases ultérieures MUST partir de cette baseline locale et non d'une recherche automatique d'une version PGR plus récente.
+
+PGR n'est pas un upstream documentaire implicite. Une référence, URL ou archive PGR utilisée pendant l'adoption reste une source de comparaison de cette opération ; elle ne crée pas un abonnement aux évolutions futures du référentiel. Une dépendance documentaire externe MAY exister uniquement si le projet la choisit et la possède explicitement comme contrat local.
+
+Un réalignement futur avec PGR MAY être engagé lorsqu'il apporte une valeur réelle. Cette opération MUST être explicite et bornée. Elle doit au minimum :
+
+1. identifier le snapshot PGR choisi, par exemple version, tag, commit ou archive ;
+2. repartir de la baseline locale autoritaire du projet ;
+3. comparer les owners applicables et classifier les écarts utiles selon `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
+4. définir le scope et les validations de la migration ;
+5. préserver les histories, tags et décisions historiques au lieu de les réécrire pour simuler une conformité continue.
+
+Le réalignement ne doit pas être présenté comme une mise à jour automatique. Entre deux opérations explicitement décidées, la gouvernance locale reste autonome et suffisante pour reprendre le projet.
+
 ## Relation avec les skeletons et templates
 
 Un skeleton PGR MAY servir de checklist de comparaison pour un projet existant. Il ne doit pas être appliqué comme si le dépôt était vide.
@@ -116,10 +134,10 @@ Une adoption n’est terminée que lorsque les décisions de son scope sont clas
 
 Une adoption PGR réussie laisse :
 
-- un projet autonome ;
+- un projet autonome dont la baseline locale gouverne les sessions et releases suivantes ;
 - 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/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.

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/610-ANDROID.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/610-ANDROID.md -->
-<!-- version: 3 -->
+<!-- version: 5 -->
 
 # Profil Android
 
@@ -15,7 +15,7 @@ Les profils Rust/JNI et Tauri ne sont pas définis ici. Ils constituent des comp
 
 ## Structure du projet
 
-Pour un dépôt exclusivement Android, les conventions Android normales restent prioritaires et la racine du dépôt MAY être directement le projet Gradle.
+Pour un dépôt exclusivement Android, les conventions Android normales restent prioritaires et la racine du dépôt MAY être directement le projet de build Android.
 
 Dans un dépôt multi-plateforme où une zone Android distincte est nécessaire, PGR SHOULD utiliser la racine :
 
@@ -33,23 +33,25 @@ project/
 ├── crates/
 ├── Web/
 └── Android/
-    ├── settings.gradle
-    ├── build.gradle
+    ├── settings.gradle(.kts)
+    ├── build.gradle(.kts)
     ├── gradle.properties
-    ├── gradlew
-    ├── gradlew.bat
-    └── gradle/
+    └── <module>/
 ```
 
+Cet exemple décrit une frontière de plateforme, pas une liste obligatoire de fichiers Gradle. Wrapper, version catalog, plugins de convention, modules et autres éléments de build restent gouvernés par la composition réellement choisie et par [`522-GRADLE.md`](522-GRADLE.md).
+
 Les noms et fichiers exacts restent soumis au projet Android réellement utilisé ; PGR ne crée pas de niveau `Android/` artificiel dans un dépôt qui est déjà exclusivement Android.
 
 ## Langage applicatif et logique de build
 
-Java est le langage applicatif Android par défaut du profil PGR lorsqu'aucune API, framework ou contrainte réelle n'impose un autre choix.
+Android ne sélectionne pas à lui seul le langage applicatif du projet. Les profils langage s'appliquent uniquement aux langages réellement présents.
 
-Kotlin MAY être utilisé lorsqu'une API, un framework ou une intégration l'exige réellement.
+Lorsqu'un projet Android contient du Java, [`520-JAVA.md`](520-JAVA.md) possède les règles Java correspondantes. La présence d'AGP, d'un JDK de build ou d'un script Gradle ne suffit pas à rendre le profil Java applicable au code produit.
 
-Groovy DSL ou Kotlin DSL MAY être utilisés par Gradle comme langage de configuration. Leur présence dans le build ne transforme pas Kotlin ou Groovy en langage applicatif du projet.
+Un autre langage applicatif MAY être utilisé lorsqu'il correspond à la stack réelle du projet. Le profil Android possède uniquement les contraintes imposées par la plateforme et ne transforme pas un choix de langage local en règle Android générale.
+
+Groovy DSL ou Kotlin DSL MAY être utilisés par Gradle comme langage de configuration conformément à [`522-GRADLE.md`](522-GRADLE.md). Leur présence dans le build ne détermine pas le langage applicatif.
 
 Les fichiers Gradle SHOULD rester aussi déclaratifs et courts que raisonnablement possible. Une logique de build importante SHOULD être possédée par une abstraction ou un plugin identifiable plutôt que devenir du code produit caché dans un script Gradle.
 
@@ -57,7 +59,7 @@ Les annotations fonctionnelles Android ou de frameworks restent autorisées lors
 
 ## Matrice AGP / Gradle / JDK
 
-Un projet Android MUST exprimer une chaîne de build compatible.
+Un projet Android qui utilise AGP MUST exprimer une chaîne de build compatible.
 
 La matrice conceptuelle est :
 
@@ -66,9 +68,11 @@ Android Gradle Plugin
 ↕
 Gradle
 ↕
-JDK LTS
+JDK de build
 ```
 
+La version AGP retenue peut également contraindre les niveaux Android SDK supportés par la chaîne de build. Cette compatibilité appartient au scope Android ; les règles Gradle générales restent possédées par [`522-GRADLE.md`](522-GRADLE.md).
+
 PGR MUST NOT imposer globalement une version Gradle, AGP ou JDK uniquement parce qu'elle est utilisée par un autre projet Android.
 
 La contrainte applicable peut être :
@@ -80,27 +84,47 @@ version exacte / pin
 latest compatible
 ```
 
-Le projet choisit la forme la moins restrictive qui reste réellement compatible avec sa stack.
+Le projet choisit la forme la moins restrictive qui reste réellement compatible avec sa stack et effectivement vérifiable.
 
-Le JDK suit le profil Java : dernière LTS compatible par défaut, LTS plus ancienne lorsqu'une contrainte Android ou de framework l'impose, non-LTS uniquement par exception justifiée.
+Le JDK utilisé pour exécuter Gradle/AGP est une contrainte de build Android même lorsqu'aucun code source Java n'existe. Lorsqu'un projet contient du Java, le niveau Java du code source et du bytecode reste un contrat distinct possédé par [`520-JAVA.md`](520-JAVA.md).
 
-Lorsque le Gradle Wrapper est retenu, ses fichiers requis sont versionnés et sa version doit satisfaire la matrice réelle AGP/Gradle/JDK.
+PGR MUST NOT confondre :
+
+```text
+JDK qui exécute Gradle / AGP
+≠
+niveau Java du code applicatif
+```
+
+Le choix Wrapper ou Gradle système, ainsi que la manière de vérifier la contrainte Gradle, restent possédés par [`522-GRADLE.md`](522-GRADLE.md). Une matrice Android plus étroite MAY raffiner cette contrainte dans le seul scope Android.
 
 ## `compileSdk`, `targetSdk` et `minSdk`
 
 Ces trois valeurs représentent des contrats différents.
 
-`compileSdk` définit l'API Android utilisée pour compiler. Il MAY être récent afin de permettre l'usage des APIs et outils actuels.
+`compileSdk` définit le niveau d'API Android disponible lors de la compilation. Il doit être compatible avec la version AGP réellement utilisée et MAY évoluer sans entraîner mécaniquement une hausse de `targetSdk` ou `minSdk`.
 
-`targetSdk` déclare le niveau de comportement Android pour lequel l'application a été adaptée. Il MUST respecter les exigences applicables au canal de distribution réellement visé.
+`targetSdk` déclare le niveau Android pour lequel l'application a été adaptée et testée du point de vue des comportements de plateforme. Il MUST respecter les exigences applicables au canal de distribution réellement visé.
 
-`minSdk` définit la plus ancienne version Android que le produit promet de pouvoir installer et exécuter.
+`minSdk` définit le plus ancien niveau d'API Android que le produit choisit réellement de supporter. Il participe notamment à l'éligibilité d'installation sur les appareils plus anciens.
 
 PGR MUST NOT déduire une hausse de `minSdk` d'une hausse de `compileSdk` ou `targetSdk`.
 
-`minSdk` SHOULD rester aussi bas que raisonnablement supportable tant que cela ne compromet pas une capacité nécessaire, une dépendance imposée, la sécurité ou une maintenance raisonnable.
+Le choix de `minSdk` MUST être justifié par le contrat produit et ses contraintes réelles : population visée, capacités nécessaires, dépendances, sécurité, coût de maintenance et preuves de compatibilité. PGR ne privilégie ni le niveau le plus bas possible ni une hausse de confort sans justification.
 
-Une hausse de `minSdk` est un changement de compatibilité utilisateur et MUST être explicitement justifiée.
+Une hausse de `minSdk` retire explicitement des appareils auparavant éligibles ; elle constitue donc un changement de compatibilité utilisateur et MUST être traitée comme tel.
+
+## Identité applicative et namespace
+
+Pour un module application Android, `applicationId` et `namespace` sont deux contrats distincts.
+
+`applicationId` identifie l'application installée et distribuée. Pour une application déjà publiée, le modifier ne constitue pas un simple renommage de code : il crée une identité applicative différente du point de vue de la plateforme et des canaux de distribution.
+
+`namespace` possède l'espace de noms utilisé par le code et les ressources générées du module. Il MAY évoluer indépendamment de `applicationId` lorsque le projet a une raison réelle de dissocier identité distribuée et organisation du code.
+
+PGR SHOULD conserver `namespace` et `applicationId` alignés lorsque cela suffit, mais MUST NOT les confondre ni dériver implicitement l'identité distribuée d'un renommage de namespace. Toute divergence ou modification d'`applicationId` doit être explicite dans la configuration Android concernée.
+
+Les valeurs concrètes telles que `com.example.product` appartiennent au projet ; PGR n'impose aucun domaine ou préfixe universel.
 
 ## `VERSION`, `versionName` et `versionCode`
 
@@ -135,15 +159,15 @@ lorsqu'un projet ou skeleton réel fournit des fichiers à contrôler. Cet audit
 
 ## Configuration locale
 
-`local.properties` est un fichier local Android typique et SHOULD rester hors Git lorsqu'il contient des chemins machine tels que l'emplacement du SDK.
+`local.properties` appartient à l'environnement local du build Android/AGP, notamment pour des chemins machine tels que l'emplacement du SDK. Il SHOULD rester hors Git.
 
-PGR MUST NOT utiliser `local.properties` comme source normative de configuration partagée du projet.
+PGR MUST NOT utiliser `local.properties` comme source normative de configuration partagée ni comme fourre-tout pour des propriétés locales propres au produit. La documentation Android réserve ce fichier aux propriétés locales comprises par la toolchain Android ; une propriété locale spécifique au projet doit utiliser un mécanisme séparé et explicitement possédé.
 
-Si l'outil ou l'IDE régénère intégralement ce fichier, aucun fichier exemple n'est nécessaire.
+Les propriétés Gradle partagées, portables et non secrètes restent gouvernées par [`522-GRADLE.md`](522-GRADLE.md). Les chemins machine, credentials, secrets et overrides développeur restent locaux, via variables d'environnement, propriétés utilisateur ou fichier explicitement ignoré selon le besoin réel.
 
-Lorsqu'une propriété locale obligatoire n'est pas automatiquement reproductible, un template MAY être fourni conformément aux règles générales PGR.
+Si l'outil ou l'IDE régénère intégralement un état local, aucun fichier exemple n'est nécessaire. Lorsqu'une valeur locale obligatoire n'est pas automatiquement reproductible, un template MAY être fourni conformément aux règles générales PGR.
 
-La même politique s'applique aux fichiers locaux analogues tels que `keystore.properties`, `user.properties` ou des variantes `*.local.properties` lorsqu'ils contiennent des valeurs propres à la machine ou à l'utilisateur.
+Un fichier local tel que `keystore.properties` ou une variante `*.local.properties` MAY exister lorsqu'il possède une responsabilité claire, mais il MUST rester hors Git lorsqu'il contient des secrets ou valeurs propres à la machine.
 
 ## Signing et secrets
 
@@ -152,7 +176,7 @@ L'interdiction générale de versionner ou distribuer des secrets reste posséd
 Dans le scope Android, les éléments suivants sont notamment des secrets ou artefacts privés soumis à cette interdiction :
 
 ```text
-release keystore
+release / upload keystore
 private signing key
 passwords
 credentials
@@ -168,7 +192,9 @@ RELEASE_KEY_ALIAS
 
 mais MUST NOT contenir leurs valeurs privées.
 
-Le debug keystore généré automatiquement est local.
+Le debug keystore généré par les outils Android est un état local de développement et ne doit pas être promu comme identité de signing de release.
+
+Les clés de release ou d'upload appartiennent à une frontière de sécurité durable de l'application publiée. Leur stockage, sauvegarde, rotation ou délégation au canal de distribution doit être décidé explicitement par le projet sans introduire la matière secrète dans Git.
 
 Le signing de release ne doit pas être requis pour une validation ordinaire de développement sauf lorsque la tranche valide précisément la distribution ou la signature finale.
 
@@ -203,25 +229,44 @@ Une BOM ou un mécanisme officiel de gestion de versions MAY être utilisé lors
 
 La politique d'un lockfile Android/Gradle, lorsqu'un projet en utilise un, doit être décidée selon le besoin réel de cet écosystème et du projet. Elle n'est pas déduite automatiquement d'un autre profil.
 
-## ABI et code natif
+## NDK, ABI et code natif
 
-Un projet Android purement Java peut ne posséder aucune règle ABI spécifique.
+Un projet Android sans bibliothèque native directe ou transitive n'a pas besoin de NDK ni de matrice ABI propre au produit.
 
-Dès qu'un projet contient du code natif via NDK, C/C++, Rust ou une autre frontière native, les ABI réellement supportées MUST être déclarées explicitement.
+Dès qu'un projet contient du code natif via NDK, C/C++, Rust, un SDK précompilé ou une autre frontière native, la toolchain native réellement nécessaire et les ABI réellement supportées MUST être explicites.
 
-Exemples possibles :
+PGR ne fixe ni version NDK ni liste universelle d'ABI. La version NDK MAY être épinglée lorsqu'une reproductibilité, une dépendance ou une exigence de packaging le justifie ; elle ne doit pas être copiée depuis un autre projet par défaut.
+
+Les mécanismes tels que `abiFilters` MAY exprimer la matrice voulue lorsque Gradle/AGP les utilise. La configuration choisie doit refléter le contrat produit et le canal de distribution plutôt qu'une liste maximale par principe.
+
+Une ABI annoncée comme supportée doit disposer d'une preuve adaptée à la propriété annoncée. Il faut distinguer au minimum :
 
 ```text
-arm64-v8a
-armeabi-v7a
-x86_64
+compilation native
+→ la bibliothèque est produite pour l'ABI
+
+packaging
+→ la bibliothèque et ses dépendances natives sont présentes dans l'artefact Android attendu
+
+runtime
+→ le package pertinent s'installe et exécute le chemin critique sur un environnement représentant l'ABI / API concernée
 ```
 
-PGR ne fixe pas une liste universelle d'ABI.
+Une cross-compilation native seule ne prouve donc ni l'intégration dans l'APK/AAB, ni le lifecycle Android, ni l'exécution sur device/AVD.
 
-Une ABI annoncée comme supportée doit disposer d'une preuve adaptée. Une cross-compilation native seule ne prouve pas l'intégration dans l'APK, le lifecycle Android ni l'exécution sur device/AVD.
+Les bibliothèques natives précompilées ou apportées par un SDK font partie du package final et MUST respecter les mêmes contraintes de compatibilité que les bibliothèques produites par le projet.
 
-Les règles JNI elles-mêmes appartiennent à un profil spécialisé et restent hors de ce document.
+Les règles JNI, Rust, SDL, `cargo ndk` ou toute autre chaîne native spécialisée appartiennent à leurs owners/projets respectifs et restent hors de ce document tant qu'un profil générique séparé n'est pas justifié.
+
+## Android Lint
+
+Android Lint est une analyse statique Android distincte de la compilation et des tests.
+
+Lorsqu'un changement touche du code, des resources, un manifest, une configuration Android ou une dépendance susceptible d'être analysée par Lint, la gate SHOULD exécuter la tâche Lint du module et du variant pertinents.
+
+PGR MUST NOT supposer qu'un build Gradle ordinaire exécute Lint automatiquement. Les commandes exactes (`lint`, `lintDebug`, `lintRelease` ou équivalent) appartiennent au projet et à sa stratégie Wrapper/Gradle système.
+
+Une baseline Lint MAY être versionnée lorsqu'elle sert réellement à isoler la dette existante des nouvelles régressions. Elle ne doit pas servir à masquer silencieusement de nouveaux diagnostics applicables.
 
 ## Niveaux de tests Android
 
@@ -229,20 +274,22 @@ PGR distingue au moins trois niveaux de preuve Android lorsqu'ils sont applicabl
 
 ```text
 JVM unit
-→ logique ne nécessitant pas le runtime Android
+→ logique exécutée sur la JVM hôte sans runtime Android réel
 
 instrumented / integration
-→ comportement nécessitant le framework Android
+→ test exécuté sur device ou émulateur avec le framework Android
 
 smoke device / AVD
-→ application ou package réel dans un environnement Android
+→ application ou package réel installé et chemin critique exécuté dans un environnement Android
 ```
 
-Un test JVM MUST NOT être enregistré comme preuve d'un comportement réel d'`Activity`, de lifecycle ou de device.
+Un test JVM MUST NOT être enregistré comme preuve d'un comportement réel d'`Activity`, de lifecycle, de package ou de device.
 
-Un test instrumenté ne remplace pas automatiquement un smoke du package final.
+Un test instrumenté prouve le comportement couvert par son runner et son environnement, mais ne remplace pas automatiquement un smoke du package final lorsque la tranche modifie packaging, signing, native libraries, manifest de lancement ou installation.
 
-Un appareil physique n'est pas obligatoire pour chaque release. Il devient nécessaire lorsqu'une propriété annoncée dépend d'un matériel ou comportement qui ne peut pas être suffisamment prouvé par AVD.
+Les tâches de tests SHOULD être ciblées par module/variant lorsque cela suffit. Une matrice instrumentée ou multi-device large n'est requise que lorsqu'elle couvre un risque réellement modifié ou une phase de release qui l'exige.
+
+Un appareil physique n'est pas obligatoire pour chaque release. Il devient nécessaire lorsqu'une propriété annoncée dépend d'un matériel, d'une ABI ou d'un comportement qui ne peut pas être suffisamment prouvé par AVD.
 
 ## Ordre de validation Android
 
@@ -274,10 +321,12 @@ Les commandes exactes appartiennent à la matrice du projet ou du skeleton qui p
 
 ## Manifest et ressources
 
-`AndroidManifest.xml` MUST déclarer uniquement les permissions et capabilities réellement nécessaires.
+`AndroidManifest.xml` MUST déclarer uniquement les composants, permissions et capabilities de plateforme réellement nécessaires au module.
 
 Une permission sensible ne doit pas être ajoutée « au cas où ». Son introduction constitue un changement significatif qui doit être visible dans le delta et, lorsque pertinent, dans la documentation de release.
 
+`applicationId` et `namespace` restent possédés par la configuration Android du module ; PGR SHOULD éviter de créer des sources de vérité concurrentes ou des copies divergentes de ces identités dans des fichiers séparés.
+
 `src/main/res/` reste la source canonique des ressources Android d'un module standard.
 
 Dans un projet multi-plateforme, des assets réellement partagés MAY vivre dans un owner commun hors d'Android si leur consommation est définie clairement.
@@ -290,20 +339,54 @@ PGR distingue les rôles des principaux artefacts :
 
 ```text
 APK debug
-→ développement et smokes ordinaires
+→ développement, installation directe et smokes ordinaires
 
 APK release
 → validation d'un package release installable lorsque nécessaire
 
 AAB
-→ artefact de distribution lorsque le canal cible l'exige
+→ artefact de distribution lorsque le canal cible l'exige ; le canal génère ensuite les APK servis aux appareils
 ```
 
-La phase de release et le scope modifié déterminent l'artefact nécessaire.
+La phase de release, le canal de distribution et le scope modifié déterminent l'artefact nécessaire.
 
-Une alpha documentaire n'a pas besoin d'un package Android réel si aucun projet Android n'est concerné. Une release d'une application Android peut au contraire nécessiter un package ou smoke réel lorsque `versionName`, `versionCode`, signing ou packaging sont modifiés.
+Un AAB n'est pas directement une preuve d'installation ou d'exécution sur device. Lorsqu'une propriété runtime ou de packaging doit être prouvée, la gate doit aussi utiliser un APK approprié ou les APK dérivés du bundle selon le canal et le risque concernés.
 
-La promotion stable ne doit pas provoquer mécaniquement un full rebuild sans preuve invalidée ; elle doit toutefois revalider le packaging ciblé lorsque les métadonnées qui entrent dans l'artefact ont changé.
+Une alpha documentaire n'a pas besoin d'un package Android réel si aucun projet Android n'est concerné. Une release d'une application Android peut au contraire nécessiter un package ou smoke réel lorsque `versionName`, `versionCode`, signing, manifest, code natif ou packaging sont modifiés.
+
+La promotion stable ne doit pas provoquer mécaniquement un full rebuild sans preuve invalidée ; elle doit toutefois revalider le packaging ciblé lorsque les métadonnées ou composants qui entrent dans l'artefact ont changé.
+
+Les exigences telles que le niveau `targetSdk` minimal, le format de publication ou les délais de compatibilité appartiennent au canal de distribution et évoluent indépendamment de PGR. Un projet publié MUST vérifier la politique officielle courante de son canal avant une release concernée ; PGR ne transforme pas une valeur datée de Google Play en default Android universel.
+
+## Pages mémoire 16 KB et packaging natif
+
+Android supporte des appareils configurés avec des pages mémoire de `16 KB`. Cette responsabilité est conditionnelle : un projet sans bibliothèque native directe ou transitive n'a pas de segments ELF à réaligner, même s'il SHOULD tester les comportements importants sur les environnements Android qu'il prétend supporter.
+
+Lorsqu'une application contient du natif et que la plateforme ou le canal de distribution exige la compatibilité `16 KB`, le package final MUST être compatible. La preuve doit couvrir les bibliothèques natives du projet ainsi que les dépendances natives précompilées réellement embarquées.
+
+Pour Google Play, la politique officielle courante vérifiée pendant `0.1.3` impose le support `16 KB` sur appareils 64 bits aux applications ciblant Android 15 / API `35` ou supérieur. Cette politique est évolutive : le projet MUST la revalider auprès de la documentation officielle au moment où elle devient une gate de release.
+
+Une preuve de compatibilité native `16 KB` SHOULD couvrir, selon l'artefact réellement distribué :
+
+```text
+ELF 64 bits
+→ segments LOAD des bibliothèques embarquées compatibles avec l'alignement 16 KB
+
+APK
+→ alignement ZIP des bibliothèques natives vérifié sur le package final
+
+AAB
+→ configuration d'alignement du bundle vérifiée lorsque ce bundle est l'artefact de distribution
+
+runtime
+→ smoke sur device/AVD 16 KB lorsque le comportement runtime ou la distribution concernée le justifie
+```
+
+Les outils Android officiels peuvent notamment contrôler les segments ELF, `zipalign -P 16` pour un APK et l'alignement déclaré par `bundletool` pour un AAB. Ces commandes sont des moyens de preuve, pas des noms de fichiers ou chemins machine à figer dans PGR.
+
+Une toolchain récente peut fournir cette compatibilité par défaut, mais PGR MUST NOT imposer une version AGP/NDK globale uniquement pour cette raison. La toolchain retenue doit satisfaire la politique courante du canal et toutes les bibliothèques natives précompilées doivent être compatibles elles aussi.
+
+Un mode de compatibilité de plateforme ou le simple fait que l'application démarre sur un appareil 16 KB ne remplace pas la preuve de conformité du package natif lorsque le canal de distribution l'exige.
 
 ## Validation et futurs audits PGR
 

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/rules/710-TAURI.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/710-TAURI.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->
 
 # Profil Tauri 2
 
@@ -54,25 +54,25 @@ Les éléments suivants appartiennent néanmoins au scope Tauri lorsqu'ils exist
 
 Leur emplacement exact reste une décision du projet ou du skeleton retenu tant qu'il est supporté par la toolchain.
 
-## Convention renforcée pour les projets contrôlés
+## Convention organisationnelle pour les projets contrôlés
 
-Le contrat universel ci-dessus reste compatible avec des projets Tauri imposés de l'extérieur. Pour un **nouveau projet Tauri contrôlé par l'organisation** qui sélectionne le profil strict PGR, les conventions suivantes forment en revanche la baseline recommandée et ne doivent pas être abandonnées sans raison documentée.
+Le contrat universel ci-dessus reste compatible avec des projets Tauri imposés de l'extérieur. Pour un **nouveau projet Tauri contrôlé par l'organisation** qui sélectionne le profil strict PGR, le présent owner définit seulement la convention propre au host et à l'intégration Tauri. La sélection de TypeScript, Vite, CSS/Sass, d'un framework CSS ou d'un package manager reste possédée par les owners Web et par la skeleton specification applicable.
 
-Le host SHOULD être une crate Cargo mixte directement lisible, sans couche `src-tauri/` ajoutée uniquement pour reproduire `create-tauri-app`. Le layout recommandé est :
+Le host SHOULD être une crate Cargo mixte directement lisible, sans couche `src-tauri/` ajoutée uniquement pour reproduire `create-tauri-app`. Cette recommandation est une convention d'organisation PGR pour les nouveaux projets contrôlés ; elle ne signifie ni que `src-tauri/` est invalide, ni qu'un projet existant doit migrer pour être acceptable.
+
+La surface Tauri recommandée reste visible à la racine de la crate :
 
 ```text
 <tauri-crate>/
 ├── Cargo.toml
 ├── build.rs
-├── package.json
-├── tsconfig.json
 ├── tauri.conf.json
 ├── capabilities/
 ├── src/
-└── frontend/
+└── <frontend-root>/
 ```
 
-Un fichier comme `vite.config.ts` appartient également à la racine lorsque Vite est le bundler sélectionné. Un projet externe MAY conserver `src-tauri/` ou une autre organisation lorsque cette structure est imposée ou qu'une migration n'apporte pas de valeur suffisante.
+`<frontend-root>/` représente la racine frontend réellement retenue. Une skeleton PGR MAY choisir `frontend/` comme convention stable, mais `710-TAURI.md` ne transforme pas ce nom en obligation universelle. De même, `package.json`, `tsconfig.json`, `vite.config.ts` ou des sources Sass n'existent que si les owners correspondants sont réellement sélectionnés.
 
 Dans le host Rust, le package mixte `lib + bin` constitue l'exception framework explicite à la séparation générale définie par `510-RUST_CARGO.md`. Pour une nouvelle baseline Tauri contrôlée :
 
@@ -86,11 +86,9 @@ Dans le host Rust, le package mixte `lib + bin` constitue l'exception framework
 
 Lorsque le workspace possède une crate de logging/tracing commune, le host Tauri l'utilise pour initialiser le runtime de diagnostics. Un plugin Tauri de tracing sert alors d'adapter à la frontière desktop/mobile ; il ne remplace pas l'owner Rust de `tracing-subscriber`, des sinks ou du lifecycle de logging.
 
-Lorsque le frontend sélectionné est TypeScript, les structures, énumérations et DTO Rust **possédés par le host** et partagés avec le frontend MUST utiliser TS-RS comme source de génération dans le profil strict, sauf incompatibilité technique explicitement documentée. Le contrat Rust reste la source de vérité ; les bindings générés ne sont pas modifiés manuellement et SHOULD rester hors Git lorsqu'ils sont entièrement reproductibles. Le skeleton MAY normaliser leur sortie sous `frontend/ts/bindings/`.
+Lorsque le frontend sélectionné est TypeScript et que des DTO, structures ou énumérations Rust doivent être partagés, la frontière typée suit [`530-TYPESCRIPT.md`](530-TYPESCRIPT.md). Un générateur tel que TS-RS MAY être retenu comme source de bindings ; le contrat Rust reste alors la source de vérité et les bindings entièrement reproductibles SHOULD rester hors Git. Le choix ou le renforcement de TS-RS appartient au projet ou au futur skeleton Tauri, pas au profil Tauri universel.
 
-Pour les projets contrôlés, `frontend/` est le répertoire recommandé pour les sources Web versionnées. TypeScript et Vite sont fortement recommandés mais restent des `SHOULD`, jamais des obligations universelles. Sass est également fortement recommandé lorsque la chaîne de styles est non triviale ou qu'une dépendance expose des sources Sass/SCSS configurables ; il reste optionnel pour un frontend qui n'en tire pas de valeur. Bootstrap est la baseline de présentation privilégiée lorsque le futur skeleton choisit un framework CSS généraliste, mais il ne devient pas une dépendance Tauri ou Web universelle. Tailwind CSS n'est pas interdit ; son adoption reste une décision explicite du projet. Les règles correspondantes appartiennent aux profils `530`, `550` et `560`, puis au futur skeleton lorsqu'il choisira effectivement cette composition.
-
-L'intégration d'un plugin SHOULD préférer les étapes explicites décrites par sa documentation — dépendance Cargo, initialisation Rust, package frontend et capabilities nécessaires — afin que chaque modification reste visible et revue. `cargo tauri add` MAY être utilisé lorsque ce raccourci apporte une vraie valeur, mais il n'est pas la voie canonique imposée aux projets contrôlés.
+L'intégration d'un plugin SHOULD préférer des étapes explicites ou, si une commande de commodité est utilisée, une revue complète de ses modifications. `cargo tauri add` MAY être utilisé lorsqu'il apporte une valeur réelle ; il n'est pas une voie canonique imposée.
 
 WASM reste normalement une unité séparée de la crate Tauri. Une adaptation WASM réutilisable SHOULD donc posséder sa propre crate/package et ses propres profils ; elle n'est intégrée au host Tauri que lorsqu'une composition architecturale explicite l'exige.
 
@@ -150,15 +148,32 @@ Cette classification évite de réécrire `package.json` et `tauri.conf.json` à
 
 Les numéros propres aux plateformes, par exemple Android `versionCode`, restent possédés par le profil plateforme concerné et ne sont pas assimilés au SemVer produit.
 
-## Capabilities, permissions et frontière WebView/native
+## Commandes, permissions et capabilities
 
-Les capability files et permissions Tauri sont du source de sécurité et SHOULD être versionnés lorsqu'ils définissent intentionnellement la surface exposée au frontend.
+Tauri distingue trois responsabilités qui ne doivent pas être confondues :
 
-Le projet SHOULD accorder uniquement les permissions nécessaires aux fenêtres/webviews concernées. Ajouter un plugin ou une commande native ne justifie pas automatiquement une capability globale plus large.
+```text
+commande enregistrée  → handler natif connu du système d'invocation
+permission             → privilège ACL, avec allow/deny et scopes éventuels
+capability             → attribution de permissions à des fenêtres/webviews et, le cas échéant, à des origines ou plateformes
+```
+
+Déclarer un wrapper `#[tauri::command]` ou enregistrer un handler dans l'application n'est donc pas une preuve suffisante de moindre privilège. Le comportement par défaut des commandes applicatives dépend du mécanisme Tauri réellement utilisé ; lorsqu'une commande ou une opération doit être restreinte, le projet MUST matérialiser et valider la politique correspondante au niveau approprié au lieu de supposer que l'enregistrement du handler constitue une ACL.
+
+Les permissions possèdent les commandes et scopes qu'elles autorisent ou refusent. Les capabilities associent ensuite ces permissions aux fenêtres/webviews concernées. Lorsqu'une fenêtre ou webview appartient à plusieurs capabilities, sa surface effective résulte de leur composition ; la revue MUST donc considérer les droits cumulés, pas chaque fichier isolément.
+
+Les capability files intentionnels sont du source de sécurité et SHOULD être versionnés. Pour une nouvelle baseline contrôlée, le projet MUST décider explicitement comment les capabilities sont sélectionnées :
+
+- sélection explicite dans `app.security.capabilities` ; ou
+- inclusion automatique des fichiers du répertoire `capabilities/` selon le comportement supporté par la version Tauri retenue.
+
+Avec Tauri 2 courant, une configuration `app.security.capabilities` absente ou vide inclut par défaut les capability files du répertoire `capabilities/`, tandis qu'une liste explicite permet de sélectionner les capabilities utilisées. Si le projet conserve l'inclusion automatique, ajouter un nouveau capability file MUST être traité comme une modification de la surface de sécurité. Une sélection explicite SHOULD être préférée dès que plusieurs capabilities, fenêtres ou niveaux de privilège rendent l'auto-inclusion moins lisible.
+
+Le projet SHOULD accorder uniquement les permissions et scopes nécessaires aux fenêtres/webviews concernées. Ajouter un plugin ou une commande native ne justifie pas automatiquement une capability globale plus large.
 
 Les schémas générés référencés par les capability files servent à l'outillage et à la validation de configuration ; ils ne deviennent pas pour autant la source normative de la politique de permissions.
 
-Toute permission distante, origine distante ou extension de scope sensible doit être explicitement justifiée et validée comme frontière de sécurité.
+Toute permission distante, origine distante ou extension de scope sensible MUST être explicitement justifiée et validée comme frontière de sécurité.
 
 ## Plugins
 

docs/skeletons/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/skeletons/000-README.md -->
-<!-- version: 6 -->
+<!-- version: 7 -->
 
 # Index des skeleton specifications PGR
 
@@ -20,6 +20,7 @@ Une specification peut se composer avec une fondation plus générale, mais la c
 - [`001-PROJECT_GOVERNANCE_FOUNDATION.md`](001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation composable pour établir la gouvernance locale, la version, la documentation minimale, le workflow retenu et sa validation initiale sans imposer d'architecture applicative.
 - [`002-RUST_CARGO_WORKSPACE.md`](002-RUST_CARGO_WORKSPACE.md) — specialization composable d'un workspace Rust/Cargo fondée sur `001`, les profils `500 + 510`, les cinq templates Rust/Cargo et une validation réelle de la toolchain.
 - [`003-WEB_FRONTEND.md`](003-WEB_FRONTEND.md) — specialization composable d'un frontend Web contrôlé fondée sur les owners `530/540/550/560`, avec TypeScript/Vite recommandés, Sass conditionnel et validation indépendante du host.
+- [`004-TAURI.md`](004-TAURI.md) — specialization Tauri 2 contrôlée composant fondation, Rust/Cargo, frontend et owner `710`, avec décisions explicites sur layout, capabilities, plugins, versions, packaging et validation proportionnée.
 
 Pour un projet existant, ces specifications servent de références de comparaison et non de recettes à recopier aveuglément. Le chemin canonique passe alors par [`../rules/230-ADOPTION.md`](../rules/230-ADOPTION.md) et son mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`.
 
@@ -27,8 +28,6 @@ Les familles Java/Android, JNI et autres domaines sans pièces suffisantes reste
 
 Le skeleton Web `003` est matérialisé en `0.1.1-alpha.5` parce que les owners `530/540/550/560`, les guides d'adaptation et la validation frontend indépendante du host permettent désormais une composition sans ownership caché. Il ne fixe ni npm, ni Vite/Sass comme obligations, ni Bootstrap, ni un layout `frontend/` universel.
 
-Le skeleton Tauri a fait l'objet d'une décision explicite en `0.0.5-alpha.9` : son host Rust/Tauri est cadré par `510` et `710`, mais sa promotion avait été différée tant que les owners Web nécessaires n'existaient pas. La décision `DEFER` et ses conditions de sortie restent enregistrées dans [`../studies/002-TAURI_SKELETON_DECISION.md`](../studies/002-TAURI_SKELETON_DECISION.md).
-
-La création du skeleton Web ne lève pas automatiquement ce `DEFER`. `0.1.1-beta.1` doit encore réconcilier objectivement les conditions de sortie avant que `0.1.4` ne réexamine un éventuel skeleton Tauri, qui devra composer les owners Web au lieu de posséder leurs règles.
+Le skeleton Tauri avait été différé en `0.0.5-alpha.9` tant que les owners Web nécessaires n'existaient pas. `0.1.4-alpha.1` a confirmé les conditions de sortie, `alpha.2` a réconcilié l'owner `710`, puis `alpha.3` matérialise `004-TAURI.md` comme specification de composition sans reprendre l'ownership Web. L'étude historique et la levée du `DEFER` restent enregistrées dans [`../studies/002-TAURI_SKELETON_DECISION.md`](../studies/002-TAURI_SKELETON_DECISION.md).
 
 Aucun fichier placeholder ne doit être ajouté pour réserver un skeleton futur.

docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Skeleton — Project governance foundation
 
@@ -70,7 +70,9 @@ Ce document doit au minimum :
 - 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.
+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 et possédé par lui. Une URL vers PGR ne remplace pas à elle seule une baseline locale exploitable et ne crée pas un upstream documentaire implicite.
+
+À l'issue de l'instanciation, la baseline locale et ses owners deviennent l'autorité des sessions et releases suivantes. Le projet MUST NOT rechercher automatiquement « la dernière version de PGR ». Un réalignement ultérieur MAY être entrepris uniquement comme opération explicite à partir d'un snapshot PGR précis choisi puis comparé à cette baseline locale.
 
 ### Version
 

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/skeletons/004-TAURI.md

@@ -0,0 +1,217 @@
+<!-- file: docs/skeletons/004-TAURI.md -->
+<!-- version: 1 -->
+
+# Skeleton — Tauri 2
+
+## Objectif
+
+Cette specification décrit une baseline organisationnelle composable pour une application Tauri 2 contrôlée par le projet, sans transformer les choix observés dans Games ou KSP en obligations universelles.
+
+Elle compose les responsabilités déjà possédées par :
+
+- [`001-PROJECT_GOVERNANCE_FOUNDATION.md`](001-PROJECT_GOVERNANCE_FOUNDATION.md) pour la gouvernance locale ;
+- [`002-RUST_CARGO_WORKSPACE.md`](002-RUST_CARGO_WORKSPACE.md) pour le workspace et le host Rust/Cargo ;
+- [`003-WEB_FRONTEND.md`](003-WEB_FRONTEND.md) lorsque le frontend Web est gouverné par cette baseline ;
+- [`../rules/710-TAURI.md`](../rules/710-TAURI.md) pour l'intégration Tauri elle-même.
+
+Le contrat transversal des skeletons reste possédé par [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md). Le présent document sélectionne et ordonne des décisions ; il ne recopie pas les règles de ces owners.
+
+## Applicabilité
+
+Appliquer ce skeleton à un nouveau host Tauri 2 dont le projet contrôle l'organisation du dépôt et souhaite une baseline PGR composable.
+
+Pour un projet Tauri existant, cette specification sert d'abord de référence de comparaison. L'adoption suit [`../rules/230-ADOPTION.md`](../rules/230-ADOPTION.md) et classe les écarts `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` au lieu de migrer mécaniquement vers le layout proposé.
+
+Ne pas appliquer ce skeleton uniquement parce qu'un frontend Web existe, parce qu'une application desktop est envisagée ou parce que Tauri apparaît dans un autre projet. La présence effective d'un host Tauri 2 est la condition d'applicabilité.
+
+## Composition de référence
+
+Pour une nouvelle baseline contrôlée, l'ordre de composition est :
+
+```text
+001 PROJECT_GOVERNANCE_FOUNDATION
+  ↓
+002 RUST_CARGO_WORKSPACE
+  ↓
+003 WEB_FRONTEND              si le frontend est gouverné ici
+  ↓
+710 TAURI                     owner framework
+  ↓
+004 TAURI                     présente specification d'instanciation
+  ↓
+profils plateforme            Android/iOS/autres uniquement s'ils sont ciblés
+```
+
+Cette composition ne transfère aucun ownership. TypeScript, package manager, Vite, CSS/Sass et framework CSS restent possédés par leurs owners Web ; Cargo/Rust reste possédé par `510`; Android reste possédé par `610` lorsqu'il s'applique.
+
+## Décisions obligatoires avant matérialisation
+
+Le projet doit résoudre explicitement au minimum :
+
+1. l'identité du host, sa place dans le workspace et les noms distincts de ses cibles `lib` et `bin` ;
+2. la version de Tauri 2 réellement retenue et sa stratégie de mise à jour ;
+3. la racine frontend et les owners Web réellement sélectionnés ;
+4. le package manager frontend lorsqu'un package JavaScript existe ;
+5. les commandes de développement et de build reliant Tauri au frontend ;
+6. la stratégie `devUrl` / `frontendDist` cohérente avec la chaîne frontend ;
+7. les capabilities réellement nécessaires et leur mode de sélection ;
+8. les permissions, commandes natives et scopes associés ;
+9. les plugins réellement requis et leurs modifications de configuration/ACL ;
+10. les fenêtres/webviews réellement nécessaires et leur répartition de privilèges ;
+11. la politique de version pour `tauri.conf.json` et le frontend conformément aux règles de gouvernance ;
+12. les ressources, icônes, bundle targets et cibles plateforme réellement distribuées ;
+13. la gate initiale capable de prouver les surfaces effectivement matérialisées.
+
+Une décision encore inconnue reste une entrée ouverte ; elle ne doit pas être remplacée par une valeur copiée depuis Games, KSP ou un scaffold Tauri.
+
+## Baseline organisationnelle recommandée
+
+Pour un nouveau projet contrôlé, le host **SHOULD** rester une crate Cargo directement lisible et la surface Tauri **SHOULD** être visible à la racine de cette crate :
+
+```text
+<tauri-crate>/
+├── Cargo.toml
+├── build.rs
+├── tauri.conf.json
+├── capabilities/
+├── src/
+│   ├── lib.rs
+│   ├── main.rs
+│   └── tauri.rs
+└── frontend/
+```
+
+`frontend/` est la convention de cette baseline PGR lorsque le projet n'a pas déjà une autre racine frontend motivée. Un projet existant ou une contrainte externe peut conserver `src-tauri/`, une autre racine frontend ou une autre disposition supportée par la toolchain ; cet écart n'est pas à lui seul une raison de réécriture.
+
+Le package Tauri contrôlé **SHOULD** utiliser une paire `lib + bin` conforme à `710-TAURI.md` : bibliothèque applicative/façade, launcher mince et module `src/tauri.rs` pour l'assemblage Tauri et les wrappers d'invocation.
+
+## Frontend
+
+Lorsque le projet ne possède pas déjà une stack frontend imposée ou motivée, la baseline Web de `003-WEB_FRONTEND.md` **SHOULD** être utilisée : TypeScript et Vite sont alors les choix recommandés, sans devenir des obligations Tauri universelles.
+
+Le package manager est une décision du projet. npm, pnpm, yarn, Bun ou un autre outil supporté peuvent être retenus selon l'environnement et les contraintes réelles.
+
+Sass et un framework CSS restent optionnels. Bootstrap, Tailwind CSS ou un autre framework ne sont jamais ajoutés par ce skeleton uniquement parce qu'ils existent dans un corpus historique.
+
+WASM reste une unité séparée par défaut. Une chaîne WASM n'est intégrée dans le host que si l'architecture du produit l'exige explicitement.
+
+## Capabilities, permissions et commandes
+
+La baseline doit rendre visibles les trois niveaux distincts définis par `710-TAURI.md` :
+
+```text
+commande native enregistrée
+permission ACL
+capability attribuée à une fenêtre/webview
+```
+
+Pour une baseline simple à une capability, le projet peut conserver le comportement d'inclusion automatique supporté par sa version Tauri si cette décision est explicite et relue.
+
+Dès que plusieurs capabilities, fenêtres/webviews ou niveaux de privilège apparaissent, une sélection explicite via `app.security.capabilities` **SHOULD** être préférée pour rendre la surface effective plus lisible.
+
+Chaque ajout de plugin, permission, scope, origine distante ou capability doit être revu comme une modification de sécurité. Une commande enregistrée n'implique pas automatiquement qu'elle doit être accessible depuis toutes les fenêtres.
+
+## Plugins
+
+Aucun plugin n'est ajouté par défaut.
+
+Lorsqu'un plugin est nécessaire, choisir sa version compatible, ajouter seulement les dépendances et bindings réellement utilisés, puis revoir les changements Rust, frontend, configuration et ACL associés.
+
+Une commande de commodité comme `cargo tauri add` peut être utilisée si elle apporte une valeur réelle, mais la voie de validation reste la revue des fichiers effectivement modifiés. Le skeleton n'exige pas cette commande.
+
+## Versions et métadonnées produit
+
+`VERSION` reste la version canonique lorsque le projet adopte ce contrat de gouvernance.
+
+La version du package Cargo du host suit la politique du workspace. `tauri.conf.json > version` et une éventuelle `package.json > version` doivent être classés explicitement, par exemple `MIRROR-STABLE` ou `MIRROR-EXACT`, selon le contrat de distribution réel.
+
+Les identifiers d'application, noms de produit, bundle identifiers, publisher metadata et numéros plateforme sont des décisions produit/plateforme ; le skeleton ne fournit aucune identité fictive.
+
+## Ordre d'initialisation
+
+Une instanciation neuve suit normalement cet ordre :
+
+1. appliquer la fondation locale et décider la version/unité de release ;
+2. matérialiser ou adapter le workspace Rust/Cargo ;
+3. créer le host Tauri et ses cibles `lib + bin` ;
+4. sélectionner puis matérialiser la baseline frontend ;
+5. raccorder `beforeDevCommand`, `beforeBuildCommand`, `devUrl` et `frontendDist` selon les outils réellement choisis ;
+6. créer `tauri.conf.json` avec uniquement les propriétés utiles ;
+7. créer les capability files et décider leur sélection ;
+8. ajouter uniquement les commandes et plugins nécessaires ;
+9. configurer fenêtres, ressources et bundle targets réellement requis ;
+10. composer les profils plateforme applicables ;
+11. exécuter la gate initiale proportionnée.
+
+L'ordre peut être adapté lorsqu'une toolchain officielle crée certaines pièces automatiquement. Les fichiers générés doivent alors être relus et adaptés aux owners locaux avant d'être considérés comme baseline.
+
+## Validation initiale
+
+La gate minimale dépend des surfaces réellement créées. Elle **SHOULD** séparer les preuves :
+
+```text
+Rust/Cargo
+→ fmt/check/clippy/tests sélectionnés par le projet
+
+frontend
+→ restore/typecheck/build/styles selon 003 et 005-WEB_FRONTEND_VALIDATION
+
+Tauri integration
+→ lancement Tauri ou smoke équivalent quand hooks/config/IPC/capabilities sont concernés
+
+packaging
+→ tauri build uniquement lorsqu'un artefact packagé doit réellement être prouvé
+
+plateforme mobile
+→ gates Android/iOS applicables en plus de Tauri
+```
+
+Une nouvelle baseline qui possède `beforeDevCommand`, `beforeBuildCommand`, `devUrl`, `frontendDist`, des commands ou des capabilities doit au minimum exercer une commande Tauri supportée qui charge réellement cette configuration ; un simple `cargo check` ne prouve pas cette intégration.
+
+Le projet doit également vérifier :
+
+```text
+CHECK  aucun placeholder ou identifiant fictif provenant de PGR/Games/KSP
+CHECK  noms lib/bin non ambigus après normalisation Cargo
+CHECK  frontend root et outputs cohérents avec tauri.conf.json
+CHECK  capabilities intentionnelles et surface cumulée relue
+CHECK  plugins présents uniquement s'ils sont utilisés
+CHECK  artefacts générés exclus ou classifiés selon leur rôle réel
+CHECK  secrets/signing credentials hors Git
+REVIEW fenêtres, bundles, ressources et targets réellement nécessaires
+```
+
+## Templates techniques
+
+Aucun template Tauri technique supplémentaire n'est requis pour matérialiser cette specification.
+
+Le host dépend trop des décisions de nommage, de frontend, de capabilities, de plugins, de fenêtres, de plateformes et de versions pour qu'un `tauri.conf.json`, `Cargo.toml`, capability file ou `src/tauri.rs` universel apporte actuellement plus de valeur qu'il ne créerait de placeholders et de defaults arbitraires.
+
+Les templates Rust/Cargo et Web existants restent utilisables pour leurs responsabilités propres. Un futur template Tauri ne sera justifié que si un besoin répétitif non correctement possédé par ces artefacts est démontré.
+
+## Projet existant
+
+Pour un projet existant :
+
+- conserver son layout supporté lorsqu'une migration n'apporte pas de valeur démontrée ;
+- comparer les owners et décisions plutôt que les noms de fichiers ;
+- inventorier capabilities, plugins, commandes, hooks, fenêtres, bundles et plateformes ;
+- classer les écarts selon `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
+- introduire les changements par tranches validables plutôt qu'en remplaçant le scaffold complet.
+
+L'objectif est l'autonomie locale du projet, pas sa ressemblance visuelle avec le skeleton PGR.
+
+## Hors scope
+
+Cette specification ne possède pas :
+
+- un framework frontend ou CSS universel ;
+- un package manager universel ;
+- une version exacte de Tauri/CLI/plugin ;
+- un port de développement universel ;
+- un catalogue de plugins ;
+- une configuration de fenêtres ou bundles universelle ;
+- une chaîne WASM implicite ;
+- les règles Android/iOS ;
+- un CI/CD ou deployment universel ;
+- un template technique Tauri par symétrie.

docs/studies/000-README.md

@@ -1,5 +1,5 @@
 <!-- file: docs/studies/000-README.md -->
-<!-- version: 4 -->
+<!-- version: 6 -->
 
 # Index des études PGR
 
@@ -12,3 +12,5 @@ Une étude peut comparer des projets sources, des technologies ou plusieurs opti
 - [`001-KSP_GAMES_RECONCILIATION.md`](001-KSP_GAMES_RECONCILIATION.md) — première réconciliation explicite de PGR avec les baselines autoritaires fournies de `khadhroony-solana-project` et `sasedev-games`.
 - [`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/002-TAURI_SKELETON_DECISION.md

@@ -1,15 +1,15 @@
 <!-- file: docs/studies/002-TAURI_SKELETON_DECISION.md -->
-<!-- version: 2 -->
+<!-- version: 4 -->
 
 # Décision de skeleton Tauri pour projets contrôlés
 
 ## Objet
 
-Cette étude enregistre la décision `0.0.5-alpha.9` sur la matérialisation d'un skeleton Tauri pour les nouveaux projets que l'organisation contrôle.
+Cette étude conserve la décision historique `0.0.5-alpha.9` sur la matérialisation d'un skeleton Tauri pour les nouveaux projets que l'organisation contrôle, puis son réexamen formel pendant `0.1.4`.
 
 Elle ne redéfinit pas les règles Tauri. Leur owner normatif reste [`../rules/710-TAURI.md`](../rules/710-TAURI.md). Le contrat des skeletons reste possédé par [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md).
 
-## Corpus et état observé
+## Corpus historique et état observé `0.0.5`
 
 Le corpus de réconciliation reste celui de `0.0.5` :
 
@@ -78,7 +78,7 @@ Références vérifiées le `2026-09-25` :
 - <https://v2.tauri.app/plugin/file-system/>
 - <https://v2.tauri.app/learn/security/using-plugin-permissions/>
 
-## Décision
+## Décision historique `0.0.5-alpha.9`
 
 Décision `alpha.9` :
 
@@ -232,3 +232,126 @@ création automatique         interdite
 `0.1.4` devra réexaminer le corpus alors courant, les versions/outils réellement soutenus, le profil `710-TAURI.md` et la composition avec `003-WEB_FRONTEND.md`. Il pourra confirmer, modifier ou abandonner le candidat historique. La présente étude ne préjuge pas de cette décision.
 
 Le candidat historique `frontend/ + Vite + TypeScript + Sass + Bootstrap + TS-RS` reste donc une observation à réexaminer, pas une baseline déjà approuvée. En particulier, `frontend/`, Vite, Sass et Bootstrap ne deviennent pas des obligations Tauri du seul fait que les owners permettant de les encadrer existent désormais.
+
+## Réexamen décisionnel `0.1.4-alpha.2`
+
+`0.1.4-alpha.1` a réaudité le corpus au lieu de prolonger le `DEFER` par inertie. Les baselines réellement fournies sont :
+
+```text
+Games 0.3.6  1 host Tauri
+KSP 0.3.19    6 hosts Tauri
+```
+
+Les `7` hosts actuels convergent encore sur un host Cargo direct `lib + bin`, `build.rs`, `tauri.conf.json`, `capabilities/`, `src/tauri.rs`, une racine frontend dédiée, TypeScript et Vite, sans `src-tauri/`. Games n'exerce toutefois plus les deux hosts du corpus historique, et Bootstrap/Sass/TS-RS, plugins, fenêtres, ACL, ports, bundle/resources et WASM restent suffisamment variables pour ne pas former une baseline Tauri indivisible.
+
+Les cinq conditions de sortie historiques sont désormais couvertes par les owners Web `530/540/550/560`, `005-WEB_FRONTEND_VALIDATION.md` et `003-WEB_FRONTEND.md`. Le motif Web qui bloquait la matérialisation en `0.0.5` est donc levé.
+
+La réconciliation de `710-TAURI.md` en révision `7` précise en outre :
+
+- la distinction entre commande enregistrée, permission et capability ;
+- la nécessité de traiter la sélection des capability files comme une décision de sécurité explicite ;
+- la composition cumulative des droits lorsqu'une fenêtre/webview appartient à plusieurs capabilities ;
+- le statut de `src-tauri/` comme layout supporté, tandis que le host Cargo direct reste une convention PGR recommandée pour les nouvelles baselines contrôlées ;
+- l'ownership Web séparé : TypeScript, Vite, Sass/CSS, framework CSS, package manager et génération de bindings ne sont plus choisis par le profil Tauri lui-même ;
+- la validation proportionnée par owner plutôt qu'un `tauri build` systématique.
+
+### Décision active
+
+La décision active de `0.1.4-alpha.2` est :
+
+```text
+DEFER historique pour absence d'owners Web    LIFT
+candidat organisationnel                      ADOPT FOR MATERIALIZATION
+skeleton à matérialiser                        docs/skeletons/004-TAURI.md
+matérialisation dans alpha.2                   NO
+matérialisation visée                          alpha.3
+```
+
+Le `DEFER` de `0.0.5-alpha.9` reste conservé comme décision historique ; il n'est plus la décision active du candidat courant.
+
+### Composition retenue pour `alpha.3`
+
+La specification Tauri candidate devra composer, sans duplication normative :
+
+```text
+001-PROJECT_GOVERNANCE_FOUNDATION
++ 002-RUST_CARGO_WORKSPACE
++ 003-WEB_FRONTEND lorsque le projet possède le frontend contrôlé correspondant
++ profil Tauri 710
++ profils plateforme réellement ciblés
+```
+
+Le skeleton pourra proposer `frontend/`, TypeScript et Vite comme baseline recommandée pour une nouvelle application contrôlée compatible, mais devra laisser visibles les décisions destinataire et ne pas convertir ces recommandations en obligations Tauri. Sass, Bootstrap, TS-RS, plugins, fenêtres, ports, CSP, bundle targets, ressources et valeurs plateforme restent conditionnels au besoin réel.
+
+La specification devra également rendre explicite la politique de sélection des capabilities et la revue de la surface de sécurité avant sa gate initiale.
+
+### Artefacts toujours différés
+
+Le réexamen ne démontre toujours pas le besoin de créer en `alpha.2` :
+
+- un template technique Tauri copiable ;
+- un contrat de validation Tauri séparé ;
+- un catalogue de plugins ou permissions par défaut ;
+- un framework CSS universel ;
+- un owner iOS, serveur Rust ou deployment/operations par proximité.
+
+Ces décisions restent à réévaluer après matérialisation de la specification, conformément au plan `0.1.4`.
+
+## Réconciliation finale des artefacts `0.1.4-beta.1`
+
+La matérialisation de `docs/skeletons/004-TAURI.md` en `alpha.3` permet de vérifier la frontière entre specification organisationnelle, owner Tauri, owners Web et validations existantes.
+
+### Couverture obtenue
+
+La composition active est :
+
+```text
+001-PROJECT_GOVERNANCE_FOUNDATION
++ 002-RUST_CARGO_WORKSPACE
++ 003-WEB_FRONTEND si applicable
++ 710-TAURI
++ 004-TAURI
++ profils plateforme réellement ciblés
+```
+
+`004-TAURI.md` ne recopie pas les règles de ces owners. Il possède les décisions d'instanciation et renvoie les contraintes détaillées à leurs documents respectifs.
+
+### Template technique Tauri
+
+Décision : **DO NOT CREATE**.
+
+Aucun ensemble de fichiers Tauri (`Cargo.toml`, `build.rs`, `tauri.conf.json`, capability files, `src/tauri.rs`) ne peut être rendu générique sans choisir prématurément au moins une partie des éléments suivants : nom du host, hooks frontend, ports/URLs, capabilities, permissions, plugins, fenêtres, identifiers, resources, bundle targets ou plateformes.
+
+Les templates Rust/Cargo et Web existants possèdent déjà les parties réellement réutilisables. Un futur template Tauri reste possible uniquement après démonstration d'un sous-ensemble répétitif non arbitraire dans plusieurs instanciations réelles.
+
+### Contrat de validation Tauri séparé
+
+Décision : **DO NOT CREATE**.
+
+La preuve nécessaire est déjà composable :
+
+- Rust/Cargo par les owners Rust et la matrice de validation ;
+- frontend par `005-WEB_FRONTEND_VALIDATION.md` ;
+- intégration Tauri, ACL, hooks et packaging par `710-TAURI.md` et la gate initiale de `004-TAURI.md` ;
+- plateformes mobiles par leurs profils applicables.
+
+Créer `docs/validation/006-TAURI_VALIDATION.md` aujourd'hui dupliquerait ces responsabilités sans lacune démontrée.
+
+### Dry-run local
+
+Décision : **NOT REQUIRED** pour `0.1.4-beta.1`.
+
+Le skeleton est une specification et ne fournit pas de scaffold exécutable. Créer un faux projet uniquement pour obtenir un lancement Tauri introduirait précisément les valeurs arbitraires que la specification cherche à éviter. Les sept hosts Games/KSP déjà audités fournissent le corpus d'implémentation ; `beta.1` doit vérifier statiquement que la specification les abstrait sans copier leurs choix locaux.
+
+### Décision active après `beta.1`
+
+```text
+DEFER historique Web                         LIFT
+004-TAURI.md                                  KEEP
+template Tauri générique                     DO NOT CREATE
+validation Tauri séparée                     DO NOT CREATE
+dry-run factice                              NOT REQUIRED
+artefact supplémentaire sans lacune réelle   FORBIDDEN BY DEFAULT
+```
+
+La prochaine étape est la RC : freeze du scope Tauri, préparation du changelog candidate et revue d'horizon transversale avant tout prompt de release suivante.

docs/studies/004-V0_1_4_HORIZON_REVIEW.md

@@ -0,0 +1,139 @@
+<!-- file: docs/studies/004-V0_1_4_HORIZON_REVIEW.md -->
+<!-- version: 1 -->
+
+# Revue d’horizon 0.1.4 — sémantique normative, autonomie et frontière Knowledge
+
+## Objet
+
+Cette étude clôt la revue d’horizon explicitement requise par le plan `0.1.4`. Elle décide si les adoptions Games/KSP peuvent suivre immédiatement la release Tauri ou si un contrat transversal doit être stabilisé auparavant.
+
+Le déclencheur provient d’un usage réel de PGR pour initialiser SaseDev Knowledge. Trois ambiguïtés ont été observées sans remettre en cause le travail Tauri de `0.1.4` : force réelle de `SHOULD`, relation d’un projet avec PGR après adoption, et emplacement futur des howtos/recettes/snippets lorsque Knowledge devient suffisamment fonctionnel.
+
+## Sources PGR examinées
+
+Les owners actuels pertinents sont :
+
+```text
+RULES.md
+rules/200-GOVERNANCE.md
+rules/210-WORKFLOW.md
+rules/220-SKELETONS.md
+rules/230-ADOPTION.md
+rules/400-VALIDATION.md
+skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+templates/003-NEW_SESSION_PROMPT.md
+templates/007-EXISTING_PROJECT_ADOPTION.md
+```
+
+Ces documents contiennent déjà des éléments compatibles avec l’intention recherchée, notamment l’autonomie du projet et la copie locale des règles applicables. Le défaut est une insuffisance de précision et de propagation du contrat, pas l’absence totale du principe.
+
+## 1. Force normative de `SHOULD`
+
+La formulation actuelle décrit `SHOULD / SHOULD NOT` comme un comportement attendu par défaut avec dérogation possible si une autre solution est mieux adaptée et justifiée. Cette rédaction peut être interprétée comme une obligation conditionnelle.
+
+La prochaine clarification doit établir sans ambiguïté :
+
+```text
+MUST / MUST NOT       exigence normative ; écart = non-conformité sauf exception/override autorisé
+SHOULD / SHOULD NOT   forte recommandation ; préférence par défaut mais non obligatoire
+MAY                   possibilité neutre ; aucune préférence implicite
+```
+
+Un écart à un `SHOULD` :
+
+- MUST NOT devenir à lui seul une non-conformité ;
+- MUST NOT faire échouer à lui seul une gate ;
+- MUST NOT exiger automatiquement un `OVERRIDE` ;
+- MAY être documenté lorsqu’il est significatif pour la maintenance, l’architecture ou la reprise future.
+
+La distinction est suffisamment structurante pour être stabilisée avant toute nouvelle adoption réelle.
+
+## 2. Autonomie après instanciation ou adoption
+
+PGR doit être un référentiel d’initialisation, de comparaison et de réalignement volontaire, pas un upstream vivant implicitement suivi par chaque projet.
+
+Le contrat cible est :
+
+```text
+snapshot PGR choisi
+        ↓
+instanciation / adoption / adaptation
+        ↓
+baseline locale du projet
+        ↓
+règles locales = autorité des sessions/releases suivantes
+```
+
+Après établissement de la baseline locale :
+
+- le projet MUST fonctionner sans rechercher une version PGR plus récente ;
+- le projet MUST NOT considérer PGR comme une dépendance documentaire implicite à mettre à jour à chaque session ;
+- ses règles, architecture, plans, templates et validations locales deviennent l’autorité de son évolution ;
+- la version PGR utilisée MAY être conservée comme provenance historique ;
+- un réalignement futur avec PGR est une opération explicite, bornée et volontaire, utilisant un snapshot PGR choisi et une nouvelle comparaison des écarts.
+
+Ce point doit être propagé dans les contrats de reprise et d’adoption, sinon l’autonomie déjà annoncée dans les règles reste trop facile à contourner involontairement.
+
+## 3. Frontière PGR / SaseDev Knowledge
+
+PGR et Knowledge doivent rester utilisables indépendamment.
+
+La frontière cible est :
+
+```text
+PGR
+  contrats normatifs et de gouvernance
+  owners et règles applicables
+  skeleton specifications minimales
+  templates nécessaires à un contrat réutilisable
+  contrats de validation/audit directement liés à ces règles
+
+SaseDev Knowledge
+  howtos détaillés
+  recettes et procédures pratiques
+  snippets
+  exemples d’intégration
+  dépannage et variantes d’implémentation
+  explications pédagogiques et comparatifs pratiques
+```
+
+PGR MUST rester auto-suffisant pour comprendre et appliquer une règle. Une règle PGR ne doit pas dépendre d’un howto Knowledge pour déterminer ce qu’elle exige.
+
+La future disponibilité de Knowledge MAY justifier l’épuration de contenus pratiques devenus redondants dans PGR, mais aucune extraction ne doit être effectuée uniquement pour anticiper cette disponibilité. Le déplacement physique exige un corpus Knowledge suffisamment fonctionnel et explicitement fourni comme source autoritaire de destination.
+
+## Décision d’horizon
+
+Les trois sujets sont transversaux à toutes les adoptions futures. Les reporter après Games/KSP ferait courir le risque de propager une sémantique ambiguë ou une liaison implicite à PGR dans les projets précisément utilisés pour éprouver le modèle d’adoption.
+
+Décision : **une release de gouvernance/autonomie doit précéder les adoptions Games/KSP**.
+
+La trajectoire devient :
+
+```text
+0.1.4   Tauri et skeleton contrôlé
+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
+```
+
+Aucun numéro au-delà de `0.1.8` n’est réservé par cette étude.
+
+## Scope attendu de 0.1.5
+
+`0.1.5` devra au minimum :
+
+1. clarifier la force de `MUST / SHOULD / MAY` et les conséquences de gate ;
+2. rendre explicite l’autorité locale après instanciation/adoption dans `230-ADOPTION`, les skeletons et les patterns de reprise concernés ;
+3. définir un mécanisme de réalignement PGR volontaire sans mise à jour automatique ;
+4. formaliser la frontière PGR / SaseDev Knowledge et classifier les contenus qui doivent rester normatifs ou devenir candidats à un futur transfert ;
+5. vérifier que PGR reste autonome sans dépendance à Knowledge ;
+6. ne pas commencer les adoptions Games/KSP ni les audits Rust réservés aux releases suivantes.
+
+Une archive SaseDev Knowledge MAY être utilisée comme corpus d’observation si elle est explicitement fournie, mais `0.1.5` ne doit pas dépendre de son existence pour corriger les contrats PGR.
+
+## Hors scope de la présente RC
+
+La présente étude ne modifie pas encore `RULES.md`, `230-ADOPTION.md`, `400-VALIDATION.md`, les skeletons de fondation ou les templates de reprise. Ces modifications appartiennent à `0.1.5` afin que `0.1.4-rc.1` reste une phase de freeze Tauri et de handoff.
+
+Elle ne migre ni Games ni KSP et ne déplace aucun contenu vers SaseDev Knowledge.

docs/studies/005-V0_1_5_HORIZON_REVIEW.md

@@ -0,0 +1,105 @@
+<!-- file: docs/studies/005-V0_1_5_HORIZON_REVIEW.md -->
+<!-- version: 2 -->
+
+# 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.
+
+Cette revue confirme qu’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. La classification canonique est `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A` :
+
+```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.

docs/templates/007-EXISTING_PROJECT_ADOPTION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/templates/007-EXISTING_PROJECT_ADOPTION.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Pattern — adoption PGR d’un projet existant
 
@@ -14,13 +14,14 @@ Il peut être instancié comme étude, plan, tableau de décision ou section d
 Consigner uniquement ce qui est réellement établi :
 
 ```text
-repository / archive : <source>
+repository / archive : <source locale autoritaire>
 commit / tag          : <si connu>
 version               : <si applicable>
+snapshot PGR choisi   : <version / tag / commit / archive de comparaison>
 validation connue     : <preuves déjà acquises et encore pertinentes>
 ```
 
-Ne pas reconstruire une baseline à partir d’hypothèses ou d’une version plus récente de PGR.
+Ne pas reconstruire une baseline à partir d’hypothèses ou d’une version plus récente de PGR. Le snapshot PGR est une entrée de comparaison explicitement choisie pour cette opération ; il n'est pas un upstream que le projet doit suivre ensuite.
 
 ## Inventaire utile
 
@@ -74,6 +75,20 @@ Exemples :
 - dette héritée documentée mais non réécrite rétroactivement.
 ```
 
+
+## Autorité après adoption
+
+À la clôture du scope, consigner explicitement que la baseline locale obtenue devient l'autorité des sessions et releases suivantes. Une forme courte suffit :
+
+```text
+baseline locale autoritaire : <version / commit / état accepté>
+réalignement PGR automatique : non
+```
+
+Les reprises ultérieures partent des règles, plans, architecture et histories du projet. Elles ne recherchent pas automatiquement « la dernière version de PGR ».
+
+Si un réalignement futur est souhaité, ouvrir une nouvelle opération bornée : choisir un snapshot PGR précis, comparer ses owners applicables à la baseline locale, classifier les écarts `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, puis valider seulement le scope retenu. Les snapshots historiques locaux restent inchangés.
+
 ## Validation de sortie
 
 L’adoption du scope est prête lorsque :

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.
 

docs/validation/001-VALIDATION_MATRIX.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # Matrice de validation PGR
 
@@ -14,8 +14,9 @@ Les catégories et règles de sélection sont définies dans [`../rules/400-VALI
 ## Contrôles actifs
 
 | ID                     | Catégorie | Commande / contrôle                                                                  | Prérequis              | Trigger                         | Phase                | Coût   | Acteur          |
-|---------------------|-----------|--------------------------------------------------------------------------------------|------------------------|---------------------------------|----------------------|--------|-----------------|
+|------------------------|-----------|--------------------------------------------------------------------------------------|------------------------|---------------------------------|----------------------|--------|-----------------|
 | `PGR-GIT-001`          | `CHECK`   | `git diff --check` ou `git diff --cached --check` selon l'état de l'index            | Git                    | toute modification suivie       | alpha/beta/RC/stable | faible | opérateur       |
+| `PGR-TEXT-HYGIENE-001` | `AUDIT`   | `python3 -B scripts/audit_text_hygiene.py <paths...>`                                | Python 3               | fichier texte gouverné modifié  | alpha/beta/RC/stable | faible | opérateur/CI    |
 | `PGR-VERSION-001`      | `CHECK`   | comparer `VERSION` à la version attendue par le delta courant                        | fichier `VERSION`      | changement de tranche/version   | alpha/beta/RC/stable | faible | opérateur       |
 | `PGR-LAYOUT-001`       | `AUDIT`   | comparer les fichiers ajoutés/remplacés/supprimés au scope déclaré du delta          | scope du delta         | changement de structure         | alpha/beta/RC/stable | faible | opérateur/revue |
 | `PGR-DOC-001`          | `AUDIT`   | vérifier chemins, rôles et responsabilités des documents touchés                     | fichiers documentaires | modification documentaire       | alpha/beta/RC/stable | faible | opérateur/revue |
@@ -27,6 +28,8 @@ Les catégories et règles de sélection sont définies dans [`../rules/400-VALI
 
 Un contrôle manuel peut rester dans la matrice lorsqu'aucun audit automatisé fiable n'existe encore. PGR SHOULD automatiser uniquement les propriétés stables et objectivement contrôlables.
 
+`PGR-TEXT-HYGIENE-001` est un contrôle mécanique indépendant du sens documentaire. Sur les fichiers texte sélectionnés, il exige des fins de ligne LF, interdit le whitespace terminal et exige exactement une seule newline finale ; une ligne vide supplémentaire à EOF est donc rejetée avant commit. Il complète les contrôles Git au lieu de les remplacer.
+
 `PGR-MD-TABLE-001` reste volontairement monotâche : il contrôle uniquement la structure et l'alignement source des tableaux Markdown. Il couvre les tableaux Markdown ordinaires ainsi que les exemples placés dans des fences explicitement `markdown` ou `md`. Les autres blocs fenced restent ignorés afin de ne pas interpréter comme Markdown des sorties terminal, extraits de code ou tableaux ASCII d'un autre langage.
 
 `PGR-MD-HEADER-001` contrôle seulement les deux premières lignes des fichiers Markdown sélectionnés : chemin relatif depuis la racine et révision interne positive. La revue `PGR-DOC-001` reste responsable du rôle documentaire et de la pertinence réelle d'un incrément de révision.

history/0.1.3/alpha.1.md

@@ -0,0 +1,89 @@
+<!-- file: history/0.1.3/alpha.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.3-alpha.1 — audit de stable, corpus et plan Android
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.3-alpha.1` exécutée le `2026-09-28` est propre. Le plan Android créé depuis la stable `v0.1.2` et le corpus Games autoritaire est cohérent avec les frontières annoncées ; aucun fix de cadrage n'est requis avant `alpha.2`.
+
+## Contrôles d'identité
+
+Les contrôles opérateur ont confirmé :
+
+```text
+VERSION                                           0.1.3-alpha.1
+docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md  présent
+deltas/0.1.3/alpha.1.md                           présent
+history/0.1.3/alpha.1.md                          absent pendant la gate
+README.md                                          version 23
+docs/000-README.md                                 version 37
+```
+
+Les deux index référencent bien le plan actif `009-V0_1_3_ANDROID_REEVALUATION_PLAN.md`.
+
+## Tests Python
+
+La suite complète a affiché :
+
+```text
+Ran 48 tests in 0.767s
+
+OK
+```
+
+Soit `48/48` tests `PASS`.
+
+## Audits Markdown
+
+Les trois audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (252 file(s))
+Markdown table audit: clean (11 table(s), 252 file(s))
+Markdown link audit: clean (316 local link(s), 252 file(s))
+```
+
+## Audit structurel `alpha.1`
+
+Le contrôle structurel de la tranche a affiché :
+
+```text
+0.1.3 alpha.1 structural audit: clean (90 prior pairs, Games Android classified, Tauri/adoption boundaries preserved)
+```
+
+Il a notamment confirmé :
+
+- les `90` couples delta/history antérieurs attendus et les sept histories `0.1.2` tous `PASS` ;
+- `0.1.2` terminé, `0.1.3` à `0.1.7` toujours engagés et aucune réservation `0.1.8` ;
+- la présence dans le prompt `009` de la baseline Games attendue, de la classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, des questions Android principales et des frontières Tauri `0.1.4` / adoption Games `0.1.5` ;
+- `610-ANDROID.md` encore en révision interne `3` pendant cette tranche de cadrage ;
+- les owners `520-JAVA.md`, `522-GRADLE.md` et `600-PLATFORMS.md` aux révisions attendues ;
+- le plan `009` contenant la trajectoire `alpha.2`, `alpha.3`, `beta.1`, `rc.1`, `rel.1` et les valeurs Games conservées comme preuves locales ;
+- l'absence de `docs/validation/006-ANDROID_VALIDATION.md` et d'un history `alpha.1` anticipé pendant la gate.
+
+## Hygiène Git et scope observé
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+Le scope indexé observé est exactement :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.3/alpha.1.md
+M  docs/000-README.md
+A  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+```
+
+Aucun fichier Android normatif n'a été modifié prématurément dans `alpha.1`.
+
+## Décision
+
+`0.1.3-alpha.1` est validée `PASS`.
+
+La tranche suivante reste `0.1.3-alpha.2`, bornée à la structure Android, la composition Gradle/Java, la matrice AGP/Gradle/JDK, les contrats `compileSdk` / `targetSdk` / `minSdk`, le versioning Android, `namespace` / `applicationId`, manifests/resources, configuration locale et signing.
+
+Les responsabilités NDK/ABI/native packaging, APK/AAB, Android Lint, tests/instrumentation, install/smokes et contraintes de distribution modernes restent réservées à `alpha.3`. Le détail 16 KB reste donc différé jusqu'à la vérification officielle prévue pour cette tranche.

history/0.1.3/alpha.2.md

@@ -0,0 +1,99 @@
+<!-- file: history/0.1.3/alpha.2.md -->
+<!-- version: 1 -->
+
+# History 0.1.3-alpha.2 — contrats Android de base
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.3-alpha.2` exécutée le `2026-09-28` est propre. La révision des contrats Android de base est validée sans fix ; `alpha.3` peut traiter le natif, le packaging, la distribution et la validation Android.
+
+## Intégration de `alpha.1`
+
+Avant la gate `alpha.2`, l'opérateur a intégré le history `PASS` de `alpha.1`, puis commit/push la tranche :
+
+```text
+commit local observé    eaa9c39 0.1.3-alpha.1
+push origin/master      585b508..eaa9c39
+```
+
+Le history `history/0.1.3/alpha.1.md` est donc présent dans `HEAD` avant validation de `alpha.2`.
+
+## Contrôles d'identité
+
+Les contrôles opérateur ont confirmé :
+
+```text
+VERSION                                            0.1.3-alpha.2
+history/0.1.3/alpha.1.md                           présent dans HEAD et PASS
+deltas/0.1.3/alpha.2.md                            présent
+history/0.1.3/alpha.2.md                           absent pendant la gate
+docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md version 2
+docs/rules/610-ANDROID.md                          version 4
+```
+
+## Tests Python
+
+La suite complète a affiché :
+
+```text
+Ran 48 tests in 0.717s
+
+OK
+```
+
+Soit `48/48` tests `PASS`.
+
+## Audits Markdown
+
+Les trois audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (254 file(s))
+Markdown table audit: clean (11 table(s), 254 file(s))
+Markdown link audit: clean (323 local link(s), 254 file(s))
+```
+
+## Audit Android de base `alpha.2`
+
+Le contrôle structurel de la tranche a affiché :
+
+```text
+0.1.3 alpha.2 Android base-contract audit: clean (language/build ownership, SDK contracts, app identity, local config and signing clarified)
+```
+
+Il a notamment confirmé :
+
+- Android reste neutre quant au langage applicatif et n'active le profil Java que lorsque Java est réellement présent ;
+- le JDK qui exécute Gradle/AGP reste distinct du niveau Java du code ;
+- `compileSdk`, `targetSdk` et `minSdk` sont des contrats séparés, avec `minSdk` justifié par le contrat produit ;
+- `namespace` et `applicationId` sont explicitement distingués ;
+- `local.properties` reste un état local Android/AGP et ne devient pas une source de configuration partagée ;
+- les secrets et artefacts privés de signing restent hors Git ;
+- l'exemple de structure ne rend plus `gradlew*` obligatoire ;
+- aucun contrat `docs/validation/006-ANDROID_VALIDATION.md` ni history `alpha.2` n'a été anticipé pendant la gate ;
+- les owners Java, Gradle et plateformes restent présents et non absorbés par Android.
+
+## Hygiène Git et scope observé
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+Le scope indexé observé est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.3/alpha.2.md
+M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+M  docs/rules/610-ANDROID.md
+```
+
+Aucun contenu NDK/ABI/16 KB, Tauri ou adoption Games n'a été absorbé prématurément dans `alpha.2`.
+
+## Décision
+
+`0.1.3-alpha.2` est validée `PASS`.
+
+La tranche suivante reste `0.1.3-alpha.3`, bornée aux responsabilités conditionnelles NDK/ABI/native packaging, APK/AAB, Android Lint, niveaux de tests, install/smokes device/AVD et contraintes de distribution modernes réellement applicables.
+
+Toute règle 16 KB doit être fondée sur une vérification Android officielle courante et rester conditionnelle à la présence de code natif, au type d'artefact et au canal de distribution concerné. Aucun owner JNI/Rust/SDL, skeleton Android ou audit spécialisé ne doit être créé par proximité.

history/0.1.3/alpha.3.md

@@ -0,0 +1,98 @@
+<!-- file: history/0.1.3/alpha.3.md -->
+<!-- version: 1 -->
+
+# History 0.1.3-alpha.3 — natif, packaging, distribution et validation Android
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.3-alpha.3` exécutée le `2026-09-28` est propre. Les responsabilités Android conditionnelles liées au code natif, aux ABI, à Lint, aux niveaux de tests, au packaging APK/AAB, aux smokes device/AVD et à la compatibilité 16 KB sont validées sans fix.
+
+## Intégration de `alpha.2`
+
+Avant la gate `alpha.3`, l'opérateur a intégré le history `PASS` de `alpha.2`, puis commit/push la tranche :
+
+```text
+commit local observé    1223a70 0.1.3-alpha.2
+push origin/master      eaa9c39..1223a70
+```
+
+Le history `history/0.1.3/alpha.2.md` est donc présent dans `HEAD` avant validation de `alpha.3`.
+
+## Contrôles d'identité
+
+Les contrôles opérateur ont confirmé :
+
+```text
+VERSION                                            0.1.3-alpha.3
+history/0.1.3/alpha.2.md                           présent dans HEAD et PASS
+deltas/0.1.3/alpha.3.md                            présent
+history/0.1.3/alpha.3.md                           absent pendant la gate
+docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md version 3
+docs/rules/610-ANDROID.md                          version 5
+```
+
+## Tests Python
+
+La suite complète a affiché :
+
+```text
+Ran 48 tests in 0.760s
+
+OK
+```
+
+Soit `48/48` tests `PASS`.
+
+## Audits Markdown
+
+Les trois audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (256 file(s))
+Markdown table audit: clean (11 table(s), 256 file(s))
+Markdown link audit: clean (323 local link(s), 256 file(s))
+```
+
+## Audit Android natif/distribution `alpha.3`
+
+Le contrôle structurel de la tranche a affiché :
+
+```text
+0.1.3 alpha.3 Android native/distribution audit: clean (conditional native ownership, lint/tests/package boundaries and 16 KB policy verified)
+```
+
+Il a notamment confirmé :
+
+- NDK et ABI restent conditionnels à la présence de bibliothèques natives directes ou transitives ;
+- PGR ne fixe ni version NDK ni liste universelle d'ABI ;
+- compilation native, présence dans le package et preuve runtime restent trois niveaux de preuve distincts ;
+- Android Lint est une gate explicite et ne doit pas être supposé exécuté par un build Gradle ordinaire ;
+- tests JVM, tests instrumentés et smokes device/AVD restent distincts et proportionnés ;
+- un AAB est un artefact de distribution et ne constitue pas à lui seul une preuve d'installation ou d'exécution ;
+- la compatibilité 16 KB est conditionnelle au code natif, au package et au canal de distribution réellement concernés ;
+- aucune version AGP/NDK, valeur `targetSdk`, liste d'ABI ou commande Games n'est devenue un minimum PGR universel ;
+- aucun owner JNI/Rust/SDL, skeleton Android, audit Python ou contrat `docs/validation/` séparé n'a été créé ;
+- Tauri `0.1.4` et l'adoption Games `0.1.5` restent hors scope.
+
+## Hygiène Git et scope observé
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+Le scope indexé observé est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.3/alpha.3.md
+M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+M  docs/rules/610-ANDROID.md
+```
+
+## Décision
+
+`0.1.3-alpha.3` est validée `PASS`.
+
+La tranche suivante reste `0.1.3-beta.1`, dédiée à la réconciliation du profil Android révisé contre Games et les owners `400`, `520`, `522` et `600`, ainsi qu'à la décision finale sur les artefacts Android supplémentaires.
+
+Si `610-ANDROID.md` et les owners existants suffisent, la beta doit consigner explicitement qu'aucun artefact supplémentaire n'est nécessaire. Si une lacune fonctionnelle impose au contraire un nouvel owner, contrat, template, skeleton ou audit, elle doit déclencher un REPLAN vers une tranche alpha dédiée plutôt que l'introduire opportunément en beta.

history/0.1.3/beta.1.md

@@ -0,0 +1,102 @@
+<!-- file: history/0.1.3/beta.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.3-beta.1 — réconciliation Android et décision finale d'artefacts
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.3-beta.1` exécutée le `2026-09-28` est propre. La réconciliation confirme que le profil Android révisé reste générique, que les choix Games restent locaux et qu'aucun artefact Android supplémentaire n'est justifié avant la release candidate.
+
+## Intégration de `alpha.3`
+
+Avant la gate `beta.1`, l'opérateur a intégré le history `PASS` de `alpha.3`, puis commit/push la tranche :
+
+```text
+commit local observé    8cbd686 0.1.3-alpha.3
+push origin/master      1223a70..8cbd686
+```
+
+Le history `history/0.1.3/alpha.3.md` est donc présent dans `HEAD` avant validation de `beta.1`.
+
+## Contrôles d'identité
+
+Les contrôles opérateur ont confirmé :
+
+```text
+VERSION                                            0.1.3-beta.1
+history/0.1.3/alpha.3.md                           présent dans HEAD et PASS
+deltas/0.1.3/beta.1.md                             présent
+history/0.1.3/beta.1.md                            absent pendant la gate
+README.md                                          version 24
+docs/000-README.md                                 version 38
+docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md version 4
+docs/rules/610-ANDROID.md                          version 5
+docs/rules/400-VALIDATION.md                       version 1
+docs/rules/520-JAVA.md                             version 4
+docs/rules/522-GRADLE.md                           version 1
+docs/rules/600-PLATFORMS.md                        version 1
+```
+
+## Tests Python
+
+La suite complète a affiché :
+
+```text
+Ran 48 tests in 0.696s
+
+OK
+```
+
+Soit `48/48` tests `PASS`.
+
+## Audits Markdown
+
+Les trois audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (258 file(s))
+Markdown table audit: clean (11 table(s), 258 file(s))
+Markdown link audit: clean (327 local link(s), 258 file(s))
+```
+
+## Réconciliation Android `beta.1`
+
+Le contrôle structurel a affiché :
+
+```text
+0.1.3 beta.1 reconciliation audit: clean (Android profile generic, Games-local choices preserved, existing owners sufficient, no extra artifacts justified)
+```
+
+Il a notamment confirmé :
+
+- `400-VALIDATION.md`, `520-JAVA.md`, `522-GRADLE.md`, `600-PLATFORMS.md` et `610-ANDROID.md` restent des owners séparés et composables ;
+- Android ne sélectionne pas Java à lui seul et ne recopie pas les responsabilités Gradle générales ;
+- les versions AGP/Gradle/JDK/Java, niveaux SDK, NDK, quatre ABI et la chaîne Rust/JNI/SDL observés dans Games restent des choix locaux ;
+- aucune valeur Games n'est devenue un `MUST` Android général ;
+- les contraintes natives, de packaging et 16 KB restent conditionnelles ;
+- aucun `docs/validation/006-ANDROID_VALIDATION.md`, skeleton Android, template Android, audit Python Android ou owner JNI/Rust/SDL n'est créé ;
+- les frontières `0.1.4` Tauri et `0.1.5` adoption Games restent intactes.
+
+## Hygiène Git et scope observé
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+Le scope indexé observé est exactement :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.3/beta.1.md
+M  docs/000-README.md
+M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+```
+
+## Décision
+
+`0.1.3-beta.1` est validée `PASS`.
+
+Aucun fix ni REPLAN n'est requis. La tranche suivante est `0.1.3-rc.1` : elle doit geler le scope Android déjà validé, produire le changelog candidat, préparer `prompts/010-V0_1_4_START_PROMPT.md` et rejouer les gates de release sans introduire de nouvelle règle fonctionnelle Android.
+
+Le prompt `010` doit préparer uniquement le réexamen Tauri `0.1.4` après publication vérifiée de `v0.1.3`. Il ne doit ni lever le `DEFER` Tauri par anticipation, ni commencer l'adoption Games `0.1.5`.

history/0.1.3/rc.1.md

@@ -0,0 +1,127 @@
+<!-- file: history/0.1.3/rc.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.3-rc.1 — release candidate Android
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.3-rc.1` exécutée le `2026-09-28` a réussi. Elle confirme le gel du profil Android révisé, l'intégrité des histories antérieurs, le changelog candidat, le prompt de reprise `010`, les tests Python, les audits Markdown et l'hygiène texte/templates avant promotion stable.
+
+## Baseline opérateur
+
+La tranche `0.1.3-beta.1` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `rc.1` :
+
+```text
+commit       3f3de72
+message      0.1.3-beta.1
+push         origin/master PASS
+```
+
+Après application du delta `rc.1`, les contrôles initiaux ont confirmé :
+
+```text
+VERSION                                                   0.1.3-rc.1
+history/0.1.3/beta.1.md                                   présent dans HEAD et le workspace
+deltas/0.1.3/rc.1.md                                      présent
+prompts/010-V0_1_4_START_PROMPT.md                        présent
+history/0.1.3/rc.1.md                                     absent pendant la gate
+CHANGELOG.md                                               version 16
+docs/000-README.md                                        version 39
+docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md       version 5
+ROADMAP.md                                                 version 14
+prompts/010-V0_1_4_START_PROMPT.md                        version 1
+docs/rules/610-ANDROID.md                                 version 5
+docs/rules/710-TAURI.md                                   version 6
+docs/studies/002-TAURI_SKELETON_DECISION.md              version 2
+docs/skeletons/003-WEB_FRONTEND.md                        version 1
+docs/validation/005-WEB_FRONTEND_VALIDATION.md            version 1
+```
+
+Le history `beta.1` a été retrouvé avec statut `PASS`.
+
+## Gate d'intégration RC
+
+Le contrôle structurel a affiché :
+
+```text
+0.1.3 rc.1 integration audit: clean (4 prior histories, frozen Android profile, candidate changelog and prompt 010 verified)
+```
+
+Il a vérifié les quatre histories antérieurs avec statut `PASS` :
+
+```text
+alpha.1   PASS
+alpha.2   PASS
+alpha.3   PASS
+beta.1    PASS
+```
+
+Avant application du présent history, `rc.1.md` est la seule tranche `0.1.3` possédant un delta sans history.
+
+La gate a également confirmé :
+
+- le `CHANGELOG` candidat `0.1.3` sans détails de tranches ;
+- le profil Android `610-ANDROID.md` gelé en révision `5` sans généralisation de `targetSdk 36`, `minSdk 21`, NDK r28, quatre ABI, Gradle 9.7.1, AGP 9.4.0 ou JDK 25 ;
+- la composition Android avec les owners génériques sans créer d'owner JNI/Rust/SDL, skeleton Android ou contrat de validation redondant ;
+- la distinction entre SDK, identité applicative, natif/ABI, Lint, niveaux de tests, APK/AAB et contraintes 16 KB conditionnelles ;
+- la roadmap `0.1.3` à `0.1.7` sans réservation de `0.1.8` ;
+- le maintien du `DEFER` Tauri jusqu'au réexamen `0.1.4` ;
+- le prompt `010` ciblant `0.1.4-alpha.1` uniquement depuis une future archive du tag `v0.1.3` et son rapport post-tag réel ;
+- l'absence de création anticipée du skeleton Tauri et le maintien des adoptions Games `0.1.5` et KSP `0.1.6` hors scope.
+
+## Tests et audits PGR
+
+La suite Python globale a exécuté `48` tests, tous réussis :
+
+```text
+Ran 48 tests in 0.745s
+
+OK
+```
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (261 file(s))
+Markdown table audit: clean (11 table(s), 261 file(s))
+Markdown link audit: clean (337 local link(s), 261 file(s))
+```
+
+L'hygiène texte/templates a également réussi :
+
+```text
+0.1.3 rc.1 text/template hygiene: clean
+```
+
+Les templates TOML Rust/Cargo et JSON Web ont été parsés ; aucun retour chariot, whitespace final ni fichier texte sans newline finale n'a été détecté dans le corpus contrôlé.
+
+## Contrôles Git
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+Le statut indexé transmis avant ajout du présent history est exactement :
+
+```text
+M  CHANGELOG.md
+M  VERSION
+A  deltas/0.1.3/rc.1.md
+M  docs/000-README.md
+M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+A  prompts/010-V0_1_4_START_PROMPT.md
+```
+
+Le scope correspond exactement à la RC annoncée. Aucun owner Android, Java, Gradle ou Tauri, template, skeleton, validation, étude technique ou script d'audit n'a été modifié pendant la RC.
+
+## Décision
+
+`0.1.3-rc.1` est `PASS`. Aucun fix ni REPLAN n'est requis.
+
+La transition autorisée est la promotion mécanique pré-tag :
+
+```text
+0.1.3-rel.1
+```
+
+Cette promotion ne doit pas rouvrir le scope fonctionnel. Elle doit uniquement présenter `0.1.3` comme stable, produire sa propre gate pré-tag et préparer le handoff de publication sans anticiper le rapport post-tag.

history/0.1.3/rel.1.md

@@ -0,0 +1,149 @@
+<!-- file: history/0.1.3/rel.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.3-rel.1 — promotion stable pré-tag
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.3-rel.1` exécutée le `2026-09-28` a réussi. Elle confirme la promotion mécanique de la release candidate vers la stable `0.1.3`, la cohérence des histories antérieurs, la présentation stable du profil Android, les tests PGR, les audits documentaires et l'hygiène texte/templates avant création du tag.
+
+## Baseline opérateur
+
+La tranche `0.1.3-rc.1` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `rel.1` :
+
+```text
+commit       a9fba6c
+message      0.1.3-rc.1
+push         origin/master PASS
+```
+
+Après application du delta `rel.1`, les contrôles initiaux ont confirmé :
+
+```text
+VERSION                                                   0.1.3
+history/0.1.3/rc.1.md                                     présent dans HEAD et le workspace
+deltas/0.1.3/rel.1.md                                     présent
+prompts/010-V0_1_4_START_PROMPT.md                        présent
+history/0.1.3/rel.1.md                                    absent pendant la gate
+README.md                                                  version 25
+ROADMAP.md                                                 version 15
+CHANGELOG.md                                               version 17
+docs/000-README.md                                        version 40
+docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md        version 6
+```
+
+Le history `rc.1` a été retrouvé avec statut `PASS`.
+
+La présentation stable est établie :
+
+```text
+ROADMAP.md     0.1.3 marqué terminé
+CHANGELOG.md   entrée `## 0.1.3` sans suffixe `(candidate)`
+README.md      profil Android réévalué contre Games présenté comme stable
+docs index     plan 009 classé historique
+```
+
+## Gate stable pré-tag
+
+Le contrôle structurel a affiché :
+
+```text
+0.1.3 rel.1 stable gate audit: clean (5 prior histories, rel.1 pending, stable Android presentation and post-tag Tauri handoff coherent)
+```
+
+Il a vérifié les cinq histories antérieurs avec statut `PASS` :
+
+```text
+alpha.1   PASS
+alpha.2   PASS
+alpha.3   PASS
+beta.1    PASS
+rc.1      PASS
+```
+
+Avant application du présent history, `rel.1.md` est la seule tranche `0.1.3` possédant un delta sans history.
+
+La gate a également confirmé :
+
+- `0.1.3` terminé dans la roadmap ;
+- `0.1.4` à `0.1.7` engagés sans réservation de `0.1.8` ;
+- le `CHANGELOG` stable sans suffixe `(candidate)` et sans détails de tranches ;
+- le plan `009` classé historique ;
+- le profil Android `610-ANDROID.md` gelé en révision `5` ;
+- l'absence de généralisation de `targetSdk 36`, `minSdk 21`, NDK r28, quatre ABI, Gradle 9.7.1, AGP 9.4.0 ou JDK 25 ;
+- la composition Android avec les owners génériques existants sans création d'owner JNI/Rust/SDL, de skeleton Android ni de contrat de validation redondant ;
+- les contrats Android stabilisés pour SDK, identité applicative, natif/ABI, Android Lint, niveaux de tests, APK/AAB et contraintes 16 KB conditionnelles ;
+- `0.1.4` réservé au réexamen Tauri, sans création anticipée du skeleton ;
+- `0.1.5` et `0.1.6` réservés respectivement aux adoptions Games et KSP ;
+- le prompt `010` préparé pour démarrer `0.1.4` uniquement depuis le tag réel `v0.1.3` et un rapport post-tag `publish.001` `PASS` ;
+- la convention de clôture `rel.N`, puis commit stable `X.Y.Z` avant création du tag.
+
+## Validation Android
+
+Les décisions Android issues du corpus Games ont été réconciliées avant la RC et `rel.1` n'a modifié aucun owner technique.
+
+La promotion stable n'a donc pas simulé de toolchain Android, Gradle, AGP, JDK ou NDK absente du dépôt PGR. Elle a rejoué les gates réellement possédées par PGR afin de vérifier que la promotion documentaire et les métadonnées de release n'ont invalidé aucune propriété du référentiel.
+
+Les choix Games qui restent locaux n'ont pas été promus en minima PGR universels et aucun artefact Android supplémentaire n'a été créé pendant la clôture.
+
+## Tests et audits PGR
+
+La suite Python globale a exécuté `48` tests, tous réussis :
+
+```text
+Ran 48 tests in 0.735s
+
+OK
+```
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (263 file(s))
+Markdown table audit: clean (11 table(s), 263 file(s))
+Markdown link audit: clean (337 local link(s), 263 file(s))
+```
+
+L'hygiène texte/templates a également affiché :
+
+```text
+0.1.3 rel.1 text/template hygiene: clean
+```
+
+Les templates TOML Rust/Cargo et JSON Web ont été parsés avec succès ; aucun retour chariot, whitespace final ni fichier texte sans newline finale n'a été détecté dans le corpus contrôlé.
+
+## Contrôles Git
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+Le statut indexé transmis avant ajout du présent history est exactement :
+
+```text
+M  CHANGELOG.md
+M  README.md
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.3/rel.1.md
+M  docs/000-README.md
+M  docs/plans/009-V0_1_3_ANDROID_REEVALUATION_PLAN.md
+```
+
+Le scope correspond exactement à la promotion stable annoncée. Aucun owner Android/Java/Gradle/Tauri, template, skeleton, validation, étude technique ou script d'audit n'a été modifié pendant `rel.1`.
+
+## Décision
+
+`0.1.3-rel.1` est `PASS`. Aucun fix ni REPLAN n'est requis.
+
+Conformément à la convention stable PGR, le présent history doit être inclus dans le commit final nommé exactement :
+
+```text
+0.1.3
+```
+
+Le commit stable doit être poussé sur `origin/master` avant création du tag annoté `v0.1.3`.
+
+Le rapport `pgr-0.1.3-publish.001-report.md` ne pourra être produit qu'après réception des preuves post-publication réelles : identité du commit stable, propreté du workspace, objet et cible déréférencée du tag local, références distantes du tag et archive ZIP téléchargée depuis le tag Gitea.
+
+Le prompt `010-V0_1_4_START_PROMPT.md` ne devient la reprise effective de `0.1.4` qu'après un rapport post-tag `PASS`.

history/0.1.4/alpha.1.md

@@ -0,0 +1,86 @@
+<!-- file: history/0.1.4/alpha.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.4-alpha.1 — intake, audit et cadrage Tauri
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.4-alpha.1` exécutée le `2026-09-29` est propre. L'intake de la stable `v0.1.3`, des corpus Games/KSP fournis et du candidat de skeleton Tauri est validé sans fix ; `alpha.2` peut réconcilier le profil Tauri et l'étude historique avant toute matérialisation de `004-TAURI.md`.
+
+## Contrôles d'identité
+
+Les contrôles opérateur ont confirmé :
+
+```text
+VERSION                                             0.1.4-alpha.1
+docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md présent
+deltas/0.1.4/alpha.1.md                            présent
+history/0.1.4/alpha.1.md                           absent pendant la gate
+docs/skeletons/004-TAURI.md                        absent pendant la gate
+```
+
+## Tests Python
+
+La suite complète a affiché :
+
+```text
+Ran 48 tests in 0.744s
+
+OK
+```
+
+Soit `48/48` tests `PASS`.
+
+## Audits Markdown
+
+Les trois audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (266 file(s))
+Markdown table audit: clean (11 table(s), 266 file(s))
+Markdown link audit: clean (343 local link(s), 266 file(s))
+```
+
+## Audit structurel `alpha.1`
+
+Le contrôle structurel de la tranche a affiché :
+
+```text
+0.1.4 alpha.1 structural audit: clean (96 prior pairs, 7 current Tauri hosts classified, no premature skeleton/adoption)
+```
+
+Il a notamment confirmé :
+
+- les `96` couples delta/history antérieurs attendus, avec les six histories `0.1.3` tous `PASS` et `rel.1` validé ;
+- `0.1.3` terminé, `0.1.4` à `0.1.7` toujours engagés et aucune réservation `0.1.8` ;
+- le prompt `010` conforme au scope `0.1.4`, à la classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` et aux frontières d'adoption Games/KSP ;
+- le plan `010` fondé sur les `7` hosts Tauri réellement observés dans Games `0.3.6` et KSP `0.3.19` ;
+- les cinq conditions historiques de sortie du report classées `SATISFIED` ;
+- `710-TAURI.md` encore en révision interne `6` et l'étude `002-TAURI_SKELETON_DECISION.md` encore en révision `2` pendant la tranche d'intake ;
+- l'absence de `docs/skeletons/004-TAURI.md` et du history `alpha.1` anticipé pendant la gate.
+
+## Hygiène Git et scope observé
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+Le scope indexé observé est exactement :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.4/alpha.1.md
+M  docs/000-README.md
+A  docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+```
+
+Aucun fichier normatif Tauri ni skeleton Tauri n'a été modifié ou créé prématurément dans `alpha.1`.
+
+## Décision
+
+`0.1.4-alpha.1` est validée `PASS`.
+
+L'ancien motif Web du `DEFER` historique est levé et le candidat de skeleton organisationnel est conservé pour matérialisation, mais seulement après la réconciliation normative de `alpha.2`.
+
+La tranche suivante reste `0.1.4-alpha.2`, bornée à `docs/rules/710-TAURI.md`, `docs/studies/002-TAURI_SKELETON_DECISION.md`, au plan actif et à leur indexation. Elle doit clarifier la frontière commande / permission / capability, la politique de sélection des capabilities, la convention de layout contrôlé et la composition avec les owners Web existants, sans créer encore `docs/skeletons/004-TAURI.md`, template Tauri ou contrat de validation Tauri séparé.

history/0.1.4/alpha.2.fix.1.md

@@ -0,0 +1,94 @@
+<!-- file: history/0.1.4/alpha.2.fix.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.4-alpha.2.fix.1 — hygiène texte rétablie
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.4-alpha.2.fix.1` exécutée le `2026-09-29` est propre. Le défaut de ligne vide surnuméraire à EOF est corrigé, l'audit réutilisable d'hygiène texte est actif et les décisions Tauri validées en `alpha.2` restent inchangées.
+
+## Baseline opérateur
+
+La tranche `0.1.4-alpha.2` en échec a été committée puis publiée avant application du fix :
+
+```text
+commit alpha.2   ed794d6
+push             7f47558..ed794d6  master -> master
+```
+
+La version observée pendant la gate du fix est :
+
+```text
+0.1.4-alpha.2.fix.1
+```
+
+`history/0.1.4/alpha.2.md` est présent avec le statut `FAIL`, tandis que `history/0.1.4/alpha.2.fix.1.md` était absent pendant la gate.
+
+## Tests Python
+
+La suite complète a affiché :
+
+```text
+Ran 55 tests in 0.890s
+
+OK
+```
+
+Soit `55/55` tests `PASS`, dont les sept cas ciblés du nouvel audit `text_hygiene`.
+
+## Audit d'hygiène texte
+
+Le nouvel audit a affiché :
+
+```text
+Text hygiene audit: clean (297 file(s))
+```
+
+Il confirme sur le corpus sélectionné :
+
+- fins de ligne LF ;
+- absence de whitespace terminal ;
+- newline finale présente ;
+- absence de ligne vide terminale surnuméraire.
+
+## Audits Markdown
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (270 file(s))
+Markdown table audit: clean (11 table(s), 270 file(s))
+Markdown link audit: clean (344 local link(s), 270 file(s))
+```
+
+## Hygiène Git et scope observé
+
+`git diff --check` puis `git diff --cached --check` n'ont produit aucun diagnostic.
+
+Le scope indexé observé est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.4/alpha.2.fix.1.md
+M  docs/rules/210-WORKFLOW.md
+M  docs/studies/002-TAURI_SKELETON_DECISION.md
+M  docs/validation/001-VALIDATION_MATRIX.md
+A  scripts/audit_text_hygiene.py
+A  tests/test_text_hygiene.py
+```
+
+La révision interne de l'étude Tauri reste `3` : seule sa terminaison de fichier a été corrigée.
+
+## Observation de livraison post-gate
+
+Après la gate, l'opérateur a constaté que les ZIP remis pour `alpha.2.history` et `alpha.2.fix.1.delta` contenaient à tort un répertoire englobant `pgr/`. Le contenu appliqué au dépôt est correct et la gate présente reste `PASS`, mais ce défaut de packaging doit être corrigé dans les archives remises et explicitement interdit par le contrat de workflow avant les livraisons suivantes.
+
+Cette observation ne modifie pas les fichiers validés par le fix ; elle constitue un durcissement du mécanisme de livraison à intégrer dès `alpha.3`.
+
+## Décision
+
+`0.1.4-alpha.2.fix.1` est validée `PASS`.
+
+`alpha.3` peut matérialiser `docs/skeletons/004-TAURI.md` sur la baseline Tauri réconciliée. La tranche doit également clarifier que les entrées d'une archive delta/history sont relatives directement à la racine du dépôt, sans répertoire englobant `<project>/`, afin que l'application canonique `unzip -o <archive> -d .` reste correcte.

history/0.1.4/alpha.2.md

@@ -0,0 +1,105 @@
+<!-- file: history/0.1.4/alpha.2.md -->
+<!-- version: 1 -->
+
+# History 0.1.4-alpha.2 — réconciliation normative Tauri
+
+## Statut
+
+FAIL
+
+La gate opérateur de `0.1.4-alpha.2` exécutée le `2026-09-29` valide les tests, audits Markdown et contrôles structurels Tauri, mais échoue sur l'hygiène Git : `docs/studies/002-TAURI_SKELETON_DECISION.md` contient une ligne vide finale supplémentaire. La tranche ne peut donc pas être déclarée `PASS` et doit être corrigée par `0.1.4-alpha.2.fix.1`.
+
+## Baseline opérateur
+
+Le history `PASS` de `0.1.4-alpha.1` a été ajouté, committé et publié avant application de `alpha.2` :
+
+```text
+commit alpha.1   7f47558
+push             fe80dbb..7f47558  master -> master
+```
+
+La version observée pendant la gate est :
+
+```text
+0.1.4-alpha.2
+```
+
+`history/0.1.4/alpha.1.md` est présent et son statut est `PASS`. `history/0.1.4/alpha.2.md` était absent pendant la gate, conformément au workflow.
+
+## Tests Python
+
+La suite complète a affiché :
+
+```text
+Ran 48 tests in 0.705s
+
+OK
+```
+
+Soit `48/48` tests `PASS`.
+
+## Audits Markdown
+
+Les trois audits documentaires ont affiché :
+
+```text
+Markdown header audit: clean (268 file(s))
+Markdown table audit: clean (11 table(s), 268 file(s))
+Markdown link audit: clean (344 local link(s), 268 file(s))
+```
+
+## Gate normative Tauri
+
+Le contrôle spécifique de `alpha.2` a terminé proprement :
+
+```text
+0.1.4 alpha.2 Tauri normative audit: clean (ACL boundaries explicit, Web ownership separated, historical DEFER lifted, skeleton still deferred to alpha.3)
+```
+
+Il confirme notamment :
+
+- `710-TAURI.md` en révision `7` avec séparation explicite commande / permission / capability ;
+- séparation des responsabilités Tauri et Web ;
+- levée du motif historique du `DEFER` dans l'étude `002` ;
+- matérialisation du skeleton Tauri toujours réservée à `alpha.3` ;
+- absence de `docs/skeletons/004-TAURI.md` pendant cette tranche ;
+- trajectoire publiée `0.1.5` Games / `0.1.6` KSP / `0.1.7` audits toujours inchangée pendant `alpha.2`.
+
+## Échec d'hygiène Git
+
+`git diff --check` a signalé :
+
+```text
+docs/studies/002-TAURI_SKELETON_DECISION.md:299: new blank line at EOF.
+```
+
+Après indexation du scope de `alpha.2`, `git diff --cached --check` a signalé exactement la même erreur :
+
+```text
+docs/studies/002-TAURI_SKELETON_DECISION.md:299: new blank line at EOF.
+```
+
+Le défaut est donc reproductible avant et après staging. Il s'agit d'une ligne vide terminale surnuméraire introduite par le delta, pas d'un écart opérateur.
+
+Le statut indexé observé est :
+
+```text
+M  VERSION
+A  deltas/0.1.4/alpha.2.md
+M  docs/000-README.md
+M  docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+M  docs/rules/710-TAURI.md
+M  docs/studies/002-TAURI_SKELETON_DECISION.md
+```
+
+Le scope fonctionnel annoncé est donc respecté, mais la preuve d'hygiène obligatoire échoue.
+
+## Décision
+
+`0.1.4-alpha.2` est `FAIL`.
+
+Le contenu normatif Tauri validé par les contrôles spécifiques n'est pas remis en cause. `0.1.4-alpha.2.fix.1` doit :
+
+1. supprimer la ligne vide surnuméraire à EOF de l'étude `002` ;
+2. ajouter un contrôle automatique monotâche empêchant cette classe de défaut sur les futurs fichiers texte gouvernés ;
+3. conserver les décisions Tauri de `alpha.2` sans commencer `alpha.3`.

history/0.1.4/alpha.3.md

@@ -0,0 +1,97 @@
+<!-- file: history/0.1.4/alpha.3.md -->
+<!-- version: 1 -->
+
+# History 0.1.4-alpha.3 — skeleton Tauri matérialisé
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.4-alpha.3` exécutée le `2026-09-29` est propre. Le skeleton Tauri contrôlé `docs/skeletons/004-TAURI.md` est matérialisé, le contrat de packaging delta/history est explicite et aucun template technique ou contrat de validation Tauri séparé n'a été créé prématurément.
+
+## Baseline opérateur
+
+La tranche corrective précédente a été committée puis publiée avant application de `alpha.3` :
+
+```text
+commit alpha.2.fix.1   9b140e8
+push                   ed794d6..9b140e8  master -> master
+```
+
+La version observée pendant la gate est :
+
+```text
+0.1.4-alpha.3
+```
+
+Les contrôles préalables confirment `history/0.1.4/alpha.2.fix.1.md` présent avec statut `PASS`, `deltas/0.1.4/alpha.3.md` présent, `docs/skeletons/004-TAURI.md` présent et `history/0.1.4/alpha.3.md` absent pendant la gate.
+
+## Tests Python
+
+La suite complète a affiché :
+
+```text
+Ran 55 tests in 0.942s
+
+OK
+```
+
+Soit `55/55` tests `PASS`.
+
+## Audit d'hygiène texte
+
+L'audit réutilisable a affiché :
+
+```text
+Text hygiene audit: clean (300 file(s))
+```
+
+La gate confirme donc LF, absence de whitespace terminal, newline finale unique et absence de ligne vide terminale surnuméraire sur le corpus sélectionné.
+
+## Audits Markdown
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (273 file(s))
+Markdown table audit: clean (11 table(s), 273 file(s))
+Markdown link audit: clean (352 local link(s), 273 file(s))
+```
+
+## Audit structurel `alpha.3`
+
+Le contrôle structurel a affiché :
+
+```text
+0.1.4 alpha.3 skeleton audit: clean (004 materialized, owners composed, no premature template/validation artifact, ZIP root contract explicit)
+```
+
+Il confirme notamment :
+
+- `docs/skeletons/004-TAURI.md` en révision interne `1` avec décisions obligatoires, baseline recommandée, ACL/capabilities, ordre d'initialisation, validation initiale et politique d'artefacts ;
+- les révisions internes attendues de `210-WORKFLOW.md`, des index, du plan, de l'owner `710` et de l'étude Tauri ;
+- le contrat de workflow interdisant un répertoire englobant dans les ZIP delta/history et imposant la vérification des entrées avant remise ;
+- l'absence de `docs/templates/011-TAURI.md` et `docs/validation/006-TAURI_VALIDATION.md` ;
+- l'absence du history `alpha.3` anticipé pendant la gate.
+
+## Hygiène Git et scope observé
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+Le scope indexé observé est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.4/alpha.3.md
+M  docs/000-README.md
+M  docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+M  docs/rules/210-WORKFLOW.md
+M  docs/skeletons/000-README.md
+A  docs/skeletons/004-TAURI.md
+```
+
+## Décision
+
+`0.1.4-alpha.3` est validée `PASS`.
+
+`beta.1` peut maintenant réconcilier l'ensemble des artefacts Tauri `0.1.4`, rechercher les duplications ou ownerships cachés et décider explicitement si un template technique Tauri, un contrat de validation séparé ou un dry-run exécutable apportent une valeur nette. En l'absence de lacune démontrée, aucun artefact supplémentaire ne doit être créé.

history/0.1.4/beta.1.md

@@ -0,0 +1,96 @@
+<!-- file: history/0.1.4/beta.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.4-beta.1 — réconciliation des artefacts Tauri
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.4-beta.1` exécutée le `2026-09-29` est propre. Elle confirme que le skeleton Tauri `004` et les owners existants suffisent, qu'aucun template technique Tauri ni contrat de validation séparé n'est justifié et qu'aucun dry-run factice n'est nécessaire pour une specification volontairement non génératrice.
+
+## Baseline opérateur
+
+La tranche précédente a été clôturée, committée puis publiée avant application de `beta.1` :
+
+```text
+commit alpha.3   e4f405e
+push             9b140e8..e4f405e  master -> master
+```
+
+La version observée pendant la gate est :
+
+```text
+0.1.4-beta.1
+```
+
+Les contrôles préalables ont confirmé `history/0.1.4/alpha.3.md` présent avec statut `PASS`, `docs/skeletons/004-TAURI.md` présent, l'absence de `docs/templates/011-TAURI.md`, l'absence de `docs/validation/006-TAURI_VALIDATION.md` et l'absence du présent history pendant la gate.
+
+## Tests Python
+
+La suite complète a affiché :
+
+```text
+Ran 55 tests in 0.935s
+
+OK
+```
+
+Soit `55/55` tests `PASS`.
+
+## Audit d'hygiène texte
+
+L'audit réutilisable a affiché :
+
+```text
+Text hygiene audit: clean (302 file(s))
+```
+
+La gate confirme donc LF, absence de whitespace terminal, newline finale unique et absence de ligne vide terminale surnuméraire sur le corpus sélectionné.
+
+## Audits Markdown
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (275 file(s))
+Markdown table audit: clean (11 table(s), 275 file(s))
+Markdown link audit: clean (352 local link(s), 275 file(s))
+```
+
+## Audit structurel `beta.1`
+
+Le contrôle structurel a affiché :
+
+```text
+0.1.4 beta.1 artifact audit: clean (004 sufficient, ownership composed, no redundant template/validation contract, no fake dry-run)
+```
+
+Il confirme notamment :
+
+- les quatre deltas antérieurs `alpha.1`, `alpha.2`, `alpha.2.fix.1` et `alpha.3` possèdent leurs histories ;
+- `beta.1.md` est le seul delta `0.1.4` encore sans history pendant la gate ;
+- `docs/skeletons/004-TAURI.md` compose les owners existants sans ownership caché ;
+- `docs/templates/011-TAURI.md` et `docs/validation/006-TAURI_VALIDATION.md` restent absents ;
+- la décision d'artefacts est explicitement `KEEP / DO NOT CREATE / NOT REQUIRED` selon le besoin réel ;
+- la roadmap reste encore inchangée pendant `beta.1`, la revue d'horizon transversale étant réservée à `rc.1`.
+
+## Hygiène Git et scope observé
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+Le scope indexé observé est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.4/beta.1.md
+M  docs/000-README.md
+M  docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+M  docs/studies/002-TAURI_SKELETON_DECISION.md
+```
+
+## Décision
+
+`0.1.4-beta.1` est validée `PASS`.
+
+`rc.1` peut maintenant geler le domaine Tauri, préparer le changelog candidat et exécuter la revue d'horizon explicitement requise par le plan. Cette revue doit décider avant génération du prochain start prompt si la clarification de `SHOULD`, l'autonomie des projets après adoption PGR et la frontière future PGR / SaseDev Knowledge imposent une release de gouvernance avant les adoptions Games/KSP.

history/0.1.4/rc.1.md

@@ -0,0 +1,113 @@
+<!-- file: history/0.1.4/rc.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.4-rc.1 — freeze Tauri et revue d’horizon
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.4-rc.1` exécutée le `2026-09-29` est propre. Elle confirme le freeze du domaine Tauri, la cohérence du changelog candidat, la revue d’horizon qui place la sémantique normative et l’autonomie en `0.1.5`, ainsi que le handoff `011` vers cette prochaine release sans commencer son implémentation.
+
+## Baseline opérateur
+
+La tranche précédente a été clôturée, committée puis publiée avant application de `rc.1` :
+
+```text
+commit beta.1   091685a
+push            e4f405e..091685a  master -> master
+```
+
+La version observée pendant la gate est :
+
+```text
+0.1.4-rc.1
+```
+
+Les contrôles préalables ont confirmé `history/0.1.4/beta.1.md` présent avec statut `PASS`, l’étude `004-V0_1_4_HORIZON_REVIEW.md` présente, le prompt `011-V0_1_5_START_PROMPT.md` présent et l’absence du présent history pendant la gate.
+
+## Révisions documentaires contrôlées
+
+Les révisions attendues ont été confirmées :
+
+```text
+CHANGELOG.md                                          version 18
+ROADMAP.md                                            version 16
+docs/000-README.md                                   version 45
+docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md    version 5
+docs/studies/000-README.md                           version 5
+docs/studies/004-V0_1_4_HORIZON_REVIEW.md            version 1
+prompts/011-V0_1_5_START_PROMPT.md                   version 1
+```
+
+## Tests Python
+
+La suite complète a affiché à deux reprises une exécution propre ; la gate finale a notamment affiché :
+
+```text
+Ran 55 tests in 0.913s
+
+OK
+```
+
+Soit `55/55` tests `PASS`.
+
+## Audit d’hygiène texte
+
+L’audit réutilisable a affiché :
+
+```text
+Text hygiene audit: clean (306 file(s))
+```
+
+## Audits Markdown
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (279 file(s))
+Markdown table audit: clean (11 table(s), 279 file(s))
+Markdown link audit: clean (356 local link(s), 279 file(s))
+```
+
+## Audit d’intégration `rc.1`
+
+Le contrôle structurel a affiché :
+
+```text
+0.1.4 rc.1 integration audit: clean (beta PASS, Tauri frozen, horizon reordered to governance 0.1.5 before Games/KSP, prompt 011 verified)
+```
+
+Il confirme notamment :
+
+- `alpha.1`, `alpha.2`, `alpha.2.fix.1`, `alpha.3` et `beta.1` possèdent leurs histories avec les statuts attendus ;
+- `rc.1.md` est le seul delta `0.1.4` encore sans history pendant la gate ;
+- `710-TAURI.md`, `004-TAURI.md` et l’étude `002` restent gelés ;
+- le changelog candidat ne contient aucune chronologie de tranches ;
+- la roadmap engage désormais `0.1.5` gouvernance/autonomie, `0.1.6` Games, `0.1.7` KSP et `0.1.8` audits Rust ;
+- le prompt `011` reprend explicitement les trois questions transversales sans démarrer `0.1.5` ;
+- aucun template Tauri générique ni contrat `006-TAURI_VALIDATION.md` n’est introduit.
+
+## Hygiène Git et scope observé
+
+`git diff --check` et `git diff --cached --check` n’ont produit aucun diagnostic.
+
+Le scope indexé observé est exactement :
+
+```text
+M  CHANGELOG.md
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.4/rc.1.md
+M  docs/000-README.md
+M  docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+M  docs/studies/000-README.md
+A  docs/studies/004-V0_1_4_HORIZON_REVIEW.md
+A  prompts/011-V0_1_5_START_PROMPT.md
+```
+
+## Décision
+
+`0.1.4-rc.1` est validée `PASS`.
+
+`rel.1` peut promouvoir mécaniquement cette RC vers la stable `0.1.4`. Cette promotion ne doit ni rouvrir le scope Tauri ni appliquer les changements normatifs réservés à `0.1.5`.

history/0.1.4/rel.1.md

@@ -0,0 +1,140 @@
+<!-- file: history/0.1.4/rel.1.md -->
+<!-- version: 1 -->
+
+# PGR 0.1.4 — history `rel.1`
+
+## Statut
+
+PASS
+
+## Objet
+
+Clôture opérateur de la tranche stable `0.1.4-rel.1`.
+
+La tranche promeut le candidat `0.1.4-rc.1` en stable `0.1.4` sans rouvrir le contenu fonctionnel Tauri : la roadmap marque `0.1.4` terminée, le changelog perd son marqueur `candidate`, le README et l'index documentaire présentent la stable, le plan `010` devient historique et le handoff `011` vers `0.1.5-alpha.1` reste cohérent.
+
+## Gate opérateur
+
+Gate exécutée le `2026-09-29`.
+
+### Préconditions et cohérence stable
+
+PASS :
+
+- `VERSION` vaut `0.1.4`;
+- `history/0.1.4/rc.1.md` est présent dans le commit précédent et porte le statut `PASS`;
+- `deltas/0.1.4/rel.1.md` est présent;
+- `history/0.1.4/rel.1.md` est absent pendant la gate;
+- `prompts/011-V0_1_5_START_PROMPT.md` est présent;
+- `README.md` porte la version documentaire `27`;
+- `ROADMAP.md` porte la version documentaire `17`;
+- `CHANGELOG.md` porte la version documentaire `19`;
+- `docs/000-README.md` porte la version documentaire `46`;
+- `docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md` porte la version documentaire `6`.
+
+### Présentation stable
+
+PASS :
+
+- `ROADMAP.md` marque `0.1.4` terminé;
+- `CHANGELOG.md` contient `## 0.1.4` sans marqueur `candidate`;
+- `README.md` présente `0.1.4` comme stable Tauri;
+- `docs/000-README.md` présente le plan `010` comme plan historique de la stable `0.1.4`;
+- le handoff `011` vers `0.1.5-alpha.1` reste présent.
+
+### Tests Python
+
+Commande :
+
+```text
+python3 -B -m unittest discover -s tests -v
+```
+
+Résultat :
+
+```text
+Ran 55 tests
+OK
+```
+
+Soit `55/55` PASS.
+
+### Hygiène texte
+
+Commande :
+
+```text
+python3 -B scripts/audit_text_hygiene.py \
+    VERSION README.md RULES.md ROADMAP.md CHANGELOG.md \
+    docs deltas history prompts scripts tests templates .gitignore .settings
+```
+
+Résultat :
+
+```text
+Text hygiene audit: clean (308 file(s))
+```
+
+### Audits Markdown
+
+Résultats :
+
+```text
+Markdown header audit: clean (281 file(s))
+Markdown table audit: clean (11 table(s), 281 file(s))
+Markdown link audit: clean (357 local link(s), 281 file(s))
+```
+
+### Audit structurel `rel.1`
+
+Résultat :
+
+```text
+0.1.4 rel.1 stable gate audit: clean (6 prior histories including expected alpha.2 FAIL/fix PASS, rel.1 pending, stable Tauri presentation and 0.1.5 handoff coherent)
+```
+
+L'audit confirme notamment :
+
+- `alpha.1` : `PASS`;
+- `alpha.2` : `FAIL`;
+- `alpha.2.fix.1` : `PASS`;
+- `alpha.3` : `PASS`;
+- `beta.1` : `PASS`;
+- `rc.1` : `PASS`;
+- `rel.1` est la seule tranche encore sans history pendant la gate;
+- les owners et artefacts Tauri stabilisés restent inchangés;
+- aucun template Tauri générique ni contrat `006-TAURI_VALIDATION.md` n'est introduit;
+- le prompt `011` conserve le handoff vers `0.1.5`.
+
+### Contrôles Git
+
+Résultats :
+
+```text
+git diff --check
+git diff --cached --check
+```
+
+Les deux commandes sont silencieuses.
+
+Scope indexé observé :
+
+```text
+M  CHANGELOG.md
+M  README.md
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.4/rel.1.md
+M  docs/000-README.md
+M  docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+```
+
+## Décision
+
+`0.1.4-rel.1` est validée `PASS`.
+
+La tranche peut être historisée puis matérialisée par le commit stable `0.1.4`. Après push, le tag annoté `v0.1.4` peut être créé et publié. La vérification post-tag doit ensuite être exécutée depuis l'archive Gitea du tag avant production de `pgr-0.1.4-publish.001-report.md`.
+
+## Handoff
+
+La prochaine version engagée reste `0.1.5`, consacrée à la sémantique normative, à l'autonomie des projets après adoption PGR et à la frontière PGR / SaseDev Knowledge. Les adoptions Games et KSP restent respectivement réservées à `0.1.6` et `0.1.7`.

history/0.1.5/alpha.1.fix.1.md

@@ -0,0 +1,97 @@
+<!-- file: history/0.1.5/alpha.1.fix.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.5-alpha.1.fix.1 — preuves de cadrage complétées
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.5-alpha.1.fix.1` exécutée le `2026-09-30` est propre. Les preuves requises mais absentes du premier transcript `alpha.1` ont été acquises sans modifier le contenu normatif ; le résultat `PARTIAL` de `alpha.1` reste conservé comme fait historique et `alpha.2` peut maintenant commencer.
+
+## Baseline opérateur
+
+La tranche `0.1.5-alpha.1` et son history `PARTIAL` ont été committés puis publiés avant application du fix :
+
+```text
+commit alpha.1   90ca422
+push             c41b69b..90ca422  master -> master
+```
+
+La version observée pendant la gate du fix est :
+
+```text
+0.1.5-alpha.1.fix.1
+```
+
+`history/0.1.5/alpha.1.md` est présent avec le statut `PARTIAL`, tandis que `history/0.1.5/alpha.1.fix.1.md` était absent pendant la gate.
+
+## Trajectoire et frontière historique
+
+Les contrôles ROADMAP ont confirmé :
+
+```text
+0.1.4   terminé
+0.1.5   engagé — sémantique normative + autonomie + frontière PGR/Knowledge
+0.1.6   engagé — adoption sasedev-games
+0.1.7   engagé — adoption khadhroony-solana-project
+0.1.8   engagé — audits Rust/Clippy read-only
+0.1.9   non réservé
+```
+
+Le contrôle d'appariement a affiché :
+
+```text
+0.1.5 alpha.1.fix.1 history boundary: clean (104 closed prior pairs, current fix pending)
+```
+
+Il confirme l'appariement exact des releases stables `0.0.1` à `0.1.4`, puis `alpha.1.md` présent à la fois sous `deltas/0.1.5` et `history/0.1.5`, avec `alpha.1.fix.1.md` encore en attente de son history pendant la gate.
+
+## Contrat du prompt et du plan
+
+Les assertions ciblées sur `prompts/011-V0_1_5_START_PROMPT.md` ont confirmé :
+
+- `SHOULD / SHOULD NOT` comme forte recommandation non obligatoire ;
+- absence de recherche automatique de « la dernière version de PGR » après établissement d'une baseline locale ;
+- adoption Games réservée à `0.1.6` ;
+- adoption KSP réservée à `0.1.7` ;
+- audits Rust/Clippy réservés à `0.1.8`.
+
+Les assertions ciblées sur `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` ont confirmé :
+
+- `29` fichiers contenant `SHOULD / SHOULD NOT` pour `242` occurrences textuelles brutes ;
+- `alpha.2` réservé à la sémantique normative et aux conséquences de gate/adoption ;
+- `alpha.3` réservé à l'autonomie locale et au réalignement volontaire ;
+- `alpha.4` réservé à la frontière PGR / SaseDev Knowledge.
+
+## Audits documentaires
+
+Les audits exécutés pendant le fix sont propres :
+
+```text
+Text hygiene audit: clean (313 file(s))
+Markdown header audit: clean (286 file(s))
+Markdown table audit: clean (11 table(s), 286 file(s))
+Markdown link audit: clean (370 local link(s), 286 file(s))
+```
+
+La suite Python n'a pas été rejouée par ce fix de preuve : aucun script ni test n'a été modifié depuis le `55/55 PASS` observé pendant `alpha.1`, et le scope du fix est limité à `VERSION` et à son delta documentaire.
+
+## Hygiène Git et scope observé
+
+`git diff --check` puis `git diff --cached --check` n'ont produit aucun diagnostic.
+
+Le scope indexé observé est exactement :
+
+```text
+M  VERSION
+A  deltas/0.1.5/alpha.1.fix.1.md
+```
+
+Aucun owner normatif, skeleton, template, plan ou document historique antérieur n'a été modifié par le fix.
+
+## Décision
+
+`0.1.5-alpha.1.fix.1` est validée `PASS`.
+
+Le cadrage `0.1.5` est maintenant suffisamment prouvé pour ouvrir `alpha.2`. La tranche suivante reste bornée à la stabilisation de la sémantique `MUST / SHOULD / MAY`, à ses conséquences sur `OVERRIDE` et les gates, et aux quelques renforcements accidentels identifiés par l'inventaire ; elle ne doit commencer ni l'autonomie `alpha.3`, ni la frontière Knowledge `alpha.4`, ni les adoptions Games/KSP.

history/0.1.5/alpha.1.md

@@ -0,0 +1,115 @@
+<!-- file: history/0.1.5/alpha.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.5-alpha.1 — cadrage normatif, autonomie et frontière Knowledge
+
+## Statut
+
+PARTIAL
+
+La gate opérateur de `0.1.5-alpha.1` exécutée le `2026-09-30` a acquis toutes les preuves mécaniques effectivement lancées, sans échec observé. Elle reste toutefois `PARTIAL` car plusieurs contrôles explicitement requis par `deltas/0.1.5/alpha.1.md` ne figurent pas dans le transcript opérateur et ne peuvent pas être remplacés par une prévalidation IA.
+
+Aucun défaut du contenu livré par `alpha.1` n'est établi par les preuves disponibles. La tranche corrective `alpha.1.fix.1` est limitée à l'acquisition des contrôles manquants ; elle ne modifie aucune règle normative et n'absorbe aucun scope de `alpha.2`.
+
+## Baseline et version observées
+
+La version observée par l'opérateur est :
+
+```text
+0.1.5-alpha.1
+```
+
+Les contrôles de présence ont confirmé :
+
+```text
+docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md   présent
+deltas/0.1.5/alpha.1.md                              présent
+history/0.1.5/alpha.1.md                              absent pendant la gate
+```
+
+La chronologie stable précédente a également été relue avec les statuts attendus :
+
+```text
+history/0.1.4/alpha.2.md          FAIL
+history/0.1.4/alpha.2.fix.1.md    PASS
+history/0.1.4/rel.1.md            PASS
+```
+
+## Tests Python observés
+
+La suite complète a terminé avec succès :
+
+```text
+Ran 55 tests in 1.678s
+
+OK
+```
+
+Soit `55/55` tests `PASS` pour les commandes réellement exécutées.
+
+## Audits observés
+
+Les audits documentaires et d'hygiène lancés par l'opérateur sont propres :
+
+```text
+Text hygiene audit: clean (311 file(s))
+Markdown header audit: clean (284 file(s))
+Markdown table audit: clean (11 table(s), 284 file(s))
+Markdown link audit: clean (370 local link(s), 284 file(s))
+```
+
+`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
+
+## Scope Git observé
+
+Avant indexation, `git status --short` a affiché :
+
+```text
+ M README.md
+ M VERSION
+ M docs/000-README.md
+?? deltas/0.1.5/
+?? docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+```
+
+Après l'ajout explicite des cinq chemins de `alpha.1`, le scope indexé est exactement :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.5/alpha.1.md
+M  docs/000-README.md
+A  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+```
+
+Aucun chemin sous `docs/rules/`, `docs/skeletons/` ou `docs/templates/` n'apparaît dans ce scope.
+
+## Preuves requises non observées
+
+Le transcript ne contient pas l'exécution des contrôles suivants pourtant présents dans la gate canonique du delta `alpha.1` :
+
+- assertions `ROADMAP.md` confirmant `0.1.4` terminé, `0.1.5` à `0.1.8` réservés et l'absence de réservation `0.1.9` ;
+- contrôle d'appariement des `103` couples delta/history historiques et de la frontière du history courant ;
+- assertions ciblées du prompt `011` sur la sémantique `SHOULD`, l'autonomie et les réservations `0.1.6` à `0.1.8` ;
+- assertions ciblées du plan `011` sur les `29` fichiers, `242` occurrences et la séparation `alpha.2` / `alpha.3` / `alpha.4`.
+
+Ces assertions avaient été prévalidées avant livraison, mais cette prévalidation ne constitue pas la preuve opérateur exigée par `docs/rules/400-VALIDATION.md`.
+
+## Diagnostic
+
+Le résultat est `PARTIAL`, et non `FAIL` : aucune commande réellement exécutée n'a échoué et aucun défaut de contenu n'est démontré. La limitation vient d'une gate opérateur incomplètement rejouée.
+
+Le bloc de commandes remis dans le handoff précédent ne reproduisait que les commandes principales alors que le delta contenait une gate plus complète. Le correctif doit donc rester strictement opérationnel et réacquérir les preuves omises sans réécrire le contenu de `alpha.1`.
+
+## Transition
+
+Appliquer le présent history puis committer/pusher `0.1.5-alpha.1` avec son statut `PARTIAL` avant d'appliquer `0.1.5-alpha.1.fix.1`.
+
+Le fix suivant :
+
+- passe `VERSION` à `0.1.5-alpha.1.fix.1` ;
+- n'altère aucun owner normatif, skeleton, template, plan ou contenu de cadrage ;
+- rejoue les preuves manquantes et les audits documentaires nécessaires à son propre artefact ;
+- autorise `alpha.2` uniquement si sa gate obtient réellement `PASS`.
+
+Aucun commit, push ni résultat de `alpha.1.fix.1` n'est déclaré observé dans le présent history.

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`.

history/0.1.5/alpha.3.md

@@ -0,0 +1,121 @@
+<!-- file: history/0.1.5/alpha.3.md -->
+<!-- version: 1 -->
+
+# History 0.1.5-alpha.3 — autonomie locale stabilisée
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.5-alpha.3` exécutée le `2026-10-01` est propre. La tranche établit la baseline locale comme autorité des sessions et releases suivantes après instanciation/adoption et définit tout réalignement futur avec PGR comme une opération volontaire, explicite et bornée.
+
+## Baseline opérateur
+
+La tranche `0.1.5-alpha.2` et son history `PASS` ont été committés puis publiés avant application de `alpha.3` :
+
+```text
+commit alpha.2   e94b786
+push             32433ca..e94b786  master -> master
+```
+
+La version observée pendant la gate est :
+
+```text
+0.1.5-alpha.3
+```
+
+Les histories précédents conservent la séquence réelle :
+
+```text
+alpha.1          PARTIAL
+alpha.1.fix.1    PASS
+alpha.2          PASS
+```
+
+Le history `alpha.3` était absent pendant la gate.
+
+## Autorité locale acquise
+
+Les assertions opérateur ont confirmé dans `RULES.md` révision `16` :
+
+- après établissement de la baseline locale, cette baseline et ses owners deviennent l'autorité des sessions et releases suivantes ;
+- PGR ne devient pas un upstream documentaire implicite ;
+- un projet MUST NOT rechercher automatiquement « la dernière version de PGR » ;
+- un réalignement futur MAY être engagé uniquement comme opération explicite et bornée à partir d'un snapshot PGR précis.
+
+`docs/rules/220-SKELETONS.md` révision `2` propage ce contrat au point d'instanciation : le projet possède sa baseline locale, ne recherche pas automatiquement une version PGR plus récente et ne revient vers PGR que depuis un snapshot explicitement choisi.
+
+`docs/rules/230-ADOPTION.md` révision `3` établit le même contrat après adoption et formalise la procédure de réalignement futur : identification du snapshot, comparaison avec la baseline locale et absence de mise à jour automatique.
+
+## Propagation aux artefacts d'adoption
+
+Les assertions ont confirmé :
+
+- `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` révision `5` : la baseline locale et ses owners deviennent autoritaires après instanciation ;
+- `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` révision `2` : le snapshot PGR choisi est explicite, l'autorité après adoption est locale et le réalignement automatique est `non`.
+
+`docs/rules/210-WORKFLOW.md` révision `9` et `docs/templates/003-NEW_SESSION_PROMPT.md` révision `2` sont restés `KEEP` comme prévu : leur reprise depuis la baseline autoritaire du projet courant est déjà compatible avec le contrat d'autonomie.
+
+Le plan `011` révision `3` enregistre `alpha.2 PASS`, les décisions de mise en œuvre `alpha.3` et maintient explicitement la frontière PGR / SaseDev Knowledge en `alpha.4`.
+
+## 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.3 history boundary: clean (106 closed prior pairs, current alpha.3 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.902s
+OK
+```
+
+Les audits documentaires sont également propres :
+
+```text
+Text hygiene audit: clean (317 file(s))
+Markdown header audit: clean (290 file(s))
+Markdown table audit: clean (11 table(s), 290 file(s))
+Markdown link audit: clean (371 local link(s), 290 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.3`. Après indexation explicite, le scope observé est exactement :
+
+```text
+M  README.md
+M  RULES.md
+M  VERSION
+A  deltas/0.1.5/alpha.3.md
+M  docs/000-README.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+M  docs/rules/220-SKELETONS.md
+M  docs/rules/230-ADOPTION.md
+M  docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
+M  docs/templates/007-EXISTING_PROJECT_ADOPTION.md
+```
+
+## Décision
+
+`0.1.5-alpha.3` est validée `PASS`.
+
+La tranche suivante peut ouvrir `alpha.4`, strictement consacrée à la frontière PGR / SaseDev Knowledge : taxonomie normative/pratique, auto-suffisance de PGR et suppression de l'ambiguïté « recette Markdown » sans migration physique vers Knowledge et sans dépendance externe.

history/0.1.5/alpha.4.md

@@ -0,0 +1,121 @@
+<!-- file: history/0.1.5/alpha.4.md -->
+<!-- version: 1 -->
+
+# History 0.1.5-alpha.4 — frontière PGR / Knowledge stabilisée
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.5-alpha.4` exécutée le `2026-10-01` est propre. La tranche fixe la frontière durable entre le référentiel normatif PGR et les contenus pratiques externes possibles sans créer de dépendance vers SaseDev Knowledge ni déplacer automatiquement de contenu.
+
+## Baseline opérateur
+
+La tranche `0.1.5-alpha.3` et son history `PASS` ont été committés puis publiés avant application de `alpha.4` :
+
+```text
+commit alpha.3   7079b15
+push             e94b786..7079b15  master -> master
+```
+
+La version observée pendant la gate est :
+
+```text
+0.1.5-alpha.4
+```
+
+Les histories précédents conservent la séquence réelle :
+
+```text
+alpha.1          PARTIAL
+alpha.1.fix.1    PASS
+alpha.2          PASS
+alpha.3          PASS
+```
+
+Le history `alpha.4` était absent pendant la gate.
+
+## Frontière PGR / Knowledge acquise
+
+Les assertions opérateur ont confirmé dans `docs/objectives/001-PROJECT_OBJECTIVES.md` révision `2` :
+
+- les skeletons sont des spécifications Markdown composables et non des recettes pratiques ;
+- PGR reste auto-suffisant pour comprendre et appliquer ses contrats normatifs ;
+- les howtos détaillés, recettes pratiques, snippets, exemples d'intégration, dépannage, comparatifs et variantes d'implémentation peuvent vivre dans une base de connaissances séparée lorsqu'une telle séparation apporte une valeur réelle.
+
+`docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` révision `5` confirme qu'un skeleton est une spécification Markdown composable, que SaseDev Knowledge n'est qu'une destination pratique possible et que PGR MUST NOT dépendre d'un dépôt Knowledge pour être interprétable ou applicable.
+
+`docs/rules/300-DOCUMENTATION.md` révision `5` devient l'owner documentaire de cette frontière :
+
+- SaseDev Knowledge MAY accueillir des contenus pratiques sans devenir owner normatif de PGR ;
+- une règle PGR MUST rester compréhensible et applicable sans howto/snippet externe ;
+- classifier un contenu comme pratique ne déclenche aucun déplacement automatique ;
+- la séparation MUST NOT créer de dépendance de PGR vers SaseDev Knowledge ou un autre dépôt documentaire externe.
+
+## Owners gelés et trajectoire
+
+Les contrôles ont confirmé que les owners hors scope de `alpha.4` restent inchangés :
+
+```text
+RULES.md                         version 16
+docs/rules/210-WORKFLOW.md      version 9
+docs/rules/230-ADOPTION.md      version 3
+```
+
+`git diff --exit-code` sur ces fichiers, `ROADMAP.md`, `CHANGELOG.md` et `history/0.1.4` n'a produit aucun écart.
+
+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.4 history boundary: clean (107 closed prior pairs, current alpha.4 pending)
+```
+
+## Tests et audits
+
+La suite Python complète est propre :
+
+```text
+Ran 55 tests in 0.916s
+OK
+```
+
+Les audits documentaires sont également propres :
+
+```text
+Text hygiene audit: clean (319 file(s))
+Markdown header audit: clean (292 file(s))
+Markdown table audit: clean (11 table(s), 292 file(s))
+Markdown link audit: clean (371 local link(s), 292 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.4`. Après indexation explicite, le scope observé est exactement :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.5/alpha.4.md
+M  docs/000-README.md
+M  docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
+M  docs/objectives/001-PROJECT_OBJECTIVES.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+M  docs/rules/300-DOCUMENTATION.md
+```
+
+## Décision
+
+`0.1.5-alpha.4` est validée `PASS`.
+
+La tranche suivante peut ouvrir `beta.1` pour la réconciliation transversale des trois contrats stabilisés : rescan des `SHOULD / SHOULD NOT`, vérification de l'autonomie/snapshots/overrides, recherche de références vivantes obsolètes et confirmation que les scopes Games `0.1.6`, KSP `0.1.7` et audits Rust/Clippy `0.1.8` n'ont pas commencé.

history/0.1.5/beta.1.md

@@ -0,0 +1,121 @@
+<!-- file: history/0.1.5/beta.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.5-beta.1 — réconciliation transversale
+
+## Statut
+
+PASS
+
+La gate opérateur de `0.1.5-beta.1` exécutée le `2026-10-01` est propre. Elle confirme la réconciliation des trois contrats transversaux stabilisés pendant les alphas sans nouveau défaut normatif démontré : sémantique `SHOULD / SHOULD NOT`, autonomie de la baseline locale et frontière PGR / SaseDev Knowledge.
+
+## Baseline opérateur
+
+La tranche `0.1.5-alpha.4` et son history `PASS` ont été committés puis publiés avant application de `beta.1` :
+
+```text
+commit alpha.4   43ee26b
+push             7079b15..43ee26b  master -> master
+```
+
+La version observée pendant la gate est :
+
+```text
+0.1.5-beta.1
+```
+
+Les histories précédents conservent la séquence réelle :
+
+```text
+alpha.1          PARTIAL
+alpha.1.fix.1    PASS
+alpha.2          PASS
+alpha.3          PASS
+alpha.4          PASS
+```
+
+Le history `beta.1` était absent pendant la gate.
+
+## Réconciliation acquise
+
+Les contrôles opérateur ont confirmé que :
+
+- `RULES.md` révision `16` conserve `SHOULD / SHOULD NOT` comme forte recommandation non obligatoire et n'exige pas automatiquement un `OVERRIDE` pour un simple écart ;
+- `230-ADOPTION.md` révision `3` interdit la recherche automatique de « la dernière version de PGR » et conserve le réalignement comme opération explicite sur snapshot choisi ;
+- `400-VALIDATION.md` révision `2` interdit qu'un simple écart à un `SHOULD / SHOULD NOT` fasse passer une tranche en `FAIL` ;
+- `300-DOCUMENTATION.md` révision `5` conserve PGR auto-suffisant et SaseDev Knowledge comme destination pratique possible sans devenir owner normatif ;
+- `210-WORKFLOW.md` reste en révision `9` et `003-NEW_SESSION_PROMPT.md` en révision `2` ;
+- la référence vivante Games de `540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` pointe vers l'adoption `0.1.6` et l'ancienne référence `0.1.5` est absente de ce contexte vivant ;
+- Games `0.1.6`, KSP `0.1.7` et les audits Rust/Clippy `0.1.8` restent réservés tandis qu'aucun `0.1.9` n'est créé.
+
+Le plan `011` révision `5` enregistre explicitement `alpha.4 PASS`, la réconciliation transversale préparée en `beta.1` et la décision de **KEEP des owners normatifs acquis**.
+
+## Frontière delta/history
+
+Le contrôle structurel a affiché :
+
+```text
+0.1.5 beta.1 history boundary: clean (108 closed prior pairs, current beta.1 pending)
+```
+
+Il confirme que les releases `0.0.1` à `0.1.4` conservent leurs couples delta/history exacts, que les cinq tranches précédentes de `0.1.5` sont closes et que `beta.1` était le seul delta courant sans history pendant sa gate.
+
+`history/0.1.4` est resté byte-stable pendant la tranche.
+
+## Freeze des owners
+
+Le contrôle `git diff --exit-code` sur les owners et artefacts normatifs acquis est propre. `beta.1` n'a donc modifié ni règle normative, ni skeleton, ni template, ni contrat de validation issu des alphas.
+
+La tranche a uniquement porté la version, la présentation/index, le plan actif et son delta.
+
+## Tests Python
+
+La suite complète a affiché :
+
+```text
+Ran 55 tests in 0.892s
+
+OK
+```
+
+Soit `55/55` tests `PASS`.
+
+## Audit d'hygiène texte
+
+L'audit réutilisable a affiché :
+
+```text
+Text hygiene audit: clean (321 file(s))
+```
+
+## Audits Markdown
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (294 file(s))
+Markdown table audit: clean (11 table(s), 294 file(s))
+Markdown link audit: clean (371 local link(s), 294 file(s))
+```
+
+## Hygiène Git et scope observé
+
+`git diff --check` puis `git diff --cached --check` n'ont signalé aucune anomalie.
+
+Après indexation, le scope observé est exactement :
+
+```text
+M  README.md
+M  VERSION
+A  deltas/0.1.5/beta.1.md
+M  docs/000-README.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+```
+
+Il correspond au scope annoncé par le delta.
+
+## Décision
+
+`0.1.5-beta.1` est validée `PASS`.
+
+La phase alpha/bêta est réconciliée sans défaut transversal restant démontré. La tranche suivante peut être `0.1.5-rc.1`, limitée au freeze des contrats acquis, à la présentation candidate, à une revue d'horizon bornée et à la préparation du handoff `0.1.6` uniquement si l'adoption Games reste la prochaine dépendance réelle.

history/0.1.5/rc.1.fix.1.md

@@ -0,0 +1,133 @@
+<!-- file: history/0.1.5/rc.1.fix.1.md -->
+<!-- version: 1 -->
+
+# PGR 0.1.5 — history `rc.1.fix.1`
+
+## Statut
+
+PASS
+
+## Objet
+
+Clôture opérateur du correctif documentaire `0.1.5-rc.1.fix.1`.
+
+Le correctif aligne exactement les trois formulations qui avaient fait échouer `rc.1`, sans rouvrir les contrats normatifs, le handoff `012`, la roadmap ou les owners gelés.
+
+## Baseline opérateur
+
+La tranche `0.1.5-rc.1` avec son history `FAIL` a été committée puis publiée avant application du correctif :
+
+```text
+commit rc.1   4d7021b
+push          ec1a296..4d7021b  master -> master
+```
+
+Une première tentative de `git push origin master` a été interrompue au prompt d'identification puis immédiatement rejouée avec succès. Elle n'a modifié ni le commit ni le contenu de la tranche.
+
+La version observée pendant la gate du correctif est :
+
+```text
+0.1.5-rc.1.fix.1
+```
+
+`history/0.1.5/rc.1.md` est présent et conserve le statut réel `FAIL`. Le history du présent correctif était absent pendant la gate.
+
+## Assertions documentaires corrigées
+
+PASS :
+
+- `CHANGELOG.md` est en révision `21` et contient la formulation canonique `forte recommandation non obligatoire` ;
+- `docs/studies/005-V0_1_5_HORIZON_REVIEW.md` est en révision `2` et contient explicitement `aucun numéro de version Games n’est figé` ;
+- la même étude contient la classification canonique `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A` ;
+- la décision de conserver `0.1.6` comme prochaine release est inchangée ;
+- aucun `0.1.9` n'est réservé ;
+- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` est en révision `7`, conserve la vérité `rc.1 FAIL` et bloque `rel.1` jusqu'au présent `PASS`.
+
+## Owners et surfaces gelés
+
+PASS :
+
+```text
+README.md                                       version 33
+ROADMAP.md                                      version 18
+docs/000-README.md                              version 52
+prompts/012-V0_1_6_START_PROMPT.md              version 1
+RULES.md                                        version 16
+docs/rules/210-WORKFLOW.md                      version 9
+docs/rules/230-ADOPTION.md                      version 3
+docs/rules/300-DOCUMENTATION.md                 version 5
+docs/rules/400-VALIDATION.md                    version 2
+```
+
+Le contrôle `git diff --exit-code` confirme également l'absence de modification des owners, skeletons et templates explicitement hors scope du fix.
+
+## Frontière delta/history
+
+Résultat opérateur :
+
+```text
+0.1.5 rc.1.fix.1 history boundary: clean (110 closed prior pairs, current rc.1.fix.1 pending)
+```
+
+La gate observe donc :
+
+- toutes les releases `0.0.1` à `0.1.4` avec leurs couples delta/history attendus ;
+- pour `0.1.5`, les histories de `alpha.1`, `alpha.1.fix.1`, `alpha.2`, `alpha.3`, `alpha.4`, `beta.1` et `rc.1` ;
+- `rc.1.fix.1` comme seule tranche courante encore sans history pendant sa validation.
+
+## Tests Python
+
+Commande :
+
+```text
+python3 -B -m unittest discover -s tests -v
+```
+
+Résultat :
+
+```text
+Ran 55 tests in 0.898s
+OK
+```
+
+Soit `55/55` PASS.
+
+## Hygiène texte
+
+Résultat :
+
+```text
+Text hygiene audit: clean (327 file(s))
+```
+
+## Audits Markdown
+
+Résultats :
+
+```text
+Markdown header audit: clean (300 file(s))
+Markdown table audit: clean (11 table(s), 300 file(s))
+Markdown link audit: clean (375 local link(s), 300 file(s))
+```
+
+## Git
+
+`git diff --check` puis `git diff --cached --check` n'ont remonté aucune anomalie.
+
+Scope final observé :
+
+```text
+M  CHANGELOG.md
+M  VERSION
+A  deltas/0.1.5/rc.1.fix.1.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+M  docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+```
+
+Ce scope correspond exactement au delta prévu.
+
+## Conclusion
+
+`0.1.5-rc.1.fix.1` est `PASS`.
+
+Les trois écarts documentaires de `rc.1` sont corrigés sans changement fonctionnel ou normatif. La candidate est donc éligible à `rel.1`, qui doit rester une promotion stable mécanique sans commencer `0.1.6`.

history/0.1.5/rc.1.md

@@ -0,0 +1,135 @@
+<!-- file: history/0.1.5/rc.1.md -->
+<!-- version: 1 -->
+
+# History 0.1.5-rc.1 — freeze et revue d’horizon
+
+## Statut
+
+FAIL
+
+La gate opérateur de `0.1.5-rc.1` exécutée le `2026-10-01` valide le freeze fonctionnel, les tests Python, les audits documentaires et le scope Git, mais échoue sur trois assertions textuelles exactes prévues par le delta. Le résultat réel est donc `FAIL` malgré l'absence de défaut normatif démontré.
+
+## Baseline opérateur
+
+La tranche `0.1.5-beta.1` et son history `PASS` ont été committés puis publiés avant application de `rc.1` :
+
+```text
+commit beta.1   ec1a296
+push            43ee26b..ec1a296  master -> master
+```
+
+La version observée pendant la gate est :
+
+```text
+0.1.5-rc.1
+```
+
+Les histories précédents conservent la séquence réelle :
+
+```text
+alpha.1          PARTIAL
+alpha.1.fix.1    PASS
+alpha.2          PASS
+alpha.3          PASS
+alpha.4          PASS
+beta.1           PASS
+```
+
+Le history `rc.1` était absent pendant la gate.
+
+## Freeze et handoff acquis
+
+Les contrôles opérateur ont confirmé notamment :
+
+- `README.md` révision `33` présente la candidate `0.1.5-rc.1` et conserve `0.1.6` comme prochaine release ;
+- `CHANGELOG.md` révision `20` contient l'entrée `0.1.5 (candidate)` sans chronologie de tranches ;
+- `ROADMAP.md` révision `18` conserve `0.1.6` Games, `0.1.7` KSP et `0.1.8` audits Rust/Clippy, sans réserver `0.1.9` ;
+- `docs/studies/005-V0_1_5_HORIZON_REVIEW.md` et `prompts/012-V0_1_6_START_PROMPT.md` sont présents ;
+- le prompt `012` exige une future stable PGR `v0.1.5`, le rapport post-tag uniquement s'il existe réellement avec statut `PASS`, une archive Games autoritaire fournie, puis un intake `0.1.6-alpha.1` avec classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A` ;
+- `RULES.md`, `210-WORKFLOW.md`, `230-ADOPTION.md`, `300-DOCUMENTATION.md` et `400-VALIDATION.md` restent gelés aux révisions attendues ;
+- `history/0.1.4` et les owners normatifs stabilisés pendant les alphas restent byte-stables pendant la RC.
+
+## Assertions en échec
+
+Trois commandes exigées par `deltas/0.1.5/rc.1.md` ont été exécutées sans produire de correspondance :
+
+```text
+grep -F 'forte recommandation non obligatoire' CHANGELOG.md
+grep -F 'aucun numéro de version Games n’est figé' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+grep -F 'ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A' docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+```
+
+Le shell a poursuivi les commandes suivantes, mais l'absence de sortie sur ces assertions exactes constitue un échec de gate.
+
+Le diagnostic est documentaire et borné :
+
+- le changelog exprime la même sémantique avec la formulation « recommandations fortes non obligatoires », mais pas la chaîne canonique attendue au singulier ;
+- l'étude contient « Aucun numéro de version Games n’est figé... » avec une majuscule initiale, alors que la gate recherche la sous-chaîne en minuscule ;
+- l'étude présente bien les cinq valeurs de classification dans un bloc, mais ne contient pas encore la forme canonique slash-separated exigée par la gate.
+
+Aucun de ces trois écarts ne modifie les contrats normatifs acquis ni la décision d'horizon.
+
+## Frontière delta/history
+
+Le contrôle structurel a affiché :
+
+```text
+0.1.5 rc.1 history boundary: clean (109 closed prior pairs, current rc.1 pending)
+```
+
+Il confirme que les releases `0.0.1` à `0.1.4` conservent leurs couples delta/history exacts, que les six tranches précédentes de `0.1.5` sont closes et que `rc.1` était le seul delta courant sans history pendant sa gate.
+
+## Tests Python
+
+La suite complète a affiché :
+
+```text
+Ran 55 tests in 0.891s
+
+OK
+```
+
+Soit `55/55` tests `PASS`.
+
+## Audit d'hygiène texte
+
+L'audit réutilisable a affiché :
+
+```text
+Text hygiene audit: clean (325 file(s))
+```
+
+## Audits Markdown
+
+Les audits documentaires sont propres :
+
+```text
+Markdown header audit: clean (298 file(s))
+Markdown table audit: clean (11 table(s), 298 file(s))
+Markdown link audit: clean (375 local link(s), 298 file(s))
+```
+
+## Hygiène Git et scope observé
+
+`git diff --check` puis `git diff --cached --check` n'ont signalé aucune anomalie.
+
+Après indexation, le scope observé est exactement :
+
+```text
+M  CHANGELOG.md
+M  README.md
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.5/rc.1.md
+M  docs/000-README.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+M  docs/studies/000-README.md
+A  docs/studies/005-V0_1_5_HORIZON_REVIEW.md
+A  prompts/012-V0_1_6_START_PROMPT.md
+```
+
+## Décision
+
+`0.1.5-rc.1` est historisée `FAIL` parce que trois assertions contractuelles de la gate ont échoué.
+
+La correction doit rester limitée à la présentation documentaire et à la traçabilité du correctif. Aucun owner normatif ne doit être rouvert et `rel.1` ne doit pas commencer avant un `0.1.5-rc.1.fix.1` validé `PASS`.

history/0.1.5/rel.1.md

@@ -0,0 +1,150 @@
+<!-- file: history/0.1.5/rel.1.md -->
+<!-- version: 1 -->
+
+# PGR 0.1.5 — history `rel.1`
+
+## Statut
+
+PASS
+
+## Objet
+
+Clôture opérateur de la tranche stable `0.1.5-rel.1`.
+
+La tranche promeut la candidate corrigée `0.1.5-rc.1.fix.1` en stable `0.1.5` sans rouvrir les contrats normatifs acquis : sémantique `MUST / SHOULD / MAY`, autonomie de la baseline locale après adoption et frontière PGR / SaseDev Knowledge.
+
+## Baseline opérateur
+
+Le correctif `0.1.5-rc.1.fix.1` avec son history `PASS` a été committé puis publié avant application de `rel.1` :
+
+```text
+commit rc.1.fix.1   f49fd11
+push                4d7021b..f49fd11  master -> master
+```
+
+La version observée pendant la gate stable est :
+
+```text
+0.1.5
+```
+
+Les résultats historiques de la release restent conservés sans réécriture :
+
+```text
+alpha.1          PARTIAL
+alpha.1.fix.1    PASS
+alpha.2          PASS
+alpha.3          PASS
+alpha.4          PASS
+beta.1           PASS
+rc.1             FAIL
+rc.1.fix.1       PASS
+```
+
+`history/0.1.5/rel.1.md` était absent pendant la gate.
+
+## Présentation stable
+
+PASS :
+
+- `README.md` révision `34` présente `0.1.5` comme stable autoritaire courante ;
+- `CHANGELOG.md` révision `22` contient `## 0.1.5` sans marqueur `candidate` et conserve la formulation canonique `forte recommandation non obligatoire` ;
+- `ROADMAP.md` révision `19` marque `0.1.5` terminé et conserve `0.1.6`, `0.1.7` et `0.1.8` ouverts, sans réserver `0.1.9` ;
+- `docs/000-README.md` révision `53` présente le plan `011` comme plan historique de la stable `0.1.5` et conserve le handoff `012` ;
+- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` révision `8` enregistre le `PASS` du correctif RC, la promotion stable et l'exigence d'une vérification post-tag avant production de `publish.001` ;
+- `docs/studies/005-V0_1_5_HORIZON_REVIEW.md` reste en révision `2` ;
+- `prompts/012-V0_1_6_START_PROMPT.md` reste en révision `1`.
+
+## Owners et contrats gelés
+
+PASS :
+
+```text
+RULES.md                                        version 16
+docs/rules/210-WORKFLOW.md                     version 9
+docs/rules/230-ADOPTION.md                     version 3
+docs/rules/300-DOCUMENTATION.md                version 5
+docs/rules/400-VALIDATION.md                   version 2
+```
+
+Le contrôle `git diff --exit-code` a également confirmé l'absence de modification des objectifs, de l'architecture, des owners, skeletons, templates, de l'étude d'horizon et du prompt `012` explicitement gelés pour la promotion stable.
+
+## Frontière delta/history
+
+Résultat opérateur :
+
+```text
+0.1.5 rel.1 stable gate audit: clean (8 prior histories including alpha.1 PARTIAL and rc.1 FAIL/fix PASS, rel.1 pending)
+```
+
+La gate confirme que :
+
+- les huit tranches antérieures de `0.1.5` possèdent chacune leur delta et leur history avec le statut réellement observé ;
+- `rel.1` est la seule tranche `0.1.5` encore sans history pendant sa validation ;
+- `history/0.1.4` reste inchangé ;
+- le changelog stable ne contient aucun nom de tranche interne `alpha`, `beta`, `rc` ou `rel` dans l'entrée `0.1.5`.
+
+## Tests Python
+
+Commande :
+
+```text
+python3 -B -m unittest discover -s tests -v
+```
+
+Résultat :
+
+```text
+Ran 55 tests in 0.919s
+OK
+```
+
+Soit `55/55` PASS.
+
+## Hygiène texte
+
+Résultat :
+
+```text
+Text hygiene audit: clean (329 file(s))
+```
+
+## Audits Markdown
+
+Résultats :
+
+```text
+Markdown header audit: clean (302 file(s))
+Markdown table audit: clean (11 table(s), 302 file(s))
+Markdown link audit: clean (375 local link(s), 302 file(s))
+```
+
+## Git
+
+`git diff --check` puis `git diff --cached --check` n'ont remonté aucune anomalie.
+
+Scope final observé :
+
+```text
+M  CHANGELOG.md
+M  README.md
+M  ROADMAP.md
+M  VERSION
+A  deltas/0.1.5/rel.1.md
+M  docs/000-README.md
+M  docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
+```
+
+Ce scope correspond exactement à la promotion stable prévue.
+
+## Décision
+
+`0.1.5-rel.1` est validée `PASS`.
+
+La tranche peut être historisée puis matérialisée par le commit stable `0.1.5`. Après push de ce commit, le tag annoté `v0.1.5` peut être créé et publié.
+
+La publication ne sera considérée comme vérifiée qu'après récupération de l'archive source Gitea du tag, contrôle indépendant de son intégrité et rejeu des gates depuis cette archive. Le rapport externe `pgr-0.1.5-publish.001-report.md` ne doit être produit qu'après ces preuves réelles.
+
+## Handoff
+
+La prochaine release engagée reste `0.1.6`, consacrée à l'adoption réelle de `sasedev-games` à partir d'un corpus Games récent et explicitement autoritaire. Elle ne doit pas commencer avant un `publish.001` de `v0.1.5` validé `PASS`.

prompts/010-V0_1_4_START_PROMPT.md

@@ -0,0 +1,98 @@
+<!-- file: prompts/010-V0_1_4_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Prompt de démarrage 0.1.4 — réexamen Tauri et skeleton contrôlé
+
+## Baseline et cible
+
+Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`.
+
+La baseline attendue au démarrage effectif de `0.1.4` est l'archive source téléchargée depuis le tag Gitea `v0.1.3`, accompagnée du rapport post-tag `pgr-0.1.3-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`.
+
+Version cible : `0.1.4`. Première tranche attendue : `0.1.4-alpha.1`.
+
+Les corpus principaux attendus pour réexaminer Tauri sont des archives autoritaires récentes de `khadhroony-solana-project` et `sasedev-games`. Si aucune baseline plus récente n'est explicitement fournie, les dernières baselines Tauri déjà auditées par PGR restent des références de comparaison, sans être présumées représenter l'état courant des projets :
+
+```text
+khadhroony-solana-project-v0.3.17.zip  2a9cabcb9f147a348dcf8d24df8bc6c5029089b6d49feb17bd4a42b4293c329a
+games-v0.3.6.zip                       ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
+```
+
+Une archive source peut légitimement ne pas contenir `.git`. Ne pas lui attribuer une preuve Git qu'elle ne peut contenir.
+
+## Reprise manuelle après publication
+
+Après vérification réelle de l'archive du tag `v0.1.3` et du rapport post-tag `PASS`, la consigne de nouvelle session doit suivre le pattern de [`../docs/templates/003-NEW_SESSION_PROMPT.md`](../docs/templates/003-NEW_SESSION_PROMPT.md) et citer les artefacts réellement obtenus.
+
+La forme attendue, si les noms et le statut sont confirmés, est :
+
+```text
+Partir de l'archive pgr-v0.1.3.zip téléchargée depuis le tag Gitea v0.1.3 et du rapport post-tag pgr-0.1.3-publish.001-report.md. Lire et exécuter prompts/010-V0_1_4_START_PROMPT.md. Vérifier intégralement la stable PGR et les baselines autoritaires fournies de KSP/Games avant de réexaminer le DEFER du skeleton Tauri et de préparer 0.1.4-alpha.1, sans commencer l'adoption Games réservée à 0.1.5 ni l'adoption KSP réservée à 0.1.6.
+```
+
+Ce texte ne doit pas être remis comme preuve de publication avant le `publish.001 PASS` réel.
+
+## Mission
+
+Réexaminer objectivement la décision `DEFER` enregistrée dans [`../docs/studies/002-TAURI_SKELETON_DECISION.md`](../docs/studies/002-TAURI_SKELETON_DECISION.md) à partir des corpus Tauri réellement fournis, du profil [`../docs/rules/710-TAURI.md`](../docs/rules/710-TAURI.md), des owners Web stabilisés par `0.1.1`, du profil Android stabilisé par `0.1.3` et des règles de skeletons.
+
+La release `0.1.4` ne part pas du principe qu'un skeleton Tauri doit être créé. Elle doit confirmer, modifier ou abandonner le candidat historique selon les preuves courantes. Si un skeleton contrôlé est justifié, il doit sélectionner et composer des owners existants plutôt que devenir leur propriétaire implicite.
+
+`alpha.1` MUST commencer par :
+
+1. auditer indépendamment la stable `v0.1.3` et son rapport post-tag lorsqu'il est fourni ;
+2. auditer les corpus KSP/Games réellement fournis et inventorier leurs hosts Tauri actuels, sans supposer que les layouts, versions ou plugins historiques sont encore représentatifs ;
+3. relire `710-TAURI.md`, `220-SKELETONS.md`, `510-RUST_CARGO.md`, `003-WEB_FRONTEND.md`, les owners Web `530/540/550/560`, `005-WEB_FRONTEND_VALIDATION.md`, `600-PLATFORMS.md`, `610-ANDROID.md`, l'étude `002-TAURI_SKELETON_DECISION.md` et la revue d'horizon `003` ;
+4. vérifier la documentation Tauri 2 officielle courante pour les points susceptibles d'avoir évolué ;
+5. créer le plan `0.1.4` avant toute matérialisation importante ;
+6. classifier les choix observés avec `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` et décider explicitement si les conditions de sortie du report historique sont réellement satisfaites par le corpus courant.
+
+## Questions à instruire
+
+La release doit notamment réexaminer :
+
+- pertinence réelle d'un skeleton Tauri organisationnel pour les nouveaux projets contrôlés ;
+- composition avec `001-PROJECT_GOVERNANCE_FOUNDATION`, `002-RUST_CARGO_WORKSPACE` et `003-WEB_FRONTEND` sans duplication normative ;
+- host Cargo direct versus layout `src-tauri/`, en distinguant convention organisationnelle et possibilité supportée par Tauri ;
+- statut de `frontend/`, Vite, TypeScript, Sass et Bootstrap : choix éventuels du skeleton/projet, jamais obligations Tauri implicites ;
+- TS-RS pour les DTO Rust/TypeScript lorsque cette frontière est réellement présente, sans le rendre universel ;
+- ownership de `tauri.conf.json`, `build.rs`, capabilities/permissions, plugins, commandes et hooks frontend ;
+- ajout manuel de plugins versus commandes de commodité telles que `cargo tauri add`, avec revue explicite des modifications générées ;
+- `devUrl`, `frontendDist`, outputs/caches et séparation source/généré ;
+- stratégie de version produit `CANONICAL / MIRROR-EXACT / MIRROR-STABLE` sans churn cérémoniel ;
+- distinction entre preuves Rust, preuves frontend, `tauri dev`, `tauri build` et packaging plateforme ;
+- projets mobiles générés/modifiés par Tauri et composition avec les profils Android/iOS applicables sans absorber leurs responsabilités dans `710` ;
+- nécessité éventuelle de templates techniques ou d'un contrat de validation Tauri supplémentaire, uniquement si un besoin non couvert est démontré ;
+- compatibilité du candidat avec plusieurs package managers et plusieurs choix frontend supportés.
+
+## Frontières obligatoires
+
+`0.1.4` MUST NOT :
+
+- migrer KSP ou Games vers PGR ;
+- créer le skeleton Tauri parce que la roadmap le mentionne ou parce que les cinq prérequis Web sont désormais couverts ;
+- transformer Vite, TypeScript, Sass, Bootstrap, npm, TS-RS, `frontend/` ou l'absence de `src-tauri/` en obligations universelles du profil Tauri sans preuve correspondante ;
+- rouvrir Android `0.1.3` sauf défaut transversal réellement démontré ;
+- démarrer l'adoption Games `0.1.5` ou l'adoption KSP `0.1.6` ;
+- intégrer WASM au host Tauri par défaut ;
+- créer un owner serveur Rust, deployment/operations ou iOS par proximité ;
+- réserver une nouvelle release au-delà de la roadmap engagée sans revue d'horizon justifiée.
+
+Les personnalisations produit, plugins concrets, fenêtres, CSP, ports, targets de bundle, icônes, ABI et autres valeurs spécifiques aux corpus restent locales sauf invariant réutilisable démontré.
+
+## Principes
+
+- Le skeleton doit composer des owners ; il ne remplace pas un owner manquant.
+- Les conditions de sortie historiques autorisent un réexamen, pas une création automatique.
+- Partir des hosts Tauri réellement présents dans les corpus courants et comparer leurs convergences/divergences.
+- Vérifier les capacités officielles courantes de Tauri 2 avant de figer une convention organisationnelle.
+- Maintenir une séparation claire entre host Rust, frontend Web, intégration Tauri et plateformes mobiles.
+- Utiliser les toolchains propriétaires des preuves : Cargo/Rust pour Rust, toolchain frontend pour le Web, CLI Tauri pour l'orchestration Tauri et outils plateforme pour les artefacts mobiles.
+- Ne pas exiger un `tauri build` complet lorsqu'une modification ne touche pas l'intégration ou le packaging ; inversement, ne pas assimiler un `cargo check` ou un build frontend isolé à une preuve Tauri complète lorsque la propriété dépend des hooks/capabilities/bundling.
+- Conserver `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` afin de préparer les futures adoptions `0.1.5` et `0.1.6` sans les commencer.
+
+## Workflow
+
+Suivre [`../RULES.md`](../RULES.md), [`../docs/rules/210-WORKFLOW.md`](../docs/rules/210-WORKFLOW.md), [`../docs/rules/220-SKELETONS.md`](../docs/rules/220-SKELETONS.md), [`../docs/rules/230-ADOPTION.md`](../docs/rules/230-ADOPTION.md) et [`../docs/rules/400-VALIDATION.md`](../docs/rules/400-VALIDATION.md).
+
+La séquence reste : delta → gate opérateur → history constaté → application du history → commit/push → delta suivant. Les commandes de handoff sont remises automatiquement conformément à [`../docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`](../docs/templates/006-OPERATOR_COMMAND_HANDOFF.md).

prompts/011-V0_1_5_START_PROMPT.md

@@ -0,0 +1,81 @@
+<!-- file: prompts/011-V0_1_5_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Prompt de démarrage 0.1.5 — sémantique normative et autonomie des projets
+
+## Baseline et cible
+
+Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`.
+
+La baseline attendue au démarrage effectif de `0.1.5` est l’archive source téléchargée depuis le tag Gitea `v0.1.4`, accompagnée du rapport post-tag `pgr-0.1.4-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`.
+
+Version cible : `0.1.5`. Première tranche attendue : `0.1.5-alpha.1`.
+
+Une archive source de tag peut légitimement ne pas contenir `.git`. Ne pas lui attribuer une preuve Git qu’elle ne peut contenir.
+
+## Mission
+
+Stabiliser avant les adoptions Games/KSP trois contrats transversaux révélés par l’utilisation réelle de PGR :
+
+1. `SHOULD / SHOULD NOT` exprime une forte recommandation non obligatoire et ne doit pas être traité comme un `MUST` affaibli ;
+2. après instanciation/adoption, le projet destinataire devient autonome et ses règles locales sont l’autorité de ses sessions/releases suivantes ;
+3. PGR reste centré sur les contrats de gouvernance/règles réutilisables tandis que howtos, recettes et snippets pratiques pourront vivre dans SaseDev Knowledge lorsque celui-ci est suffisamment fonctionnel, sans créer de dépendance normative de PGR vers Knowledge.
+
+La décision de trajectoire autoritaire est enregistrée dans [`../docs/studies/004-V0_1_4_HORIZON_REVIEW.md`](../docs/studies/004-V0_1_4_HORIZON_REVIEW.md).
+
+## Intake obligatoire
+
+Avant toute modification :
+
+- vérifier intégralement l’archive stable `v0.1.4` et le rapport post-tag réellement fourni ;
+- relire `RULES.md`, `docs/rules/200-GOVERNANCE.md`, `210-WORKFLOW.md`, `220-SKELETONS.md`, `230-ADOPTION.md` et `400-VALIDATION.md` ;
+- relire `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`, `docs/templates/003-NEW_SESSION_PROMPT.md` et `007-EXISTING_PROJECT_ADOPTION.md` ;
+- relire la revue d’horizon `004-V0_1_4_HORIZON_REVIEW.md` et le plan historique `010-V0_1_4_TAURI_REEVALUATION_PLAN.md` ;
+- vérifier les deltas/histories `0.1.4`, notamment le `FAIL` explicite de `alpha.2` et son `alpha.2.fix.1 PASS`, sans réécrire cette histoire ;
+- vérifier que la première tranche préparée est bien `0.1.5-alpha.1`.
+
+## Contrat normatif à établir
+
+Le travail doit converger vers les propriétés suivantes sans supposer leur rédaction finale :
+
+```text
+MUST / MUST NOT       obligation ou interdiction normative
+SHOULD / SHOULD NOT   forte recommandation non obligatoire
+MAY                   possibilité neutre
+```
+
+Un écart à un `SHOULD` ne doit pas, à lui seul, provoquer un échec de gate ni exiger un `OVERRIDE`. Une justification locale peut rester utile lorsqu’elle apporte une valeur durable, mais elle ne transforme pas la recommandation en obligation.
+
+## Contrat d’autonomie à établir
+
+L’utilisation de PGR est ponctuelle : sélection d’un snapshot, instanciation/adoption, adaptation, puis établissement d’une baseline locale autonome.
+
+Les sessions/releases ultérieures d’un projet destinataire doivent partir de ses propres règles, plans, architecture et historiques. Elles ne doivent ni rechercher automatiquement « la dernière version de PGR », ni traiter PGR comme un upstream à suivre.
+
+Un réalignement futur avec PGR reste possible uniquement comme scope explicite utilisant un snapshot PGR choisi et une nouvelle comparaison des écarts.
+
+## Frontière avec SaseDev Knowledge
+
+PGR doit rester auto-suffisant pour comprendre ses exigences. `0.1.5` doit formaliser une frontière entre :
+
+- contrats normatifs, owners, skeleton specifications minimales et validations directement liées aux règles, qui restent dans PGR ;
+- howtos, recettes, snippets, exemples pratiques, dépannage et variantes d’implémentation, qui deviennent candidats à Knowledge.
+
+Ne pas déplacer automatiquement du contenu vers SaseDev Knowledge. Si un corpus Knowledge autoritaire est explicitement fourni pendant la session, il MAY servir à vérifier la frontière ou préparer une migration future ; son absence ne bloque pas `0.1.5`.
+
+## Hors scope
+
+`0.1.5` ne doit pas :
+
+- commencer l’adoption de `sasedev-games`, désormais réservée à `0.1.6` ;
+- commencer l’adoption de `khadhroony-solana-project`, désormais réservée à `0.1.7` ;
+- commencer les audits Rust/Clippy read-only, désormais réservés à `0.1.8` ;
+- rouvrir le domaine Tauri `0.1.4` sans défaut transversal réellement démontré ;
+- convertir tous les `SHOULD` existants en `MUST` ou `MAY` mécaniquement ;
+- rendre PGR dépendant de SaseDev Knowledge pour interpréter une règle.
+
+## Première tranche attendue
+
+`0.1.5-alpha.1` doit commencer par un audit transversal des formulations et artefacts concernés, classifier les ambiguïtés réelles, créer/consolider le plan de release et proposer les owners exacts à modifier. Elle ne doit pas réécrire massivement les règles avant cet inventaire.
+
+La validation doit rester proportionnée et inclure au minimum les tests/audits PGR applicables, l’audit d’hygiène texte et des contrôles structurels prouvant que les adoptions Games/KSP n’ont pas été commencées prématurément.

prompts/012-V0_1_6_START_PROMPT.md

@@ -0,0 +1,87 @@
+<!-- file: prompts/012-V0_1_6_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Prompt de démarrage 0.1.6 — adoption réelle de PGR par sasedev-games
+
+## Baselines et cible
+
+Dépôt canonique PGR : `https://git.sasedev.com/Sasedev/pgr`.
+
+La baseline PGR attendue au démarrage effectif de `0.1.6` est l’archive source téléchargée depuis le tag Gitea `v0.1.5`, accompagnée du rapport post-tag `pgr-0.1.5-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`.
+
+La session doit également recevoir une archive récente et explicitement autoritaire de `sasedev-games`. Le présent prompt ne fixe volontairement aucun numéro Games : utiliser la baseline réellement fournie et ne pas reconstruire une version depuis d’anciens documents PGR.
+
+Version cible PGR : `0.1.6`. Première tranche attendue : `0.1.6-alpha.1`.
+
+Une archive source de tag peut légitimement ne pas contenir `.git`. Ne pas lui attribuer une preuve Git qu’elle ne peut contenir.
+
+## Mission
+
+Exercer réellement le modèle d’adoption PGR contre `sasedev-games`, sans transformer PGR en upstream permanent du projet et sans généraliser les décisions propres à Games.
+
+L’objectif est de produire une cartographie explicite `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A`, puis de matérialiser uniquement les changements réellement justifiés dans la baseline locale Games.
+
+La décision de trajectoire autoritaire est enregistrée dans [`../docs/studies/005-V0_1_5_HORIZON_REVIEW.md`](../docs/studies/005-V0_1_5_HORIZON_REVIEW.md).
+
+## Intake obligatoire
+
+Avant toute modification :
+
+- vérifier intégralement la stable PGR `v0.1.5` et le rapport post-tag réellement fourni ;
+- vérifier intégralement l’archive Games fournie et identifier sa version/baseline autoritaire réelle ;
+- relire `RULES.md`, `docs/rules/200-GOVERNANCE.md`, `210-WORKFLOW.md`, `220-SKELETONS.md`, `230-ADOPTION.md`, `300-DOCUMENTATION.md` et `400-VALIDATION.md` ;
+- relire `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`, `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` et les profils techniques réellement applicables au corpus Games observé ;
+- relire le plan historique `011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` et la revue d’horizon `005-V0_1_5_HORIZON_REVIEW.md` ;
+- vérifier les deltas/histories `0.1.5` sans réécrire la vérité opérateur, notamment `alpha.1 PARTIAL` puis `alpha.1.fix.1 PASS` ;
+- vérifier que la première tranche préparée est bien `0.1.6-alpha.1`.
+
+## Contrat d’adoption
+
+L’audit doit classifier chaque écart réellement pertinent :
+
+```text
+ADOPT        règle/artefact PGR retenu pour la baseline locale Games
+KEEP-LOCAL   décision Games existante conservée comme autorité locale
+OVERRIDE     contradiction réelle et documentée avec un MUST PGR applicable
+DEFER        sujet potentiellement applicable mais non justifié dans le scope courant
+N/A          owner/profil non applicable au corpus Games observé
+```
+
+Un écart à un `SHOULD / SHOULD NOT` ne crée pas à lui seul un `OVERRIDE` et ne doit pas être traité comme une non-conformité.
+
+Ne pas forcer l’adoption d’un profil uniquement parce qu’il existe dans PGR. L’applicabilité doit être démontrée par la baseline Games réellement fournie.
+
+## Autorité locale après adoption
+
+PGR sert de snapshot de comparaison et d’adoption. Une fois la baseline locale Games établie, cette baseline et ses owners deviennent l’autorité des sessions/releases suivantes de `sasedev-games`.
+
+Les sessions Games ultérieures ne doivent pas rechercher automatiquement « la dernière version de PGR » ni traiter PGR comme un upstream documentaire permanent.
+
+Un futur réalignement reste possible uniquement comme opération explicitement décidée à partir d’un snapshot PGR précis.
+
+## Préservation du contexte Games
+
+Les décisions produit, architectures métier, POCs et contraintes propres à Games restent locales lorsqu’elles ne relèvent pas d’un contrat PGR générique.
+
+Ne pas promouvoir automatiquement un ancien POC, une technologie historique ou un artefact expérimental au rang de surface produit/applicable. La baseline Games fournie doit démontrer son rôle courant.
+
+Ne pas supprimer ou réécrire une décision locale uniquement pour obtenir une symétrie avec PGR.
+
+## Hors scope
+
+`0.1.6` ne doit pas :
+
+- commencer l’adoption de `khadhroony-solana-project`, réservée à `0.1.7` ;
+- commencer les audits Rust/Clippy read-only, réservés à `0.1.8` ;
+- rouvrir les contrats transversaux de `0.1.5` sans contradiction réelle démontrée par l’adoption Games ;
+- rendre Games dépendant de PGR ou de SaseDev Knowledge ;
+- généraliser dans PGR des choix Games uniquement parce qu’ils sont présents dans le corpus ;
+- fabriquer un corpus, une version Games ou une preuve runtime absente de l’archive fournie.
+
+## Première tranche attendue
+
+`0.1.6-alpha.1` doit être une tranche d’intake et de cartographie : vérifier les deux baselines, inventorier les surfaces Games réelles, déterminer les profils PGR applicables, produire la classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A`, proposer le plan de release et identifier les owners exacts à modifier.
+
+Elle ne doit pas effectuer une migration massive avant cette cartographie.
+
+La validation doit rester proportionnée au corpus Games réellement applicable et conserver séparées les preuves PGR, les preuves Games et les décisions d’adoption.

scripts/audit_text_hygiene.py

@@ -0,0 +1,136 @@
+#!/usr/bin/env python3
+# file: scripts/audit_text_hygiene.py
+# version: 1
+
+"""Validate mechanical hygiene of selected governed text files."""
+
+from __future__ import annotations
+
+import argparse
+import pathlib
+import sys
+
+_IGNORED_DIRECTORIES = frozenset({".git", ".idea", ".venv", "__pycache__", "dist", "node_modules", "target"})
+_TEXT_SUFFIXES = frozenset(
+    {
+        ".cfg",
+        ".conf",
+        ".css",
+        ".gradle",
+        ".html",
+        ".ini",
+        ".js",
+        ".json",
+        ".jsx",
+        ".kts",
+        ".md",
+        ".prefs",
+        ".properties",
+        ".py",
+        ".rs",
+        ".scss",
+        ".sh",
+        ".toml",
+        ".ts",
+        ".tsx",
+        ".txt",
+        ".xml",
+        ".yaml",
+        ".yml",
+    }
+)
+_TEXT_NAMES = frozenset({".gitignore", "VERSION"})
+
+
+def _is_governed_text(path: pathlib.Path) -> bool:
+    return path.name in _TEXT_NAMES or path.suffix.lower() in _TEXT_SUFFIXES
+
+
+def _selected_files(raw_paths: list[str], root: pathlib.Path) -> tuple[list[pathlib.Path], list[str]]:
+    files: set[pathlib.Path] = set()
+    errors: list[str] = []
+
+    for raw_path in raw_paths:
+        path = pathlib.Path(raw_path)
+        if path.is_dir() or path.is_file():
+            if not path.resolve().is_relative_to(root):
+                errors.append(f"Text hygiene audit: path outside project root: {path}")
+                continue
+        if path.is_dir():
+            candidates = (
+                candidate
+                for candidate in path.rglob("*")
+                if candidate.is_file()
+                and _is_governed_text(candidate)
+                and not any(part in _IGNORED_DIRECTORIES for part in candidate.parts)
+            )
+        elif path.is_file() and _is_governed_text(path):
+            candidates = iter((path,))
+        else:
+            errors.append(f"Text hygiene audit: unsupported or missing path: {path}")
+            continue
+
+        for candidate in candidates:
+            canonical = candidate.resolve()
+            if not canonical.is_relative_to(root):
+                errors.append(f"Text hygiene audit: path outside project root: {candidate}")
+            else:
+                files.add(canonical)
+
+    return sorted(files), errors
+
+
+def _audit_file(path: pathlib.Path, root: pathlib.Path) -> list[str]:
+    relative = path.relative_to(root).as_posix()
+    data = path.read_bytes()
+    errors: list[str] = []
+
+    if b"\r" in data:
+        errors.append(f"{relative}: CR byte found; governed text must use LF line endings")
+
+    if not data.endswith(b"\n"):
+        errors.append(f"{relative}: EOF: missing final LF")
+    elif data.endswith(b"\n\n"):
+        errors.append(f"{relative}: EOF: extra blank line; exactly one final LF is required")
+
+    for line_number, line in enumerate(data.split(b"\n")[:-1], start=1):
+        if line.endswith((b" ", b"\t")):
+            errors.append(f"{relative}:{line_number}: trailing whitespace")
+
+    return errors
+
+
+def main() -> int:
+    """Run the read-only text hygiene audit from the project root."""
+
+    parser = argparse.ArgumentParser(description=__doc__)
+    parser.add_argument("paths", nargs="+", help="Governed text files or directories to audit")
+    args = parser.parse_args()
+
+    root = pathlib.Path.cwd().resolve()
+    files, selection_errors = _selected_files(args.paths, root)
+    if selection_errors or not files:
+        for error in selection_errors or ["Text hygiene audit: no governed text files selected"]:
+            print(error, file=sys.stderr)
+        return 2
+
+    errors: list[str] = []
+    for path in files:
+        try:
+            errors.extend(_audit_file(path, root))
+        except OSError as error:
+            print(f"Text hygiene audit: cannot read {path}: {error}", file=sys.stderr)
+            return 2
+
+    for error in errors:
+        print(error, file=sys.stderr)
+    if errors:
+        print(f"Text hygiene audit: {len(errors)} error(s) across {len(files)} file(s)", file=sys.stderr)
+        return 1
+
+    print(f"Text hygiene audit: clean ({len(files)} file(s))")
+    return 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())

tests/test_text_hygiene.py

@@ -0,0 +1,83 @@
+# file: tests/test_text_hygiene.py
+# version: 1
+
+"""Exercise the governed text hygiene audit's real file and CLI contracts."""
+
+from __future__ import annotations
+
+import pathlib
+import subprocess
+import sys
+import tempfile
+import unittest
+
+_SCRIPT = pathlib.Path(__file__).resolve().parents[1] / "scripts/audit_text_hygiene.py"
+
+
+class TextHygieneAuditTests(unittest.TestCase):
+    def setUp(self) -> None:
+        temporary = tempfile.TemporaryDirectory(prefix="pgr-text-hygiene-")
+        self.addCleanup(temporary.cleanup)
+        self.root = pathlib.Path(temporary.name)
+
+    def source(self, name: str, contents: bytes) -> pathlib.Path:
+        path = self.root / name
+        path.parent.mkdir(parents=True, exist_ok=True)
+        path.write_bytes(contents)
+        return path
+
+    def run_audit(self, *paths: str) -> subprocess.CompletedProcess[str]:
+        return subprocess.run(
+            [sys.executable, "-B", str(_SCRIPT), *paths],
+            cwd=self.root,
+            capture_output=True,
+            text=True,
+            check=False,
+        )
+
+    def test_exactly_one_final_lf_is_clean(self) -> None:
+        self.source("README.md", b"line one\nline two\n")
+        result = self.run_audit("README.md")
+        self.assertEqual(result.returncode, 0, result.stderr)
+        self.assertIn("clean (1 file(s))", result.stdout)
+
+    def test_extra_blank_line_at_eof_is_rejected(self) -> None:
+        self.source("docs/page.md", b"content\n\n")
+        result = self.run_audit("docs/page.md")
+        self.assertEqual(result.returncode, 1)
+        self.assertIn("extra blank line", result.stderr)
+
+    def test_missing_final_lf_is_rejected(self) -> None:
+        self.source("VERSION", b"1.2.3")
+        result = self.run_audit("VERSION")
+        self.assertEqual(result.returncode, 1)
+        self.assertIn("missing final LF", result.stderr)
+
+    def test_crlf_is_rejected(self) -> None:
+        self.source("config.toml", b"value = true\r\n")
+        result = self.run_audit("config.toml")
+        self.assertEqual(result.returncode, 1)
+        self.assertIn("CR byte found", result.stderr)
+
+    def test_trailing_space_and_tab_are_rejected(self) -> None:
+        self.source("docs/page.md", b"first \nsecond\t\n")
+        result = self.run_audit("docs/page.md")
+        self.assertEqual(result.returncode, 1)
+        self.assertIn("docs/page.md:1: trailing whitespace", result.stderr)
+        self.assertIn("docs/page.md:2: trailing whitespace", result.stderr)
+
+    def test_generated_directory_is_skipped(self) -> None:
+        self.source("docs/visible.md", b"clean\n")
+        self.source("docs/target/generated.md", b"bad\n\n")
+        result = self.run_audit("docs")
+        self.assertEqual(result.returncode, 0, result.stderr)
+        self.assertIn("clean (1 file(s))", result.stdout)
+
+    def test_missing_path_is_a_selection_error(self) -> None:
+        result = self.run_audit("missing.md")
+        self.assertEqual(result.returncode, 2)
+        self.assertIn("unsupported or missing path", result.stderr)
+
+
+if __name__ == "__main__":
+    unittest.main()