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

0.1.0-beta.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-26 23:10:02 +02:00
parent a65a183ee4
commit 5393257d93
9 changed files with 644 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 21 -->
<!-- version: 22 -->
# Documentation PGR
@@ -27,6 +27,8 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
- [`rules/230-ADOPTION.md`](rules/230-ADOPTION.md) — contrat d’adoption proportionnée de PGR par un projet existant sans réécriture rétroactive de son historique.
- [`templates/007-EXISTING_PROJECT_ADOPTION.md`](templates/007-EXISTING_PROJECT_ADOPTION.md) — pattern court de baseline, mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, découpage et validation d’une migration existante.
- [`validation/004-RUST_CARGO_BASELINE_DRY_RUN.md`](validation/004-RUST_CARGO_BASELINE_DRY_RUN.md) — contrat de dry-run temporaire pour vérifier la composition d’un nouveau workspace Rust/Cargo et l’adoption non destructive d’un workspace existant.
- [`studies/003-V0_1_0_HORIZON_REVIEW.md`](studies/003-V0_1_0_HORIZON_REVIEW.md) — revue d’horizon de `beta.1` engageant `0.1.1` à `0.1.7` par domaines cohérents et laissant WASM, serveur Rust et deployment sans réservation prématurée.
- [`../prompts/007-V0_1_1_START_PROMPT.md`](../prompts/007-V0_1_1_START_PROMPT.md) — prompt de reprise préparé pour la fondation frontend Web `0.1.1`, à utiliser seulement après publication et vérification post-tag de `0.1.0`.
## Points d'entrée de 0.0.5

