Related
Summary
Secrets and providers should be separate concerns (N providers → 1 named secret). The daemon API now supports that model (SetSecret / secret_name + secret_store, ConfigureProvider referencing an existing name — see PR #113 / DR-047), but the UIs still treat credential entry as part of provider add/edit.
Users should be able to:
- Manage named secrets independently (add / list / update / delete; choose
memory | keychain | env)
- When configuring a provider, pick an existing
secret_name rather than inventing a per-provider key
Desired outcome
Secrets management UI (web dashboard + VS Code provider panel)
- Dedicated Secrets surface (tab or equivalent) to create/list/delete named secrets
- Show presence / store kind only — never secret values in list views
- Support
secret_store: memory | keychain | env (env = reference an exported variable)
Provider configuration
- Provider form selects
secret_name (and optional store when writing a new value) instead of only embedding a raw API key that invents ${PROVIDER}_API_KEY
- Preserve a short legacy path for “paste key while adding provider” if needed, but prefer pick-existing
Context
Acceptance criteria
Related
secret_name/secret_store, DR-047)Summary
Secrets and providers should be separate concerns (N providers → 1 named secret). The daemon API now supports that model (
SetSecret/secret_name+secret_store,ConfigureProviderreferencing an existing name — see PR #113 / DR-047), but the UIs still treat credential entry as part of provider add/edit.Users should be able to:
memory|keychain|env)secret_namerather than inventing a per-provider keyDesired outcome
Secrets management UI (web dashboard + VS Code provider panel)
secret_store:memory|keychain|env(env = reference an exported variable)Provider configuration
secret_name(and optional store when writing a new value) instead of only embedding a raw API key that invents${PROVIDER}_API_KEYContext
Acceptance criteria