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.