**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.
3.1 KiB
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) :
- 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 racinesmart_ide. - 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/). - Configuration ia_dev : lorsqu’un id projet est enregistré pour les agents ou le ticketing, un
conf.jsonpeut être versionné soussmart_ide/projects/<id>/conf.json; les scriptsia_devy accèdent via le lienia_dev/projects/<id>lorsque le scriptensure-ia-dev-smart-ide-project-link.sh(ou équivalent) 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.