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 actif de 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.

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, préparer le CHANGELOG.md candidate et le prompt ouvrant 0.1.5 consacré à l'adoption Games. Une revue d'horizon est effectuée avant toute réservation au-delà de 0.1.7.

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 release ne réserve aucun numéro au-delà de 0.1.7. Le CHANGELOG.md et le ROADMAP.md ne sont pas réécrits à l'ouverture alpha.1 ; ils sont mis à jour dans les phases de fermeture lorsqu'ils décrivent l'état effectivement atteint et la trajectoire confirmé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.