0.0.3-rc.1

This commit is contained in:
2026-09-24 13:22:43 +02:00
parent 47114fa96b
commit ec3a101d9b
6 changed files with 219 additions and 5 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md -->
<!-- version: 7 -->
<!-- version: 8 -->
# Plan 0.0.3 — templates initiaux et audits réutilisables
@@ -134,14 +134,18 @@ La comparaison des prompts `002` et `003` confirme une répétition utile à fac
Vérifier ownership, navigation, séparation règle/template/audit, absence de versions universelles arbitraires et proportion des contrôles. Aucun nouveau domaine majeur sans REPLAN.
La revue préparatoire de cette tranche constate que les sept deltas `0.0.3` de `alpha.1` à `alpha.6`, fix inclus, forment une chaîne de versions continue depuis `0.0.2` et possèdent chacun un history `PASS` fondé sur la gate opérateur ; `beta.1` n'a pas encore de history. Les propriétaires restent distincts : profil `510` pour les conventions Rust facultatives, règles `210` et `300` pour workflow et headers, documents de `docs/templates/` pour l'adaptation, scripts monotâches pour les contrôles. Leurs validations ciblées ont été acquises dans les tranches précédentes ; `beta.1` vérifie leur intégration et la navigation sans exiger de nouveau build des projets sources.
La revue préparatoire de cette tranche a constaté que les sept deltas `0.0.3` de `alpha.1` à `alpha.6`, fix inclus, forment une chaîne de versions continue depuis `0.0.2` et possèdent chacun un history `PASS` fondé sur la gate opérateur. Les propriétaires restent distincts : profil `510` pour les conventions Rust facultatives, règles `210` et `300` pour workflow et headers, documents de `docs/templates/` pour l'adaptation, scripts monotâches pour les contrôles. Leurs validations ciblées avaient été acquises dans les tranches précédentes ; `beta.1` a vérifié leur intégration et la navigation sans exiger de nouveau build des projets sources.
Trois écarts documentaires justifient le delta : l'index de `docs/` présentait tous ses templates comme techniques alors que le troisième décrit la reprise de session ; le plan désignait toujours les headers Markdown comme candidat après leur livraison ; la matrice réservait l'audit de liens à `beta/RC/stable` alors que les gates `alpha` l'emploient également sur des changements de navigation. L'index racine ne pointait pas vers le plan actif. Ces renvois sont corrigés dans les documents vivants sans modifier les snapshots ni les choix de version `0.1.0` et d'édition `2024` explicitement présentés comme exemples adaptables dans les manifests et instructions Rust/Cargo. Le résultat de la gate `beta.1` reste à constater par son history séparé.
Trois écarts documentaires justifiaient le delta : l'index de `docs/` présentait tous ses templates comme techniques alors que le troisième décrit la reprise de session ; le plan désignait toujours les headers Markdown comme candidat après leur livraison ; la matrice réservait l'audit de liens à `beta/RC/stable` alors que les gates `alpha` l'emploient également sur des changements de navigation. L'index racine ne pointait pas vers le plan actif. Ces renvois ont été corrigés dans les documents vivants sans modifier les snapshots ni les choix de version `0.1.0` et d'édition `2024` explicitement présentés comme exemples adaptables dans les manifests et instructions Rust/Cargo.
### rc.1 — gate de release candidate
Geler le scope, préparer le changelog et le prompt de la version suivante si la trajectoire est confirmée ; exécuter la gate documentaire et les vérifications ciblées des scripts réellement ajoutés.
La gate opérateur de `beta.1` est `PASS` : `15` tests ciblés, trois audits Markdown, chaîne des sept histories alpha et cinq TOML vérifiés. Son résultat détaillé appartient à `history/0.0.3/beta.1.md`. À l'entrée de `rc.1`, le scope est gelé sur les cinq fichiers Rust/Cargo avec leurs deux guides techniques, la spécification du message manuel, les deux audits de style Rust facultatifs et l'audit des headers Markdown. Les règles et scripts antérieurs restent en place ; aucun profil technologique nouveau, générateur ou skeleton complet n'entre dans cette release.
La RC prépare une entrée candidate `0.0.3` dans le changelog et le prompt `004` de `0.0.4`. La première tranche de cette future version décidera des skeleton specifications réellement justifiées après audit de la stable publiée. L'entrée candidate ne devient une entrée de release publiée qu'à la promotion stable ; le rapport post-tag reste une preuve ultérieure distincte. La gate de `rc.1` et son history sont encore à obtenir.
### stable — 0.0.3
Promouvoir la RC validée, produire le history de clôture pré-tag, committer et tagger, puis contrôler séparément l'archive du tag publiée.