Files
sasedev-knowledge/docs/studies/003-V0_0_1_FOUNDATION_RECONCILIATION.md
2026-09-28 10:37:50 +02:00

178 lines
6.4 KiB
Markdown

<!-- file: docs/studies/003-V0_0_1_FOUNDATION_RECONCILIATION.md -->
<!-- version: 1 -->
# Réconciliation de fondation et revue d'horizon 0.0.1
## Objet
Cette étude appartient à `0.0.1-beta.1`.
Elle réconcilie les objectifs de fondation, l'architecture réellement matérialisée après les tranches alpha, les décisions différées et l'horizon de roadmap.
Elle ne crée aucune fonctionnalité runtime.
## Baseline de gouvernance
La fondation reste gouvernée par PGR stable `v0.1.1`, vérifiée au démarrage de `0.0.1`.
Aucun `OVERRIDE` PGR n'a été nécessaire.
Knowledge a sélectionné localement une convention plus stricte pour les tests unitaires Rust : `unit_tests/` séparé de `src/`, avec `tests/` réservé aux tests d'intégration Cargo. Cette sélection reste compatible avec le `MAY` générique de PGR `0.1.1`.
## État matérialisé
### Workspace Rust
Sept packages existent :
```text
knowledge-domain-lib
knowledge-git-api
knowledge-sync-api
knowledge-web-lib
knowledge-pgr-server
knowledge-howtos-server
knowledge-snippets-server
```
Les trois launchers sont des unités de déploiement distinctes.
`knowledge-web-lib` possède la composition Actix/Maud réellement partagée.
`knowledge-git-api` et `knowledge-sync-api` restent des frontières passives, sans implémentation provider/forge/persistence.
### Web
Le package :
```text
Web/knowledge-template-lab/
```
possède npm, lockfile versionné, TypeScript strict, Vite, Sass et Bootstrap.
Le build produit un manifest avec l'entrée stable :
```text
src/main.ts
```
`knowledge-web-lib` consomme réellement ce contrat :
- dev : `KNOWLEDGE_VITE_DEV_ORIGIN` ;
- production : `KNOWLEDGE_VITE_MANIFEST_PATH` ;
- préfixe : `KNOWLEDGE_ASSET_BASE_PATH`.
Les trois launchers reçoivent leur bind via configuration.
### Tests
Les tests unitaires sont hors de `src/` sous `unit_tests/`.
L'audit `audit_rust_test_layout.py` empêche le retour du layout historique.
Les tests d'intégration Cargo futurs restent propriétaires de `tests/`.
## Décisions de fondation confirmées
| Domaine | Décision beta |
|-----------------------------------------------|-----------------------------------------|
| Git autoritaire pour le contenu publié | `CONFIRM` |
| forge optionnelle | `CONFIRM` |
| plusieurs sources Git possibles par famille | `CONFIRM` |
| trois launchers Web séparés | `CONFIRM` |
| logique Web partagée dans `knowledge-web-lib` | `CONFIRM` |
| PostgreSQL logique partagé pour l'état futur | `CONFIRM`, non matérialisé |
| templates statiques comme laboratoire | `CONFIRM` |
| Maud comme rendu runtime actuel | `CONFIRM` |
| manifest Vite comme mapping production | `CONFIRM` |
| surfaces admin protégées localement | `CONFIRM` comme contrat, non implémenté |
| quatrième admin app | `DEFER` |
| Gitea | `DEFER` |
| formats finaux HOWTO/snippet | `DEFER` |
## DEFER conservés
Les choix suivants ne sont pas devenus nécessaires pendant `0.0.1` :
- adapter Gitea ou autre forge ;
- driver/ORM PostgreSQL ;
- migrations PostgreSQL ;
- moteur de recherche externe ;
- fournisseur d'identité externe ;
- modèle final de rôles/capabilities ;
- routes admin/login ;
- quatrième application d'administration ;
- formats finaux HOWTO/snippet ;
- workflow complet de propositions ;
- écriture Git, branches de proposition, rebase/merge/push ;
- déploiement multi-domaines de production.
Les maintenir différés réduit le couplage et ne bloque aucune preuve de fondation.
## Incohérences documentaires corrigées en beta
La réconciliation corrige les formulations historiques devenues obsolètes :
- owners Web encore indiqués comme « tranche Web » alors qu'ils ont été matérialisés en `alpha.4` ;
- launchers décrits comme non matérialisés alors qu'ils existent depuis `alpha.5` ;
- `knowledge-web-lib` encore listée comme crate candidate ;
- API du loader Vite encore décrite comme différée alors qu'elle est maintenant possédée par `knowledge-web-lib`.
Les références aux tranches alpha restent autorisées lorsqu'elles expliquent l'historique réel, mais ne doivent plus contredire l'état courant.
## Revue d'horizon
La fondation possède maintenant assez de contrats pour engager une seule prochaine release sans inventer le reste de la trajectoire.
### Release engagée
```text
0.0.2 — Git générique et synchronisation de lecture
```
Mission :
- matérialiser une implémentation provider-neutral derrière `knowledge-git-api` ;
- gérer des sources Git locales et remotes génériques ;
- maintenir une matérialisation locale contrôlée ;
- rafraîchir/fetcher lorsque nécessaire ;
- résoudre une référence vers une révision autoritaire ;
- exposer un snapshot/worktree de lecture déterministe aux futurs parseurs ;
- faire converger déclenchement explicite et périodique vers un même cas d'usage de synchronisation ;
- détecter le changement de révision sans dépendre d'une forge.
Non-objectifs de `0.0.2` :
- pull/merge requests ou webhooks forge-specific ;
- publication Git en écriture ;
- workflow complet de propositions ;
- PostgreSQL ;
- parsing final HOWTO/snippet ;
- recherche ;
- auth/admin ;
- déploiement production.
Le choix technique d'implémentation Git — processus `git`, `gix`, autre crate ou combinaison justifiée — reste à étudier au démarrage de `0.0.2`. La mission est décidée, pas la bibliothèque.
### Horizon laissé ouvert
Aucun numéro n'est réservé après `0.0.2`.
Les thèmes PostgreSQL, parsing/index, propositions/admin/auth, forge et publication seront ordonnés après retour réel du chemin Git/synchronisation.
## Handoff
`prompts/002-V0_0_2_START_PROMPT.md` prépare la reprise.
Il ne devient exécutable qu'après :
```text
0.0.1 rel.N PASS
commit produit 0.0.1
tag v0.0.1 publié
rapport post-tag Knowledge PASS
```
Si la publication stable révèle un défaut, le handoff `0.0.2` reste bloqué jusqu'à résolution.