0.0.3-alpha.1.fix.1

docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/003-V0_0_3_GIT_WRITE_PLAN.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Plan 0.0.3 — écriture Git contrôlée et push gardé
 
@@ -19,7 +19,7 @@ Knowledge start prompt     prompts/003-V0_0_3_START_PROMPT.md
 
 PGR `v0.1.3` reste une provenance historique de l'adoption fermée pendant `0.0.2`. Aucune version PGR plus récente n'est une source de cette release et aucune réévaluation PGR n'est engagée.
 
-`0.0.3-alpha.1` est la tranche courante de cadrage. Aucun history n'existe avant la gate opérateur.
+`0.0.3-alpha.1` a produit une gate technique propre jusqu'aux tests workspace mais reste `PARTIAL` : la fin de gate n'a pas été fournie et la revue opérateur a détecté un mauvais cycle de rédaction du changelog, du prompt suivant et de la roadmap. `0.0.3-alpha.1.fix.1` corrige uniquement ce workflow documentaire avant l'implémentation fonctionnelle.
 
 ## Mission
 
@@ -131,9 +131,20 @@ La gate de `alpha.1` reste une gate de cadrage : elle valide baseline, documenta
 - confirmer l'autonomie normative Knowledge sans nouvelle consultation PGR ;
 - réconcilier les `DEFER` avec la prochaine mission ;
 - produire l'étude `006` ;
-- engager `0.0.3` dans la roadmap ;
+- engager `0.0.3` et établir un premier horizon au-delà d'elle ;
 - mettre à jour les owners/architecture vivants nécessaires ;
 - établir le présent plan ;
+- créer exceptionnellement `prompts/003-V0_0_3_START_PROMPT.md` comme rattrapage, puisque `0.0.2` avait été fermée sans prochaine mission décidée ;
+- ne modifier aucun code sous `crates/` ni `Web/`.
+
+### alpha.1.fix.1 — correction du cycle documentaire
+
+- conserver `alpha.1` comme `PARTIAL` sans réécrire ses preuves ;
+- retirer du changelog l'entrée candidate écrite prématurément ;
+- faire de la roadmap une vue de la release en cours plus un horizon prévisionnel borné ;
+- codifier que le changelog est rédigé vers la stabilisation à partir des changements réellement acquis ;
+- codifier que le prompt de `N+1` est normalement préparé pendant les dernières phases de `N`, après revue d'horizon ;
+- garder `prompts/003-V0_0_3_START_PROMPT.md` comme rattrapage historique valide ;
 - ne modifier aucun code sous `crates/` ni `Web/`.
 
 ### alpha.2 — contrat d'écriture provider-neutral
@@ -167,8 +178,9 @@ La gate de `alpha.1` reste une gate de cadrage : elle valide baseline, documenta
 - réconcilier contrats, implémentation et documentation durable ;
 - vérifier les `DEFER` encore valides ;
 - rejouer la non-régression utile, y compris runtime global si nécessaire à la stabilisation ;
-- décider explicitement si une mission suivante est suffisamment définie pour être engagée ;
-- ne pas numéroter automatiquement une version ultérieure.
+- réévaluer `0.0.4` comme prochaine mission potentielle et l'horizon `0.0.5` / `0.0.6` / `0.0.7` ;
+- réordonner, scinder ou dénuméroter ces horizons si les preuves de `0.0.3` le justifient ;
+- si `0.0.4` est suffisamment décidée, préparer son prompt de démarrage avant la clôture stable de `0.0.3`.
 
 ### rc.1 — candidate stable
 
@@ -180,7 +192,8 @@ La gate de `alpha.1` reste une gate de cadrage : elle valide baseline, documenta
 ### rel.1 — promotion stable pré-tag
 
 - promouvoir mécaniquement `VERSION` et le workspace vers `0.0.3` ;
-- fermer changelog/roadmap/plan sans nouveau scope ;
+- finaliser le changelog à partir du scope réellement acquis ;
+- fermer roadmap/plan sans nouveau scope et vérifier que le handoff de la prochaine release décidée est déjà présent ;
 - rejouer la gate stable prévue ;
 - produire le history observé avant commit produit/tag ;
 - ne fabriquer aucun rapport post-tag avant publication réelle.
@@ -214,10 +227,17 @@ La release est fermable lorsque :
 - les règles/architecture décrivent l'état effectivement obtenu ;
 - beta et RC ont fermé les non-régressions prévues.
 
