0.0.5-beta.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 12 -->
|
||||
<!-- version: 13 -->
|
||||
|
||||
# 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`.
|
||||
|
||||
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
|
||||
|
||||
|
||||
10
ROADMAP.md
10
ROADMAP.md
@@ -1,5 +1,5 @@
|
||||
<!-- file: ROADMAP.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# 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é.
|
||||
|
||||
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`.
|
||||
|
||||
208
deltas/0.0.5/beta.1.md
Normal file
208
deltas/0.0.5/beta.1.md
Normal 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
|
||||
```
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 15 -->
|
||||
<!-- version: 16 -->
|
||||
|
||||
# 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.
|
||||
- [`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.
|
||||
- [`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.
|
||||
- [`../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
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- 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
|
||||
|
||||
@@ -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.
|
||||
|
||||
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
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/studies/001-KSP_GAMES_RECONCILIATION.md -->
|
||||
<!-- version: 10 -->
|
||||
<!-- version: 11 -->
|
||||
|
||||
# É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.
|
||||
|
||||
## 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
98
history/0.0.5/beta.1.md
Normal 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
69
prompts/006-V0_1_0_START_PROMPT.md
Normal 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.
|
||||
Reference in New Issue
Block a user