0.0.3-beta.1

ROADMAP.md

@@ -1,43 +1,47 @@
 <!-- file: ROADMAP.md -->
-<!-- version: 10 -->
+<!-- version: 11 -->
 
 # Roadmap SaseDev Knowledge
 
-La roadmap montre la release effectivement en cours et un horizon borné des releases suivantes. Une release d'horizon reste prévisionnelle tant qu'une revue d'horizon ne l'a pas engagée comme prochaine mission ; son numéro, son ordre ou son scope peuvent encore être replanifiés.
+La roadmap montre la release effectivement en cours et un horizon borné des releases suivantes. Une release d'horizon reste prévisionnelle tant qu'elle n'est pas ouverte : son numéro, son ordre ou son scope peuvent encore être replanifiés par une revue d'horizon ultérieure.
 
 Statuts : `( )` engagée/planifiée, `(x)` terminée, `(h)` horizon prévisionnel, `(d)` différée, `(c)` annulée.
 
 ## Fondation
 
-- `(x) 0.0.1` — fondation Knowledge : gouvernance PGR, workspace à trois applications Actix Web, architecture Git/forge/PostgreSQL partagé, frontières PGR/HOWTO/snippet, contrat d'administration locale protégée sans UI/auth complète, workspace Rust, premiers contrats, baseline Web reproductible, rendu Maud et intégration réelle du manifest Vite, sans implémentation métier disproportionnée.
+- `(x) 0.0.1` — fondation Knowledge : gouvernance locale, workspace à trois applications Actix Web, architecture Git/forge/PostgreSQL partagé, frontières PGR/HOWTO/snippet, baseline Web reproductible, rendu Maud et intégration réelle du manifest Vite, sans implémentation métier disproportionnée.
 
 ## Releases livrées
 
-- `(x) 0.0.2` — implémentation Git générique et synchronisation de lecture : backend provider-neutral derrière `knowledge-git-api`, configuration de sources locales/remotes, matérialisation locale reproductible, refresh/résolution de révision, snapshot/worktree de lecture et convergence des déclencheurs explicite/périodique vers un même cas d'usage, sans API de forge obligatoire, écriture/publication Git, PostgreSQL ni format final HOWTO/snippet.
+- `(x) 0.0.2` — Git générique et synchronisation de lecture : backend provider-neutral, sources locales/remotes, mirror contrôlé, refresh/résolution de révision, snapshot/worktree de lecture et cas d'usage partagé `Changed` / `Unchanged`, sans forge obligatoire ni persistance PostgreSQL.
 
 ## Release en cours
 
-- `( ) 0.0.3` — écriture Git contrôlée et push gardé : contrat d'écriture provider-neutral distinct de la lecture, worktree d'écriture isolé, mutations confinées, commit avec identité explicite et mise à jour d'une branche `refs/heads/...` seulement lorsque son état distant correspond à l'attente fournie ; sans forge obligatoire, rebase/merge automatique, PostgreSQL ni workflow complet de proposition.
+- `( ) 0.0.3` — écriture Git contrôlée et push gardé : contrat d'écriture séparé de la lecture, worktree candidat isolé, mutations confinées, commit à identité explicite et mise à jour d'une branche `refs/heads/...` uniquement lorsque son état distant correspond à l'attente fournie ; divergence = conflit récupérable, sans rebase/merge automatique ni forge obligatoire.
 
-## Horizon prévisionnel
+## Horizon produit après 0.0.3
 
-L'ordre ci-dessous exprime l'horizon de travail actuel. Il sert à préparer les dépendances et éviter qu'une release soit décidée isolément ; il n'engage pas ces releases avant leur revue d'horizon dédiée.
+La revue `0.0.3-beta.1` retient `0.0.4` comme prochaine mission si `0.0.3` ferme sa RC/stable sans découverte bloquante. Les versions suivantes restent des horizons : elles explicitent la trajectoire des trois produits Web sans figer prématurément leurs détails.
 
