0.0.3-alpha.6

VERSION

@@ -1 +1 @@
-0.0.3-alpha.5
+0.0.3-alpha.6

deltas/0.0.3/alpha.6.md

@@ -0,0 +1,92 @@
+<!-- file: deltas/0.0.3/alpha.6.md -->
+<!-- version: 1 -->
+
+# Delta 0.0.3-alpha.6 — prompt manuel de reprise
+
+## Baseline et version
+
+Baseline : `0.0.3-alpha.5`, avec `history/0.0.3/alpha.5.md` appliqué et committé. Ce delta MUST NOT être appliqué avant ce commit.
+
+Version avant application :
+
+```text
+0.0.3-alpha.5
+```
+
+Version après application :
+
+```text
+0.0.3-alpha.6
+```
+
+## Décision et objet
+
+La comparaison des prompts `002` et `003` et des règles `210-WORKFLOW.md` confirme une répétition utile : baseline taggée, version cible, première tranche et consigne d'audit à la reprise. `003` ajoute une preuve de vérification post-tag distincte et une phrase manuelle à remettre à l'opérateur. La décision conditionnelle de la tranche est donc **retenir** une spécification courte dans `docs/templates/003-NEW_SESSION_PROMPT.md`.
+
+Ce document rassemble les champs à renseigner et une forme de message manuel, avec une branche claire lorsque le rapport post-tag manque ou n'est pas `PASS`. Il ne génère rien, ne fige aucun nom de projet ni preuve et ne prépare pas encore le prompt versionné de `0.0.4`. `docs/rules/210-WORKFLOW.md` reste propriétaire de la séquence delta/history/commit et de la publication après tag ; le plan vivant enregistre la décision.
+
+## Scope
+
+REPLACE :
+
+```text
+VERSION
+docs/rules/210-WORKFLOW.md
+docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
+```
+
+ADD :
+
+```text
+docs/templates/003-NEW_SESSION_PROMPT.md
+deltas/0.0.3/alpha.6.md
+```
+
+DELETE : aucun.
+
+L'archive contient uniquement ces fichiers complets. Aucun history `alpha.6`, prompt `004`, générateur, modification de prompts historiques ou changement de configuration Rust/Cargo n'est inclus.
+
+## Validation opérateur
+
+Après application sur le commit `alpha.5`, depuis la racine du dépôt :
+
+```bash
+test "$(cat VERSION)" = '0.0.3-alpha.6'
+git cat-file -e HEAD:history/0.0.3/alpha.5.md
+test -f history/0.0.3/alpha.5.md
+test -f deltas/0.0.3/alpha.6.md
+test -f docs/templates/003-NEW_SESSION_PROMPT.md
+test ! -e history/0.0.3/alpha.6.md
+test ! -e prompts/004-V0_0_4_START_PROMPT.md
+
+grep -Fx '<!-- version: 3 -->' docs/rules/210-WORKFLOW.md
+grep -Fx '<!-- version: 6 -->' docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
+grep -F '### Retenu : spécification courte du prompt manuel de nouvelle session' \
+    docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
+
+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
+
+git diff --check
+git add VERSION docs/rules/210-WORKFLOW.md \
+    docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md \
+    docs/templates/003-NEW_SESSION_PROMPT.md deltas/0.0.3/alpha.6.md
+git diff --cached --check
+git status --short
+```
+
+Scope attendu avant ajout du history : trois `REPLACE` et deux `ADD`. Revue opérateur : confirmer que le message manuel est actionnable sans supposer un rapport `PASS`, que son contrat versionné est distinct, que les prompts `002`/`003` restent historiques et que la préparation de `0.0.4` n'est pas anticipée.
+
+## Transition
+
+### PASS
+
+Produire séparément `history/0.0.3/alpha.6.md` d'après la gate exécutée, l'appliquer et committer avant de passer à `beta.1` pour la réconciliation de release.
+
+### FAIL
+
+Enregistrer le diagnostic puis corriger uniquement cette spécification et ses renvois dans `alpha.6.fix.1`, sauf REPLAN justifié.

docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Plan 0.0.3 — templates initiaux et audits réutilisables
 
