Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.0.5-beta.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-25 18:07:50 +02:00
parent 5a83968813
commit c97ca5f21a
9 changed files with 420 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@@ -1,5 +1,5 @@
<!-- file: README.md --> <!-- file: README.md -->
<!-- version: 12 --> <!-- version: 13 -->
# Project Governance Rules # Project Governance Rules
@@ -13,7 +13,7 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`.
PGR est actuellement en phase de fondation `0.0.x`. PGR est actuellement en phase de fondation `0.0.x`.
La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` établit la gouvernance normative et documentaire de PGR lui-même. La release `0.0.2` ajoute les premiers profils réutilisables Rust/Cargo, Java/Maven/Gradle et Android, ainsi que deux audits Markdown. La release `0.0.3` fournit les premiers modèles Rust/Cargo, deux audits de style Rust facultatifs, l'audit des headers Markdown et la spécification du message manuel de reprise. La release `0.0.4` définit le contrat transversal des skeleton specifications, ajoute une fondation composable de gouvernance locale et une première spécialisation Rust/Cargo workspace fondée sur les profils `500 + 510` et les cinq templates existants. La release `0.0.5` est en cours de réconciliation explicite avec les baselines réelles de `khadhroony-solana-project` et `sasedev-games` afin de distinguer les besoins communs réutilisables des conventions qui doivent rester locales. La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` établit la gouvernance normative et documentaire de PGR lui-même. La release `0.0.2` ajoute les premiers profils réutilisables Rust/Cargo, Java/Maven/Gradle et Android, ainsi que deux audits Markdown. La release `0.0.3` fournit les premiers modèles Rust/Cargo, deux audits de style Rust facultatifs, l'audit des headers Markdown et la spécification du message manuel de reprise. La release `0.0.4` définit le contrat transversal des skeleton specifications, ajoute une fondation composable de gouvernance locale et une première spécialisation Rust/Cargo workspace fondée sur les profils `500 + 510` et les cinq templates existants. La release `0.0.5` réconcilie PGR avec les baselines réelles de `khadhroony-solana-project` et `sasedev-games` : prompts versionnés, contrats documentaires locaux, lifecycle inter-release, profil Rust strict et audits monotâches, premier profil Tauri 2 et décision explicite de différer son skeleton complet jusqu'à matérialisation d'owners Web suffisants.
## Entrées principales ## Entrées principales

10
ROADMAP.md
View File

