0.0.4-alpha.1
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 6 -->
|
||||
<!-- version: 7 -->
|
||||
|
||||
# Project Governance Rules
|
||||
|
||||
@@ -27,6 +27,7 @@ La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` é
|
||||
- [`docs/plans/001-V0_0_1_FOUNDATION_PLAN.md`](docs/plans/001-V0_0_1_FOUNDATION_PLAN.md) — plan historique de fondation `0.0.1` ;
|
||||
- [`docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md`](docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md) — plan historique des premiers profils `0.0.2` ;
|
||||
- [`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 actif des skeleton specifications `0.0.4` ;
|
||||
- [`docs/validation/001-VALIDATION_MATRIX.md`](docs/validation/001-VALIDATION_MATRIX.md) — matrice de validation.
|
||||
|
||||
## Langue et nomenclature
|
||||
|
||||
150
deltas/0.0.4/alpha.1.md
Normal file
150
deltas/0.0.4/alpha.1.md
Normal file
@@ -0,0 +1,150 @@
|
||||
<!-- file: deltas/0.0.4/alpha.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.0.4-alpha.1 — audit de baseline et cadrage des skeletons
|
||||
|
||||
## Baseline et version
|
||||
|
||||
Baseline : archive source fournie `pgr-v0.0.3.zip`, déclarée téléchargée depuis le tag Gitea `v0.0.3`, accompagnée du rapport externe `pgr-0.0.3-publish.001-report.md` avec statut `PASS`.
|
||||
|
||||
SHA-256 vérifié de l'archive :
|
||||
|
||||
```text
|
||||
517fb46ada098fdc221ae53a8ff4b409b81e0244ec5ce4d0e6fca0c3da61b866
|
||||
```
|
||||
|
||||
Le rapport post-tag annonce le même hash et reste extérieur à la stable. L'archive sans `.git` est contrôlée par son contenu ; elle n'est pas utilisée comme preuve autonome du commit ou de la référence distante du tag.
|
||||
|
||||
Version avant application :
|
||||
|
||||
```text
|
||||
0.0.3
|
||||
```
|
||||
|
||||
Version après application :
|
||||
|
||||
```text
|
||||
0.0.4-alpha.1
|
||||
```
|
||||
|
||||
## Objet
|
||||
|
||||
Exécuter la gate de cadrage imposée par `prompts/004-V0_0_4_START_PROMPT.md` avant toute matérialisation importante : vérifier la stable, les règles `200` à `610`, la gouvernance documentaire, les templates et audits existants, la chaîne delta/history et les limites annoncées ; déterminer ensuite quels skeletons disposent déjà d'entrées suffisantes et planifier les tranches de `0.0.4`.
|
||||
|
||||
Le résultat détaillé de cette revue et le découpage prévisionnel sont consignés dans `docs/plans/004-V0_0_4_SKELETONS_PLAN.md`. Aucun défaut bloquant de `0.0.3` n'impose une correction rétroactive avant ce cadrage.
|
||||
|
||||
Le plan retient comme premières cibles la fondation composable d'un projet gouverné PGR puis un skeleton Rust/Cargo workspace. Java/Maven/Gradle, Android, Web, JNI, Tauri et les autres familles sans pièces suffisantes restent différés.
|
||||
|
||||
## Scope
|
||||
|
||||
REPLACE :
|
||||
|
||||
```text
|
||||
VERSION
|
||||
README.md
|
||||
docs/000-README.md
|
||||
```
|
||||
|
||||
ADD :
|
||||
|
||||
```text
|
||||
docs/plans/004-V0_0_4_SKELETONS_PLAN.md
|
||||
deltas/0.0.4/alpha.1.md
|
||||
```
|
||||
|
||||
DELETE : aucun.
|
||||
|
||||
L'archive delta contient uniquement ces cinq fichiers complets avec leurs chemins relatifs. Aucun history, skeleton concret, nouvelle règle, template technique, script ou manifest de suppression n'appartient à `alpha.1`.
|
||||
|
||||
`README.md` et `docs/000-README.md` sont des documents vivants : ils ajoutent le plan actif comme point d'entrée. `ROADMAP.md` annonce déjà `0.0.4` comme planifiée et `CHANGELOG.md` reste limité aux releases publiées ; ils n'ont pas besoin d'une modification cérémonielle dans cette tranche.
|
||||
|
||||
## Validation opérateur
|
||||
|
||||
Après application sur le commit stable `0.0.3`, depuis la racine du dépôt :
|
||||
|
||||
```bash
|
||||
test "$(cat VERSION)" = '0.0.4-alpha.1'
|
||||
test -f docs/plans/004-V0_0_4_SKELETONS_PLAN.md
|
||||
test -f deltas/0.0.4/alpha.1.md
|
||||
test ! -e history/0.0.4/alpha.1.md
|
||||
|
||||
grep -Fx '<!-- version: 7 -->' README.md
|
||||
grep -Fx '<!-- version: 5 -->' docs/000-README.md
|
||||
grep -F '004-V0_0_4_SKELETONS_PLAN.md' README.md
|
||||
grep -F '004-V0_0_4_SKELETONS_PLAN.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
|
||||
import tomllib
|
||||
|
||||
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)
|
||||
|
||||
expected_counts = {'0.0.1': 12, '0.0.2': 12, '0.0.3': 10}
|
||||
for release, expected in expected_counts.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) == expected, (release, len(deltas))
|
||||
assert deltas == histories, (release, sorted(deltas ^ histories))
|
||||
|
||||
for path in Path('history/0.0.3').glob('*.md'):
|
||||
text = path.read_text(encoding='utf-8')
|
||||
assert re.search(r'## Statut\s+PASS\s', text), path
|
||||
|
||||
for path in (
|
||||
Path('scripts/audit_rust_blank_lines.py'),
|
||||
Path('scripts/audit_rust_const_blocks.py'),
|
||||
Path('scripts/_rust_audit_common.py'),
|
||||
):
|
||||
assert path.is_file(), path
|
||||
|
||||
print('Baseline structural audit: clean (34 prior delta/history pairs, 10/10 histories 0.0.3 PASS, 5 TOML parsed)')
|
||||
PY
|
||||
|
||||
git diff --check
|
||||
git add VERSION README.md docs/000-README.md \
|
||||
docs/plans/004-V0_0_4_SKELETONS_PLAN.md deltas/0.0.4/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.0.4/alpha.1.md
|
||||
M docs/000-README.md
|
||||
A docs/plans/004-V0_0_4_SKELETONS_PLAN.md
|
||||
```
|
||||
|
||||
La vérification du ZIP et du rapport post-tag appartient à l'intake de cette tranche et a été utilisée pour préparer le plan. L'opérateur confirme également que les fichiers fournis sont bien ceux téléchargés pour la reprise, que le hash de l'archive concorde avec le rapport, que le rapport est `PASS` et qu'il n'est pas copié dans le dépôt.
|
||||
|
||||
La revue opérateur doit confirmer que le plan ne transforme pas une prévision en règle active, que les valeurs Rust/Cargo d'exemple restent adaptables et que les domaines différés ne sont pas matérialisés par anticipation.
|
||||
|
||||
## Transition
|
||||
|
||||
### PASS
|
||||
|
||||
Rédiger et livrer séparément `history/0.0.4/alpha.1.md` avec les résultats réellement observés ; l'appliquer et committer la tranche. Préparer seulement ensuite `0.0.4-alpha.2` pour le contrat de composition des skeletons.
|
||||
|
||||
### FAIL
|
||||
|
||||
Consigner le résultat réel dans le history de `alpha.1`, puis corriger le cadrage dans `0.0.4-alpha.1.fix.1` ou produire un REPLAN motivé. Aucun contenu de `alpha.2` ne doit être absorbé silencieusement dans un fix.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Documentation PGR
|
||||
|
||||
@@ -18,9 +18,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.0.3
|
||||
## Points d'entrée de 0.0.4
|
||||
|
||||
- [`plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md`](plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md) — périmètre et décisions de la release `0.0.3` ;
|
||||
- [`plans/004-V0_0_4_SKELETONS_PLAN.md`](plans/004-V0_0_4_SKELETONS_PLAN.md) — cadrage actif des premières skeleton specifications et de leur composition ;
|
||||
- [`templates/001-RUST_CARGO_TOOLING.md`](templates/001-RUST_CARGO_TOOLING.md) et [`templates/002-CARGO_MANIFESTS.md`](templates/002-CARGO_MANIFESTS.md) — adaptation des cinq fichiers Rust/Cargo copiables ;
|
||||
- [`templates/003-NEW_SESSION_PROMPT.md`](templates/003-NEW_SESSION_PROMPT.md) — spécification du message manuel après une stable publiée ;
|
||||
- [`validation/001-VALIDATION_MATRIX.md`](validation/001-VALIDATION_MATRIX.md) et [`validation/002-RUST_STYLE_AUDITS.md`](validation/002-RUST_STYLE_AUDITS.md) — gates PGR et limites des audits de style Rust facultatifs.
|
||||
|
||||
152
docs/plans/004-V0_0_4_SKELETONS_PLAN.md
Normal file
152
docs/plans/004-V0_0_4_SKELETONS_PLAN.md
Normal file
@@ -0,0 +1,152 @@
|
||||
<!-- file: docs/plans/004-V0_0_4_SKELETONS_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# 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`.
|
||||
|
||||
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 :
|
||||
|
||||
```text
|
||||
517fb46ada098fdc221ae53a8ff4b409b81e0244ec5ce4d0e6fca0c3da61b866
|
||||
```
|
||||
|
||||
Le rapport externe `pgr-0.0.3-publish.001-report.md` est fourni séparément, conclut `PASS` et annonce le même hash. Il atteste une vérification post-tag distincte et ne fait pas partie de la stable. L'archive source ne contient pas `.git`, ce qui est conforme au contrat de reprise ; l'identité du commit et du tag décrite dans le rapport n'est pas déduite du contenu du ZIP.
|
||||
|
||||
Les règles applicables au cadrage sont `RULES.md`, les familles `200`, `210`, `300`, `400`, `500`, `510`, `520`, `600`, `610`, ainsi que `docs/architecture/003-RULE_PROFILE_MODEL.md`. Les guides `docs/templates/001` à `003`, les cinq modèles Rust/Cargo, les trois audits Markdown et les deux audits facultatifs de style Rust complètent l'inventaire réel de la stable.
|
||||
|
||||
## Audit indépendant de la stable `v0.0.3`
|
||||
|
||||
L'archive fournie est lisible et son contenu distribué est cohérent dans les contrôles effectués :
|
||||
|
||||
- SHA-256 égal au rapport post-tag ;
|
||||
- `140` entrées ZIP : `115` fichiers et `25` répertoires, avec une seule racine `pgr/` ;
|
||||
- test CRC propre, aucun doublon, aucune collision de casse, aucun chemin absolu ou avec traversée `..`, aucun chemin Windows ambigu et aucun lien symbolique ;
|
||||
- extraction propre de `115` fichiers ; `VERSION` contient exactement `0.0.3` suivi d'un retour à la ligne ; `.git` est absent comme attendu ;
|
||||
- les fichiers distribués sont UTF-8, sans octet NUL, retour CR, espace de fin de ligne ou retour final manquant ;
|
||||
- aucun chemin distribué de build/cache ou secret contrôlé n'est présent ; `.settings/org.eclipse.core.resources.prefs` reste l'exception Eclipse versionnée prévue ;
|
||||
- `99` fichiers Markdown possèdent des headers `file/version` mécaniquement conformes ;
|
||||
- les trois audits Markdown sont propres : `99` fichiers pour les headers, `3` tableaux et `79` liens locaux ;
|
||||
- les `15` tests Python ciblés réussissent ;
|
||||
- les cinq fichiers TOML sous `templates/rust-cargo/` se parsèrent correctement ;
|
||||
- les deux audits de style Rust facultatifs n'ont pas de corpus Rust produit à inspecter dans PGR ; leur comportement est couvert par `tests/test_rust_audits.py` et leur sélection doit rester explicite dans un projet destinataire.
|
||||
|
||||
La chaîne workflow est complète :
|
||||
|
||||
```text
|
||||
0.0.1 : 12 deltas / 12 histories
|
||||
0.0.2 : 12 deltas / 12 histories
|
||||
0.0.3 : 10 deltas / 10 histories
|
||||
```
|
||||
|
||||
Chaque delta possède son history homonyme. Les histories `0.0.3`, de `alpha.1` à `rel.001`, sont tous `PASS`. Les échecs historiques des séries antérieures sont conservés comme snapshots et sont suivis par leurs corrections explicites ; ils ne sont pas réécrits rétroactivement.
|
||||
|
||||
Les limites annoncées restent visibles et cohérentes : l'audit des liens ne valide pas les anchors, l'audit des headers ne juge pas la pertinence sémantique d'une révision, les audits Rust utilisent une analyse lexicale ciblée et l'archive source ne prouve pas elle-même une référence Git distante. Aucun de ces points ne constitue un défaut bloquant de la stable.
|
||||
|
||||
## Revue des règles, profils et propriétaires
|
||||
|
||||
La hiérarchie normative reste cohérente avec le modèle de profils : règles générales, langage/écosystème, plateforme, puis scopes plus spécifiques et exceptions explicites. Aucun profil n'est applicable par simple fréquence ou provenance historique.
|
||||
|
||||
Les responsabilités utiles à `0.0.4` sont distinctes :
|
||||
|
||||
- `200` possède le lifecycle et le rôle de `alpha.1` comme gate de cadrage ;
|
||||
- `210` possède plans, deltas, histories, prompts, baselines et séparation pré-tag/post-tag ;
|
||||
- `300` possède rôles documentaires, documents vivants, snapshots et headers ;
|
||||
- `400` possède la sélection proportionnelle des preuves et l'autorité du gate opérateur ;
|
||||
- `500` et `600` possèdent les contrats communs des profils langage et plateforme ;
|
||||
- `510`, `520` et `610` possèdent respectivement Rust/Cargo, Java/Maven/Gradle et Android ;
|
||||
- `docs/architecture/003-RULE_PROFILE_MODEL.md` possède le modèle de composition et interdit les profils composites sans contrat propre réel.
|
||||
|
||||
La séparation règle / template / skeleton / audit de `docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` reste adaptée. `0.0.4` doit l'étendre par des artefacts concrets sans déplacer les propriétaires normatifs existants.
|
||||
|
||||
## Inventaire des capacités disponibles pour des skeletons
|
||||
|
||||
### Fondation gouvernée PGR — prête à être spécifiée
|
||||
|
||||
Une baseline de projet gouverné constitue une fondation composable, pas une architecture applicative. Les contrats nécessaires existent déjà : versioning, workflow, documentation, validation et modèle de profils. Le skeleton devra indiquer quels artefacts locaux créer ou copier, comment sélectionner les règles réellement applicables et quelles décisions restent propres au projet.
|
||||
|
||||
Il ne doit pas recopier l'historique de PGR, imposer toutes les familles de règles ni créer une dépendance dynamique vers le dépôt PGR.
|
||||
|
||||
### Rust/Cargo workspace — prêt à être spécifié
|
||||
|
||||
Le besoin est suffisamment couvert par des artefacts réels : profil `510`, deux guides d'adaptation, cinq templates Rust/Cargo et deux audits de style facultatifs documentés. Le skeleton pourra composer une fondation gouvernée avec `500 + 510` et sélectionner uniquement les templates nécessaires.
|
||||
|
||||
Les décisions destinataire restent explicites : nom du projet et des crates, version de release, édition/toolchain, métadonnées de publication, membres du workspace, dépendances et features, politique `Cargo.lock`, chemin des artefacts Cargo, seuils Clippy, politique de lints et sélection éventuelle des audits de style. Les valeurs d'exemple `0.1.0`, `2024`, `project-name`, `project-core-lib`, les seuils Clippy et les chemins de build ne deviennent jamais universels.
|
||||
|
||||
### Java / Maven / Gradle — différé
|
||||
|
||||
Le profil `520` définit des règles, mais PGR ne possède encore aucun template Maven/Gradle ou corpus technique éprouvé à instancier. Le choix Maven/Gradle, la politique de wrapper et les versions de toolchain doivent être déterminés dans un chantier justifié avant de produire un skeleton concret.
|
||||
|
||||
### Android — différé
|
||||
|
||||
Le profil `610` définit la structure de responsabilité et les décisions Android, mais aucun template AGP/Gradle, manifest applicatif, matrice SDK ou projet réel n'existe dans PGR. Un skeleton Android serait prématuré avant ces pièces et avant la sélection explicite de sa composition avec Java/Gradle ou un autre stack réel.
|
||||
|
||||
### Web, JNI, Tauri et autres familles absentes — différés
|
||||
|
||||
Ces domaines ne possèdent pas encore tous leurs propriétaires normatifs et templates nécessaires. `0.0.4` ne crée pas de profils ou skeletons placeholders pour eux.
|
||||
|
||||
## Contrat visé pour une skeleton specification
|
||||
|
||||
La tranche de composition devra fixer un contrat commun minimal. Chaque skeleton doit au moins permettre d'identifier :
|
||||
|
||||
```text
|
||||
applicabilité et objectif
|
||||
profils/règles sélectionnés
|
||||
fichiers à créer, copier ou adapter
|
||||
templates applicables et source de leurs choix
|
||||
décisions obligatoires propres au destinataire
|
||||
options et exceptions explicites
|
||||
ordre de composition
|
||||
validation initiale proportionnée
|
||||
éléments volontairement hors scope
|
||||
```
|
||||
|
||||
Un skeleton reste une procédure Markdown. Il ne génère pas le projet, ne télécharge pas de dépendances, ne remplace pas les toolchains et ne fige pas l'architecture future. Après instanciation, le projet possède ses copies locales et ses décisions.
|
||||
|
||||
Les règles communes de sélection et de composition doivent avoir un propriétaire normatif unique sous `docs/rules/`. Les spécifications concrètes vivront dans une collection documentaire dédiée créée seulement avec son premier contenu réel. Les fichiers techniques copiables restent sous `templates/` et leurs instructions d'adaptation sous `docs/templates/`.
|
||||
|
||||
## Découpage prévisionnel de `0.0.4`
|
||||
|
||||
### alpha.1 — audit de stable et cadrage
|
||||
|
||||
Vérifier indépendamment `v0.0.3`, le rapport post-tag, les règles `200` à `610`, les cinq templates Rust/Cargo, les trois audits Markdown, les deux audits Rust facultatifs et la chaîne de deltas/histories. Inventorier les skeletons réellement justifiés et fixer le présent plan avant toute matérialisation importante.
|
||||
|
||||
### alpha.2 — contrat de composition des skeletons
|
||||
|
||||
Créer le propriétaire normatif des règles de sélection et de composition des skeletons, puis la collection documentaire des skeleton specifications avec son index. Définir la frontière entre règles copiées/adaptées, templates techniques, décisions propres au projet, overrides et validation. Réconcilier les index et l'architecture sans créer encore de domaine technologique supplémentaire.
|
||||
|
||||
Le nom et le numéro exacts du document normatif seront choisis à l'application selon la responsabilité finale ; le plan ne transforme pas un chemin prévisionnel en règle déjà active.
|
||||
|
||||
### alpha.3 — fondation de projet gouverné
|
||||
|
||||
Matérialiser une première specification composable décrivant la baseline de gouvernance locale d'un projet utilisant PGR : version, règles sélectionnées, documentation minimale, workflow réellement retenu et validation initiale. Elle doit rester proportionnée et permettre d'omettre les collections ou artefacts sans contenu réel.
|
||||
|
||||
Cette fondation n'est ni un framework ni une architecture applicative et ne doit pas recopier les deltas, histories ou décisions propres au dépôt PGR.
|
||||
|
||||
### alpha.4 — skeleton Rust/Cargo workspace
|
||||
|
||||
Matérialiser la première specialization technologique en composant la fondation gouvernée avec `500 + 510`, les cinq templates Rust/Cargo et les guides d'adaptation existants. Documenter les décisions destinataire avant copie et les audits facultatifs explicitement sélectionnés.
|
||||
|
||||
La gate doit inclure une instanciation temporaire minimale ou une vérification équivalente lorsque la toolchain Rust est disponible, afin de distinguer la validité syntaxique des templates de leur adoption correcte. Cette preuve ne transforme pas PGR lui-même en workspace Rust.
|
||||
|
||||
### beta.1 — réconciliation interne
|
||||
|
||||
Vérifier ownership, liens, index, absence de duplication normative, non-universalisation des valeurs d'exemple, limites des audits et cohérence des deux premières specifications. Confirmer explicitement que Java/Android/Web/JNI/Tauri restent différés tant que leurs pièces requises manquent.
|
||||
|
||||
Aucun chantier de réconciliation complète avec KSP ou Games n'entre ici : la roadmap réserve cette mission à `0.0.5`.
|
||||
|
||||
### 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.
|
||||
|
||||
### 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.
|
||||
|
||||
## Points de décision et stratégie de validation
|
||||
|
||||
Un REPLAN devient nécessaire si la fondation gouvernée exige des templates génériques inexistants pour rester actionnable, si le contrat de composition duplique des règles existantes au lieu de les référencer, si le skeleton Rust impose une architecture plus étroite que le profil `510`, ou si l'instanciation minimale révèle qu'un template technique ne peut pas être adopté sans nouvelle décision normative.
|
||||
|
||||
Les tranches documentaires utilisent les trois audits Markdown et les contrôles Git applicables. Toute modification des scripts ou de leurs contrats rejoue leurs tests ciblés. Toute modification d'un template Rust/Cargo vérifie sa syntaxe et, lorsqu'elle prétend à une instanciation fonctionnelle, une gate Cargo proportionnée dans un environnement temporaire. Aucun build Java/Android n'est demandé tant qu'aucun artefact concret de ces écosystèmes n'entre dans le scope.
|
||||
76
history/0.0.4/alpha.1.md
Normal file
76
history/0.0.4/alpha.1.md
Normal file
@@ -0,0 +1,76 @@
|
||||
<!-- file: history/0.0.4/alpha.1.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.0.4-alpha.1 — audit de baseline et cadrage des skeletons
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La gate de `0.0.4-alpha.1` exécutée par l'opérateur le `2026-09-24` valide la reprise depuis la stable `0.0.3`, le cadrage des premières skeleton specifications et le plan actif de `0.0.4`. Les contrôles mécaniques demandés sont propres et le scope Git observé correspond exactement au delta.
|
||||
|
||||
## Baseline et version
|
||||
|
||||
La tranche a été appliquée sur l'état stable `0.0.3` contrôlé pendant le cadrage depuis l'archive `pgr-v0.0.3.zip` et le rapport post-tag externe `pgr-0.0.3-publish.001-report.md` déclaré `PASS`.
|
||||
|
||||
La version contrôlée après application est :
|
||||
|
||||
```text
|
||||
0.0.4-alpha.1
|
||||
```
|
||||
|
||||
Le plan `docs/plans/004-V0_0_4_SKELETONS_PLAN.md` et le delta `deltas/0.0.4/alpha.1.md` sont présents ; `history/0.0.4/alpha.1.md` était absent pendant la gate. Les révisions attendues de `README.md` et `docs/000-README.md` sont respectivement `7` et `5`, et les deux documents référencent le plan actif.
|
||||
|
||||
## Validation opérateur observée
|
||||
|
||||
L'opérateur a fourni les sorties du `2026-09-24` depuis `~/Projects/pgr`. Le contrôle de `VERSION` a été exécuté à `13:48:46`, puis les autres contrôles et validations à `13:53:25`–`13:53:26`.
|
||||
|
||||
La suite Python globale a exécuté `15` tests, tous réussis :
|
||||
|
||||
```text
|
||||
Ran 15 tests in 0.223s
|
||||
|
||||
OK
|
||||
```
|
||||
|
||||
Les trois audits documentaires affichent :
|
||||
|
||||
```text
|
||||
Markdown header audit: clean (101 file(s))
|
||||
Markdown table audit: clean (3 table(s), 101 file(s))
|
||||
Markdown link audit: clean (81 local link(s), 101 file(s))
|
||||
```
|
||||
|
||||
Le contrôle structurel de la baseline affiche :
|
||||
|
||||
```text
|
||||
Baseline structural audit: clean (34 prior delta/history pairs, 10/10 histories 0.0.3 PASS, 5 TOML parsed)
|
||||
```
|
||||
|
||||
Il confirme notamment l'appariement des `12` deltas/histories de `0.0.1`, des `12` de `0.0.2` et des `10` de `0.0.3`, le statut `PASS` des dix histories `0.0.3`, la présence des trois scripts d'audit Rust attendus et le parsing des cinq fichiers TOML du template Rust/Cargo.
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont affiché aucun diagnostic. Après ajout des fichiers du delta, le statut indexé transmis est exactement :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
A deltas/0.0.4/alpha.1.md
|
||||
M docs/000-README.md
|
||||
A docs/plans/004-V0_0_4_SKELETONS_PLAN.md
|
||||
```
|
||||
|
||||
La transcription du terminal intercale un fragment du heredoc Python avec le début de la sortie `unittest`. Les quinze cas individuels, le résumé final `OK`, les trois audits documentaires, le contrôle structurel et le statut Git restent néanmoins identifiables et ne signalent aucun échec.
|
||||
|
||||
## Revue de cadrage
|
||||
|
||||
La revue du contenu livré confirme que le plan distingue bien les prévisions des règles déjà actives : le contrat commun des skeletons est présenté comme une cible à fixer dans `alpha.2`, et aucun chemin prévisionnel n'est transformé en propriétaire normatif avant sa création effective.
|
||||
|
||||
Les valeurs Rust/Cargo citées dans le plan restent explicitement des exemples ou décisions destinataire à adapter, notamment `0.1.0`, `2024`, `project-name`, `project-core-lib`, les seuils Clippy et les chemins de build. Aucun de ces choix n'est promu en valeur universelle.
|
||||
|
||||
Java/Maven/Gradle, Android, Web, JNI, Tauri et les autres familles sans pièces suffisantes restent explicitement différés. Aucun skeleton concret, profil supplémentaire, template ou artefact technologique de ces domaines n'est matérialisé dans `alpha.1`.
|
||||
|
||||
## Transition
|
||||
|
||||
Appliquer le présent history puis committer `0.0.4-alpha.1` avant tout delta `alpha.2`. Le commit futur n'est pas attesté par les sorties fournies.
|
||||
|
||||
Après ce commit, la tranche suivante est `0.0.4-alpha.2` et doit rester limitée au contrat de sélection et de composition des skeletons, à son propriétaire normatif et à l'index de la collection documentaire correspondante, conformément au plan actif.
|
||||
Reference in New Issue
Block a user