0.0.1-alpha.1.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: 1 -->
+<!-- version: 2 -->
 
 # Plan 0.0.1 — fondation SaseDev Knowledge
 
@@ -25,6 +25,7 @@ La release doit établir :
 
 - la gouvernance PGR locale ;
 - la composition des owners/skeletons réellement applicables ;
+- la topologie du workspace à trois applications Actix Web distinctes ;
 - les frontières Git générique / forge optionnelle / PostgreSQL ;
 - les frontières PGR / HOWTO / snippet / project-local ;
 - un workspace Rust minimal strict et reproductible ;
@@ -34,29 +35,33 @@ La release doit établir :
 
 ## État acquis et questions ouvertes
 
-Acquis par le cadrage `alpha.1` :
+Acquis par le cadrage `alpha.1.fix.1` :
 
-- dépôt applicatif `sasedev-knowledge`, nom court `knowledge` ;
+- dépôt applicatif/workspace `sasedev-knowledge`, nom court `knowledge` ;
+- trois launchers publics retenus : `knowledge-pgr-server`, `knowledge-howtos-server`, `knowledge-snippets-server` ;
+- au moins trois sources Git indépendantes : `pgr`, `howtos`, `snippets` ;
 - Git autoritaire pour le contenu ;
 - forge facultative derrière adapter ;
-- PostgreSQL pour l'état applicatif/projections ;
-- monolithe modulaire comme baseline de déploiement ;
-- PGR, HOWTOs et snippets dans des dépôts séparés ;
+- une base PostgreSQL logique partagée pour l'état transversal et les projections ;
+- crates communes privilégiées à la duplication entre launchers ;
 - Rust stable/édition 2024 ;
 - Actix Web, Maud, Vite, TypeScript, Sass, Bootstrap et PostgreSQL retenus comme intentions locales conformes aux owners applicables ;
+- préférence Eclipse UTF-8 versionnée conformément à la politique PGR ;
 - aucun override PGR nécessaire.
 
 Restent volontairement ouverts jusqu'à la tranche qui les consomme :
 
 - package manager et lockfile frontend ;
 - `Cargo.lock` ;
-- racine/configuration concrète du frontend ;
+- racine(s) et partage concret du frontend entre les trois applications ;
 - driver/ORM et migrations PostgreSQL ;
+- éventuel découpage en schémas PostgreSQL ;
 - moteur de recherche ;
 - fournisseur d'identité ;
 - adapter forge réel ;
 - formats finaux HOWTO/snippet ;
-- liste définitive des crates.
+- topologie d'administration ;
+- liste définitive des crates de bibliothèque.
 
 ## Scope
 
@@ -65,6 +70,7 @@ Restent volontairement ouverts jusqu'à la tranche qui les consomme :
 - documentation de gouvernance et architecture ;
 - workspace Rust/Cargo minimal ;
 - configuration de toolchain/lints proportionnée ;
+- trois packages serveur distincts uniquement lorsque leur composition devient utile ;
 - premiers types/traits de boundary lorsque leur responsabilité est claire ;
 - baseline Web minimale et reproductible ;
 - validation indépendante backend/frontend ;
@@ -83,7 +89,8 @@ Restent volontairement ouverts jusqu'à la tranche qui les consomme :
 - authentification complète ;
 - production multi-domaines ;
 - moteur de rendu final de tous les formats ;
-- architecture microservices.
+- architecture de microservices distribués ;
+- quatrième application d'administration sans besoin démontré.
 
 ## Stratégie de validation
 
