0.1.0-alpha.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 14 -->
|
||||
<!-- version: 15 -->
|
||||
|
||||
# Project Governance Rules
|
||||
|
||||
@@ -11,7 +11,7 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`.
|
||||
|
||||
## Statut
|
||||
|
||||
PGR est actuellement en phase de fondation `0.0.x`.
|
||||
PGR a clôturé sa phase de fondation `0.0.x` et construit actuellement sa première baseline réutilisable `0.1.0`.
|
||||
|
||||
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.
|
||||
|
||||
@@ -29,6 +29,7 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
|
||||
- [`docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md`](docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md) — plan historique des templates et audits `0.0.3` ;
|
||||
- [`docs/plans/004-V0_0_4_SKELETONS_PLAN.md`](docs/plans/004-V0_0_4_SKELETONS_PLAN.md) — plan historique des skeleton specifications `0.0.4` ;
|
||||
- [`docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md`](docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md) — plan historique de réconciliation `0.0.5` ;
|
||||
- [`docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md`](docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md) — plan actif de la première baseline réutilisable `0.1.0` ;
|
||||
- [`docs/studies/001-KSP_GAMES_RECONCILIATION.md`](docs/studies/001-KSP_GAMES_RECONCILIATION.md) — étude de réconciliation et classification des écarts entre PGR, KSP et Games ;
|
||||
- [`docs/skeletons/000-README.md`](docs/skeletons/000-README.md) — index des skeleton specifications et de leur contrat de composition ;
|
||||
- [`docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) — fondation composable de gouvernance locale pour un projet adoptant PGR ;
|
||||
|
||||
202
deltas/0.1.0/alpha.1.md
Normal file
202
deltas/0.1.0/alpha.1.md
Normal file
@@ -0,0 +1,202 @@
|
||||
<!-- file: deltas/0.1.0/alpha.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.0-alpha.1 — audit de la stable et cadrage de la baseline réutilisable
|
||||
|
||||
## Baseline et sources
|
||||
|
||||
Baseline PGR autoritaire : `pgr-v0.0.5.zip`, archive source téléchargée depuis le tag Gitea `v0.0.5`, accompagnée du rapport externe `pgr-0.0.5-publish.001-report.md` avec statut `PASS`.
|
||||
|
||||
SHA-256 vérifiés :
|
||||
|
||||
```text
|
||||
pgr-v0.0.5.zip 1fb72bafb24b5a0f3406561b96caa8245142a5f099e692842d9ef1ba44f41b49
|
||||
pgr-0.0.5-publish.001-report.md a6727fd1f3122dbb19eb79d6b904ebaed2bbfc360ed4a34cc1299cb2166efd96
|
||||
games-v0.3.6.zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
|
||||
khadhroony-solana-project-v0.3.16.zip db3cc1b3fc3fb07ee864b02e2a7346c673d4cf63b33e8e872aca6c6458856ca0
|
||||
```
|
||||
|
||||
Games et KSP sont uniquement des corpus de pression pour préparer l'adoption future ; ils ne sont ni modifiés ni incorporés à cette archive delta.
|
||||
|
||||
Version avant application :
|
||||
|
||||
```text
|
||||
0.0.5
|
||||
```
|
||||
|
||||
Version après application :
|
||||
|
||||
```text
|
||||
0.1.0-alpha.1
|
||||
```
|
||||
|
||||
## Objet
|
||||
|
||||
Exécuter `prompts/006-V0_1_0_START_PROMPT.md` : auditer intégralement la stable `v0.0.5`, ses règles, profils, templates, skeletons, audits, décisions différées et chaîne de gouvernance, puis créer le plan de la première baseline réellement réutilisable avant tout changement normatif important.
|
||||
|
||||
La tranche consigne également les décisions de cadrage acquises pendant la reprise :
|
||||
|
||||
- corriger en `0.1.0` la convention future `rel.001` vers `rel.1` sans réécrire l'historique ;
|
||||
- distinguer le nom de tranche de fermeture du commit qui établit finalement la stable `X.Y.Z` ;
|
||||
- formaliser le handoff automatique des commandes Git après chaque history et des commandes/preuves de publication avant/après tag ;
|
||||
- traiter Web, serveur Rust/Actix, Java/Android, WASM et Tauri dans des releases `0.1.x` séparées, jamais comme un bloc unique `0.1.0` ;
|
||||
- préparer l'adoption de PGR par Games dès que son sous-ensemble requis est prêt, puis par KSP dont la pression est principalement Rust/Cargo + Tauri.
|
||||
|
||||
Aucune de ces corrections n'est encore matérialisée normativement dans `alpha.1`.
|
||||
|
||||
## Résultat de l'audit d'intake
|
||||
|
||||
La stable et son rapport post-tag sont cohérents. L'archive contient `225` entrées sous `pgr/`, `194` fichiers et `31` répertoires, CRC propre, aucun symlink et aucune métadonnée `.git` attendue.
|
||||
|
||||
La suite PGR donne `48/48` tests `PASS`. Les audits Markdown sont propres : `171` fichiers pour les headers, `8` tables sur `171` fichiers et `161` liens locaux sur `171` fichiers.
|
||||
|
||||
Les `62` couples delta/history de `0.0.1` à `0.0.5` sont complets. Les `19` histories de `0.0.5` conservent leurs statuts réels, notamment `rel.001` `FAIL` puis `rel.001.fix.1` `PASS`.
|
||||
|
||||
Les owners actuels couvrent déjà Rust/Cargo (`510`), Java/Maven/Gradle (`520`), Android (`610`) et Tauri (`710`). Les templates techniques actuels sont Rust/Cargo ; les skeletons concrets sont la fondation de gouvernance et le workspace Rust/Cargo. Le skeleton Tauri reste correctement `DEFER` tant que les owners Web manquants ne sont pas matérialisés.
|
||||
|
||||
Games `0.3.6` confirme une pression réelle Web/Vite/TypeScript/Sass, Android/Gradle, Rust/WASM et Tauri, avec `0.3.7` réservé dans son propre roadmap à l'alignement PGR. KSP `0.3.16` contient six applications Tauri et un socle essentiellement Rust/Cargo. Ces observations servent au sizing futur et ne créent aucun profil dans cette tranche.
|
||||
|
||||
## Scope
|
||||
|
||||
REPLACE :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
README.md
|
||||
docs/000-README.md
|
||||
```
|
||||
|
||||
ADD :
|
||||
|
||||
```text
|
||||
docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
|
||||
deltas/0.1.0/alpha.1.md
|
||||
```
|
||||
|
||||
DELETE : aucun.
|
||||
|
||||
`RULES.md`, `ROADMAP.md`, `CHANGELOG.md`, les règles, profils, templates, skeletons, scripts et histories existants restent inchangés dans `alpha.1`.
|
||||
|
||||
Aucun `history/0.1.0/alpha.1.md` n'est anticipé avant la gate opérateur.
|
||||
|
||||
## Validation opérateur
|
||||
|
||||
Après application sur la stable `0.0.5`, depuis la racine du dépôt :
|
||||
|
||||
```bash
|
||||
test "$(cat VERSION)" = '0.1.0-alpha.1'
|
||||
test -f docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
|
||||
test -f deltas/0.1.0/alpha.1.md
|
||||
test ! -e history/0.1.0/alpha.1.md
|
||||
|
||||
grep -Fx '<!-- version: 15 -->' README.md
|
||||
grep -Fx '<!-- version: 18 -->' docs/000-README.md
|
||||
grep -F '006-V0_1_0_REUSABLE_BASELINE_PLAN.md' README.md docs/000-README.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
|
||||
|
||||
expected = {
|
||||
'0.0.1': 12,
|
||||
'0.0.2': 12,
|
||||
'0.0.3': 10,
|
||||
'0.0.4': 9,
|
||||
'0.0.5': 19,
|
||||
}
|
||||
for release, count in expected.items():
|
||||
deltas = {path.name for path in Path('deltas', release).glob('*.md')}
|
||||
histories = {path.name for path in Path('history', release).glob('*.md')}
|
||||
assert len(deltas) == count, (release, len(deltas))
|
||||
assert deltas == histories, (release, sorted(deltas ^ histories))
|
||||
|
||||
statuses = {}
|
||||
for path in Path('history/0.0.5').glob('*.md'):
|
||||
text = path.read_text(encoding='utf-8')
|
||||
match = re.search(r'## Statut\s+(PASS|FAIL|PARTIAL|BLOCKED)\s', text)
|
||||
assert match is not None, path
|
||||
statuses[path.name] = match.group(1)
|
||||
assert statuses['rel.001.md'] == 'FAIL'
|
||||
assert statuses['rel.001.fix.1.md'] == 'PASS'
|
||||
|
||||
for path in (
|
||||
Path('docs/rules/510-RUST_CARGO.md'),
|
||||
Path('docs/rules/520-JAVA_MAVEN_GRADLE.md'),
|
||||
Path('docs/rules/610-ANDROID.md'),
|
||||
Path('docs/rules/710-TAURI.md'),
|
||||
Path('docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md'),
|
||||
Path('docs/skeletons/002-RUST_CARGO_WORKSPACE.md'),
|
||||
Path('docs/studies/002-TAURI_SKELETON_DECISION.md'),
|
||||
):
|
||||
assert path.is_file(), path
|
||||
|
||||
plan = Path('docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md').read_text(encoding='utf-8')
|
||||
for phrase in (
|
||||
'rel.1',
|
||||
'première tranche qui obtient le PASS stable',
|
||||
'Commandes opérateur et publication',
|
||||
'une release/session par domaine cohérent',
|
||||
'Games',
|
||||
'KSP',
|
||||
'TypeScript',
|
||||
'Vite',
|
||||
'Android',
|
||||
'WASM',
|
||||
'Tauri',
|
||||
'Actix Web ou autre framework',
|
||||
'beta.1 — réconciliation finale et revue d\'horizon',
|
||||
):
|
||||
assert phrase in plan, phrase
|
||||
|
||||
assert '- `( ) 0.1.0`' in Path('ROADMAP.md').read_text(encoding='utf-8')
|
||||
assert '- `( ) 0.1.1`' not in Path('ROADMAP.md').read_text(encoding='utf-8')
|
||||
print('0.1.0 alpha.1 structural audit: clean (62 prior pairs, stable workflow truth preserved, future 0.1.x unnumbered)')
|
||||
PY
|
||||
|
||||
git diff --check
|
||||
git add VERSION README.md docs/000-README.md \
|
||||
docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md \
|
||||
deltas/0.1.0/alpha.1.md
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Le scope indexé attendu avant ajout du history est :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
A deltas/0.1.0/alpha.1.md
|
||||
M docs/000-README.md
|
||||
A docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
|
||||
```
|
||||
|
||||
La revue opérateur doit également confirmer que :
|
||||
|
||||
- le plan ne transforme pas les futurs axes `0.1.x` en versions numérotées prématurément ;
|
||||
- Java/Android et Tauri sont reconnus comme profils existants, non recréés artificiellement ;
|
||||
- le `DEFER` du skeleton Tauri reste intact dans cette tranche ;
|
||||
- Games et KSP restent des corpus externes non modifiés ;
|
||||
- aucune règle Web/WASM/Actix n'est introduite dans `alpha.1` ;
|
||||
- les anciennes occurrences `rel.001*` restent intactes et historiques.
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Produire `history/0.1.0/alpha.1.md` à partir des résultats réellement observés. Dans la même réponse, si aucune décision nouvelle n'est ouverte, préparer séparément le delta `0.1.0-alpha.2` consacré uniquement à la clôture stable `rel.N` et à l'identité du commit final.
|
||||
|
||||
Après remise du history, fournir spontanément le bloc Git exact à exécuter pour fermer `alpha.1` avant application du delta suivant, même si la règle normative des handoffs automatiques ne sera matérialisée qu'en `alpha.3`.
|
||||
|
||||
### FAIL
|
||||
|
||||
Consigner le résultat réel dans le history, puis ouvrir `0.1.0-alpha.1.fix.1` ou un REPLAN selon la cause. Aucun changement de `alpha.2` ne doit être absorbé silencieusement dans le fix.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 17 -->
|
||||
<!-- version: 18 -->
|
||||
|
||||
# Documentation PGR
|
||||
|
||||
@@ -20,6 +20,10 @@ D'autres collections telles que `ideas/`, `studies/`, `reference/` ou `formats/`
|
||||
|
||||
Les templates techniques copiables sous `templates/` restent séparés des instructions documentaires sous `docs/templates/`. Les répertoires workflow de racine (`deltas/`, `history/`, `handoffs/`, `manifests/`, `prompts/`, `scripts/`) restent séparés de `docs/` parce qu'ils portent le processus de développement et de livraison lui-même.
|
||||
|
||||
## Points d'entrée de 0.1.0
|
||||
|
||||
- [`plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md`](plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md) — audit de la stable `v0.0.5`, cadrage du workflow de clôture/publication et préparation de la première baseline PGR réellement réutilisable.
|
||||
|
||||
## Points d'entrée de 0.0.5
|
||||
|
||||
- [`plans/005-V0_0_5_RECONCILIATION_PLAN.md`](plans/005-V0_0_5_RECONCILIATION_PLAN.md) — périmètre et décisions de la release `0.0.5` ;
|
||||
|
||||
257
docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
Normal file
257
docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
Normal file
@@ -0,0 +1,257 @@
|
||||
<!-- file: docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Plan 0.1.0 — première baseline PGR réutilisable
|
||||
|
||||
## Statut et sources
|
||||
|
||||
Plan actif créé pendant `0.1.0-alpha.1` conformément à `prompts/006-V0_1_0_START_PROMPT.md` après audit indépendant de la stable taggée `v0.0.5` et de son rapport post-tag.
|
||||
|
||||
Sources autoritaires de reprise :
|
||||
|
||||
```text
|
||||
pgr-v0.0.5.zip 1fb72bafb24b5a0f3406561b96caa8245142a5f099e692842d9ef1ba44f41b49
|
||||
pgr-0.0.5-publish.001-report.md a6727fd1f3122dbb19eb79d6b904ebaed2bbfc360ed4a34cc1299cb2166efd96
|
||||
```
|
||||
|
||||
Le rapport `publish.001` est `PASS` et porte sur cette même archive. L'absence de `.git` dans l'archive du tag est normale et n'est pas une validation manquante.
|
||||
|
||||
Deux corpus récents ont également été fournis pour préparer l'adoption future sans devenir des dépendances de la baseline `0.1.0` :
|
||||
|
||||
```text
|
||||
games-v0.3.6.zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
|
||||
khadhroony-solana-project-v0.3.16.zip db3cc1b3fc3fb07ee864b02e2a7346c673d4cf63b33e8e872aca6c6458856ca0
|
||||
```
|
||||
|
||||
Games `0.3.6` conserve explicitement `0.3.7` comme future release d'alignement PGR. KSP `0.3.16` reste principalement un corpus Rust/Cargo avec six applications Tauri ; aucune migration de Games ou KSP n'appartient à `0.1.0`.
|
||||
|
||||
## Audit de la stable `v0.0.5`
|
||||
|
||||
### Intégrité et chaîne historique
|
||||
|
||||
L'archive stable contient `225` entrées sous une racine unique `pgr/`, soit `194` fichiers et `31` répertoires. Son CRC est propre, aucun lien symbolique n'est présent et `.git` est absent comme attendu pour une archive de tag Gitea.
|
||||
|
||||
Les `62` couples delta/history des releases `0.0.1` à `0.0.5` sont complets :
|
||||
|
||||
```text
|
||||
0.0.1 12 / 12
|
||||
0.0.2 12 / 12
|
||||
0.0.3 10 / 10
|
||||
0.0.4 9 / 9
|
||||
0.0.5 19 / 19
|
||||
```
|
||||
|
||||
La vérité opérateur de `0.0.5` est conservée, notamment les `FAIL` intermédiaires et la fermeture finale `rel.001.fix.1` en `PASS`. Aucun ancien delta/history ne sera renommé rétroactivement lorsque la nouvelle convention `rel.N` sera introduite.
|
||||
|
||||
### Tests et audits
|
||||
|
||||
La stable passe :
|
||||
|
||||
```text
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
48 tests PASS
|
||||
|
||||
Markdown header audit: clean (171 file(s))
|
||||
Markdown table audit: clean (8 table(s), 171 file(s))
|
||||
Markdown link audit: clean (161 local link(s), 171 file(s))
|
||||
```
|
||||
|
||||
Les audits PGR restent monotâches et read-only : trois audits Markdown, six audits de style Rust, un audit Rust de façade/export completeness, plus leur helper commun. Aucun audit ne devient un wrapper de build.
|
||||
|
||||
### Règles, profils, templates et skeletons
|
||||
|
||||
La hiérarchie normative est cohérente et possède un owner explicite pour gouvernance, workflow, skeletons, documentation, validation, langages/écosystèmes, plateformes et frameworks.
|
||||
|
||||
Profils techniques déjà matérialisés :
|
||||
|
||||
```text
|
||||
510 Rust / Cargo
|
||||
520 Java / Maven / Gradle
|
||||
610 Android
|
||||
710 Tauri 2
|
||||
```
|
||||
|
||||
La baseline possède cinq templates techniques Rust/Cargo sous `templates/rust-cargo/`, deux skeleton specifications concrètes — fondation de gouvernance et workspace Rust/Cargo — et les contrats de validation associés.
|
||||
|
||||
Le profil Rust/Cargo est suffisamment avancé pour servir rapidement de référence à Games et KSP. Les profils Java/Gradle et Android existent déjà normativement ; leur future release `0.1.x` devra donc d'abord réévaluer leur complétude pratique, leurs templates, skeletons et audits nécessaires au cas Games au lieu de recréer les profils depuis zéro.
|
||||
|
||||
Le profil Tauri `710` existe également, mais le skeleton Tauri contrôlé reste volontairement `DEFER` : il attend des owners Web suffisants pour TypeScript, Vite, Sass/CSS, sorties frontend et validation frontend indépendante.
|
||||
|
||||
## Défauts de gouvernance à corriger en 0.1.0
|
||||
|
||||
L'audit ne révèle pas de défaut bloquant de la stable, mais deux conventions doivent être corrigées avant de diffuser PGR plus largement.
|
||||
|
||||
### Clôture stable `rel.N`
|
||||
|
||||
L'expérience réelle de `0.0.5` montre que la convention actuelle `rel.001` mélange inutilement padding historique et identité de tranche. La convention future doit utiliser :
|
||||
|
||||
```text
|
||||
rel.1
|
||||
rel.1.fix.1
|
||||
rel.2
|
||||
...
|
||||
```
|
||||
|
||||
Les anciens fichiers `rel.001*` restent immuables.
|
||||
|
||||
Le nom de tranche et le message du commit qui matérialise finalement la stable doivent être distingués. Par défaut PGR :
|
||||
|
||||
```text
|
||||
rel.1 FAIL -> commit de tranche X.Y.Z-rel.1
|
||||
rel.1.fix.1 FAIL -> commit de tranche X.Y.Z-rel.1.fix.1
|
||||
première tranche qui obtient le PASS stable
|
||||
-> commit final X.Y.Z
|
||||
```
|
||||
|
||||
Le tag `vX.Y.Z` n'est créé qu'après ce commit final stable.
|
||||
|
||||
### Commandes opérateur et publication
|
||||
|
||||
Après production d'un history constaté, le générateur doit remettre spontanément les commandes exactes à exécuter entre l'application de ce history et le delta suivant. Le défaut PGR retenu est :
|
||||
|
||||
```bash
|
||||
git add -A
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
git commit -m "<message attendu>"
|
||||
git push origin <branche>
|
||||
```
|
||||
|
||||
Le bloc doit être adapté au projet et au statut réel de la tranche ; il ne doit pas inventer une branche ou un remote lorsqu'ils ne sont pas établis.
|
||||
|
||||
Pour la dernière clôture pré-tag, le handoff opérateur doit en plus fournir le bloc de tag/vérification approprié et indiquer explicitement les preuves/artefacts à remettre pour générer la vérification post-tag, notamment l'archive issue du tag et les preuves Git réellement disponibles. Un tag annoté doit être vérifié sans confondre l'objet tag avec son commit déréférencé.
|
||||
|
||||
Après `publish.* PASS`, la consigne manuelle de nouvelle session reste produite automatiquement selon `docs/templates/003-NEW_SESSION_PROMPT.md`.
|
||||
|
||||
## Mission de `0.1.0`
|
||||
|
||||
`0.1.0` doit transformer la fondation `0.0.x` en baseline réellement réutilisable **sans absorber les domaines technologiques futurs**.
|
||||
|
||||
La release doit :
|
||||
|
||||
1. corriger la sémantique de clôture `rel.N` et des commits stables ;
|
||||
2. rendre obligatoire le handoff automatique des commandes opérateur après chaque history et lors de la publication ;
|
||||
3. formaliser une adoption proportionnée de PGR par un projet existant, distincte de l'instanciation d'un nouveau projet ;
|
||||
4. vérifier que la fondation et le skeleton Rust/Cargo peuvent servir de baseline réutilisable sans dépendre de choix KSP/Games ;
|
||||
5. effectuer avant RC une revue d'horizon qui engage uniquement les prochaines releases `0.1.x` suffisamment décidées.
|
||||
|
||||
`0.1.0` ne crée pas de profil Web, WASM, serveur Rust/Actix, Java, Android ou Tauri supplémentaire. Ces domaines seront traités séparément dans la série `0.1.x` lorsque leur release dédiée sera engagée.
|
||||
|
||||
## Direction acquise pour la série `0.1.x`
|
||||
|
||||
La série `0.1.x` doit rester composée de releases concrètes indépendantes, en pratique une release/session par domaine cohérent. Il est explicitement exclu de regrouper Web, serveur Rust, Java/Android, Tauri et WASM dans `0.1.0` ou dans une unique grosse release suivante.
|
||||
|
||||
La revue d'horizon de `0.1.0` devra ordonner et, seulement lorsque le scope est suffisamment décidé, numéroter les axes suivants :
|
||||
|
||||
- owners Web contrôlés : TypeScript, Vite, Sass/CSS, package manager/build outputs et validation frontend ;
|
||||
- serveur Web Rust — Actix Web ou autre framework seulement à partir d'un besoin et d'un corpus réels, notamment pour les trajectoires HTTP/3 ;
|
||||
- réévaluation pratique du profil Java/Gradle existant pour Games ;
|
||||
- réévaluation pratique du profil Android existant pour Games ;
|
||||
- WASM comme domaine séparé si l'adoption Games démontre qu'un owner PGR apporte une valeur immédiate ;
|
||||
- levée du `DEFER` Tauri seulement après matérialisation des owners Web nécessaires ;
|
||||
- adoption de PGR par Games dès que le sous-ensemble requis est réellement prêt ;
|
||||
- adoption de PGR par KSP ensuite, avec une pression principalement Rust/Cargo + Tauri et sans attendre les profils non pertinents pour KSP.
|
||||
|
||||
Les numéros exacts `0.1.1`, `0.1.2`, etc. ne sont pas réservés dans `alpha.1`. Cette attribution appartient à la revue d'horizon lorsque l'ordre réel est suffisamment décidé.
|
||||
|
||||
Après cette vague d'adoption `0.1.x`, les axes plus larges — projets documentaires/spécifications tels que `saselang-bible`, généricité hors logiciel et autres familles technologiques — restent candidats pour une trajectoire `0.2.x`/`0.3.x` à décider ultérieurement, sans réservation artificielle aujourd'hui.
|
||||
|
||||
## Trajectoire prévisionnelle de `0.1.0`
|
||||
|
||||
### alpha.1 — audit de stable et plan
|
||||
|
||||
Vérifier intégralement `v0.0.5`, son rapport post-tag, les owners normatifs, profils, templates, skeletons, audits, chaîne delta/history et décisions différées. Consigner le cadrage présent sans changement normatif ni migration externe.
|
||||
|
||||
### alpha.2 — clôture stable et identité `rel.N`
|
||||
|
||||
Modifier les owners de gouvernance/workflow nécessaires pour :
|
||||
|
||||
- remplacer la convention future `rel.001` par `rel.1` ;
|
||||
- préserver l'immutabilité des anciennes releases ;
|
||||
- définir le message de commit des tranches de clôture échouées ;
|
||||
- définir que le commit qui obtient finalement le `PASS` stable se nomme `X.Y.Z` par défaut avant création de `vX.Y.Z`.
|
||||
|
||||
Aucun changement technologique dans cette tranche.
|
||||
|
||||
### alpha.3 — handoff automatique des commandes opérateur
|
||||
|
||||
Formaliser le bloc de commandes remis après chaque history, l'ordre commit/push avant application du delta suivant, les commandes supplémentaires de tag pour une stable validée et la liste des preuves à fournir pour produire le rapport post-tag.
|
||||
|
||||
Créer ou adapter un template documentaire uniquement si cela évite de dupliquer ces commandes dans chaque delta.
|
||||
|
||||
### alpha.4 — adoption d'un projet existant
|
||||
|
||||
Formaliser une méthode courte d'adoption PGR pour un dépôt existant : audit de la baseline réelle, mapping des owners applicables, classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, migration progressive et interdiction de réécrire l'historique uniquement pour le rendre rétroactivement conforme.
|
||||
|
||||
Ce contrat doit permettre de préparer Games puis KSP sans imposer tous les profils PGR à chaque projet.
|
||||
|
||||
### alpha.5 — baseline réutilisable et dry-run de composition
|
||||
|
||||
Réconcilier la fondation `001`, le skeleton Rust/Cargo `002`, les templates Rust/Cargo et la validation minimale. Effectuer un dry-run documentaire/structurel d'instanciation et d'adoption afin de vérifier qu'un nouveau projet Rust et un projet Rust existant peuvent sélectionner les owners utiles sans dépendre de KSP/Games.
|
||||
|
||||
Les profils Java/Android/Tauri sont classifiés mais ne reçoivent pas leurs nouveaux templates/skeletons dans cette 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.
|
||||
|
||||
Le prompt de la prochaine version n'est créé que lorsque cette revue a effectivement fixé la cible suivante.
|
||||
|
||||
### rc.1 — release candidate
|
||||
|
||||
Geler le scope, produire l'entrée candidate de `CHANGELOG.md`, exécuter le release gate complet applicable, vérifier le prompt/handoff suivant et confirmer que les changements `rel.N`/commandes opérateur sont exercés par les artefacts de la release elle-même.
|
||||
|
||||
### rel.1 — promotion stable
|
||||
|
||||
Première utilisation de la convention corrigée `rel.1`. La promotion reste mécanique et proportionnée. Si `rel.1` échoue, le history est conservé et un `rel.1.fix.N` corrige uniquement la fermeture ; la première tranche qui établit réellement la stable est committée sous `0.1.0` avant le tag `v0.1.0`.
|
||||
|
||||
## Stratégie de validation
|
||||
|
||||
Chaque tranche documentaire rejoue au minimum :
|
||||
|
||||
```text
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
python3 -B scripts/audit_markdown_headers.py ...
|
||||
python3 -B scripts/audit_markdown_tables.py ...
|
||||
python3 -B scripts/audit_markdown_links.py ...
|
||||
```
|
||||
|
||||
Les scripts d'audit restent read-only et ne déclenchent aucun build. Les changements de workflow doivent recevoir des contrôles structurels ciblés qui vérifient la nomenclature future sans imposer de renommer les snapshots historiques.
|
||||
|
||||
Le dry-run de composition `alpha.5` doit privilégier les parsers/outils officiels lorsque disponibles. Une prévalidation générateur ne remplace pas le gate opérateur.
|
||||
|
||||
## Déclencheurs de REPLAN
|
||||
|
||||
REPLAN est requis si :
|
||||
|
||||
- `0.1.0` commence à absorber Web, Android, WASM, Actix ou le skeleton Tauri au lieu de les laisser à des releases `0.1.x` distinctes ;
|
||||
- la convention de commit stable ne peut pas être définie sans ambiguïté avec les histories `FAIL`/fix ;
|
||||
- le handoff automatique dépend de valeurs Git qui ne peuvent pas être établies de manière sûre ;
|
||||
- l'adoption d'un projet existant exige de modifier rétroactivement son historique ;
|
||||
- le dry-run révèle que la fondation ou le skeleton Rust/Cargo n'est pas réellement autonome ;
|
||||
- la revue d'horizon transforme des candidats en numéros réservés sans scope suffisamment décidé.
|
||||
|
||||
## Clôture et transition
|
||||
|
||||
- documentation durable du workflow : `alpha.2` à `alpha.4` ;
|
||||
- preuve de réutilisabilité : `alpha.5` ;
|
||||
- réconciliation documentaire et revue d'horizon : `beta.1` ;
|
||||
- `CHANGELOG` candidate et release gate : `rc.1` ;
|
||||
- promotion stable et nouveau contrat `rel.1` : `rel.1` ;
|
||||
- tag/post-tag : après le commit stable `0.1.0`, avec handoff opérateur automatique ;
|
||||
- prompt suivant : créé uniquement si `beta.1` a réellement engagé la prochaine cible `0.1.x`.
|
||||
|
||||
## Revue d'horizon
|
||||
|
||||
État : **requise**.
|
||||
|
||||
Moment : `beta.1`, après preuve de réutilisabilité et avant RC.
|
||||
|
||||
Sorties autorisées :
|
||||
|
||||
- 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.
|
||||
103
history/0.1.0/alpha.1.md
Normal file
103
history/0.1.0/alpha.1.md
Normal file
@@ -0,0 +1,103 @@
|
||||
<!-- file: history/0.1.0/alpha.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.1.0-alpha.1 — audit de la stable et cadrage de la baseline réutilisable
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La gate opérateur de `0.1.0-alpha.1` exécutée le `2026-09-25` valide l'audit de reprise depuis `v0.0.5`, le plan de la première baseline PGR réutilisable et le maintien des futurs domaines `0.1.x` comme axes non numérotés. Aucun fix ni REPLAN de `alpha.1` n'est requis.
|
||||
|
||||
Cette preuve ferme uniquement le cadrage `alpha.1`. Elle ne matérialise encore ni la nouvelle convention `rel.N`, ni le handoff automatique des commandes Git, ni un profil technologique supplémentaire.
|
||||
|
||||
## Baseline et version
|
||||
|
||||
La tranche part de la stable taggée `v0.0.5`, dont l'archive autoritaire et le rapport post-tag `publish.001` ont été audités pendant la préparation du delta.
|
||||
|
||||
La version contrôlée après application du delta est :
|
||||
|
||||
```text
|
||||
0.1.0-alpha.1
|
||||
```
|
||||
|
||||
L'opérateur a confirmé la présence de `deltas/0.1.0/alpha.1.md` et l'absence du présent history pendant la gate. Les révisions attendues ont été retrouvées :
|
||||
|
||||
```text
|
||||
README.md version 15
|
||||
docs/000-README.md version 18
|
||||
docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md présent et indexé
|
||||
```
|
||||
|
||||
## Validation opérateur observée
|
||||
|
||||
L'opérateur a fourni les sorties du `2026-09-25` depuis `~/Projects/pgr`, à `22:08:29`–`22:08:30`.
|
||||
|
||||
La suite Python globale a exécuté `48` tests, tous réussis :
|
||||
|
||||
```text
|
||||
Ran 48 tests in 0.720s
|
||||
|
||||
OK
|
||||
```
|
||||
|
||||
Les audits documentaires sont propres :
|
||||
|
||||
```text
|
||||
Markdown header audit: clean (173 file(s))
|
||||
Markdown table audit: clean (8 table(s), 173 file(s))
|
||||
Markdown link audit: clean (163 local link(s), 173 file(s))
|
||||
```
|
||||
|
||||
Le contrôle structurel spécifique a affiché :
|
||||
|
||||
```text
|
||||
0.1.0 alpha.1 structural audit: clean (62 prior pairs, stable workflow truth preserved, future 0.1.x unnumbered)
|
||||
```
|
||||
|
||||
Il confirme notamment :
|
||||
|
||||
- les `62` couples delta/history des releases `0.0.1` à `0.0.5` ;
|
||||
- la conservation de `rel.001` en `FAIL` et `rel.001.fix.1` en `PASS` dans l'historique `0.0.5` ;
|
||||
- la présence des profils Rust/Cargo, Java/Maven/Gradle, Android et Tauri ainsi que des skeletons et de l'étude Tauri attendus ;
|
||||
- les décisions de cadrage `rel.1`, commit stable final, releases `0.1.x` par domaine, Games avant KSP et maintien des axes Web/Vite/Android/WASM/Tauri/serveur Rust comme horizons non numérotés ;
|
||||
- l'absence de réservation prématurée de `0.1.1` dans `ROADMAP.md`.
|
||||
|
||||
## 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 README.md
|
||||
M VERSION
|
||||
A deltas/0.1.0/alpha.1.md
|
||||
M docs/000-README.md
|
||||
A docs/plans/006-V0_1_0_REUSABLE_BASELINE_PLAN.md
|
||||
```
|
||||
|
||||
Le scope correspond donc au delta livré et aucun fichier normatif, profil, template, skeleton, script ou history antérieur n'a été modifié par `alpha.1`.
|
||||
|
||||
## Revue de cadrage
|
||||
|
||||
Les précisions ajoutées pendant la session ne remettent pas en cause le scope validé de `alpha.1` :
|
||||
|
||||
- les domaines Web, serveur Rust, Java/Android, WASM et Tauri restent destinés à des releases `0.1.x` séparées ;
|
||||
- KSP reste principalement dépendant de la baseline Rust/Cargo déjà mûre et du futur déblocage Tauri ;
|
||||
- un futur audit Python simulant uniquement un sous-ensemble statiquement vérifiable des conventions Clippy est conservé comme candidat non prioritaire après les adoptions Games puis KSP ; il ne remplacera pas `cargo clippy` ;
|
||||
- les profils de déploiement/exploitation — reverse proxy, bases de données, conteneurs et responsabilités associées — restent un horizon plus lointain, sans numéro de release réservé.
|
||||
|
||||
Ces deux derniers horizons n'ont pas été introduits dans les fichiers de `alpha.1`. Ils peuvent être enregistrés dans le plan actif lors d'une tranche ultérieure sans transformer cette gate en échec.
|
||||
|
||||
## Transition
|
||||
|
||||
Appliquer le présent history puis committer et pousser `0.1.0-alpha.1`.
|
||||
|
||||
La tranche suivante est :
|
||||
|
||||
```text
|
||||
0.1.0-alpha.2
|
||||
```
|
||||
|
||||
Elle est strictement consacrée à la convention future `rel.N`, à l'abandon du padding `rel.001` pour les nouvelles releases et à la distinction entre commits de clôture échoués et commit final stable `X.Y.Z`. Les anciennes releases restent immuables.
|
||||
Reference in New Issue
Block a user