Nicolas Cantu
b21ac2cf64
- Add services/anythingllm-devtools HTTP API (repos + AnythingLLM + RAG) - Rename gitea-issues to git-issues across smart_ide agents and docs - Add projects/builazoo, builazoo README, cron fragment, ssh-config.example - Add ensure-ia-dev-project-link.sh; wrapper delegates smart_ide id - Bump ia_dev submodule (git-issues rename, project symlinks) - Align 4nkaiignore templates; update API index and project docs
39 lines
3.2 KiB
Markdown
39 lines
3.2 KiB
Markdown
# docv — intégrations IA via la plateforme smart_ide
|
||
|
||
**Gestion documentaire**, données sur **environnements déployés** et **SSH** (plus de vérité métier dans un `data/` Git), adaptation du dépôt docv et multi-hôte : [docv-service-integration.md](./docv-service-integration.md), [remote-deployed-data-ssh.md](./remote-deployed-data-ssh.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 [repo/projects-directory.md](../repo/projects-directory.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). L’alimentation du workspace repose sur un corpus **aligné sur les données déployées** : récupération via **SSH** depuis test / pprod / prod puis pipeline de synchro (voir [remote-deployed-data-ssh.md](./remote-deployed-data-ssh.md), [anythingllm-workspaces.md](../anythingllm-workspaces.md), 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-project-link.sh`](../../scripts/ensure-ia-dev-project-link.sh) `<id>` (ou le wrapper `ensure-ia-dev-smart-ide-project-link.sh` pour `smart_ide`) 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.
|