Proposition : Amelioration du workflow IA suggest + actions parametrables

Status : IMPLEMENTEE

Problemes constates

1. L'IA repart de zero - Quand on demande une modification ("en Mo"), l'IA ne connait pas la commande precedente qui marchait. Elle reinvente tout et echoue.
2. Workflow lourd - Il faut creer l'action avant de pouvoir iterer. On ne peut pas tester/modifier librement puis sauvegarder une fois satisfait.
3. Actions statiques - Une fois l'action creee, impossible de la rendre generique avec des parametres (ex: nom du disque, seuil, etc.)

Solution proposee

1. Contexte conversationnel (backend + frontend)

Frontend (index.tsx) :

• Maintenir un tableau aiConversation qui accumule les echanges :

  [
    { role: 'user', prompt: 'taille des disques' },
    { role: 'ai', command: 'wmic logicaldisk get size', tested: true, exit_code: 0, stdout: '...' },
    { role: 'user', prompt: 'en Mo plutot' }
  ]

• Envoyer ce tableau dans l'appel suggestCommand

Backend (ai.ts - buildSystemPrompt) :

• Ajouter une section "CONVERSATION PRECEDENTE" dans le system prompt :

  CONVERSATION:
  - User: "taille des disques"
  - AI: wmic logicaldisk get size (OK, exit 0)
    Output: ...
  - User: "en Mo plutot"
  → Adapte la commande precedente, ne repars pas de zero

API (index.ts) :

• Ajouter param optionnel conversation a l'endpoint /api/ai/suggest-command

Fichiers modifies :

• connectors-api/src/index.ts : ajouter conversation au body schema
• connectors-api/src/services/ai.ts : suggestCommand() + buildSystemPrompt()
• connectors-front/src/lib/api.ts : ajouter conversation au type
• connectors-front/src/routes/connectors/instance/[id]/index.tsx : signal aiConversation, alimentation

2. Workflow tester d'abord, sauvegarder apres

Actuellement :

[Suggerer] → commande → [Tester] [Creer l'action] [Ignorer]

Propose :

[Suggerer] → commande → [Tester] [Ignorer]
                              ↓
                         resultat test
                              ↓
                    [Modifier le prompt] [Sauvegarder comme action] [Corriger (si echec)]

• "Creer l'action" n'apparait QU'APRES un test reussi (exit 0)
• Tant que le test echoue : "Corriger" (deja en place) + champ pour modifier le prompt
• Le bouton "Creer l'action" ouvre un mini-formulaire avec le nom de l'action

Fichiers modifies :

• connectors-front/src/routes/connectors/instance/[id]/index.tsx : reorganiser les boutons AI

3. Actions parametrables (inputs dynamiques)

Permettre de definir des {{variables}} dans une commande, qui deviennent des champs a remplir avant execution.

Exemple :

• Commande : df -BM {{mount_point}} | tail -1
• A l'execution : un input "mount_point" apparait avec placeholder

Schema action (config JSONB) :

{
  "type": "command",
  "command": "df -BM {{mount_point}} | tail -1",
  "output_parser": "raw",
  "inputs": [
    { "name": "mount_point", "label": "Point de montage", "default": "/", "required": true }
  ]
}

Frontend (index.tsx ou composant dedie) :

• Au clic "Run" sur une action avec inputs, afficher un formulaire dans le modal
• Remplacer les {{variables}} avant d'envoyer a l'API
• Proposer de detecter les variables lors de la creation (regex {{...}})

Backend :

• executeAction : remplacer les {{variables}} dans la commande avant exec SSH
• Validation : verifier que toutes les variables required sont fournies

Lors de la sauvegarde IA :

• Proposer "Rendre generique ?" avec detection des valeurs qui pourraient etre parametrees
• Ex: si la commande contient /dev/sda, proposer {{device}} avec default /dev/sda

Fichiers modifies :

• connectors-api/src/services/actions.ts : substitution variables a l'execution
• connectors-api/src/index.ts : accepter inputs dans le body execute
• connectors-front/src/routes/connectors/instance/[id]/index.tsx : formulaire inputs dans modal exec
• connectors-front/src/routes/actions/[id]/index.tsx ou edit/ : edition des inputs

Ordre d'implementation

1. Contexte conversationnel (impact le plus fort, corrige le probleme principal)
2. Workflow tester/sauvegarder (UX, frontend only sauf le contexte)
3. Actions parametrables (feature complete, backend + frontend)

Ce qu'on NE touche PAS

• Modele Ollama (mistral:latest) - on enrichit juste le prompt
• Structure DB actions - inputs va dans le JSONB config existant
• Endpoint execute action - on ajoute un param optionnel inputs