-Un `PASS` de `alpha.1` autorise uniquement `0.0.3-alpha.2`. Tout autre statut produit d'abord son history puis un fix ou REPLAN selon le diagnostic.
+Le `PARTIAL` de `alpha.1` autorise uniquement `0.0.3-alpha.1.fix.1`. Un `PASS` de ce fix autorise `0.0.3-alpha.2`. Tout autre statut produit d'abord son history puis un nouveau fix ou REPLAN selon le diagnostic.
 
 ## Revue d'horizon
 
-La revue d'horizon n'est pas réalisée en `alpha.1`.
+`alpha.1.fix.1` établit un horizon prévisionnel afin que `0.0.3` ne soit pas développée isolément :
 
-Les thèmes PostgreSQL, proposition/revue, rendu/publication produit, recherche, forge, auth/admin et opérations restent non numérotés. `beta.1` décidera, à partir du retour réel de l'écriture Git, si l'un d'eux devient la prochaine mission.
+```text
+0.0.4  PostgreSQL partagé et migrations
+0.0.5  contenu structuré et lecture publique
+0.0.6  identité / autorisation / administration locale
+0.0.7  propositions / revue / publication
+```
+
+Ces numéros sont des horizons, pas encore des missions engagées. `beta.1` doit les réévaluer à la lumière de l'implémentation réelle de `0.0.3`, confirmer ou modifier la prochaine mission et préparer le prompt de cette mission pendant la fin de `0.0.3` si elle est suffisamment définie. Recherche avancée, adapters de forge, scheduler, administration transverse, opérations multi-domaines et autres `DEFER` restent reclassables ultérieurement.

docs/rules/210-WORKFLOW.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/210-WORKFLOW.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Workflow local Knowledge
 
@@ -102,7 +102,11 @@ Les commandes ne sont pas différées à une réponse ultérieure. Lorsque le de
 
 ## Prompts et changement de session
 
-Un prompt de démarrage versionné décrit la baseline exacte, les sources requises, la mission et les vérifications nécessaires pour ouvrir une release. Il ne complète pas silencieusement des données manquantes par un état supposé d'une conversation ou d'un workspace non vérifié.
+Un prompt de démarrage versionné décrit la baseline attendue, les sources requises, la mission et les vérifications nécessaires pour ouvrir une release. Il ne complète pas silencieusement des données manquantes par un état supposé d'une conversation ou d'un workspace non vérifié.
+
+Le cycle normal prépare le prompt de la release `N+1` pendant les dernières phases de `N`, après la revue d'horizon qui a suffisamment défini la prochaine mission et avant la clôture stable de `N`. Comme le commit/tag/rapport post-tag définitifs de `N` n'existent pas encore à ce moment, le prompt versionné ne doit pas inventer leur SHA ou leur résultat : il exige que l'introduction de la session suivante fournisse l'archive taggée et le rapport post-tag réels et qu'ils soient vérifiés avant développement.
+
+Si une stable historique a été fermée sans prompt de la release suivante parce que la mission n'était pas encore décidée, le prompt peut exceptionnellement être créé au démarrage réel de cette release ; cette situation est un rattrapage et non le cycle normal.
 
 Une coupure de session au milieu d'une tranche ne change pas `VERSION`. Si nécessaire, un handoff local décrit l'état exact, les décisions acquises, les preuves déjà obtenues et ce qui reste à exécuter.
 
@@ -116,7 +120,7 @@ Le tag stable `vX.Y.Z` est créé seulement après le commit stable. L'archive t
 
 Le rapport post-tag `sasedev-knowledge-X.Y.Z-publish.001-report.md` est une preuve distincte. Il vérifie le tag/archive réellement publiés et ne doit pas être préfabriqué comme preuve du delta `rel.1`.
 
-Le prompt d'une release suivante n'est préparé que si sa mission est réellement décidée. Aucune version future n'est inventée pour remplir un handoff.
+Le prompt d'une release suivante n'est préparé que si sa mission est suffisamment décidée par la revue d'horizon. Lorsqu'elle l'est, ce prompt fait partie des artefacts de fin de la release courante afin que la stable publiée contienne déjà son handoff vers la suite. Les éléments post-tag encore inconnus restent à vérifier au démarrage suivant plutôt qu'à être inventés.
 
 ## Immutabilité des artefacts historiques
 

docs/rules/300-DOCUMENTATION.md

