# 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, comment les **données projet** sont servies depuis les **environnements déployés** (SSH), et comment **adapter** le dépôt docv pour ne pas dépendre de chemins machine figés dans le code.

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 données

**Vérité données déployées** : la **source de référence** des données métier (fichiers, index, bases utilisées pour la doc et le RAG) est sur les **environnements déployés** (test, pprod, prod), pas dans Git. **docv** doit pouvoir **récupérer** ces données via **SSH** (voir [remote-deployed-data-ssh.md](./remote-deployed-data-ssh.md)) avant synchronisation vers AnythingLLM ou traitement local. Les répertoires `data/` dans les clones applicatifs restent des **miroirs ou caches** : à exclure de l’historique Git (`.gitignore` dans chaque dépôt produit).

```mermaid
flowchart TB
  subgraph deployed [Serveurs_test_pprod_prod]
    D[data_et_BDD]
  end
  subgraph local [Poste_ou_service_docv]
    M[miroir_ou_cache_local]
    DV[docv_repo]
  end
  deployed -->|SSH_rsync_ou_dump| M
  M --> DV
```

- **`PROJECTS_CLONE_ROOT`** : répertoire absolu parent des clones **`<projet>/`** (code). Convention : souvent **`../projects`** relatif à smart_ide ([projects/README.md](../../projects/README.md)).
- **Zone de travail docv** : chemin résolu par **`DOCV_PROJECTS_ROOT`** (ou équivalent) vers un répertoire où les **fichiers issus des environnements déployés** sont présents après **pont SSH** (structure exacte à documenter dans le dépôt docv : sous-dossiers par `projectId`, par env, etc.).

## 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` (ou équivalent : répertoire du **miroir** après fetch SSH), URLs, et paramètres SSH côté hôte — alignés sur [platform-target.md](../platform-target.md) et [remote-deployed-data-ssh.md](./remote-deployed-data-ssh.md).

## Multi-hôte : poste local docv, smart_ide, environnements déployés

**docv** peut tourner sur un **hôte différent** de l’orchestrateur et des services smart_ide.

- 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).
- L’alignement des **données** avec les serveurs **test / pprod / prod** repose sur **SSH** (ou équivalent) depuis l’hôte qui exécute docv ou un job dédié, pas sur un `data/` versionné dans le clone Git — détail : [remote-deployed-data-ssh.md](./remote-deployed-data-ssh.md). Un **stockage partagé** (NFS, etc.) reste une option alternative si la politique projet le prévoit.

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