0.1.4

0.1.4-rc.1
0.1.4-beta.1
2026-09-29 18:11:44 +02:00 · 2026-09-29 18:01:37 +02:00 · 2026-09-29 15:07:38 +02:00 · 2026-09-29 14:00:25 +02:00 · 2026-09-29 13:36:20 +02:00 · 2026-09-29 11:45:01 +02:00
31 changed files with 3503 additions and 51 deletions
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,5 @@
 <!-- file: CHANGELOG.md -->
-<!-- version: 17 -->
+<!-- version: 19 -->
 # Changelog Project Governance Rules
@@ -7,6 +7,15 @@ 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.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 ;
--- a/README.md
+++ b/README.md
@@ -1,5 +1,5 @@
 <!-- file: README.md -->
-<!-- version: 25 -->
+<!-- version: 27 -->
 # 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, avec `0.1.2` d’owners Java, Maven et Gradle séparés et composables, et avec `0.1.3` d’un profil Android réévalué contre Games sans généraliser ses choix locaux. Les contrats SDK, identité, natif/ABI, Lint, tests, packaging et 16 KB sont désormais bornés par leur applicabilité réelle. Tauri reste réservé à `0.1.4` et l’adoption Games à `0.1.5`.
+PGR a clôturé sa phase de fondation `0.0.x` et dispose désormais d’une suite de baselines stables `0.1.x`. La stable `0.1.4` réexamine le domaine Tauri contre les corpus Games/KSP, consolide l’owner `710`, matérialise le skeleton organisationnel `004-TAURI.md`, confirme qu’aucun template technique ni contrat de validation Tauri séparé n’est justifié et ajoute un audit réutilisable d’hygiène texte. La revue d’horizon de fermeture réserve `0.1.5` à la sémantique normative, à l’autonomie des projets après adoption et à la frontière PGR / SaseDev Knowledge avant les adoptions Games `0.1.6` et KSP `0.1.7`.
-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 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.
 ## Entrées principales
@@ -33,6 +33,8 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
 - [`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/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 ;
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -1,5 +1,5 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 15 -->
+<!-- version: 17 -->
 # Roadmap Project Governance Rules
@@ -26,21 +26,21 @@ 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 ;
 - `(x) 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 ;
+- `(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 ;
- `( ) 0.1.5` — adoption réelle de PGR par `sasedev-games` avec mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
+- `( ) 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 `khadhroony-solana-project`, principalement sur Rust/Cargo + Tauri et sans dépendance aux profils non applicables ;
+- `( ) 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` — audits Python read-only d'un sous-ensemble statique des conventions Rust/Clippy, après les deux adoptions, sans prétendre remplacer `cargo clippy`.
+- `( ) 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. Une nouvelle revue d’horizon doit intervenir si `0.1.5` démontre que l’autonomie ne peut pas être stabilisée sans scope supplémentaire, ou si Games/KSP exigent un owner réellement préalable à une adoption proportionnée.
 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`.
--- a/2
+++ b/2
@@ -1 +1 @@
-0.1.3
+0.1.4
--- a/deltas/0.1.4/alpha.1.md
+++ b/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.
--- a/deltas/0.1.4/alpha.2.fix.1.md
+++ b/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`.
--- a/deltas/0.1.4/alpha.2.md
+++ b/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
 ```
--- a/deltas/0.1.4/alpha.3.md
+++ b/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.
--- a/deltas/0.1.4/beta.1.md
+++ b/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.
--- a/deltas/0.1.4/rc.1.md
+++ b/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`.
--- a/deltas/0.1.4/rel.1.md
+++ b/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`.
--- a/docs/000-README.md
+++ b/docs/000-README.md
@@ -1,5 +1,5 @@
 <!-- file: docs/000-README.md -->
-<!-- version: 40 -->
+<!-- version: 46 -->
 # Documentation PGR
@@ -20,6 +20,17 @@ 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.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`.
--- a/docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md
+++ b/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`.
--- a/docs/rules/210-WORKFLOW.md
+++ b/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.
--- a/docs/rules/710-TAURI.md
+++ b/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 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.
 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.
 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
--- a/docs/skeletons/000-README.md
+++ b/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).
+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).
 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.
 Aucun fichier placeholder ne doit être ajouté pour réserver un skeleton futur.
--- a/docs/skeletons/004-TAURI.md
+++ b/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.
--- a/docs/studies/000-README.md
+++ b/docs/studies/000-README.md
@@ -1,5 +1,5 @@
 <!-- file: docs/studies/000-README.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 # Index des études PGR
