0.1.0-beta.1

docs/studies/000-README.md

@@ -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.

docs/studies/003-V0_1_0_HORIZON_REVIEW.md

@@ -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é.