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

New Issue

2026-08-19T14:58:41-04:00

bruno commented

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

Objectif

Aujourd'hui, am install agentty installe le binaire mais ne configure RIEN : l'utilisateur doit ensuite chercher la doc de chaque agent (variable d'env ? fichier YAML/JSON/TOML ?) pour brancher sa clé API et son modèle. Avec 72 agents au catalogue et des conventions hétérogènes, c'est la friction n°1 après installation.

Cette épique centralise les secrets/providers/modèles dans UN endroit et configure automatiquement chaque agent à l'installation :

registre de providers : nom, base_url, liste de modèles, modèle par défaut, token dans le keyring OS (jamais en clair) ;
provider + modèle par défaut globaux (settings.default_provider) ;
à l'install : am install <agent> utilise le provider/modèle par défaut ; am install <agent> --provider X --model Y pour surcharger ; am install <agent> --no-config conserve le comportement actuel ;
au lancement : am run <agent> --provider X --model Y pour surcharger à la volée (étend #71 aux providers cloud).

Dépendances (déjà livrées, rien à refaire)

#36 secrets keyring OS · #40 profils d'environnement · #71 lien agent ↔ modèle · #66 sync (secrets exclus).

Issues enfants (ordre de livraison, dépendances entre parenthèses)

#88 — Registre de providers + commandes am providers (S→M) — aucun prérequis
#89 — Secrets partagés par provider : namespace keyring + résolution @secret fallback agent → provider (S) — dépend de #88
#90 — Champs provider/model dans AgentDef + flags --provider/--model/--no-config à l'install (S→M) — dépend de #88
#91 — Configuration post-install : bloc config: par agent (env_map + fichiers) et écriture automatique (L, le gros morceau) — dépend de #89 et [v0.7.0] AgentDef provider/model + flags --provider/--model/--no-config à l'installation (#90)
#92 — am run/start --provider : override provider/modèle au lancement, cloud inclus (S→M) — dépend de #90

Critères d'acceptation

settings.providers + settings.default_provider visibles dans am config show
am providers list/add/set-token/default fonctionnels ; tokens jamais affichés ni loggés
am install <agent> configure l'agent avec le provider/modèle par défaut (ou ceux passés en flags)
am install <agent> --no-config conserve le comportement actuel
am run <agent> --provider X --model Y fonctionne pour les providers cloud
les tokens restent dans le keyring, exclus de am sync et des sorties --json

Référence ROADMAP

Nouvel axe livré en v0.7.0 — priorité P0, avant la Phase 3 (v1.0, issues #76–#80 en P3). S'appuie sur #36/#40/#71/#66 (livrés).

## Objectif Aujourd'hui, `am install agentty` installe le binaire mais ne configure RIEN : l'utilisateur doit ensuite chercher la doc de chaque agent (variable d'env ? fichier YAML/JSON/TOML ?) pour brancher sa clé API et son modèle. Avec 72 agents au catalogue et des conventions hétérogènes, c'est la friction n°1 après installation. Cette épique centralise les secrets/providers/modèles dans UN endroit et configure automatiquement chaque agent à l'installation : - registre de providers : nom, base_url, liste de modèles, modèle par défaut, token dans le keyring OS (jamais en clair) ; - provider + modèle par défaut globaux (`settings.default_provider`) ; - à l'install : `am install <agent>` utilise le provider/modèle par défaut ; `am install <agent> --provider X --model Y` pour surcharger ; `am install <agent> --no-config` conserve le comportement actuel ; - au lancement : `am run <agent> --provider X --model Y` pour surcharger à la volée (étend #71 aux providers cloud). ## Dépendances (déjà livrées, rien à refaire) #36 secrets keyring OS · #40 profils d'environnement · #71 lien agent ↔ modèle · #66 sync (secrets exclus). ## Issues enfants (ordre de livraison, dépendances entre parenthèses) 1. **#88 — Registre de providers + commandes `am providers`** (S→M) — aucun prérequis 2. **#89 — Secrets partagés par provider** : namespace keyring + résolution `@secret` fallback agent → provider (S) — dépend de #88 3. **#90 — Champs `provider`/`model` dans AgentDef + flags `--provider`/`--model`/`--no-config` à l'install** (S→M) — dépend de #88 4. **#91 — Configuration post-install** : bloc `config:` par agent (env_map + fichiers) et écriture automatique (L, le gros morceau) — dépend de #89 et #90 5. **#92 — `am run/start --provider`** : override provider/modèle au lancement, cloud inclus (S→M) — dépend de #90 ## Critères d'acceptation - [ ] `settings.providers` + `settings.default_provider` visibles dans `am config show` - [ ] `am providers list/add/set-token/default` fonctionnels ; tokens jamais affichés ni loggés - [ ] `am install <agent>` configure l'agent avec le provider/modèle par défaut (ou ceux passés en flags) - [ ] `am install <agent> --no-config` conserve le comportement actuel - [ ] `am run <agent> --provider X --model Y` fonctionne pour les providers cloud - [ ] les tokens restent dans le keyring, exclus de `am sync` et des sorties `--json` ## Référence ROADMAP Nouvel axe livré en **v0.7.0 — priorité P0**, avant la Phase 3 (v1.0, issues #76–#80 en P3). S'appuie sur #36/#40/#71/#66 (livrés).

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

bruno added the P0 epic labels 2026-08-19 14:58:41 -04:00

bruno referenced this issue

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

[v0.7.0] Registre de providers : settings.providers + default_provider + commandes am providers #88

bruno referenced this issue

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

[v0.7.0] Secrets partagés par provider : namespace keyring providers/<nom> + résolution @secret fallback agent → provider #89

bruno referenced this issue

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

[v0.7.0] AgentDef provider/model + flags --provider/--model/--no-config à l'installation #90

bruno referenced this issue