dsh-router-core 0.4.2 → 0.4.4

package/src/ext-prompt/render.ts

@@ -0,0 +1,216 @@
+/**
+ * 纯逻辑层 —— 分类开关的读取、校验与 prompt 文本渲染。
+ *
+ * 为什么单独成文件：**不 import cordis / 任何 DSH 包**，所以能被 `node --test`
+ * 直接跑。DSH 侧的注册/挂载（ext.ts / inject.ts）只是薄壳；所有会出错的判断
+ * 都在这里，且这里能注入违规用例证明它们会变红。
+ */
+import { PROMPT_CATEGORIES, PROMPT_TITLE, type PromptCategory } from './content.ts'
+
+/** 落盘在 `router.extStore` 数据块里的形状。 */
+export interface PromptExtData {
+  /** 分类开关：`{ [categoryId]: boolean }`。缺项走 `defaultOn`。 */
+  categories?: Record<string, boolean>
+  /**
+   * 用户在面板里改过的文本：`{ [categoryId]: { title?, body? } }`。
+   *
+   * ⚠️ **与 `categories` 分开两个键**：开关是"开不开"、文本是"写成什么样"。
+   *   挤在一个键里，改标题会顺手碰到开关状态（`writeData` 是**整块替换**，
+   *   少一个键就是少一份数据）。
+   *
+   * ⚠️ **只存覆盖值，不存全文**：没改过的分类不出现在这里 ⇒ 内置内容仍是唯一
+   *   事实源，升级内置文案时没改过的那几条会跟着更新。存全文 = 用户改一个字
+   *   就永久冻结了整段，之后内置更新对它们完全失效。
+   */
+  text?: Record<string, PromptCategoryOverride>
+  /**
+   * 用户自建的准则条目。**与内置的 `PROMPT_CATEGORIES` 分开存** ——
+   * 内置那 14 条是**代码常量**（发版即定），混在一起就会出现"代码里有一条、
+   * 落盘里又有一条"的归属问题：升级时新加的内置条目会和用户的旧数据打架。
+   *
+   * 存的是**完整条目**（不是覆盖值）：自建的东西没有"内置版本"可回退。
+   */
+  custom?: PromptCategory[]
+  /**
+   * 展示顺序：`[id, …]`，含内置与自建。
+   *
+   * ⚠️ **只存 id 顺序，不重排内置数组本身**：内置 14 条的次序是 `content.ts`
+   *   里的代码顺序，它同时是"准则作为一份文档的阅读顺序"；让用户拖动去改它，
+   *   等于让代码顺序随某个用户的操作漂移 —— 别人拿到新版本看到的次序就变了。
+   *   落盘只记"这次会话里按什么顺序显示"，代码顺序永远是兜底。
+   */
+  order?: string[]
+}
+
+/** 一条分类上用户改过的字段（只记改了的那些）。 */
+export interface PromptCategoryOverride {
+  title?: string
+  body?: string
+}
+
+/** 解出某分类**生效用**的文本：用户覆盖优先，否则用内置的。 */
+export function effectiveText(
+  id: string,
+  override: PromptCategoryOverride | undefined,
+  base: PromptCategory,
+): { title: string; body: string } {
+  return {
+    // ⚠️ 空串是**非法**覆盖（写入端已挡），万一脏数据进来了也不能让它把
+    //   分类"变成空的" —— 那会让那条规则凭空消失，看起来像被关了。
+    title: override?.title !== undefined && override.title !== '' ? override.title : base.title,
+    body: override?.body !== undefined && override.body !== '' ? override.body : base.body,
+  }
+}
+
+/** 分类 id 的全集（校验用）。 */
+export function knownCategoryIds(): string[] {
+  return PROMPT_CATEGORIES.map((c) => c.id)
+}
+
+/**
+ * 解出「哪些分类要渲染」。
+ *
+ * 三层语义，**顺序不可换**：
+ *   ① 总开关关 ⇒ 一条都不渲染（不是"渲染但没内容"——那样面板显示已开启、实际无效果）；
+ *   ② 数据块里显式写了的分类，用**用户存的值**（含显式 `false`）；
+ *   ③ 没写过的分类，用 `defaultOn`。
+ *
+ * ⚠️ 为什么 ② 要区别于「没写」：`false` 与 `undefined` 语义完全不同 ——
+ * 前者是用户主动关掉，后者是"没碰过"。把两者当同一件事，用户第一次关掉某分类
+ * 后升级插件、新增同名分类，那条就永远是关的（用户没要求过）。
+ */
+export function resolveEnabledCategories(
+  masterOn: boolean,
+  data: PromptExtData | undefined,
+): Set<string> {
+  const out = new Set<string>()
+  if (!masterOn) return out
+  const saved = data?.categories
+  // ⚠️ 遍历的是**合成后的列表**（内置 + 自建），不是内置常量 ——
+  //   否则自建条目的开关永远算不出来（它不在 PROMPT_CATEGORIES 里）。
+  for (const c of resolveCategories(data)) {
+    const v = saved ? saved[c.id] : undefined
+    if (v === undefined) {
+      if (c.defaultOn) out.add(c.id)
+    } else if (v === true) {
+      out.add(c.id)
+    }
+  }
+  return out
+}
+
+/**
+ * 渲染成**一个**段落文本（多分类拼一起）。
+ *
+ * 为什么要拼成一段而不是一段一个：面板开关是"分类"粒度，而 prompt 读起来
+ * 是一段连续的准则 —— 分成 14 个 section 会让 KV cache 每个分类各占一段、
+ * 增删任意一个分类都让其后全部位移。这里**注册一个 section，文本由开关拼装**。
+ *
+ * @returns 关闭的分类不进结果；全关 ⇒ 空串（上游 `renderPrompt` 会丢弃空段）。
+ */
+export function renderCategories(
+  enabled: ReadonlySet<string>,
+  categories: readonly PromptCategory[] = PROMPT_CATEGORIES,
+  overrides?: PromptExtData['text'],
+  /** 有没有加整段标题。默认 true；传**外部分类表**时传 false（见下方注释）。 */
+  withTitle = true,
+): string {
+  const lines: string[] = []
+  for (const c of categories) {
+    if (!enabled.has(c.id)) continue
+    // ⚠️ **这里用覆盖后的 body** —— 面板改的内容必须真的进 prompt。
+    //   漏了这一行，编辑就只是改了**显示**（用户会以为改了却没生效，
+    //   而 prompt 里还是旧的 ⇒ 最坏的一种"看起来成功了"）。
+    //   自建条目没有覆盖（`text` 里不会有它的键），`effectiveText` 走原值。
+    lines.push(effectiveText(c.id, overrides?.[c.id], c).body)
+  }
+  // ⚠️ **标题放在最后 join 之前**：它不属于任何分类（见 PROMPT_TITLE 的注释），
+  //   且只在**至少有一条规则开启**时才出现 —— 全关时整段返回空串被平台丢弃，
+  //   留着标题就变成"有一套叫准则 v5 的东西"却一条规则都没有。
+  //   标题放在**前面**：它要解释后面这些规则是什么。
+  // ⚠️ **分类之间空一行**（2026-09-29 用户拍板）。单 `\n` 时 15 条规则在窄栏里
+  //   密排成一块，肉眼看不出是 15 条独立的规则 —— 那正是"全都跑成一行"的观感
+  //   来源（实测系统提示词里 `\n` 一直都在，是**排版**问题不是**内容**问题）。
+  //   空行让每条规则成为独立段落。代价是 13 个换行符（~13 token，可忽略），
+  //   且不改变前缀位置 ⇒ KV cache 行为不变。
+  // ⚠️ 标题由**显式参数**决定，**不靠 `categories === PROMPT_CATEGORIES` 这种
+  //   引用相等**（2026-09-29 实测踩过）：接入自建条目后调用方传的是
+  //   `resolveCategories(data)` 合成列表，引用永远不相等 ⇒ 标题静默消失
+  //   （测试当场抓到）。「是不是默认那张表」是个**语义问题**，不该由
+  //   「是不是同一个对象」这种实现细节决定。
+  if (lines.length === 0) return ''
+  return withTitle ? [PROMPT_TITLE, ...lines].join('\n\n') : lines.join('\n\n')
+}
+
+/**
+ * 渲染当前应注入的完整 prompt 文本（总开关 + 分类开关都算进去）。
+ *
+ * 总开关关 ⇒ 空串，让上游 `renderPrompt` 丢弃该段 —— **不是**注入一段空白。
+ */
+export function renderPromptText(masterOn: boolean, data: PromptExtData | undefined): string {
+  if (!masterOn) return ''
+  // ⚠️ 传入 `resolveCategories(data)`（含自建 + 排序）而不是常量
+  //   `PROMPT_CATEGORIES` —— 否则拖动排序和自建条目都只停在面板上，不进 prompt。
+  return renderCategories(
+    resolveEnabledCategories(masterOn, data),
+    resolveCategories(data),
+    data?.text,
+    true, // 合成列表也是本扩展的条目集，照样加标题
+  )
+}
+
+/**
+ * 合成后的**一条**准则条目：内置或自建，已应用标题/正文覆盖。
+ * `builtin` 用来决定按钮（内置没有「删除」，只有「还原」）。
+ */
+export interface ResolvedCategory extends PromptCategory {
+  /** 自建（用户加的）——可删除；内置的不可删除。 */
+  readonly custom: boolean
+  /** 文本被用户改过（决定「还原」按钮是否可点）。 */
+  readonly overridden: boolean
+}
+
+/**
+ * 内置 + 自建 + 排序 ⇒ 有序的最终条目列表。
+ *
+ * ⚠️ 三条规则（顺序不可换）：
+ *  1. **内置在前、自建在后**，除非 `order` 显式给了别的次序。代码顺序是
+ *     "准则作为一份文档的阅读顺序"，不该被用户拖动改掉（见 `PromptExtData.order`）。
+ *  2. `order` 里**不认识的 id 一律忽略**，落盘不可信（手改的 ext.json、上一版的残渣）。
+ *  3. `order` **没提到的条目按原序补在后面** —— 丢了某条 ≠ 它消失了。
+ */
+export function resolveCategories(data: PromptExtData | undefined): ResolvedCategory[] {
+  const custom = Array.isArray(data?.custom) ? data.custom : []
+  // 自建条目也要过滤：脏数据里的空 id / 空正文会让渲染产出空白段落。
+  const validCustom = custom.filter(
+    (c) => !!c && typeof c.id === 'string' && c.id !== '' && typeof c.body === 'string' && c.body !== '',
+  )
+  const base: ResolvedCategory[] = [
+    ...PROMPT_CATEGORIES.map((c) => ({
+      ...c,
+      custom: false,
+      overridden: data?.text?.[c.id] !== undefined,
+    })),
+    ...validCustom.map((c) => ({
+      ...c,
+      title: c.title,
+      defaultOn: c.defaultOn !== false,
+      custom: true,
+      overridden: false, // 自建条目没有"内置版本"，改了就回不去
+    })),
+  ]
+  const order = Array.isArray(data?.order) ? data.order : []
+  if (order.length === 0) return base
+  const byId = new Map(base.map((c) => [c.id, c]))
+  const out: ResolvedCategory[] = []
+  for (const id of order) {
+    const hit = byId.get(id)
+    if (hit === undefined) continue // 规则 2
+    out.push(hit)
+    byId.delete(id)
+  }
+  for (const c of base) {
+    if (byId.has(c.id)) out.push(c) // 规则 3
+  }
+  return out
+}

