0.0.2-beta.1

This commit is contained in:
2026-09-29 06:10:29 +02:00
parent da5445354e
commit 5cee2a65b0
13 changed files with 541 additions and 47 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
<!-- version: 13 -->
<!-- version: 14 -->
# Architecture de fondation Knowledge
@@ -15,23 +15,25 @@ Le principe directeur reste :
## Workspace Rust matérialisé
`alpha.2` instancie le skeleton PGR `002-RUST_CARGO_WORKSPACE`. `alpha.3` matérialise les trois premières frontières passives :
```text
knowledge-domain-lib famille/source de contenu
knowledge-git-api GitRepository provider-neutral
knowledge-sync-api RepositoryEventSource et signal de réconciliation
```
`alpha.5` complète la fondation avec :
La stable `0.0.1` a matérialisé les premières frontières et le runtime Web :
```text
knowledge-domain-lib famille/source de contenu
knowledge-git-api GitRepository provider-neutral
knowledge-sync-api RepositoryEventSource et signal de réconciliation
knowledge-web-lib composition Actix/Maud et assets Vite
knowledge-pgr-server launcher PGR
knowledge-howtos-server launcher HOWTOs
knowledge-snippets-server launcher snippets
```
`0.0.2` ajoute deux owners réels sans changer la topologie multi-app :
```text
knowledge-git-lib backend Git générique : mirror/refresh/resolve/snapshot
knowledge-app-lib cas d'usage partagé de synchronisation Changed/Unchanged
```
Les deux crates `-api` sont justifiées par des implémentations réellement remplaçables ou multiples. Elles restent sans runtime, sans logging propre et sans dépendance à Actix, Gitea ou PostgreSQL.
Les tests unitaires Rust sont désormais placés hors de `src/` sous `unit_tests/`, conformément à la convention locale Knowledge sélectionnée sur l'option permise par PGR.
@@ -330,9 +332,9 @@ En particulier, Knowledge ne doit pas hériter mécaniquement :
- d’une arborescence d’assets spécifique au corpus ;
- de dépendances TypeScript `@types/*` non justifiées par les packages réellement consommés.
`alpha.4` possède le frontend indépendant et la production du manifest. La clé stable `src/main.ts` constitue l'entrée d'asset commune de départ ; son entrée de manifest doit référencer les sorties JavaScript et CSS générées.
`0.0.1-alpha.4` possède le frontend indépendant et la production du manifest. La clé stable `src/main.ts` constitue l'entrée d'asset commune de départ ; son entrée de manifest doit référencer les sorties JavaScript et CSS générées.
`alpha.5` matérialise `knowledge-web-lib` comme owner partagé de l'intégration Actix/Maud. La crate choisit entre un dev server configuré par `KNOWLEDGE_VITE_DEV_ORIGIN` et un manifest configuré par `KNOWLEDGE_VITE_MANIFEST_PATH`. En production elle dérive le répertoire `assets/` depuis le manifest et le sert sous le préfixe `/assets`, tandis que `KNOWLEDGE_ASSET_BASE_PATH` garde le préfixe d'URL configurable. Les erreurs de configuration/manifest restent récupérables et remontent avant le démarrage du listener.
`0.0.1-alpha.5` matérialise `knowledge-web-lib` comme owner partagé de l'intégration Actix/Maud. La crate choisit entre un dev server configuré par `KNOWLEDGE_VITE_DEV_ORIGIN` et un manifest configuré par `KNOWLEDGE_VITE_MANIFEST_PATH`. En production elle dérive le répertoire `assets/` depuis le manifest et le sert sous le préfixe `/assets`, tandis que `KNOWLEDGE_ASSET_BASE_PATH` garde le préfixe d'URL configurable. Les erreurs de configuration/manifest restent récupérables et remontent avant le démarrage du listener.
Les trois packages `knowledge-pgr-server`, `knowledge-howtos-server` et `knowledge-snippets-server` sont des launchers minces : chacun sélectionne `ServerSite` et le nom de sa variable de bind, puis délègue au runtime commun. Ils ne possèdent aucune logique de rendu ou de manifest dupliquée.
@@ -348,6 +350,21 @@ La fondation matérialisée est cohérente avec les objectifs `0.0.1` :
`0.0.2-alpha.1` conserve cette réconciliation comme baseline : la release courante ouvre uniquement le chemin Git générique de lecture et la synchronisation réelle ; les autres axes restent différés.
## Réconciliation `0.0.2-beta.1`
La mission Git/synchronisation est réconciliée avec l'implémentation réellement obtenue :
- neuf packages Cargo, sans crate placeholder ;
- `knowledge-git-api` provider-neutral et `knowledge-git-lib` comme implémentation process Git contrôlée ;
- sources locales/remotes convergeant vers un mirror contrôlé puis vers une révision commit et un snapshot validé ;
- `knowledge-app-lib` comme unique owner du cas d'usage refresh / resolve / compare / snapshot ;
- dernière révision fournie par l'appelant, sans stockage caché ;
- causes de synchronisation non autoritaires, `Periodic` sans scheduler imposé ;
- règles Knowledge autonomes après l'adoption ponctuelle PGR `v0.1.3` ;
- aucun adapter forge, PostgreSQL, auth/admin complète, écriture Git ou format final HOWTO/snippet introduit par anticipation.
Les besoins de rétention de snapshots, submodules/LFS, partage multi-processus de la racine Git et scheduler concret restent différés jusqu'à preuve d'un besoin réel. Aucune prochaine release n'est numérotée par cette réconciliation.
## 10. Administration
L'administration Web est une interface vers les mêmes cas d'usage que l'édition locale Git, pas une deuxième source de vérité.