2.7 KiB
History 0.0.2-rel.001 — promotion stable pré-tag
Statut
PASS
La tranche 0.0.2-rel.001 a été validée par l'opérateur.
La promotion stable vers 0.0.2 est cohérente avant création du tag. Le contrôle post-tag publish.001 reste une étape séparée et doit porter sur l'archive réellement produite depuis le tag v0.0.2.
Baseline
La tranche précédente 0.0.2-rc.1.fix.1 a été validée PASS, puis committée et poussée sous le commit observé :
3ba513d
Version contrôlée après application de rel.001 :
0.0.2
Validation opérateur observée
La version stable a été confirmée :
test "$(cat VERSION)" = "0.0.2"
Les marqueurs de clôture stable ont été retrouvés :
README.md
→ La release `0.0.2` ajoute le premier modèle de profils réutilisables
README.md
→ plan historique des premiers profils `0.0.2`
ROADMAP.md
→ `(x) 0.0.2`
docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
→ Plan clôturé par la promotion stable `0.0.2` après validation de `0.0.2-rc.1.fix.1`.
docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
→ Le contrôle post-tag `publish.001` reste une preuve séparée
Le CHANGELOG.md contient exactement l'entrée :
## 0.0.2
Le prompt de reprise prompts/003-V0_0_3_START_PROMPT.md existe et référence correctement :
v0.0.2
pgr-v0.0.2.zip
pgr-0.0.2-publish.001-report.md
Pairing deltas / histories
La boucle de contrôle a vérifié que chaque delta deltas/0.0.2/*.md antérieur à rel.001.md possède son history correspondant.
Aucun history manquant n'a été signalé.
Audits documentaires
Résultats observés :
Markdown table audit: clean (2 table(s), 72 file(s))
Markdown link audit: clean (50 local link(s), 72 file(s))
Markdown header audit: clean (72 file(s))
Contrôles Git
git diff --check et git diff --cached --check n'ont produit aucun diagnostic.
Le scope Git observé avant ajout du présent history est exactement :
M README.md
M ROADMAP.md
M VERSION
A deltas/0.0.2/rel.001.md
M docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md
Résultat
0.0.2-rel.001 est validée PASS.
L'état est prêt pour :
1. application du présent history ;
2. commit stable `0.0.2` ;
3. push du commit stable ;
4. création du tag `v0.0.2` sur ce commit ;
5. push du tag ;
6. téléchargement de l'archive ZIP produite depuis ce tag ;
7. contrôle post-tag `publish.001` de cette archive réelle ;
8. production de `pgr-0.0.2-publish.001-report.md`.
Le tag ne doit pas être considéré publié correctement tant que publish.001 n'a pas contrôlé l'archive réellement servie par la forge.