0.0.4-alpha.2

This commit is contained in:
2026-09-24 14:30:13 +02:00
parent bf306daea6
commit 7408616909
11 changed files with 459 additions and 15 deletions

189
deltas/0.0.4/alpha.2.md Normal file
View File

@@ -0,0 +1,189 @@
<!-- file: deltas/0.0.4/alpha.2.md -->
<!-- version: 1 -->
# Delta 0.0.4-alpha.2 — contrat de composition des skeletons
## Baseline et version
Baseline : commit opérateur `bf306da` (`0.0.4-alpha.1`) après application de `history/0.0.4/alpha.1.md` avec statut `PASS`, puis push sur `origin/master`.
La baseline attendue contient donc le delta, le plan et le history de `alpha.1`, sans contenu `alpha.2` préalable.
Version avant application :
```text
0.0.4-alpha.1
```
Version après application :
```text
0.0.4-alpha.2
```
## Objet
Matérialiser le contrat transversal annoncé par le plan `0.0.4` sans anticiper les skeletons concrets des tranches suivantes.
La tranche crée `docs/rules/220-SKELETONS.md` comme propriétaire normatif unique de l'applicabilité, de la sélection, de la composition, des décisions projet, des overrides et de la validation initiale des skeleton specifications. Elle active également `docs/skeletons/` avec un index réel décrivant la responsabilité de la collection.
Les index normatifs et documentaires ainsi que les deux documents d'architecture concernés sont réconciliés avec ce nouveau propriétaire. Le modèle des profils reste possédé par `docs/architecture/003-RULE_PROFILE_MODEL.md` ; le nouveau document `220` le référence au lieu de dupliquer sa hiérarchie.
Aucun skeleton de fondation, Rust/Cargo, Java/Android, Web, JNI, Tauri ou autre domaine technologique n'appartient à cette tranche.
## Scope
REPLACE :
```text
VERSION
README.md
RULES.md
docs/000-README.md
docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
docs/architecture/003-RULE_PROFILE_MODEL.md
docs/rules/000-README.md
```
ADD :
```text
docs/rules/220-SKELETONS.md
docs/skeletons/000-README.md
deltas/0.0.4/alpha.2.md
```
DELETE : aucun.
L'archive delta contient uniquement ces dix fichiers complets avec leurs chemins relatifs. Elle ne contient pas `history/0.0.4/alpha.1.md`, déjà committé dans la baseline, ni `history/0.0.4/alpha.2.md`, qui sera produit après la gate opérateur.
Le plan `docs/plans/004-V0_0_4_SKELETONS_PLAN.md` n'est pas modifié : la tranche réalise son étape `alpha.2` sans replan ni changement substantiel de trajectoire.
## Décisions normatives matérialisées
Le contrat commun impose notamment qu'un skeleton :
- déclare son objectif et son applicabilité à partir de faits du projet ;
- identifie les règles, profils, templates, fichiers, décisions, options, overrides, ordre utile, validation et hors-scope nécessaires ;
- référence les owners normatifs existants au lieu de devenir propriétaire implicite de leurs règles ;
- conserve les projets instanciés autonomes et sans dépendance runtime/build vers PGR ;
- distingue les valeurs obligatoires, exemples, recommandations et choix libres lorsqu'une confusion serait possible ;
- n'applique pas tous les profils PGR par défaut ;
- n'utilise pas l'ordre de composition comme priorité normative implicite ;
- ne crée pas de skeleton composite sans interaction réelle à posséder ;
- utilise une validation proportionnée au contenu réellement matérialisé.
La collection `docs/skeletons/` reste vide de specification concrète dans `alpha.2` hormis son index. Sa création n'est pas un placeholder : l'index documente le contrat de collection réellement activé par le nouveau owner normatif.
## Validation opérateur
Après application sur le commit `bf306da`, depuis la racine du dépôt :
```bash
test "$(cat VERSION)" = '0.0.4-alpha.2'
test -f history/0.0.4/alpha.1.md
test -f deltas/0.0.4/alpha.2.md
test -f docs/rules/220-SKELETONS.md
test -f docs/skeletons/000-README.md
test ! -e history/0.0.4/alpha.2.md
test ! -e docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
test ! -e docs/skeletons/002-RUST_CARGO_WORKSPACE.md
grep -Fx '<!-- version: 8 -->' README.md
grep -Fx '<!-- version: 10 -->' RULES.md
grep -Fx '<!-- version: 6 -->' docs/000-README.md
grep -Fx '<!-- version: 3 -->' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
grep -Fx '<!-- version: 3 -->' docs/architecture/003-RULE_PROFILE_MODEL.md
grep -Fx '<!-- version: 11 -->' docs/rules/000-README.md
grep -Fx '<!-- version: 1 -->' docs/rules/220-SKELETONS.md
grep -Fx '<!-- version: 1 -->' docs/skeletons/000-README.md
grep -F 'docs/rules/220-SKELETONS.md' RULES.md
grep -F '220-SKELETONS.md' docs/rules/000-README.md
grep -F 'skeletons/' docs/000-README.md
grep -F '220-SKELETONS.md' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
grep -F '220-SKELETONS.md' docs/architecture/003-RULE_PROFILE_MODEL.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_counts = {'0.0.1': 12, '0.0.2': 12, '0.0.3': 10, '0.0.4': 1}
for release, expected in expected_counts.items():
histories = {path.name for path in Path('history', release).glob('*.md')}
if release == '0.0.4':
assert histories == {'alpha.1.md'}, histories
continue
deltas = {path.name for path in Path('deltas', release).glob('*.md')}
assert len(deltas) == expected, (release, len(deltas))
assert deltas == histories, (release, sorted(deltas ^ histories))
text = Path('history/0.0.4/alpha.1.md').read_text(encoding='utf-8')
assert re.search(r'## Statut\s+PASS\s', text)
assert sorted(path.name for path in Path('docs/skeletons').glob('*.md')) == ['000-README.md']
rule = Path('docs/rules/220-SKELETONS.md').read_text(encoding='utf-8')
for phrase in (
'## Applicabilité',
'## Contenu minimal d\'une specification',
'## Sélection des règles et profils',
'## Templates et artefacts techniques',
'## Décisions propres au projet',
'## Composition de plusieurs skeletons',
'## Overrides et exceptions',
'## Validation de l\'instanciation',
):
assert phrase in rule, phrase
print('Skeleton contract audit: clean (alpha.1 PASS baseline, alpha.2 contract/index only)')
PY
git diff --check
git add VERSION README.md RULES.md docs/000-README.md \
docs/architecture/002-GOVERNANCE_ARCHITECTURE.md \
docs/architecture/003-RULE_PROFILE_MODEL.md \
docs/rules/000-README.md docs/rules/220-SKELETONS.md \
docs/skeletons/000-README.md deltas/0.0.4/alpha.2.md
git diff --cached --check
git status --short
```
Le scope indexé attendu avant ajout du history est :
```text
M README.md
M RULES.md
M VERSION
A deltas/0.0.4/alpha.2.md
M docs/000-README.md
M docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
M docs/architecture/003-RULE_PROFILE_MODEL.md
M docs/rules/000-README.md
A docs/rules/220-SKELETONS.md
A docs/skeletons/000-README.md
```
La revue opérateur doit également confirmer que `220-SKELETONS.md` reste transversal, ne duplique pas les règles de profils ou de validation et ne matérialise aucun choix technologique futur par anticipation.
## Transition
### PASS
Rédiger et livrer `history/0.0.4/alpha.2.md` avec les résultats réellement observés ; l'appliquer puis committer la tranche. La tranche suivante est `0.0.4-alpha.3`, consacrée à la première skeleton specification de fondation d'un projet gouverné.
Le history `alpha.2` et le delta `alpha.3` MAY être livrés dans la même réponse après la gate `PASS`, tout en restant deux archives séparées. Le delta `alpha.3` MUST NOT être appliqué avant le commit complet de `alpha.2`.
### FAIL
Consigner le résultat réel dans le history de `alpha.2`, puis corriger le contrat dans `0.0.4-alpha.2.fix.1` ou produire un REPLAN motivé. Aucun skeleton concret de `alpha.3` ne doit être absorbé silencieusement dans un fix.