@epoch-agent/protocol 1.1.0 → 2.0.0

package/dist/index.d.ts

@@ -1676,15 +1676,16 @@ type ComplianceAction = (typeof COMPLIANCE_ACTIONS)[number];
  * 侧栏最下面那一行「用户」（2026-09-07）—— 宿主可以换掉的名字和头像。
  *
  * 这是「宿主装配期按下的事实」那条路上的**第五个键**（`brand` → `sidebarMenu`
- * → `blankCards` → `blankGreeting` → 这一个 → 同一天还多了个 `userMenu`）：
- * 只读、`GET /api/config` 原样下发、界面上没有写端点。为什么是配置项而不是
+ * → `blankCards` → `blankGreeting` → 这一个）：只读、`GET /api/config` 原样下发、
+ * 界面上没有写端点。为什么是配置项而不是
  * `createWebServer()` 的装配参数，全文在
  * [`EpochConfig.brand`](./config.ts) 上（一句话：走 `epoch web --json` 起子进程的
  * 宿主没有构造函数可传）。
  *
- * ⚠️ **它和 `userMenu` 是同一天落的两个键，但管的不是同一件事**：这一个只管那一行
- * 上的**名字和头像**，那张菜单里有什么归 `userMenu`（判据在
- * [sidebar-menu.ts](./sidebar-menu.ts) 文件头第一节）。只配这一个的宿主得到
+ * ⚠️ **它只管那一行上的名字和头像，不管那张菜单里有什么**（2026-09-07 拆键时立的
+ * 那条口径）：那张菜单现在归「谁画」—— 缺省我们画（里面只剩内置的「设置」一项），
+ * 配了 `EpochConfig.userMenuHost` 归宿主自己画（判据在
+ * [sidebar-menu.ts](./sidebar-menu.ts) 文件末尾）。只配这一个的宿主得到
  * 「一行改了名字的触发器 + 一张只有『设置』的菜单」—— 那是一句说得通的话。
  *
  * ## ⚠️ 它和前四个键**默认档不同**：不配也有东西，而且照旧点得开
@@ -1694,7 +1695,7 @@ type ComplianceAction = (typeof COMPLIANCE_ACTIONS)[number];
  *
  * | 键                    | 没配 = 屏幕上 |
  * | --------------------- | ------------------------------------- |
- * | `brand` / `sidebarMenu` / `userMenu` / `blankCards` | 什么都没有 |
+ * | `brand` / `sidebarMenu` / `sidebarHeadMenu` / `blankCards` | 什么都没有 |
  * | `blankGreeting`       | **我们那句**招呼（跟着界面语言翻） |
  * | 这一个                | **我们那句**「用户」+ 一枚 `user-round` |
  *
@@ -1743,6 +1744,157 @@ interface HostUser {
     icon?: string;
 }
 
+/**
+ * 用户自己登记的模型条目（「我的模型」那张列表，2026-10-15）。
+ *
+ * ## 它补的是什么
+ *
+ * 改造前一个进程只有**一个**可配端点：`provider.{type, baseUrl, apiKey}`。副模型 /
+ * 降级模型只是一个模型名字符串，骑在主 provider 上；同一家 provider 也只能有一把 key
+ * （router 的凭据表按 `ProviderType` 存）。于是「主模型走官方、副模型走自建中转」
+ * 「两个 OpenAI 兼容端点并存」这种最常见的用法一个都表达不出来。
+ *
+ * 条目把「端点 + 凭据 + 模型名 + 这个模型的能力」捆成一个可被引用的东西。
+ * `model` / `models.utility` / `fallback.model` 写成 `@<id>` 就是指向它
+ * （见 {@link ENTRY_REF_PREFIX}）。
+ *
+ * ⚠️ **2.0.0 起这是模型唯一的写法**：`provider:` 段 + 裸模型名那条老路删了
+ * （同一个模型能同时以两种身份出现，菜单里两行一模一样），老值读到就忽略并报一条
+ * `legacy_ignored`。判据在 protocol 的 `model-ref.ts` 文件头。
+ *
+ * ## 存在哪儿
+ *
+ * `<homeDir>/models.json`，只有用户级。**文件里不放 key** —— key 进 SecretStore，
+ * 名字由 {@link entrySecretName} 算出来。判据：`config.yaml` 的写入器只会改标量和
+ * 一层嵌套（core 的 `config/write.ts`），写不了对象列表；而一份整体替换的 JSON
+ * 是最不容易半写坏的形状。
+ *
+ * ## 端点是条目自己的属性
+ *
+ * **没有「进程级统一端点」这回事**（`EPOCH_BASE_URL` / `config.gateway` 2026-10-15 删了）：
+ * 每一条条目按自己的 `provider` / `baseUrl` / `protocol` 走，用自己的 key。
+ * 宿主（星云那类）把网关地址写进 `hostPreset.models[].baseUrl` —— 那一组是只读的
+ * （`host: true`），所以「我预置的那几条一定打我的网关」由宿主写在条目里来保证。
+ * 判据在 core 的 `provider/entry-route.ts` 文件头。
+ */
+
+/**
+ * 推理强度的五档。逐字对上 `@ai-sdk/anthropic` 的 `effort` 枚举
+ * （`node_modules/@ai-sdk/anthropic/dist/index.d.ts` 里 `effort: z.ZodOptional<z.ZodEnum<…>>`），
+ * 也是 `@ai-sdk/openai` 的 `reasoningEffort` 的子集。界面上是 低 / 中 / 高 / 超高 / 极致。
+ */
+declare const REASONING_EFFORTS: readonly ["low", "medium", "high", "xhigh", "max"];
+type ReasoningEffort = (typeof REASONING_EFFORTS)[number];
+/**
+ * 「关掉思考」那一档。**不在 {@link REASONING_EFFORTS} 里**：它不是一个强度，
+ * 而且只有条目声明了 `capabilities.reasoningToggle` 才允许选。
+ */
+declare const REASONING_OFF: "off";
+type ReasoningChoice = ReasoningEffort | typeof REASONING_OFF;
+declare function isReasoningEffort(v: unknown): v is ReasoningEffort;
+/**
+ * 一段会话此刻的推理强度（输入框旁「选择强度」那张卡要画的全部东西）。
+ *
+ * 只有落在「我的模型」里、而且声明了思考模式的那一条上才有档位；别的情形 `levels` 是空的，
+ * 那张卡整个不画。
+ */
+interface ReasoningState {
+    /** 这一条声明支持的档位，按滑块从左到右的顺序 */
+    levels: ReasoningEffort[];
+    /** 滑块最左边多不多一个「关」（条目声明了「允许关闭思考」且不是「仅思考模式」） */
+    canTurnOff: boolean;
+    /** 这段会话手动选过的那一档；null = 没选过，用 {@link default} */
+    choice: ReasoningChoice | null;
+    /** 条目声明的默认档；null = 「自动」（不发强度参数，由端点自己定） */
+    default: ReasoningEffort | null;
+}
+/**
+ * 自定义端点说哪种协议。**只有 provider 是 `openai-compatible`（界面上的「自定义」）
+ * 时才看这一格** —— 内置的那几家协议由它们自己的 SDK 决定。
+ */
+declare const MODEL_ENTRY_PROTOCOLS: readonly ["openai-chat", "anthropic-messages"];
+type ModelEntryProtocol = (typeof MODEL_ENTRY_PROTOCOLS)[number];
+/**
+ * 这个模型能做什么。**每一格不填 = 跟着元数据表走**（core 的 `getCapability()`），
+ * 填了就压过它 —— 用户比我们那张静态表更清楚自建端点上挂的是什么。
+ */
+interface ModelEntryCapabilities {
+    /** 工具调用。`false` 时这一轮不发工具，它只能聊天 */
+    tools?: boolean;
+    /** 图片输入 */
+    images?: boolean;
+    /** 思考模式。不开的话强度那一组整个不出现 */
+    reasoning?: boolean;
+    /** 仅思考模式：关不掉思考（界面上不给「关」那一档） */
+    reasoningOnly?: boolean;
+    /** 允许关闭思考：滑块上多一个「关」 */
+    reasoningToggle?: boolean;
+}
+interface ModelEntry {
+    /**
+     * 稳定 id，引用它的地方写 `@<id>`。规则见 {@link isModelEntryId}。
+     * **改显示名不改它** —— 改了它等于让所有引用一起断掉。
+     */
+    id: string;
+    /** 显示名。不填就显示 {@link model} */
+    name?: string;
+    /** 走哪家的 SDK。`openai-compatible` 就是界面上的「自定义」 */
+    provider: ProviderType;
+    /** 只有自定义端点看它，缺省 `openai-chat` */
+    protocol?: ModelEntryProtocol;
+    /** 不填 = 那家的官方地址 */
+    baseUrl?: string;
+    /**
+     * 「自定义协议」：接口地址**原样使用**，不再补 `/chat/completions`。
+     * 适用于代理层或服务端已经自己处理好路径的场景。只对 `openai-chat` 协议有意义
+     */
+    rawUrl?: boolean;
+    /** 发给端点的模型名 */
+    model: string;
+    capabilities?: ModelEntryCapabilities;
+    /** 支持的推理强度档位，以及默认用哪一档（不给 = 不发强度参数，由端点自己定） */
+    reasoning?: {
+        levels: ReasoningEffort[];
+        default?: ReasoningEffort;
+    };
+    /** 上下文窗口（token）。不填 = 用元数据表的值 */
+    contextLength?: number;
+    /** 单次输出上限（token）。不填 = 用全局 `maxOutputTokens` */
+    maxOutputTokens?: number;
+    /**
+     * 宿主预置的这一条（`hostPreset.models` 物化来的，2026-10-15）。
+     *
+     * 宿主条目的语义：**只读** —— 界面不画编辑 / 删除，服务端拒绝覆盖和删除。
+     * 端点 / key 由**宿主写在条目里**（每条自带 baseUrl，打哪个地址宿主说了算），
+     * 原样生效、不强制。用户自己添加的条目永远没有这一格。
+     */
+    host?: true;
+}
+/** 引用一个条目的写法：`@<id>` */
+declare const ENTRY_REF_PREFIX = "@";
+/**
+ * id 的规则：小写字母 / 数字 / 连字符，最长 64，不以连字符开头。
+ *
+ * 收这么窄是因为它要进三个地方，三处各有各的限制：yaml 的标量（`@` 开头要引号，
+ * 其余字符都不要）、SecretStore 的名字（`^[A-Za-z0-9._:-]{1,128}$`，infra 的
+ * `assertValidSecretName`）、以及 URL 的路径段（server 的 `/api/models/:id`）。
+ */
+declare function isModelEntryId(id: string): boolean;
+/** `@<id>`。写进 `model` / `models.utility` / `fallback.model` 的就是这个 */
+declare function entryRef(id: string): string;
+/** 这个条目的 key 存在 SecretStore 里叫什么 */
+declare function entrySecretName(id: string): string;
+/** 所有条目 key 的共同前缀。启动预取靠它从 store 的名字索引里认出哪些是条目的 */
+declare const ENTRY_SECRET_PREFIX = "EPOCH_MODEL_KEY_";
+/** 一个 SecretStore 名字是不是某个条目的 key */
+declare function isEntrySecretName(name: string): boolean;
+/**
+ * 条目在界面上叫什么：显示名优先，没有就是模型名。
+ * 放 protocol 是因为 web 和 runtime 都要它，而「同一个东西两处各起一个名字」
+ * 正是这类列表最常见的不一致。
+ */
+declare function entryDisplayName(entry: Pick<ModelEntry, 'name' | 'model'>): string;
+
 /**
  * 金额的**展示**口径 —— 全仓唯一一处把数字变成「一串带货币符号的字」的地方。
  *
@@ -2042,24 +2194,35 @@ interface SettingsPaneItem {
 }
 
 /**
- * 宿主自定义的侧栏菜单项（2026-09-02）—— **一个形状，两个键**（2026-09-07 拆开）。
+ * 宿主自定义的那几格侧栏菜单（2026-09-02；2026-10-16 起「用户」那一格整个交出去了）。
  *
- * 这个文件里的 {@link SidebarMenuItem} 是**两个配置键共用的那一个 item 形状**：
+ * 这个文件里的 {@link SidebarMenuItem} 是**几个宿主配置键共用的那一个 item 形状**：
  *
  * | 键 | 画在哪 | 不配 = |
  * | -- | ------ | ------ |
  * | `EpochConfig.sidebarMenu` | 侧栏最底下那一格里「用户」**右边**那枚分体按钮（一项露在外面，其余在「⋯」里） | 那枚按钮整个没有，「用户」照旧一整行 |
- * | `EpochConfig.userMenu`    | 「用户」点开的那张菜单里的宿主项（排在「设置」上面） | 菜单里只有「设置」，**连分隔线都没有** |
+ * | `EpochConfig.sidebarHeadMenu`（2026-10-15） | 侧栏头「收起侧栏」左边那几枚图标；收起后探出来那张卡里是几行菜单 | 侧栏头一枚都不多 |
+ *
+ * 同一条消息还有一个发送方不是菜单项：`EpochConfig.brandMenuId`（2026-10-15）配了时，
+ * 点侧栏头那一格品牌发 `{ type, id: brandMenuId }`。
  *
- * ⚠️ **两个键互不兜底**，这是拆开那一笔的全部内容（老板原话：「不行，需要是两个
- * 配置」）：只配 `sidebarMenu` 的宿主得到几行常驻按钮、菜单里**一项宿主项都没有**；
- * 只配 `userMenu` 的反过来。谁都不去拿另一个顶上 —— 那种兜底的表现是宿主配了一个键
- * 却在**两处**都看见东西，而它想改掉多出来的那一处时会发现没有对应的键可关。
- * 判据在 web 的 `shell/sidebar.tsx` 上（两个常量各判一次「键在且非空数组」）。
+ * ⚠️ **2026-10-16：原来的第三格 `EpochConfig.userMenu`（「用户」点开那张菜单里的宿主项，
+ * 2026-09-07 拆出来的、2026-10-15 还长了下一级和行尾）撤了** —— 用户拍板「整张菜单归宿主
+ * 自己画」。那一格不再吃这份形状：配了 `EpochConfig.userMenuHost` 时点「用户」/头像只发
+ * 一条 {@link UserMenuMessage}（带触发器的位置），宿主弹它**自己的**菜单；不配时那张菜单
+ * 里只剩内置的「设置」一项。两条消息（出站那条和入站的 {@link OpenSettingsMessage}）
+ * 在这个文件的末尾。
  *
- * ⚠️ **类型名照旧是 `SidebarMenuItem`，没有跟着拆成两个**。它是**同一个形状**
+ * ⚠️ **剩下的两个键互不兜底**，这是 2026-09-07 拆开那一笔留下的规矩（老板原话：
+ * 「不行，需要是两个配置」）：只配一个的宿主在**另一面一项都没有**；谁都不去拿另一个
+ * 顶上 —— 那种兜底的表现是宿主配了一个键却在**两处**都看见东西，而它想改掉多出来的
+ * 那一处时会发现没有对应的键可关。判据在 web 的 `shell/sidebar.tsx` 上
+ * （几个常量各判一次「键在且非空数组」）。
+ *
+ * ⚠️ **类型名照旧是 `SidebarMenuItem`，没有跟着拆**。它是**同一个形状**
  * （`id` / `label` / `icon` 三个字段，一个字都不差），为「这一份是给哪个键的」造第二个
- * 名字只会多一处要同步的地方 —— 而两个键的 item 真要长得不一样的那天，那时才拆。
+ * 名字只会多一处要同步的地方 —— 而某个键的 item 真要长得不一样的那天，那时才拆
+ * （{@link SidebarNavItem} 就是 10-13 那样长出来的）。
  *
  * 2026-09-02 到 09-07 之间它只有一个键（`sidebarMenu`），中途还有过**同一份 items
  * 画在两处**的一版（当天定稿就被否了，见上面那条 ⚠️）。宿主那侧接的那句 `message`
@@ -2072,10 +2235,10 @@ interface SettingsPaneItem {
  *
  * ## 点下去发生什么：往父窗口发一条 `postMessage`，**不跳页**
  *
- * ⚠️ **两个键共用这一条消息，而且不带「来源」** —— 点侧栏那几行和点菜单里那几项发出去
- * 的东西**逐字节一样**（`{ type, id }`）。刻意的：宿主已经拿 `id` 认出了是哪一项，
- * 而那个 `id` 出自它自己那份配置 —— 它当然知道自己把那一项配在了哪个键上。
- * 多带一个 `from: 'sidebar' | 'menu'` 的代价是**宿主那句监听得跟着改**，
+ * ⚠️ **几个键共用这一条消息，而且不带「来源」** —— 点侧栏底部那几项、侧栏头那几枚、
+ * 品牌那一格发出去的东西**逐字节一样**（`{ type, id }`）。刻意的：宿主已经拿 `id`
+ * 认出了是哪一项，而那个 `id` 出自它自己那份配置 —— 它当然知道自己把那一项配在了
+ * 哪个键上。多带一个 `from: 'sidebar' | 'menu'` 的代价是**宿主那句监听得跟着改**，
  * 换来的是一个它本来就答得出的答案。
  *
  * 这是这一格和 `brand` 唯一的形状差别 —— 品牌是一个字符串，菜单是一个**动作**，
@@ -2113,11 +2276,15 @@ interface SettingsPaneItem {
  * 内容是**宿主自己写进自己配置文件的那个 `id`** —— 里面没有 token、没有会话 id、
  * 没有任何一个字是从别处读来的。收窄成一个可配的 origin 只会多一个键，
  * 而它唯一的效果是让宿主更容易把自己的监听配错（同 core 那条
- * 「没有消费方的配置项就是死键」）。反过来的方向照旧守着：**我们不监听
- * `message`**，所以宿主发什么进来都改不动这张页的任何状态。
+ * 「没有消费方的配置项就是死键」）。
+ *
+ * ⚠️ **反过来的方向 2026-10-16 开了一条**：宿主可以发 {@link OpenSettingsMessage}
+ * 让这张页打开设置弹窗 —— **只此一条命令**，只认父窗口（守卫判据在那个常量上）。
+ * 除它以外，宿主发什么进来都改不动这张页的任何状态；文件末尾那两节
+ * （「用户菜单归宿主」）是这一条的上下文。
  */
 /**
- * 侧栏菜单里的一项。**`sidebarMenu` 和 `userMenu` 两个键共用这一个形状**
+ * 侧栏菜单里的一项。**`sidebarMenu` 和 `sidebarHeadMenu` 两个键共用这一个形状**
  * （见文件头第一节那张表）—— 名字里的 `Sidebar` 是它 2026-09-02 出生时的位置，
  * 不是「只给 `sidebarMenu` 用」的意思。
  *
@@ -2133,9 +2300,9 @@ interface SidebarMenuItem {
      * 重了的话宿主收到消息也分不出用户按的是哪一行，而屏幕上那两行长得完全不一样。
      *
      * ⚠️ **跨键重复反过来不拦，而且它是一句说得通的话**：同一个 `id` 同时配进
-     * `sidebarMenu` 和 `userMenu`，意思是「这个去处两处都摆一份」—— 那时两处点下去
-     * 发的是同一条消息，宿主那侧本来就该做同一件事（判据在文件头「两个键共用这一条
-     * 消息」那一段）。要拦的话得让 schema 跨字段看，而它拦掉的是一个正当写法。
+     * `sidebarMenu` 和 `sidebarHeadMenu`，意思是「这个去处两处都摆一份」—— 那时两处
+     * 点下去发的是同一条消息，宿主那侧本来就该做同一件事（判据在文件头「几个键共用
+     * 这一条消息」那一段）。要拦的话得让 schema 跨字段看，而它拦掉的是一个正当写法。
      *
      * 它**不是**给人看的，所以不必好读；给人看的是 {@link label}。
      */
