@chanlerdev/scorel 0.0.1 → 0.0.2

package/docs/spec/ship/S0072-gui-glass-sidebar-and-picker-anchoring.md

@@ -0,0 +1,116 @@
+# S0072: GUI Glass Sidebar And Picker Anchoring
+
+## Goal
+
+Tighten the Codex App alignment after S0071 using the latest reference screenshots:
+make the GUI sidebar read as transparent macOS glass, remove user-visible entries for
+features that are not implemented, fix the empty workspace copy, and anchor the project
+picker to the project pill instead of floating in the center of the workspace.
+
+This is a GUI polish follow-up only. It does not change Host, Relay, Session JSONL,
+provider execution, or package distribution boundaries.
+
+## Scope
+
+- Make the main sidebar and settings sidebar use translucent glass-like surfaces over
+  the Electron vibrancy window, while keeping light and dark theme tokens.
+- Remove disabled placeholders for features that do not exist. In this spec that means
+  Search, Plugins, Automations, attachment add, permission policy dropdown, model picker,
+  microphone, placeholder Settings sections, disabled config controls, and fake config
+  links. Keep New Chat, Settings, Add Local Project, Add Remote Project, and Relay
+  pairing/refresh because those are implemented paths.
+- Empty workspace copy:
+  - with no selected Project: `我们要构建什么？`
+  - with a selected Project: `我们应该在 {Project} 中构建什么？`
+- Project picker visibility:
+  - when no Project is selected, keep a compact `选择项目` pill.
+  - when a Project is selected, show a compact project pill in the composer footer area,
+    not a long row that visually consumes the composer context strip.
+- Sidebar `添加项目` must reuse the same project picker component and menu behavior as
+  the composer project pill. It must not bypass the picker and directly open the local
+  folder dialog.
+- Project picker placement follows the trigger pill. The popover must be anchored near
+  the clicked pill and must not float in the center of the workspace.
+- In the selected-project empty heading, `{Project}` is clickable and opens the same
+  project picker.
+- Hide project metadata that is not currently backed by user-controllable GUI features,
+  including `本地模式`, `Relay 远程`, and `main`.
+- Focusing the composer textarea must not add an extra outer ring around the whole
+  composer shell.
+- Remove `不使用项目` from the picker. GUI remains Project-first per S0064.
+- It is acceptable to keep implemented add actions: Add Local Project and Add Remote
+  Project.
+
+## Not In Scope
+
+- Global Search implementation.
+- Plugin, Automation, model picker, microphone, or permission-policy implementation.
+- SSH remote device, direct WS + token, or HTTP API.
+- WebUI reuse of GUI components.
+- Replacing Electron with SwiftUI/AppKit.
+
+## Acceptance Criteria
+
+- Sidebar visually reads as a macOS glass/source-list surface in both light and dark
+  themes, rather than an opaque flat panel.
+- Primary sidebar shows only implemented top-level commands: New Chat and Settings,
+  plus Project list/add controls.
+- Settings exposes only implemented controls in this pass: Relay pairing/refresh. It
+  must not show placeholder sections like MCP, Browser, Computer Control, Hooks, Git,
+  or disabled config controls.
+- Empty workspace without a selected Project says `我们要构建什么？`.
+- Empty workspace with a selected Project says `我们应该在 {Project} 中构建什么？`.
+- The selected Project name inside that heading is an interactive project picker trigger.
+- The sidebar add-project control and composer project control share the same picker
+  component and expose the same Add Local / Add Remote actions.
+- Project picker opens next to the triggering pill, both from empty workspace and session
+  workspace, and is not centered on the page.
+- Selected-project pill stays compact; it does not become a full-width `选择项目` strip.
+- Picker contains Add Local Project and Add Remote Project, but no null-project option.
+- Composer project context does not render unsupported mode/branch labels such as
+  `本地模式` or `main`.
+- Textarea focus keeps the composer surface visually stable; no extra outer focus ring.
+- Light and dark theme screenshots show the same structure, spacing, and hierarchy.
+
+## Test Requirements
+
+- Add renderer tests that lock the empty workspace heading behavior and ensure disabled
+  placeholder sidebar/composer actions are not rendered.
+- Add renderer tests that lock the selected Project heading trigger and ensure unsupported
+  mode/branch labels are not rendered.
+- Add renderer tests that ensure Settings does not expose unimplemented placeholder
+  sections or fake config controls.
+- Add a renderer test that locks the picker option set and confirms it does not include
+  `不使用项目`.
+- Run:
+  - `pnpm --filter @scorel/app-gui typecheck`
+  - `pnpm --filter @scorel/app-gui test`
+  - `pnpm --filter @scorel/app-gui build`
+- Run a real Electron visual smoke through CDP or Computer Use:
+  - empty workspace
+  - picker opened from the project pill
+  - settings shell
+  - dark theme using system theme or `data-theme="dark"` test override
+
+## Impacted Files
+
+- `apps/gui/src/renderer/styles.css`
+- `apps/gui/src/renderer/shell/Sidebar.tsx`
+- `apps/gui/src/renderer/workspace/EmptyState.tsx`
+- `apps/gui/src/renderer/workspace/SessionView.tsx`
+- `apps/gui/src/renderer/composer/ProjectPickerMenu.tsx`
+- `apps/gui/src/renderer/composer/ProjectPickerPill.tsx`
+- `apps/gui/src/renderer/settings/SettingsNav.tsx`
+- `apps/gui/src/renderer/settings/SettingsShell.tsx`
+- `apps/gui/src/renderer/settings/sections/ConfigSection.tsx`
+- GUI renderer tests under `apps/gui/src/renderer/`
+- `docs/ROADMAP.md`
+
+## Risks And Boundaries
+
+- Electron vibrancy differs by OS and accessibility settings. CSS must still provide
+  readable fallback colors when vibrancy is unavailable.
+- Hidden placeholder removal should not delete future roadmap intent; it only removes
+  non-functional user-visible controls from the current GUI.
+- The picker anchor should use DOM geometry only in the renderer. It must not introduce
+  new IPC channels or main-process UI state.

