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 58cc2493e5 chore: consolidate ia_dev module, sync tooling, and harden gateways (0.0.5) 
Initial state:
- ia_dev was historically referenced as ./ia_dev in docs and integrations, while the vendored module lives under services/ia_dev.
- AnythingLLM sync and hook installation had error masking / weak exit signaling.
- Proxy layers did not validate proxy path segments, allowing path normalization tricks.

Motivation:
- Make the IDE-oriented workflow usable (sync -> act -> deploy/preview) with explicit errors.
- Reduce security footguns in proxying and script automation.

Resolution:
- Standardize IA_DEV_ROOT usage and documentation to services/ia_dev.
- Add SSH remote data mirroring + optional AnythingLLM ingestion.
- Extend AnythingLLM pull sync to support upload-all/prefix and fail on upload errors.
- Harden smart-ide-sso-gateway and smart-ide-global-api proxying with safe-path checks and non-leaking error responses.
- Improve ia-dev-gateway runner validation and reduce sensitive path leakage.
- Add site scaffold tool (Vite/React) with OIDC + chat via sso-gateway -> orchestrator.

Root cause:
- Historical layout changes (submodule -> vendored tree) and missing central contracts for path resolution.
- Missing validation for proxy path traversal patterns.
- Overuse of silent fallbacks (|| true, exit 0 on partial failures) in automation scripts.

Impacted features:
- Project sync: git pull + AnythingLLM sync + remote data mirror ingestion.
- Site frontends: SSO gateway proxy and orchestrator intents (rag.query, chat.local).
- Agent execution: ia-dev-gateway script runner and SSE output.

Code modified:
- scripts/remote-data-ssh-sync.sh
- scripts/anythingllm-pull-sync/sync.mjs
- scripts/install-anythingllm-post-merge-hook.sh
- cron/git-pull-project-clones.sh
- services/smart-ide-sso-gateway/src/server.ts
- services/smart-ide-global-api/src/server.ts
- services/smart-ide-orchestrator/src/server.ts
- services/ia-dev-gateway/src/server.ts
- services/ia_dev/tools/site-generate.sh

Documentation modified:
- docs/** (architecture, API docs, ia_dev module + integration, scripts)

Configurations modified:
- config/services.local.env.example
- services/*/.env.example

Files in deploy modified:
- services/ia_dev/deploy/*

Files in logs impacted:
- logs/ia_dev.log (runtime only)
- .logs/* (runtime only)

Databases and other sources modified:
- None

Off-project modifications:
- None

Files in .smartIde modified:
- .smartIde/agents/*.md
- services/ia_dev/.smartIde/**

Files in .secrets modified:
- None

New patch version in VERSION:
- 0.0.5

CHANGELOG.md updated:
- yes
2026-04-04 18:36:43 +02:00

3.4 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.

Quels services privilégier côté back (et lesquels restent orientés poste IDE) : services-functional-scope.md § 2 et § 4.

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_ROOT/projects/<id> (ex. services/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.