50
docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md -->
<!-- version: 7 -->
<!-- version: 8 -->
# Plan 0.1.0 — première baseline PGR réutilisable
@@ -213,24 +213,34 @@ Games et KSP restent des futurs consommateurs : aucune migration externe ni acti
### alpha.5 — baseline réutilisable et dry-run de composition
Statut opérateur : **à valider**.
Statut opérateur : **PASS**.
Réconcilier la fondation `001`, le skeleton Rust/Cargo `002`, les templates Rust/Cargo et la validation minimale. Le contrat `004-RUST_CARGO_BASELINE_DRY_RUN.md` distingue explicitement :
La fondation `001`, le skeleton Rust/Cargo `002`, les templates Rust/Cargo et la validation minimale ont été réconciliés. Les deux chemins du contrat `004-RUST_CARGO_BASELINE_DRY_RUN.md` ont été exécutés avec Cargo :
```text
NEW instanciation temporaire réelle des templates avec Cargo
ADOPTION mapping non destructif d’un workspace existant
NEW PASS — metadata/fmt/check/clippy sur instanciation temporaire
ADOPTION PASS — workspace synthétique valide et choix KEEP-LOCAL / DEFER préservés
```
La gate doit exercer le mode `NEW` avec `cargo metadata`, `cargo fmt`, `cargo check` et `cargo clippy`, puis exercer le mode `ADOPTION` sur une baseline synthétique différente des templates et prouver que les décisions `KEEP-LOCAL` / `DEFER` ne sont pas écrasées.
Les profils Java/Android/Tauri sont classifiés mais ne reçoivent pas leurs nouveaux templates/skeletons dans cette tranche. Games et KSP ne sont pas utilisés comme fixtures du dry-run.
Les `48/48` tests PGR et les trois audits Markdown sont restés propres. Games et KSP n'ont pas été utilisés comme fixtures et aucun profil technologique supplémentaire n'a été absorbé par la tranche.
### beta.1 — réconciliation finale et revue d'horizon
Stabiliser la baseline `0.1.0`, vérifier les documents durables et effectuer la revue d'horizon obligatoire. Cette revue décidera les prochaines releases `0.1.x` à réellement inscrire dans `ROADMAP.md`, une par domaine cohérent, en privilégiant la préparation rapide de Games puis KSP.
Statut opérateur : **à valider**.
Le prompt de la prochaine version n'est créé que lorsque cette revue a effectivement fixé la cible suivante.
La revue d'horizon est matérialisée dans `003-V0_1_0_HORIZON_REVIEW.md`. Elle engage une séquence par domaines cohérents :
```text
0.1.1 Web frontend
0.1.2 Java / Gradle
0.1.3 Android
0.1.4 Tauri contrôlé, sous condition de readiness Web
0.1.5 adoption Games
0.1.6 adoption KSP
0.1.7 audits Rust/Clippy statiques Python-only
```
WASM, serveur Rust et deployment restent non numérotés. Le prompt `007-V0_1_1_START_PROMPT.md` est préparé pour la cible suivante mais ne devient exécutable qu'après publication de `v0.1.0` et vérification post-tag `PASS`.
### rc.1 — release candidate
@@ -278,15 +288,17 @@ REPLAN est requis si :
## Revue d'horizon
État : **requise**.
État : **matérialisée en `beta.1`, à valider par la gate opérateur**.
Moment : `beta.1`, après preuve de réutilisabilité et avant RC.
Décision proposée par la revue :
Sorties autorisées :
- engager `0.1.1` Web frontend ;
- engager séparément `0.1.2` Java/Gradle et `0.1.3` Android ;
- engager `0.1.4` comme release de domaine Tauri, avec obligation de reconfirmer la readiness Web avant toute matérialisation de skeleton ;
- engager `0.1.5` pour l'adoption Games puis `0.1.6` pour l'adoption KSP ;
- engager `0.1.7` pour les audits Rust/Clippy statiques Python-only après retour réel des deux adoptions ;
- conserver WASM et serveur Rust comme candidats sans numéro ;
- conserver `saselang-bible` et la généricité hors logiciel pour une trajectoire ultérieure ;
- conserver deployment/operations comme horizon majeur ultérieur sans réserver aujourd'hui `0.4.x` ou `0.5.x`.
- engager une ou plusieurs prochaines releases `0.1.x`, chacune avec un seul domaine cohérent ;
- conserver certains axes comme `DEFER` ou candidats sans numéro ;
- ordonner Games avant KSP lorsque les owners requis le permettent ;
- lever le `DEFER` Tauri uniquement si les owners Web requis existent réellement ;
- repousser WASM ou serveur Rust si leur normalisation n'apporte pas encore assez de valeur ;
- conserver `saselang-bible` et la généricité hors logiciel pour une trajectoire ultérieure sans l'inventer prématurément.
La revue complète et ses critères de réouverture sont possédés par `../studies/003-V0_1_0_HORIZON_REVIEW.md`.