package/docs/spec/ship/S0073-provider-model-profile-contract.md

@@ -0,0 +1,241 @@
+# S0073: Provider Model Profile Contract
+
+## Goal
+
+Turn Scorel's current single configured model into a real provider/model profile
+contract that GUI, Host runtime, CLI, and future subagents can share:
+
+- keep pi-ai as the lower provider/model abstraction;
+- let users configure pi-ai built-in providers and custom compatible endpoints;
+- expose a curated available-model pool instead of every provider catalog entry;
+- assign three role aliases from that pool: `primary`, `standard`, and `auxiliary`;
+- use the selected model's real metadata for runtime execution, session metadata, and
+  context-window-sensitive tools;
+- make GUI Settings and composer model selection reflect implemented product paths.
+
+The business outcome is simple: Scorel stops pretending there is only one model, but
+does not jump into a full provider marketplace or routing policy engine.
+
+## Scope
+
+### 1. Config contract
+
+Update `docs/spec/extensions.md` and the runtime config schema from one `[model]`
+section to a model profile contract.
+
+The new shape must support:
+
+- provider definitions:
+  - pi-ai built-in provider entries;
+  - custom compatible endpoint entries with explicit API shape;
+- provider model entries under those providers:
+  - stable `id`;
+  - provider reference;
+  - pi-ai model id;
+  - display name;
+  - optional role suitability metadata only when it is needed by UI;
+  - required metadata for custom models: `contextWindow`, `maxTokens`, `reasoning`,
+    and compatibility flags where needed;
+- available model entries:
+  - stable available-model id;
+  - reference to one provider model;
+  - optional display override;
+- role assignments:
+  - `primary`;
+  - `standard`;
+  - `auxiliary`.
+
+The schema must reject unknown sections/keys through the shared schema path. Do not add
+ad hoc special cases for one invalid key.
+
+Backward compatibility with the old single `[model]` config or intermediate
+`[models.*]` config is not required. Scorel is pre-1.0, has no production config
+inventory to preserve, and `docs/SHIP.md` allows explicit config breaks when the
+current spec says so.
+
+### 2. Provider/model resolution
+
+Keep provider execution under `packages/core/src/provider/pi-ai.ts`.
+
+Add a resolver that can:
+
+- list the configured available model summaries;
+- resolve a model by available-model id;
+- resolve a model by role alias;
+- create the correct pi-ai `Model<Api>` for both built-in and custom entries;
+- return the model's `contextWindow` for tool budgets.
+
+Scorel must not reimplement provider request protocols. It should continue to pass the
+resolved pi-ai model and API key to pi-ai.
+
+### 3. Host/runtime selection
+
+Host runtime must use the selected model for each session/turn:
+
+- default new sessions use `standard` unless the caller explicitly chooses another
+  available model or role;
+- CLI can continue using the default role without exposing a new command flag in this
+  spec;
+- GUI composer can choose an available model for new prompts/sessions;
+- session metadata records the selected model id and role when known;
+- session header persists enough selected-model metadata to keep resume auditable if
+  config later changes;
+- assistant events keep recording actual provider/model metadata from pi-ai.
+
+Tool creation must use the actual selected model's context window, not a global model
+from startup config.
+
+### 4. Protocol/client surface
+
+Expose a Host API that lets clients inspect provider connections, provider models, the
+available model pool, and role assignment.
+
+The response must be display-safe:
+
+- no API keys;
+- no raw provider payloads;
+- no Relay-visible credentials;
+- enough provider connection metadata for UI labels, role badges, and disabled/error
+  states;
+- `apiKeyEnv` is allowed in display responses, but raw `apiKey` values are not;
+- missing provider env vars are reported as credential status, not as `list_models`
+  failures;
+- if the target Project has no model profile config yet, `list_models` returns an empty
+  model list instead of surfacing config-not-found as a user-facing error.
+
+Expose a Host API for adding/updating a Project's provider/model profile. GUI must use
+this Host-owned path for both local and Relay Projects; renderer code must not write
+`.scorel/config.toml` directly.
+
+Saving a provider/model profile is a config edit, not a provider call. It must validate
+shape and merge into the existing Project config, but it must not require the target
+Host process to already have the provider API key env var set. Missing credentials
+should block runtime use, not saving.
+
+### 5. GUI surface
+
+Settings separates model management from connection management:
+
+- `模型`: provider/model profile and available models;
+- `连接`: Relay pair/refresh and remote devices.
+
+The Model settings page must support adding a provider/model profile:
+
+- show configured provider connections as source entries;
+- show provider models under the configured provider connections;
+- show available models / use pool separately from provider models;
+- show role assignments for `primary`, `standard`, and `auxiliary`;
+- add or update a provider connection;
+- add or update provider models under a provider connection;
+- add a provider model into available models before it can be used by composer, main
+  agent, or future subagents;
+- support one provider connection with multiple configured models without overwriting
+  previously-added models;
+- show missing credential status clearly without treating it as a save failure;
+- show invalid model/profile errors clearly.
+
+Composer gets a real model picker:
+
+- it lists available models from the connected Host;
+- selecting a model affects the current new session / next prompt path according to the
+  runtime contract;
+- it must not list arbitrary provider catalog entries that are not in available models.
+
+The UI should use generic role language, not Anthropic-specific names such as Opus,
+Sonnet, or Haiku.
+
+### 6. Subagent contract only
+
+This spec defines the model-selection contract future subagents must use:
+
+- default subagent selection is role-based (`primary`, `standard`, `auxiliary`);
+- explicit subagent model override, when added later, must point to an available model id;
+- subagents must not bypass the available-model pool.
+
+This spec does not implement a new subagent execution engine.
+
+## Not In Scope
+
+- OAuth or browser-based provider login.
+- Provider marketplace, pricing comparison, latency benchmarking, automatic model ranking,
+  fallback chains, or policy-based routing.
+- Dynamic remote catalog sync for every provider. Built-in pi-ai catalog and configured
+  custom model entries are enough for V1.
+- Storing raw API keys in GUI state or config. GUI only stores `apiKeyEnv`; users set
+  the environment variable on the target Host.
+- Full subagent orchestration.
+- Per-tool model routing.
+- Per-message hidden model switching not visible in session metadata.
+- Relay storage of provider credentials, prompt text, provider payloads, or model routing
+  internals.
+
+## Acceptance Criteria
+
+- `docs/spec/extensions.md` documents the new provider/model profile config and clearly
+  states that old single `[model]` config is replaced.
+- Config tests cover:
+  - one built-in provider with three available role assignments;
+  - one custom compatible endpoint with manual metadata;
+  - rejecting unknown model/profile keys;
+  - rejecting a role that points outside the available model pool;
+  - rejecting a missing provider credential env var.
+- Core/provider tests cover:
+  - resolving a built-in available model through pi-ai;
+  - resolving a custom available model;
+  - resolving role aliases to available models;
+  - using the selected model's context window.
+- Daemon/client tests cover:
+  - model profile summary is exposed without API keys;
+  - a Project with no model config returns an empty model profile summary;
+  - adding/updating a provider/model profile writes a valid `.scorel/config.toml`
+    without requiring API key env vars;
+  - adding a second model under the same provider preserves the existing provider and
+    model entries;
+  - new sessions default to `standard`;
+  - explicit selected model id and resolved display metadata are persisted in session
+    metadata;
+  - resumed sessions use the persisted selected model rather than silently switching
+    because current config changed;
+  - runtime uses the selected model when creating the provider and coding tools.
+- GUI tests cover:
+  - Settings renders separate `模型` and `连接` pages;
+  - Model settings supports adding a provider/model profile;
+  - composer renders a real model picker, not a disabled placeholder;
+  - picker options are limited to available models;
+  - role labels are generic (`primary`, `standard`, `auxiliary`) and not hard-coded to
+    Anthropic names.
+- Run:
+  - `pnpm --filter @scorel/core test`
+  - `pnpm --filter @scorel/daemon test`
+  - `pnpm --filter @scorel/app-gui typecheck`
+  - `pnpm --filter @scorel/app-gui test`
+  - `pnpm typecheck && pnpm test`
+- Run one real-provider product smoke with a real configured model profile. Mock/fake
+  provider is not accepted as completion proof for the product path.
+
+## Impacted Files
+
+- `docs/spec/extensions.md`
+- `docs/ROADMAP.md`
+- `packages/core/src/config/index.ts`
+- `packages/core/src/config/config.test.ts`
+- `packages/core/src/provider/pi-ai.ts`
+- `packages/core/src/provider/pi-ai.test.ts`
+- `packages/core/src/tools/coding-tools.ts`
+- `packages/daemon/src/index.ts`
+- daemon tests under `packages/daemon/src/`
+- protocol/client types under `packages/protocol/src/` and `packages/client/src/` if the
+  Host API needs new messages
+- GUI renderer and tests under `apps/gui/src/renderer/`
+
+## Risks And Boundaries
+
+- pi-ai built-in catalog metadata is local package data; provider-side model availability
+  can drift. Runtime errors must clearly say which configured provider/model failed.
+- Custom endpoints may not expose reliable model catalogs. V1 should require explicit
+  custom model metadata instead of guessing.
+- Changing default role assignments must not rewrite historical session events.
+- Larger context windows directly affect Read output budgets. Tests must prove the
+  selected model drives the budget.
+- A broad "login provider" abstraction would be misleading for API-key custom endpoints.
+  Use "provider connection" or "provider config" unless real OAuth/login is implemented.

