0.0.1-alpha.2

docs/plans/001-V0_0_1_FOUNDATION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/001-V0_0_1_FOUNDATION_PLAN.md -->
-<!-- version: 2 -->
+<!-- version: 3 -->
 
 # Plan 0.0.1 — fondation SaseDev Knowledge
 
@@ -52,7 +52,7 @@ Acquis par le cadrage `alpha.1.fix.1` :
 Restent volontairement ouverts jusqu'à la tranche qui les consomme :
 
 - package manager et lockfile frontend ;
-- `Cargo.lock` ;
+- modèle détaillé des rôles/capabilities ;
 - racine(s) et partage concret du frontend entre les trois applications ;
 - driver/ORM et migrations PostgreSQL ;
 - éventuel découpage en schémas PostgreSQL ;
@@ -60,7 +60,8 @@ Restent volontairement ouverts jusqu'à la tranche qui les consomme :
 - fournisseur d'identité ;
 - adapter forge réel ;
 - formats finaux HOWTO/snippet ;
-- topologie d'administration ;
+- URL et routage exacts des surfaces d'administration/login ;
+- décision d'une éventuelle quatrième application d'administration transverse ;
 - liste définitive des crates de bibliothèque.
 
 ## Scope
@@ -113,17 +114,19 @@ 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`.
+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. Sa gate opérateur est `PASS`.
 
-Aucun code fonctionnel n'est ajouté.
+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, toolchain/configuration durable réellement nécessaire et premier package de bibliothèque possédant une responsabilité claire.
+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.
 
-Décider explicitement `Cargo.lock`, outputs de build et premier sous-ensemble de crates réellement matérialisé.
+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.
 
-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.
+É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.
 
 ### alpha.3 — contrats domaine/Git/synchronisation
 
@@ -172,6 +175,7 @@ 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 ;
+- une future administration transverse tente de contourner ou remplacer les contrôles d'autorisation propres aux trois applications ;
 - 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 ;