0.0.1-alpha.1

docs/objectives/001-PROJECT_OBJECTIVES.md

@@ -0,0 +1,51 @@
+<!-- file: docs/objectives/001-PROJECT_OBJECTIVES.md -->
+<!-- version: 1 -->
+
+# 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.
+
+## Façades produit visées
+
+Les hostnames suivants sont des intentions produit, pas des obligations de déploiement de `0.0.1` :
+
+```text
+pgr.sasedev.com
+howtos.sasedev.com
+snippets.sasedev.com
+```
+
+Une même application MAY servir plusieurs hostnames tant que les frontières de contenu restent explicites.
+
+## Objectifs durables
+
+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 ;
+- 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.
+
+## Non-objectifs de la fondation 0.0.1
+
+`0.0.1` ne cherche pas à livrer :
+
+- un moteur de recherche complet ;
+- une UI d'administration complète ;
+- un workflow de contribution complet ;
+- un support complet Gitea/GitHub/GitLab ;
+- 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.
+
+## 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.