package/docs/spec/ship/S0074-gui-model-provider-settings-split.md

@@ -0,0 +1,113 @@
+# S0074: GUI Model And Provider Settings Split
+
+## Goal
+
+Make GUI Settings model configuration match the user workflow:
+
+1. choose the three working models Scorel actually uses;
+2. maintain the curated available-model pool;
+3. manage LLM provider connections and provider-level models separately.
+
+The business outcome is that users can understand where a model comes from, whether it
+is allowed for Scorel use, and which model powers each agent role without reading TOML.
+
+## Scope
+
+### 1. Settings navigation
+
+Split the current model/provider combined page into three settings pages:
+
+- `模型`: working model role assignment and available models;
+- `Provider`: LLM provider connections and provider model/source management;
+- `连接`: Relay pairing and remote device connection management.
+
+`Provider` is intentionally separate from `连接`: LLM providers are model suppliers,
+while `连接` is about remote Scorel devices and Relay.
+
+### 2. Model page
+
+The `模型` page must show:
+
+- a top section for choosing `Primary`, `Standard`, and `Auxiliary` from available
+  models only;
+- an available models section showing alias, display name, source provider model,
+  provider/model id, and current role usage;
+- controls to add a provider model into available models.
+
+The page must not expose provider connection fields such as `baseUrl`, `apiKeyEnv`, or
+provider protocol controls.
+
+### 3. Provider page
+
+The `Provider` page must show:
+
+- a left provider list;
+- a right scrollable provider details panel with `providerId`, provider type, protocol
+  / API shape, `baseUrl`, and `apiKeyEnv`;
+- the provider's models below the provider details, with an action to stage/add a model
+  into available models;
+- manual provider model entry for V1.
+
+V1 can display configured provider models as the provider model source list. Real remote
+catalog sync from provider `/v1/models` is not part of this spec, but the UI should be
+shaped so that future catalog data can replace the configured list without changing the
+page hierarchy.
+
+### 4. Existing Host contract
+
+Continue using the Host-owned `list_models` and `upsert_model_profile` path. Renderer
+code must not write `.scorel/config.toml` directly.
+
+This spec can reuse the S0073 data model and does not need a new protocol message unless
+the UI needs one for clean implementation.
+
+## Not In Scope
+
+- Fetching provider `/v1/models` catalogs.
+- OAuth/browser provider login.
+- Storing raw API keys.
+- Pricing, benchmarking, automatic model ranking, routing policy, or fallback chains.
+- Changing runtime model selection semantics from S0073.
+- Renaming `primary`, `standard`, or `auxiliary`.
+
+## Acceptance Criteria
+
+- Settings nav shows separate `模型`, `Provider`, and `连接` pages.
+- `模型` page renders working model role selectors before available models.
+- `模型` page does not render provider connection fields.
+- `Provider` page renders a provider list and a scrollable provider details area.
+- `Provider` page exposes provider fields and provider models/source list.
+- Available models can still be added from a provider model through the Host upsert path.
+- Missing credentials remain status-only in Settings and do not block saving config.
+- A project with no model config still renders empty model/provider settings without
+  throwing.
+
+## Test Requirements
+
+- GUI rendering tests cover the three settings nav entries.
+- GUI rendering tests assert `模型` and `Provider` content are separated.
+- Existing daemon/config tests for S0073 must continue to pass.
+- Run:
+  - `pnpm --filter @scorel/app-gui test`
+  - `pnpm --filter @scorel/app-gui build`
+  - `pnpm typecheck`
+  - `pnpm test`
+
+## Impacted Files
+
+- `docs/spec/ship/S0074-gui-model-provider-settings-split.md`
+- `docs/ROADMAP.md`
+- `apps/gui/src/renderer/settings/SettingsShell.tsx`
+- `apps/gui/src/renderer/settings/sections/ModelSection.tsx`
+- new provider settings section under `apps/gui/src/renderer/settings/sections/`
+- `apps/gui/src/renderer/styles.css`
+- GUI renderer tests under `apps/gui/src/renderer/`
+
+## Risks And Boundaries
+
+- Splitting pages must not duplicate divergent save logic. Both pages should continue
+  using the same Host profile upsert API.
+- Provider model source list can be mistaken for live catalog sync. V1 copy must be
+  clear that it is the configured provider models list until remote catalog sync exists.
+- `Provider` must not be folded into `连接`, or users will confuse LLM suppliers with
+  Relay/remote device connectivity.