@@ -1,5 +1,5 @@
 <!-- file: docs/rules/300-DOCUMENTATION.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Documentation locale Knowledge
 
@@ -22,9 +22,9 @@ La révision documentaire augmente lorsqu'un contenu réel du fichier change ; e
 
 `RULES.md` est l'entrée normative locale et renvoie vers les owners détaillés sous `docs/rules/`.
 
-`ROADMAP.md` décrit les objectifs et horizons produits réellement engagés. Il ne sert ni de journal quotidien ni de catalogue exhaustif des prereleases. Une version future n'y est pas réservée sans mission réelle.
+`ROADMAP.md` décrit la release en cours et un horizon borné des prochaines releases. Il distingue explicitement une mission engagée d'une version d'horizon encore révisable ; l'horizon sert à ordonner les dépendances et à préparer la suite sans transformer chaque intention en engagement irrévocable. Il ne sert ni de journal quotidien ni de catalogue exhaustif des prereleases.
 
-`CHANGELOG.md` synthétise les changements utiles aux jalons de release. Les fixes et essais alpha internes ne sont pas transformés en catalogue exhaustif lorsque leur détail appartient déjà aux deltas/histories.
+`CHANGELOG.md` synthétise les changements réellement acquis d'une release. Il n'est normalement pas rédigé au démarrage ou pendant le cadrage alpha à partir d'intentions : une entrée candidate est préparée vers les phases de stabilisation, lorsque l'implémentation et les histories permettent de décrire ce qui existe effectivement, puis finalisée avant la promotion stable. Les fixes et essais alpha internes ne sont pas transformés en catalogue exhaustif lorsque leur détail appartient déjà aux deltas/histories.
 
 `docs/000-README.md` indexe la documentation durable et fournit le chemin de lecture principal.
 
@@ -64,14 +64,16 @@ Le plan est mis à jour lorsqu'une hypothèse de pilotage devient fausse, pas po
 
 ## Revue d'horizon
 
-Lorsqu'une release approche de sa stabilisation et que la suite n'est pas déjà décidée, une revue d'horizon explicite détermine s'il faut engager une prochaine mission, maintenir les domaines futurs non numérotés ou reclasser un `DEFER`.
+Lorsqu'une release approche de sa stabilisation, une revue d'horizon explicite réévalue la release suivante et, autant que les dépendances sont suffisamment connues, au moins les deux releases d'horizon qui la suivent. Elle peut engager la prochaine mission, réordonner ou scinder un horizon, maintenir un domaine non numéroté ou reclasser un `DEFER`.
 
-La revue n'invente pas un numéro de version uniquement pour assurer la continuité documentaire.
+Une version marquée comme horizon n'est pas encore une promesse de scope : son numéro et sa mission peuvent changer à la revue suivante. La roadmap doit néanmoins donner assez de visibilité pour que la release en cours soit développée dans une trajectoire produit cohérente plutôt qu'en isolation.
 
 ## Prompts de nouvelle session
 
 Un prompt normal Knowledge repart de la stable Knowledge, de son rapport post-tag lorsqu'il existe, puis du prompt versionné local. Il vérifie les artefacts Knowledge locaux avant de préparer la tranche suivante.
 
+Le prompt de la release suivante est normalement rédigé pendant les dernières phases de la release courante, après sa revue d'horizon. Il fait partie du handoff livré par la stable courante. Les identifiants post-tag qui n'existent pas encore lors de sa rédaction ne sont pas inventés : la session suivante les reçoit dans son texte d'introduction et les vérifie contre l'archive et le rapport réellement publiés.
+
 Il MUST NOT demander de rechercher ou charger PGR ou un autre référentiel externe, sauf lorsque cette release contient explicitement une réévaluation/adoption de ce référentiel.
 
 Le pattern local est [`../templates/001-NEW_SESSION_PROMPT.md`](../templates/001-NEW_SESSION_PROMPT.md).

docs/templates/001-NEW_SESSION_PROMPT.md

@@ -1,25 +1,42 @@
 <!-- file: docs/templates/001-NEW_SESSION_PROMPT.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Pattern local — prompt de nouvelle session
 
 ## Usage
 
