# 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. 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. ## 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. ## 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. ## Horizon prévisionnel 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. - `(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é. ## 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 : - recherche/indexation avancée au-delà des capacités PostgreSQL/locales réellement nécessaires ; - adapter Gitea puis autres forges et webhooks forge-only ; - scheduler/jobs de synchronisation 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. 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.