@@ -91,12 +98,13 @@ Les gates suivent [`../validation/001-VALIDATION_MATRIX.md`](../validation/001-V
 
 Principes :
 
-- gate documentaire pour `alpha.1` ;
+- gate documentaire pour `alpha.1` et ses fixes ;
+- politique Eclipse explicitement contrôlée ;
 - Cargo officiel dès matérialisation Rust ;
 - audits Rust structurels PGR seulement s'ils apportent une preuve distincte ;
 - package manager/TypeScript/Vite/Sass officiels dès matérialisation Web ;
 - backend et frontend validables séparément ;
-- smoke seulement pour une propriété runtime réellement introduite ;
+- chaque launcher serveur reçoit un smoke seulement lorsqu'une propriété runtime réelle est introduite ;
 - aucune prévalidation assistant ne vaut `PASS` opérateur.
 
 ## Trajectoire prévisionnelle
@@ -105,31 +113,43 @@ Principes :
 
 Matérialiser la fondation locale : version, règles, objectifs, profil PGR, architecture, plan, validation, roadmap/changelog et prompt de démarrage.
 
+Le résultat opérateur initial est `FAIL`. Le fix `alpha.1.fix.1` corrige la politique Eclipse, la gate de fichiers et la topologie produit à trois applications sans ouvrir le scope `alpha.2`.
+
 Aucun code fonctionnel n'est ajouté.
 
 ### alpha.2 — workspace Rust/Cargo minimal
 
-Instancier le skeleton `002-RUST_CARGO_WORKSPACE` sur la fondation : manifest workspace, toolchain/configuration durable réellement nécessaire, premier package possédant une responsabilité claire et gates Cargo officielles.
+Instancier le skeleton `002-RUST_CARGO_WORKSPACE` sur la fondation : manifest workspace, toolchain/configuration durable réellement nécessaire et premier package de bibliothèque possédant une responsabilité claire.
 
 Décider explicitement `Cargo.lock`, outputs de build et premier sous-ensemble de crates réellement matérialisé.
 
+Les trois packages serveur sont connus architecturalement mais ne sont pas obligatoirement tous créés dans cette tranche si leur seule existence serait un placeholder.
+
 ### alpha.3 — contrats domaine/Git/synchronisation
 
-Introduire uniquement les premiers contrats/types nécessaires aux frontières `GitRepository`, contenu et synchronisation, avec tests ciblés. Ne pas ajouter d'API Gitea ni de persistance PostgreSQL par anticipation.
+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.
 
-Les noms conceptuels du cadrage peuvent être adaptés si l'implémentation montre un meilleur owner ; toute modification du plan est tracée dans le delta correspondant.
+Ne pas ajouter d'API Gitea ni de persistance PostgreSQL par anticipation.
 
 ### alpha.4 — baseline Web indépendante
 
 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.
 
-Ne pas faire de la présence d'Actix/Maud une excuse pour coupler la gate frontend au serveur.
+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.
 
-### alpha.5 — composition serveur minimale
+### alpha.5 — composition des trois serveurs minimale
 
-Matérialiser le minimum Actix Web/Maud nécessaire pour prouver la composition avec les contrats et assets de fondation, sans admin complète, auth complète, persistence métier complète ni forge.
+Matérialiser le minimum Actix Web/Maud nécessaire pour prouver trois launchers minces :
 
-Cette tranche peut être réduite ou reportée si `alpha.2` à `alpha.4` montrent qu'une stable de fondation plus petite est suffisante.
+```text
+knowledge-pgr-server
+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.
+
+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
 
@@ -151,8 +171,10 @@ REPLAN obligatoire si :
 
 - une tranche nécessite plusieurs responsabilités non prévues qui ne peuvent plus être validées proprement ensemble ;
 - un choix de crate impose un couplage du domaine à Actix/Gitea/PostgreSQL ;
+- les trois launchers entraînent une duplication de logique qui devrait être possédée par une crate commune ;
 - le frontend ne peut pas être validé indépendamment du host sans raison architecturale réelle ;
 - le choix Git impose une API de forge pour une opération fondamentale ;
+- la base PostgreSQL partagée impose un couplage de contenu qui contredit l'autorité Git ;
 - le format de contenu doit être figé sans corpus représentatif ;
 - trois fixes ou plus apparaissent sur une même tranche ;
 - un prérequis externe invalide la mission de fondation.