package/src/ext-prompt/row.json

@@ -0,0 +1,5 @@
+{
+  "name": "dsh-router-core-ext-prompt",
+  "type": "module",
+  "description": "分层提示词扩展（随 dsh-router 核心分发）"
+}

package/src/ext-route.test.ts

@@ -0,0 +1,78 @@
+/**
+ * `/router/api/ext` 路由的**出口判据**。
+ *
+ * ⚠️ 为什么需要它（2026-09-30 实测的「扩展一直加载中、然后卡死」）：
+ *   我重构 op 分支时以为「成功路径统一落到末尾响应」，把 GET 的
+ *   `writeJson(res, 200, {ok:true, enhancers:list})` 删了 —— 结果**没有任何地方
+ *   写响应** ⇒ 请求永不结束 ⇒ 面板一直转圈。
+ *
+ *   ⚠️ **它躲过了全部现有闸门**：typecheck 通过（`writeJson` 少调一次不是类型错误）、
+ *   387 条单测全绿（没有一条从 HTTP 入口打过这个路由）、build 通过。
+ *   典型的「绕过入口的验证 = 没验入口」—— 判据全在函数级，缺一条**路由级**的。
+ *
+ * 做法：不启真服务器，直接读源码断言**每个 return 之前都有出口**这种形状 ——
+ * 太脆。改为**结构判据**：GET 与 PATCH 两条成功路径都必须能走到 `writeJson`。
+ */
+import test from 'node:test'
+import assert from 'node:assert/strict'
+import { readFileSync, readdirSync } from 'node:fs'
+
+const src = readFileSync(new URL('./index.ts', import.meta.url), 'utf8')
+
+/** 取出 `/ext` 路由的整段源码。 */
+function extRouteBody(): string {
+  const start = src.indexOf('route(`${ROUTER_API_BASE}/ext`')
+  assert.ok(start > 0, '找不到 /ext 路由')
+  // 到下一个 `route(` 之前
+  const next = src.indexOf('\n  route(', start + 10)
+  return src.slice(start, next > 0 ? next : start + 4000)
+}
+
+test('★ /ext 路由必须有 GET 的响应出口（少写一次 = 请求永不结束）', () => {
+  const body = extRouteBody()
+  const writes = body.match(/writeJson\(res, 2\d\d/g) ?? []
+  assert.ok(writes.length >= 1,
+    '/ext 路由里一处 writeJson 都没有 ⇒ 请求永不返回（面板一直"加载中"）')
+  // GET 成功路径：算完 list 之后必须写出
+  const listLine = body.indexOf('const list: ExtInfo[]')
+  assert.ok(listLine > 0, '找不到 GET 的 list 计算')
+  const after = body.slice(listLine)
+  // ⚠️ 窗口取 600 而非 200：出口上方有 5 行注释，窗口太窄会**误判成缺失**
+  //   （我第一版 200 就红了，而代码是好的 —— 又一次「判据比被守的东西严」）。
+  assert.match(after.slice(0, 600), /writeJson\(res,\s*200/,
+    'GET 算完 list 之后没有 writeJson ⇒ 响应不出口')
+})
+
+test('★ op 成功路径也必须带 enhancers（客户端靠它刷新）', () => {
+  const body = extRouteBody()
+  // op 块里那处：两侧都带 enhancers
+  const opWrites = body.match(/writeJson\(res,\s*200,\s*addedId[^)]*enhancers/g) ?? []
+  assert.ok(opWrites.length >= 1, 'op 成功没有回 enhancers ⇒ 增删改后界面停在旧状态')
+})
+
+test('注入：删掉 GET 的 writeJson ⇒ 本判据会红', () => {
+  // 反向自检：把出口拿掉，上面那条必须不成立。
+  const stripped = extRouteBody().replace(
+    /writeJson\(res,\s*200,\s*\{\s*ok:\s*true,\s*enhancers:\s*list\s*\}\)/,
+    '/* removed */',
+  )
+  const after = stripped.slice(stripped.indexOf('const list: ExtInfo[]'))
+  assert.doesNotMatch(after.slice(0, 600), /writeJson\(res,\s*200/,
+    '注入没生效：这个替换匹配不上（判据会静默全绿）')
+})
+
+// ── 源码目录的野文件（2026-09-30 实测：`.bak` 被提交进仓）────────
+test('★ src 下不许有备份/临时文件（它们会被 `git add -A` 顺手带进仓）', () => {
+  // ⚠️ 实测经过：我用 `sed -i.bak` 做注入验证，备份文件 `content.ts.bak`
+  //   **被 `git add src/ext-prompt/` 带进了提交**。
+  //   它没被任何代码引用（`.bak` 后缀），所以**测试、typecheck、build 全绿** ——
+  //   典型的「产物看起来对、仓里却多了一份东西」。
+  //   而且它危险在：下一个人看到 `content.ts.bak` 会以为是**第二份内容**，
+  //   正是准则里「反查重复：新旧成两份」要防的。
+  //
+  // `check-publish` 只管「patch / exports / files 白名单 / 源码清单」的一致性，
+  // **不管源码目录里的野文件** ⇒ 这里补上。
+  const junk = [...readdirSync(new URL('.', import.meta.url), { recursive: true } as never) as string[]]
+    .filter((f) => /\.(bak|orig|rej|tmp|swp)$/.test(f) || /~$/.test(f))
+  assert.deepEqual(junk, [], `源码目录里有临时/备份文件：${junk.join(', ')}`)
+})

package/src/host-version.test.ts

@@ -1,9 +1,12 @@
 /**
- * 宿主版本探测测试 —— 锁死「最近命中徽章仅在 >= 0.1.7 出现」这条判定。
+ * 宿主版本探测测试 —— 锁死那条**版本地板**（>= 0.2.0）。
  *
- * 起因：`conversation.composer.dock` 座位在 0.1.5 也在，但渲染在 InputBar 之后
- * 的独立块（位置不对）；只有 0.1.7 才放进底部操作行。座位名相同没法靠契约区分，
- * 只能按宿主版本号判定——本测试就是这条判据的唯一守卫。
+ * 这条判据现在只有一个用途：**在老宿主上出声**。兼容分叉（三处 `>= 0.1.7`）随
+ * 0.2.0 单面编写一起删掉了，所以本测试守的是「低于地板会被判为不支持 → apply 时
+ * 打警告」这条报警链，而不是某个功能开关。
+ *
+ * 地板抬到 0.2.0 的那一刻，0.1.7 从「支持」翻成「不支持」——这条断言就是那次
+ * 翻面的记录：谁想再加回 0.1.x 兼容，本测试会先红。
  */
 import test from 'node:test'
 import assert from 'node:assert/strict'
@@ -11,7 +14,7 @@ import { mkdirSync, mkdtempSync, writeFileSync } from 'node:fs'
 import { tmpdir } from 'node:os'
 import { join } from 'node:path'
 import { pathToFileURL } from 'node:url'
-import { detectHostVersion, isHost017Plus, supportsLastHitDock } from './host-version.ts'
+import { detectHostVersion, isHostSupported } from './host-version.ts'
 
 /** 造一个「装了指定版本 dsh」的临时 profile，返回它的 file: URL。 */
 function profileWithDsh(version: string | null): string {
@@ -25,37 +28,27 @@ function profileWithDsh(version: string | null): string {
 }
 
 test('读得到版本：detectHostVersion 返回 profile 里装的 dsh 版本', () => {
-  assert.equal(detectHostVersion(profileWithDsh('0.1.5-rc.3')), '0.1.5-rc.3')
-  assert.equal(detectHostVersion(profileWithDsh('0.1.7-alpha.2')), '0.1.7-alpha.2')
+  assert.equal(detectHostVersion(profileWithDsh('0.1.7-rc.2')), '0.1.7-rc.2')
+  assert.equal(detectHostVersion(profileWithDsh('0.2.0-rc.1')), '0.2.0-rc.1')
 })
 
-test('支持位：>= 0.1.7 才为真（预发布标识忽略，按前导数字比）', () => {
-  assert.equal(supportsLastHitDock(profileWithDsh('0.1.7-alpha.2')), true)
-  assert.equal(supportsLastHitDock(profileWithDsh('0.1.7')), true)
-  assert.equal(supportsLastHitDock(profileWithDsh('0.2.0')), true)
-  assert.equal(supportsLastHitDock(profileWithDsh('1.0.0')), true)
-  // 低于 0.1.7 → 不挂（0.1.5 位置不对，宁可不显示）
-  assert.equal(supportsLastHitDock(profileWithDsh('0.1.5-rc.3')), false)
-  assert.equal(supportsLastHitDock(profileWithDsh('0.1.6-alpha.2')), false)
-  assert.equal(supportsLastHitDock(profileWithDsh('0.1.4')), false)
+test('地板：>= 0.2.0 才算支持（预发布标识忽略，按前导数字比）', () => {
+  for (const v of ['0.2.0-rc.1', '0.2.0', '0.2.1', '1.0.0']) {
+    assert.equal(isHostSupported(profileWithDsh(v)), true, v)
+  }
 })
 
-test('isHost017Plus 与徽章支持位同源（三处兼容分叉共用一个判据）', () => {
-  for (const v of ['0.1.7-alpha.2', '0.1.7', '0.2.0', '1.0.0']) {
-    assert.equal(isHost017Plus(profileWithDsh(v)), true, v)
-    assert.equal(supportsLastHitDock(profileWithDsh(v)), true, v)
-  }
-  for (const v of ['0.1.5-rc.3', '0.1.6-alpha.2', '0.1.4']) {
-    assert.equal(isHost017Plus(profileWithDsh(v)), false, v)
-    assert.equal(supportsLastHitDock(profileWithDsh(v)), false, v)
+test('地板之下（0.1.5/0.1.6/0.1.7）判为不支持 —— 会打警告而不是静默走错路径', () => {
+  for (const v of ['0.1.5-rc.3', '0.1.6-alpha.2', '0.1.7-rc.2', '0.1.4']) {
+    assert.equal(isHostSupported(profileWithDsh(v)), false, v)
   }
 })
 
-test('读不到版本 → 一律当不支持（不抛、宁可不显示）', () => {
+test('读不到版本 → 判为不支持（无法确认也值得说一声），且不抛', () => {
   assert.equal(detectHostVersion(profileWithDsh(null)), undefined)
-  assert.equal(supportsLastHitDock(profileWithDsh(null)), false)
+  assert.equal(isHostSupported(profileWithDsh(null)), false)
   // 垃圾版本号
-  assert.equal(supportsLastHitDock(profileWithDsh('not-a-version')), false)
+  assert.equal(isHostSupported(profileWithDsh('not-a-version')), false)
   // baseUrl 缺失（冷启动/单测）→ 回落 ~/.dsh/profiles/web，不抛
-  assert.doesNotThrow(() => supportsLastHitDock(undefined))
+  assert.doesNotThrow(() => isHostSupported(undefined))
 })

package/src/host-version.ts

@@ -1,37 +1,46 @@
 /**
- * 宿主 DSH 版本探测 —— **0.1.5 / 0.1.7 兼容分叉的唯一判据来源**。
+ * 宿主 DSH 版本探测 —— 现在只剩两件事：**报版本**（日志 + `/router/api/health`）与
+ * **守版本地板**。
  *
- * 原先三处兼容都靠「能力检测」（看方法/属性在不在），语义上是同一个问题
- * ——「这是 0.1.7 还是更老」——却各检各的、还容易误判（插件自己 node_modules
- * 里的依赖版本与宿主实际加载的版本并不一致：实测插件解析到 schemastery 3.18.4，
- * profile 里却是 3.18.3、全局是 3.18.2）。所以统一改成**读宿主版本号**判定：
+ * ## 为什么不再有兼容分叉
  *
- *   1. 「最近命中」徽章：composer.dock 在 0.1.5 渲染位置不对 → >= 0.1.7 才挂。
- *   2. 设置命名空间：0.1.5 用 `settings.installSection` 注册；0.1.7 改由导出的
- *      Config 驱动（无此方法）→ 按版本走对应注册路径。
- *   3. adapter 的 tool-result 消息形态：0.1.5/0.1.6 = user 里的 'tool-result'
- *      块；0.1.7+ = 独立 role:'tool' 消息。
+ * 原来这里有三处 `>= 0.1.7` 的分叉（设置卡片注册路径、「最近命中」徽章座位、adapter
+ * 的工具结果消息形态），彼此独立判断、还容易误判。本插件现已按 **0.2.0 单面**编写，
+ * 三处的旧分支全部删除：
+ *
+ *   1. 设置卡片：0.1.5 走 `settings.installSection`，0.1.7+ 走导出的 volatile Config。
+ *      0.2.0 只有后者 → installSection 分支删除。
+ *   2. 「最近命中」徽章：0.1.5 渲染在 InputBar 之后的独立块（位置不对），0.1.7+ 才在
+ *      composer 底部操作行。0.2.0 起无条件挂载，不再问支持位。
+ *   3. adapter 工具结果形态：旧的「user 内嵌 tool-result 块」0.1.7 起退役；0.2.0 的
+ *      v3→v4 会话迁移还主动拒绝该包装，所以它到不了 adapter → 分支删除。
+ *
+ * ## 为什么仍要读版本
+ *
+ * 因为**跑在老宿主上必须出声**。删掉分叉不等于「老宿主也能跑」：0.1.x 上本插件会
+ * 静默走错路径（卡片不出、徽章错位、工具结果丢失），而用户看到的现象与「插件坏了」
+ * 无法区分。所以这里只保留一个判据 `isHostSupported`（>= 0.2.0），仅用于 apply 时
+ * 打一条醒目的警告 —— 不是兼容，是可诊断。
  *
  * 读法：宿主把 profile 目录挂在 `ctx.baseUrl`（见 data-dir.ts）。本插件跑在宿主
  * 进程内，`require.resolve('@deepseek-ai/dsh/package.json', { paths: [profile] })`
- * 会沿 profile 的 node_modules 向上解析到全局安装根（实测命中 bun 全局目录）。
- * 拿不到就回落直接拼路径，再不行就返回 undefined（按「不支持/老版本」处理，不抛）。
+ * 会沿 profile 的 node_modules 向上解析到全局安装根。拿不到就回落直接拼路径，再不行
+ * 返回 undefined（按「无法确认」处理，不抛）。
  *
- * 注意：**只能在 `apply(ctx)` 里用**（那时才有 baseUrl）。模块顶层（如 Config 导出）
- * 解析到的是插件自己的依赖，不能代表宿主——那处保留能力检测，见 index.ts 注释。
+ * 注意：**只能在 `apply(ctx)` 里用**（那时才有 baseUrl）。模块顶层解析到的是插件自己
+ * 的依赖，不能代表宿主。
  */
 import { readFileSync } from 'node:fs'
 import { createRequire } from 'node:module'
 import { join } from 'node:path'
 import { profileDirOf } from './data-dir.ts'
 
-/** 各兼容分叉的版本门槛。 */
-/** composer.dock 徽章 / 独立 role:'tool' 消息形态：0.1.7 起。 */
-const V0_1_7: readonly number[] = [0, 1, 7]
+/** 版本地板：低于此版本的宿主本插件不再兼容（0.1.5/0.1.6/0.1.7 全部落此下）。 */
+const V0_2_0: readonly number[] = [0, 2, 0]
 
 /**
  * 解析并比较 semver（只取前导数字段，预发布标识忽略）。
- * `0.1.7-alpha.2` → [0,1,7]，`0.1.5-rc.3` → [0,1,5]。
+ * `0.2.0-rc.1` → [0,2,0]，`0.1.7-alpha.2` → [0,1,7]。
  * 返回负数/0/正数，语义同 `<`/`==`/`>`。
  */
 function compareVersion(a: readonly number[], b: readonly number[]): number {
@@ -43,7 +52,7 @@ function compareVersion(a: readonly number[], b: readonly number[]): number {
   return 0
 }
 
-/** `0.1.7-alpha.2` → [0,1,7]；解析失败返回 null。 */
+/** `0.2.0-rc.1` → [0,2,0]；解析失败返回 null。 */
 function parseVersion(raw: string): number[] | null {
   const m = /^(\d+)(?:\.(\d+))?(?:\.(\d+))?/.exec(raw.trim())
   if (m === null) return null
@@ -53,11 +62,11 @@ function parseVersion(raw: string): number[] | null {
 /**
  * 探测 profile 里安装的 DSH 宿主版本。
  * @param baseUrl 宿主注入的 profile 锚点（`ctx.baseUrl`）
- * @returns 形如 `0.1.7-alpha.2`；读不到返回 undefined（调用方按「不支持」处理）
+ * @returns 形如 `0.2.0-rc.1`；读不到返回 undefined
  */
 export function detectHostVersion(baseUrl?: string): string | undefined {
   const profile = profileDirOf(baseUrl)
-  // 先走模块解析（能沿 node_modules 向上找到全局安装根），再回落直接拼路径。
+  // 先走模块解析（能沿 node_modules 向上找到全局安装根），再回落直接路径。
   const candidates: string[] = []
   try {
     candidates.push(createRequire(join(profile, 'noop.js')).resolve('@deepseek-ai/dsh/package.json'))
@@ -76,26 +85,17 @@ export function detectHostVersion(baseUrl?: string): string | undefined {
   return undefined
 }
 
-/** 宿主版本是否 >= 门槛。读不到版本 → false（按老版本处理）。 */
-function atLeast(baseUrl: string | undefined, min: readonly number[]): boolean {
+/**
+ * 宿主是否在本插件支持的地板之上（>= 0.2.0）。
+ *
+ * **只用于报警，不用于分流** —— 低于地板时插件照常加载，但要在日志里说清「这台宿主
+ * 不再兼容、会出现什么症状」，把静默的错变成可查的错。读不到版本 → false（当作
+ * 「无法确认」，同样值得说一句）。
+ */
+export function isHostSupported(baseUrl?: string): boolean {
   const v = detectHostVersion(baseUrl)
   if (v === undefined) return false
   const parsed = parseVersion(v)
   if (parsed === null) return false
-  return compareVersion(parsed, min) >= 0
-}
-
-/**
- * 宿主是否 >= 0.1.7。三处兼容分叉共用这一个判据：
- *   - 「最近命中」徽章（composer.dock 位置正确）
- *   - 设置命名空间（Config 驱动而非 installSection）
- *   - adapter 的独立 role:'tool' 消息形态
- */
-export function isHost017Plus(baseUrl?: string): boolean {
-  return atLeast(baseUrl, V0_1_7)
-}
-
-/** 「最近命中」徽章是否可用（= 宿主 >= 0.1.7）。 */
-export function supportsLastHitDock(baseUrl?: string): boolean {
-  return isHost017Plus(baseUrl)
+  return compareVersion(parsed, V0_2_0) >= 0
 }