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
39 lines
3.0 KiB
Markdown
39 lines
3.0 KiB
Markdown
# docv — intégrations IA via la plateforme smart_ide
|
||
|
||
**Gestion documentaire**, chemins **`../projects/<projet>/data`**, adaptation du dépôt docv et multi-hôte : [docv-service-integration.md](./docv-service-integration.md).
|
||
|
||
## Rôle de smart_ide
|
||
|
||
Le monorepo **smart_ide** sert aussi de **socle technique** pour les intégrations IA consommées par le **backend docv** (filière Enso). Le principe : exposer, parmi les services locaux, des **API HTTP génériques** (orchestrateur, gateway agents, Ollama, AnythingLLM, micro-services sous `services/`) que le back **docv** peut appeler pour offrir les fonctionnalités IA **par projet**.
|
||
|
||
Référence d’arborescence côté Enso (machine de développement type) : dépôt **docv** sous un chemin du genre `…/enso/docv` (ex. historique `/home/desk/code/enso/docv`). Les URLs et secrets réels par environnement restent hors dépôt ([platform-target.md](../platform-target.md), [sso-docv-enso.md](./sso-docv-enso.md)).
|
||
|
||
## Modèle « projet »
|
||
|
||
Pour chaque **projet logique** (ex. périmètre docv, autre produit) :
|
||
|
||
1. **Clone Git** : le dépôt applicatif doit être **déjà cloné** au même titre que les autres projets de l’espace de travail, en général sous une **racine de clones** **distincte** du dossier `./projects/` du monorepo (voir [projects/README.md](../../projects/README.md)) — convention fréquente : répertoire **frère** `../projects/<nom>/` par rapport à la racine `smart_ide`.
|
||
2. **AnythingLLM** : le projet doit être **rattaché à un workspace** AnythingLLM (un workspace par projet). Si le clone ou le workspace **manque** ou est désynchronisé, la procédure d’exploitation prévoit de **créer / mettre à jour** le clone et d’**aligner** le workspace (synchronisation déterministe, voir [anythingllm-workspaces.md](../anythingllm-workspaces.md) et scripts sous `scripts/`).
|
||
3. **Configuration ia_dev** : lorsqu’un id projet est enregistré pour les agents ou le ticketing, un `conf.json` peut être versionné sous **`smart_ide/projects/<id>/conf.json`** ; les scripts `ia_dev` y accèdent via le lien `ia_dev/projects/<id>` lorsque le script [`ensure-ia-dev-smart-ide-project-link.sh`](../../scripts/ensure-ia-dev-smart-ide-project-link.sh) (ou équivalent) a été exécuté.
|
||
|
||
## Flux cible (vue simplifiée)
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
Docv[docv_backend]
|
||
Orch[orchestrator]
|
||
GW[ia_dev_gateway]
|
||
ALLM[AnythingLLM]
|
||
Oll[Ollama]
|
||
Docv --> Orch
|
||
Orch --> GW
|
||
Orch --> ALLM
|
||
Orch --> Oll
|
||
```
|
||
|
||
Les contrats HTTP détaillés : [API/README.md](../API/README.md), [orchestrator-api.md](./orchestrator-api.md), [ia-dev-service.md](./ia-dev-service.md). Vue d’ensemble écosystème et synchro : [ecosystem-architecture-and-sync.md](../ecosystem-architecture-and-sync.md).
|
||
|
||
## SSO
|
||
|
||
L’authentification utilisateur front / docv (OIDC) est décrite dans [sso-docv-enso.md](./sso-docv-enso.md) ; elle est **orthogonale** aux appels **serveur à serveur** (tokens API, réseau interne) entre docv et les services smart_ide.
|