@@ -72,9 +72,9 @@ Ces fichiers ou extraits doivent être copiables et compréhensibles sans figer
 
 Pour la validation, comparer les templates au profil `510`, parser les configs/manifests avec un parseur TOML et exercer sur un workspace d'essai les héritages et le cas d'une exception locale quand les toolchains sont disponibles. Tester `rustfmt` et Clippy pour les réglages réellement livrés dans un projet Rust concerné ; une compilation de KSP/Games n'est pas une gate de PGR.
 
-### Candidat conditionnel : template de prompt manuel de nouvelle session
+### Retenu : spécification courte du prompt manuel de nouvelle session
 
-Les prompts `002` et `003` montrent un besoin récurrent de transmission de la baseline taggée, du rapport post-tag lorsqu'il existe et de la mission suivante. Une courte spécification Markdown réutilisable pourrait décrire les champs nécessaires et leur responsabilité, sans produire un générateur ni un prompt dupliquant tout le plan. La tranche dédiée n'est retenue qu'après avoir démontré que cette factorisation simplifie effectivement la prochaine clôture.
+Les prompts `002` et `003` répètent la transmission de la baseline taggée, de la cible et de la première tranche ; `003` ajoute le rapport post-tag et le texte manuel remis à l'opérateur. Après comparaison, `alpha.6` retient une courte spécification Markdown des champs et de la phrase de reprise. Elle facilite la prochaine clôture sans créer un générateur, un nouveau prompt versionné prématuré ou une copie du plan. Le rapport ne devient un champ rempli que s'il existe et que son résultat est réellement connu.
 
 ### Différés
 
@@ -128,7 +128,7 @@ Extraire le contrôle récurrent en un script read-only monotâche, documenter s
 
 ### alpha.6 — décision sur le template de workflow
 
-Factoriser le prompt manuel seulement si la revue des prompts et du workflow confirme un bénéfice net ; sinon constater explicitement son report et passer à la stabilisation sans artefact artificiel.
+La comparaison des prompts `002` et `003` confirme une répétition utile à factoriser : baseline source, preuve post-tag éventuelle, prompt versionné et gate d'intake. Livrer une spécification courte de rédaction manuelle, détenue par `210-WORKFLOW.md`, sans générateur ni prompt de version suivante avant la clôture stable. Le template reste distinct des configurations Rust/Cargo et ne modifie pas les prompts historiques.
 
 ### beta.1 — réconciliation
 

docs/rules/210-WORKFLOW.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/210-WORKFLOW.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Workflow artifact rules
 
@@ -193,6 +193,8 @@ Le prompt :
 
 Une interruption au milieu d'une version MUST NOT produire artificiellement le prompt de la version suivante.
 
+Lors d'une nouvelle session ouverte depuis une stable publiée, une courte consigne manuelle MAY identifier l'archive du tag, le rapport post-tag lorsqu'il existe réellement, le prompt versionné à lire et la première gate. [`../templates/003-NEW_SESSION_PROMPT.md`](../templates/003-NEW_SESSION_PROMPT.md) décrit une forme réutilisable ; elle ne remplace ni le prompt versionné ni la preuve de publication.
+
 ## Handoff
 
 Un handoff est un snapshot de continuité utilisé lorsqu'un travail doit être repris sans changer artificiellement de version ou de tranche.

docs/templates/003-NEW_SESSION_PROMPT.md

