pgr/docs/studies/003-V0_1_0_HORIZON_REVIEW.md

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 :

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à :

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 :

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