Nicolas Cantu
0f9a69e368
- Add features/remote-deployed-data-ssh.md (source of truth on test/pprod/prod) - Extend projects conf smart_ide.remote_data_access and anythingllm slugs (enso example) - active-project.json.example + gitignore; .vscode/settings smartIde.activeProjectId - Update docv integration docs, anythingllm-workspaces, ecosystem, API README - Cursor rule: resolve project id from active-project / env / workspace setting
1.9 KiB
1.9 KiB
AnythingLLM — workspaces par projet
Principe
- Un workspace AnythingLLM est créé (ou associé) par projet : documents indexés, embeddings, threads et paramètres RAG sont scopés au projet, pas mélangés entre dépôts.
- Cela permet à la mémoire interrogée par
ask/ les agents de rester pertinente et traçable par contexte métier.
Synchronisation avec les sources de corpus
- Une moulinette (pipeline de synchro) met à jour le workspace à partir de fichiers sélectionnés : en plus du dépôt Git (sources, doc versionnée), le corpus peut inclure des fichiers issus des environnements déployés, obtenus par SSH (rsync, dumps, exports) vers un répertoire local ou de service — voir features/remote-deployed-data-ssh.md.
- Les règles d’inclusion / exclusion (
.4nkaiignore, secrets interdits) doivent rester explicites ; les données métier ne doivent pas être commitées dans Git sousdata/sur les dépôts applicatifs.
Exploitation
- Instance Docker décrite dans services.md : stockage hôte typiquement sous
$HOME/anythingllmsur l’hôte qui exécute le conteneur — en première cible de déploiement, cet hôte est le serveur distant (SSH), pas obligatoirement le poste Linux client ; la création de plusieurs workspaces se fait dans l’UI AnythingLLM (ou via API) en conservant la convention « un workspace = un projet ». - L’orchestrateur IDE décide quand interroger AnythingLLM (voir system-architecture.md). L’URL vue depuis le client peut exiger un tunnel SSH ou un rebond réseau : deployment-target.md.
- Stratégie d’ensemble (Git, hooks, scripts de synchro) : ecosystem-architecture-and-sync.md.