4nk/smart_ide
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
smart_ide/docs/features/docv-service-integration.md
Nicolas Cantu ac96434351 docs: centralize README content under docs/repo/ 
**Motivations:**
- Single canonical documentation tree under docs/; reduce drift between README copies.

**Evolutions:**
- Add docs/repo/ with operational guides (cron, systemd, projects, logs, docv, ia_dev, services, scripts, extension).
- Replace scattered README.md files with pointers to docs/repo/*.md.
- Refresh docs/README.md index and cross-links across docs/, .cursor rules/agents.
- Bump ia_dev submodule to matching doc pointer commits.
2026-04-03 18:20:31 +02:00

5.0 KiB
Raw Blame History

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.

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

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 (repo/projects-directory.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 et 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.
  • 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. 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.

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