0.0.1-alpha.3.fix.1

docs/plans/001-V0_0_1_FOUNDATION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/001-V0_0_1_FOUNDATION_PLAN.md -->
-<!-- version: 4 -->
+<!-- version: 5 -->
 
 # Plan 0.0.1 — fondation SaseDev Knowledge
 
@@ -126,7 +126,13 @@ Le skeleton `002-RUST_CARGO_WORKSPACE` est matérialisé avec `knowledge-domain-
 
 ### 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.
+Statut opérateur initial : **FAIL**.
+
+La gate valide la structure et les audits puis échoue dans `knowledge-domain-lib` : `SourceId::new` tente de construire le tuple struct privé via le re-export crate-root depuis son sous-module. Le même défaut bloque `cargo check`, Clippy et les trois suites ciblées.
+
+`alpha.3.fix.1` corrige ce défaut Rust, ajoute une régression directe de construction `SourceId` et précise la trajectoire Web/Maud fournie avant clôture de la tranche ; il ne démarre aucune implémentation frontend ou serveur.
+
+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.
 
 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.
 
@@ -134,15 +140,19 @@ Adopter les audits Rust PGR de structure/façade désormais utiles avec les prem
 
 Ne pas ajouter d'API Gitea ni de persistance PostgreSQL par anticipation.
 
-### alpha.4 — baseline Web indépendante
+### alpha.4 — baseline Web indépendante et templates de référence
 
-Instancier le skeleton `003-WEB_FRONTEND` : choisir package manager et lockfile, TypeScript strict, Vite, Sass et Bootstrap réellement nécessaires, avec typecheck/build indépendants du backend.
+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.
 
-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.
+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.
 
-### alpha.5 — composition des trois serveurs minimale
+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.
 
-Matérialiser le minimum Actix Web/Maud nécessaire pour prouver trois launchers minces :
+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.
+
+### 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` :
 
 ```text
 knowledge-pgr-server
@@ -152,6 +162,8 @@ 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.
 
+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.
+
 La tranche ne doit pas introduire admin complète, auth complète, persistance métier complète ni forge obligatoire.
 
 ### beta.1 — réconciliation de fondation