@@ -2165,12 +2332,13 @@ interface SidebarMenuItem {
  *
  * ## 为什么有第二个名字
  *
- * 上面那个类型的 JSDoc 写着「两个键的 item 真要长得不一样的那天，那时才拆」——
- * 10-11 那天拆的。`primary` 回答的是「哪一项单独露在外面」，而 `userMenu`
- * 那几项本来就**全在一张菜单里**，这个问题在那一面没有宾语。给它也加上的话，
- * 宿主会以为在 `userMenu` 里写 `primary: true` 能把某一项拎到菜单外面去。
+ * 上面那个类型的 JSDoc 写着「某个键的 item 真要长得不一样的那天，那时才拆」——
+ * 10-11 那天拆的。`primary` 回答的是「哪一项单独露在外面」，而 `sidebarHeadMenu`
+ * 那几枚图标（以及 2026-10-16 之前的 `userMenu`）本来就**没有这个宾语** ——
+ * 侧栏头那一排不分「外面 / 里面」。给它们也加上的话，宿主会以为在那里写
+ * `primary: true` 能把某一项拎到别处去。
  *
- * ⚠️ `userMenu` 里写了 `primary` 不报错，是**被丢掉** —— core 的配置 schema 对
+ * ⚠️ `sidebarHeadMenu` 里写了 `primary` 不报错，是**被丢掉** —— core 的配置 schema 对
  * 不认识的字段一律剥掉而不是拒绝（判据在那份 schema 的文件头：配错一个字段
  * 不该让整份配置失效）。
  */
@@ -2219,6 +2387,101 @@ interface SidebarMenuMessage {
     type: typeof SIDEBAR_MENU_MESSAGE_TYPE;
     id: string;
 }
+/**
+ * 配了 `EpochConfig.userMenuHost` 时，「用户」那一行点下去**不再画我们那张菜单**
+ * —— 改为往父窗口发一条 {@link UserMenuMessage}，宿主收到后弹**它自己的**菜单。
+ *
+ * ## 为什么整张交出去
+ *
+ * 宿主（星云工作台）要的是一张和它自己产品一致的账户菜单（账户中心 / 检查更新 /
+ * 云同步 / 退出登录……），而 2026-09-07 起我们只让它往我们画的菜单里塞项 ——
+ * 样式、位置、层级全归我们。老板 2026-10-16 拍板：**整张归它**，我们只留
+ * 「点下去了」这一件事要告诉它（这条消息）和「设置要回来开」这一件事要它告诉我们
+ * （{@link OpenSettingsMessage}）。原来的 `EpochConfig.userMenu`（往菜单里塞宿主项）
+ * 随之删掉。
+ *
+ * ⚠️ **不配 `userMenuHost` 的机器上这条消息一个字节都不发**：那时我们照旧自己画
+ * 那张菜单（2026-10-16 起里面只剩内置的「设置」一项）。两个档都发的话，宿主
+ * 会弹自己那张、我们也会弹我们那张 —— 屏幕上两张菜单叠着。
+ *
+ * ## 载荷为什么带 `rect`
+ *
+ * 宿主弹的是**自己的**菜单（Electron 原生菜单 / 它页面上的浮层），想贴着这一格弹
+ * 就得知道这一格在哪儿 —— 而它在 iframe 外面，读不到我们 DOM 里任何元素的坐标。
+ * 所以这条消息把触发器的位置带上。
+ *
+ * ⚠️ **四条边只给 `left` / `top` / `width` / `height`，不给 `right` / `bottom`**：
+ * 后两个加一次就有，多带就是多两个会漂的副本（同 {@link SidebarMenuMessage}
+ * 「不带 `label`」那条判据）；字段口径照 web 的 `MenuRect`（`DOMRect` 结构上满足它）
+ * —— 别用 `x` / `y`，那是 `left` / `top` 的别名，两个近义名就是两处会分歧的地方。
+ *
+ * ⚠️ **坐标系是这张页自己的 viewport（CSS px，`getBoundingClientRect()` 的原值，
+ * 四舍五入到整像素）**。页嵌在 iframe / webview 里时，宿主自己加上那一层的偏移 ——
+ * 我们不知道也不需要知道自己在谁的窗口里。
+ */
+interface UserMenuMessage {
+    type: typeof USER_MENU_MESSAGE_TYPE;
+    /** 触发器（「用户」那一行 / 头像那一枚）在**这张页的 viewport**里的位置，见上 */
+    rect: {
+        left: number;
+        top: number;
+        width: number;
+        height: number;
+    };
+}
+/**
+ * 那条出站消息的 `type`。**宿主和我们共用这一个字面量**，两边都别手抄。
+ *
+ * 跟 {@link SIDEBAR_MENU_MESSAGE_TYPE} / `PLUGIN_MENU_MESSAGE_TYPE` 同族：
+ * 名字都是「**发生了什么**」的陈述（这条读作「用户菜单（被点了）」），
+ * 而入站那条 {@link OPEN_SETTINGS_MESSAGE_TYPE} 是**命令**句式（「打开设置」）
+ * —— 一个宿主作者扫一眼常量表就分得清哪条是收、哪条是发。
+ */
+declare const USER_MENU_MESSAGE_TYPE = "epoch:user-menu";
+/**
+ * 宿主发进来让这张页打开设置弹窗 —— **全仓第一条入站命令**（2026-10-16）。
+ *
+ * ## 它补的是哪个洞
+ *
+ * 菜单整个归宿主之后，「设置」那一项住在**宿主的菜单**里（它的原生菜单里那一行
+ * 「设置 ⌘,」），点下去必须落回这张页 —— 而在此之前入站方向是**刻意关着**的
+ * （文件头那条 ⚠️：我们不监听 `message`，浏览器上谁都能发）。这一条是那个立场上
+ * 开的第一扇窗：**只此一条命令、只认一个 `type`、只认父窗口**。
+ *
+ * ## 守卫（web 那一侧的实现判据）
+ *
+ * - **`event.source === window.parent`** —— 和我们发消息用的是同一个对象
+ *   （DOM 规范：顶层文档时 `window.parent === window`，于是 Electron preload
+ *   那一档「自己发给自己」同一条判据就通）。`window.top` 不认：多层嵌套时该收
+ *   这条命令的是**直接**嵌我们的那一层，越过它去认更外层等于把「谁在驱动这张页」
+ *   这件事搞糊）。这条守卫真正挡住的是**我们自己页里嵌的 iframe**（比如提问页
+ *   那个答题框）：它发得出来消息，但 `source` 对不上，够不着这条命令；
+ * - **不做 origin 白名单**：①这条消息的载荷**只有一个字面量**，不写任何状态、
+ *   不做任何权限判断 —— 它唯一的效果等同于用户自己按 `⌘,`；②嵌我们的宿主
+ *   origin 不可知（`file://` 那一档就是 `'null'`），加白名单等于给最需要它的
+ *   一档判死；③同文件头那条判据：收窄成一个可配的 origin 只会多一个键，
+ *   而它唯一的效果是让宿主更容易把自己的监听配错；
+ * - 不认识的 `type`、非对象载荷、别的窗口发来的 → **静默忽略**，不报错。
+ *
+ * ## 载荷只有 `type`
+ *
+ * ⚠️ **v1 不带给「打开到哪一屏」的 `pane`**：`ConfigPaneId` 认不出来那一档在本仓
+ * 是**必须出声**的（配置里拼错一个分区名有一条带字段路径的 warn），而入站消息
+ * 没有诊断通道 —— 一个拼错的 pane 会静默落到默认屏，宿主查不出是拼错还是我们
+ * 没实现。要开这一格，得同时想清楚「认不出来时说给谁听」。
+ *
+ * ⚠️ **`settingsHidden` 把分区全藏了时不响应**（同 web 那条 `⌘,` 的判据：
+ * 屏幕上找不到设置、却进得去一张空弹窗，比两边都没有更难懂）。
+ */
+interface OpenSettingsMessage {
+    type: typeof OPEN_SETTINGS_MESSAGE_TYPE;
+}
+/**
+ * 那条入站命令的 `type`。宿主和我们共用这一个字面量。
+ *
+ * 动词句式是刻意的 —— 见 {@link USER_MENU_MESSAGE_TYPE} 上那段「陈述 vs 命令」。
+ */
+declare const OPEN_SETTINGS_MESSAGE_TYPE = "epoch:open-settings";
 
 /**
  * 配置契约。
@@ -2295,16 +2558,17 @@ declare function apiKeyEnvVar(type: ProviderType): string | null;
 /** 所有 API key 环境变量名（去重），用于「凭据是否已配置」探测 */
 declare const API_KEY_ENV_VARS: readonly string[];
 interface EpochConfig {
-    provider: {
-        type: ProviderType;
-        apiKey: string;
-        credentials: Array<{
-            apiKey: string;
-            model?: string;
-        }>;
-        baseUrl?: string;
-    };
-    model: string;
+    /**
+     * 主模型：`@<id>`，指向「我的模型」里的一条（见 `model-ref.ts`）。
+     * **缺席 = 还没有模型** —— 进程照常起，界面引导用户去加一条。
+     */
+    model?: string;
+    /**
+     * 「我的模型」（2026-10-15）。**真源是 `<homeDir>/models.json`**，由 loader 读进来；
+     * `config.yaml` 里写这一格不生效（loader 会丢掉并报一条提示）。
+     * 引用写法是 `@<id>`，形状和判据在 `model-entry.ts`。
+     */
+    modelEntries?: ModelEntry[];
     /**
      * 内部任务用的模型（方案 19）。缺省 = 全部走主模型（改造前的行为）。
      *
@@ -2312,7 +2576,7 @@ interface EpochConfig {
      * 不是「它便宜」—— 用户完全可以给它配一个同样贵的模型（比如为了压缩质量）。
      * 按行为命名，不按价格命名。
      *
-     * 取值是 `<provider>/<model>` 或裸模型名（见 `parseModelRef`）。
+     * 取值是 `@<id>`（见 `parseModelRef`）。
      */
     models?: {
         /** 目前唯一的消费方是上下文压缩 —— 长会话里最高频、也最不需要强模型的调用 */
@@ -2383,17 +2647,12 @@ interface EpochConfig {
         maxBackoffMs: number;
     };
     /**
-     * 降级去哪儿（方案 26 §2.4）。两级，顺序固定：
-     *
-     *   1. `model` —— **同一个 provider** 换个模型。先试它，因为凭据、限速桶、
-     *      计价口径都不变，用户感知最小
-     *   2. `providers` —— 换一家。同 provider 内已经没得试了才走到这儿
-     *
-     * `model` 不带 provider 前缀（带了也只取模型名）：它的定义就是「同一家的后备」，
-     * 跨家的事交给 `providers`。
+     * 降级去哪儿（方案 26 §2.4）：主模型出错时换到的那一条，`@<id>`。
+     * 缺席 = 不降级。2.0.0 之前还有「同家内置降级表」和 `providers`（换一家用那家的默认模型）
+     * 两级，都是老写法的产物，随它一起删了 —— 条目是用户自己确认过能用的那一份，
+     * 内置表里的模型名拿去打一个自建端点必然 404。
      */
     fallback?: {
-        providers: ProviderType[];
         model?: string;
     };
     /** Command hooks 配置（从 config.yaml hooks 字段解析） */
@@ -2863,30 +3122,36 @@ interface EpochConfig {
      * 不是这两个值之一会产出一条带字段路径的 warn 诊断（同 `brand` 的空串）。
      */
     brandWhenSidebarCollapsed?: BrandWhenSidebarCollapsed;
+    /**
+     * 点 {@link brand} 那一格时回给宿主的 `id`（2026-10-15）。**缺省 = 那一格只是字，点不动。**
+     *
+     * 配了之后品牌那一格变成一枚按钮，点下去发的是和宿主菜单项**同一条** `postMessage`
+     * （`{ type: 'epoch:sidebar-menu', id: <这个值> }`，判据在
+     * [sidebar-menu.ts](./sidebar-menu.ts) 的文件头）—— 宿主那句监听一个字都不用改，
+     * 它拿 `id` 就认得出这一下是点了品牌。品牌画在哪儿就在哪儿能点（侧栏头里；
+     * {@link brandWhenSidebarCollapsed} 为 `'show'` 时侧栏收起后那一格也是）。
+     *
+     * 同 `brandWhenSidebarCollapsed`：**没配 `brand` 时不起作用**，不算配错；
+     * 空串是配错了（不要就别写这个键），core 的 schema 产一条带字段路径的 warn 诊断。
+     */
+    brandMenuId?: string;
     /**
      * 宿主自定义的**侧栏那几行常驻按钮**（2026-09-02；2026-09-07 语义收窄成只管
      * 这一处）。**缺省 = 侧栏上那几行整个没有**，那一格里只剩「用户」那一行。
      *
      * 画的位置是侧栏底部「用户」那一行**上面**，一行一个宿主入口。
      *
-     * ## ⚠️ 2026-09-07：这个键**不再管那张菜单**，菜单归 {@link userMenu}
+     * ## ⚠️ 这个键只管侧栏底部那一处（2026-09-07 语义收窄）
      *
      * 中间有过一版「同一份 items 画在两处」（侧栏那几行 + 用户菜单里那几项），
-     * 当天就被否了（老板原话：「不行，需要是两个配置」）。今天是**两个键各管各的面**：
-     *
-     * | 键 | 画在哪 |
-     * | -- | ------ |
-     * | 这一个 | 只画侧栏底部那几行常驻按钮 |
-     * | {@link userMenu} | 只画「用户」点开的那张菜单里的宿主项 |
-     *
-     * ⚠️ **两个键互不兜底**：配了这一个、菜单里**一项宿主项都没有**（只剩「设置」，
-     * 连分隔线都没有）；配了 `userMenu`、侧栏上**一行都不多**。判据（以及那种兜底
-     * 为什么是坏的）在 [sidebar-menu.ts](./sidebar-menu.ts) 文件头第一节。
+     * 当天就被否了（老板原话：「不行，需要是两个配置」）。从那天起**每个键各管各的面**：
+     * 这一个只画侧栏底部那枚分体按钮，{@link sidebarHeadMenu} 只画侧栏头那几枚 ——
+     * 两个键互不兜底，判据（以及那种兜底为什么是坏的）在
+     * [sidebar-menu.ts](./sidebar-menu.ts) 文件头第一节。
      *
-     * ⚠️ **这个键自己的形状一个字都没改** —— `id` / `label` / `icon` 三个字段、
-     * 点下去那条 `postMessage`、顺序原样、空数组算配错，全部照旧。宿主已经接好的
-     * 那句 `message` 监听不用动；要动的只是「原来那一份也在菜单里」的宿主，
-     * 它把想留在菜单里的那几项抄进 `userMenu` 就行。
+     * ⚠️ **它和「用户」那张菜单再没有关系**（2026-10-16）：后者整个归宿主自己画
+     * （{@link userMenuHost}），而原来那个「往菜单里塞宿主项」的键
+     * （`EpochConfig.userMenu`）已删 —— 它自己那句 `message` 监听照旧不用动。
      *
      * 形状、口径、以及「点下去往父窗口发一条 `postMessage`」那条判据，全文在
      * [sidebar-menu.ts](./sidebar-menu.ts) 的文件头 —— 这儿只记它和 {@link brand}
@@ -2902,45 +3167,53 @@ interface EpochConfig {
      * 兜（web 那一格：外面恒为一枚按钮，其余全收进它右边那枚「⋯」展开的菜单），
      * 不由校验兜。
      *
-     * 每一项比 `userMenu` 多一个 `primary`（哪一项单独露在外面，**最多一项、
-     * 不写就是第一项**），判据在 {@link SidebarNavItem} 上。
+     * 每一项比 {@link sidebarHeadMenu} 多一个 `primary`（哪一项单独露在外面，
+     * **最多一项、不写就是第一项**），判据在 {@link SidebarNavItem} 上。
      */
     sidebarMenu?: readonly SidebarNavItem[];
     /**
-     * 宿主自定义的**「用户」菜单里那几项**（2026-09-07）。**缺省 = 那张菜单里只有
-     * 内置的「设置」一项，连那道分隔线都没有**。
+  
+    /**
+     * 「用户」那一格**整张菜单归宿主自己画**（2026-10-16）。**缺省（或 `false`）=
+     * 照旧由我们画**（那张菜单；2026-10-16 起里面只有内置的「设置」一项）。
      *
-     * 「用户」是侧栏最底下那一行（名字和头像归 {@link user}），点开是一张菜单：
-     * 这个键那几项在最上面 → 一道分隔线 → 内置的「设置」（带 `⌘,` 芯片，
-     * **永远最下面、不可配**）。
+     * 这里的**宿主**指嵌你的那个应用（星云工作台那类），不是网络意义上的 host。
      *
-     * ## ⚠️ 它和 {@link sidebarMenu} 是**两个配置，互相不兜底**
+     * 配 `true` 之后，点「用户」/头像**我们不画任何菜单**，只往父窗口发一条
+     * `{ type: 'epoch:user-menu', rect }`（`UserMenuMessage`）—— 你在自己那一侧
+     * 弹自己的菜单（原生菜单 / 自己的浮层），`rect` 是触发器的位置，想贴着弹就用它。
      *
-     * 这个键 2026-09-07 从 `sidebarMenu` 里**拆出来**的 —— 那天中途有一版是「同一份
-     * items 两处都画」，当天被否（老板原话：「不行，需要是两个配置」）。所以：
+     * ⚠️ **配套的另一半在入站方向**：你菜单里的「设置」那一项点下去时，发一条
+     * `{ type: 'epoch:open-settings' }` 回来（`OpenSettingsMessage`），
+     * 由这张页打开设置弹窗 —— 那是全仓第一条入站命令。
+     * 两条消息的形状、载荷、守卫全文在 [sidebar-menu.ts](./sidebar-menu.js) 的文件末尾。
+     * 你原生菜单里印的 `⌘,` 加速键归你自己接；这张页里的 `⌘,` 键位照旧在
+     * （页面有焦点时），两条不冲突。
      *
-     * - 只配 `sidebarMenu` → 有那几行，**菜单里一项宿主项都没有**；
-     * - 只配这一个 → **侧栏上一行都不多**，菜单里有那几项；
-     * - 两个都配 → 两处各画各的（内容可以完全不一样，那正是拆开的用处）。
+     * ⚠️ **不配这一格的机器什么都不变**：菜单照旧我们画、设置入口照旧在里面 ——
+     * 直接在浏览器里打开 `epoch web` 的场景（没有外层窗口接那条消息）走的就是这一档。
      *
-     * **不许拿另一个顶上。** 那种兜底的表现是宿主配了一个键却在两处都看见东西，
-     * 而它想关掉多出来的那一处时会发现没有对应的键可关。
+     * 同 {@link sidebarMenu} 一族：宿主装配期按下的事实、只读、`GET /api/config`
+     * 原样下发（没配就不带那个键）。写成字符串之类会产出一条带字段路径的 warn 诊断
+     * （同 `brandWhenSidebarCollapsed`：这个键只认布尔）。
+     */
+    userMenuHost?: boolean;
+    /**
+     * 宿主自定义的**侧栏头那几枚图标**（2026-10-15）。**缺省 = 一枚都不多**，侧栏头里
+     * 照旧只有「收起侧栏」+「搜索聊天」。
      *
-     * ## 形状：和 {@link sidebarMenu} **逐字同一个**
+     * 画的位置：侧栏展开时是头部右边那一排图标里、「收起侧栏」的**左边**（一项一枚，
+     * `label` 在 `aria-label` / `title` 上）；侧栏收起后指着开关探出来那张卡里是一行菜单
+     * （图标 + `label`）—— 同「搜索聊天」那两个入口，谁显示谁藏全在 CSS。
      *
-     * 同一个 {@link SidebarMenuItem}（`id` / `label` / `icon`）、同一条
-     * `postMessage`（`{ type: 'epoch:sidebar-menu', id }`，**不带来源**）、
-     * 同一张图标白名单、同一枚兜底图标。全文在
-     * [sidebar-menu.ts](./sidebar-menu.ts) 的文件头 —— 那个文件现在是**两个键共用**的
-     * 一份说明，`SidebarMenuItem` 这个名字里的 `Sidebar` 是它出生时的位置，
-     * 不是「只给 `sidebarMenu` 用」。
+     * 形状、口径逐字照 {@link sidebarMenu}（同一个 {@link SidebarMenuItem}、同一条
+     * `postMessage`、同一张图标白名单；空数组是配错了、`id` 不许重复、跨键重复不拦），
+     * 和它**互不兜底**。
      *
-     * ⚠️ 三条边界也逐字照那一个：**空数组是配错了**（不要就别写这个键，core 的 schema
-     * 为这个键产出一条带自己字段路径的 warn 诊断）、**`id` 不许重复**（在这个键内部；
-     * 跨键重复不拦，那是「两处都摆一份」）、**不设条数上限**（装不下由那张菜单
-     * 自己滚，判据在 web 的 `menu/index.tsx` 的 `placeMenu` 上）。
+     * 每一项上那个「未读点」**不是配置**：宿主在运行中用 `POST /api/host/badges` 开关，
+     * 判据在 [wire-host-badges.ts](./wire-host-badges.ts) 的文件头。
      */
-    userMenu?: readonly SidebarMenuItem[];
+    sidebarHeadMenu?: readonly SidebarMenuItem[];
     /**
      * 宿主自定义的那几张开场卡片（2026-09-04）。**缺省 = 新会话空屏上一张都没有**，
      * 那一屏仍然只有一行招呼。
@@ -2980,10 +3253,10 @@ interface EpochConfig {
      * 侧栏最下面那一行「用户」的名字和头像（2026-09-07）。**缺省 = 我们那句「用户」
      * + 一枚 `user-round`**，那一行**永远在** —— 它是设置的唯一入口。
      *
-     * ⚠️ **它只管那一行上的名字和头像，不管那张菜单里有什么** —— 菜单里的宿主项归
-     * {@link userMenu}（那是拆出来的第二个键）。两个键并排、各管一格：
-     * 只配这一个的宿主得到「一行改了名字的触发器 + 一张只有『设置』的菜单」，
-     * 而那是一句说得通的话。
+     * ⚠️ **它只管那一行上的名字和头像，不管那张菜单里有什么** —— 那张菜单归「谁画」
+     * （缺省我们画，只有内置的「设置」一项；配了 {@link userMenuHost} 归宿主自己画），
+     * 和这一格无关。两格并排、各管各的：只配这一个的宿主得到「一行改了名字的触发器 +
+     * 一张只有『设置』的菜单」，而那是一句说得通的话。
      *
      * 形状、以及「为什么这一格的默认档和上面四个键相反」，全文在
      * [host-user.ts](./host-user.ts) 的文件头 —— 这儿只记它和它们的**关系**：
@@ -3068,8 +3341,8 @@ interface EpochConfig {
      *
      * ## ⚠️ 差别二：它和 {@link settingsHidden} 是**两个键，互不掺和**
      *
-     * 形状上像 `sidebarMenu` / `userMenu` 那一对，但关系不是：那一对是同一种东西
-     * 的两个落点，这一对是**一个减一个加**。三档都说得通：
+     * 形状上像 `sidebarMenu` / `sidebarHeadMenu` 那一对，但关系不是：那一对是同一种
+     * 东西的两个落点，这一对是**一个减一个加**。三档都说得通：
      *
      * - 只配 `settingsHidden` → 我们那十个少几个，没有宿主自己的分区；
      * - 只配这一个 → 十个全在，后面多几项宿主的；
@@ -3175,22 +3448,27 @@ declare function isSearchProviderType(value: string): value is SearchProviderTyp
 declare const SEARCH_API_KEY_ENV: Record<SearchProviderType, string | null>;
 
 /**
- * 模型引用的解析（方案 19）。
+ * 模型引用的解析（方案 19 → 2.0.0）。
  *
- * 配置里写一个模型有两种形态：
+ * 配置里写一个模型**只有一种形态**：`@<id>`，指向「我的模型」里的一个条目
+ * （`<homeDir>/models.json`，形状在 `model-entry.ts`）：
  *
- *   models.utility: gpt-4o-mini                 → 主 provider 上的另一个模型
- *   models.utility: deepseek/deepseek-chat      → 换一家
+ *   model: '@deepseek-flash'
+ *   models.utility: '@relay-mini'
  *
- * 放 protocol 而不是 core：CLI 校验（`epoch config set`）和 core 解析都要用它，
- * 放一边另一边就得抄一份 —— 而这个仓库已经因为「同一份映射有两份且不一致」
- * 吃过亏（provider → 环境变量名那份，见 config.ts 的注释）。
+ * ⚠️ **2.0.0 删掉了老写法**（`provider:` 段 + 裸模型名 / `<provider>/<model>`）。
+ * 用户拍的板：「彻底删掉，一切按条目来」—— 起因是同一个模型能同时以老写法和条目
+ * 两种身份出现，菜单里两行一模一样、分不清哪个是哪个。老写法的值今天读到就忽略
+ * （core 的 loader 报一条 `legacy_ignored`），不迁移、不报错。
+ *
+ * 放 protocol 而不是 core：CLI 校验（`epoch config set`）、TUI `/model`、server 和
+ * core 解析都要用它，放一边另一边就得抄一份。
  */
 
+/** 一个模型引用：指向「我的模型」里哪一条 */
 interface ModelRef {
-    /** 不给 = 用主 provider */
-    provider?: ProviderType;
-    model: string;
+    /** 条目 id（`ModelEntry.id`），不带 `@` */
+    entry: string;
 }
 /**
  * 谁选的这个模型（方案 26）。
@@ -3213,9 +3491,9 @@ type ModelSelectionOrigin = 'config' | 'user-switch' | 'command-frontmatter' | '
 /**
  * 当前生效的模型选择（方案 26）。
  *
- * 和 {@link ModelRef} 的区别是**它一定是解析完的**：provider 必然有值
- * （`ModelRef.provider` 可以不给，表示「主 provider」），model 是可以直接
- * 发给 SDK 的裸名。换句话说 `ModelRef` 是用户写的，`ModelSelection` 是引擎认的。
+ * 和 {@link ModelRef} 的区别是**它一定是解析完的**：`provider` / `model` 是从条目上
+ * 读出来的那两格（`model` 是可以直接发给 SDK 的模型名），供显示、能力查询、计价用。
+ * 换句话说 `ModelRef` 是用户写的，`ModelSelection` 是引擎认的。
  *
  * 放 protocol 是因为三层都要它：core 的 `ProviderRouter` 持有它，
  * runtime 转出去，tui 拿它渲染状态栏 —— 而 tui 不许 import core。
@@ -3224,6 +3502,11 @@ interface ModelSelection {
     provider: ProviderType;
     model: string;
     origin: ModelSelectionOrigin;
+    /**
+     * 这个选择来自哪个条目（「我的模型」）。**2.0.0 起必有** —— 老写法删掉之后，
+     * 每一个选择都是一条条目；端点和 key 跟着条目走。
+     */
+    entry: string;
 }
 /**
  * 换模型时**调用方**才知道的会话事实（方案 26）。
@@ -3261,11 +3544,13 @@ interface SelectionContext {
  * 「超过 128k」里的那个 `128k` 只有引擎算得出来。
  */
 type SelectionRejection = 
-/** 没凭据 —— 连请求都发不出去。`envVar` 是那家的 key 环境变量名，没有就是 null */
+/**
+ * 没凭据 —— 连请求都发不出去。2.0.0 起 key 只认条目自己那把（钥匙串 `EPOCH_MODEL_KEY_<id>`），
+ * 所以这里只说是哪一条；下一步是「去设置页给这一条填 key」，不再有「设某个环境变量」那一支
+ */
 {
     code: 'no-credential';
-    provider: ProviderType;
-    envVar: string | null;
+    entry: string;
 }
 /** 会话里已经有图片，而新模型不认 */
  | {
@@ -3278,6 +3563,15 @@ type SelectionRejection =
     model: string;
     usedTokens: number;
     contextLength: number;
+}
+/**
+ * `@<id>` 指向的条目不在「我的模型」里（被删了、或者 id 打错了，2026-10-15）。
+ * 单独一档而不是归进 `no-credential`：那一档的下一步是「去配 key」，而这里的下一步是
+ * 「去列表里挑一个还在的」
+ */
+ | {
+    code: 'unknown-entry';
+    entry: string;
 };
 /**
  * 换成了、但有代价的地方（方案 26）。码 + 参数，理由同 {@link SelectionRejection}。
@@ -3333,25 +3627,13 @@ type SetSelectionResult = {
     rejection: SelectionRejection;
 };
 /**
- * 解析 `<provider>/<model>` 或裸模型名。
- *
- * **不能 `split('/')` 就完事** —— 模型名里本来就带斜杠。证据在
- * `provider/router.ts` 自己的降级表里：
+ * 解析 `@<id>`。
  *
- * ```ts
- * togetherai: 'meta-llama/Llama-3.3-70B-Instruct-Turbo',
- * ```
- *
- * 规则（顺序固定）：
- *   1. 按**第一个** `/` 切成 head + rest
- *   2. `head` 是已知 provider 且 `rest` 非空 → `{ provider: head, model: rest }`
- *   3. 否则整串都是模型名 → `{ model: 原串 }`
+ * 2.0.0 起**只认这一种**：裸模型名、`<provider>/<model>`、`@` 后面不是合法 id 的，
+ * 一律返回 `undefined` —— 调用方据此报「不是一个条目引用」（loader 当成老写法忽略、
+ * CLI / TUI / server 拒收），不猜它想指哪一条。
  *
- * 第 3 条不是兜底，是**主路径**：最常见的用法是「同一家的便宜模型」
- * （`utility: gpt-4o-mini`），不该逼用户写 provider 前缀。
- * 它同时也让 `meta-llama/Llama-...` 这种带斜杠的裸模型名能原样通过。
- *
- * @returns 空串 / 全空白返回 `undefined`（调用方据此报「没配」而不是「配错了」）
+ * @returns 合法时 `{ entry }`；空串 / 全空白 / 不是 `@<合法 id>` 时 `undefined`
  */
 declare function parseModelRef(raw: string): ModelRef | undefined;
 
@@ -3425,7 +3707,7 @@ interface CustomCommandDef {
     /**
      * frontmatter 的 `model`：这一轮临时换的模型。
      *
-     * 写法同 `models.utility`（`gpt-4o-mini` 或 `deepseek/deepseek-chat`），
+     * 写法同 `models.utility`：`@<id>`（「我的模型」里的一条），
      * 另外认一个关键字 `utility` —— 意思是「用配置里那个便宜模型」，
      * 免得每份命令文件各自把模型名抄一遍。解析结果是 {@link ExpandedCommand.model}，
      * **只管这一轮**，轮末无条件回到上一个选择（方案 26 §2.2）。
@@ -4304,9 +4586,14 @@ interface EpochMessage {
  *
  * 四件事定在这儿，渲染那一侧的细节在 web 的 `dock/question.tsx` 文件头：
  *
- * 1. **它是附加的，不替代 `options`。** 选项仍然 2–4 个必填 —— 终端里画不出
- *    iframe，让页面替代选项的话 TUI 在这一问上**一个可画的东西都不剩**，
- *    只能新增一条「自己开链接 / 跳过」的分支。
+ * 1. **给了页面，选项就可以不给**（2026-10-15 改口径，用户原话「现在还必须要有
+ *    一个菜单选项，我觉得不合理」）。原来这一条是「附加，不替代 `options`，
+ *    选项仍然 2–4 个必填」，理由是终端里画不出 iframe。那条理由站得住，可它让
+ *    **页面那一侧的每一次用法**都替终端付账：插件起页就是因为几个选项说不清，
+ *    逼模型再编两个选项出来，用户在 dock 里看到的是一张页 + 两行和页面重复的字。
+ *    现在的口径是 **0 个（仅当有 `page`）或 2–4 个**；终端那一侧落到「把地址说
+ *    出来 + 自由输入」（宿主无条件提供），代价写在 TUI 的 `use-question.ts` 那一处。
+ *    ⚠️ **1 个照旧不收**（{@link MIN_OPTIONS} 那条「一个选项不是问题」没变）。
  * 2. 🔴 **`url` 只收本机回环**（`127.0.0.1` / `localhost`）。⚠️ 这一格和
  *    `EpochConfig.settingsPanes` 那个 iframe **表面像、安全口径相反**：
  *    那边的 url 来自**用户自己写的 `config.yaml`**，所以「给什么嵌什么」站得住；
@@ -4366,12 +4653,18 @@ interface QuestionItem {
     question: string;
     /** 极短标签，UI 上当 chip 用（≤ {@link MAX_HEADER_CHARS} 字） */
     header: string;
-    /** {@link MIN_OPTIONS}–{@link MAX_OPTIONS} 个选项 */
+    /**
+     * {@link MIN_OPTIONS}–{@link MAX_OPTIONS} 个选项；带 {@link page} 时**可以是空数组**
+     * （判据在文件头「页面位」第 1 条）。
+     *
+     * ⚠️ 键本身**始终在**（空的时候是 `[]`，不是缺键）：宿主那几处都是直接
+     * `item.options.map(...)`，改成可选键等于让每一处各自补一个 `?? []`。
+     */
     options: QuestionOption[];
     /** 多选（答案是数组）还是单选（答案是一个字符串） */
     multiSelect: boolean;
     /**
-     * 这一问还可以嵌一张页面（插件在本机起的）。**附加，不是替代 `options`**。
+     * 这一问还可以嵌一张页面（插件在本机起的）。给了它，`options` 就可以是空的。
      *
      * 不给 = 今天那个纯选项的形态（绝大多数提问）。给 = dock 在正文区多画一个
      * `<iframe>`，用户在页面上操作完，答案经 `postMessage` 回到父文档、
@@ -4419,7 +4712,12 @@ interface QuestionAnswer {
  * 通常意味着它没读上下文。工具会**拒绝**并把这个上限说给模型（验收 5）。
  */
 declare const MAX_QUESTIONS = 4;
-/** 每个问题的选项数下界。一个选项不是问题，是通知 */
+/**
+ * 每个问题的选项数下界。一个选项不是问题，是通知。
+ *
+ * 唯一的例外是**带页面、一个选项都不给**（{@link QuestionItem.page}）——
+ * 那时问题在页面里，不在选项里。给了就得够这个数。
+ */
 declare const MIN_OPTIONS = 2;
 /** 每个问题的选项数上界。超过四个用户就开始扫而不是读了 */
 declare const MAX_OPTIONS = 4;
@@ -7087,6 +7385,20 @@ type WireHubEvent =
     text: string;
     autoSend: boolean;
 }
+/**
+ * **宿主未读点那张表**（2026-10-15）—— 此刻亮着点的那几项宿主菜单的 `id`，**整张表**。
+ * 形状、三条投递路径、以及「补齐为什么走这一帧而不是一发 GET」全在
+ * [wire-host-badges.ts](./wire-host-badges.ts) 的文件头。
+ *
+ * ⚠️ **它有两种身份**：宿主改了一项 → 广播帧（进环形缓冲、占序号）；每一条连接刚接上
+ * → **连接级帧**（`seq: 0`，排在 `connected` 和补帧之后）。两种都**没有 `sessionId`**
+ * （进程级，同 `plugins-changed`）。客户端照单全收、后到的盖掉先到的 —— 同一条流上
+ * 的顺序就是它们的新旧。
+ */
+ | {
+    type: 'host-badges';
+    dots: string[];
+}
 /**
  * 这一轮的用户消息 —— **一轮开跑那一刻**广播（2026-10-10）。
  *
@@ -7164,6 +7476,9 @@ type WireTaggedEvent = {
  * 它们一律 `seq: 0`，服务端发它们时**不写 SSE 的 `id:` 行**。
  * 广播帧从 1 开始。
  *
+ * ⚠️ 2026-10-15 起连接级帧多一种：`host-badges` 接上那一刻的整张表
+ * （同一个 `type` 也有广播那一种身份，判据在那一帧上）。不认识它的客户端照常忽略即可。
+ *
  * `ts` 是服务端产生这条事件的 epoch 毫秒。它**不是**给排序用的（`seq` 才是），
  * 是给界面画时间戳和算「这一步跑了多久」用的。
  */
@@ -7179,7 +7494,8 @@ interface WireEnvelope<E extends WireTaggedEvent = WireEvent> {
      * **连接级帧（`connected` / `stream-reset`）没有它** —— 它们描述的是这条连接，
      * 不是某个会话。
      *
-     * ⚠️ **进程级的广播帧也没有它**（2026-09-24 起只有 `plugins-changed` 一种）：
+     * ⚠️ **进程级的广播帧也没有它**（2026-09-24 起的 `plugins-changed`、2026-10-15 起的
+     * `host-badges`）：
      * 它进环形缓冲、占广播序号，但说的事不属于任何一段会话。在那之前这一句写的是
      * 「其余每一帧都必有」—— 读到这儿的人别按那句旧话去断言。
      */
@@ -7758,6 +8074,63 @@ interface BackgroundTaskInfo {
     artifact?: string;
 }
 
+/**
+ * 宿主未读点（2026-10-15）—— 宿主在**运行中**开 / 关某一项宿主菜单上的那个小圆点。
+ *
+ * ```
+ * POST /api/host/badges   { id, dot }  → 200 WireHostBadges（改完之后的整张表）
+ * GET  /api/host/badges                → 200 WireHostBadges
+ * ```
+ *
+ * ## 它是运行期状态，不是配置
+ *
+ * 那几项**画不画**归配置（`EpochConfig.sidebarHeadMenu`，装配期按下的事实）；某一项
+ * **此刻有没有未读**归宿主的业务（站内信来了一条），只有宿主在运行中才知道。所以它
+ * 只在服务进程的内存里，**进程重启即清空** —— 一个上次进程留下的未读点在启动时自己
+ * 冒出来，说的是一件宿主此刻并不知道的事。
+ *
+ * ## 三条投递路径
+ *
+ * | 页面此刻在哪 | 走哪条 |
+ * | --- | --- |
+ * | 首屏，流还没接上 | `GET /api/config` 的 `hostBadges`（有点才带这个键） |
+ * | 流**每一次**接上（含断线重连） | 连接级帧 `host-badges`（`seq: 0`）—— 接上那一刻的整张表 |
+ * | 流开着，宿主改了一项 | 广播帧 `host-badges`（进环形缓冲）—— 改完之后的整张表 |
+ *
+ * ⚠️ **补齐走流里那一帧，不走「连上之后自己 GET 一次」**（`host-compose` 走的是后者）。
+ * 帧载荷是**整张表**而不是增量，所以晚到的一份旧表会盖掉新表：一发 GET 和流上的帧
+ * 走两条连接、谁先到不定，要么加一个版本号去比，要么让它们在同一条有序的流上 ——
+ * 服务端在 `connected` 和补帧之后、登记进扇出之前同步塞一帧当前的表，之后的每一帧
+ * 都排在它后面。断线续传补回来的那几帧旧表也排在它前面，最后落地的总是此刻那一份。
+ *
+ * ## ⚠️ 没有「回环之外一律 403」那道闸
+ *
+ * 判据同 `POST /api/host/compose`：那道闸守的是「这一发会往用户盘上写东西 / 起一个
+ * 子进程」。这一发只改内存里的一张表、让界面上亮一个点，能力不比任何一条已鉴权的写
+ * 端点多。它照旧过鉴权和 `Origin` 那道闸（POST）。
+ */
+/**
+ * 此刻**亮着点**的那几项的 `id`（宿主菜单项的 `id`，同 `SidebarMenuItem.id`），
+ * 按第一次点亮的先后排。
+ *
+ * ⚠️ 形状是「亮着的那几个 id」，不是 `id → boolean`：关掉就是从表里拿掉，于是
+ * 「没有这一项」和「这一项是 false」不会是两种说法。以后要带数字的话加一格并列的
+ * 字段，这一格的意思不变。
+ *
+ * ⚠️ **不认得的 `id` 照收**（服务端不拿它去对配置）：界面上只有配过的那几项会画点，
+ * 多出来的 id 不画、不报错 —— 宿主可以先点亮再配，也可以对着同一张表在几处画。
+ */
+interface WireHostBadges {
+    dots: string[];
+}
+/** `POST /api/host/badges` 的请求：开 / 关**一项**的点。同一个值写两次是幂等的（不发帧） */
+interface WireHostBadgeRequest {
+    /** 宿主菜单项的 `id`，非空字符串 */
+    id: string;
+    /** `true` 点亮、`false` 熄掉。只认布尔，写成字符串是 400 */
+    dot: boolean;
+}
+
 /**
  * REST 载荷契约 —— [方案 20 §3](../../../docs/verify/VERIFY_RECORD-20-web.md) 那张端点表的类型化版本。
  *
@@ -7838,12 +8211,6 @@ interface WireHealthResponse {
     version: string;
 }
 declare const WIRE_HEALTH_FIELDS: WireFields<WireHealthResponse>;
-/** `provider` 的脱敏视图。**绝不是** `EpochConfig.provider` —— 那里面有真的 API key */
-interface WireProviderSummary {
-    provider: string;
-    /** 已脱敏（`maskApiKey`）。TUI 的 `/model` 显示的就是它 */
-    apiKeyHint: string;
-}
 /**
  * 工具清单的一行。只给名字和描述，schema 不下发。
  *
@@ -8085,7 +8452,8 @@ declare const WIRE_ABOUT_FIELDS: WireFields<WireAbout>;
  */
 interface WireConfigResponse {
     sessionId: string;
-    model: string;
+    /** 配置里的主模型，`@<id>`；还没配时是 null */
+    model: string | null;
     /**
      * 权限级别。字段名跟 `EpochConfig.permission` 对齐（前端原来叫 `permissionLevel`，
      * 于是首屏那一栏永远是 `undefined`）。
@@ -8215,14 +8583,16 @@ interface WireConfigResponse {
      * 两个值的含义在那边的表上。形状口径同上面 {@link brand}。
      */
     brandWhenSidebarCollapsed?: BrandWhenSidebarCollapsed;
+    /** 点品牌那一格回给宿主的 `id`（2026-10-15）—— `EpochConfig.brandMenuId` 原样转发，没配就没有这个键 */
+    brandMenuId?: string;
     /**
      * 宿主自定义的**侧栏那几行常驻按钮** —— **宿主没配就没有这个键**（2026-09-02）。
      *
-     * ⚠️ **2026-09-07 语义收窄成只管那几行**：那天中途有一版把这一份同时画进
-     * 「用户」那张菜单里，当天定稿否了它 —— 菜单里的宿主项从此是**另一个键**
-     * （{@link userMenu}），两个键**互不兜底**。**网线上这一格的形状一个字都没改**，
-     * 加的是并排那个新键；而画在哪儿本来就是那张界面自己的排版决定，
-     * 这条端点也服务着自己画前端的宿主（EMBEDDING §10）。
+     * ⚠️ **2026-09-07 语义收窄成只管那一处**：那天中途有一版把这一份同时画进
+     * 「用户」那张菜单里，当天定稿否了它 —— 从那以后每个键**只管自己那一面**、
+     * 互不兜底（2026-10-16 起「用户」那张菜单整个归宿主自己画，见下面
+     * {@link userMenuHost}）。**网线上这一格的形状一个字都没改**；而画在哪儿本来
+     * 就是那张界面自己的排版决定，这条端点也服务着自己画前端的宿主（EMBEDDING §10）。
      *
      * 和 {@link brand} 同一个形状、同一个理由，连搭在这条端点上的理由都一样：
      * 侧栏首屏就要画它，为一份可选的静态清单另开一个端点等于让每个客户端多一次往返。
@@ -8238,20 +8608,35 @@ interface WireConfigResponse {
      */
     sidebarMenu?: readonly SidebarNavItem[];
     /**
-     * 宿主自定义的**「用户」菜单里那几项** —— **宿主没配就没有这个键**（2026-09-07）。
+     * 「用户」那一格**整张菜单归宿主自己画**（2026-10-16）—— `EpochConfig.userMenuHost`
+     * 原样转发；**宿主没配就没有这个键**。
      *
-     * 来源是 `EpochConfig.userMenu`。**item 的形状和上面那个键逐字同一个**
-     * （同一个 {@link SidebarMenuItem}、同一条 `postMessage`），差的只是画在哪一格 ——
-     * 全文在 [sidebar-menu.ts](./sidebar-menu.ts) 的文件头第一节那张表。
+     * `true` = 那一格点下去我们**不画任何菜单**：往父窗口发一条 `{ type: 'epoch:user-menu',
+     * rect }`（触发器在页 viewport 里的位置），宿主自己弹它的菜单；配套的入站命令
+     * `epoch:open-settings`（宿主点自己菜单里的「设置」时发回来）在
+     * [sidebar-menu.ts](./sidebar-menu.js) 的文件末尾。
      *
-     * ⚠️ **两个键在这条网线上也互不兜底**：客户端拿不到这个键时，那张菜单里
-     * **一项宿主项都没有**（第一方 Web UI 那边只剩内置的「设置」，连分隔线都没有）
-     * —— **不许拿 `sidebarMenu` 那一份顶上**。自己画前端的宿主（EMBEDDING §10）
-     * 照同一条口径：两个键各画各的面，缺哪个就少哪一面。
+     * ⚠️ **没这个键（或 `false`）= 老形态**：菜单照旧我们画。直接在浏览器里打开
+     * `epoch web`（没有外层窗口接那条消息）走的就是这一档 —— 所以这一格**不是开关**，
+     * 是「这一格由谁画」的两档，缺省档必须仍然是完整可用的（设置入口在里面）。
      *
      * ⚠️ **原样转发，服务端一个字都不改**，判据逐字同上面那个 `sidebarMenu`。
      */
-    userMenu?: readonly SidebarMenuItem[];
+    userMenuHost?: boolean;
+    /**
+     * 宿主自定义的**侧栏头那几枚图标**（2026-10-15）—— `EpochConfig.sidebarHeadMenu` 原样转发，
+     * 没配就没有这个键。口径逐字同 {@link sidebarMenu}（同一个 item 形状、同一条 `postMessage`、
+     * 两个键互不兜底）。
+     */
+    sidebarHeadMenu?: readonly SidebarMenuItem[];
+    /**
+     * 首屏那一刻**亮着点**的那几项（2026-10-15）—— **一个都没亮就没有这个键**。
+     *
+     * 它只管「流还没接上」那一小段：流一接上，服务端就在那条流上补一帧当前的整张表
+     * （连接级 `host-badges`），从那以后以流为准。判据全文在
+     * [wire-host-badges.ts](./wire-host-badges.ts) 的文件头。
+     */
+    hostBadges?: WireHostBadges;
     /**
      * 宿主自定义的那几张开场卡片 —— **宿主没配就没有这个键**（2026-09-04）。
      *
@@ -8351,8 +8736,12 @@ interface WireConfigResponse {
      * {@link WireCompressionLine} 的第一节。
      */
     compression: WireCompressionLine;
-    /** 没配 provider 时为 null */
-    provider: WireProviderSummary | null;
+    /**
+     * 这个进程**跑得了会话**（有主模型、模型层起来了）。false 时界面进只读那一档、
+     * 引导用户去设置页「添加模型」—— 2.0.0 之前这一格是 `provider: WireProviderSummary | null`，
+     * 随老写法的 `provider:` 段一起换掉：今天「能不能跑」不再由某一家 provider 的 key 决定
+     */
+    modelReady: boolean;
     tools: readonly WireToolSummary[];
     /** 方案 17 的启动诊断。有 `error` 的要在界面上显眼地摆出来 */
     diagnostics: readonly Diagnostic[];
@@ -9547,7 +9936,8 @@ declare const WIRE_SEND_MESSAGE_FIELDS: WireFields<WireSendMessageRequest>;
  * `POST /api/sessions/:id/attachments` 的回执（2026-09-11）。
  *
  * 请求体是**裸字节**（`application/octet-stream`），原始文件名走查询串
- * `?name=`。不用 multipart：这条路上只有一个文件、没有别的字段，
+ * `?name=`；`?dir=` 落进一个预留过的附件文件夹的某一层（2026-10-15，回的 `name`
+ * 是 `dir/文件名`，见 {@link WireAttachmentFolderResponse}）。不用 multipart：这条路上只有一个文件、没有别的字段，
  * 而 multipart 要在服务端引一个解析器（或手写一个），换来的只是把一个
  * 查询参数搬进 body。
  *
@@ -9571,6 +9961,15 @@ interface WireAttachmentUploadResponse {
     bytes: number;
 }
 declare const WIRE_ATTACHMENT_UPLOAD_FIELDS: WireFields<WireAttachmentUploadResponse>;
+/**
+ * `POST /api/sessions/:id/attachments/folder?name=` 的回执（2026-10-15）：占下的文件夹名
+ * （撞名加过后缀）。之后那个文件夹里的文件带 `?dir=<这个名字>[/子目录]` 逐个传；
+ * 发消息时 `attachments` 里放的就是这个名字 —— 服务端交给模型的是一份清单，不是正文。
+ */
+interface WireAttachmentFolderResponse {
+    name: string;
+}
+declare const WIRE_ATTACHMENT_FOLDER_FIELDS: WireFields<WireAttachmentFolderResponse>;
 /**
  * 立即 202，结果走 SSE。不是长轮询 —— 5 分钟的任务会撞上任何一层代理的超时。
  *
@@ -9759,6 +10158,22 @@ interface WireAbortResponse {
     returned?: EpochUserContent[];
 }
 declare const WIRE_ABORT_FIELDS: WireFields<WireAbortResponse>;
+/**
+ * `DELETE /api/sessions/:id/messages/:clientMessageId` —— 撤回一条还在排队的消息
+ * （2026-10-15，输入框上方那张排队卡片的删除键）。
+ *
+ * 编号就是发送时带上的那个 `WireSendMessageRequest.clientMessageId`：没带编号发出去的
+ * 消息撤不回来（浏览器每条都带，判据在那一格上）。
+ *
+ * `withdrawn: false` **不是失败**：引擎已经把它拌进了正在跑的那一轮、或者已经用它开了
+ * 新的一轮 —— 那一刻事件流上会（或者已经）有它的 `steer` / `user-message`，前端照着
+ * 那一帧把它画进对话就是了。所以这一条恒回 200，会话不存在才是 404。
+ */
+interface WireWithdrawMessageResponse {
+    /** 真从队列里拿掉了 = `true`；已经被取走 / 编号不认得 = `false` */
+    withdrawn: boolean;
+}
+declare const WIRE_WITHDRAW_MESSAGE_FIELDS: WireFields<WireWithdrawMessageResponse>;
 /**
  * `GET /api/sessions/:id/approvals` —— 重连之后补拉挂起的审批。
  *
@@ -11970,9 +12385,9 @@ declare const WIRE_ROLE_REMOVE_FIELDS: WireFields<WireRoleRemoveResponse>;
  * | 每张卡上有哪几项 | `HostMarketplaces.pluginMenu`（runtime，按条目调）| 宿主的代码      |
  * | 点了之后发生什么 | 一条 `postMessage`（这个文件）                   | 宿主的窗口      |
  *
- * ⚠️ **第一半是一个按条目调的函数，不是一个配置键** —— 这是它和侧栏那两张宿主菜单
- * （[sidebar-menu.ts](./sidebar-menu.ts)，`EpochConfig.sidebarMenu` / `userMenu`）
- * 唯一的形状差别。那两张是**整页一份**，写在配置文件里就够了；这一张是**每一条各一份**，
+ * ⚠️ **第一半是一个按条目调的函数，不是一个配置键** —— 这是它和侧栏那几份宿主菜单
+ * （[sidebar-menu.ts](./sidebar-menu.ts)，`EpochConfig.sidebarMenu` / `sidebarHeadMenu`）
+ * 唯一的形状差别。那几份是**整页一份**，写在配置文件里就够了；这一张是**每一条各一份**，
  * 而「这一条给不给删」要看这一条是谁传的 —— 一个静态的配置键表达不出来。
  *
  * ## 点下去发生什么：**逐字照侧栏那一条**
@@ -11994,9 +12409,9 @@ declare const WIRE_ROLE_REMOVE_FIELDS: WireFields<WireRoleRemoveResponse>;
  *
  * 宿主在自己那一侧删完，调一句 `runtime.plugins.refresh()` 把目录重读一遍。那一下会
  * 让服务端往全局事件流里发一帧 `plugins-changed`（判据在 wire.ts 那一帧上），开着的
- * 那一页收到后自己重读一次列表。**这一条消息本身不参与**：我们照旧**不监听
- * `message`**（同 sidebar-menu.ts 那条「反过来的方向照旧守着」），宿主发什么进来
- * 都改不动这张页。
+ * 那一页收到后自己重读一次列表。**这一条消息本身不参与**：除了 sidebar-menu.ts
+ * 那条 `epoch:open-settings`（2026-10-16 开的**唯一一条**入站命令，它只开设置弹窗），
+ * 我们**不监听 `message`**，宿主发什么进来都改不动这张页。
  *
  * ## ⚠️ 局域网那一档下这张菜单**不画**
  *
@@ -13399,6 +13814,14 @@ interface WirePluginUploadPlan {
     description: string;
     /** 清单里的 `author.name`，摊平；没写就是 `null` */
     author: string | null;
+    /**
+     * 包里自带的那张图标，**一律是 `data:`**（2026-10-15）。`null` 的口径和读法同
+     * {@link WirePluginPreview.icon}（core 的 `readPluginIcon`）。
+     *
+     * ⚠️ **它是兜底**：上传那一屏的头像先用表单里那格 `icon`（宿主声明了才有），
+     * 那一格缺席才轮到它。之前没有这一格，面板头上永远是名字首字。
+     */
+    icon: string | null;
     /** 会打进包里的每一个文件，按路径排过序 */
     files: readonly WirePluginUploadFile[];
     totalBytes: number;
@@ -14580,9 +15003,9 @@ type WireSettingLayer = 'builtin' | 'user' | 'env' | 'project' | 'projectLocal'
 /**
  * 一个配置项的值。
  *
- * 数组是给 `fallback.providers`（降级链是有序的一串 provider）——
- * **服务端不 join 成字符串**：分隔符是排版不是文字，两份 catalog 里未必一样，
- * 而拼一次就等于把一个界面决定钉死在网线上。
+ * 数组是给**有序的链**这种值留的形态（2.0.0 之前就是 `fallback.providers`，
+ * 随老写法删了；今天一个都没有）—— **服务端不 join 成字符串**：分隔符是排版
+ * 不是文字，两份 catalog 里未必一样，而拼一次就等于把一个界面决定钉死在网线上。
  *
  * ## `boolean` 从 2026-08-16 起真的会出现，2026-08-31 起还**写得进去**
  *
@@ -14601,8 +15024,9 @@ type WireSettingLayer = 'builtin' | 'user' | 'env' | 'project' | 'projectLocal'
 type WireSettingValue = string | number | boolean | readonly string[];
 /**
  * 写控件的形态。**只有三档，因为这条路只画得出「改一个标量」** ——
- * 数组不在里面（`fallback.providers` 是一条有序的链，不是一个输入框，
- * 判据在 core 的 `SETTING_WRITE_KEYS` 上）。
+ * 数组不在里面（「有序的链」要的是「加一项 / 删一项」，不是一个输入框；
+ * 2.0.0 之前那个例子是 `fallback.providers`。判据在 core 的
+ * `SETTING_WRITE_KEYS` 上）。
  *
  * 枚举也归 `string`，候选另走 {@link WireSettingRow.choices}：多一档
  * `'enum'` 的话，「是不是枚举」在载荷上就有了两个答案（那一档和那个数组），
@@ -14896,8 +15320,7 @@ interface WireSettingsWriteRequest {
      *
      * **服务端会按这个键自己的值域再校验一遍**（`maxTurns` 是正整数这类），
      * 界面那一侧的检查只是为了早说一句，不是判定。数组和对象一律拒 ——
-     * 可写的键**全是标量**，判据在 core 的 `SETTING_WRITE_KEYS` 上
-     * （`fallback.providers` 那条链因此没有铅笔）。
+     * 可写的键**全是标量**，判据在 core 的 `SETTING_WRITE_KEYS` 上。
      */
     value: WireSettingValue;
 }
@@ -15104,6 +15527,12 @@ interface WireModelSelection {
      * 按钮比没有按钮更坏）。
      */
     origin: ModelSelectionOrigin;
+    /**
+     * 落在「我的模型」里的哪一条。**2.0.0 起必有**（老写法删了，每个选择都是一条条目）。
+     * 输入框旁那张菜单靠它勾出当前那一条 —— 同一个模型名可以挂在两条不同的端点上，
+     * 按模型名勾会勾错
+     */
+    entry: string;
 }
 declare const WIRE_MODEL_SELECTION_FIELDS: WireFields<WireModelSelection>;
 /** `GET /api/sessions/:id/model` 的响应 */
@@ -15124,26 +15553,25 @@ interface WireModelResponse {
      */
     selection: WireModelSelection | null;
     /**
-     * 配置里那一个（`reset` 的目标），拼成 `provider/model` 或裸模型名。
+     * 配置里那一个（`reset` 的目标），`@<id>`；还没配主模型时是 null。
      *
      * 下发它是为了让「回到配置里那个」这一项**说得出自己要回到哪儿**。
      * 一个只写着「恢复默认」的菜单项，用户点之前不知道会得到什么。
      */
     configured: string | null;
+    /**
+     * 推理强度（2026-10-15）。缺席 = 这一侧没有这个动作（老服务端 / 嵌入宿主没接）；
+     * `levels` 为空 = 此刻那一条没声明档位，「选择强度」那张卡整个不画
+     */
+    effort?: ReasoningState;
 }
 declare const WIRE_MODEL_FIELDS: WireFields<WireModelResponse>;
 /**
  * `POST /api/sessions/:id/model` 的请求体。
  *
- * **`model` 是用户敲的那一串原文**，`provider/model` 和裸模型名都收 ——
- * 网线上走原文而不是拆好的 `{provider, model}`，是因为拆法有一条不显然的规矩
- * （模型名里本来就带斜杠，`meta-llama/Llama-3.3-70B-Instruct-Turbo` 是个裸模型名），
- * 而那条规矩的唯一真源是 {@link parseModelRef}。让浏览器先拆一遍再发，
- * 等于要求它也有一份同样的规矩 —— 那是第二份实现。
- *
- * 服务端收到之后**必须**过一次 `parseModelRef`（它就在 protocol，那一层够得着），
- * 因为 `ModelControl.set()` 收的是拆好的引用。不拆的后果是静默的：
- * 「换一家」做不到，而响应里一切正常。
+ * **`model` 是 `@<id>` 原文**（2.0.0 起只收这一种，裸模型名 / `provider/model` 回 400）。
+ * 服务端收到之后过一次 {@link parseModelRef}（它就在 protocol，那一层够得着），
+ * 因为 `ModelControl.set()` 收的是拆好的引用。
  */
 interface WireModelSetRequest {
     /**
@@ -15187,8 +15615,7 @@ declare const WIRE_MODEL_SET_FIELDS: WireFields<WireModelSetRequest>;
  */
 type WireModelRejection = {
     code: 'no-credential';
-    provider: ProviderType;
-    envVar: string | null;
+    entry: string;
 } | {
     code: 'images-unsupported';
     model: string;
@@ -15197,6 +15624,9 @@ type WireModelRejection = {
     model: string;
     usedTokens: number;
     contextLength: number;
+} | {
+    code: 'unknown-entry';
+    entry: string;
 };
 /** 换成了、但有代价 —— 和 protocol 的 {@link SelectionWarning} 逐字同形，理由同上 */
 type WireModelCaveat = {
@@ -15231,259 +15661,135 @@ type WireModelSetResponse = {
      * 判据在 protocol 的 {@link SelectionWarning} 上。
      */
     caveats: readonly WireModelCaveat[];
+    /** 换完之后的推理强度（档位跟着那一条走，换了就是另一组）。语义同 `WireModelResponse.effort` */
+    effort?: ReasoningState;
 } | {
     ok: false;
     rejection: WireModelRejection;
 };
+/** `POST /api/sessions/:id/model/effort` —— 选一档。`null` = 回到条目的默认档 */
+interface WireModelEffortRequest {
+    effort: ReasoningChoice | null;
+}
+/** `ok: false` = 那一档不在这一条声明的档位里（或者它不许关），什么都没动 */
+interface WireModelEffortResponse {
+    ok: boolean;
+    effort: ReasoningState;
+}
 
-/**
- * 一个可挑的 provider。**这一层是闭合的**，逐字来自 `PROVIDER_INFOS`。
- *
- * ⚠️ 别在任何下游再抄一份这张表。`config.ts` 的文件头逐字记着那个病：
- * 「之前这份列表在 cli/src/index.ts 里被复制了三遍，加一个 provider 要改四处，
- * 漏一处就是『支持但选不到』」。这一份契约是那张表的**投影**，不是第二份。
- */
-interface WireProviderOption {
+/** 供应商下拉的分组。顺序就是菜单里的顺序 */
+declare const WIRE_PROVIDER_GROUPS: readonly ["domestic", "global", "local", "custom"];
+type WireProviderGroup = (typeof WIRE_PROVIDER_GROUPS)[number];
+/** 弹窗里那张供应商菜单的一行 */
+interface WireEntryProvider {
     type: ProviderType;
-    /** 展示名，来自 `ProviderInfo.label` */
+    /** 显示名，按请求的语言渲染（中文界面是「深度求索 DeepSeek」这种） */
     label: string;
-    /**
-     * API key 的环境变量名。**不需要 key 的（本地 Ollama）是 null** ——
-     * 界面据此决定「先配一把 key」那一档要不要说得出变量名，
-     * 判据同 `WireModelRejection` 的 `no-credential` 那一档。
-     */
-    envVar: string | null;
-    /**
-     * 这台机器上这把 key 配好了没有。
-     *
-     * **由服务端答，不让浏览器猜**：判定走的是引擎读 key 的那同一份
-     * （`readProviderKeyEnv()`：process.env > `.env` > 钥匙串），而后两处
-     * 浏览器一个字都看不见。`cli/src/commands/model.ts` 的文件头记着这一格答错
-     * 的后果 —— 「回车沿用旧 key」被当成没有 key，于是模型列表**完全不对**。
-     *
-     * `envVar` 为 null 的那家这里恒是 `true`：它不需要 key，
-     * 而「没配 key」这句话对它是假的。
-     */
+    group: WireProviderGroup;
+    /** 这家的官方地址，弹窗里「接口地址」的占位符。自定义端点没有，是 null */
+    defaultBaseUrl: string | null;
+    /** 这家要不要 key。Ollama 不要 */
+    needsKey: boolean;
+}
+/** 列表里的一条：条目本身 + key 的状态 */
+interface WireModelEntry extends ModelEntry {
+    /** 这一条此刻有没有可用的 key（自己的，或者没填地址时继承那家的） */
     hasKey: boolean;
-    /**
-     * 这台机器上那把 key 长什么样 —— **已脱敏**（`maskApiKey`），没配 / 不需要时是 `null`。
-     *
-     * ⚠️ **这一格是「已配置」的可核对形态，不是凭据。** 只有 `hasKey: true` 的话，
-     * 用户在设置页看到的是一个空的密码框加一句「已配置」—— 而他此刻真正想知道的是
-     * **哪一把**（换了机器、翻过 profile、上周贴过两次），而那个问题
-     * 一个布尔答不了。走的是 `WireProviderSummary.apiKeyHint`（TUI 的 `/model` 印的那份）
-     * 同一个函数，先例在那儿。
-     *
-     * ⚠️ 而它**不许放宽成裸 key**：[§6.4 的第一条「绝不」](../../../docs/verify/VERIFY_RECORD-20-web.md)
-     * 是「API key 下发到浏览器」—— devtools 直接就能读。脱敏在**服务端**做，
-     * 不是发全的让浏览器自己截（那样 key 已经过了网线）。
-     */
+    /** 脱敏后的 key。没有就是 null */
     keyHint: string | null;
-    /**
-     * **这台机器此刻配的就是这一家**（2026-09-11）。这张单子里最多一家是 `true`。
-     *
-     * ## 加它是为了让选择器「一展示就有清单」
-     *
-     * 改造前浏览器这一侧 `provider` 的初值是 `undefined`，于是打开顶栏那张菜单
-     * 看到的是一句「挑一家」和一个空的模型下拉 —— 用户必须先在 provider 那一格
-     * 上手动选中他**本来就在用的那一家**，才会发出第一发探测。多一步、而且那一步
-     * 的信息量是零（答案只有一个）。
-     *
-     * 有了这一格，`useModelCatalog` 在 provider 单子回来的那一刻就能自动探它。
-     *
-     * ## ⚠️ 为什么不让浏览器自己去比对
-     *
-     * 浏览器手上确实有一个「此刻的模型」（`GET /api/config` 的
-     * `WireProviderSummary`，以及会话那一份 `WireModelSelection`），拿它去和这张
-     * 单子对一遍也能得出同样的结论 —— **但那是在下游重建一份判断**。
-     * `config.ts` 的文件头逐字记着这个病（「被复制了三遍，加一个 provider 要改
-     * 四处」）。服务端本来就知道答案（`ModelCatalogOptions.configured`），
-     * 让它直接说出来。
-     *
-     * ## ⚠️ 它**不是**「选中态」
-     *
-     * 说的是「配置里写的是这一家」。用户在菜单里点到别家之后，界面的选中态跟着
-     * 走，而这一格纹丝不动 —— 它到下一次 `GET /api/providers` 之前都不会变。
-     * 拿它当受控组件的 `value` 会得到一个点不动的下拉。
-     */
-    current: boolean;
-}
-declare const WIRE_PROVIDER_OPTION_FIELDS: WireFields<WireProviderOption>;
-/** `GET /api/providers` 的响应 */
-interface WireProvidersResponse {
-    /**
-     * 可挑的那几家，顺序就是 `PROVIDER_INFOS` 的顺序。
-     *
-     * ⚠️ **只含 `interactive: true` 的那些**（bedrock / azure 不在里面）：
-     * 那两家不是单 key 认证，挑中了也配不起来，走配置文件。这个过滤条件
-     * **也来自那张表本身**（`ProviderInfo.interactive`），不是在下游另立的名单。
-     */
-    providers: readonly WireProviderOption[];
+    /** key 是条目自己的（true），还是继承那家 provider 的（false）。没 key 时 false */
+    ownKey: boolean;
 }
-declare const WIRE_PROVIDERS_FIELDS: WireFields<WireProvidersResponse>;
-/**
- * 这份清单是哪儿来的 —— 和 core 的 `DiscoverResult.source` 逐字同形。
- *
- * 下发它不是为了展示来源，是为了让「探不到」那几句话说得出**你现在看到的是什么**：
- * `cache` 是上次探到的、`static` 是内置的（可能已经过期）。
- * 少了这一格，那句话只能说「探测失败」，而用户面前明明列着一串模型名。
- */
-type WireModelSource = 'live' | 'cache' | 'static';
-/**
- * 探这一家的结果落在哪一档。**四档各说各的，一句都不许合并成「没有可用模型」**
- * —— 这条规矩这一屏已经有先例（`model-menu.tsx` 的「三种拒绝各说各的」）。
- *
- * 判据是**下一步动作不同**：
- *
- * | 档            | 用户下一步                                        |
- * | ------------- | ------------------------------------------------- |
- * | `ok`          | 挑一个，或者照旧手敲                              |
- * | `no-key`      | 去配一把 key（`epoch model`，或设那个环境变量）   |
- * | `probe-failed`| 查网络 / key 对不对 / 那个 base URL 有没有 `/models` |
- * | `empty`       | 没得挑，**手敲**（这一家没给出任何名字）          |
- *
- * ⚠️ 还有第五档「**还在探**」，它**刻意不在这个联合里**：那是「这一发请求
- * 在飞」，是浏览器自己的状态，服务端答不出来也不该答。它长在界面那一侧，
- * 判据在 `shell/model-catalog.ts` 上。
- *
- * ## ⚠️ 优先级是定死的，因为 `discoverModels()` **从不失败**
- *
- * core 那个函数是三层回退（live → 缓存 → 内置静态目录），**任何情形下都回一个
- * 结果**，没有异常、没有 null。所以这四档不是「catch 到了什么」，是**推出来的**，
- * 而推的顺序必须写死（判据在 runtime 的 `ModelCatalogControl.discover` 上）：
- *
- * 1. `no-key` —— 这家要 key 而这台机器上没有。**排最前**：它是根因，
- *    也是唯一一个用户当场能动手的。这时候说「这个 provider 没有模型」是假话
- * 2. `empty` —— 最后手上一个名字都没有。这时候没有清单可画，只有手敲
- * 3. `probe-failed` —— 有名字可画，但**不是**这一发探回来的（`source` 说是哪来的）
- * 4. `ok` —— live 且非空
- */
-type WireModelProbeStatus = 'ok' | 'no-key' | 'probe-failed' | 'empty';
-/**
- * 探一家的结果。
- *
- * ⚠️ **`models` 是建议不是全集**，判据见文件头那张表。契约上没有任何东西
- * 允许消费方把它当值域用 —— 真要拦的话该在这儿写一个 `enum`，而我们**不写**。
- */
-interface WireModelSuggestions {
-    /** 探的是哪一家。回声一遍是为了让界面认得出「这份结果是不是我刚才点的那个」 */
-    provider: ProviderType;
-    /** 探回来的模型名。**可能是空数组**，那是 `empty` 那一档 */
-    models: readonly string[];
-    source: WireModelSource;
-    status: WireModelProbeStatus;
+/** 主模型 / 副模型 / 降级模型此刻各指向哪一条（条目 id），没指向条目就是 null */
+interface WireModelEntryRefs {
+    model: string | null;
+    utility: string | null;
+    fallback: string | null;
 }
-declare const WIRE_MODEL_SUGGESTIONS_FIELDS: WireFields<WireModelSuggestions>;
 /**
- * `POST /api/providers/:type/models` 的请求体。
- *
- * ## 为什么是 POST 而不是 GET
- *
- * 这一下**有两处真实的副作用**，不是一次纯读：
- *
- * 1. 它发一个真的网络请求到 provider 的 `/models`，**带着用户那把 key**；
- * 2. 它把结果**写进磁盘缓存**（core 的 `saveCache()`）。
- *
- * 写成 GET 的话，`auth.ts` 那道 Origin 校验不查安全方法 —— 于是任何一个页面都能
- * 让这台机器替它去 provider 那儿发请求。判据同 plan / rewind / settings /
- * `POST .../model` 那几条。
- *
- * ⚠️ **没有 `WIRE_*_FIELDS` 清单**：这份载荷一个必填字段都没有，
- * `wireFields` 会产出一个空数组，而一个空清单在 `conformsToWire()` 里
- * 对任何对象都成立 —— 那不是一道校验，是一句看着像校验的空话。
+ * 一个槽位此刻**实际**落在哪一条条目。2.0.0 之前还有「供应商 + 裸模型名」那一支
+ * （老写法 / 内置降级表），随老写法一起删了。
  */
-interface WireProviderModelsRequest {
-    /**
-     * 绕开磁盘缓存重新探一次。不给 = 照常走三层回退。
-     *
-     * 这一格**必须有**，因为探测结果是**落盘缓存**的（24 小时）：用户换了 key、
-     * 或者 provider 上了新模型，没有这一下他看到的永远是缓存那一份，
-     * 而界面上没有任何东西说得出「你看的是旧的」。
-     * CLI 那边同一个东西叫 `epoch model --refresh`。
-     */
-    refresh?: boolean;
+interface WireEffectiveModel {
+    entry: string;
 }
-/** `POST /api/providers/:type/models` 的响应 */
-interface WireProviderModelsResponse {
-    suggestions: WireModelSuggestions;
-}
-declare const WIRE_PROVIDER_MODELS_FIELDS: WireFields<WireProviderModelsResponse>;
 /**
- * `POST /api/providers/:type/key` 的请求体 —— **在这台机器上配一把 key**（2026-08-31）。
- *
- * ## 为什么 Web UI 上需要它
- *
- * 在这条端点之前，浏览器上「没配 key」这一档能说的只有一句
- * 「设一个 `MOONSHOT_API_KEY`，或者跑 `epoch model`」—— 也就是**把用户赶回终端**。
- * 而 `epoch web` 的整个前提是那台机器就在用户手上（回环 + 一次性 token，
- * 见 `auth.ts` 的文件头），所以「替他把 key 写进他自己的钥匙串」不是越权，
- * 是这一屏本来就欠的那一步。
- *
- * ## ⚠️ 这一发是**单向**的：key 上得去，下不来
+ * 副模型 / 降级模型此刻**实际生效**的是什么（2026-10-15）。设置页那两格照它画：
+ * 用户原话「实际生效的是什么就展示什么，不要展示『跟随主模型』『不指定（…）』这种」。
  *
- * 请求体里有裸 key，响应体里**没有**（只有 {@link WireProviderKeyResponse.keyHint}
- * 那份脱敏串）。§6.4 第一条「绝不」管的是**下行**，这一条一个字都没松。
- *
- * ## 落点由服务端决定，不由请求说
- *
- * 请求体里**没有**「写进钥匙串还是写进 .env」这样的字段：那是
- * `SecretStore` 的降级链（钥匙串 → DPAPI → libsecret → 明文 0600）自己的事，
- * 而它的判据（「降级必须响亮」，方案 3.3）在 infra。让浏览器点一个后端，
- * 等于把那条链抄成了第二份，还允许用户主动挑一个更不安全的。
- * 实际落到哪儿由响应回声，见 {@link WireProviderKeyResponse.backend}。
+ * 不能直接拿 {@link WireModelEntryRefs} 画：副模型没配时实际用的是主模型，`refs.utility` 是 null。
+ * 算法在 runtime 的 `effectiveOf()`，逐条对着 core 的路由。
  */
-interface WireProviderKeyRequest {
-    /**
-     * 那把 key 的原文。**必填、且不许是空串**。
-     *
-     * ⚠️ 空串**不当成「删掉这把 key」**，回 400。这一屏上「清空输入框再按保存」和
-     * 「我要撤销这把 key」长得一模一样，而它们的后果差很远 —— 真要删的那天单开一个
-     * 说得出自己在删的动作（`DELETE`），别让一个保存按钮兼职。
-     */
-    apiKey: string;
+interface WireEffectiveSlots {
+    /** 副模型。没配就是主模型；主模型也没配（还没有模型）时是 null */
+    utility: WireEffectiveModel | null;
+    /** 主模型出错时降到哪儿。`null` = 不降级 */
+    fallback: WireEffectiveModel | null;
 }
-/**
- * `POST /api/providers/:type/key` 的响应 —— **写在哪儿、加没加密**。
- *
- * ⚠️ **这里一个中文字都不发**，判据逐字同这一组另外两条（`providers.ts` 文件头第 4 节）：
- * `SecretStore.detail` 是一句现成的中文，照抄过来能省浏览器一份 catalog ——
- * 但那句话是按**服务进程的 locale** 渲染的，而一台 `epoch web` 后面可能同时坐着
- * 两种语言的人（方案 58）。所以下发的是 {@link backend} 这个**码**，措辞在浏览器那侧。
- */
-interface WireProviderKeyResponse {
-    /** 配的是哪一家。回声一遍，同 `WireModelSuggestions.provider` */
-    provider: ProviderType;
+interface WireModelEntriesResponse {
+    entries: WireModelEntry[];
     /**
-     * 写完之后这家配好了没有。
-     *
-     * **恒 `true`**，而它照旧下发：这一格是浏览器那张 provider 单子里同名字段的
-     * 新值（那张单子取一次就不再取，见 `web/src/model/catalog.ts` 的 `asked`），
-     * 让调用方去推「写成功 = 现在有了」，就是把服务端的结论在下游重算一遍。
+     * 宿主预置那一组的显示名（`hostPreset.label`，2026-10-15）。有宿主条目（`host: true`）才有；
+     * 界面上这一组收成一行、下拉里一个分组，标题就是这个名字。没给宿主就叫「宿主」（web 兜底）
      */
-    hasKey: boolean;
-    /** 脱敏后的那把 key（`maskApiKey`）。同 {@link WireProviderOption.keyHint}，**不是原文** */
-    keyHint: string;
+    hostLabel?: string;
     /**
-     * 真的落到哪个后端了 —— `keychain` / `dpapi` / `libsecret` / `plaintext`。
-     *
-     * ⚠️ **必须回显**：方案 3.3「降级必须响亮」在写入侧的对应物就是这一格
-     * （`cli/src/files/env-file.ts` 的 `writeProviderKey` 文件头逐字写着
-     * 「我的 key 进了钥匙串还是明文文件，是用户有权当场知道的事」）。
-     * 值域刻意是 `string` 而不是一个联合：后端清单是 infra 那一侧的事，
-     * 在契约里再钉一张表就是第二份名单。
+     * `models.json` 的绝对路径。⚠️ **网页这边今天没有读者** —— 设置页那一屏原来把它印在标题
+     * 底下那行提示里，2026-10-15 用户拍了撤掉（判据在 web 的 `settings/model-entries.tsx`
+     * 文件头）。字段留着是「路径是这条接口的一部分」，不是「有个界面在用它」
      */
-    backend: string;
-    /** 这个后端加密不加密。`plaintext` 那一档是 false，界面据此把那句话说重一点 */
-    encrypted: boolean;
-    /**
-     * 明文降级时那个文件在哪儿；没降级就是 `null`。
-     *
-     * 只有这一档给路径，是因为只有这一档用户**有下一步可做**（去 `chmod`、
-     * 去把它加进 `.gitignore`、或者干脆去修钥匙串）。钥匙串那一档给路径没有意义。
-     */
-    envPath: string | null;
+    path: string;
+    refs: WireModelEntryRefs;
+    effective: WireEffectiveSlots;
+    providers: WireEntryProvider[];
+    /** `models.json` 里被丢掉的条目（坏 JSON / 校验不过 / id 重复），原话 */
+    issues: string[];
+}
+declare const WIRE_MODEL_ENTRIES_FIELDS: WireFields<WireModelEntriesResponse>;
+interface WireModelEntrySaveRequest {
+    entry: ModelEntry;
+    /**
+     * 新填的 key。**不给 = 不动原来那把**（编辑时用户没碰 key 那一格）；
+     * 给空串 = 删掉条目自己的 key（退回继承那家的）
+     */
+    apiKey?: string;
+}
+interface WireModelEntrySaveResponse {
+    entry: WireModelEntry;
+    /** 存完之后整张表，界面直接拿它重画 */
+    list: WireModelEntriesResponse;
+}
+declare const WIRE_MODEL_ENTRY_SAVE_FIELDS: WireFields<WireModelEntrySaveResponse>;
+/**
+ * 测试连接 / 列模型的请求。`entry` 是弹窗里**还没保存的草稿**。
+ * `apiKey` 不给时用这个 id 已经存着的那把（编辑一条已有的、没改 key 的时候）。
+ */
+interface WireModelEntryProbeRequest {
+    entry: ModelEntry;
+    apiKey?: string;
+}
+/** 测试连接的结论。码的含义见 core 的 `EntryProbeCode` */
+/** 逐字同 core 的 `EntryProbeCode`（每一档的含义写在那边） */
+type WireEntryProbeCode = 'ok' | 'auth' | 'model-not-found' | 'network' | 'error' | 'need-model' | 'invalid';
+interface WireModelEntryTestResponse {
+    code: WireEntryProbeCode;
+    models: string[];
+    httpStatus?: number;
+    latencyMs: number;
+    /** 端点的原话（已脱敏）。只在不是 ok 时给 */
+    detail?: string;
+}
+declare const WIRE_MODEL_ENTRY_TEST_FIELDS: WireFields<WireModelEntryTestResponse>;
+/** 主 / 副 / 降级那一格改指向哪一条。`id: null` = 「跟随主模型」，主模型那一格不收 null */
+interface WireModelEntryRefRequest {
+    slot: keyof WireModelEntryRefs;
+    id: string | null;
+}
+interface WireModelEntryModelsResponse {
+    /** **建议不是全集**，同 `WireModelSuggestions.models` */
+    models: string[];
 }
-declare const WIRE_PROVIDER_KEY_FIELDS: WireFields<WireProviderKeyResponse>;
+declare const WIRE_MODEL_ENTRY_MODELS_FIELDS: WireFields<WireModelEntryModelsResponse>;
 
 /**
  * 「不看参数」这一问的答案。**四档，`depends` 是其中一个真答案**（见文件头）。
@@ -16957,4 +17263,4 @@ declare const SECRET_SERVICE = "epoch-agent";
  */
 declare const MCP_DATA_KEY_NAME = "mcp-auth-data-key";
 
-export { ACTION_CONTEXTS, AGENT_ROLE_NAME_PATTERN, API_KEY_ENV_VARS, APPEARANCE_LANGS, APPEARANCE_SIDEBAR_WIDTH, APPEARANCE_THEMES, APPROVAL_OUTCOMES, type ActiveAgentRole, type AgentEvent, type AgentEventOf, type AgentEventType, type AgentRole, type AgentRoleScope, type AgentRoleSource, type AppearanceLang, type AppearanceTheme, type ApprovalAnswer, type ApprovalOutcome, type ApprovalReply, type ApprovalRequest, type ApprovalScope, type ArtifactKind, type AttributeValue, type Attributes, BRAND_WHEN_SIDEBAR_COLLAPSED, type BackgroundTaskInfo, type BackgroundTaskKind, type BackgroundTaskStatus, type BlankCard, type BlankGreeting, type BoundKey, type BrandWhenSidebarCollapsed, type BudgetBreach, COMMAND_NAME_PATTERN, COMPLIANCE_ACTIONS, COMPLIANCE_CATEGORIES, CURRENCIES, type Catalogs, type ComplianceAction, type ComplianceCategory, type ContextBreakdown, type ContextNote, type ContextSegment, type ContextSegmentKind, type Currency, type CurrencyDisplay, type CustomCommandDef, type CustomCommandSource, DEFAULT_AGENT_ROLE, DEFAULT_LANG, type DecidedTrustLevel, type Diagnostic, DiagnosticSink, type DiagnosticStatus, type EpochConfig, type EpochContentPart, type EpochFilePart, type EpochHook, type EpochImagePart, type EpochMessage, type EpochMessageRole, type EpochPlugin, type EpochSessionPart, type EpochSkill, type EpochTextPart, type EpochTool, type EpochToolCall, type EpochToolResult, type EpochTurnFacts, type EpochUserContent, type ExpandedCommand, FOLLOW_SYSTEM, type FileOmitReason, type FinishReason, type FixableApproval, type FlatCatalog, type FormatMoneyOptions, GEN_AI, HEADLESS_INPUT_EVENT_TYPES, HEADLESS_INPUT_FORMATS, HEADLESS_OUTPUT_FORMATS, HEADLESS_PROTOCOL_VERSION, type HeadlessEnvelope, type HeadlessEvent, type HeadlessInit, type HeadlessInputEvent, type HeadlessInputEventType, type HeadlessInputFormat, type HeadlessLifecycleEvent, type HeadlessOutputFormat, type HeadlessResult, type HeadlessResultReason, type HookContext, type HookEvent, type HookHandler, type HookManager, type HookRegistration, type HookType, type HostText, type HostUser, type JsonSchema, KEY_ACTIONS, type KeyAction, type KeyChord, type KeyContext, type KeySequence, type KeybindingReport, type KeybindingSource, type KeybindingTable, LANGS, type Lang, type LocalizedDetail, type LogFn, MAX_ATTACH_BYTES, MAX_ATTACH_FILES, MAX_ATTACH_TOTAL_BYTES, MAX_HEADER_CHARS, MAX_OPTIONS, MAX_QUESTIONS, MAX_SESSION_ATTACH_BYTES, MAX_SESSION_REFS, MCP_DATA_KEY_NAME, METRIC, MIN_OPTIONS, type MentionSet, type ModelRef, type ModelSelection, type ModelSelectionOrigin, type MoneyDigits, NOOP_TELEMETRY, type NoticeCode, OPERATION_TYPES, OVERSIZE_RATIO, type Operation, type OperationType, PERMISSION_LEVELS, PLAN_OUTCOMES, PLUGIN_CATEGORY_DISPLAY_SEP, PLUGIN_MENU_MESSAGE_TYPE, PLUGIN_PREVIEW_STREAM_MIME, PLUGIN_UPLOAD_MULTI_SEP, PROVIDER_INFOS, PROVIDER_TYPES, type PermissionDecision, type PermissionLevel, type PermissionManager, type PermissionRuleLists, type PlanApprovalOutcome, type PlanProposal, type PluginContext, type PluginMenuMessage, type ProviderInfo, type ProviderType, type QuestionAnswer, type QuestionItem, type QuestionOption, type QuestionPage, type QuestionRequest, RESERVED_CHORDS, RESERVED_COMMAND_NAMES, type RejectReason, type RejectedKey, type RuleValue, SCHEDULE_DRAFT_TOOL, SCHEDULE_INTERVAL_MAX_MINUTES, SCHEDULE_INTERVAL_MIN_MINUTES, SCHEDULE_MAX_TIMES_PER_DAY, SCHEDULE_RUN_STATUSES, SEARCH_API_KEY_ENV, SEARCH_PROVIDER_TYPES, SECRET_SERVICE, SEQUENCE_CONTEXTS, SESSION_MENTION_PREFIX, SESSION_REFERENCE_ERROR_CODES, SETTINGS_PANE_IDS, SHELL_KINDS, SIDEBAR_MENU_MESSAGE_TYPE, SIMULTANEOUS_CONTEXTS, SYSTEM_NOTE_PREFIX, type ScheduleAllowlist, type ScheduleBackendKind, type ScheduleCronTrigger, type ScheduleCycle, type ScheduleDefinition, type ScheduleDraft, type ScheduleDraftAllowlist, type ScheduleDraftCreate, type ScheduleDraftPermission, type ScheduleDraftUpdate, type SchedulePendingApproval, type SchedulePendingItem, type ScheduleRun, type ScheduleRunStatus, type ScheduleRunnerSpec, type ScheduleTrigger, type ScheduleTriggerKind, type ScheduleWeekday, type ScheduleWideningKind, type SearchProviderType, type SecretBackendId, type SecretStore, type SelectionContext, type SelectionRejection, type SelectionWarning, type SessionAttachKind, type SessionAttachResult, type SessionOmitReason, type SessionSurfaceMessage, type SessionSurfaceView, type SetSelectionResult, type SettingsPaneId, type SettingsPaneItem, type ShellKind, type SidebarMenuItem, type SidebarMenuMessage, type SidebarNavItem, type SpanLike, type SubToolCall, type SubToolCallResult, type Telemetry, type TokenUsage, type ToolAnnotations, type ToolArtifact, type ToolArtifactInput, type ToolContext, type ToolDefinition, ToolExposure, type ToolProvider, type ToolResult, type Translate, type TranslateVars, type TrustExecGrant, type TrustGrant, type TrustLevel, type TrustManager, type TrustRecord, type TrustScope, type TrustTier, UNLIMITED_TURNS, type VerifyResult, WIRE_ABORT_FIELDS, WIRE_ABOUT_FIELDS, WIRE_AGENT_ROLE_FIELDS, WIRE_APPEARANCE_RESPONSE_FIELDS, WIRE_APPROVAL_CACHE_REVOKE_REQUEST_FIELDS, WIRE_APPROVAL_CACHE_REVOKE_RESPONSE_FIELDS, WIRE_APPROVAL_LIST_FIELDS, WIRE_APPROVAL_ROW_FIELDS, WIRE_ARTIFACTS_FIELDS, WIRE_ATTACHMENT_UPLOAD_FIELDS, WIRE_AUDIT_LOG_FIELDS, WIRE_AUDIT_ROW_FIELDS, WIRE_AUTH_COOKIE, WIRE_AUTH_COOKIE_ATTRS, WIRE_AUTH_TOKEN_PARAM, WIRE_BACKGROUND_TASK_FIELDS, WIRE_BLOCKED_GOALS_FIELDS, WIRE_BLOCKED_GOAL_FIELDS, WIRE_BLOCKED_LEVEL_FIELDS, WIRE_BUILTIN_CONNECTOR_FIELDS, WIRE_CACHED_APPROVAL_FIELDS, WIRE_CAPABILITIES_FIELDS, WIRE_CAPABILITY_PROJECT_FIELDS, WIRE_CHECKPOINT_LIST_FIELDS, WIRE_CHECKPOINT_SUMMARY_FIELDS, WIRE_COMMANDS_FIELDS, WIRE_COMMAND_EXPANSION_FIELDS, WIRE_COMPACT_FIELDS, WIRE_COMPRESSION_LINE_FIELDS, WIRE_CONFIG_FIELDS, WIRE_CONTEXT_FIELDS, WIRE_CREATE_SESSION_FIELDS, WIRE_CREATE_WORKSPACE_FIELDS, WIRE_CREATE_WORKSPACE_RESPONSE_FIELDS, WIRE_CUSTOM_COMMAND_FIELDS, WIRE_DELETE_SESSION_FIELDS, WIRE_DIFF_FILE_FIELDS, WIRE_ERROR_FIELDS, WIRE_FILE_CANDIDATES_FIELDS, WIRE_FILE_CANDIDATE_FIELDS, WIRE_FILE_CHANGE_FIELDS, WIRE_FILE_OPEN_RESPONSE_FIELDS, WIRE_FILE_REFERENCE_FIELDS, WIRE_FILE_STAT_MAX, WIRE_FILE_STAT_OK_FIELDS, WIRE_FILE_STAT_REFUSED_FIELDS, WIRE_FILE_STAT_RESPONSE_FIELDS, WIRE_FILE_TEXT_RESPONSE_FIELDS, WIRE_FORGET_WORKSPACE_FIELDS, WIRE_FORGET_WORKSPACE_RESPONSE_FIELDS, WIRE_GOAL_ACTIONS, WIRE_GOAL_BLOCK_FIELDS, WIRE_GOAL_CLEAR_FIELDS, WIRE_GOAL_CREATE_FIELDS, WIRE_GOAL_FIELDS, WIRE_GOAL_LIMITS_FIELDS, WIRE_GOAL_PHASES, WIRE_GOAL_REFUSALS, WIRE_GOAL_RESPONSE_FIELDS, WIRE_GOAL_WRITE_FIELDS, WIRE_HEALTH_FIELDS, WIRE_IMAGE_REFERENCE_FIELDS, WIRE_KNOWN_WORKSPACE_FIELDS, WIRE_LANG_PARAM, WIRE_LAST_SESSION_FIELDS, WIRE_LAST_SESSION_RESPONSE_FIELDS, WIRE_MANAGED_LOCK_FIELDS, WIRE_MCP_ADD_FIELDS, WIRE_MCP_ADD_RESPONSE_FIELDS, WIRE_MCP_APPLY_ENTRY_FIELDS, WIRE_MCP_APPLY_RESPONSE_FIELDS, WIRE_MCP_CONFIG_APPLY_FIELDS, WIRE_MCP_CONFIG_FIELDS, WIRE_MCP_CONFIG_ISSUE_FIELDS, WIRE_MCP_CONFIG_SAVE_FIELDS, WIRE_MCP_CONFIG_SAVE_RESPONSE_FIELDS, WIRE_MCP_CONNECTOR_FIELDS, WIRE_MCP_RECONNECT_FIELDS, WIRE_MESSAGE_LIST_FIELDS, WIRE_MODEL_FIELDS, WIRE_MODEL_SELECTION_FIELDS, WIRE_MODEL_SET_FIELDS, WIRE_MODEL_SUGGESTIONS_FIELDS, WIRE_PATCH_SESSION_FIELDS, WIRE_PATCH_SESSION_RESPONSE_FIELDS, WIRE_PERMISSION_RULE_FIELDS, WIRE_PERMISSION_SET_REQUEST_FIELDS, WIRE_PERMISSION_SET_RESPONSE_FIELDS, WIRE_PERMISSION_SHADOW_FIELDS, WIRE_PERMISSION_STATE_FIELDS, WIRE_PERMISSION_STATUS_FIELDS, WIRE_PLAN_ACTIONS, WIRE_PLAN_FIELDS, WIRE_PLAN_MODE_REQUEST_FIELDS, WIRE_PLAN_MODE_RESPONSE_FIELDS, WIRE_PLAN_MODE_STATE_FIELDS, WIRE_PLUGINS_FIELDS, WIRE_PLUGIN_ACTION_FIELDS, WIRE_PLUGIN_ARCHIVE_SUFFIXES, WIRE_PLUGIN_INSTALL_FIELDS, WIRE_PLUGIN_LOCAL_FIELDS, WIRE_PLUGIN_LOCAL_INSTALL_FIELDS, WIRE_PLUGIN_MARKETPLACE_FIELDS, WIRE_PLUGIN_MARKETPLACE_RESPONSE_FIELDS, WIRE_PLUGIN_NAME_FIELDS, WIRE_PLUGIN_PREVIEW_FIELDS, WIRE_PLUGIN_PREVIEW_RESPONSE_FIELDS, WIRE_PLUGIN_REFRESH_RESPONSE_FIELDS, WIRE_PLUGIN_STAGE_FIELDS, WIRE_PLUGIN_STAGE_RESPONSE_FIELDS, WIRE_PLUGIN_UPDATE_FIELDS, WIRE_PLUGIN_UPLOAD_CONFIRM_FIELDS, WIRE_PLUGIN_UPLOAD_FIELDS, WIRE_PLUGIN_UPLOAD_FORM_FIELDS, WIRE_PLUGIN_UPLOAD_PREVIEW_RESPONSE_FIELDS, WIRE_PLUGIN_UPLOAD_RESPONSE_FIELDS, WIRE_POLICY_DIR_FIELDS, WIRE_POLICY_STATUS_FIELDS, WIRE_PROJECT_INVENTORY_FIELDS, WIRE_PROVIDERS_FIELDS, WIRE_PROVIDER_KEY_FIELDS, WIRE_PROVIDER_MODELS_FIELDS, WIRE_PROVIDER_OPTION_FIELDS, WIRE_QUESTION_LIST_FIELDS, WIRE_QUESTION_ROW_FIELDS, WIRE_RESPOND_APPROVAL_FIELDS, WIRE_RESPOND_APPROVAL_RESPONSE_FIELDS, WIRE_RESPOND_QUESTION_FIELDS, WIRE_RESPOND_QUESTION_RESPONSE_FIELDS, WIRE_REWIND_FILE_PLAN_FIELDS, WIRE_REWIND_OUTCOME_FIELDS, WIRE_REWIND_PREVIEW_FIELDS, WIRE_REWIND_REQUEST_FIELDS, WIRE_REWIND_RESPONSE_FIELDS, WIRE_REWIND_SCOPES, WIRE_ROLES_FIELDS, WIRE_ROLE_ADD_FIELDS, WIRE_ROLE_ADD_RESPONSE_FIELDS, WIRE_ROLE_REMOVE_FIELDS, WIRE_RUNNING_SCHEDULE_FIELDS, WIRE_SANDBOX_STATUS_FIELDS, WIRE_SCHEDULE_CAPABILITY_FIELDS, WIRE_SCHEDULE_CREATE_FIELDS, WIRE_SCHEDULE_DEFAULTS_FIELDS, WIRE_SCHEDULE_DELETE_FIELDS, WIRE_SCHEDULE_FIELDS, WIRE_SCHEDULE_FIX_FIELDS, WIRE_SCHEDULE_FIX_REQUEST_FIELDS, WIRE_SCHEDULE_ISSUE_CODES, WIRE_SCHEDULE_LIST_FIELDS, WIRE_SCHEDULE_PENDING_FIELDS, WIRE_SCHEDULE_RECORDING_FIELDS, WIRE_SCHEDULE_ROW_FIELDS, WIRE_SCHEDULE_RUNNING_FIELDS, WIRE_SCHEDULE_RUNS_FIELDS, WIRE_SCHEDULE_RUN_FIELDS, WIRE_SCHEDULE_SAVE_FIELDS, WIRE_SECURITY_FIELDS, WIRE_SECURITY_WORKSPACE_FIELDS, WIRE_SEND_MESSAGE_FIELDS, WIRE_SEND_MESSAGE_RESPONSE_FIELDS, WIRE_SESSION_CANDIDATES_FIELDS, WIRE_SESSION_CANDIDATE_FIELDS, WIRE_SESSION_FINISH_FIELDS, WIRE_SESSION_LIST_FIELDS, WIRE_SESSION_REFERENCE_FIELDS, WIRE_SESSION_RESPONSE_FIELDS, WIRE_SESSION_SUMMARY_FIELDS, WIRE_SESSION_WORKSPACE_FIELDS, WIRE_SESSION_WORKSPACE_RESPONSE_FIELDS, WIRE_SETTINGS_FIELDS, WIRE_SETTINGS_WRITE_FIELDS, WIRE_SETTINGS_WRITE_REQUEST_FIELDS, WIRE_SETTING_PENDING_FIELDS, WIRE_SETTING_ROW_FIELDS, WIRE_SETTING_STEP_FIELDS, WIRE_SETTING_WRITE_FIELDS, WIRE_SETTING_WRITE_LAYERS, WIRE_SKILL_BODY_FIELDS, WIRE_SKILL_DROP_SUFFIXES, WIRE_SKILL_FIELDS, WIRE_SKILL_IMPORT_FIELDS, WIRE_SKILL_IMPORT_PREVIEW_FIELDS, WIRE_SKILL_REMOVE_FIELDS, WIRE_SKILL_STAGE_FIELDS, WIRE_TASKS_FIELDS, WIRE_TOOLS_FIELDS, WIRE_TOOL_GATE_FIELDS, WIRE_TOOL_ROW_FIELDS, WIRE_TRUST_REQUEST_FIELDS, WIRE_TRUST_REQUEST_RESPONSE_FIELDS, WIRE_WORKSPACE_DIFF_FIELDS, WIRE_WORKSPACE_DIRS_FIELDS, WIRE_WORKSPACE_DIR_ENTRY_FIELDS, WIRE_WORKSPACE_REF_FIELDS, type WireAbortResponse, type WireAbout, type WireAgentEnvelope, type WireAgentEvent, type WireAgentRoleSummary, type WireAppearanceRequest, type WireAppearanceResponse, type WireApprovalCacheRevokeRequest, type WireApprovalCacheRevokeResponse, type WireApprovalListResponse, type WireApprovalRequest, type WireArtifactsResponse, type WireAttachmentUploadResponse, type WireAuditCode, type WireAuditLog, type WireAuditOutcome, type WireAuditRow, type WireAuthDenyReason, type WireAuthDenyStatus, type WireAuthGuard, type WireAuthRequestView, type WireAuthVerdict, type WireBackgroundTask, type WireBindWorkspaceRequest, type WireBlockedGoal, type WireBlockedGoalsResponse, type WireBlockedLevel, type WireBuiltinConnector, type WireCachedApproval, type WireCachedDecision, type WireCapabilitiesResponse, type WireCapabilityProject, type WireCheckpointListResponse, type WireCheckpointSummary, type WireCommandExpansion, type WireCommandsResponse, type WireCompactRequest, type WireCompactResponse, type WireCompressionLine, type WireConfigResponse, type WireContextResponse, type WireCreateSessionRequest, type WireCreateSessionResponse, type WireCreateWorkspaceRequest, type WireCreateWorkspaceResponse, type WireCustomCommand, type WireDeleteSessionResponse, type WireDiffFile, type WireDiffNote, type WireDiffOmitReason, type WireDiffSource, type WireDiffStatus, type WireEnvelope, type WireErrorResponse, type WireEvent, type WireFields, type WireFileCandidate, type WireFileCandidatesResponse, type WireFileChange, type WireFileKind, type WireFileOpenRefusal, type WireFileOpenResponse, type WireFileReference, type WireFileRefusal, type WireFileStat, type WireFileStatOk, type WireFileStatRefused, type WireFileStatResponse, type WireFileTextResponse, type WireFixture, type WireFixtureCase, type WireForgetWorkspaceRequest, type WireForgetWorkspaceResponse, type WireGoal, type WireGoalBlock, type WireGoalClearResponse, type WireGoalCreateRequest, type WireGoalLimits, type WireGoalPhase, type WireGoalRefusal, type WireGoalResponse, type WireGoalUpdateRequest, type WireGoalWriteResponse, type WireHealthResponse, type WireHostCompose, type WireHostComposeRequest, type WireHostComposeResponse, type WireHostComposeStateResponse, type WireHostComposeTakeResponse, type WireHubEnvelope, type WireHubEvent, type WireImageReference, type WireKnownWorkspace, type WireKnownWorkspaceRef, type WireLastSessionRequest, type WireLastSessionResponse, type WireManagedLock, type WireMcpAddRequest, type WireMcpAddResponse, type WireMcpApplyAction, type WireMcpApplyEntry, type WireMcpApplyResponse, type WireMcpConfigApplyRequest, type WireMcpConfigIssue, type WireMcpConfigResponse, type WireMcpConfigSaveRequest, type WireMcpConfigSaveResponse, type WireMcpConnector, type WireMcpReconnectResponse, type WireMessageListResponse, type WireModelCaveat, type WireModelProbeStatus, type WireModelRejection, type WireModelResponse, type WireModelSelection, type WireModelSetRequest, type WireModelSetResponse, type WireModelSource, type WireModelSuggestions, type WirePatchSessionRequest, type WirePatchSessionResponse, type WirePermissionRememberFailure, type WirePermissionRuleRow, type WirePermissionSetRequest, type WirePermissionSetResponse, type WirePermissionShadow, type WirePermissionState, type WirePermissionStatus, type WirePickDirectoryResponse, type WirePlanAction, type WirePlanModeRequest, type WirePlanModeResponse, type WirePlanModeState, type WirePlanResponse, type WirePluginActionResponse, type WirePluginCategory, type WirePluginCounts, type WirePluginDependency, type WirePluginDependencyInventory, type WirePluginDependencyStatus, type WirePluginDoc, type WirePluginDocs, type WirePluginEntry, type WirePluginHit, type WirePluginHookTally, type WirePluginInstallRequest, type WirePluginLocalInstallRequest, type WirePluginLocalRequest, type WirePluginMarketplace, type WirePluginMarketplaceRequest, type WirePluginMarketplaceResponse, type WirePluginMenuItem, type WirePluginNameRequest, type WirePluginPreview, type WirePluginPreviewRequest, type WirePluginPreviewResponse, type WirePluginPreviewStreamLine, type WirePluginProgressStep, type WirePluginRefreshResponse, type WirePluginRefuseReason, type WirePluginSourceType, type WirePluginStageRequest, type WirePluginStageResponse, type WirePluginStatus, type WirePluginUpdateRequest, type WirePluginUploadChoice, type WirePluginUploadConfirmRequest, type WirePluginUploadField, type WirePluginUploadFieldName, type WirePluginUploadFields, type WirePluginUploadFile, type WirePluginUploadForm, type WirePluginUploadPlan, type WirePluginUploadPreviewResponse, type WirePluginUploadRequest, type WirePluginUploadResponse, type WirePluginVersionUnmet, type WirePluginVisibility, type WirePluginsResponse, type WirePolicyDir, type WirePolicyStatus, type WireProjectInventory, type WireProviderKeyRequest, type WireProviderKeyResponse, type WireProviderModelsRequest, type WireProviderModelsResponse, type WireProviderOption, type WireProviderSummary, type WireProvidersResponse, type WireQuestionListResponse, type WireQuestionRequest, type WireReplayMessage, type WireResetReason, type WireRespondApprovalRequest, type WireRespondApprovalResponse, type WireRespondQuestionRequest, type WireRespondQuestionResponse, type WireRewindAction, type WireRewindDrift, type WireRewindFilePlan, type WireRewindOutcome, type WireRewindPreview, type WireRewindRequest, type WireRewindResponse, type WireRewindScope, type WireRoleAddRequest, type WireRoleAddResponse, type WireRoleRemoveFailure, type WireRoleRemoveResponse, type WireRolesResponse, type WireRunningSchedule, type WireSandboxReason, type WireSandboxStatus, type WireScheduleCapability, type WireScheduleCreateRequest, type WireScheduleDefaults, type WireScheduleDeleteResponse, type WireScheduleFixRequest, type WireScheduleFixResponse, type WireScheduleIssue, type WireScheduleIssueCode, type WireScheduleListResponse, type WireSchedulePendingResponse, type WireScheduleRecordingResponse, type WireScheduleRegisterRefusal, type WireScheduleRegisterWarning, type WireScheduleRegistration, type WireScheduleResponse, type WireScheduleRow, type WireScheduleRunResponse, type WireScheduleRunningResponse, type WireScheduleRunsResponse, type WireScheduleSaveResponse, type WireScheduleUpdateRequest, type WireSecurityResponse, type WireSecurityWorkspace, type WireSendMessageRequest, type WireSendMessageResponse, type WireSessionCandidate, type WireSessionCandidatesResponse, type WireSessionFinish, type WireSessionListResponse, type WireSessionReference, type WireSessionResponse, type WireSessionSummary, type WireSessionWorkspace, type WireSessionWorkspaceResponse, type WireSettingApply, type WireSettingFutile, type WireSettingLayer, type WireSettingPending, type WireSettingRow, type WireSettingStep, type WireSettingValue, type WireSettingValueKind, type WireSettingWrite, type WireSettingWriteLayer, type WireSettingsResponse, type WireSettingsWriteRequest, type WireSettingsWriteResponse, type WireSkillBodyResponse, type WireSkillImportConflict, type WireSkillImportEntry, type WireSkillImportFailure, type WireSkillImportForm, type WireSkillImportIssue, type WireSkillImportPreviewResponse, type WireSkillImportResponse, type WireSkillRemoveFailure, type WireSkillRemoveResponse, type WireSkillStageFailure, type WireSkillStageResponse, type WireSkillSummary, type WireSummaryWorkspace, type WireTaggedEvent, type WireTasksResponse, type WireToolGate, type WireToolGateAxis, type WireToolRow, type WireToolSummary, type WireToolVerdict, type WireToolsResponse, type WireTrustRequestRequest, type WireTrustRequestResponse, type WireTurnState, type WireWorkspaceBinding, type WireWorkspaceDiffResponse, type WireWorkspaceDirEntry, type WireWorkspaceDirsResponse, type WireWorkspaceRef, apiKeyEnvVar, assertNeverPart, assistantTurnText, attachSessionSurface, chordId, collectPendingApprovals, compressionThresholdTokens, conformsToWire, contentToText, cronTimes, diagnosticToLine, extractAllMentions, extractMentions, extractSessionMentions, filePartSummary, flattenCatalog, formatMoney, getProviderInfo, hasFailure, imagePartOmittedSummary, isAppearanceLang, isAppearanceSidebarWidth, isAppearanceTheme, isApprovalOutcome, isContextNearlyFull, isCurrency, isHeadlessInputFormat, isHeadlessLifecycleEvent, isHeadlessOutputFormat, isKeyAction, isLang, isMentionableFilePath, isOperationType, isPermissionLevel, isPlanOutcome, isPromptOversize, isProviderType, isQuestionAnswerMap, isSearchProviderType, isSettingsPaneId, isValidAgentRoleName, isValidCommandName, isWireGoalPhase, isWireHubEvent, isWirePlanAction, isWirePluginArchiveName, isWireRewindScope, isWireSettingWriteLayer, isWireSkillDropName, joinUploadMulti, makeTranslate, mcpConnectorState, normalizeApproval, packSessionSurface, parseChord, parseModelRef, parseSequence, perAction, placeholdersOf, promptTokens, resolveHostText, sequenceId, sessionPartSummary, splitUploadMulti, stripSystemNote, systemNote, tableOf, totalUsageTokens, translatorFor, truncateToBudget, turnDigest, unfixedRules, utf8ByteLength, wireFields };
+export { ACTION_CONTEXTS, AGENT_ROLE_NAME_PATTERN, API_KEY_ENV_VARS, APPEARANCE_LANGS, APPEARANCE_SIDEBAR_WIDTH, APPEARANCE_THEMES, APPROVAL_OUTCOMES, type ActiveAgentRole, type AgentEvent, type AgentEventOf, type AgentEventType, type AgentRole, type AgentRoleScope, type AgentRoleSource, type AppearanceLang, type AppearanceTheme, type ApprovalAnswer, type ApprovalOutcome, type ApprovalReply, type ApprovalRequest, type ApprovalScope, type ArtifactKind, type AttributeValue, type Attributes, BRAND_WHEN_SIDEBAR_COLLAPSED, type BackgroundTaskInfo, type BackgroundTaskKind, type BackgroundTaskStatus, type BlankCard, type BlankGreeting, type BoundKey, type BrandWhenSidebarCollapsed, type BudgetBreach, COMMAND_NAME_PATTERN, COMPLIANCE_ACTIONS, COMPLIANCE_CATEGORIES, CURRENCIES, type Catalogs, type ComplianceAction, type ComplianceCategory, type ContextBreakdown, type ContextNote, type ContextSegment, type ContextSegmentKind, type Currency, type CurrencyDisplay, type CustomCommandDef, type CustomCommandSource, DEFAULT_AGENT_ROLE, DEFAULT_LANG, type DecidedTrustLevel, type Diagnostic, DiagnosticSink, type DiagnosticStatus, ENTRY_REF_PREFIX, ENTRY_SECRET_PREFIX, type EpochConfig, type EpochContentPart, type EpochFilePart, type EpochHook, type EpochImagePart, type EpochMessage, type EpochMessageRole, type EpochPlugin, type EpochSessionPart, type EpochSkill, type EpochTextPart, type EpochTool, type EpochToolCall, type EpochToolResult, type EpochTurnFacts, type EpochUserContent, type ExpandedCommand, FOLLOW_SYSTEM, type FileOmitReason, type FinishReason, type FixableApproval, type FlatCatalog, type FormatMoneyOptions, GEN_AI, HEADLESS_INPUT_EVENT_TYPES, HEADLESS_INPUT_FORMATS, HEADLESS_OUTPUT_FORMATS, HEADLESS_PROTOCOL_VERSION, type HeadlessEnvelope, type HeadlessEvent, type HeadlessInit, type HeadlessInputEvent, type HeadlessInputEventType, type HeadlessInputFormat, type HeadlessLifecycleEvent, type HeadlessOutputFormat, type HeadlessResult, type HeadlessResultReason, type HookContext, type HookEvent, type HookHandler, type HookManager, type HookRegistration, type HookType, type HostText, type HostUser, type JsonSchema, KEY_ACTIONS, type KeyAction, type KeyChord, type KeyContext, type KeySequence, type KeybindingReport, type KeybindingSource, type KeybindingTable, LANGS, type Lang, type LocalizedDetail, type LogFn, MAX_ATTACH_BYTES, MAX_ATTACH_FILES, MAX_ATTACH_TOTAL_BYTES, MAX_HEADER_CHARS, MAX_OPTIONS, MAX_QUESTIONS, MAX_SESSION_ATTACH_BYTES, MAX_SESSION_REFS, MCP_DATA_KEY_NAME, METRIC, MIN_OPTIONS, MODEL_ENTRY_PROTOCOLS, type MentionSet, type ModelEntry, type ModelEntryCapabilities, type ModelEntryProtocol, type ModelRef, type ModelSelection, type ModelSelectionOrigin, type MoneyDigits, NOOP_TELEMETRY, type NoticeCode, OPEN_SETTINGS_MESSAGE_TYPE, OPERATION_TYPES, OVERSIZE_RATIO, type OpenSettingsMessage, type Operation, type OperationType, PERMISSION_LEVELS, PLAN_OUTCOMES, PLUGIN_CATEGORY_DISPLAY_SEP, PLUGIN_MENU_MESSAGE_TYPE, PLUGIN_PREVIEW_STREAM_MIME, PLUGIN_UPLOAD_MULTI_SEP, PROVIDER_INFOS, PROVIDER_TYPES, type PermissionDecision, type PermissionLevel, type PermissionManager, type PermissionRuleLists, type PlanApprovalOutcome, type PlanProposal, type PluginContext, type PluginMenuMessage, type ProviderInfo, type ProviderType, type QuestionAnswer, type QuestionItem, type QuestionOption, type QuestionPage, type QuestionRequest, REASONING_EFFORTS, REASONING_OFF, RESERVED_CHORDS, RESERVED_COMMAND_NAMES, type ReasoningChoice, type ReasoningEffort, type ReasoningState, type RejectReason, type RejectedKey, type RuleValue, SCHEDULE_DRAFT_TOOL, SCHEDULE_INTERVAL_MAX_MINUTES, SCHEDULE_INTERVAL_MIN_MINUTES, SCHEDULE_MAX_TIMES_PER_DAY, SCHEDULE_RUN_STATUSES, SEARCH_API_KEY_ENV, SEARCH_PROVIDER_TYPES, SECRET_SERVICE, SEQUENCE_CONTEXTS, SESSION_MENTION_PREFIX, SESSION_REFERENCE_ERROR_CODES, SETTINGS_PANE_IDS, SHELL_KINDS, SIDEBAR_MENU_MESSAGE_TYPE, SIMULTANEOUS_CONTEXTS, SYSTEM_NOTE_PREFIX, type ScheduleAllowlist, type ScheduleBackendKind, type ScheduleCronTrigger, type ScheduleCycle, type ScheduleDefinition, type ScheduleDraft, type ScheduleDraftAllowlist, type ScheduleDraftCreate, type ScheduleDraftPermission, type ScheduleDraftUpdate, type SchedulePendingApproval, type SchedulePendingItem, type ScheduleRun, type ScheduleRunStatus, type ScheduleRunnerSpec, type ScheduleTrigger, type ScheduleTriggerKind, type ScheduleWeekday, type ScheduleWideningKind, type SearchProviderType, type SecretBackendId, type SecretStore, type SelectionContext, type SelectionRejection, type SelectionWarning, type SessionAttachKind, type SessionAttachResult, type SessionOmitReason, type SessionSurfaceMessage, type SessionSurfaceView, type SetSelectionResult, type SettingsPaneId, type SettingsPaneItem, type ShellKind, type SidebarMenuItem, type SidebarMenuMessage, type SidebarNavItem, type SpanLike, type SubToolCall, type SubToolCallResult, type Telemetry, type TokenUsage, type ToolAnnotations, type ToolArtifact, type ToolArtifactInput, type ToolContext, type ToolDefinition, ToolExposure, type ToolProvider, type ToolResult, type Translate, type TranslateVars, type TrustExecGrant, type TrustGrant, type TrustLevel, type TrustManager, type TrustRecord, type TrustScope, type TrustTier, UNLIMITED_TURNS, USER_MENU_MESSAGE_TYPE, type UserMenuMessage, type VerifyResult, WIRE_ABORT_FIELDS, WIRE_ABOUT_FIELDS, WIRE_AGENT_ROLE_FIELDS, WIRE_APPEARANCE_RESPONSE_FIELDS, WIRE_APPROVAL_CACHE_REVOKE_REQUEST_FIELDS, WIRE_APPROVAL_CACHE_REVOKE_RESPONSE_FIELDS, WIRE_APPROVAL_LIST_FIELDS, WIRE_APPROVAL_ROW_FIELDS, WIRE_ARTIFACTS_FIELDS, WIRE_ATTACHMENT_FOLDER_FIELDS, WIRE_ATTACHMENT_UPLOAD_FIELDS, WIRE_AUDIT_LOG_FIELDS, WIRE_AUDIT_ROW_FIELDS, WIRE_AUTH_COOKIE, WIRE_AUTH_COOKIE_ATTRS, WIRE_AUTH_TOKEN_PARAM, WIRE_BACKGROUND_TASK_FIELDS, WIRE_BLOCKED_GOALS_FIELDS, WIRE_BLOCKED_GOAL_FIELDS, WIRE_BLOCKED_LEVEL_FIELDS, WIRE_BUILTIN_CONNECTOR_FIELDS, WIRE_CACHED_APPROVAL_FIELDS, WIRE_CAPABILITIES_FIELDS, WIRE_CAPABILITY_PROJECT_FIELDS, WIRE_CHECKPOINT_LIST_FIELDS, WIRE_CHECKPOINT_SUMMARY_FIELDS, WIRE_COMMANDS_FIELDS, WIRE_COMMAND_EXPANSION_FIELDS, WIRE_COMPACT_FIELDS, WIRE_COMPRESSION_LINE_FIELDS, WIRE_CONFIG_FIELDS, WIRE_CONTEXT_FIELDS, WIRE_CREATE_SESSION_FIELDS, WIRE_CREATE_WORKSPACE_FIELDS, WIRE_CREATE_WORKSPACE_RESPONSE_FIELDS, WIRE_CUSTOM_COMMAND_FIELDS, WIRE_DELETE_SESSION_FIELDS, WIRE_DIFF_FILE_FIELDS, WIRE_ERROR_FIELDS, WIRE_FILE_CANDIDATES_FIELDS, WIRE_FILE_CANDIDATE_FIELDS, WIRE_FILE_CHANGE_FIELDS, WIRE_FILE_OPEN_RESPONSE_FIELDS, WIRE_FILE_REFERENCE_FIELDS, WIRE_FILE_STAT_MAX, WIRE_FILE_STAT_OK_FIELDS, WIRE_FILE_STAT_REFUSED_FIELDS, WIRE_FILE_STAT_RESPONSE_FIELDS, WIRE_FILE_TEXT_RESPONSE_FIELDS, WIRE_FORGET_WORKSPACE_FIELDS, WIRE_FORGET_WORKSPACE_RESPONSE_FIELDS, WIRE_GOAL_ACTIONS, WIRE_GOAL_BLOCK_FIELDS, WIRE_GOAL_CLEAR_FIELDS, WIRE_GOAL_CREATE_FIELDS, WIRE_GOAL_FIELDS, WIRE_GOAL_LIMITS_FIELDS, WIRE_GOAL_PHASES, WIRE_GOAL_REFUSALS, WIRE_GOAL_RESPONSE_FIELDS, WIRE_GOAL_WRITE_FIELDS, WIRE_HEALTH_FIELDS, WIRE_IMAGE_REFERENCE_FIELDS, WIRE_KNOWN_WORKSPACE_FIELDS, WIRE_LANG_PARAM, WIRE_LAST_SESSION_FIELDS, WIRE_LAST_SESSION_RESPONSE_FIELDS, WIRE_MANAGED_LOCK_FIELDS, WIRE_MCP_ADD_FIELDS, WIRE_MCP_ADD_RESPONSE_FIELDS, WIRE_MCP_APPLY_ENTRY_FIELDS, WIRE_MCP_APPLY_RESPONSE_FIELDS, WIRE_MCP_CONFIG_APPLY_FIELDS, WIRE_MCP_CONFIG_FIELDS, WIRE_MCP_CONFIG_ISSUE_FIELDS, WIRE_MCP_CONFIG_SAVE_FIELDS, WIRE_MCP_CONFIG_SAVE_RESPONSE_FIELDS, WIRE_MCP_CONNECTOR_FIELDS, WIRE_MCP_RECONNECT_FIELDS, WIRE_MESSAGE_LIST_FIELDS, WIRE_MODEL_ENTRIES_FIELDS, WIRE_MODEL_ENTRY_MODELS_FIELDS, WIRE_MODEL_ENTRY_SAVE_FIELDS, WIRE_MODEL_ENTRY_TEST_FIELDS, WIRE_MODEL_FIELDS, WIRE_MODEL_SELECTION_FIELDS, WIRE_MODEL_SET_FIELDS, WIRE_PATCH_SESSION_FIELDS, WIRE_PATCH_SESSION_RESPONSE_FIELDS, WIRE_PERMISSION_RULE_FIELDS, WIRE_PERMISSION_SET_REQUEST_FIELDS, WIRE_PERMISSION_SET_RESPONSE_FIELDS, WIRE_PERMISSION_SHADOW_FIELDS, WIRE_PERMISSION_STATE_FIELDS, WIRE_PERMISSION_STATUS_FIELDS, WIRE_PLAN_ACTIONS, WIRE_PLAN_FIELDS, WIRE_PLAN_MODE_REQUEST_FIELDS, WIRE_PLAN_MODE_RESPONSE_FIELDS, WIRE_PLAN_MODE_STATE_FIELDS, WIRE_PLUGINS_FIELDS, WIRE_PLUGIN_ACTION_FIELDS, WIRE_PLUGIN_ARCHIVE_SUFFIXES, WIRE_PLUGIN_INSTALL_FIELDS, WIRE_PLUGIN_LOCAL_FIELDS, WIRE_PLUGIN_LOCAL_INSTALL_FIELDS, WIRE_PLUGIN_MARKETPLACE_FIELDS, WIRE_PLUGIN_MARKETPLACE_RESPONSE_FIELDS, WIRE_PLUGIN_NAME_FIELDS, WIRE_PLUGIN_PREVIEW_FIELDS, WIRE_PLUGIN_PREVIEW_RESPONSE_FIELDS, WIRE_PLUGIN_REFRESH_RESPONSE_FIELDS, WIRE_PLUGIN_STAGE_FIELDS, WIRE_PLUGIN_STAGE_RESPONSE_FIELDS, WIRE_PLUGIN_UPDATE_FIELDS, WIRE_PLUGIN_UPLOAD_CONFIRM_FIELDS, WIRE_PLUGIN_UPLOAD_FIELDS, WIRE_PLUGIN_UPLOAD_FORM_FIELDS, WIRE_PLUGIN_UPLOAD_PREVIEW_RESPONSE_FIELDS, WIRE_PLUGIN_UPLOAD_RESPONSE_FIELDS, WIRE_POLICY_DIR_FIELDS, WIRE_POLICY_STATUS_FIELDS, WIRE_PROJECT_INVENTORY_FIELDS, WIRE_PROVIDER_GROUPS, WIRE_QUESTION_LIST_FIELDS, WIRE_QUESTION_ROW_FIELDS, WIRE_RESPOND_APPROVAL_FIELDS, WIRE_RESPOND_APPROVAL_RESPONSE_FIELDS, WIRE_RESPOND_QUESTION_FIELDS, WIRE_RESPOND_QUESTION_RESPONSE_FIELDS, WIRE_REWIND_FILE_PLAN_FIELDS, WIRE_REWIND_OUTCOME_FIELDS, WIRE_REWIND_PREVIEW_FIELDS, WIRE_REWIND_REQUEST_FIELDS, WIRE_REWIND_RESPONSE_FIELDS, WIRE_REWIND_SCOPES, WIRE_ROLES_FIELDS, WIRE_ROLE_ADD_FIELDS, WIRE_ROLE_ADD_RESPONSE_FIELDS, WIRE_ROLE_REMOVE_FIELDS, WIRE_RUNNING_SCHEDULE_FIELDS, WIRE_SANDBOX_STATUS_FIELDS, WIRE_SCHEDULE_CAPABILITY_FIELDS, WIRE_SCHEDULE_CREATE_FIELDS, WIRE_SCHEDULE_DEFAULTS_FIELDS, WIRE_SCHEDULE_DELETE_FIELDS, WIRE_SCHEDULE_FIELDS, WIRE_SCHEDULE_FIX_FIELDS, WIRE_SCHEDULE_FIX_REQUEST_FIELDS, WIRE_SCHEDULE_ISSUE_CODES, WIRE_SCHEDULE_LIST_FIELDS, WIRE_SCHEDULE_PENDING_FIELDS, WIRE_SCHEDULE_RECORDING_FIELDS, WIRE_SCHEDULE_ROW_FIELDS, WIRE_SCHEDULE_RUNNING_FIELDS, WIRE_SCHEDULE_RUNS_FIELDS, WIRE_SCHEDULE_RUN_FIELDS, WIRE_SCHEDULE_SAVE_FIELDS, WIRE_SECURITY_FIELDS, WIRE_SECURITY_WORKSPACE_FIELDS, WIRE_SEND_MESSAGE_FIELDS, WIRE_SEND_MESSAGE_RESPONSE_FIELDS, WIRE_SESSION_CANDIDATES_FIELDS, WIRE_SESSION_CANDIDATE_FIELDS, WIRE_SESSION_FINISH_FIELDS, WIRE_SESSION_LIST_FIELDS, WIRE_SESSION_REFERENCE_FIELDS, WIRE_SESSION_RESPONSE_FIELDS, WIRE_SESSION_SUMMARY_FIELDS, WIRE_SESSION_WORKSPACE_FIELDS, WIRE_SESSION_WORKSPACE_RESPONSE_FIELDS, WIRE_SETTINGS_FIELDS, WIRE_SETTINGS_WRITE_FIELDS, WIRE_SETTINGS_WRITE_REQUEST_FIELDS, WIRE_SETTING_PENDING_FIELDS, WIRE_SETTING_ROW_FIELDS, WIRE_SETTING_STEP_FIELDS, WIRE_SETTING_WRITE_FIELDS, WIRE_SETTING_WRITE_LAYERS, WIRE_SKILL_BODY_FIELDS, WIRE_SKILL_DROP_SUFFIXES, WIRE_SKILL_FIELDS, WIRE_SKILL_IMPORT_FIELDS, WIRE_SKILL_IMPORT_PREVIEW_FIELDS, WIRE_SKILL_REMOVE_FIELDS, WIRE_SKILL_STAGE_FIELDS, WIRE_TASKS_FIELDS, WIRE_TOOLS_FIELDS, WIRE_TOOL_GATE_FIELDS, WIRE_TOOL_ROW_FIELDS, WIRE_TRUST_REQUEST_FIELDS, WIRE_TRUST_REQUEST_RESPONSE_FIELDS, WIRE_WITHDRAW_MESSAGE_FIELDS, WIRE_WORKSPACE_DIFF_FIELDS, WIRE_WORKSPACE_DIRS_FIELDS, WIRE_WORKSPACE_DIR_ENTRY_FIELDS, WIRE_WORKSPACE_REF_FIELDS, type WireAbortResponse, type WireAbout, type WireAgentEnvelope, type WireAgentEvent, type WireAgentRoleSummary, type WireAppearanceRequest, type WireAppearanceResponse, type WireApprovalCacheRevokeRequest, type WireApprovalCacheRevokeResponse, type WireApprovalListResponse, type WireApprovalRequest, type WireArtifactsResponse, type WireAttachmentFolderResponse, type WireAttachmentUploadResponse, type WireAuditCode, type WireAuditLog, type WireAuditOutcome, type WireAuditRow, type WireAuthDenyReason, type WireAuthDenyStatus, type WireAuthGuard, type WireAuthRequestView, type WireAuthVerdict, type WireBackgroundTask, type WireBindWorkspaceRequest, type WireBlockedGoal, type WireBlockedGoalsResponse, type WireBlockedLevel, type WireBuiltinConnector, type WireCachedApproval, type WireCachedDecision, type WireCapabilitiesResponse, type WireCapabilityProject, type WireCheckpointListResponse, type WireCheckpointSummary, type WireCommandExpansion, type WireCommandsResponse, type WireCompactRequest, type WireCompactResponse, type WireCompressionLine, type WireConfigResponse, type WireContextResponse, type WireCreateSessionRequest, type WireCreateSessionResponse, type WireCreateWorkspaceRequest, type WireCreateWorkspaceResponse, type WireCustomCommand, type WireDeleteSessionResponse, type WireDiffFile, type WireDiffNote, type WireDiffOmitReason, type WireDiffSource, type WireDiffStatus, type WireEffectiveModel, type WireEffectiveSlots, type WireEntryProbeCode, type WireEntryProvider, type WireEnvelope, type WireErrorResponse, type WireEvent, type WireFields, type WireFileCandidate, type WireFileCandidatesResponse, type WireFileChange, type WireFileKind, type WireFileOpenRefusal, type WireFileOpenResponse, type WireFileReference, type WireFileRefusal, type WireFileStat, type WireFileStatOk, type WireFileStatRefused, type WireFileStatResponse, type WireFileTextResponse, type WireFixture, type WireFixtureCase, type WireForgetWorkspaceRequest, type WireForgetWorkspaceResponse, type WireGoal, type WireGoalBlock, type WireGoalClearResponse, type WireGoalCreateRequest, type WireGoalLimits, type WireGoalPhase, type WireGoalRefusal, type WireGoalResponse, type WireGoalUpdateRequest, type WireGoalWriteResponse, type WireHealthResponse, type WireHostBadgeRequest, type WireHostBadges, type WireHostCompose, type WireHostComposeRequest, type WireHostComposeResponse, type WireHostComposeStateResponse, type WireHostComposeTakeResponse, type WireHubEnvelope, type WireHubEvent, type WireImageReference, type WireKnownWorkspace, type WireKnownWorkspaceRef, type WireLastSessionRequest, type WireLastSessionResponse, type WireManagedLock, type WireMcpAddRequest, type WireMcpAddResponse, type WireMcpApplyAction, type WireMcpApplyEntry, type WireMcpApplyResponse, type WireMcpConfigApplyRequest, type WireMcpConfigIssue, type WireMcpConfigResponse, type WireMcpConfigSaveRequest, type WireMcpConfigSaveResponse, type WireMcpConnector, type WireMcpReconnectResponse, type WireMessageListResponse, type WireModelCaveat, type WireModelEffortRequest, type WireModelEffortResponse, type WireModelEntriesResponse, type WireModelEntry, type WireModelEntryModelsResponse, type WireModelEntryProbeRequest, type WireModelEntryRefRequest, type WireModelEntryRefs, type WireModelEntrySaveRequest, type WireModelEntrySaveResponse, type WireModelEntryTestResponse, type WireModelRejection, type WireModelResponse, type WireModelSelection, type WireModelSetRequest, type WireModelSetResponse, type WirePatchSessionRequest, type WirePatchSessionResponse, type WirePermissionRememberFailure, type WirePermissionRuleRow, type WirePermissionSetRequest, type WirePermissionSetResponse, type WirePermissionShadow, type WirePermissionState, type WirePermissionStatus, type WirePickDirectoryResponse, type WirePlanAction, type WirePlanModeRequest, type WirePlanModeResponse, type WirePlanModeState, type WirePlanResponse, type WirePluginActionResponse, type WirePluginCategory, type WirePluginCounts, type WirePluginDependency, type WirePluginDependencyInventory, type WirePluginDependencyStatus, type WirePluginDoc, type WirePluginDocs, type WirePluginEntry, type WirePluginHit, type WirePluginHookTally, type WirePluginInstallRequest, type WirePluginLocalInstallRequest, type WirePluginLocalRequest, type WirePluginMarketplace, type WirePluginMarketplaceRequest, type WirePluginMarketplaceResponse, type WirePluginMenuItem, type WirePluginNameRequest, type WirePluginPreview, type WirePluginPreviewRequest, type WirePluginPreviewResponse, type WirePluginPreviewStreamLine, type WirePluginProgressStep, type WirePluginRefreshResponse, type WirePluginRefuseReason, type WirePluginSourceType, type WirePluginStageRequest, type WirePluginStageResponse, type WirePluginStatus, type WirePluginUpdateRequest, type WirePluginUploadChoice, type WirePluginUploadConfirmRequest, type WirePluginUploadField, type WirePluginUploadFieldName, type WirePluginUploadFields, type WirePluginUploadFile, type WirePluginUploadForm, type WirePluginUploadPlan, type WirePluginUploadPreviewResponse, type WirePluginUploadRequest, type WirePluginUploadResponse, type WirePluginVersionUnmet, type WirePluginVisibility, type WirePluginsResponse, type WirePolicyDir, type WirePolicyStatus, type WireProjectInventory, type WireProviderGroup, type WireQuestionListResponse, type WireQuestionRequest, type WireReplayMessage, type WireResetReason, type WireRespondApprovalRequest, type WireRespondApprovalResponse, type WireRespondQuestionRequest, type WireRespondQuestionResponse, type WireRewindAction, type WireRewindDrift, type WireRewindFilePlan, type WireRewindOutcome, type WireRewindPreview, type WireRewindRequest, type WireRewindResponse, type WireRewindScope, type WireRoleAddRequest, type WireRoleAddResponse, type WireRoleRemoveFailure, type WireRoleRemoveResponse, type WireRolesResponse, type WireRunningSchedule, type WireSandboxReason, type WireSandboxStatus, type WireScheduleCapability, type WireScheduleCreateRequest, type WireScheduleDefaults, type WireScheduleDeleteResponse, type WireScheduleFixRequest, type WireScheduleFixResponse, type WireScheduleIssue, type WireScheduleIssueCode, type WireScheduleListResponse, type WireSchedulePendingResponse, type WireScheduleRecordingResponse, type WireScheduleRegisterRefusal, type WireScheduleRegisterWarning, type WireScheduleRegistration, type WireScheduleResponse, type WireScheduleRow, type WireScheduleRunResponse, type WireScheduleRunningResponse, type WireScheduleRunsResponse, type WireScheduleSaveResponse, type WireScheduleUpdateRequest, type WireSecurityResponse, type WireSecurityWorkspace, type WireSendMessageRequest, type WireSendMessageResponse, type WireSessionCandidate, type WireSessionCandidatesResponse, type WireSessionFinish, type WireSessionListResponse, type WireSessionReference, type WireSessionResponse, type WireSessionSummary, type WireSessionWorkspace, type WireSessionWorkspaceResponse, type WireSettingApply, type WireSettingFutile, type WireSettingLayer, type WireSettingPending, type WireSettingRow, type WireSettingStep, type WireSettingValue, type WireSettingValueKind, type WireSettingWrite, type WireSettingWriteLayer, type WireSettingsResponse, type WireSettingsWriteRequest, type WireSettingsWriteResponse, type WireSkillBodyResponse, type WireSkillImportConflict, type WireSkillImportEntry, type WireSkillImportFailure, type WireSkillImportForm, type WireSkillImportIssue, type WireSkillImportPreviewResponse, type WireSkillImportResponse, type WireSkillRemoveFailure, type WireSkillRemoveResponse, type WireSkillStageFailure, type WireSkillStageResponse, type WireSkillSummary, type WireSummaryWorkspace, type WireTaggedEvent, type WireTasksResponse, type WireToolGate, type WireToolGateAxis, type WireToolRow, type WireToolSummary, type WireToolVerdict, type WireToolsResponse, type WireTrustRequestRequest, type WireTrustRequestResponse, type WireTurnState, type WireWithdrawMessageResponse, type WireWorkspaceBinding, type WireWorkspaceDiffResponse, type WireWorkspaceDirEntry, type WireWorkspaceDirsResponse, type WireWorkspaceRef, apiKeyEnvVar, assertNeverPart, assistantTurnText, attachSessionSurface, chordId, collectPendingApprovals, compressionThresholdTokens, conformsToWire, contentToText, cronTimes, diagnosticToLine, entryDisplayName, entryRef, entrySecretName, extractAllMentions, extractMentions, extractSessionMentions, filePartSummary, flattenCatalog, formatMoney, getProviderInfo, hasFailure, imagePartOmittedSummary, isAppearanceLang, isAppearanceSidebarWidth, isAppearanceTheme, isApprovalOutcome, isContextNearlyFull, isCurrency, isEntrySecretName, isHeadlessInputFormat, isHeadlessLifecycleEvent, isHeadlessOutputFormat, isKeyAction, isLang, isMentionableFilePath, isModelEntryId, isOperationType, isPermissionLevel, isPlanOutcome, isPromptOversize, isProviderType, isQuestionAnswerMap, isReasoningEffort, isSearchProviderType, isSettingsPaneId, isValidAgentRoleName, isValidCommandName, isWireGoalPhase, isWireHubEvent, isWirePlanAction, isWirePluginArchiveName, isWireRewindScope, isWireSettingWriteLayer, isWireSkillDropName, joinUploadMulti, makeTranslate, mcpConnectorState, normalizeApproval, packSessionSurface, parseChord, parseModelRef, parseSequence, perAction, placeholdersOf, promptTokens, resolveHostText, sequenceId, sessionPartSummary, splitUploadMulti, stripSystemNote, systemNote, tableOf, totalUsageTokens, translatorFor, truncateToBudget, turnDigest, unfixedRules, utf8ByteLength, wireFields };