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

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 (recommandé : Host enso-test-app, ProxyJump, IdentityFile, etc.).
  • remote_data_directories : liste d’objets { "role": "…", "path_on_server": "…" } décrivant les chemins sur la machine déployée (ex. répertoire docv, dossier de pièces jointes, répertoire de dumps). Les chemins sont indicatifs : les ajuster sur chaque ferme.
  • 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).

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/ : projects/README.md