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