4nk/smart_ide
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
smart_ide/docs/features/docv-ai-integration.md
Nicolas Cantu b21ac2cf64 feat: anythingllm-devtools service, builazoo project, ssh-config example, docs 
- 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
2026-04-03 19:06:19 +02:00

3.2 KiB
Raw Blame History

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, 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, 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) — 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, 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 <id> (ou le wrapper ensure-ia-dev-smart-ide-project-link.sh pour smart_ide) a été exécuté.

Flux cible (vue simplifiée)

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, orchestrator-api.md, ia-dev-service.md. Vue d’ensemble écosystème et synchro : ecosystem-architecture-and-sync.md.

SSO

L’authentification utilisateur front / docv (OIDC) est décrite dans sso-docv-enso.md ; elle est orthogonale aux appels serveur à serveur (tokens API, réseau interne) entre docv et les services smart_ide.