0.1.2-alpha.2

docs/plans/001-V0_0_1_FOUNDATION_PLAN.md

@@ -1,98 +1,214 @@
 <!-- file: docs/plans/001-V0_0_1_FOUNDATION_PLAN.md -->
-<!-- version: 2 -->
+<!-- version: 6 -->
 
-# Plan 0.0.1 — fondation de PGR
+# Plan 0.0.1 — fondation SaseDev Knowledge
 
-## Statut
+## Statut et sources
 
-Plan clôturé par la promotion stable `0.0.1` après validation de `0.0.1-rc.1.fix.1`.
+Plan actif préparé après vérification de la stable PGR `v0.1.1` et de `pgr-0.1.1-publish.001-report.md` `PASS`.
 
-Aucune stable PGR antérieure n'existait. Cette version rend le dépôt capable de se gouverner lui-même avant l'introduction des profils technologiques et templates prévus dans les releases suivantes.
+Sources de cadrage :
+
+```text
+PGR v0.1.1 archive SHA-256
+caaf8f456f7f8520172ea7705fd0cf5c5bf0e942dc4a773410bcbe7fe4ce243a
+
+Knowledge start prompt
+prompts/001-V0_0_1_START_PROMPT.md
+```
 
 ## Mission
 
-`0.0.1` doit établir la fondation normative, documentaire et opératoire de Project Governance Rules.
+`0.0.1` doit rendre le nouveau dépôt suffisamment gouverné, reproductible et architecturalement découplé pour commencer ensuite l'implémentation de Knowledge sans coupler le domaine à Gitea, PostgreSQL, Actix ou une représentation éditoriale prématurée.
 
-La release doit notamment fixer :
+La release doit établir :
 
-- la finalité et les non-objectifs de PGR ;
-- la hiérarchie `MUST` / `SHOULD` / `MAY` et les règles de scope/override/exception ;
-- le modèle SemVer et le rôle de `VERSION` ;
-- le lifecycle `alpha` → `beta` → `rc` → stable et les `.fix.N` ;
-- le cadrage obligatoire de `alpha.1`, le replan et l'abandon/supersession ;
-- les rôles de `README`, `RULES`, `ROADMAP`, `CHANGELOG` et des collections documentaires ;
-- les contrats des plans, deltas, historiques, prompts, handoffs et manifests ;
-- la séparation TEST / AUDIT / DIAGNOSTIC ;
-- la validation proportionnée et l'autorité du gate opérateur ;
-- les règles de reprise de session et de baseline ZIP taggée ;
-- la préparation du prompt de démarrage de `0.0.2`.
+- 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 ;
+- une baseline frontend indépendante du backend selon les owners Web PGR ;
+- de premiers contrats ciblés sans implémentation disproportionnée ;
+- une validation suffisante pour promouvoir une stable `0.0.1`.
 
-## Hors périmètre
+## État acquis et questions ouvertes
 
-`0.0.1` ne doit pas encore :
+Acquis par le cadrage `alpha.1.fix.1` :
 
-- formaliser en détail tous les profils Rust, Java, Android, Tauri, Web, PHP, Python, C/C++ ;
-- produire le catalogue final des templates techniques ;
-- fournir des skeleton specifications complets par type de projet ;
-- créer un générateur PGR ;
-- anticiper des audits spécialisés sans besoin concret ;
-- réappliquer PGR à KSP ou games, travail réservé à une release ultérieure.
+- 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 ;
+- 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.
 
-## Principes de dimensionnement
+Restent volontairement ouverts jusqu'à la tranche qui les consomme :
 
-Une tranche doit rester cohérente et validable indépendamment. La cible de 15 à 30 minutes de travail effectif reste une heuristique de dimensionnement, pas une deadline.
+- package manager et lockfile frontend ;
+- 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 ;
+- moteur de recherche ;
+- fournisseur d'identité ;
+- adapter forge réel ;
+- formats finaux HOWTO/snippet ;
+- 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.
 
-Si le plan devient manifestement faux, un `alpha.N` peut jouer le rôle de REPLAN. Une version n'est jamais forcée vers stable uniquement pour respecter une session de conversation.
+## Scope
 
-## Prévision
+`0.0.1` inclut :
 
-### alpha.1 — Bootstrap and framing
+- 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 ;
+- documentation de fermeture et handoff de la stable.
 
-Créer la baseline minimale : identité, `.gitignore`, `VERSION`, documents racine, objectifs, profil du dépôt, architecture de gouvernance, index des règles, matrice de validation, plan actif, delta et prompt initial.
+## Hors scope
 
-Aucune implémentation massive des règles détaillées n'est réalisée dans cette tranche.
+`0.0.1` n'implémente pas :
 
-### alpha.2 — Core governance rules
+- moteur de recherche complet ;
+- UI d'administration complète ;
+- workflow complet de contribution ;
+- adapter multi-forge complet ;
+- intégration Gitea obligatoire ;
+- schéma PostgreSQL métier complet ;
+- authentification complète ;
+- production multi-domaines ;
+- moteur de rendu final de tous les formats ;
+- architecture de microservices distribués ;
+- quatrième application d'administration sans besoin démontré.
 
-Formaliser les règles communes de versioning et lifecycle : SemVer, `VERSION`, maturité, fixes, cadrage `alpha.1`, replan, abandon/supersession, stable promotion et publication.
+## Stratégie de validation
 
-### alpha.3 — Workflow artifacts
+Les gates suivent [`../validation/001-VALIDATION_MATRIX.md`](../validation/001-VALIDATION_MATRIX.md).
 
