Nicolas Cantu
ac96434351
**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.
64 lines
5.0 KiB
Markdown
64 lines
5.0 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, 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 ([repo/projects-directory.md](../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](../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 : [repo/docv-services-directory.md](../repo/docv-services-directory.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)
|