sasedev-knowledge/README.md

SaseDev Knowledge

SaseDev Knowledge est le workspace applicatif destiné à publier et administrer plusieurs familles de connaissance SaseDev sans transformer PGR en encyclopédie technique.

Le dépôt applicatif retenu est sasedev-knowledge. Le nom court du projet et le préfixe de crates sont knowledge.

Statut

La version courante est définie par VERSION.

0.0.1 est une release de fondation. Elle établit la gouvernance, les frontières d'architecture, le workspace minimal, les premiers contrats et les validations nécessaires avant toute implémentation fonctionnelle importante.

Topologie produit de fondation

Le workspace héberge trois applications Web Actix distinctes, correspondant aux trois façades publiques prévues :

knowledge-pgr-server       -> pgr.sasedev.com
knowledge-howtos-server    -> howtos.sasedev.com
knowledge-snippets-server  -> snippets.sasedev.com

Ces trois launchers restent minces et réutilisent les mêmes crates communes lorsqu'une responsabilité est réellement partagée. Leur séparation de processus ne transforme pas le domaine en microservices et n'autorise pas la duplication de logique métier.

Chaque famille possède au minimum sa propre source Git autoritaire : dépôt pgr, dépôt howtos et dépôt snippets. La configuration doit permettre d'ajouter d'autres sources sans figer le système à exactement trois repositories.

PostgreSQL est mutualisable et constitue la baseline retenue pour l'état transversal de la plateforme : comptes, sessions, propositions, synchronisation, index et relations entre familles. Il ne remplace jamais les sources Git comme vérité du contenu publié.

Chaque application Web doit pouvoir exposer sa propre surface d'administration protégée pour son domaine. Les chemins HTTP exacts ne sont pas encore figés. Une éventuelle quatrième application d'administration pourra agréger des fonctions transversales, mais elle ne remplacera pas les contrôles d'autorisation propres aux trois serveurs.

Le workspace Rust matérialise désormais trois frontières passives avant toute implémentation technique : knowledge-domain-lib pour les identités de famille/source, knowledge-git-api pour le contrat Git générique et knowledge-sync-api pour les signaux de synchronisation. Ces deux crates -api sont justifiées par des implémentations remplaçables ou multiples ; elles ne dépendent ni d'Actix, ni de Gitea, ni de PostgreSQL.

Frontend de référence et rendu Maud

Knowledge adopte le profil Web PGR comme partie obligatoire de la fondation. alpha.4 matérialise un package partagé de laboratoire sous Web/knowledge-template-lab/ avec npm, TypeScript strict, Vite, Sass et Bootstrap.

Ce package sert à développer, prévisualiser et valider les assets et templates statiques de référence indépendamment des serveurs Actix. Il n'est pas une quatrième application produit ni une UI de production.

Les templates statiques sont un harness de conception/validation, pas le moteur de rendu de production. Le markup runtime des trois applications sera adapté en Maud. Le build Vite active un manifest et possède une entrée stable src/main.ts dont les assets hashés seront résolus plus tard par l'intégration Maud. Les URL publiques finales, routes admin/login et API Rust du loader restent différées jusqu'aux tranches serveur.

Le mécanisme observé dans actix-auth-app est documenté comme corpus technique à adapter, pas comme code autoritaire à copier.

Invariants de fondation

• Git est la source autoritaire du contenu versionné.
• Une forge est une intégration optionnelle et ne constitue pas une dépendance du domaine.
• Les trois applications publiques sont déployables séparément mais composent des bibliothèques communes.
• PostgreSQL conserve l'état applicatif partagé et les projections ; il ne remplace pas Git comme vérité du contenu publié.
• Chaque serveur Web conserve une frontière d'administration protégée propre à son domaine, indépendamment d'une éventuelle façade d'administration transversale.
• La lecture publique doit pouvoir fonctionner depuis des copies Git locales et un index/cache applicatif sans appel à une forge pour chaque requête.
• PGR, HOWTOs, snippets et décisions project-local conservent des forces et responsabilités documentaires distinctes.
• Une proposition externe ne publie jamais directement du contenu et conserve la révision Git de base utilisée pour sa création.

Entrées principales

• RULES.md — point d'entrée normatif local ;
• ROADMAP.md — trajectoire macro engagée ;
• CHANGELOG.md — changements utiles par release ;
• docs/000-README.md — index documentaire ;
• docs/objectives/001-PROJECT_OBJECTIVES.md — objectifs et non-objectifs ;
• docs/architecture/001-PROJECT_PROFILE.md — baseline PGR, profils/skeletons et matrice de décisions ;
• docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md — architecture de fondation multi-app Git/forge/PostgreSQL et frontières de contenu ;
• docs/studies/001-AUTH_ADMIN_CORPUS_STUDY.md — étude des deux corpus historiques auth/admin et décisions de réutilisation conceptuelle ;
• docs/studies/002-ACTIX_MAUD_VITE_CORPUS_STUDY.md — étude ciblée du pattern Vite manifest / Actix / Maud à adapter pour Knowledge ;
• docs/plans/001-V0_0_1_FOUNDATION_PLAN.md — plan vivant de 0.0.1 ;
• docs/validation/001-VALIDATION_MATRIX.md — matrice de validation ;
• prompts/001-V0_0_1_START_PROMPT.md — prompt de démarrage autoritaire de la release.

Langue et nomenclature

Les noms de fichiers, crates, identifiants et code sont en anglais. La documentation normative et explicative principale est en français.