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