-- `(h) 0.0.4` — persistance PostgreSQL partagée : premier schéma réel, migrations, configuration logique persistante des sources et état de synchronisation nécessaire aux futurs cas d'usage transversaux, sans déplacer le contenu publié hors de Git.
-- `(h) 0.0.5` — contenu structuré et lecture publique : formats/corpus réels PGR, HOWTO et snippet, normalisation/parsing, relations utiles et rendu public depuis la révision Git/index local, sans workflow complet de contribution.
-- `(h) 0.0.6` — identité, autorisation et administration locale : comptes/sessions, rôles ou capabilities réellement nécessaires et surfaces d'administration protégées par façade, sans créer une quatrième application sans ownership démontré.
-- `(h) 0.0.7` — propositions, revue et publication : proposition basée sur une révision Git, revue/audit applicatif, détection de conflit et publication produisant une révision Git autoritaire avant exposition comme contenu publié.
+- `(h) 0.0.4` — fondation PostgreSQL partagée : premier schéma réel et migrations, configuration logique persistante des sources, dernière révision synchronisée/indexée et état transversal minimal reconstructible ; Git reste autoritaire pour le contenu publié.
+- `(h) 0.0.5` — modèles de contenu et projections : corpus réels PGR/HOWTO/snippet, parsing/validation, métadonnées et relations utiles, projection locale lisible depuis Git + PostgreSQL et contrats de lecture nécessaires aux trois façades.
+- `(h) 0.0.6` — templates publics des trois sites : développer et valider dans `Web/knowledge-template-lab` les pages de garde, navigation, listes, détails, recherche/filtrage visible et composants partagés pour PGR, HOWTOs et snippets, sans encore faire de ces templates le rendu runtime définitif.
+- `(h) 0.0.7` — templates d'administration des trois sites : dashboards et surfaces de gestion propres à PGR, HOWTOs et snippets, formulaires/états de proposition et revue nécessaires au produit, toujours comme références Web validables avant adaptation serveur.
+- `(h) 0.0.8` — lecture publique Actix Web / Maud : matérialiser les routes publiques réelles des trois serveurs, alimentées par Git/projections locales, et adapter en Maud les templates publics validés tout en conservant le pipeline Vite/assets commun.
+- `(h) 0.0.9` — administration Actix Web / Maud et autorisation : matérialiser identité/session/capabilities réellement nécessaires, routes admin protégées par façade et adaptation Maud des templates d'administration validés.
+- `(h) 0.0.10` — gestion, proposition, revue et publication : relier les interfaces d'administration aux cas d'usage d'édition, conserver la révision Git de base, gérer les conflits, produire/pousser la révision Git autoritaire puis réconcilier les projections PostgreSQL.
 
 ## Domaines ultérieurs à reclasser
 
-Les thèmes suivants restent volontairement non numérotés tant que l'horizon ci-dessus n'a pas été réévalué ou qu'un besoin plus prioritaire ne les engage pas :
+Les thèmes suivants restent volontairement non numérotés ou peuvent être absorbés dans une release d'horizon seulement lorsqu'un besoin mesuré le justifie :
 
-- recherche/indexation avancée au-delà des capacités PostgreSQL/locales réellement nécessaires ;
+- recherche/indexation avancée au-delà des capacités PostgreSQL et des projections réellement nécessaires aux façades ;
 - adapter Gitea puis autres forges et webhooks forge-only ;
-- scheduler/jobs de synchronisation ou publication ;
+- scheduler/jobs de synchronisation, indexation ou publication ;
 - quatrième application d'administration transverse ;
 - déploiement/opérations multi-domaines ;
 - partage concurrent d'une même racine Git entre plusieurs processus ;
-- support explicite Git LFS/submodules et politiques de rétention/cleanup avancées.
+- support explicite Git LFS/submodules et politiques de rétention/cleanup avancées ;
+- observabilité transversale ou service réseau supplémentaire sans ownership démontré.
 
-La revue d'horizon de chaque release doit vérifier la release suivante et réévaluer au moins les deux releases qui la suivent. Elle peut conserver, réordonner, fusionner, scinder ou dénuméroter un élément d'horizon lorsque les preuves produit ou techniques le justifient.
+Chaque revue d'horizon doit vérifier la prochaine mission et réévaluer au moins les deux releases qui la suivent. Elle peut conserver, réordonner, fusionner, scinder ou dénuméroter un horizon lorsque les preuves produit ou techniques le justifient.