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

0.0.1-alpha.5

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-28 09:50:20 +02:00
parent 8f6f072e11
commit c17b7068a3
26 changed files with 1952 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/architecture/001-PROJECT_PROFILE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/001-PROJECT_PROFILE.md -->
<!-- version: 6 -->
<!-- version: 7 -->
# Profil du projet Knowledge
@@ -70,8 +70,8 @@ Les profils Java/Maven/Gradle, Android et autres technologies absentes ne sont p
| Rust stable / édition 2024 | `ADOPT` | profil Rust/Cargo PGR |
| 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 |
| Actix Web | `KEEP-LOCAL` | trois launchers matérialisés en `alpha.5` et composition partagée dans `knowledge-web-lib` |
| Maud | `KEEP-LOCAL` | rendu SSR commun matérialisé dans `knowledge-web-lib` en `alpha.5` |
| TypeScript | `ADOPT` | conforme au owner `530` et à l'intention locale |
| Package manager frontend | `KEEP-LOCAL` | npm sélectionné en `alpha.4` ; `package-lock.json` versionné |
| Vite | `KEEP-LOCAL` + owner `550` adopté | build/preview des templates et assets de référence ; manifest de production consommé par l’intégration Maud |

8
docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
<!-- version: 6 -->
<!-- version: 7 -->
# Architecture de fondation Knowledge
@@ -264,7 +264,11 @@ 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. `alpha.5` possède l’intégration Actix/Maud et doit décider si le loader d’assets devient une crate/lib partagée entre les trois serveurs.
`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.
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.
## 10. Administration

15
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: 10 -->
<!-- version: 11 -->
# Plan 0.0.1 — fondation SaseDev Knowledge
@@ -181,10 +181,11 @@ La gate opérateur d'`alpha.4.fix.1` reste **FAIL**. L'hygiène Git est corrigé
L'audit structurel du fix contenait également une vérification trop large de tous les `*.d.ts` sous `Web/`, incluant `node_modules`; il doit être limité aux déclarations appartenant au source du projet.
`alpha.4.fix.2` ajoute donc `@types/node` sur la branche Node 24, expose les types `node`, ajoute `ESNext.Disposable` et corrige uniquement la gate structurelle associée. Aucun scope runtime n'est ajouté.
Sa gate opérateur est **PASS** : typecheck et build Vite passent, le manifest est valide, les gates Rust restent propres et le warning `@parcel/watcher` demeure seulement observable sans approbation automatique.
### alpha.5 — composition Actix/Maud et manifest Vite
Matérialiser le minimum Actix Web/Maud nécessaire pour prouver trois launchers minces et intégrer les assets produits par `alpha.4` :
Matérialiser `knowledge-web-lib` comme owner partagé de la composition Actix/Maud et trois launchers minces :
```text
knowledge-pgr-server
@@ -192,11 +193,15 @@ knowledge-howtos-server
knowledge-snippets-server
```
Ils doivent composer les mêmes contrats/bibliothèques lorsque la responsabilité est partagée et rester capables de recevoir des configurations de sources Git distinctes.
Les launchers ne possèdent que la sélection de façade et du nom de variable de bind. `knowledge-web-lib` possède les routes publiques minimales `/` et `/healthz`, le rendu Maud et l'intégration Vite.
Le HTML runtime est rendu avec Maud. En développement, la composition MAY cibler le dev server Vite configuré ; en production, elle MUST résoudre les assets hashés via le manifest Vite ou un mapping équivalent produit par la chaîne Web. Le pattern de `actix-auth-app` est à adapter sous les règles Knowledge, notamment sans `panic!` et sans origin/port codé en dur.
En développement, `KNOWLEDGE_VITE_DEV_ORIGIN` fournit l'origin et la page charge `@vite/client` puis `src/main.ts`. En production, `KNOWLEDGE_VITE_MANIFEST_PATH` fournit le manifest ; l'entrée stable `src/main.ts` est résolue vers ses assets hashés et le répertoire `assets/` est servi par Actix Files. `KNOWLEDGE_ASSET_BASE_PATH` garde le préfixe de production configurable. Configurer simultanément dev-origin et manifest est une erreur récupérable.
La tranche ne doit pas introduire admin complète, auth complète, persistance métier complète ni forge obligatoire.
Les binds sont exclusivement configurés par `KNOWLEDGE_PGR_BIND_ADDRESS`, `KNOWLEDGE_HOWTOS_BIND_ADDRESS` et `KNOWLEDGE_SNIPPETS_BIND_ADDRESS`. Aucun port de déploiement n'est codé en dur.
La gate doit couvrir les tests `knowledge-web-lib`, la compilation/Clippy des quatre nouvelles crates, le build Vite et un smoke HTTP production des trois launchers vérifiant `/healthz`, le rendu Maud et le service réel des assets hashés.
La tranche ne doit pas introduire admin complète, auth complète, persistance métier complète, logging transverse artificiel ni forge obligatoire.
### beta.1 — réconciliation de fondation

23
docs/validation/001-VALIDATION_MATRIX.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
<!-- version: 10 -->
<!-- version: 11 -->
# Matrice de validation Knowledge
@@ -295,3 +295,24 @@ Le second fix Web doit prouver :
- gates Rust existantes toujours propres après le bump de version ;
- aucun serveur Actix/Maud, loader Rust du manifest, route runtime, migration PostgreSQL ou adapter de forge ajouté ;
- staging Git propre et outputs générés absents du dépôt.
## Gate de `0.0.1-alpha.5`
La composition serveur doit prouver :
- `VERSION = 0.0.1-alpha.5` et version workspace identique ;
- history `alpha.4.fix.2` `PASS` committé avant application ;
- workspace contenant `knowledge-web-lib` et exactement les trois nouveaux launchers attendus ;
- `knowledge-web-lib` comme unique owner Actix/Maud/Vite runtime partagé ;
- launchers dépendant de `knowledge-web-lib` sans dépendance directe Actix/Maud/Serde ;
- Actix Web `4.15.0`, Actix Files `0.7.0`, Maud `0.27.0`, Serde `1.0.229` et Serde JSON `1.0.151` dans le manifest de `knowledge-web-lib` ;
- aucun `panic!`, `unwrap`, `expect` ou `?` ajouté ;
- aucune origin/port Vite ou adresse de bind choisie par le code ;
- mode dev résolvant `@vite/client` puis `src/main.ts` depuis `KNOWLEDGE_VITE_DEV_ORIGIN` ;
- mode production résolvant `src/main.ts` depuis le manifest configuré et servant les fichiers `/assets/*` depuis le build réel ;
- routes runtime limitées à `/` et `/healthz` pour cette tranche ;
- aucune route admin/login, auth, PostgreSQL ou forge ajoutée ;
- `npm ci`, typecheck et build du template lab toujours `PASS` ;
- audits Rust PGR, `cargo check`, Clippy strict et tests ciblés `PASS` ;
- smoke HTTP production `PASS` pour les trois launchers avec ports de test injectés par environnement ;
- `Cargo.lock` mis à jour/versionné et staging propre.