Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.1.4-alpha.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-29 11:33:56 +02:00
parent fe80dbbb73
commit 7f475584d6
6 changed files with 624 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 40 -->
<!-- version: 41 -->
# Documentation PGR
@@ -20,6 +20,14 @@ 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 actif du réexamen Tauri : audit des hosts Games/KSP actuels, classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, décision contrôlée sur le skeleton et séquencement jusqu'à la stable.
- [`rules/710-TAURI.md`](rules/710-TAURI.md) — owner Tauri 2 à réconcilier avec le corpus courant et la documentation officielle avant toute modification normative.
- [`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.
- [`studies/002-TAURI_SKELETON_DECISION.md`](studies/002-TAURI_SKELETON_DECISION.md) — décision historique `DEFER`, conditions de sortie et préparation `0.1.1-beta.1` réexaminées par la présente release.
- [`../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`.

318
docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md Normal file
View File

@@ -0,0 +1,318 @@
<!-- file: docs/plans/010-V0_1_4_TAURI_REEVALUATION_PLAN.md -->
<!-- version: 1 -->
# 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 :
```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.
## 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`.