0.0.1-alpha.3

This commit is contained in:
2026-09-27 22:23:43 +02:00
parent 8cd187b700
commit 6b6bdcfc71
29 changed files with 1973 additions and 32 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/001-PROJECT_PROFILE.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Profil du projet Knowledge
@@ -38,7 +38,7 @@ Le prompt de démarrage exige néanmoins une matrice `ADOPT / KEEP-LOCAL / OVERR
| `220-SKELETONS` | `ADOPT` pour l'instanciation | `alpha.1` | composition explicite sans copie mécanique |
| `300-DOCUMENTATION` | `ADOPT` | `alpha.1` | rôles documentaires et taxonomie utile |
| `400-VALIDATION` | `ADOPT` | `alpha.1` | preuves proportionnées et autorité opérateur |
| `500-LANGUAGES` + `510-RUST_CARGO` | `ADOPT` | `alpha.2` | backend Rust/workspace Cargo contrôlé |
| `500-LANGUAGES` + `510-RUST_CARGO` | `ADOPT` | `alpha.2+` | backend Rust/workspace Cargo contrôlé |
| `530-TYPESCRIPT` | `ADOPT` | tranche Web | frontend durable TypeScript |
| `540-JAVASCRIPT_PACKAGE_ECOSYSTEM` | `ADOPT` | tranche Web | package manager/lockfile/scripts explicites |
| `550-VITE` | `ADOPT` puisque Vite est retenu | tranche Web | dev server/build/cache/outputs |
@@ -68,7 +68,7 @@ Les profils Java/Maven/Gradle, Android et autres technologies absentes ne sont p
| Synchronisation sans webhook | `KEEP-LOCAL` | explicite/polling constituent le socle ; hooks/webhooks sont des accélérateurs |
| PostgreSQL | `KEEP-LOCAL` | une base logique partagée pour l'état transversal et les projections ; jamais vérité du contenu Git publié |
| Rust stable / édition 2024 | `ADOPT` | profil Rust/Cargo PGR |
| Workspace Cargo | `ADOPT` | skeleton Rust/Cargo ; matérialisation `alpha.2` |
| Workspace Cargo | `ADOPT` | skeleton Rust/Cargo ; actif depuis `alpha.2` |
| `Cargo.lock` | `KEEP-LOCAL` | versionné : workspace applicatif déployable, résolution reproductible entre opérateur et livraisons |
| Actix Web | `KEEP-LOCAL` | trois launchers serveur distincts ; PGR ne possède pas de profil Actix dédié |
| Maud | `KEEP-LOCAL` | rendu SSR initial lorsque pertinent |
@@ -100,14 +100,21 @@ knowledge-howtos-server launcher Actix Web de la façade HOWTOs
knowledge-snippets-server launcher Actix Web de la façade snippets
```
Ils ne sont pas encore matérialisés en `alpha.2`. Lorsqu'ils le seront, leurs `main.rs` resteront minces et composeront les bibliothèques réutilisables. Chacun doit pouvoir protéger sa propre surface d'administration métier.
Ils ne sont pas encore matérialisés en `alpha.3`. Lorsqu'ils le seront, leurs `main.rs` resteront minces et composeront les bibliothèques réutilisables. Chacun doit pouvoir protéger sa propre surface d'administration métier.
Les responsabilités de bibliothèques suivantes restent candidates et ne deviennent des packages que lorsqu'elles possèdent un ownership réel :
Les responsabilités matérialisées sont :
```text
knowledge-domain-lib types métier stables de famille/source ; aucune dépendance Actix/Git-provider/forge/PostgreSQL
knowledge-git-api contrat passif GitRepository ; implémentations génériques remplaçables derrière cette frontière
knowledge-sync-api contrat passif RepositoryEventSource et signaux de réconciliation ; plusieurs mécanismes producteurs prévus
```
Les responsabilités suivantes restent candidates et ne deviennent des packages que lorsqu'elles possèdent un ownership réel :
```text
knowledge-domain-lib ownership des contrats et types métier stables ; crate matérialisée en alpha.2 sans contrats Git prématurés
knowledge-app-lib orchestration des use cases transversaux, si la séparation apporte une valeur réelle
knowledge-git-lib implémentation Git générique
knowledge-git-lib implémentation Git générique de knowledge-git-api
knowledge-store-postgres-lib état applicatif PostgreSQL partagé
knowledge-forge-gitea-lib adapter Gitea optionnel
knowledge-web-lib composition Web réellement partagée, seulement si les trois serveurs dupliqueraient sinon du code

View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Architecture de fondation Knowledge
@@ -15,7 +15,15 @@ Le principe directeur reste :
## Workspace Rust matérialisé
`alpha.2` instancie le skeleton PGR `002-RUST_CARGO_WORKSPACE` avec une première crate `knowledge-domain-lib`. Cette crate possède la frontière de domaine commune mais n'introduit pas encore les contrats Git/synchronisation réservés à `alpha.3`.
`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
```
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.
Le workspace est une application déployable à train de release unique ; `Cargo.lock` est donc versionné pour conserver la résolution effectivement vérifiée. Les artefacts Cargo sont dirigés hors du dépôt vers `../builds/sasedev-knowledge/target/`.
@@ -50,6 +58,10 @@ knowledge-pgr-server knowledge-howtos-server knowledge-snippets-server
La dépendance pointe vers les contrats métier. Les détails Actix, processus Git, API Gitea ou SQL ne remontent pas dans le domaine.
`GitRepository` ne porte que les opérations génériques actuellement nécessaires : rafraîchir la vue locale d'une source et résoudre une référence opaque vers une révision Git autoritaire. Le contrat ne suppose ni API de forge, ni type de remote particulier, ni format SHA figé.
`RepositoryEventSource` ne produit qu'un `RepositorySyncSignal` associé à un `source_id`. La cause est volontairement grossière (`Explicit`, `Periodic`, `ExternalSignal`) afin que hook Git, webhook de forge ou watcher ne deviennent pas des concepts autoritaires du domaine.
## 1. Applications publiques
Les trois façades publiques sont des unités de déploiement distinctes :

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

View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Matrice de validation Knowledge
@@ -161,3 +161,22 @@ La tranche doit prouver :
- étude auth/admin présente avec distinction entre fonctionnalités câblées, préparatoires et seulement annoncées ;
- surfaces admin locales documentées sans figer `/admin`, `/login` ou un modèle de rôles ;
- hygiène Git et headers documentaires applicables.
## Gate de `0.0.1-alpha.3`
La tranche doit prouver :
- `VERSION = 0.0.1-alpha.3` et `[workspace.package].version` identique ;
- trois packages seulement : `knowledge-domain-lib`, `knowledge-git-api`, `knowledge-sync-api` ;
- `knowledge-git-api` et `knowledge-sync-api` comme crates passives sans dépendance Actix, Gitea, PostgreSQL ou runtime ;
- source/famille de contenu capables de représenter plus de trois sources configurées ;
- `GitRepository` indépendant d'une forge et sans format de hash Git figé ;
- `RepositoryEventSource` produisant un signal non autoritaire lié à un `source_id` ;
- `Cargo.lock` régénéré par Cargo et versionné après ajout des deux packages ;
- `cargo fmt --all -- --check`, `cargo check --workspace` et Clippy strict ;
- tests ciblés des trois crates ;
- audits Rust PGR sélectionnés propres, y compris la façade crate-root ;
- absence de `knowledge-git-lib`, adapter Gitea, schéma PostgreSQL, Actix Web et frontend ;
- hygiène Git et headers documentaires/code applicables.
L'audit `audit_rust_const_blocks.py` n'appartient pas à la gate globale de cette tranche.