@@ -1,5 +1,5 @@
<!-- file: ROADMAP.md --> <!-- file: ROADMAP.md -->
<!-- version: 6 --> <!-- version: 7 -->
# Roadmap Project Governance Rules # Roadmap Project Governance Rules
@@ -23,6 +23,12 @@ Statuts : `( )` planifié, `(x)` terminé, `(d)` différé, `(c)` annulé.
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é. 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é.
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 différer/mettre en pause la trajectoire concernée. ### Trajectoire explicitement différée
- `(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.
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.
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.
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.0.5-alpha.9 0.0.5-beta.1

208
deltas/0.0.5/beta.1.md Normal file
View File

@@ -0,0 +1,208 @@
<!-- file: deltas/0.0.5/beta.1.md -->
<!-- version: 1 -->
# Delta 0.0.5-beta.1 — réconciliation intégrée et transition vers 0.1.0
## Baseline
Version attendue avant application :
```text
0.0.5-alpha.9
```
Le history `history/0.0.5/alpha.9.md` avec statut `PASS` MUST avoir été appliqué, committé et poussé avant ce delta.
Version après application :
```text
0.0.5-beta.1
```
## Objet
Fermer la phase alpha de `0.0.5` par une réconciliation intégrée des décisions réellement matérialisées, puis préparer la transition vers la première baseline réutilisable `0.1.0` sans inventer d'owners, de skeletons ou de releases futures.
Cette tranche :
- rejoue la classification KSP/Games sur l'état PGR obtenu ;
- vérifie que chaque responsabilité nouvelle possède un owner identifiable et que les conventions locales non généralisées restent hors du noyau ;
- inscrit durablement le skeleton Tauri contrôlé comme trajectoire `DEFER` dans `ROADMAP.md`, sans numéro de release réservé ;
- maintient les trois autres axes discutés pendant `alpha.8` au stade de candidats d'horizon, hors roadmap engagée ;
- réconcilie les points d'entrée durables ;
- prépare `prompts/006-V0_1_0_START_PROMPT.md` puisque la mission `0.1.0` est suffisamment connue.
## Décision de roadmap
La décision `alpha.9` a déjà établi qu'un skeleton Tauri complet ne peut pas être matérialisé proprement avant l'existence d'owners Web suffisants. Ce report est plus qu'une idée : il résulte d'une étude et possède des conditions de sortie explicites.
`ROADMAP.md` enregistre donc :
```text
(d) skeleton Tauri pour projets contrôlés
```
sans associer cette trajectoire à `0.1.1`, `0.2.0` ou une autre release hypothétique.
Les axes suivants restent en revanche hors roadmap tant qu'une revue d'horizon ne les engage pas :
- maturation plus large des profils techniques composables ;
- projet documentaire/spécification avec `saselang-bible` comme corpus pilote possible ;
- audit de généricité de PGR hors développement logiciel.
Cette distinction applique directement `300-DOCUMENTATION.md` : une décision de report réelle peut être conservée comme trajectoire différée, tandis qu'un candidat d'horizon ne devient pas automatiquement un engagement macro.
## Réconciliation intégrée
L'étude `001-KSP_GAMES_RECONCILIATION.md` reçoit une matrice de sortie `beta.1` qui confirme notamment :
```text
prompt versionné OWNED
contrats de fichiers/familles OWNED
lifecycle inter-release / horizon OWNED
profil Rust contrôlé OWNED
audits Rust monotâches OWNED
profil Tauri 2 OWNED
skeleton Tauri complet DEFER
Web/Vite/TypeScript/Sass DEFER
Android/JNI spécifique LOCAL/DEFER
architectures métier KSP/Games LOCAL
```
La présence d'un owner PGR n'impose pas sa sélection à tous les projets. Applicabilité, composition et overrides restent gouvernés par le modèle de profils.
## Prompt 006
`prompts/006-V0_1_0_START_PROMPT.md` prépare la reprise après publication réelle de `v0.0.5`.
Il fixe uniquement ce qui est déjà décidé :
- baseline autoritaire `pgr-v0.0.5.zip` et rapport post-tag séparé lorsqu'il existe et est `PASS` ;
- cible `0.1.0`, première tranche `0.1.0-alpha.1` ;
- audit complet de la stable avant extension ;
- mission de première baseline réellement réutilisable ;
- nécessité de produire/consolider le plan `0.1.0` pendant `alpha.1` ;
- revue d'horizon obligatoire avant fermeture ;
- skeleton Tauri conservé `DEFER` tant que ses préconditions ne sont pas réellement satisfaites.
Le prompt MUST NOT être interprété comme un plan détaillé de `0.1.0` ni comme une promesse de matérialiser tous les candidats d'horizon.
## Documentation durable
`README.md` résume désormais les capacités réellement apportées par `0.0.5` sans recopier le plan de release.
`docs/000-README.md` expose les deux contrats de validation Rust et le prompt de reprise candidat `006`.
Le plan `005` enregistre le résultat de la réconciliation intégrée et conserve les responsabilités `rc.1`, stable et `publish.001` déjà attribuées.
## Hors scope
Cette tranche ne :
- crée pas de skeleton Tauri `003` ;
- crée pas de profil Web placeholder ;
- attribue pas de release au travail Tauri différé ;
- ajoute pas les trois candidats d'horizon à la roadmap engagée ;
- modifie pas `CHANGELOG.md`, réservé à la préparation RC puis à la stable ;
- migre pas KSP ou Games ;
- change pas les règles Rust/Tauri fermées pendant les alphas.
## Validation opérateur
Après application du history `PASS` de `alpha.9`, commit/push de cette tranche, puis application du présent delta :
```bash
test "$(cat VERSION)" = '0.0.5-beta.1'
test -f history/0.0.5/alpha.9.md
test -f deltas/0.0.5/beta.1.md
test -f prompts/006-V0_1_0_START_PROMPT.md
test ! -e history/0.0.5/beta.1.md
grep -A2 '^## Statut$' history/0.0.5/alpha.9.md | grep -Fx 'PASS'
grep -Fx '<!-- version: 13 -->' README.md
grep -Fx '<!-- version: 7 -->' ROADMAP.md
grep -Fx '<!-- version: 16 -->' docs/000-README.md
grep -Fx '<!-- version: 13 -->' docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
grep -Fx '<!-- version: 11 -->' docs/studies/001-KSP_GAMES_RECONCILIATION.md
grep -Fx '<!-- version: 1 -->' prompts/006-V0_1_0_START_PROMPT.md
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
python3 -B - <<'PY'
from pathlib import Path
import re
history = Path("history/0.0.5/alpha.9.md").read_text(encoding="utf-8")
assert re.search(r"## Statut\s+PASS\s", history)
roadmap = Path("ROADMAP.md").read_text(encoding="utf-8")
assert "(d) skeleton Tauri pour projets contrôlés" in roadmap
assert "Aucun numéro de release n'est réservé pour ce travail" in roadmap
assert "saselang-bible" not in roadmap
study = Path("docs/studies/001-KSP_GAMES_RECONCILIATION.md").read_text(encoding="utf-8")
for phrase in (
"## Réconciliation intégrée `beta.1`",
"skeleton Tauri contrôlé complet",
"`DEFER`",
"repris dans `ROADMAP.md` sans numéro de release",
"Les trois axes plus larges identifiés pendant `alpha.8` restent des **candidats d'horizon**",
):
assert phrase in study, phrase
plan = Path("docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md").read_text(encoding="utf-8")
for phrase in (
"Le `DEFER` du skeleton Tauri contrôlé est suffisamment décidé",
"`prompts/006-V0_1_0_START_PROMPT.md` est préparé",
"il ne transforme pas le skeleton Tauri différé en obligation de `0.1.0`",
):
assert phrase in plan, phrase
prompt = Path("prompts/006-V0_1_0_START_PROMPT.md").read_text(encoding="utf-8")
for phrase in (
"# Prompt de démarrage 0.1.0 — première baseline réutilisable",
"pgr-v0.0.5.zip",
"pgr-0.0.5-publish.001-report.md",
"Version cible : `0.1.0`. Première tranche attendue : `0.1.0-alpha.1`.",
"Le skeleton Tauri contrôlé reste `DEFER`",
"Le plan `0.1.0` MUST programmer une revue d'horizon avant la clôture stable.",
):
assert phrase in prompt, phrase
assert not any(Path("docs/skeletons").glob("003-TAURI*.md"))
print("0.0.5 beta.1 integrated reconciliation: clean (owners reconciled, Tauri defer roadmapped, horizon candidates remain uncommitted, prompt 006 prepared)")
PY
git diff --check
git add VERSION README.md ROADMAP.md \
docs/000-README.md \
docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md \
docs/studies/001-KSP_GAMES_RECONCILIATION.md \
prompts/006-V0_1_0_START_PROMPT.md \
deltas/0.0.5/beta.1.md
git diff --cached --check
git status --short
```
La sortie Git attendue avant ajout du history est exactement :
```text
M README.md
M ROADMAP.md
M VERSION
A deltas/0.0.5/beta.1.md
M docs/000-README.md
M docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
M docs/studies/001-KSP_GAMES_RECONCILIATION.md
A prompts/006-V0_1_0_START_PROMPT.md
```

5
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md --> <!-- file: docs/000-README.md -->
<!-- version: 15 --> <!-- version: 16 -->
# Documentation PGR # Documentation PGR
@@ -27,8 +27,9 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
- [`studies/002-TAURI_SKELETON_DECISION.md`](studies/002-TAURI_SKELETON_DECISION.md) — décision `alpha.9` sur la maturité du skeleton Tauri contrôlé et ses prérequis Web encore manquants. - [`studies/002-TAURI_SKELETON_DECISION.md`](studies/002-TAURI_SKELETON_DECISION.md) — décision `alpha.9` sur la maturité du skeleton Tauri contrôlé et ses prérequis Web encore manquants.
- [`templates/004-FILE_FAMILY_CONTRACTS.md`](templates/004-FILE_FAMILY_CONTRACTS.md) — pattern facultatif pour expliciter les responsabilités et règles de modification de familles de fichiers locales lorsque la complexité le justifie. - [`templates/004-FILE_FAMILY_CONTRACTS.md`](templates/004-FILE_FAMILY_CONTRACTS.md) — pattern facultatif pour expliciter les responsabilités et règles de modification de familles de fichiers locales lorsque la complexité le justifie.
- [`templates/005-RELEASE_PLAN.md`](templates/005-RELEASE_PLAN.md) — pattern de plan de release avec clôture/transition explicites et revue d'horizon proportionnée. - [`templates/005-RELEASE_PLAN.md`](templates/005-RELEASE_PLAN.md) — pattern de plan de release avec clôture/transition explicites et revue d'horizon proportionnée.
- [`validation/003-RUST_EXPORT_COMPLETENESS.md`](validation/003-RUST_EXPORT_COMPLETENESS.md) — contrat, provenance et limites de l'audit Rust facultatif de façade crate-root. - [`validation/002-RUST_STYLE_AUDITS.md`](validation/002-RUST_STYLE_AUDITS.md) et [`validation/003-RUST_EXPORT_COMPLETENESS.md`](validation/003-RUST_EXPORT_COMPLETENESS.md) — contrats et limites des audits Rust monotâches réconciliés depuis les corpus réels.
- [`rules/700-FRAMEWORKS.md`](rules/700-FRAMEWORKS.md) et [`rules/710-TAURI.md`](rules/710-TAURI.md) — activation de la famille framework et premier profil Tauri 2 issu de la réconciliation KSP/Games. - [`rules/700-FRAMEWORKS.md`](rules/700-FRAMEWORKS.md) et [`rules/710-TAURI.md`](rules/710-TAURI.md) — activation de la famille framework et premier profil Tauri 2 issu de la réconciliation KSP/Games.
- [`../prompts/006-V0_1_0_START_PROMPT.md`](../prompts/006-V0_1_0_START_PROMPT.md) — prompt de reprise préparé pour la première baseline réutilisable `0.1.0`, à utiliser seulement après publication et vérification post-tag de `0.0.5`.
## Points d'entrée de 0.0.4 ## Points d'entrée de 0.0.4

10
docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md --> <!-- file: docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md -->
<!-- version: 12 --> <!-- version: 13 -->
# Plan 0.0.5 — réconciliation réelle avec KSP et sasedev-games # Plan 0.0.5 — réconciliation réelle avec KSP et sasedev-games
@@ -140,7 +140,13 @@ La condition de sortie du `DEFER` est la matérialisation d'owners Web suffisant
Rejouer la matrice de l'étude sur l'état PGR obtenu. Vérifier : owner unique, navigation, absence de règles KSP/Games aspirées par accident, caractère facultatif des patterns/audits concernés, cohérence des skeletons et domaines encore différés. Rejouer la matrice de l'étude sur l'état PGR obtenu. Vérifier : owner unique, navigation, absence de règles KSP/Games aspirées par accident, caractère facultatif des patterns/audits concernés, cohérence des skeletons et domaines encore différés.
Cette tranche réconcilie aussi la documentation durable et vérifie que le présent plan possède un contrat de fermeture exécutable. Le prompt `006` vers `0.1.0` peut être préparé ici si la mission `0.1.0` reste suffisamment connue. La réconciliation intégrée confirme que les owners créés ou renforcés par `0.0.5` restent bornés à leur responsabilité : prompt versionné, contrats documentaires facultatifs, lifecycle inter-release, profil/audits Rust stricts et profil Tauri. Les architectures métier KSP/Games, Android/JNI spécifique, Web autonome et distribution restent hors du noyau central tant qu'un owner réutilisable n'est pas justifié.
Le `DEFER` du skeleton Tauri contrôlé est suffisamment décidé pour devenir une trajectoire explicitement différée dans `ROADMAP.md`, sans numéro de release réservé. Les trois candidats plus larges de revue d'horizon restent volontairement hors de la roadmap engagée tant qu'une décision macro n'existe pas.
La mission `0.1.0` reste suffisamment connue : `prompts/006-V0_1_0_START_PROMPT.md` est préparé dans cette tranche comme prompt candidat de reprise. Il exige l'audit complet de la stable `0.0.5`, la consolidation d'un plan `0.1.0-alpha.1` proportionné et une revue d'horizon avant fermeture ; il ne transforme pas le skeleton Tauri différé en obligation de `0.1.0`.
Cette tranche réconcilie ainsi la documentation durable et confirme que le présent plan possède un contrat de fermeture exécutable avant `rc.1`.
### rc.1 — scope gelé et gate candidate ### rc.1 — scope gelé et gate candidate

24
docs/studies/001-KSP_GAMES_RECONCILIATION.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/studies/001-KSP_GAMES_RECONCILIATION.md --> <!-- file: docs/studies/001-KSP_GAMES_RECONCILIATION.md -->
<!-- version: 10 --> <!-- version: 11 -->
# Étude de réconciliation PGR / KSP / sasedev-games # Étude de réconciliation PGR / KSP / sasedev-games
@@ -293,3 +293,25 @@ prendre la stable réelle du projet
``` ```
`0.0.5` améliore donc le référentiel et ses points d'adoption ; il ne migre ni KSP ni Games. `0.0.5` améliore donc le référentiel et ses points d'adoption ; il ne migre ni KSP ni Games.
## Réconciliation intégrée `beta.1`
Après les tranches `alpha.1` à `alpha.9`, la classification initiale peut être rejouée sur l'état PGR obtenu sans aspirer les architectures métier des corpus.
| Domaine | Owner / artefact PGR après réconciliation | Statut intégré | Décision durable |
|---------------------------------------------------------------|---------------------------------------------------------------------------------------|----------------|-------------------------------------------------------------------------------------------------------|
| prompt de démarrage versionné | `210-WORKFLOW.md` + prompts de release | `OWNED` | contrat générique renforcé ; commandes et baselines propres au projet restent locales |
| contrats de fichiers/familles | `300-DOCUMENTATION.md` + `004-FILE_FAMILY_CONTRACTS.md` | `OWNED` | pattern facultatif, jamais inventaire obligatoire |
| lifecycle inter-release / horizon | `200-GOVERNANCE.md`, `210-WORKFLOW.md`, `300-DOCUMENTATION.md`, `005-RELEASE_PLAN.md` | `OWNED` | fermeture, transition et revue d'horizon ont désormais des owners explicites |
| profil Rust contrôlé | `510-RUST_CARGO.md` + skeleton `002` | `OWNED` | explicité, crate-root, suffixes architecturaux, séparation lib/bin et tracing transverse bornés |
| audits Rust structurels | `002-RUST_STYLE_AUDITS.md`, `003-RUST_EXPORT_COMPLETENESS.md`, scripts monotâches | `OWNED` | pas d'audit composite ; `const_blocks` reste sélectionné lorsque l'ordre est sémantique |
| Tauri 2 | `700-FRAMEWORKS.md` + `710-TAURI.md` | `OWNED` | host/layout contrôlé, capabilities/plugins, TS-RS, versions et gate framework possédés |
| skeleton Tauri contrôlé complet | étude `002-TAURI_SKELETON_DECISION.md` | `DEFER` | report durable jusqu'à matérialisation d'owners Web ; repris dans `ROADMAP.md` sans numéro de release |
| Web / Vite / TypeScript / Sass | aucun owner dédié en `0.0.5` | `DEFER` | ne pas créer de profils placeholders pour satisfaire le skeleton Tauri |
| Android/JNI Rust, distribution Games, architecture métier KSP | owners locaux ou preuves insuffisantes | `LOCAL/DEFER` | aucune aspiration dans PGR central |
La navigation durable pointe désormais vers les owners correspondant réellement aux décisions livrées. Les skeletons `001` et `002` restent composables ; aucun `003-TAURI...` n'est créé par anticipation. Les audits réutilisables restent opt-in ou sélectionnés par profil selon leur propriété, et aucune divergence historique des corpus n'est transformée rétroactivement en dette PGR.
Le `DEFER` Tauri est le seul travail différé de cette réconciliation suffisamment décidé pour être reporté explicitement dans la roadmap. Les trois axes plus larges identifiés pendant `alpha.8` restent des **candidats d'horizon**, pas des engagements : maturation de profils techniques composables, projet documentaire/spécification avec `saselang-bible` comme corpus pilote possible, et audit de généricité de PGR hors développement logiciel.
Cette réconciliation confirme que la mission de `0.0.5` est suffisamment fermée pour entrer en RC après la gate `beta.1`, sous réserve qu'aucune incohérence documentaire ou de navigation ne soit révélée par l'opérateur.

98
history/0.0.5/beta.1.md Normal file
View File

@@ -0,0 +1,98 @@
<!-- file: history/0.0.5/beta.1.md -->
<!-- version: 1 -->
# History 0.0.5-beta.1 — réconciliation intégrée
## Statut
PASS
La gate opérateur de `0.0.5-beta.1` exécutée le `2026-09-25` valide la réconciliation intégrée de la release : les owners restent bornés, le skeleton Tauri contrôlé est durablement enregistré comme trajectoire `DEFER` sans numéro de release, les trois axes plus larges restent des candidats d'horizon non engagés et le prompt `006` vers `0.1.0` est préparé sans transformer ces reports en obligations.
Les tests, audits Markdown, contrôle d'intégration ciblé et contrôles Git sont propres. Aucun correctif `beta.1` n'est requis.
## Baseline et version
La tranche part du commit opérateur de `0.0.5-alpha.9` poussé sur `origin/master` :
```text
5a83968 0.0.5-alpha.9
```
La version contrôlée après application du delta est :
```text
0.0.5-beta.1
```
`history/0.0.5/alpha.9.md` est présent avec statut `PASS`, `deltas/0.0.5/beta.1.md` et `prompts/006-V0_1_0_START_PROMPT.md` sont présents, et `history/0.0.5/beta.1.md` était absent pendant la gate.
## Validation opérateur observée
L'opérateur a fourni les sorties du `2026-09-25` depuis `~/Projects/pgr`, à `18:00:37`–`18:01:27`.
Les contrôles de révision ont confirmé :
```text
README.md version 13
ROADMAP.md version 7
docs/000-README.md version 16
docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md version 13
docs/studies/001-KSP_GAMES_RECONCILIATION.md version 11
prompts/006-V0_1_0_START_PROMPT.md version 1
```
La suite Python globale a exécuté `48` tests, tous réussis :
```text
Ran 48 tests in 0.678s
OK
```
Les audits documentaires sont propres :
```text
Markdown header audit: clean (164 file(s))
Markdown table audit: clean (8 table(s), 164 file(s))
Markdown link audit: clean (161 local link(s), 164 file(s))
```
Le contrôle structurel spécifique affiche :
```text
0.0.5 beta.1 integrated reconciliation: clean (owners reconciled, Tauri defer roadmapped, horizon candidates remain uncommitted, prompt 006 prepared)
```
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
Le scope Git observé avant ajout du présent history est exactement :
```text
M README.md
M ROADMAP.md
M VERSION
A deltas/0.0.5/beta.1.md
M docs/000-README.md
M docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md
M docs/studies/001-KSP_GAMES_RECONCILIATION.md
A prompts/006-V0_1_0_START_PROMPT.md
```
## Résultat
La phase beta confirme que `0.0.5` possède un contrat de fermeture exécutable. Le `DEFER` du skeleton Tauri est visible dans la roadmap sans fausse réservation de version ; les profils techniques supplémentaires, le corpus documentaire/spécification et l'audit hors logiciel restent des candidats d'horizon jusqu'à décision explicite.
Le prompt `006` est prêt comme artefact de reprise candidat vers `0.1.0`, sous réserve de la publication stable réelle de `v0.0.5` et de son contrôle post-tag.
## Transition
Appliquer le présent history puis committer et pousser `0.0.5-beta.1`.
La tranche suivante est :
```text
0.0.5-rc.1
```
Elle gèle le scope fonctionnel, prépare l'entrée candidate `0.0.5` du changelog, vérifie le `ROADMAP` et le prompt `006`, puis rejoue la gate de release candidate sans introduire de nouveau besoin commun.

69
prompts/006-V0_1_0_START_PROMPT.md Normal file
View File

@@ -0,0 +1,69 @@
<!-- file: prompts/006-V0_1_0_START_PROMPT.md -->
<!-- version: 1 -->
# Prompt de démarrage 0.1.0 — première baseline réutilisable
## Baseline et cible
Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`.
La baseline attendue au démarrage effectif de `0.1.0` est l'archive source téléchargée depuis le tag Gitea `v0.0.5`, dont le nom attendu est `pgr-v0.0.5.zip`. Une archive source peut légitimement ne pas contenir `.git` ; vérifier son contenu et ses artefacts de gouvernance sans lui attribuer une preuve Git qu'elle ne peut contenir.
Version cible : `0.1.0`. Première tranche attendue : `0.1.0-alpha.1`.
Si un rapport séparé `pgr-0.0.5-publish.001-report.md` a effectivement été produit et conclut `PASS`, le fournir avec l'archive. S'il est absent ou non validé, le signaler explicitement ; ne jamais présumer la publication ou un résultat PASS. Ce rapport ne fait pas partie du tag et ne remplace pas l'audit de la nouvelle session.
## Reprise manuelle après publication
Après vérification réelle de l'archive du tag et du rapport post-tag PASS, remettre spontanément à l'opérateur un message de reprise adapté selon [`../docs/templates/003-NEW_SESSION_PROMPT.md`](../docs/templates/003-NEW_SESSION_PROMPT.md). Si les noms attendus sont confirmés et le rapport est PASS, la base du texte est :
```text
Partir de l'archive pgr-v0.0.5.zip téléchargée depuis le tag Gitea v0.0.5 et du rapport post-tag pgr-0.0.5-publish.001-report.md. Lire et exécuter prompts/006-V0_1_0_START_PROMPT.md. Vérifier intégralement la stable PGR, ses règles, profils, templates, skeletons, audits, décisions différées et chaîne de gouvernance avant de préparer 0.1.0-alpha.1.
```
Si le rapport manque ou n'est pas PASS, retirer sa mention et transmettre son état réel séparément. Ce texte ne doit être remis qu'après clôture stable et vérification post-tag de `0.0.5`, jamais comme attestation anticipée au stade RC.
## Mission
Transformer les fondations `0.0.x` en première baseline PGR réellement réutilisable pour initialiser de nouveaux projets sans importer des choix locaux non applicables.
`alpha.1` MUST commencer par auditer indépendamment la stable `v0.0.5` : gouvernance, owners normatifs, templates, skeleton specifications, audits, documentation, roadmap, histories/deltas et rapport post-tag lorsqu'il est fourni. Elle doit ensuite produire ou consolider le plan `0.1.0` avant toute extension importante.
Le plan doit notamment déterminer :
- quelles règles, profils, templates et skeletons sont suffisamment cohérents pour constituer la baseline réutilisable ;
- quelles validations doivent être considérées comme gates minimales ou conditionnelles d'une nouvelle instanciation ;
- quelles décisions différées doivent seulement être conservées, réétudiées ou réellement engagées ;
- où aura lieu la revue d'horizon obligatoire avant fermeture de `0.1.0`.
## Décisions héritées à respecter
- Le skeleton Tauri contrôlé reste `DEFER` tant que les owners Web suffisants ne sont pas matérialisés. `0.1.0` MAY réexaminer cette trajectoire si son plan crée effectivement ces owners, mais MUST NOT créer le skeleton seulement pour fermer le report.
- Les profils Web/TypeScript/Vite/Sass, observability et autres domaines techniques ne sont pas présumés nécessaires : ils exigent un besoin réutilisable, un corpus réel et un owner clair avant normalisation.
- Les projets documentaires/spécifications, notamment `saselang-bible` comme corpus pilote possible, et l'usage de PGR hors logiciel restent des candidats d'horizon tant qu'une décision macro ne les engage pas.
- Aucune release postérieure à `0.1.0` ne doit être inventée pour remplir la roadmap.
## Principes de baseline
- Un owner normatif unique par responsabilité ; les skeletons sélectionnent/composent les owners et ne remplacent pas ceux qui manquent.
- Une règle n'existe que si elle apporte une valeur réelle de sûreté, cohérence, lisibilité, reprise ou automatisation.
- Compiler, outil officiel, manifeste/build system et audits read-only sont préférés aux tests textuels redondants.
- Les audits restent monotâches et leurs limites explicites ; un contrôle lexical ne prétend pas remplacer un parser ou le compilateur.
- Les profils stricts peuvent être le défaut des nouveaux projets contrôlés tout en permettant des overrides explicites lorsqu'un projet externe ou une contrainte technique impose autre chose.
- Les versions, décisions et documents restent classifiés par responsabilité ; `VERSION` ne force pas la réécriture de tous les miroirs techniques ou produit.
## Revue d'horizon obligatoire
Le plan `0.1.0` MUST programmer une revue d'horizon avant la clôture stable. Cette revue doit décider, à partir de la baseline réellement obtenue, s'il faut :
- étendre `ROADMAP.md` avec des objectifs suffisamment décidés ;
- conserver explicitement l'horizon ouvert avec un prochain déclencheur ;
- requalifier une trajectoire différée telle que le skeleton Tauri ;
- différer/mettre en pause d'autres axes ;
- ou constater qu'un objectif macro est accompli.
Elle ne doit pas réserver des numéros de version uniquement pour donner l'impression d'une trajectoire longue.
## Workflow
Suivre `RULES.md`, [`../docs/rules/210-WORKFLOW.md`](../docs/rules/210-WORKFLOW.md) et [`../docs/rules/400-VALIDATION.md`](../docs/rules/400-VALIDATION.md). La séquence reste delta → gate opérateur → history constaté → application du history → commit → delta suivant. Les corrections utilisent `.fix.N`; une session ou une discussion stratégique ne crée pas de version à elle seule.