Nicolas Cantu
58cc2493e5
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
41 lines
3.4 KiB
Markdown
41 lines
3.4 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**.
|
||
|
||
Quels services privilégier côté back (et lesquels restent orientés poste IDE) : **[services-functional-scope.md](../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](../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_ROOT/projects/<id>` (ex. `services/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.
|