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

28
ROADMAP.md
View File

@@ -1,5 +1,5 @@
<!-- file: ROADMAP.md --> <!-- file: ROADMAP.md -->
<!-- version: 8 --> <!-- version: 9 -->
# Roadmap Project Governance Rules # Roadmap Project Governance Rules
@@ -17,18 +17,30 @@ Statuts : `( )` planifié, `(x)` terminé, `(d)` différé, `(c)` annulé.
## Première baseline réutilisable ## Première baseline réutilisable
- `( ) 0.1.0` — première baseline PGR destinée à initialiser de nouveaux projets à partir de règles, templates et skeleton specifications éprouvés. - `( ) 0.1.0` — première baseline PGR destinée à initialiser de nouveaux projets et à adopter progressivement des projets existants à partir de règles, templates, skeleton specifications et validations éprouvés.
## Horizon après `0.1.0` ## Trajectoire engagée `0.1.x`
L'horizon est volontairement ouvert. PGR ne réserve pas encore `0.1.1`, `0.2.0` ou une autre release sans objectif suffisamment décidé. La revue d'horizon de `0.1.0-beta.1` engage les releases suivantes, chacune avec un domaine cohérent et une session/release indépendante :
### Trajectoire explicitement différée - `( ) 0.1.1` — fondation frontend Web : TypeScript, Vite, Sass/CSS, package/build outputs et validation frontend indépendante ;
- `( ) 0.1.2` — réévaluation pratique du profil Java/Maven/Gradle existant et matérialisation des artefacts génériques réellement nécessaires ;
- `( ) 0.1.3` — réévaluation pratique du profil Android existant à partir de Games, sans absorber les décisions propres aux jeux ou à SDL ;
- `( ) 0.1.4` — domaine Tauri : réexamen du `DEFER` et matérialisation du skeleton contrôlé seulement si les owners Web issus de `0.1.1` satisfont réellement les conditions de sortie ;
- `( ) 0.1.5` — adoption réelle de PGR par `sasedev-games` avec mapping `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
- `( ) 0.1.6` — adoption réelle de PGR par `khadhroony-solana-project`, principalement sur Rust/Cargo + Tauri et sans dépendance aux profils non applicables ;
- `( ) 0.1.7` — audits Python read-only d'un sous-ensemble statique des conventions Rust/Clippy, après les deux adoptions, sans prétendre remplacer `cargo clippy`.
- `(d) skeleton Tauri pour projets contrôlés` — la décision `0.0.5-alpha.9` conserve le candidat, mais sa matérialisation attend des owners Web suffisants pour TypeScript, Vite, Sass/CSS et leur validation. Aucun numéro de release n'est réservé pour ce travail et `0.1.0` ne doit pas le considérer comme obligatoire par défaut. Le détail et les conditions de cette séquence sont conservés dans [`docs/studies/003-V0_1_0_HORIZON_REVIEW.md`](docs/studies/003-V0_1_0_HORIZON_REVIEW.md).
Cette entrée conserve une décision de report réelle ; elle ne transforme pas les autres candidats d'horizon en engagements. Les profils techniques supplémentaires, les projets documentaires/spécifications et l'audit de généricité hors logiciel restent chez leurs owners actuels tant qu'une revue d'horizon n'a pas décidé leur entrée dans la trajectoire engagée. ## Trajectoires différées ou non numérotées
Le plan de `0.1.0` devra programmer une revue d'horizon avant sa clôture, à un moment où la première baseline réutilisable sera assez établie pour juger la suite. Cette revue pourra se tenir dans une session stratégique séparée sans modifier `VERSION`. Elle décidera soit d'étendre la présente roadmap, soit de maintenir explicitement l'horizon ouvert avec un nouveau déclencheur de revue, soit de requalifier/différer/mettre en pause une trajectoire concernée. - `(d) skeleton Tauri avant owners Web suffisants` — la décision `0.0.5-alpha.9` reste vraie pendant `0.1.0`; `0.1.4` réexaminera cette décision après `0.1.1` et ne doit pas fabriquer un skeleton incomplet ;
- `WASM` — candidat séparé à réévaluer pendant l'adoption Games si un owner PGR apporte une valeur immédiate ;
- `serveur Web Rust / Actix Web ou alternative` — candidat à partir d'un corpus d'implémentation réel, pas sur la seule base d'une trajectoire roadmap ;
- `saselang-bible`, projets documentaires/spécifications et généricité hors logiciel — candidats d'une trajectoire ultérieure `0.2.x` / `0.3.x` à décider ;
- `deployment & operations` — famille future pour reverse proxies, bases de données, Docker/Compose, services Linux, secrets, migrations/backups, health et observabilité ; un horizon `0.4.x` ou `0.5.x` est plausible mais aucun numéro précis n'est réservé.
Une nouvelle revue d'horizon doit intervenir si un prérequis réel invalide l'ordre engagé, notamment si `0.1.1` doit être scindée, si `0.1.4` ne peut pas lever le `DEFER` Tauri ou si Games exige un owner WASM/serveur avant une adoption proportionnée.
Le contenu détaillé et le nombre de tranches de chaque release sont définis par son plan actif, créé ou consolidé pendant `alpha.1`. Le contenu détaillé et le nombre de tranches de chaque release sont définis par son plan actif, créé ou consolidé pendant `alpha.1`.

2
VERSION
View File

@@ -1 +1 @@
0.1.0-alpha.5 0.1.0-beta.1

237
deltas/0.1.0/beta.1.md Normal file
View File

@@ -0,0 +1,237 @@
<!-- file: deltas/0.1.0/beta.1.md -->
<!-- version: 1 -->
# Delta 0.1.0-beta.1 — réconciliation finale et revue d'horizon
## Baseline et version
Baseline attendue : commit opérateur de `0.1.0-alpha.5`, réalisé après application de `history/0.1.0/alpha.5.md` avec statut `PASS`.
Le hash de ce commit n'est pas anticipé.
Version avant application :
```text
0.1.0-alpha.5
```
Version après application :
```text
0.1.0-beta.1
```
## Objet
Fermer la phase alpha de `0.1.0` en réconciliant la baseline réellement validée et en exécutant la revue d'horizon obligatoire avant RC.
La tranche :
- enregistre le `PASS` de `alpha.5` dans le plan actif ;
- matérialise `003-V0_1_0_HORIZON_REVIEW.md` ;
- engage dans `ROADMAP.md` uniquement les prochaines releases `0.1.x` suffisamment décidées ;
- conserve WASM, serveur Rust et deployment/operations sans réservation prématurée ;
- prépare `007-V0_1_1_START_PROMPT.md` pour la prochaine cible Web, sans l'activer avant publication de `v0.1.0`.
Aucun profil technique, template Rust/Cargo, skeleton ou script d'audit n'est modifié dans `beta.1`.
## Scope
REPLACE :
```text
VERSION
ROADMAP.md
docs/000-README.md
docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
docs/studies/000-README.md
```
ADD :
```text
deltas/0.1.0/beta.1.md
docs/studies/003-V0_1_0_HORIZON_REVIEW.md
prompts/007-V0_1_1_START_PROMPT.md
```
DELETE : aucun.
`README.md`, `RULES.md`, `CHANGELOG.md`, les profils, skeletons, templates techniques et scripts restent inchangés.
## Décision de revue d'horizon
Les releases suivantes sont engagées :
```text
0.1.1 fondation frontend Web
0.1.2 réévaluation Java / Gradle
0.1.3 réévaluation Android
0.1.4 domaine Tauri et levée conditionnelle du DEFER
0.1.5 adoption Games
0.1.6 adoption KSP
0.1.7 audits Rust/Clippy statiques Python-only
```
Cette séquence applique le principe « une release/session par domaine cohérent » et conserve Games avant KSP.
`0.1.4` n'autorise pas par avance le skeleton Tauri : la release doit d'abord vérifier que `0.1.1` a réellement fourni les owners Web nécessaires.
WASM et serveur Rust/Actix ou alternative restent non numérotés. Le futur domaine deployment/operations reste un horizon majeur possible, notamment `0.4.x` ou `0.5.x`, sans réservation précise.
## Prochaine cible
Après stable `v0.1.0` et `publish.* PASS`, la prochaine cible engagée est :
```text
0.1.1 — fondation frontend Web
```
Le prompt `prompts/007-V0_1_1_START_PROMPT.md` demande un audit indépendant de la stable et du corpus Games réellement fourni. Il ne migre pas Games et ne crée ni Tauri, ni WASM, ni serveur Rust.
## Validation opérateur
Après application du history `PASS`, commit/push de `alpha.5`, puis application du présent delta :
```bash
test "$(cat VERSION)" = '0.1.0-beta.1'
git cat-file -e HEAD:history/0.1.0/alpha.5.md
test -f history/0.1.0/alpha.5.md
test -f deltas/0.1.0/beta.1.md
test -f docs/studies/003-V0_1_0_HORIZON_REVIEW.md
test -f prompts/007-V0_1_1_START_PROMPT.md
test ! -e history/0.1.0/beta.1.md
grep -A2 '^## Statut$' history/0.1.0/alpha.5.md | grep -Fx 'PASS'
grep -Fx '<!-- version: 9 -->' ROADMAP.md
grep -Fx '<!-- version: 22 -->' docs/000-README.md
grep -Fx '<!-- version: 8 -->' docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
grep -Fx '<!-- version: 3 -->' docs/studies/000-README.md
grep -Fx '<!-- version: 1 -->' docs/studies/003-V0_1_0_HORIZON_REVIEW.md
grep -Fx '<!-- version: 1 -->' prompts/007-V0_1_1_START_PROMPT.md
```
Contrôle structurel de la revue :
```bash
python3 -B - <<'PYGATE'
from pathlib import Path
import re
history = Path("history/0.1.0/alpha.5.md").read_text(encoding="utf-8")
roadmap = Path("ROADMAP.md").read_text(encoding="utf-8")
plan = Path("docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md").read_text(encoding="utf-8")
study = Path("docs/studies/003-V0_1_0_HORIZON_REVIEW.md").read_text(encoding="utf-8")
prompt = Path("prompts/007-V0_1_1_START_PROMPT.md").read_text(encoding="utf-8")
tauri = Path("docs/studies/002-TAURI_SKELETON_DECISION.md").read_text(encoding="utf-8")
assert re.search(r"## Statut\s+PASS\s", history)
expected = {
"0.1.1": "fondation frontend Web",
"0.1.2": "Java/Maven/Gradle",
"0.1.3": "Android",
"0.1.4": "Tauri",
"0.1.5": "sasedev-games",
"0.1.6": "khadhroony-solana-project",
"0.1.7": "Rust/Clippy",
}
for version, phrase in expected.items():
assert f"- `( ) {version}`" in roadmap, version
assert phrase in roadmap, phrase
assert "- `( ) 0.1.8`" not in roadmap
assert "WASM" in roadmap
assert "serveur Web Rust / Actix Web ou alternative" in roadmap
assert "deployment & operations" in roadmap
assert "aucun numéro précis n'est réservé" in roadmap
for phrase in (
"`0.1.1` — fondation frontend Web",
"`0.1.5` — adoption de Games",
"`0.1.6` — adoption de KSP",
"`0.1.7` — audits Rust/Clippy statiques Python",
"Candidats laissés sans numéro",
"Déploiement et exploitation",
"La décision `DEFER` de `002-TAURI_SKELETON_DECISION.md` reste vraie pendant `0.1.0`.",
):
assert phrase in study, phrase
assert "Statut opérateur : **PASS**." in plan
assert "Statut opérateur : **à valider**." in plan
assert "0.1.7 audits Rust/Clippy statiques Python-only" in plan
assert "WASM, serveur Rust et deployment restent non numérotés." in plan
for phrase in (
"# Prompt de démarrage 0.1.1 — fondation frontend Web",
"games-v0.3.6.zip",
"TypeScript",
"Vite",
"Sass/CSS",
"Le skeleton Tauri reste `DEFER` pendant cette release.",
"0.1.2",
"0.1.3",
):
assert phrase in prompt, phrase
assert "DEFER" in tauri
print("0.1.0 beta.1 horizon review audit: clean (0.1.1..0.1.7 engaged, Tauri conditional, deferred domains remain unnumbered)")
PYGATE
```
Puis rejouer les preuves PGR :
```bash
python3 -B -m unittest discover -s tests -v
python3 -B scripts/audit_markdown_headers.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
python3 -B scripts/audit_markdown_tables.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
python3 -B scripts/audit_markdown_links.py \
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
git diff --check
git add VERSION ROADMAP.md docs/000-README.md \
docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md \
docs/studies/000-README.md \
docs/studies/003-V0_1_0_HORIZON_REVIEW.md \
prompts/007-V0_1_1_START_PROMPT.md \
deltas/0.1.0/beta.1.md
git diff --cached --check
git status --short
```
Le scope indexé attendu avant ajout du history de `beta.1` est exactement :
```text
M ROADMAP.md
M VERSION
A deltas/0.1.0/beta.1.md
M docs/000-README.md
M docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
M docs/studies/000-README.md
A docs/studies/003-V0_1_0_HORIZON_REVIEW.md
A prompts/007-V0_1_1_START_PROMPT.md
```
## Revue opérateur complémentaire
Confirmer que :
- la roadmap n'engage pas un catalogue exhaustif de technologies ;
- chaque release `0.1.1` à `0.1.7` possède un domaine cohérent ;
- Games reste avant KSP ;
- le skeleton Tauri n'est pas présenté comme déjà autorisé ;
- WASM et serveur Rust restent réellement sans numéro ;
- deployment/operations n'est pas artificiellement fixé à `0.4.0` ou `0.5.0` ;
- `007-V0_1_1_START_PROMPT.md` ne doit être exécuté qu'après `v0.1.0` publié et vérifié ;
- aucun profil, skeleton technique ou script d'audit n'est ajouté/modifié dans cette tranche.
## Transition
PASS : produire `history/0.1.0/beta.1.md`, fermer la tranche avec le handoff opérateur automatique, puis préparer `0.1.0-rc.1`.
FAIL : conserver le résultat réel dans le history et corriger par `beta.1.fix.N` ou REPLAN si la revue macro elle-même doit changer.

4
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md --> <!-- file: docs/000-README.md -->
<!-- version: 21 --> <!-- version: 22 -->
# Documentation PGR # 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. - [`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. - [`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. - [`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 ## 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 --> <!-- 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 # 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 ### 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 ```text
NEW instanciation temporaire réelle des templates avec Cargo NEW PASS — metadata/fmt/check/clippy sur instanciation temporaire
ADOPTION mapping non destructif d’un workspace existant 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 `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.
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.
### beta.1 — réconciliation finale et revue d'horizon ### 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 ### rc.1 — release candidate
@@ -278,15 +288,17 @@ REPLAN est requis si :
## Revue d'horizon ## 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 ; La revue complète et ses critères de réouverture sont possédés par `../studies/003-V0_1_0_HORIZON_REVIEW.md`.
- 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.

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

@@ -1,5 +1,5 @@
<!-- file: docs/studies/000-README.md --> <!-- file: docs/studies/000-README.md -->
<!-- version: 2 --> <!-- version: 3 -->
# Index des études PGR # 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`. - [`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. - [`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é.

110
history/0.1.0/beta.1.md Normal file
View File

@@ -0,0 +1,110 @@
<!-- file: history/0.1.0/beta.1.md -->
<!-- version: 1 -->
# History 0.1.0-beta.1 — réconciliation finale et revue d'horizon
## Statut
PASS
La gate opérateur de `0.1.0-beta.1` exécutée le `2026-09-26` a réussi. Elle valide la réconciliation de la baseline `0.1.0`, la revue d'horizon obligatoire, la roadmap engagée `0.1.1` à `0.1.7` et le prompt de reprise `007` vers la fondation frontend Web.
## Baseline opérateur
La tranche `0.1.0-alpha.5` a été clôturée avec son history `PASS`, puis committée et poussée avant application de `beta.1` :
```text
commit a65a183
message 0.1.0-alpha.5
push origin/master PASS
```
Après application du delta `beta.1`, les contrôles initiaux ont confirmé :
```text
VERSION 0.1.0-beta.1
history/0.1.0/alpha.5.md présent dans HEAD et le workspace
deltas/0.1.0/beta.1.md présent
docs/studies/003-V0_1_0_HORIZON_REVIEW.md présent
prompts/007-V0_1_1_START_PROMPT.md présent
history/0.1.0/beta.1.md absent pendant la gate
ROADMAP.md version 9
docs/000-README.md version 22
docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md version 8
docs/studies/000-README.md version 3
docs/studies/003-V0_1_0_HORIZON_REVIEW.md version 1
prompts/007-V0_1_1_START_PROMPT.md version 1
```
Le history `alpha.5` a été retrouvé avec statut `PASS`.
## Revue d'horizon
Le contrôle structurel a affiché :
```text
0.1.0 beta.1 horizon review audit: clean (0.1.1..0.1.7 engaged, Tauri conditional, deferred domains remain unnumbered)
```
La roadmap engage désormais, dans cet ordre :
```text
0.1.1 fondation frontend Web
0.1.2 Java / Gradle
0.1.3 Android
0.1.4 Tauri sous condition de readiness Web
0.1.5 adoption sasedev-games
0.1.6 adoption khadhroony-solana-project
0.1.7 audits Rust/Clippy statiques Python-only
```
La gate confirme simultanément qu'aucune `0.1.8` n'est réservée, que WASM et le serveur Web Rust/Actix ou alternative restent sans numéro et que le domaine `deployment & operations` demeure un horizon ultérieur sans réservation précise.
La décision `DEFER` du skeleton Tauri reste applicable pendant `0.1.0`. Le prompt `007` prépare `0.1.1` mais n'autorise ni migration Games/KSP, ni Tauri, ni WASM, ni serveur Rust dans cette release Web.
## Tests et audits PGR
La suite Python globale a exécuté `48` tests, tous réussis :
```text
Ran 48 tests in 0.762s
OK
```
Les audits documentaires sont propres :
```text
Markdown header audit: clean (193 file(s))
Markdown table audit: clean (8 table(s), 193 file(s))
Markdown link audit: clean (193 local link(s), 193 file(s))
```
## Contrôles Git
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic. Le statut indexé transmis avant ajout du présent history est exactement :
```text
M ROADMAP.md
M VERSION
A deltas/0.1.0/beta.1.md
M docs/000-README.md
M docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
M docs/studies/000-README.md
A docs/studies/003-V0_1_0_HORIZON_REVIEW.md
A prompts/007-V0_1_1_START_PROMPT.md
```
Le scope correspond exactement au delta annoncé. Aucun profil technique, template Rust/Cargo, skeleton ou script d'audit n'a été modifié par `beta.1`.
## Décision
`0.1.0-beta.1` est `PASS`. Aucun fix ni REPLAN n'est requis.
La tranche suivante est :
```text
0.1.0-rc.1
```
La RC gèle le scope, produit l'entrée candidate du `CHANGELOG`, rejoue le release gate complet applicable, vérifie le handoff opérateur et le prompt `007`, puis prépare la première promotion stable utilisant la convention `rel.1`.

77
prompts/007-V0_1_1_START_PROMPT.md Normal file
View File

@@ -0,0 +1,77 @@
<!-- file: prompts/007-V0_1_1_START_PROMPT.md -->
<!-- version: 1 -->
# Prompt de démarrage 0.1.1 — fondation frontend Web
## Baseline et cible
Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`.
La baseline attendue au démarrage effectif de `0.1.1` est l'archive source téléchargée depuis le tag Gitea `v0.1.0`, accompagnée du rapport post-tag `pgr-0.1.0-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`.
Version cible : `0.1.1`. Première tranche attendue : `0.1.1-alpha.1`.
Le corpus principal attendu pour instruire le besoin Web est une archive autoritaire récente de `sasedev-games`. Si aucune baseline plus récente n'est explicitement fournie, la baseline de référence déjà auditée reste :
```text
games-v0.3.6.zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
```
Une archive source peut légitimement ne pas contenir `.git`. Ne pas lui attribuer une preuve Git qu'elle ne peut contenir.
## Mission
Créer la première fondation frontend Web contrôlée de PGR à partir de besoins réellement exercés, principalement dans Games, sans importer automatiquement les choix locaux du corpus.
`alpha.1` MUST commencer par :
1. auditer indépendamment la stable `v0.1.0` et son rapport post-tag lorsqu'il est fourni ;
2. auditer le corpus Games réellement fourni et identifier les responsabilités Web exercées ;
3. relire `docs/studies/003-V0_1_0_HORIZON_REVIEW.md` et `docs/studies/002-TAURI_SKELETON_DECISION.md` ;
4. créer le plan `0.1.1` avant toute normalisation importante.
## Scope de domaine attendu
La release doit instruire ensemble les responsabilités nécessaires à un frontend Web contrôlé :
- TypeScript et configuration applicable ;
- Vite, dev server et contrat de build outputs ;
- Sass/CSS, sources et artefacts générés ;
- package manager, manifest et lockfile sans imposer arbitrairement npm ;
- séparation entre validation frontend et validation du host ;
- templates, skeletons et audits read-only seulement lorsqu'ils apportent une preuve générique réelle.
La release peut créer plusieurs owners si les responsabilités l'exigent, mais reste une seule release de domaine Web frontend.
## Hors scope
`0.1.1` MUST NOT :
- créer le skeleton Tauri contrôlé ;
- intégrer WASM au host ou créer un profil WASM par simple proximité ;
- normaliser Actix Web ou un autre serveur Rust sans corpus d'implémentation suffisant ;
- migrer Games vers PGR ;
- migrer KSP vers PGR ;
- réécrire le profil Java/Gradle ou Android, qui possèdent leurs releases dédiées `0.1.2` et `0.1.3` ;
- traiter les sujets deployment/operations de l'horizon futur.
## Relation avec Tauri
Le skeleton Tauri reste `DEFER` pendant cette release. `0.1.1` doit néanmoins produire les owners Web suffisamment explicites pour que `0.1.4` puisse réexaminer objectivement les conditions de sortie de `002-TAURI_SKELETON_DECISION.md`.
La réussite de `0.1.1` ne vaut pas automatiquement levée du `DEFER` Tauri.
## Principes
- Partir des faits observés dans le corpus, pas d'un catalogue théorique du Web moderne.
- Un outil ou package manager n'est pas rendu obligatoire parce qu'il est présent dans Games.
- Les sorties générées doivent avoir un owner clair et une politique explicite de versionnement/ignorance.
- Les audits Python restent monotâches et read-only ; ils ne remplacent ni TypeScript, ni Vite, ni Sass, ni le package manager.
- Conserver la distinction `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` pour préparer l'adoption Games ultérieure.
- Ne pas réserver de nouvelles releases au-delà de la roadmap engagée sans nouvelle revue d'horizon justifiée.
## Workflow
Suivre `RULES.md`, `docs/rules/210-WORKFLOW.md`, `docs/rules/230-ADOPTION.md` et `docs/rules/400-VALIDATION.md`.
La séquence reste : delta → gate opérateur → history constaté → application du history → commit/push → delta suivant. Les commandes de handoff sont remises automatiquement conformément à `docs/templates/006-OPERATOR_COMMAND_HANDOFF.md`.