smart_ide/docs/features/remote-deployed-data-ssh.md

Données sur environnements déployés — SSH, docv, AnythingLLM, services

Règle de périmètre

• La vérité opérationnelle des données métier (fichiers documentaires, volumes applicatifs, dumps ou extractions de bases utilisées pour l’IA / docv / recherche) réside sur les machines déployées test, pprod et prod, pas dans l’historique Git des dépôts applicatifs.
• Les dépôts sources (clone local ou CI) contiennent le code et la doc versionnée ; les répertoires du type data/, caches d’index, exports SQL destinés au RAG, etc. doivent être ignorés par Git (.gitignore dans chaque dépôt applicatif concerné). Smart_ide ne remplace pas le .gitignore des projets externes : la convention est documentée ici pour alignement équipe.

Objectifs par consommateur

Consommateur	Besoin	Moyen prévu
docv	Lire / actualiser la vue documentaire et les données projet alignées sur l’état déployé	Connexion SSH (ou rebond ProxyJump) vers les hôtes ou bastions par environnement ; copie contrôlée (rsync, scp, sftp) ou commandes distantes (ex. pg_dump sur le serveur) vers une zone de travail locale ou de service autorisée, puis ingestion AnythingLLM / API docv selon les pipelines du dépôt docv.
AnythingLLM	Workspace par projet alimenté avec un corpus proche de la prod (ou de test)	Après récupération SSH depuis l’environnement cible (fichiers + éventuels dumps transformés en documents), exécution des scripts de synchro existants (anythingllm-workspaces.md, anythingllm-pull-sync-after-pull.md) en pointant vers ce miroir local ou volume monté, pas vers un data/ versionné dans Git.
Services smart_ide (éditeur, IA, extraction, recherche dans les données)	Opérer sur des fichiers ou flux qui ne sont pas dans le clone Git	Même principe : les services qui doivent lire des données déployées obtiennent un chemin résolu après fetch SSH (répertoire cache par projet / environnement) ou exécutent des commandes distantes via SSH ; les contrats HTTP existants (API/README.md) peuvent être étendus côté implémentation pour accepter une racine de lecture (*_ROOT, *_CACHE_DIR) alimentée par ce flux.

Les secrets (clés SSH, mots de passe BDD) restent hors dépôt : fichiers sous ~/.ssh/config, agents SSH, coffres locaux — jamais dans projects/*/conf.json.

Schéma logique

flowchart TB
  subgraph deployed [Environnements déployés]
    T[test]
    P[pprod]
    R[prod]
  end
  subgraph git [Dépôts Git]
    APP[clone applicatif]
  end
  subgraph bridge [Pont SSH]
    SSH[ssh_rsync_ou_commande_distante]
  end
  subgraph consumers [Consommateurs]
    DV[docv]
    ALLM[AnythingLLM]
    SVC[services_smart_ide]
  end
  T --> SSH
  P --> SSH
  R --> SSH
  SSH --> DV
  SSH --> ALLM
  SSH --> SVC
  APP --> git
  APP -.-x|pas de data versionnée| git

Déclaration dans projects/<id>/conf.json

Les chemins locaux vers clones (project_path, deploy.repository_root, etc.) sont relatifs à la racine du monorepo smart_ide (ou absolus). Les path_on_server sous smart_ide.remote_data_access restent des chemins absolus sur la machine déployée.

Bloc optionnel smart_ide (ignoré par les outils qui ne le lisent pas, ex. parties d’ia_dev qui ne sélectionnent que leurs champs) :

• remote_data_access.environments.<test|pprod|prod> : pour chaque environnement,

  • ssh_host_alias : nom d’hôte SSH tel que défini dans ~/.ssh/config (Host …). Pour enso, le déploiement lit ENSO_SSH_HOST dans le fichier enso-deploy.env de l’environnement (exemples dans enso/deploy/enso-deploy.env.example : test, pprod, prod). Si votre Host local diffère (ex. enso-test-app), renseigner ce libellé ici pour que les outils SSH du poste ciblent la bonne entrée.
  • remote_app_root (optionnel) : chemin absolu sur le serveur de la racine du clone applicatif lorsqu’il est fixé par les scripts de déploiement. Pour enso, même sémantique que ENSO_REMOTE_ROOT (ex. /home/ncantu/enso dans l’exemple du dépôt enso ; sous $HOME sur la cible pour les unités systemd utilisateur, voir commentaire dans enso-deploy.env.example).
  • remote_data_directories : liste d’objets { "role": "…", "path_on_server": "…" } avec path_on_server en chemin absolu sur la machine déployée. Pour enso, les rôles enso_monorepo_clone et docv_dp_git_data reflètent ENSO_REMOTE_ROOT et le sous-chemin par défaut data/dossiers-permanents décrit dans enso/deploy/enso-deploy.env.example et enso/docs/features/DOSSIERS_PERMANENTS_DATA_GIT.md. Ajuster si DOCV_DP_GIT_REPO_ROOT / DOCV_DP_GIT_DATA_SUBPATH sur la cible divergent.
  • database (optionnel) : description non secrète du besoin (moteur, stratégie dump) ; pas d’URL ni mot de passe dans le JSON versionné.

• anythingllm_workspace_slug (optionnel) : objet ou chaînes par env — slugs de workspace alignés sur anythingllm-workspaces.md.

Un exemple structuré est donné sous projects/enso/conf.json ; copier / adapter pour d’autres ids.

Configuration projet dans l’IDE

Objectif : indiquer quel projects/<id>/ est actif pour l’éditeur et les agents, sans mélanger avec IA_PROJECT_ID ia_dev quand ils divergent.

1. Fichier local (recommandé)

   • Copier projects/active-project.json.example vers projects/active-project.json.
   • Ce fichier est ignoré par Git (voir racine .gitignore).
   • Champs : id (obligatoire, ex. enso), default_env (optionnel : test | pprod | prod). L’exemple versionné peut contenir d’autres clés purement documentaires (ex. notes) ignorées par les automatisations.

2. Paramètres du fichier workspace VS Code / Cursor

   • Dans le .code-workspace que vous ouvrez (ex. projects/enso/smart_ide.code-workspace), renseigner :
     "smartIde.activeProjectId": "<id>"
   • Même clé possible dans .vscode/settings.json à la racine du dossier smart_ide pour un dossier unique.
   • Ces clés ne sont pas des clés natives VS Code : elles servent de convention lue par scripts, extensions maison ou règles Cursor (voir .cursor/rules/smart-ide-ia-dev-bridge.mdc).

Ordre de priorité suggéré pour les automatisations : projects/active-project.json → variable d’environnement SMART_IDE_PROJECT_ID si défini au lancement → smartIde.activeProjectId dans les settings du workspace → demande explicite à l’utilisateur.

Liens

• Intégration docv et chemins historiques locaux : docv-service-integration.md
• IA docv : docv-ai-integration.md
• AnythingLLM : anythingllm-workspaces.md
• Écosystème Git / synchro : ecosystem-architecture-and-sync.md
• Index projects/ : repo/projects-directory.md