3
docs/studies/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/studies/000-README.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Index des études PGR
@@ -11,3 +11,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) — étude de readiness `alpha.9` déterminant si les owners existants suffisent à matérialiser un skeleton Tauri contrôlé sans transférer au skeleton la propriété normative du frontend.
- [`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.

163
docs/studies/003-V0_1_0_HORIZON_REVIEW.md Normal file
View File

@@ -0,0 +1,163 @@
<!-- file: docs/studies/003-V0_1_0_HORIZON_REVIEW.md -->
<!-- version: 1 -->
# Revue d'horizon 0.1.0 — trajectoire d'adoption et owners techniques
## Objet
Cette étude matérialise la revue d'horizon obligatoire prévue par `0.1.0-beta.1`. Elle intervient après validation de la première baseline Rust/Cargo réutilisable et avant RC.
Elle ne cherche pas à remplir artificiellement la roadmap. Elle engage seulement les releases `0.1.x` dont le domaine, l'ordre et les prérequis sont suffisamment décidés à partir des owners PGR existants et des corpus Games/KSP déjà audités.
## État acquis à l'entrée
`0.1.0-alpha.5` a démontré deux propriétés nécessaires à une adoption réelle :
```text
NEW les templates Rust/Cargo peuvent instancier un workspace temporaire accepté par Cargo/rustfmt/Clippy
ADOPTION un workspace Rust existant peut conserver des décisions KEEP-LOCAL / DEFER sans copie destructive
```
Le contrat `230-ADOPTION.md` permet donc de migrer progressivement un dépôt réel sans attendre que PGR possède un owner pour chaque technologie rencontrée.
Les profils suivants existent déjà :
```text
510 Rust / Cargo
520 Java / Maven / Gradle
610 Android
710 Tauri 2
```
Le skeleton Tauri reste toutefois `DEFER` tant que les owners Web requis par `002-TAURI_SKELETON_DECISION.md` ne sont pas matérialisés.
## Pression des corpus
### Games
La baseline Games fournie exerce déjà plusieurs domaines distincts :
- Rust/Cargo ;
- frontend Web avec TypeScript, Vite et Sass/CSS ;
- Java/Gradle ;
- Android/JNI/SDL ;
- Tauri ;
- WASM dans certains chemins ;
- trajectoire serveur future, mais sans implémentation Actix Web autoritaire suffisante dans le corpus audité.
Games possède déjà une future release locale `0.3.7` destinée à l'alignement PGR. PGR doit donc préparer rapidement les owners réellement nécessaires sans absorber tout le dépôt Games dans une seule release PGR.
### KSP
KSP exerce principalement Rust/Cargo et plusieurs applications Tauri. Son adoption ne doit pas attendre Java, Android, WASM ou un profil serveur qui ne lui sont pas nécessaires.
L'ordre retenu reste Games avant KSP, afin que la première adoption large fournisse un retour d'expérience avant la migration du second corpus.
## Releases `0.1.x` engagées
### `0.1.1` — fondation frontend Web
Domaine : Web frontend contrôlé.
Scope attendu :
- owner(s) TypeScript applicables ;
- Vite et contrat dev/build outputs ;
- Sass/CSS et statut des artefacts générés ;
- package manager et lockfile classifiés sans imposer arbitrairement npm ;
- validation frontend indépendante du host Tauri ;
- templates/skeletons/audits uniquement lorsqu'un besoin réutilisable est démontré.
Games est le corpus principal. Cette release ne crée pas le skeleton Tauri, n'intègre pas WASM et ne normalise pas encore un serveur Rust.
### `0.1.2` — réévaluation Java / Gradle
Domaine : Java et build Gradle génériques.
Le profil `520-JAVA_MAVEN_GRADLE.md` existe déjà. La release doit le confronter à Games, séparer ce qui appartient à Java/Gradle de ce qui appartient à Android, puis créer uniquement les templates, validations ou audits génériques manquants.
### `0.1.3` — réévaluation Android
Domaine : Android.
Le profil `610-ANDROID.md` existe déjà. La release doit l'éprouver sur le corpus Games, notamment autour du projet Gradle Android, des wrappers Java/JNI, des ressources et du packaging, sans transférer dans PGR les choix propres à un jeu ou à SDL lorsqu'ils ne sont pas génériques.
### `0.1.4` — Tauri contrôlé
Domaine : Tauri.
Cette release réexamine formellement le `DEFER` actuel après `0.1.1`. Le skeleton Tauri contrôlé n'est matérialisé que si les conditions de sortie de `002-TAURI_SKELETON_DECISION.md` sont réellement satisfaites par les owners Web alors disponibles.
Si ces conditions ne sont pas satisfaites, la release conserve explicitement le `DEFER` et REPLAN la suite au lieu de fabriquer un skeleton incomplet.
### `0.1.5` — adoption de Games
Domaine : adoption réelle de `sasedev-games`.
Utiliser `230-ADOPTION.md` et `007-EXISTING_PROJECT_ADOPTION.md` pour établir la baseline autoritaire, mapper les owners PGR applicables et découper la migration. Les domaines non encore possédés par PGR peuvent rester `KEEP-LOCAL` ou `DEFER` ; l'adoption ne doit pas créer une obligation de normaliser WASM ou le serveur uniquement pour obtenir un statut global artificiel.
### `0.1.6` — adoption de KSP
Domaine : adoption réelle de `khadhroony-solana-project`.
La pression principale attendue est Rust/Cargo + Tauri. La migration réutilise le retour d'expérience de Games et ne doit pas attendre les profils Java/Android/WASM/serveur non applicables.
### `0.1.7` — audits Rust/Clippy statiques Python
Domaine : prévalidation Rust dans un environnement Python-only.
Cette release reste volontairement après les deux adoptions afin de dériver les contrôles de conventions réellement utiles observés dans PGR, Games et KSP.
Les scripts :
- sont read-only et non interactifs ;
- fonctionnent sans Cargo ni `rustc` ;
- réutilisent les options Rust/Clippy possédées par PGR au lieu d'inventer une politique parallèle ;
- documentent chaque contrôle comme `FULL`, `LIMITED` ou `UNSUPPORTED` ;
- ne présentent jamais un `PASS` Python comme équivalent à `cargo clippy PASS`.
## Candidats laissés sans numéro
### WASM
Le corpus Games exerce WASM, mais la valeur d'un owner PGR séparé doit être confirmée pendant `0.1.5`. Aucun numéro n'est réservé maintenant.
### Serveur Web Rust
Actix Web ou une alternative reste un candidat à partir d'un corpus d'implémentation réel. La présence d'une trajectoire HTTP/3/WebTransport dans un roadmap projet ne suffit pas à normaliser aujourd'hui un framework serveur.
### Projets documentaires et généricité hors logiciel
`saselang-bible` reste un bon corpus futur pour tester PGR sur un projet documentaire/spécification. Cet axe, ainsi que la généricité hors logiciel, reste orienté vers une trajectoire `0.2.x` / `0.3.x` à décider ultérieurement.
### Déploiement et exploitation
Une future famille majeure devra traiter de manière composable les responsabilités de déploiement et d'exploitation : reverse proxy Nginx/Apache, PostgreSQL/MySQL ou autres bases, Docker/Compose, services Linux, environnements/secrets, migrations, backup/restore, health, observabilité et skeletons/audits de déploiement.
Un horizon `0.4.x` ou `0.5.x` est plausible, mais aucun numéro précis n'est réservé tant que les séries intermédiaires n'ont pas déterminé le découpage réel.
## Décision sur Tauri
La décision `DEFER` de `002-TAURI_SKELETON_DECISION.md` reste vraie pendant `0.1.0`.
La roadmap engage `0.1.4` comme release de domaine Tauri, pas comme autorisation anticipée de créer le skeleton. Son premier devoir sera de vérifier que `0.1.1` a effectivement fourni les owners Web nécessaires.
## Prochaine cible
La prochaine release PGR après publication de `0.1.0` est :
```text
0.1.1 — fondation frontend Web
```
Le prompt `prompts/007-V0_1_1_START_PROMPT.md` est donc préparé pendant `beta.1`, mais ne doit être exécuté qu'après stable `v0.1.0` et vérification post-tag `PASS`.
## Critère de réouverture de la revue
Une nouvelle revue macro est requise si :
- `0.1.1` révèle que le domaine Web doit être scindé avant de pouvoir servir Tauri ;
- Games ne peut pas être adopté avec `KEEP-LOCAL` / `DEFER` sans owner WASM ou serveur supplémentaire ;
- `0.1.4` ne peut pas lever le `DEFER` Tauri ;
- l'ordre Games puis KSP cesse d'être rationnel à cause d'une dépendance technique nouvellement démontrée ;
- une release engagée perd son besoin réel ou doit être remplacée par une autre responsabilité.