@@ -0,0 +1,29 @@
+<!-- file: docs/templates/003-NEW_SESSION_PROMPT.md -->
+<!-- version: 1 -->
+
+# Spécification du prompt manuel de nouvelle session
+
+## Usage
+
+Cette spécification sert à préparer un court message de reprise après une stable publiée. Le prompt de démarrage propre à la version suivante reste un fichier `prompts/NNN-VX_Y_Z_START_PROMPT.md` finalisé selon [`210-WORKFLOW.md`](../rules/210-WORKFLOW.md). Le message manuel indique où commencer et quelles preuves fournir ; il ne copie ni ce prompt, ni le plan, ni le history de la release.
+
+La comparaison des prompts PGR `002` et `003` montre une structure récurrente (baseline taggée, cible, première tranche et mission). `003` ajoute le rapport de vérification post-tag et un texte transmis explicitement à l'opérateur. Une forme courte commune réduit les oublis lors de la clôture suivante, sans rendre obligatoires des champs propres à PGR dans les autres projets.
+
+## Champs à renseigner
+
+1. **Baseline** : identifier le tag stable, le nom réel de l'archive source téléchargée depuis ce tag et la forge d'origine. Une archive sans `.git` demande une vérification interne ; elle ne prouve pas à elle seule le commit du tag.
+2. **Preuve post-tag** : si un rapport de publication/vérification distinct existe et est réellement `PASS`, indiquer son chemin exact et le joindre. Sinon, signaler explicitement qu'il est absent ou que son état n'est pas `PASS` ; ne jamais fabriquer cette preuve ni la confondre avec le tag.
+3. **Contrat de reprise** : indiquer le chemin du prompt `prompts/NNN-VX_Y_Z_START_PROMPT.md` existant dans la baseline, la version cible et la première tranche attendue. Le prompt versionné possède la mission détaillée et le scope de la release.
+4. **Intake** : demander la vérification de l'archive, des règles applicables, de la gouvernance, de la structure documentaire et des deltas/histories avant de préparer la première tranche. Adapter la liste aux artefacts effectivement présents et aux risques du projet.
+
+## Forme à remplir et à remettre
+
+Après vérification des chemins et de l'état réel du rapport, écrire **une seule phrase** adaptée au projet. Si le rapport est `PASS` et fourni :
+
+```text
+Partir de l'archive <nom exact du ZIP issu du tag vX.Y.Z> et du rapport post-tag <chemin exact du rapport PASS>. Lire et exécuter <chemin du prompt de démarrage dans la baseline>. Vérifier l'archive, les règles, la gouvernance, la structure documentaire, les deltas/histories et la cohérence globale avant de préparer <version cible-alpha.1>.
+```
+
+Si le rapport est absent ou non validé, retirer « et du rapport post-tag ... » de la phrase et préciser séparément son état réel à la nouvelle session. Conserver les noms exacts de la forge et des fichiers du projet : la forme `<nom exact du ZIP>` n'est qu'un champ de rédaction.
+
+Rédiger le texte manuel à la clôture après le contrôle de l'archive publiée et le remettre à l'opérateur. Une interruption au milieu d'une prerelease suit le mécanisme de reprise de la tranche courante prévu dans `210-WORKFLOW.md` ; elle ne crée pas artificiellement un nouveau prompt de version.

history/0.0.3/alpha.6.md

@@ -0,0 +1,40 @@
+<!-- file: history/0.0.3/alpha.6.md -->
+<!-- version: 1 -->
+
+# History 0.0.3-alpha.6 — prompt manuel de reprise
+
+## Statut
+
+PASS
+
+La gate de `alpha.6` exécutée par l'opérateur le `2026-09-24` valide la spécification courte du prompt manuel de nouvelle session et les renvois documentaires associés.
+
+## Baseline et version
+
+L'opérateur a confirmé `VERSION = 0.0.3-alpha.6`, la présence dans `HEAD` de `history/0.0.3/alpha.5.md` par `git cat-file -e`, la présence de ce history dans le répertoire de travail, du delta `alpha.6` et du template `003`, ainsi que l'absence du history courant et de `prompts/004-V0_0_4_START_PROMPT.md` avant cette livraison. Les révisions internes du workflow et du plan sont respectivement `3` et `6` ; la décision de retenir une spécification manuelle figure bien dans le plan.
+
+## Validation opérateur observée
+
+Les trois audits ont affiché :
+
+```text
+Markdown header audit: clean (91 file(s))
+Markdown table audit: clean (3 table(s), 91 file(s))
+Markdown link audit: clean (69 local link(s), 91 file(s))
+```
+
+`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  VERSION
+A  deltas/0.0.3/alpha.6.md
+M  docs/plans/003-V0_0_3_TEMPLATES_AUDITS_PLAN.md
+M  docs/rules/210-WORKFLOW.md
+A  docs/templates/003-NEW_SESSION_PROMPT.md
+```
+
+Le collage du terminal intercale un fragment de la commande `git add` dans la sortie de l'audit des liens ; son résultat final `clean` et les autres contrôles restent lisibles. Aucun échec n'est signalé.
+
+## Transition
+
+Appliquer ce history puis committer `alpha.6` avant le delta `beta.1`. Le commit futur n'est pas attesté par la transcription fournie. La suite prévue est la réconciliation des responsabilités, de la navigation, des templates et des audits avant la RC.