-Formaliser plans, deltas, history, prompts, handoffs, manifests de suppression, workflow PASS/FAIL et reprise après interruption.
+Principes :
 
-### alpha.4 — Documentation governance
+- 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 ;
+- 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.
 
-Formaliser les rôles des documents, taxonomie documentaire, headers, révisions internes, déplacement/split/fusion, conservation historique, objectifs, ideas/studies/architecture/reference et politique de langue.
+## Trajectoire prévisionnelle
 
-### alpha.5 — Validation governance
+### alpha.1 — cadrage et gouvernance
 
-Formaliser la matrice de validation, sélection proportionnelle, TEST/AUDIT/DIAGNOSTIC, opérateur autoritaire, tests utiles/non redondants, mocks lorsque pertinents et transitions de gate.
+Matérialiser la fondation locale : version, règles, objectifs, profil PGR, architecture, plan, validation, roadmap/changelog et prompt de démarrage.
 
-### beta.1 — Foundation reconciliation
+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`.
 
-Réconcilier les documents de fondation, éliminer duplications et contradictions, vérifier navigation, rôles, scopes et complétude de `0.0.1`.
+Aucun code fonctionnel n'est ajouté dans `alpha.1` ou son fix.
 
-### rc.1 — Foundation release candidate
+### alpha.2 — workspace Rust/Cargo minimal
 
-Geler le scope, préparer l'entrée candidate de changelog et le prompt `0.0.2`, puis exécuter la gate documentaire complète applicable.
+Statut opérateur : **PASS**.
 
-### stable — 0.0.1
+Le skeleton `002-RUST_CARGO_WORKSPACE` est matérialisé avec `knowledge-domain-lib`, `Cargo.lock` versionné, artefacts Cargo hors dépôt et étude auth/admin séparant fonctionnalités réelles et intentions historiques. Les gates `metadata`, `fmt`, `check`, Clippy et tests workspace sont propres.
 
-Promouvoir mécaniquement la RC validée, finaliser les métadonnées de release, enregistrer `rel.001`, commit/tag `v0.0.1`, puis utiliser l'archive ZIP taggée comme baseline autoritaire de `0.0.2`.
+### alpha.3 — contrats domaine/Git/synchronisation
 
-## Clôture
+Statut opérateur initial : **FAIL**.
 
-La release candidate a nécessité `rc.1.fix.1` pour corriger exclusivement une commande de gate incompatible avec l'expansion d'historique d'un Bash interactif. La gate RC complète a ensuite été validée PASS sans modification du scope normatif.
+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.
 
-La promotion stable `rel.001` clôt le plan en mettant à jour uniquement les métadonnées vivantes de release et en préparant le tag `v0.0.1`.
+`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. Sa gate opérateur reste toutefois **FAIL** : `cargo check` et les tests passent, mais Clippy strict rejette les quatre variantes publiques de `ContentFamily` non documentées sous `missing_docs`.
 
-## Critères de fermeture
+`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.
 
-`0.0.1` est fermée lorsque :
+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.
 
-- PGR peut expliquer et appliquer son propre cycle de version ;
-- les responsabilités des principaux artefacts de gouvernance sont non ambiguës ;
-- la validation d'une tranche peut être sélectionnée proportionnellement ;
-- une interruption ou reprise de session est gouvernée ;
-- le passage RC → stable → tag → archive suivante est défini ;
-- aucune règle technologique détaillée hors fondation n'est nécessaire pour comprendre le workflow PGR.
+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.
+
+Adopter les audits Rust PGR de structure/façade désormais utiles avec les premiers items publics partagés. Ne pas activer globalement l'audit `const`, qui reste sélection explicite par fichier.
+
+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.
+
+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.
+
+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.
+
+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
+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.
+
+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
+
+Rejouer les gates pertinentes, réconcilier docs/architecture avec ce qui existe réellement, traiter les décisions devenues nécessaires et effectuer la revue d'horizon.
+
+Aucune nouvelle grande fonctionnalité ne doit être introduite en beta par défaut.
+
+### rc.1 — candidate stable
+
+Clôturer les défauts de cohérence, préparer la présentation stable, le handoff suivant et vérifier l'absence de scope futur introduit par anticipation.
+
+### rel.1 — fermeture stable
+
+Exécuter la gate de release, produire le premier history `rel.N[/fix.M]` réellement `PASS`, matérialiser le commit produit `0.0.1`, publier le tag stable selon la politique Git retenue et effectuer la vérification post-tag requise.
+
+## Déclencheurs de REPLAN
+
+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 ;
+- 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.
+
+## Clôture et transition
+
+- documentation durable : réconciliée à chaque tranche qui change son contrat, puis revue en `beta.1` ;
+- `CHANGELOG.md` : entrée candidate tenue à jour puis finalisée en `rel.1` ;
+- `ROADMAP.md` : revue d'horizon en `beta.1`, sans création automatique d'une prochaine version ;
+- prompt/handoff suivant : préparé avant la clôture une fois la prochaine mission réellement décidée ;
+- fermeture du plan : `rel.1` ou son fix qui établit la stable ;
+- publication : commit produit `0.0.1`, tag stable puis rapport post-tag séparé.
+
+## Revue d'horizon
+
+- état : requise en `beta.1` ;
+- raison : aucune version après `0.0.1` n'est suffisamment cadrée pour être réservée aujourd'hui ;
+- sorties autorisées : engager une prochaine version avec mission réelle, laisser l'horizon ouvert ou différer la suite ;
+- interdiction : fabriquer un numéro uniquement pour satisfaire une cadence documentaire.