package/docs/spec/ship/S0075-provider-catalog-model-cards.md

@@ -0,0 +1,93 @@
+# S0075: Provider Catalog Model Cards
+
+## Goal
+
+Make the GUI Provider settings page usable for real provider setup:
+
+- "新建 provider" must visibly reset the details panel for a new provider;
+- provider models should be shown as selectable model cards, not a table plus an
+  always-expanded form;
+- the Provider page should fetch models from the provider `/models` endpoint from the
+  Host side, then let users choose which fetched models become available models.
+
+## Scope
+
+### 1. Host catalog API
+
+Add a Host-owned request that fetches a provider's model catalog for a Project:
+
+- input: `projectId`, `providerId`;
+- output: a display-safe list of catalog models with `id` and `displayName`;
+- renderer never reads raw API keys;
+- missing credentials return a user-facing error;
+- custom OpenAI-compatible providers use `GET {baseUrl}/models` with bearer auth.
+
+For V1, only OpenAI-compatible `/models` catalog fetch is required. Built-in pi-ai
+catalog and non-OpenAI protocols can be handled by later specs.
+
+### 2. Provider page interaction
+
+Update `Provider` settings:
+
+- right top header has a `获取模型` button;
+- provider model source list is rendered as compact cards/blocks;
+- cards are collapsed by default;
+- clicking a card expands its model config details;
+- each card has a button state representing whether the model is selected into
+  available models (`选用` / `已选用`);
+- manual add remains available for users to add a model not returned by `/models`;
+- clicking `新建 provider` clears/selects a new-provider editing state instead of
+  appearing to do nothing.
+
+## Not In Scope
+
+- Full provider catalog sync persistence or background refresh.
+- Pricing, latency, model ranking, routing policy, or fallback chains.
+- OAuth/browser login.
+- API key storage.
+- Dynamic metadata discovery for `contextWindow`, `maxTokens`, or reasoning support.
+
+## Acceptance Criteria
+
+- GUI shows a `获取模型` button on the Provider page.
+- Clicking `新建 provider` changes the details panel to a new provider draft.
+- Provider model entries render as collapsed cards by default.
+- Clicking a model card expands details/config controls.
+- Model card action shows `选用` when not in available models and `已选用` when already
+  selected.
+- Host catalog fetch uses `/models` for custom OpenAI-compatible providers.
+- Renderer uses IPC/client API for catalog fetch and never reads provider API keys.
+
+## Test Requirements
+
+- Protocol/client tests cover the new catalog fetch request shape.
+- Daemon test covers fetching from a real local HTTP `/models` endpoint.
+- GUI rendering test covers `获取模型`, collapsed model cards, and selected state text.
+- Run:
+  - `pnpm --filter @scorel/daemon test`
+  - `pnpm --filter @scorel/app-gui test`
+  - `pnpm --filter @scorel/app-gui build`
+  - `pnpm typecheck`
+  - `pnpm test`
+
+## Impacted Files
+
+- `docs/spec/ship/S0075-provider-catalog-model-cards.md`
+- `docs/ROADMAP.md`
+- `packages/protocol/src/events.ts`
+- `packages/protocol/src/wire.ts`
+- `packages/client/src/index.ts`
+- `packages/daemon/src/index.ts`
+- `apps/gui/src/shared/ipc.ts`
+- `apps/gui/src/main.ts`
+- `apps/gui/src/main/local-host.ts`
+- `apps/gui/src/main/relay-service.ts`
+- `apps/gui/src/renderer/settings/sections/ProviderSection.tsx`
+- `apps/gui/src/renderer/styles.css`
+
+## Risks And Boundaries
+
+- `/models` responses often lack context window and max token metadata. Users may still
+  need to expand a card and fill metadata before saving custom provider models.
+- Some providers do not implement OpenAI-compatible `/models`; V1 should fail clearly
+  instead of pretending every protocol has a shared catalog endpoint.

