sasedev-knowledge/docs/plans/001-V0_0_1_FOUNDATION_PLAN.md

<!-- file: docs/plans/001-V0_0_1_FOUNDATION_PLAN.md -->
<!-- version: 3 -->

# 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 ;
- 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`.

## État acquis et questions ouvertes

Acquis par le cadrage `alpha.1.fix.1` :

- 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.

Restent volontairement ouverts jusqu'à la tranche qui les consomme :

- 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.

## Scope

`0.0.1` inclut :

- 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.

## 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 de microservices distribués ;
- quatrième application d'administration sans besoin démontré.

## Stratégie de validation

Les gates suivent [`../validation/001-VALIDATION_MATRIX.md`](../validation/001-VALIDATION_MATRIX.md).

Principes :

- 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.

## 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.

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é dans `alpha.1` ou son fix.

### alpha.2 — workspace Rust/Cargo minimal

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é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.

É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

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.

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.

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 des trois serveurs minimale

Matérialiser le minimum Actix Web/Maud nécessaire pour prouver trois launchers minces :

```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

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.