Nicolas Cantu
bc3c75e15f
- Copy enso/docs tree to services/docv/enso-docs (refresh via cp -a from enso repo) - Document mirror and refresh command in services/docv/README.md - Ignore services/docv/target for local Rust workspace - Track docv-service-integration, API docv.md, and related doc index updates
62 lines
4.5 KiB
Markdown
62 lines
4.5 KiB
Markdown
# docv — service de gestion documentaire et données projet
|
||
|
||
## Objectif
|
||
|
||
**docv** fournit la **gestion documentaire** aux projets de la filière Enso (workflows, API et stockage métier documents). Ce document fixe comment **smart_ide** référence docv comme **service externe** au monorepo, où placer les **données projet** (`../projects/<projet>/data`), et comment **adapter** le dépôt docv pour ne plus dépendre de chemins machine figés.
|
||
|
||
Les **intégrations IA** (orchestrateur, Ollama, AnythingLLM, etc.) sont décrites séparément : [docv-ai-integration.md](./docv-ai-integration.md).
|
||
|
||
## Emplacement du code docv
|
||
|
||
Le dépôt applicatif **docv** n’est **pas** copié dans smart_ide. Référence type sur une machine de développement : **`…/enso/docv`** (ex. `/home/desk/code/enso/docv`). Le dossier [services/docv/](../../services/docv/) dans smart_ide contient uniquement le **contrat** (README, exemple de noms de variables).
|
||
|
||
## Convention disque : clones et `data/`
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph parent [Parent_commun_exemple_code]
|
||
SI[smart_ide]
|
||
PR[projects]
|
||
EN[enso_ou_autre]
|
||
SI --> SI
|
||
PR --> P1["projects_projA_data"]
|
||
PR --> P2["projects_projB_data"]
|
||
EN --> DV[docv_repo]
|
||
end
|
||
```
|
||
|
||
- **`PROJECTS_CLONE_ROOT`** : répertoire absolu qui contient un sous-dossier par **identifiant de projet** (`<projet>/`), avec le code ou la racine métier du clone. Convention alignée avec [projects/README.md](../../projects/README.md) : souvent le répertoire **frère** de `smart_ide` nommé **`projects`**, donc **`../projects`** relatif à la racine de smart_ide.
|
||
- **Données documentaires pour docv** : **`${PROJECTS_CLONE_ROOT}/<projet>/data/`**. Le contenu de `data/` est **synchronisé** par les mécanismes du projet (contrôle de version partiel, pipelines, rsync, stockage partagé) ; smart_ide ne prescrit pas un seul outil de synchro, mais impose la **structure** pour que docv résolve un chemin stable par projet.
|
||
|
||
## Adaptations attendues dans le dépôt docv (amont)
|
||
|
||
À réaliser dans le clone **docv** (hors ce monorepo) :
|
||
|
||
1. Variable d’environnement **`DOCV_PROJECTS_ROOT`** (ou nom équivalent documenté en équipe) : chemin absolu vers **`PROJECTS_CLONE_ROOT`** (parent des répertoires `<projet>/`).
|
||
2. Résolution du répertoire de données :
|
||
**`path.join(DOCV_PROJECTS_ROOT, projectId, 'data')`** (ou équivalent selon le langage), avec règles métier pour existence / création contrôlée.
|
||
3. Suppression des chemins **en dur** du type `/home/desk/code/enso/...` dans la logique runtime ; conserver de tels chemins uniquement comme **exemples** dans la documentation.
|
||
4. Par **environnement** (test, pprod, prod), utiliser des fichiers d’environnement **hors Git** avec des valeurs distinctes pour `DOCV_PROJECTS_ROOT` et URLs, alignés sur [platform-target.md](../platform-target.md).
|
||
|
||
## Multi-hôte : poste local docv vs serveur SSH smart_ide
|
||
|
||
**docv** peut tourner sur un **hôte différent** de celui où s’exécutent l’orchestrateur et les services smart_ide (ex. docv sur poste desk, smart_ide via SSH sur serveur distant).
|
||
|
||
- Les appels HTTP de smart_ide vers docv utilisent une **URL réseau** (`DOCV_BASE_URL`, TLS, allowlist) — voir [services/docv/.env.example](../../services/docv/.env.example).
|
||
- Le répertoire **`../projects/<projet>/data`** sur la machine **docv** n’est **pas** automatiquement le même que sur le serveur smart_ide : il faut un **stockage partagé** (NFS, montage), une **réplication**, ou une autre stratégie explicite. Sans cela, docv et smart_ide ne voient pas les mêmes fichiers.
|
||
|
||
## Orchestrateur et routage
|
||
|
||
Lorsque le routage « intentions » doit déléguer à docv (création de document, recherche catalogue métier, etc.), l’orchestrateur utilise la **base URL** et l’**auth** documentées pour l’environnement ; le détail des endpoints reste la responsabilité du dépôt docv. Index des services : [API/README.md](../API/README.md).
|
||
|
||
## SSO
|
||
|
||
L’authentification utilisateur (OIDC) entre front et docv : [sso-docv-enso.md](./sso-docv-enso.md). Elle ne remplace pas l’auth **serveur à serveur** entre composants smart_ide et docv.
|
||
|
||
## Liens
|
||
|
||
- Contrat dans le monorepo : [services/docv/README.md](../../services/docv/README.md)
|
||
- Copie de la doc **enso** (`docs/`) sous [services/docv/enso-docs/](../../services/docv/enso-docs/) (architecture docv, plans, etc.)
|
||
- IA : [docv-ai-integration.md](./docv-ai-integration.md)
|
||
- Écosystème et synchro Git : [ecosystem-architecture-and-sync.md](../ecosystem-architecture-and-sync.md)
|