0.0.1-alpha.1.fix.1

docs/objectives/001-PROJECT_OBJECTIVES.md

@@ -1,11 +1,11 @@
 <!-- file: docs/objectives/001-PROJECT_OBJECTIVES.md -->
-<!-- version: 1 -->
+<!-- version: 2 -->
 
 # Objectifs SaseDev Knowledge
 
 ## Mission
 
-SaseDev Knowledge fournit une plateforme contrôlée permettant de publier, relier, rechercher et administrer des contenus de connaissance SaseDev tout en conservant Git comme vérité versionnée et PGR comme référentiel normatif indépendant.
+SaseDev Knowledge fournit un workspace applicatif contrôlé permettant de publier, relier, rechercher et administrer des contenus de connaissance SaseDev tout en conservant Git comme vérité versionnée et PGR comme référentiel normatif indépendant.
 
 ## Façades produit visées
 
@@ -17,7 +17,33 @@ howtos.sasedev.com
 snippets.sasedev.com
 ```
 
-Une même application MAY servir plusieurs hostnames tant que les frontières de contenu restent explicites.
+Ils correspondent à trois applications Actix Web distinctes dans un même workspace :
+
+```text
+knowledge-pgr-server
+knowledge-howtos-server
+knowledge-snippets-server
+```
+
+Cette séparation permet de faire évoluer, déployer et dimensionner chaque façade indépendamment tout en partageant les bibliothèques de domaine, Git, stockage, rendu et observabilité lorsque leur ownership est réellement commun.
+
+## Sources Git de contenu
+
+La fondation retient au minimum trois sources Git indépendantes :
+
+```text
+pgr       -> contenu normatif PGR
+howtos    -> contenu procédural HOWTO
+snippets  -> contenu court/contextualisé
+```
+
+Chaque application possède sa source primaire de publication. L'architecture doit néanmoins permettre plusieurs repositories par famille si le produit l'exige ultérieurement ; les trois dépôts initiaux ne constituent pas une limite codée en dur.
+
+## État applicatif partagé
+
+Les trois applications peuvent et, dans la baseline de fondation, doivent utiliser le même stockage PostgreSQL logique pour l'état transversal de plateforme : identités, sessions, propositions, revues, synchronisation, index et relations calculées.
+
+Ce partage ne fusionne pas les sources de vérité éditoriales : le contenu publié de chaque famille reste autoritaire dans son ou ses repositories Git.
 
 ## Objectifs durables
 
@@ -26,12 +52,14 @@ Knowledge doit permettre à terme :
 - de publier une stable PGR issue d'un tag vérifié, avec un éventuel canal `dev` distinct ;
 - de publier des HOWTOs procéduraux sans leur attribuer une force normative PGR ;
 - de publier des snippets courts et contextualisés ;
+- de déployer séparément les trois façades publiques sans dupliquer la logique partagée ;
 - d'administrer des dépôts publics ou privés ;
 - d'accepter des propositions externes sans écriture directe dans le contenu publié ;
 - de conserver une révision Git de base pour détecter les conflits ;
 - d'utiliser une forge lorsqu'elle apporte des capacités supplémentaires sans la rendre obligatoire ;
 - de servir les lectures publiques depuis des données locales/indexées lorsque la forge distante est indisponible ;
-- de garder les contenus récupérables et intelligibles par un clone Git indépendant du site.
+- de garder les contenus récupérables et intelligibles par un clone Git indépendant du site ;
+- de relier PGR, HOWTOs et snippets via un état/index partagé sans leur donner la même force normative.
 
 ## Non-objectifs de la fondation 0.0.1
 
@@ -44,8 +72,10 @@ Knowledge doit permettre à terme :
 - un déploiement multi-domaines de production ;
 - un moteur de rendu final pour tous les formats ;
 - un système d'authentification complet ;
-- une architecture microservices.
+- une architecture de microservices distribués.
 
 ## Principe de simplicité
 
-Le monolithe modulaire est la baseline architecturale de départ. Une séparation en services n'est introduite que lorsqu'une contrainte observée justifie un nouveau boundary de déploiement.
+La baseline n'est plus un processus Web unique. Elle est un **workspace modulaire multi-app** : trois launchers Actix Web séparés et des crates communes réutilisables.
+
+La séparation des trois façades correspond à une frontière produit explicite ; elle ne doit pas entraîner une multiplication de services internes, de bases ou de crates sans ownership réel. Toute séparation supplémentaire demande une contrainte observée.