0.0.1-alpha.1

docs/plans/001-V0_0_1_FOUNDATION_PLAN.md

@@ -0,0 +1,174 @@
+<!-- file: docs/plans/001-V0_0_1_FOUNDATION_PLAN.md -->
+<!-- version: 1 -->
+
+# Plan 0.0.1 — fondation SaseDev Knowledge
+
+## Statut et sources
+
+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`.
+
+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 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 établir :
+
+- la gouvernance PGR locale ;
+- la composition des owners/skeletons réellement applicables ;
+- 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`.
+
+## État acquis et questions ouvertes
+
+Acquis par le cadrage `alpha.1` :
+
+- dépôt applicatif `sasedev-knowledge`, nom court `knowledge` ;
+- 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 ;
+- Rust stable/édition 2024 ;
+- Actix Web, Maud, Vite, TypeScript, Sass, Bootstrap et PostgreSQL retenus comme intentions locales conformes aux owners applicables ;
+- 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 ;
+- driver/ORM et migrations PostgreSQL ;
+- moteur de recherche ;
+- fournisseur d'identité ;
+- adapter forge réel ;
+- formats finaux HOWTO/snippet ;
+- liste définitive des crates.
+
+## Scope
+
+`0.0.1` inclut :
+
+- documentation de gouvernance et architecture ;
+- workspace Rust/Cargo minimal ;
+- configuration de toolchain/lints proportionnée ;
+- 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.
+
+## Hors scope
+
+`0.0.1` n'implémente pas :
+
+- 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 microservices.
+
+## Stratégie de validation
+
+Les gates suivent [`../validation/001-VALIDATION_MATRIX.md`](../validation/001-VALIDATION_MATRIX.md).
+
+Principes :
+
+- gate documentaire pour `alpha.1` ;
+- 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 ;
+- aucune prévalidation assistant ne vaut `PASS` opérateur.
+
+## Trajectoire prévisionnelle
+
+### alpha.1 — cadrage et gouvernance
+
+Matérialiser la fondation locale : version, règles, objectifs, profil PGR, architecture, plan, validation, roadmap/changelog et prompt de démarrage.
+
+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.
+
+Décider explicitement `Cargo.lock`, outputs de build et premier sous-ensemble de crates réellement matérialisé.
+
+### 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.
+
+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.
+
+### 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.
+
+### alpha.5 — composition serveur 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.
+
+Cette tranche peut être réduite ou reportée si `alpha.2` à `alpha.4` montrent qu'une stable de fondation plus petite est suffisante.
+
+### 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 ;
+- 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 ;
+- 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.