-Ce pattern prépare le court message opérateur remis après une stable Knowledge publiée. Le prompt détaillé reste un fichier versionné sous `prompts/`.
+Ce pattern prépare le prompt versionné qui permettra d'ouvrir une future release Knowledge.
+
+Le cycle normal crée le prompt de `N+1` pendant les dernières phases de la release `N`, après une revue d'horizon ayant suffisamment défini la mission suivante et avant la clôture stable de `N`. Il doit donc être présent dans la stable `N` publiée.
 
 Une session normale Knowledge ne consulte pas PGR. Une mention PGR n'apparaît que lorsque la release cible contient explicitement une réévaluation/adoption PGR.
 
-## Forme normale
+## Informations connues à la rédaction
 
-Lorsque le rapport post-tag de la baseline est `PASS` :
+Pendant la fin de `N`, les éléments suivants peuvent être établis :
 
 ```text
-Partir de l'archive sasedev-knowledge-vX.Y.Z.zip téléchargée depuis le tag Gitea vX.Y.Z et du rapport post-tag sasedev-knowledge-X.Y.Z-publish.001-report.md. Lire et exécuter prompts/NNN-<NEXT_RELEASE>_START_PROMPT.md. Vérifier intégralement l'archive Knowledge, les règles locales, la gouvernance, l'architecture, la structure documentaire, les deltas/histories, les décisions différées et la cohérence globale avant de préparer <NEXT_RELEASE>-alpha.1.
+release stable attendue   N
+release suivante          N+1
+mission de N+1            décidée par la revue d'horizon
+chemin du prompt           prompts/NNN-<NEXT_RELEASE>_START_PROMPT.md
 ```
 
-`X.Y.Z` désigne la stable autoritaire de départ et `<NEXT_RELEASE>` la release suivante réellement décidée ; ces deux valeurs ne sont pas supposées identiques.
+Le commit stable exact, le SHA-256 de l'archive taggée et le résultat du rapport post-tag de `N` n'existent pas encore nécessairement. Le prompt MUST NOT inventer ces valeurs.
 
-Les noms et versions sont remplacés uniquement par des valeurs établies. Si le rapport post-tag n'existe pas ou n'est pas `PASS`, il n'est pas présenté comme preuve.
+## Forme normale du texte d'introduction de la session suivante
+
+Après publication réelle de `N`, l'opérateur fournit :
+
+```text
+Partir de l'archive sasedev-knowledge-vX.Y.Z.zip téléchargée depuis le tag Gitea vX.Y.Z et du rapport post-tag sasedev-knowledge-X.Y.Z-publish.001-report.md. Considérer cette stable comme la baseline autoritaire de SaseDev Knowledge. Lire et exécuter prompts/NNN-<NEXT_RELEASE>_START_PROMPT.md. Vérifier intégralement l'archive, les règles et owners normatifs locaux, la gouvernance, l'architecture, la structure documentaire, les deltas/histories, les décisions DEFER, la revue d'horizon et la cohérence globale avant de préparer <NEXT_RELEASE>-alpha.1.
+```
+
+Le prompt versionné exige alors de vérifier que l'archive et le rapport fournis correspondent réellement à la stable publiée avant tout développement.
+
+## Rattrapage exceptionnel
+
+Si une stable a été fermée sans prompt suivant parce qu'aucune mission n'était encore décidée, le prompt MAY être créé lors de l'ouverture réelle de la release suivante. Ce cas est documenté comme rattrapage ; il ne devient pas le cycle normal.
 
 ## Réévaluation externe explicite
 

docs/templates/002-RELEASE_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/templates/002-RELEASE_PLAN.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Pattern local — plan de release
 
@@ -30,4 +30,8 @@ Le nombre de tranches n'est pas fixé. Les phases annoncées restent sous `## Tr
 
 Le plan pilote le travail restant ; il n'est pas un journal de commandes. Les preuves détaillées vivent dans `history/` et les règles durables vivent chez leur owner local.
 
-Un REPLAN met à jour la trajectoire et les responsabilités devenues fausses. Aucune version postérieure n'est réservée uniquement pour remplir la roadmap.
+Un REPLAN met à jour la trajectoire et les responsabilités devenues fausses.
+
+La revue d'horizon de fin de release doit réévaluer la prochaine mission et un horizon borné au-delà d'elle. Lorsque `N+1` est suffisamment décidée, la fin de `N` prépare aussi son prompt versionné de démarrage afin que la stable `N` contienne déjà le handoff vers la suite.
+
+Le changelog n'est pas une intention du plan : son entrée de release est préparée vers la stabilisation à partir du résultat réellement matérialisé, puis finalisée avant la promotion stable.