0.0.1-alpha.4
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/001-PROJECT_PROFILE.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# Profil du projet Knowledge
|
||||
|
||||
@@ -73,11 +73,11 @@ Les profils Java/Maven/Gradle, Android et autres technologies absentes ne sont p
|
||||
| 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 |
|
||||
| TypeScript | `ADOPT` | conforme au owner `530` et à l'intention locale |
|
||||
| Package manager frontend | `DEFER` | choisir dans la tranche Web avant création du manifest/lockfile |
|
||||
| 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 |
|
||||
| Sass | `KEEP-LOCAL` + owner `560` adopté | styles source de la chaîne de validation Web et des assets réellement servis par les pages Maud |
|
||||
| Bootstrap | `KEEP-LOCAL` | framework CSS retenu pour les templates de référence et le rendu Maud ; jamais règle PGR universelle |
|
||||
| Racine(s) frontend | `DEFER` | décider en `alpha.4` selon le partage réel entre les trois applications et leurs templates de référence |
|
||||
| Racine(s) frontend | `KEEP-LOCAL` | package partagé `Web/knowledge-template-lab/` pour les références statiques et assets communs |
|
||||
| Templates statiques Web | `KEEP-LOCAL` | harness de conception/validation ; le markup runtime est adapté et servi par Maud |
|
||||
| Intégration manifest Vite / Maud | `KEEP-LOCAL` | mapping d’assets hashés requis en production ; API Rust exacte différée jusqu’à la composition serveur |
|
||||
| Driver/ORM PostgreSQL | `DEFER` | reprendre à la première implémentation persistante réelle |
|
||||
@@ -92,6 +92,8 @@ Les profils Java/Maven/Gradle, Android et autres technologies absentes ne sont p
|
||||
|
||||
Aucun `OVERRIDE` n'est requis à ce stade.
|
||||
|
||||
La sélection Web `alpha.4` conserve une seule baseline partagée tant qu'aucune divergence réelle entre les trois façades ne justifie plusieurs packages. Les entrées spécifiques pourront être ajoutées dans ce package avant toute duplication de toolchain.
|
||||
|
||||
## Nomenclature de crates candidate
|
||||
|
||||
Les trois packages exécutables sont des boundaries produit retenus :
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/002-KNOWLEDGE_ARCHITECTURE.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# Architecture de fondation Knowledge
|
||||
|
||||
@@ -236,7 +236,7 @@ Pour HOWTOs/snippets :
|
||||
|
||||
Actix Web et Maud sont des choix de composition/rendu locaux. Vite gère les assets/interactions frontend lorsqu'il est matérialisé.
|
||||
|
||||
La stratégie exacte de partage des assets/frontend entre les trois applications reste `DEFER` jusqu'à la tranche Web : un package commun n'est créé que si du code/assets sont réellement communs.
|
||||
La baseline `alpha.4` retient un package de laboratoire partagé `Web/knowledge-template-lab/` pour les assets et templates statiques de référence communs. Cette décision évite trois toolchains identiques ; une divergence réelle pourra introduire ultérieurement des entrées ou packages supplémentaires.
|
||||
|
||||
### Pipeline Web de référence et rendu runtime
|
||||
|
||||
@@ -264,7 +264,7 @@ 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. `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` 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.
|
||||
|
||||
## 10. Administration
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/001-V0_0_1_FOUNDATION_PLAN.md -->
|
||||
<!-- version: 7 -->
|
||||
<!-- version: 8 -->
|
||||
|
||||
# Plan 0.0.1 — fondation SaseDev Knowledge
|
||||
|
||||
@@ -134,7 +134,7 @@ La gate valide la structure et les audits puis échoue dans `knowledge-domain-li
|
||||
|
||||
`alpha.3.fix.2` corrige exclusivement cette dette de documentation publique et rejoue la gate Rust complète sans modifier les contrats domaine/Git/synchronisation ni le cadrage Web/Maud. Sa gate opérateur reste toutefois **FAIL** malgré le passage de `cargo check`, Clippy strict et des trois suites ciblées : `git diff --check` détecte une ligne vide supplémentaire en fin de `docs/validation/001-VALIDATION_MATRIX.md`.
|
||||
|
||||
`alpha.3.fix.3` corrige exclusivement cette anomalie documentaire de fin de fichier, conserve les corrections Rust déjà validées et rejoue la gate complète avant clôture d'`alpha.3`.
|
||||
`alpha.3.fix.3` corrige exclusivement cette anomalie documentaire de fin de fichier, conserve les corrections Rust déjà validées et rejoue la gate complète avant clôture d'`alpha.3`. Sa gate opérateur est **PASS**.
|
||||
|
||||
Le scope fonctionnel de `alpha.3` reste : 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.
|
||||
|
||||
@@ -146,13 +146,25 @@ Ne pas ajouter d'API Gitea ni de persistance PostgreSQL par anticipation.
|
||||
|
||||
### alpha.4 — baseline Web indépendante et templates de référence
|
||||
|
||||
Instancier obligatoirement le skeleton `003-WEB_FRONTEND` : choisir package manager et lockfile, TypeScript strict, Vite, Sass et Bootstrap, avec typecheck/build indépendants du backend.
|
||||
Instancier obligatoirement le skeleton `003-WEB_FRONTEND` avec les décisions désormais résolues :
|
||||
|
||||
Le frontend sert d’abord de laboratoire de templates statiques : développer et valider indépendamment le markup de référence, les comportements TypeScript, le responsive Bootstrap et les styles Sass avant adaptation du markup runtime en Maud. Les pages statiques ne deviennent pas une seconde UI de production.
|
||||
```text
|
||||
package Web/knowledge-template-lab/
|
||||
package manager npm
|
||||
lockfile package-lock.json versionné
|
||||
TypeScript strict
|
||||
Vite build + dev server + manifest
|
||||
styles Sass
|
||||
framework CSS Bootstrap
|
||||
```
|
||||
|
||||
Activer le manifest de build Vite et définir des clés d’entrée stables pour les assets réellement destinés aux pages Maud. Les outputs restent générés/hors Git conformément à PGR.
|
||||
Le package reste partagé entre les trois façades tant qu'aucune divergence réelle ne justifie une séparation. Il sert d’abord de laboratoire de templates statiques : développer et valider indépendamment le markup de référence, les comportements TypeScript, le responsive Bootstrap et les styles Sass avant adaptation du markup runtime en Maud. Les pages statiques ne deviennent pas une seconde UI de production.
|
||||
|
||||
Décider à cette tranche si les trois applications partagent un package d'assets/frontend ou possèdent des entrées séparées. Ne pas dupliquer par défaut, ne pas imposer non plus un frontend unique sans preuve de réutilisation. Définir également une preuve minimale contre la dérive entre templates statiques de référence et future adaptation Maud.
|
||||
Le build Vite active le manifest et matérialise une entrée stable `src/main.ts`. Cette entrée importe la chaîne Sass afin que le manifest relie l'entrée logique aux sorties JavaScript/CSS hashées consommables plus tard par Maud.
|
||||
|
||||
Les outputs et caches restent sous `../builds/sasedev-knowledge/` et hors Git. La gate doit prouver une restauration reproductible depuis `package-lock.json`, un typecheck séparé, le build Vite, un manifest parsable et la présence des assets attendus.
|
||||
|
||||
La preuve contre la dérive statique/Maud reste volontairement limitée à cette tranche : le package de référence documente les invariants de classes/attributs/assets, tandis que la comparaison runtime réelle n'existe qu'après matérialisation Maud en `alpha.5`.
|
||||
|
||||
### alpha.5 — composition Actix/Maud et manifest Vite
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/validation/001-VALIDATION_MATRIX.md -->
|
||||
<!-- version: 7 -->
|
||||
<!-- version: 8 -->
|
||||
|
||||
# Matrice de validation Knowledge
|
||||
|
||||
@@ -231,3 +231,27 @@ Le troisième fix doit prouver :
|
||||
- aucune modification fonctionnelle des contrats domaine/Git/synchronisation ;
|
||||
- aucun frontend, serveur Actix, schéma PostgreSQL ou adapter de forge ajouté ;
|
||||
- staging Git propre à la tranche.
|
||||
|
||||
## Gate de `0.0.1-alpha.4`
|
||||
|
||||
La tranche Web doit prouver :
|
||||
|
||||
- `VERSION = 0.0.1-alpha.4` et version workspace Cargo identique ;
|
||||
- history `alpha.3.fix.3` `PASS` committé avant application d'`alpha.4` ;
|
||||
- package unique `Web/knowledge-template-lab/` et absence des trois launchers Actix encore différés ;
|
||||
- npm sélectionné comme package manager ;
|
||||
- `package-lock.json` généré par npm, versionné et non ignoré ;
|
||||
- dépendances réelles et versions explicites pour TypeScript, Vite, Sass, Bootstrap, Popper et types nécessaires ;
|
||||
- `npm ci` `PASS` depuis le lockfile ;
|
||||
- `npm run typecheck` indépendant `PASS` ;
|
||||
- `npm run build` `PASS` ;
|
||||
- cache Vite et `build.outDir` hors dépôt sous `../builds/sasedev-knowledge/` ;
|
||||
- manifest Vite de production parsable ;
|
||||
- entrée stable `src/main.ts` présente dans le manifest et associée à un asset JavaScript ;
|
||||
- au moins un asset CSS associé à l'entrée ou à son graphe de build ;
|
||||
- page statique de référence incluse dans le build Vite sans route Actix/Maud ;
|
||||
- aucun chemin `/admin`, `/login` ou hostname de production figé dans le package de laboratoire ;
|
||||
- aucune crate serveur, dépendance Actix/Maud, migration PostgreSQL ou adapter de forge ajouté ;
|
||||
- gates Rust existantes toujours propres après le bump de version ;
|
||||
- `git diff --cached --check` propre et outputs générés absents du staging.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user