package/docs/spec/ship/S0076-provider-modal-search-and-direct-key.md

@@ -0,0 +1,70 @@
+# S0076: Provider Modal Search And Direct API Key
+
+## Goal
+
+Polish the GUI model/provider settings flow so users can configure real providers
+without confusing provider names, drafts, or credential setup:
+
+- provider display should show the LLM provider name, not a model path;
+- `Models from provider` should be searchable;
+- creating a provider should happen in a modal and only persist after save;
+- users can paste a direct API key instead of only referencing an env var.
+
+## Scope
+
+### 1. Provider name display
+
+Provider values may arrive as path-like strings during development, such as
+`AMP/codex/gpt-5.3-codex-spark`. GUI model summaries should display only the
+provider segment before the first `/`, while model ids keep the full model id.
+
+When saving a provider from GUI, normalize the provider field to that first segment.
+
+### 2. Provider catalog search
+
+The Provider page `Models from provider` panel gets a search input that filters
+configured provider models and fetched `/models` catalog cards by display name,
+provider model key, or provider model id.
+
+### 3. New provider modal
+
+Clicking `新建 provider` opens a modal form. The provider list and detail panel do not
+change until the user saves the modal. Canceling closes the modal without creating or
+selecting a draft provider.
+
+### 4. Direct API key
+
+Provider config supports either:
+
+- `apiKeyEnv`, resolved from environment variables; or
+- `apiKey`, stored directly in `.scorel/config.toml`.
+
+GUI never receives direct API key values when listing providers. Editing an existing
+direct-key provider shows only that a direct key is configured. Saving a provider with
+the API key field left blank preserves the existing direct key.
+
+## Not In Scope
+
+- OS keychain storage or encryption-at-rest.
+- Migrating existing env-key providers to direct-key providers automatically.
+- Provider delete / duplicate / reorder controls.
+- Advanced catalog metadata beyond `/models` id/name.
+
+## Acceptance Criteria
+
+- Model settings show provider names using the segment before `/`.
+- Provider page has a search input for `Models from provider`.
+- `新建 provider` opens a modal; canceling it persists nothing.
+- Saving a provider from the modal creates the provider and then selects it.
+- Users can provide either an env var name or a direct API key.
+- Provider list/status differentiates env and direct credentials without exposing raw
+  direct API key values through IPC.
+- `/models` fetch works with both env-key and direct-key providers.
+
+## Test Requirements
+
+- Config tests cover direct API key loading, redacted profile listing, and provider
+  model upsert preserving existing direct keys.
+- GUI rendering tests cover provider search, new provider modal trigger, direct API key
+  fields, and provider display normalization.
+- Typecheck and GUI build pass.