diff --git a/ROADMAP.md b/ROADMAP.md index ad1568c..1f0f21d 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,5 +1,5 @@ - + # Roadmap Project Governance Rules @@ -17,18 +17,30 @@ Statuts : `( )` planifié, `(x)` terminé, `(d)` différé, `(c)` annulé. ## 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`. diff --git a/VERSION b/VERSION index 8dc312c..4ab2ff6 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.1.0-alpha.5 +0.1.0-beta.1 diff --git a/deltas/0.1.0/beta.1.md b/deltas/0.1.0/beta.1.md new file mode 100644 index 0000000..06a2743 --- /dev/null +++ b/deltas/0.1.0/beta.1.md @@ -0,0 +1,237 @@ + + + +# 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 '' ROADMAP.md +grep -Fx '' docs/000-README.md +grep -Fx '' docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md +grep -Fx '' docs/studies/000-README.md +grep -Fx '' docs/studies/003-V0_1_0_HORIZON_REVIEW.md +grep -Fx '' 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. diff --git a/docs/000-README.md b/docs/000-README.md index 1b40790..31db594 100644 --- a/docs/000-README.md +++ b/docs/000-README.md @@ -1,5 +1,5 @@ - + # 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 diff --git a/docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md b/docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md index 6da1a1e..e7fa78a 100644 --- a/docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md +++ b/docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md @@ -1,5 +1,5 @@ - + # 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`. diff --git a/docs/studies/000-README.md b/docs/studies/000-README.md index 8083404..ba8dd53 100644 --- a/docs/studies/000-README.md +++ b/docs/studies/000-README.md @@ -1,5 +1,5 @@ - + # 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. diff --git a/docs/studies/003-V0_1_0_HORIZON_REVIEW.md b/docs/studies/003-V0_1_0_HORIZON_REVIEW.md new file mode 100644 index 0000000..e883c73 --- /dev/null +++ b/docs/studies/003-V0_1_0_HORIZON_REVIEW.md @@ -0,0 +1,163 @@ + + + +# 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é. diff --git a/history/0.1.0/beta.1.md b/history/0.1.0/beta.1.md new file mode 100644 index 0000000..c32f9ff --- /dev/null +++ b/history/0.1.0/beta.1.md @@ -0,0 +1,110 @@ + + + +# 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`. diff --git a/prompts/007-V0_1_1_START_PROMPT.md b/prompts/007-V0_1_1_START_PROMPT.md new file mode 100644 index 0000000..98dbba8 --- /dev/null +++ b/prompts/007-V0_1_1_START_PROMPT.md @@ -0,0 +1,77 @@ + + + +# 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`.