桌面端 README 的共享清单把「设置」列入，但设置文档实际是各 profile 自己的 cordis.patch.yml

[YOUKNOWWHOOO]

现象

apps/desktop/README.zh.md 的「已知限制」小节（本次核对为第 470 行）逐字写：

桌面壳与 CLI dsh 共享 $DSH_HOME 下的会话、设置、凭据、工作区和存储，但可执行包、插件激活和锁文件彼此隔离。

英文版 apps/desktop/README.md 的「Known limitations」小节（第 468 行）是同一句。

这句话枚举的五项里，「设置」与实现不符：设置文档不是数据根下的共享文件，而是当前活动 profile 自己的 cordis.patch.yml，因此设置按 profile 分裂。CLI 的 web profile 与桌面端固定使用的 desktop profile 各持一份，一端在设置页里做的改动，另一端看不到。

证据一：官方文档

docs/subsystems/settings.md（文档站路径 reference/subsystems/settings.md）首段逐字：

The settings service projects volatile Config fields from active profile entries. The configuration editor persists edits through Cordis patches.

本机译文：设置服务从活动 profile 的条目投影易变 Config 字段，配置编辑器通过 Cordis patch 持久化编辑。

证据二：发布产物逐行回读（本机 @deepseek-ai/dsh 0.2.0-rc.2，以下位置为包内产物路径，不是仓库源码行号）

• 设置文档的路径：dsh-settings/lib/index.js 第 399 至 408 行

  /** Current profile patch shown by the native configuration editor. */
  get documentPath() {
    return this.ownerContext.configEditor.documentPath;
  }
  prepareDocument() {
    return Promise.resolve(this.documentPath);
  }

• 该路径的来源：dsh-config-editor/lib/index.js 第 24 至 26 行的 get documentPath() { return this.ownerContext.profileContext.patchPath; }；写盘在同文件第 123 行的 writeFileAtomic(path, String(document), …)。

• patchPath 的定义：dsh-app-boot/lib/index.js 第 946 行的 const patchPath = join(dir, PROFILE_PATCH_FILENAME);，其中 dir 是该 profile 的目录、PROFILE_PATCH_FILENAME = "cordis.patch.yml"；该值经 dsh/lib/profile-boot-*.js 第 263 行的 patchPath: composed.profile.patchPath 进入 profileContext。

• 设置的写入通道确实落在同一个服务上：dsh-settings/lib/index.js 第 324 行的 static inject = ["configEditor", "profileContext"]，写入调用在第 502 至 508 行的 this.ownerContext.configEditor.edit(entry, …)。

• 遗留设置文档只被一次性导入，不是活的配置层：dsh-settings/lib/index.js 第 343 至 363 行（其中第 348 行为 const path = join(profile.home, "settings.yaml");）。

因此设置的实际落点是 $DSH_HOME/profiles/<profile>/cordis.patch.yml：对 CLI 是 web，对桌面端是 desktop（后者由 apps/desktop/src/paths.ts 以字面量常量固定）。

影响

1. 以这句话为设计依据的部署会得出错误结论：以为设置在两端共享。它写在「已知限制」小节里，读者更容易把它当成一条已被确认的边界事实。
2. 同一份 README 的表格行（apps/desktop/README.zh.md 第 80 行）写的是「CLI 与 Desktop 共享 $DSH_HOME 下受支持的产品数据」——这是较宽的表述，与实现不冲突；冲突只出现在第 470 行那处逐项枚举里。
3. 这条同样是 Proposal: Let Desktop inherit existing CLI configuration and provide guided plugin migration #8351 所述现象（首次启动桌面端后「新状态掩盖了旧设置」）在设置归属上的成因：设置文档属于 web profile，桌面端使用 desktop profile，因此桌面端看不到 CLI 侧已保存的设置。

建议

把第 470 行（英文第 468 行）枚举中的「设置」去掉，或补一句说明：设置按 profile 持久化于该 profile 的 cordis.patch.yml，不跨 profile 共享。

环境

• 操作系统：Windows 11 家庭版 25H2（内部版本 26200.8246，x64）。
• @deepseek-ai/dsh 0.2.0-rc.2，经 npx 安装，dsh web 监听回环地址；profile 组合为 @deepseek-ai/dsh-base + @deepseek-ai/dsh-web-app。
• 本次为只读核对：上游仓库 master 的 README 与文档，以及本机安装树的发布产物（逐行回读）。未安装桌面端，未做运行期观测；关于桌面端 profile 名的结论来自 apps/desktop/src/paths.ts 的源码。

[f-infinite-z]

补一个一手佐证：我们做桌面端适配时正好核对过这条——本机 desktop profile 的 cordis.patch.yml 里确实保存着设置编辑产生的 ui-* 行（ui-theme 偏好、ui-settings-account 等），与 web profile 各持一份，「设置随 profile 分裂」在实际产物上可直接观察到；和 #8351 说的"首次启动桌面端看不到 CLI 侧设置"是同一成因。建议采纳：枚举里去掉「设置」，或明确写"设置按 profile 独立"。