sasedev-knowledge/docs/studies/003-V0_0_1_FOUNDATION_RECONCILIATION.md

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 :

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 :

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 :

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

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 :

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.