blomios/IdeA
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0061685b08dbcf7d17e0188d23cb928ab59669da
IdeA/.ideai/memory/multi-profile-codex-claude-model-catalogue-scoping.md
Blomios ea7ea71230 feat: finalise multi-profil Codex/Claude avec catalogue de modèles 
- Backend : clone_profile_from_seed généralisé (non OpenCode)
- Backend : catalogue static Claude/Codex (3 modèles chacun, 1 recommandé)
- Backend : commandes Tauri list_claude_models/list_codex_models
- Frontend : ProfilesSettings refonte en onglets Codex/Claude + create/duplicate/edit/delete
- Frontend : ModelSelect searchable partagé + fallback saisie manuelle
- Frontend : assignation agent nom · modèle
- Tests QA : 4 profils modèles distincts (2 Claude, 2 Codex) assignés à agents
2026-07-26 14:56:26 +02:00

3.0 KiB
Raw Blame History

name, description, metadata
name description metadata
multi-profile-codex-claude-model-catalogue-scoping memory note multi-profile-codex-claude-model-catalogue-scoping
type
project

Cadrage : profils multiples Codex/Claude + catalogue de modèles

Demande utilisateur : plusieurs profils Codex et Claude, chacun avec son modèle, assignables aux agents ; lister les modèles plutôt que saisie manuelle quand possible.

État vérifié de l'existant (2026-07-26)

Le backend est déjà générique multi-profils, contrairement à ce qu'on pourrait croire à la lecture seule des mémoires F35/F36 (qui documentaient le cas OpenCode) :

  • AgentProfile (crates/domain/src/profile.rs) porte déjà model: Option<String> (ticket #99, explicitement prévu pour Codex/Claude), et profiles.json (FsProfileStore) est une liste indexée par id, pas un slot singleton par provider.
  • Commandes déjà câblées : list_profiles, save_profile (upsert générique par id), delete_profile, reference_profiles, detect_profiles.
  • Ce qui existe seulement pour OpenCode : clone_opencode_profile_from_seed (alloue un id frais via IdGenerator) et save_opencode_provider_profile, plus un vrai catalogue de modèles (crates/application/src/agent/provider_catalogue.rs, lit le cache models.dev d'OpenCode avec repli statique).
  • catalogue.rs : un seul profil de référence Claude et un seul Codex, aucun .with_model(...).
  • Frontend ProfilesSettings.tsx : simple list+delete, pas de create/duplicate/edit inline ; toute édition rouvre FirstRunWizard.

Gaps identifiés (pas de migration de schéma nécessaire)

  1. Backend : généraliser le pattern CloneOpenCodeProfileFromSeed (fresh_profile_id via IdGenerator) en un use case CloneProfileFromSeed non spécifique à OpenCode, pour dupliquer un profil Claude/Codex avec un nom + model en override. Ne PAS laisser le frontend miner l'id (romprait la discipline IdGenerator déjà en place).
  2. Backend : catalogue de modèles Claude/Codex — aucune API fiable côté CLI, donc liste statique curée (même esprit que static_fallback_catalogue() d'OpenCode), exposée par commande Tauri infaillible (list_claude_models/list_codex_models ou générique par structuredAdapter). Le frontend garde toujours un champ de saisie manuelle en repli (liste jamais garantie exhaustive).
  3. Frontend : refonte ProfilesSettings.tsx en onglets Codex/Claude/OpenCode avec create/duplicate/edit/delete par onglet + ModelSelect searchable partagé ; simplifier FirstRunWizard pour ne créer qu'un profil par défaut par provider détecté, avec renvoi vers Settings pour en ajouter d'autres.

Découpage de livraison

DevBackend (use case + catalogues + commandes, petit lot, zéro migration) → DevFrontend (refonte Settings + first-run simplifié) → QA (créer 2 profils Claude modèles différents + 2 Codex, assigner à des agents distincts, vérifier le bon modèle atteint la CLI au lancement, non-régression OpenCode) → Git (branche feature unique, lot petit et couplé).