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