0.0.4-rc.1
This commit is contained in:
10
CHANGELOG.md
10
CHANGELOG.md
@@ -1,5 +1,5 @@
|
||||
<!-- file: CHANGELOG.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# Changelog Project Governance Rules
|
||||
|
||||
@@ -7,6 +7,14 @@ Ce fichier décrit les changements utiles aux utilisateurs ou intégrateurs des
|
||||
|
||||
Les tranches `alpha`, `beta`, `rc`, fixes, validations, audits et détails de développement appartiennent aux plans, deltas et historiques. Ils ne sont pas recopiés ici par défaut.
|
||||
|
||||
## 0.0.4 (candidate)
|
||||
|
||||
- définit un contrat transversal de skeleton specifications pour sélectionner et composer règles, profils, templates, décisions destinataire, overrides et validation sans dupliquer les propriétaires normatifs ;
|
||||
- ajoute une fondation composable de gouvernance locale pour initialiser version, documentation minimale, workflow retenu et validation proportionnée d'un projet utilisant PGR ;
|
||||
- ajoute une spécialisation Rust/Cargo workspace composant la fondation avec les profils `500 + 510` et les cinq templates Rust/Cargo existants ;
|
||||
- explicite les décisions à adapter avant instanciation, notamment version, édition/toolchain, membres, métadonnées, dépendances/features, `Cargo.lock`, lints, chemins d'artefacts et audits facultatifs ;
|
||||
- conserve Java/Maven/Gradle, Android, Web, JNI, Tauri et les autres familles insuffisamment matérialisées comme domaines différés plutôt que créer des skeletons prématurés.
|
||||
|
||||
## 0.0.3
|
||||
|
||||
- fournit cinq fichiers modèles Rust/Cargo : `rustfmt.toml`, `clippy.toml`, `.cargo/config.toml`, un manifest workspace et un manifest de crate membre, avec instructions d'adaptation ;
|
||||
|
||||
265
deltas/0.0.4/rc.1.md
Normal file
265
deltas/0.0.4/rc.1.md
Normal file
@@ -0,0 +1,265 @@
|
||||
<!-- file: deltas/0.0.4/rc.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.0.4-rc.1 — gel du scope et préparation de release
|
||||
|
||||
## Baseline et version
|
||||
|
||||
Baseline : `0.0.4-beta.1.fix.1`, avec `history/0.0.4/beta.1.fix.1.md` appliqué et committé. Ce delta MUST NOT être appliqué avant ce commit.
|
||||
|
||||
Le commit exact de cette baseline sera celui produit par l'opérateur après la gate `beta.1.fix.1` ; il n'est pas anticipé dans cette livraison simultanée du history et du delta suivant.
|
||||
|
||||
Version avant application :
|
||||
|
||||
```text
|
||||
0.0.4-beta.1.fix.1
|
||||
```
|
||||
|
||||
Version après application :
|
||||
|
||||
```text
|
||||
0.0.4-rc.1
|
||||
```
|
||||
|
||||
## Objet et gel
|
||||
|
||||
La réconciliation `beta.1.fix.1` est `PASS`. La RC gèle le scope fonctionnel de `0.0.4` sur :
|
||||
|
||||
- le contrat transversal des skeleton specifications sous `docs/rules/220-SKELETONS.md` ;
|
||||
- la collection `docs/skeletons/` et son index ;
|
||||
- `001-PROJECT_GOVERNANCE_FOUNDATION.md` comme fondation composable sans spécialisation technologique ;
|
||||
- `002-RUST_CARGO_WORKSPACE.md` comme première spécialisation technologique, composée avec les profils `500 + 510` ;
|
||||
- les cinq templates Rust/Cargo déjà introduits avant `0.0.4`, utilisés avec des décisions destinataire explicites et une instanciation temporaire vérifiable.
|
||||
|
||||
Le changelog reçoit une entrée candidate `0.0.4` orientée utilisateurs. Le plan enregistre les résultats `FAIL → fix PASS` des gates `alpha.4` et `beta.1`, puis le gel RC. Le prompt `005` prépare `0.0.5`, dont la roadmap confirme la mission de réconciliation réelle avec `khadhroony-solana-project` et `sasedev-games` à partir de baselines explicitement fournies.
|
||||
|
||||
Aucun nouveau skeleton, profil, template, audit, générateur ou domaine technologique n'entre en RC. Java/Maven/Gradle, Android, Web, JNI, Tauri et les autres familles différées restent hors scope.
|
||||
|
||||
## Scope
|
||||
|
||||
REPLACE :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
CHANGELOG.md
|
||||
docs/plans/004-V0_0_4_SKELETONS_PLAN.md
|
||||
```
|
||||
|
||||
ADD :
|
||||
|
||||
```text
|
||||
prompts/005-V0_0_5_START_PROMPT.md
|
||||
deltas/0.0.4/rc.1.md
|
||||
```
|
||||
|
||||
DELETE : aucun.
|
||||
|
||||
L'archive contient exactement ces fichiers complets. Le history `beta.1.fix.1` est livré séparément ; le history `rc.1` sera produit après la gate opérateur.
|
||||
|
||||
## Gate opérateur de release candidate
|
||||
|
||||
Après application sur le commit `beta.1.fix.1`, depuis la racine du dépôt :
|
||||
|
||||
```bash
|
||||
test "$(cat VERSION)" = '0.0.4-rc.1'
|
||||
git cat-file -e HEAD:history/0.0.4/beta.1.fix.1.md
|
||||
test -f history/0.0.4/beta.1.fix.1.md
|
||||
test -f deltas/0.0.4/rc.1.md
|
||||
test -f prompts/005-V0_0_5_START_PROMPT.md
|
||||
test ! -e history/0.0.4/rc.1.md
|
||||
|
||||
grep -Fx '<!-- version: 6 -->' CHANGELOG.md
|
||||
grep -Fx '## 0.0.4 (candidate)' CHANGELOG.md
|
||||
grep -Fx '<!-- version: 2 -->' docs/plans/004-V0_0_4_SKELETONS_PLAN.md
|
||||
grep -F '`beta.1.fix.1` a rejoué la réconciliation et est `PASS`' docs/plans/004-V0_0_4_SKELETONS_PLAN.md
|
||||
grep -F 'pgr-v0.0.4.zip' prompts/005-V0_0_5_START_PROMPT.md
|
||||
grep -F 'khadhroony-solana-project' prompts/005-V0_0_5_START_PROMPT.md
|
||||
grep -F 'sasedev-games' prompts/005-V0_0_5_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
|
||||
import tomllib
|
||||
|
||||
expected_histories = {
|
||||
'alpha.1.md': 'PASS',
|
||||
'alpha.2.md': 'PASS',
|
||||
'alpha.3.md': 'PASS',
|
||||
'alpha.4.md': 'FAIL',
|
||||
'alpha.4.fix.1.md': 'PASS',
|
||||
'beta.1.md': 'FAIL',
|
||||
'beta.1.fix.1.md': 'PASS',
|
||||
}
|
||||
histories = {path.name for path in Path('history/0.0.4').glob('*.md')}
|
||||
assert histories == set(expected_histories), histories
|
||||
for name, status in expected_histories.items():
|
||||
text = Path('history/0.0.4', name).read_text(encoding='utf-8')
|
||||
assert re.search(rf'## Statut\s+{status}\s', text), (name, status)
|
||||
|
||||
deltas = {path.name for path in Path('deltas/0.0.4').glob('*.md')}
|
||||
assert deltas == set(expected_histories) | {'rc.1.md'}, deltas
|
||||
|
||||
skeletons = sorted(path.name for path in Path('docs/skeletons').glob('*.md'))
|
||||
assert skeletons == [
|
||||
'000-README.md',
|
||||
'001-PROJECT_GOVERNANCE_FOUNDATION.md',
|
||||
'002-RUST_CARGO_WORKSPACE.md',
|
||||
], skeletons
|
||||
|
||||
rule = Path('docs/rules/220-SKELETONS.md').read_text(encoding='utf-8')
|
||||
assert 'Un skeleton sélectionne les owners normatifs applicables ; il ne redéfinit pas leur contenu.' in rule
|
||||
|
||||
foundation = Path('docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md').read_text(encoding='utf-8')
|
||||
for owner in ('200-GOVERNANCE.md', '210-WORKFLOW.md', '300-DOCUMENTATION.md', '400-VALIDATION.md'):
|
||||
assert owner in foundation, owner
|
||||
|
||||
rust = Path('docs/skeletons/002-RUST_CARGO_WORKSPACE.md').read_text(encoding='utf-8')
|
||||
for owner in ('500-LANGUAGES.md', '510-RUST_CARGO.md'):
|
||||
assert owner in rust, owner
|
||||
assert 'Ils ne deviennent jamais des valeurs universelles par simple copie.' in rust
|
||||
|
||||
for path in (
|
||||
Path('templates/rust-cargo/rustfmt.toml'),
|
||||
Path('templates/rust-cargo/clippy.toml'),
|
||||
Path('templates/rust-cargo/.cargo/config.toml'),
|
||||
Path('templates/rust-cargo/Cargo.toml'),
|
||||
Path('templates/rust-cargo/crates/project-core-lib/Cargo.toml'),
|
||||
):
|
||||
with path.open('rb') as stream:
|
||||
tomllib.load(stream)
|
||||
|
||||
prompt = Path('prompts/005-V0_0_5_START_PROMPT.md').read_text(encoding='utf-8')
|
||||
for value in ('pgr-v0.0.4.zip', 'pgr-0.0.4-publish.001-report.md', '0.0.5-alpha.1', 'khadhroony-solana-project', 'sasedev-games'):
|
||||
assert value in prompt, value
|
||||
assert 'Ne pas déduire leur version, leur commit ou leur contenu' in prompt
|
||||
|
||||
print('RC integration audit: clean (7 prior histories, 3 skeleton docs, 5 TOML parsed, prompt 005 ready)')
|
||||
PY
|
||||
|
||||
command -v cargo
|
||||
command -v rustfmt
|
||||
cargo --version
|
||||
rustc --version
|
||||
rustfmt --version
|
||||
cargo clippy --version
|
||||
|
||||
tmp="$(mktemp -d)"
|
||||
trap 'rm -rf "$tmp"' EXIT
|
||||
mkdir -p "$tmp/.cargo" "$tmp/crates/smoke-core-lib/src"
|
||||
cp templates/rust-cargo/Cargo.toml "$tmp/Cargo.toml"
|
||||
cp templates/rust-cargo/rustfmt.toml "$tmp/rustfmt.toml"
|
||||
cp templates/rust-cargo/clippy.toml "$tmp/clippy.toml"
|
||||
cp templates/rust-cargo/.cargo/config.toml "$tmp/.cargo/config.toml"
|
||||
cp templates/rust-cargo/crates/project-core-lib/Cargo.toml "$tmp/crates/smoke-core-lib/Cargo.toml"
|
||||
printf '1.2.3\n' > "$tmp/VERSION"
|
||||
|
||||
python3 -B - "$tmp" <<'PY'
|
||||
from pathlib import Path
|
||||
import sys
|
||||
|
||||
root = Path(sys.argv[1])
|
||||
replacements = {
|
||||
root / 'Cargo.toml': (
|
||||
('# file: templates/rust-cargo/Cargo.toml', '# file: Cargo.toml'),
|
||||
('members = ["crates/project-core-lib"]', 'members = ["crates/smoke-core-lib"]'),
|
||||
('version = "0.1.0"', 'version = "1.2.3"'),
|
||||
),
|
||||
root / 'rustfmt.toml': (
|
||||
('# file: templates/rust-cargo/rustfmt.toml', '# file: rustfmt.toml'),
|
||||
),
|
||||
root / 'clippy.toml': (
|
||||
('# file: templates/rust-cargo/clippy.toml', '# file: clippy.toml'),
|
||||
),
|
||||
root / '.cargo/config.toml': (
|
||||
('# file: templates/rust-cargo/.cargo/config.toml', '# file: .cargo/config.toml'),
|
||||
(
|
||||
'# Replace project-name with a unique name before using this configuration.',
|
||||
'# Smoke fixture: project-specific build directory already selected.',
|
||||
),
|
||||
('../builds/project-name/target', 'target-smoke'),
|
||||
),
|
||||
root / 'crates/smoke-core-lib/Cargo.toml': (
|
||||
(
|
||||
'# file: templates/rust-cargo/crates/project-core-lib/Cargo.toml',
|
||||
'# file: crates/smoke-core-lib/Cargo.toml',
|
||||
),
|
||||
('name = "project-core-lib"', 'name = "smoke-core-lib"'),
|
||||
),
|
||||
}
|
||||
for path, pairs in replacements.items():
|
||||
text = path.read_text(encoding='utf-8')
|
||||
for old, new in pairs:
|
||||
assert old in text, (path, old)
|
||||
text = text.replace(old, new)
|
||||
path.write_text(text, encoding='utf-8')
|
||||
for path in root.rglob('*'):
|
||||
if path.is_file() and path.name != 'Cargo.lock':
|
||||
text = path.read_text(encoding='utf-8')
|
||||
assert 'project-name' not in text, path
|
||||
assert 'project-core-lib' not in text, path
|
||||
print('RC temporary Rust/Cargo template adaptation: clean')
|
||||
PY
|
||||
|
||||
cat > "$tmp/crates/smoke-core-lib/src/lib.rs" <<'RS'
|
||||
//! Minimal crate used to validate the PGR Rust/Cargo templates.
|
||||
|
||||
/// Returns the deterministic smoke value.
|
||||
pub fn smoke_value() -> u8 {
|
||||
return 1;
|
||||
}
|
||||
RS
|
||||
|
||||
(
|
||||
cd "$tmp"
|
||||
cargo metadata --format-version 1 --no-deps >/dev/null
|
||||
cargo fmt --all -- --check
|
||||
cargo check --workspace
|
||||
cargo clippy --workspace --all-targets --all-features -- -D warnings
|
||||
)
|
||||
|
||||
rm -rf "$tmp"
|
||||
trap - EXIT
|
||||
|
||||
git diff --check
|
||||
git add VERSION CHANGELOG.md docs/plans/004-V0_0_4_SKELETONS_PLAN.md \
|
||||
prompts/005-V0_0_5_START_PROMPT.md deltas/0.0.4/rc.1.md
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Le scope attendu avant ajout du history est exactement :
|
||||
|
||||
```text
|
||||
M CHANGELOG.md
|
||||
M VERSION
|
||||
A deltas/0.0.4/rc.1.md
|
||||
M docs/plans/004-V0_0_4_SKELETONS_PLAN.md
|
||||
A prompts/005-V0_0_5_START_PROMPT.md
|
||||
```
|
||||
|
||||
## Revue opérateur complémentaire
|
||||
|
||||
Confirmer que le changelog décrit la release et non ses tranches internes, que les deux `FAIL` historiques restent visibles avec leurs fixes `PASS`, que le prompt `005` ne présume aucune version KSP/Games non fournie et que la RC n'étend pas le périmètre fonctionnel.
|
||||
|
||||
Une gate RC `PASS` n'est ni la promotion stable, ni le tag `v0.0.4`, ni la vérification de l'archive publiée après le tag.
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Produire séparément `history/0.0.4/rc.1.md`, l'appliquer puis committer/pousser la RC avant le delta stable `rel.001`.
|
||||
|
||||
Le history RC et le delta stable MAY être livrés ensemble sous forme de deux archives séparées après observation de cette gate opérateur.
|
||||
|
||||
### FAIL
|
||||
|
||||
Consigner l'échec réel dans `history/0.0.4/rc.1.md` et corriger uniquement le scope gelé dans `rc.1.fix.1`, sauf REPLAN explicite si la candidate révèle un défaut fonctionnel plus large.
|
||||
@@ -1,11 +1,11 @@
|
||||
<!-- file: docs/plans/004-V0_0_4_SKELETONS_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Plan 0.0.4 — skeleton specifications et composition
|
||||
|
||||
## Statut et sources
|
||||
|
||||
Plan actif créé pendant `0.0.4-alpha.1` après audit indépendant de la stable publiée `v0.0.3` demandé par `prompts/004-V0_0_4_START_PROMPT.md`.
|
||||
Plan actif créé pendant `0.0.4-alpha.1` après audit indépendant de la stable publiée `v0.0.3` demandé par `prompts/004-V0_0_4_START_PROMPT.md`. Les tranches `alpha.1` à `alpha.3` sont `PASS`. `alpha.4` a enregistré `FAIL` sur sa gate d'instanciation, puis `alpha.4.fix.1` a corrigé cette gate et est `PASS`. `beta.1` a enregistré `FAIL` sur une erreur de syntaxe de sa gate de réconciliation, puis `beta.1.fix.1` a rejoué la réconciliation et est `PASS`. À l'entrée de `rc.1`, aucun de ces deux fixes n'a nécessité de modifier les règles, skeletons ou templates validés ; le scope fonctionnel est gelé.
|
||||
|
||||
La baseline autoritaire est l'archive source fournie `pgr-v0.0.3.zip`, déclarée téléchargée depuis le tag Gitea `v0.0.3`. Son SHA-256 vérifié pendant le cadrage est :
|
||||
|
||||
@@ -137,10 +137,14 @@ Vérifier ownership, liens, index, absence de duplication normative, non-univers
|
||||
|
||||
Aucun chantier de réconciliation complète avec KSP ou Games n'entre ici : la roadmap réserve cette mission à `0.0.5`.
|
||||
|
||||
La première gate `beta.1` a enregistré `FAIL` uniquement parce qu'une chaîne Python de contrôle contenait une apostrophe non échappée. `beta.1.fix.1` a corrigé la gate sans modifier de contenu vivant et a confirmé la réconciliation : owners distincts, trois documents skeletons seulement, valeurs Rust/Cargo adaptables, limites des audits explicites, cinq TOML valides et domaines différés toujours absents.
|
||||
|
||||
### rc.1 — gate de release candidate
|
||||
|
||||
Geler le scope, préparer l'entrée `0.0.4` du changelog et le prompt `005` de `0.0.5` si la trajectoire est confirmée. Rejouer les validations documentaires, tests et smokes réellement invalidés par la release.
|
||||
|
||||
Le scope gelé comprend le contrat transversal `220-SKELETONS.md`, l'index de collection, la fondation gouvernée `001`, la spécialisation Rust/Cargo `002` et l'utilisation des cinq templates Rust/Cargo déjà présents. Aucun nouveau domaine technologique, générateur, template, audit ou règle normative n'entre en RC. La trajectoire `0.0.5` reste celle de la roadmap : réconciliation réelle de PGR avec `khadhroony-solana-project` et `sasedev-games`, à partir de baselines explicites qui devront être fournies à cette future session plutôt que déduites d'un état local implicite.
|
||||
|
||||
### stable — 0.0.4
|
||||
|
||||
Promouvoir la RC validée, finaliser les documents vivants, produire le history pré-tag, committer et tagger `v0.0.4`, puis vérifier séparément l'archive publiée. La preuve post-tag reste extérieure au tag.
|
||||
|
||||
92
history/0.0.4/rc.1.md
Normal file
92
history/0.0.4/rc.1.md
Normal file
@@ -0,0 +1,92 @@
|
||||
<!-- file: history/0.0.4/rc.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.0.4-rc.1 — gate de release candidate
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La gate opérateur de `0.0.4-rc.1` exécutée le `2026-09-24` valide le gel fonctionnel de la release candidate, sa présentation candidate, le prompt de reprise `005` et le smoke d'instanciation Rust/Cargo. Cette preuve porte sur la RC avant son commit ; elle ne constitue ni la promotion stable, ni le tag `v0.0.4`, ni une vérification post-tag.
|
||||
|
||||
## Baseline et scope observés
|
||||
|
||||
La baseline opérateur est le commit `3f8fa6b` de `0.0.4-beta.1.fix.1`, poussé sur `master` avant application du delta RC. L'opérateur a confirmé `VERSION = 0.0.4-rc.1`, la présence dans `HEAD` de `history/0.0.4/beta.1.fix.1.md`, la présence du delta `rc.1` et du prompt `005`, ainsi que l'absence du présent history avant sa livraison.
|
||||
|
||||
Les révisions et marqueurs attendus ont été retrouvés :
|
||||
|
||||
```text
|
||||
CHANGELOG.md version 6
|
||||
CHANGELOG 0.0.4 (candidate)
|
||||
docs/plans/004-V0_0_4_SKELETONS_PLAN.md version 2
|
||||
beta.1.fix.1 PASS consigné dans le plan
|
||||
prompts/005-V0_0_5_START_PROMPT.md baseline pgr-v0.0.4.zip
|
||||
prompts/005-V0_0_5_START_PROMPT.md khadhroony-solana-project
|
||||
prompts/005-V0_0_5_START_PROMPT.md sasedev-games
|
||||
```
|
||||
|
||||
Le prompt `005` reste conditionnel : il demande explicitement les baselines réelles de KSP et `sasedev-games`, interdit d'en déduire version, commit ou contenu, et ne présente le rapport `pgr-0.0.4-publish.001-report.md` comme disponible que s'il a réellement été produit et validé.
|
||||
|
||||
## Tests et audits documentaires
|
||||
|
||||
Les `15` tests Python ciblés ont tous réussi :
|
||||
|
||||
```text
|
||||
Ran 15 tests in 0.212s
|
||||
OK
|
||||
```
|
||||
|
||||
Les trois audits Markdown ont affiché :
|
||||
|
||||
```text
|
||||
Markdown header audit: clean (120 file(s))
|
||||
Markdown table audit: clean (3 table(s), 120 file(s))
|
||||
Markdown link audit: clean (116 local link(s), 120 file(s))
|
||||
```
|
||||
|
||||
L'audit d'intégration RC a affiché :
|
||||
|
||||
```text
|
||||
RC integration audit: clean (7 prior histories, 3 skeleton docs, 5 TOML parsed, prompt 005 ready)
|
||||
```
|
||||
|
||||
Il confirme notamment les statuts historiques précédents (`alpha.4 = FAIL`, `alpha.4.fix.1 = PASS`, `beta.1 = FAIL`, `beta.1.fix.1 = PASS`), les trois documents de la collection skeletons, les owners attendus, les cinq TOML Rust/Cargo lisibles et la disponibilité du prompt `005`.
|
||||
|
||||
## Smoke Rust/Cargo observé
|
||||
|
||||
La toolchain observée est :
|
||||
|
||||
```text
|
||||
cargo 1.94.1 (29ea6fb6a 2026-03-24)
|
||||
rustc 1.94.1 (e408947bf 2026-03-25)
|
||||
rustfmt 1.8.0-stable (e408947bfd 2026-03-25)
|
||||
clippy 0.1.94 (e408947bfd 2026-03-25)
|
||||
```
|
||||
|
||||
L'adaptation temporaire des cinq templates a terminé par :
|
||||
|
||||
```text
|
||||
RC temporary Rust/Cargo template adaptation: clean
|
||||
```
|
||||
|
||||
Le workspace temporaire `smoke-core-lib v1.2.3` a ensuite passé `cargo metadata`, `cargo fmt --all -- --check`, `cargo check --workspace` et `cargo clippy --workspace --all-targets --all-features -- -D warnings`. Les sorties Cargo de `check` et `clippy` se terminent toutes deux par `Finished dev profile` sans diagnostic bloquant.
|
||||
|
||||
Le répertoire temporaire a été supprimé et le trap désarmé après le smoke ; aucun artefact de cette instanciation n'entre dans PGR.
|
||||
|
||||
## Scope Git
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic. Après ajout des fichiers RC, le statut indexé transmis est exactement :
|
||||
|
||||
```text
|
||||
M CHANGELOG.md
|
||||
M VERSION
|
||||
A deltas/0.0.4/rc.1.md
|
||||
M docs/plans/004-V0_0_4_SKELETONS_PLAN.md
|
||||
A prompts/005-V0_0_5_START_PROMPT.md
|
||||
```
|
||||
|
||||
La revue du contenu confirme que le changelog décrit la release plutôt que ses tranches internes, que les deux `FAIL` historiques restent visibles avec leurs fixes `PASS`, que le prompt `005` ne présume aucune baseline KSP/Games non fournie et qu'aucun nouveau skeleton, profil, template, audit ou domaine technologique n'a été introduit en RC.
|
||||
|
||||
## Transition
|
||||
|
||||
Appliquer ce history puis committer/pousser `0.0.4-rc.1`. Ensuite seulement appliquer le delta stable `rel.001`. La promotion stable reste pré-tag : le tag `v0.0.4`, son archive source Gitea et le rapport post-tag `publish.001` ne pourront être attestés qu'après un `rel.001` PASS, son history, le commit stable et la publication réelle du tag.
|
||||
66
prompts/005-V0_0_5_START_PROMPT.md
Normal file
66
prompts/005-V0_0_5_START_PROMPT.md
Normal file
@@ -0,0 +1,66 @@
|
||||
<!-- file: prompts/005-V0_0_5_START_PROMPT.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Prompt de démarrage 0.0.5 — réconciliation réelle avec KSP et sasedev-games
|
||||
|
||||
## Baseline PGR et cible
|
||||
|
||||
Dépôt canonique PGR : `https://git.sasedev.com/Sasedev/pgr`.
|
||||
|
||||
La baseline PGR attendue au démarrage effectif de `0.0.5` est l'archive source téléchargée depuis le tag Gitea `v0.0.4`, dont le nom attendu est `pgr-v0.0.4.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.0.5`. Première tranche attendue : `0.0.5-alpha.1`.
|
||||
|
||||
Si un rapport séparé `pgr-0.0.4-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.
|
||||
|
||||
## Sources de réconciliation externes
|
||||
|
||||
`0.0.5` doit confronter PGR à des états réels de `khadhroony-solana-project` et `sasedev-games`. Les baselines exactes de ces deux projets doivent donc être fournies explicitement à la session sous forme d'archives, tags ou autres snapshots autoritaires clairement identifiés.
|
||||
|
||||
Ne pas déduire leur version, leur commit ou leur contenu d'une conversation précédente, d'un workspace local non fourni ou d'un souvenir de projet. Si l'une des deux sources manque, l'indiquer et borner l'audit à ce qui est effectivement disponible au lieu de fabriquer une comparaison complète.
|
||||
|
||||
Ces projets sont des corpus de réconciliation. Leurs conventions locales ne deviennent pas automatiquement des règles PGR, et PGR ne doit pas leur imposer rétroactivement une règle sans avoir distingué le besoin commun du besoin spécifique au projet.
|
||||
|
||||
## Reprise manuelle après publication
|
||||
|
||||
Après vérification réelle de l'archive du tag PGR 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 PGR attendus ci-dessus sont confirmés et le rapport est PASS, la base de la phrase est :
|
||||
|
||||
```text
|
||||
Partir de l'archive pgr-v0.0.4.zip téléchargée depuis le tag Gitea v0.0.4 et du rapport post-tag pgr-0.0.4-publish.001-report.md. Lire et exécuter prompts/005-V0_0_5_START_PROMPT.md. Vérifier l'archive PGR et les baselines autoritaires fournies de khadhroony-solana-project et sasedev-games avant de préparer 0.0.5-alpha.1.
|
||||
```
|
||||
|
||||
Si le rapport manque ou n'est pas PASS, retirer sa mention et transmettre son état réel séparément. Adapter également les références KSP/Games aux fichiers ou tags réellement fournis. Ce texte ne doit être remis qu'après clôture stable et vérification post-tag de `0.0.4`, jamais comme attestation anticipée au stade RC.
|
||||
|
||||
## Mission
|
||||
|
||||
Réaliser la première réconciliation explicite de PGR avec deux projets réels qui ont servi de corpus de conception : `khadhroony-solana-project` et `sasedev-games`.
|
||||
|
||||
`alpha.1` MUST commencer par auditer indépendamment la stable `v0.0.4`, ses règles, profils, templates, skeleton specifications, audits et chaîne delta/history. Elle doit ensuite inventorier les règles, conventions, structures et audits réellement présents dans les deux baselines externes fournies, puis classer chaque écart avant toute modification importante.
|
||||
|
||||
La réconciliation doit distinguer au minimum :
|
||||
|
||||
- ce qui est déjà correctement possédé par PGR et seulement appliqué localement ;
|
||||
- ce qui révèle un besoin commun manquant ou insuffisamment spécifié dans PGR ;
|
||||
- ce qui doit rester spécifique à KSP ou à Games ;
|
||||
- ce qui est devenu obsolète, redondant ou contradictoire dans un projet par rapport au modèle PGR actuel ;
|
||||
- ce qui nécessite un nouveau profil, template, skeleton ou audit uniquement si un besoin réel et réutilisable le justifie.
|
||||
|
||||
Fixer ensuite un plan `0.0.5` proportionné. Ne pas transformer la phase d'inventaire en migration massive des projets et ne pas supposer qu'une divergence doit forcément être résolue du côté PGR.
|
||||
|
||||
## Principes de réconciliation
|
||||
|
||||
- Comparer des responsabilités et propriétés concrètes, pas seulement des noms de fichiers ou des structures visuellement similaires.
|
||||
- Conserver un propriétaire normatif unique et éviter de recopier dans PGR une règle déjà possédée ailleurs sous une forme plus générale.
|
||||
- Ne généraliser une convention locale KSP/Games que lorsqu'au moins son besoin et son contrat sont réellement réutilisables.
|
||||
- Préserver les exceptions locales motivées et les contraintes propres à une plateforme, un protocole, une application ou une phase de développement.
|
||||
- Réutiliser les audits PGR existants lorsqu'ils contrôlent déjà la propriété recherchée ; ne pas recréer des scripts composites uniquement parce qu'ils existent dans un projet source.
|
||||
- Vérifier les skeletons `001` et `002` contre des usages réels sans considérer leur adoption intégrale comme obligatoire.
|
||||
- Documenter explicitement les éléments différés si les preuves disponibles ne suffisent pas à créer un owner ou un artefact PGR durable.
|
||||
|
||||
## 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 baselines externes servent à l'analyse et à la preuve. Une modification effective de KSP ou de `sasedev-games`, si elle devient nécessaire, doit être explicitement planifiée et validée dans le scope approprié ; elle ne doit pas être cachée dans un delta PGR.
|
||||
Reference in New Issue
Block a user