0.0.3-beta.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: 7 -->
+<!-- version: 8 -->
 
 # 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` et `alpha.1.fix.1` sont conservées `PARTIAL` avec leurs preuves réelles. `alpha.1.fix.2` a complété la gate documentaire et technique en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` reste historisée `FAIL` pour son défaut de test `E0369`; `alpha.3.fix.1` a corrigé uniquement cette assertion et sa gate opérateur est `PASS`. `alpha.4` ferme maintenant le scope fonctionnel alpha avec le push gardé et les conflits explicites.
+`0.0.3-alpha.1` et `alpha.1.fix.1` sont conservées `PARTIAL` avec leurs preuves réelles. `alpha.1.fix.2` a complété la gate documentaire et technique en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` reste historisée `FAIL` pour son défaut de test `E0369`; `alpha.3.fix.1` a corrigé uniquement cette assertion en `PASS`. `alpha.4` a fermé le scope fonctionnel alpha en `PASS` avec push gardé, création de branche sous attente d'absence et conflit concurrent sans écrasement. `beta.1` réconcilie maintenant l'état acquis, prépare le changelog candidat, rejoue la non-régression de stabilisation et effectue la revue d'horizon produit.
 
 ## Mission
 
@@ -199,12 +199,16 @@ La gate de `alpha.1` reste une gate de cadrage : elle valide baseline, documenta
 
 ### beta.1 — réconciliation et revue d'horizon
 
-- 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 ;
-- 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`.
+- partir de `alpha.4 = PASS` historisé et committé ;
+- réconcilier contrats, implémentation et documentation durable sans modifier `crates/` ni `Web/` ;
+- préparer `CHANGELOG.md` en état `0.0.3 (candidate)` à partir des capacités réellement acquises ;
+- vérifier les `DEFER` encore valides et reclasser la prochaine dépendance structurante ;
+- retenir `0.0.4` comme fondation PostgreSQL partagée, sans préchoisir driver/ORM avant son étude de démarrage ;
+- étendre l'horizon jusqu'aux phases de modèles/projections, templates publics, templates admin, intégration Actix/Maud et workflow de gestion/proposition/publication des trois sites ;
+- produire l'étude durable `007-V0_0_3_GIT_WRITE_RECONCILIATION.md` ;
+- préparer `prompts/004-V0_0_4_START_PROMPT.md` pendant cette stabilisation, sans inventer commit/tag/SHA postérieurs de `v0.0.3` ;
+- rejouer la non-régression Rust et Web utile à la stabilisation ;
+- n'introduire aucune fonctionnalité PostgreSQL, Web, auth, forge ou proposition dans `0.0.3`.
 
 ### rc.1 — candidate stable
 
@@ -251,17 +255,29 @@ 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.
 
-Le `PARTIAL` de `alpha.1` a autorisé `0.0.3-alpha.1.fix.1`. Le premier fix est resté `PARTIAL`, puis `alpha.1.fix.2` a fermé la preuve en `PASS`. `alpha.2` a ensuite matérialisé le contrat d'écriture provider-neutral avec une gate `PASS`. `alpha.3` est conservée `FAIL` à cause de l'assertion de test `E0369`; `alpha.3.fix.1` corrige uniquement le test et sa gate opérateur est `PASS`. `alpha.4` peut donc fermer le scope fonctionnel alpha par le push gardé et les conflits explicites.
+Le `PARTIAL` de `alpha.1` a autorisé `0.0.3-alpha.1.fix.1`. Le premier fix est resté `PARTIAL`, puis `alpha.1.fix.2` a fermé la preuve en `PASS`. `alpha.2` a matérialisé le contrat d'écriture provider-neutral en `PASS`. `alpha.3` est conservée `FAIL` à cause de l'assertion de test `E0369`; `alpha.3.fix.1` a corrigé uniquement le test en `PASS`. `alpha.4` a ensuite fermé le scope fonctionnel alpha en `PASS`. La beta doit maintenant stabiliser et réconcilier cet état sans nouveau code produit.
 
 ## Revue d'horizon
 
-`alpha.1.fix.1` établit un horizon prévisionnel afin que `0.0.3` ne soit pas développée isolément :
+La revue `0.0.3-beta.1` remplace l'horizon initial trop centré sur les seules briques backend. La prochaine mission suffisamment définie est :
 
 ```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
+0.0.4  fondation PostgreSQL partagée et migrations
 ```
 
-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.
+L'horizon produit devient ensuite :
+
+```text
+0.0.5  modèles de contenu et projections PGR/HOWTO/snippet
+0.0.6  templates publics des trois sites, pages de garde incluses
+0.0.7  templates d'administration des trois sites
+0.0.8  routes publiques Actix Web + adaptation Maud
+0.0.9  auth/autorisation + routes admin Actix Web + adaptation Maud
+0.0.10 gestion/proposition/revue/publication Git + PostgreSQL
+```
+
+Ces versions après `0.0.4` restent des horizons révisables. Elles rendent cependant explicite l'objectif produit : trois sites distincts PGR, HOWTOs et snippets, chacun avec lecture publique et gestion, partageant Git comme vérité éditoriale, PostgreSQL comme état/projection applicative et un pipeline de templates Web validés avant adaptation runtime en Maud.
+
+Recherche avancée, adapters de forge, webhooks forge-only, scheduler, administration transverse, opérations multi-domaines, Git LFS/submodules et partage multi-processus restent non numérotés tant qu'un besoin réel ne les engage pas.
+
+`prompts/004-V0_0_4_START_PROMPT.md` est préparé pendant `beta.1` conformément au cycle normal de handoff. Il exige au prochain démarrage l'archive taggée réelle `v0.0.3` et son rapport post-tag, sans inventer à l'avance le commit stable ou le SHA-256 qui n'existent pas encore.