pgr/docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md

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 :

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 :

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 :

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 :

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 :

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 :

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 :

crates/apps/game-snake-poc-tauri

KSP 0.3.19 possède six hosts Tauri courants :

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 :

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 :

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 :

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 :

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 :

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 :

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.