@@ -12,3 +12,4 @@ 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.
--- a/docs/studies/002-TAURI_SKELETON_DECISION.md
+++ b/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.
--- a/docs/studies/004-V0_1_4_HORIZON_REVIEW.md
+++ b/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.
--- a/docs/validation/001-VALIDATION_MATRIX.md
+++ b/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
@@ -13,20 +13,23 @@ 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          |
+| 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-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-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-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-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-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-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 |
+| `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-MD-HEADER-001` | `AUDIT`   | `python3 -B scripts/audit_markdown_headers.py <paths...>`                            | Python 3               | Markdown gouverné modifié       | alpha/beta/RC/stable | faible | opérateur/CI    |
+| `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 |
-| `PGR-MD-TABLE-001`  | `AUDIT`   | `python3 -B scripts/audit_markdown_tables.py <paths...>`                             | Python 3               | table Markdown ajoutée/modifiée | alpha/beta/RC/stable | faible | opérateur/CI    |
+| `PGR-MD-HEADER-001`    | `AUDIT`   | `python3 -B scripts/audit_markdown_headers.py <paths...>`                            | Python 3               | Markdown gouverné modifié       | alpha/beta/RC/stable | faible | opérateur/CI    |
-| `PGR-NAV-001`       | `AUDIT`   | `python3 -B scripts/audit_markdown_links.py <paths...>`                              | Python 3               | navigation ou réconciliation    | alpha/beta/RC/stable | faible | opérateur/CI    |
+| `PGR-MD-TABLE-001`     | `AUDIT`   | `python3 -B scripts/audit_markdown_tables.py <paths...>`                             | Python 3               | table Markdown ajoutée/modifiée | alpha/beta/RC/stable | faible | opérateur/CI    |
-| `PGR-SCOPE-001`     | `AUDIT`   | vérifier que les documents vivants pointent vers les propriétaires normatifs actuels | documents vivants      | réconciliation de phase         | beta/RC/stable       | faible | revue           |
+| `PGR-NAV-001`          | `AUDIT`   | `python3 -B scripts/audit_markdown_links.py <paths...>`                              | Python 3               | navigation ou réconciliation    | alpha/beta/RC/stable | faible | opérateur/CI    |
-| `PGR-STATUS-001`    | `CHECK`   | `git status --short`                                                                 | Git                    | avant fermeture d'une tranche   | alpha/beta/RC/stable | faible | opérateur       |
+| `PGR-SCOPE-001`        | `AUDIT`   | vérifier que les documents vivants pointent vers les propriétaires normatifs actuels | documents vivants      | réconciliation de phase         | beta/RC/stable       | faible | revue           |
 | `PGR-STATUS-001`       | `CHECK`   | `git status --short`                                                                 | Git                    | avant fermeture d'une tranche   | alpha/beta/RC/stable | faible | opérateur       |
 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.
--- a/history/0.1.4/alpha.1.md
+++ b/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é.
--- a/history/0.1.4/alpha.2.fix.1.md
+++ b/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.
--- a/history/0.1.4/alpha.2.md
+++ b/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`.
--- a/history/0.1.4/alpha.3.md
+++ b/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éé.
--- a/history/0.1.4/beta.1.md
+++ b/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.
--- a/history/0.1.4/rc.1.md
+++ b/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`.
--- a/history/0.1.4/rel.1.md
+++ b/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`.
--- a/prompts/011-V0_1_5_START_PROMPT.md
+++ b/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.
--- a/scripts/audit_text_hygiene.py
+++ b/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())
--- a/tests/test_text_hygiene.py
+++ b/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()
Author	SHA1	Message	Date
SinuS Von SifriduS	c41b69badf	0.1.4	2026-09-29 18:11:44 +02:00
SinuS Von SifriduS	4fc3cd5e7e	0.1.4-rc.1	2026-09-29 18:01:37 +02:00
SinuS Von SifriduS	091685af50	0.1.4-beta.1	2026-09-29 15:07:38 +02:00
SinuS Von SifriduS	e4f405ea9d	0.1.4-alpha.3	2026-09-29 14:00:25 +02:00
SinuS Von SifriduS	9b140e85b3	0.1.4-alpha.2.fix.1	2026-09-29 13:36:20 +02:00
SinuS Von SifriduS	ed794d66a0	0.1.4-alpha.2	2026-09-29 11:45:01 +02:00
SinuS Von SifriduS	7f475584d6	0.1.4-alpha.1	2026-09-29 11:33:56 +02:00