Sasedev/sasedev-knowledge
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.0.1-alpha.3

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-27 22:23:43 +02:00
parent 8cd187b700
commit 6b6bdcfc71
29 changed files with 1973 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/plans/001-V0_0_1_FOUNDATION_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/001-V0_0_1_FOUNDATION_PLAN.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Plan 0.0.1 — fondation SaseDev Knowledge
@@ -120,18 +120,18 @@ Aucun code fonctionnel n'est ajouté dans `alpha.1` ou son fix.
### alpha.2 — workspace Rust/Cargo minimal
Instancier le skeleton `002-RUST_CARGO_WORKSPACE` sur la fondation : manifest workspace, outillage durable, artefacts Cargo hors dépôt et première crate `knowledge-domain-lib` possédant la frontière de domaine commune.
Statut opérateur : **PASS**.
Décision `Cargo.lock` : le versionner, car Knowledge est un workspace applicatif déployable à train de release unique et doit conserver la résolution effectivement validée.
Étudier les deux corpus historiques auth/admin fournis et formaliser uniquement les enseignements durables : identité partageable, autorisation serveur et surface admin propre à chaque application. Ne pas importer les URL, rôles, OAuth/OIDC, MFA ou écrans inachevés comme exigences.
Les trois packages serveur restent connus architecturalement mais ne sont pas créés dans cette tranche : sans routes/cas d'usage réels, ils seraient encore des placeholders.
Le skeleton `002-RUST_CARGO_WORKSPACE` est matérialisé avec `knowledge-domain-lib`, `Cargo.lock` versionné, artefacts Cargo hors dépôt et étude auth/admin séparant fonctionnalités réelles et intentions historiques. Les gates `metadata`, `fmt`, `check`, Clippy et tests workspace sont propres.
### alpha.3 — contrats domaine/Git/synchronisation
Introduire uniquement les premiers contrats/types nécessaires aux frontières `GitRepository`, source/famille de contenu et synchronisation, avec tests ciblés. Le modèle doit supporter au moins les trois sources initiales sans coder une limite à trois.
Matérialiser `knowledge-git-api` et `knowledge-sync-api` parce que ces frontières ont des implémentations réellement remplaçables/multiples. Garder ces crates passives ; ne pas créer `knowledge-git-lib`, worker, Gitea ou persistence par anticipation.
Adopter les audits Rust PGR de structure/façade désormais utiles avec les premiers items publics partagés. Ne pas activer globalement l'audit `const`, qui reste sélection explicite par fichier.
Ne pas ajouter d'API Gitea ni de persistance PostgreSQL par anticipation.
### alpha.4 — baseline Web indépendante