[v0.7.0] Configuration post-install : bloc config: par agent (env_map + fichiers) et écriture automatique #91

New Issue

2026-08-19T14:59:24-04:00

bruno commented

2026-08-19 14:59:24 -04:00

Épique : #87 · Dépend de : #89 (secrets partagés) et #90 (flags --provider/--model)

Objectif

LE gros morceau : après am install, écrire automatiquement la configuration de l'agent avec le provider/modèle résolu — au lieu de laisser l'utilisateur chercher la doc de chaque agent (variable d'env ? fichier YAML/JSON/TOML ?).

Spécification

Nouveau bloc config: dans les définitions d'agents (config.yaml) :

- name: agentty
  ...
  config:
    env_map:                        # variables d'env attendues par l'agent
      api_key: AGENTTY_API_KEY      #  -> @secret résolu (issue #89)
      model: AGENTTY_MODEL
      base_url: AGENTTY_BASE_URL
    files:                          # fichiers de config à écrire/éditer (optionnel)
      - path: ~/.config/agentty/config.toml
        keys: [model, base_url]     # clés supportées par ce format
    provider_default: openai        # optionnel, sinon default_provider

Comportement :

à la fin de am install (après post_install, avant le succès final), résoudre provider/modèle (issue #90) puis :
1. si env_map : enregistrer la config comme env par défaut de l'agent (AgentDef.env avec placeholder @secret pour api_key) — l'injection existe déjà au start/run
2. si files : écrire le fichier (création du dossier parent, édition douce si le fichier existe : ne pas écraser les clés inconnues)
3. si aucun bloc config et install.configurable → message : « agent sans adaptateur de config — voir sa doc »
adaptateurs de formats : TOML, YAML, JSON, key=value (4 familles couvrent ~tous les agents) ; chaque agent du catalogue reçoit son bloc config: au fil de l'eau
am install --no-config / --dry-run : respectés (issue #90)
nouveau module src/agent_config.rs (pures fonctions + tests par famille de format, pattern probe.rs pour le cache éventuel)

Critères d'acceptation

am install agentty produit un agent fonctionnel (provider/modèle résolus, clé branchée via keyring)
édition douce : un fichier existant garde ses clés inconnues
env_map sans fichier = env injectée au start/run (aucun fichier écrit)
agent sans adaptateur → message clair, install réussit quand même
adaptateurs TOML/YAML/JSON/conf testés unitairement (round-trip)
--dry-run n'écrit RIEN
jamais de token en clair dans un fichier écrit : uniquement la référence @secret

Référence ROADMAP

Milestone v0.7.0 — priorité P0. Respecte le garde-fou #7 (rester orchestrateur : on écrit des fichiers de config standard, on ne réimplémente pas les agents).

Épique : #87 · Dépend de : #89 (secrets partagés) et #90 (flags --provider/--model) ## Objectif LE gros morceau : après `am install`, écrire automatiquement la configuration de l'agent avec le provider/modèle résolu — au lieu de laisser l'utilisateur chercher la doc de chaque agent (variable d'env ? fichier YAML/JSON/TOML ?). ## Spécification Nouveau bloc `config:` dans les définitions d'agents (config.yaml) : ```yaml - name: agentty ... config: env_map: # variables d'env attendues par l'agent api_key: AGENTTY_API_KEY # -> @secret résolu (issue #89) model: AGENTTY_MODEL base_url: AGENTTY_BASE_URL files: # fichiers de config à écrire/éditer (optionnel) - path: ~/.config/agentty/config.toml keys: [model, base_url] # clés supportées par ce format provider_default: openai # optionnel, sinon default_provider ``` Comportement : - à la fin de `am install` (après post_install, avant le succès final), résoudre provider/modèle (issue #90) puis : 1. si `env_map` : enregistrer la config comme env par défaut de l'agent (AgentDef.env avec placeholder `@secret` pour api_key) — l'injection existe déjà au start/run 2. si `files` : écrire le fichier (création du dossier parent, édition douce si le fichier existe : ne pas écraser les clés inconnues) 3. si aucun bloc config et `install.configurable` → message : « agent sans adaptateur de config — voir sa doc » - adaptateurs de formats : TOML, YAML, JSON, key=value (4 familles couvrent ~tous les agents) ; chaque agent du catalogue reçoit son bloc `config:` au fil de l'eau - `am install --no-config` / `--dry-run` : respectés (issue #90) - nouveau module src/agent_config.rs (pures fonctions + tests par famille de format, pattern probe.rs pour le cache éventuel) ## Critères d'acceptation - [ ] `am install agentty` produit un agent fonctionnel (provider/modèle résolus, clé branchée via keyring) - [ ] édition douce : un fichier existant garde ses clés inconnues - [ ] env_map sans fichier = env injectée au start/run (aucun fichier écrit) - [ ] agent sans adaptateur → message clair, install réussit quand même - [ ] adaptateurs TOML/YAML/JSON/conf testés unitairement (round-trip) - [ ] `--dry-run` n'écrit RIEN - [ ] jamais de token en clair dans un fichier écrit : uniquement la référence @secret ## Référence ROADMAP Milestone v0.7.0 — priorité P0. Respecte le garde-fou #7 (rester orchestrateur : on écrit des fichiers de config standard, on ne réimplémente pas les agents).

bruno added this to the v0.7.0 — Providers & configuration automatisée milestone 2026-08-19 14:59:24 -04:00

bruno added the P0 axe-7 L labels 2026-08-19 14:59:24 -04:00

bruno referenced this issue

2026-08-19 14:59:24 -04:00

[v0.7.0] am run/start --provider : override provider/modèle au lancement (providers cloud inclus) #92

bruno referenced this issue

2026-08-19 14:59:41 -04:00

[épique] Providers & configuration automatisée — registre centralisé (tokens, providers, modèles, défaut) + config auto à l'install #87

bruno referenced this issue from a commit

2026-08-19 20:41:42 -04:00

feat: v0.7.0 — configuration post-install : bloc config: par agent (env_map + fichiers), adaptateurs TOML/YAML/JSON/key=value, édition douce, jamais de token en clair (api_key = @secret) (closes #91)

bruno closed this issue