smart_ide/docs/features/docv-service-integration.md

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.

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/ dans smart_ide contient uniquement le contrat (README, exemple de noms de variables).

Convention disque : clones et data/

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

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

SSO

L’authentification utilisateur (OIDC) entre front et docv : 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
• Copie de la doc enso (docs/) sous services/docv/enso-docs/ (architecture docv, plans, etc.)
• IA : docv-ai-integration.md
• Écosystème et synchro Git : ecosystem-architecture-and-sync.md