两个客户端包的 README 把设置偏好的持久化位置写成 home 级 patch，实际落点是当前 profile 的 patch

[YOUKNOWWHOOO]

现象

两个客户端包的 README 都把设置偏好的持久化目标写成数据根级的 $DSH_HOME/cordis.patch.yml：

• dsh-client-locale/README.zh.md:12（英文版 README.md:12）逐字为「loopback 页面把选择持久化到 $DSH_HOME/cordis.patch.yml，非 loopback 页面则只为当前进程保留选择」；英文版为 loopback pages persist them in \$DSH_HOME/cordis.patch.yml`, while non-loopback pages keep them only for the current process`。
• dsh-client-ui-theme/README.zh.md:12（英文版 README.md:12）逐字为「回环客户端把两个值存入 ui-theme 设置命名空间，本地提供方默认将其持久化到 $DSH_HOME/cordis.patch.yml」；英文版为 A loopback client stores both values in the \ui-theme` settings namespace, which the local provider persists in `$DSH_HOME/cordis.patch.yml` by default`。

两处写的都是 home 级 patch。而设置（含这两个命名空间）的持久化文档实际是当前活动 profile 的 cordis.patch.yml。

证据一：这两个包自己的源码不这么写

两包的源码注释都把取值位置写成 "Host user-settings document"，没有一个提到 home 级 patch：

• dsh-client-ui-theme/lib/index.js:3 逐字为 /** Theme preferences stored in the Host user-settings document. */；该插件把 preference 与 fontSize 定义成普通 volatile Config（同文件 :80-83）。
• dsh-client-locale/lib/client.js:914 逐字为 /** Locale preference stored in the Host user-settings document. */。

证据二：设置文档的解析链落在 profile 目录

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

• dsh-settings/lib/index.js:399-408：get documentPath() { return this.ownerContext.configEditor.documentPath; }，其 JSDoc 逐字为 Current profile patch shown by the native configuration editor.；prepareDocument() 返回同一路径。同文件 :324 为 static inject = ["configEditor", "profileContext"]，写入调用在 :502-508。
• dsh-config-editor/lib/index.js:24-26：get documentPath() { return this.ownerContext.profileContext.patchPath; }；写盘在同文件 :123 的 writeFileAtomic(path, String(document), …)。
• dsh-app-boot/lib/index.js:946：const patchPath = join(dir, PROFILE_PATCH_FILENAME);（PROFILE_PATCH_FILENAME = "cordis.patch.yml"，dir 是该 profile 的目录），经 dsh/lib/profile-boot-*.js:263 的 patchPath: composed.profile.patchPath 进入 profileContext。
• $DSH_HOME/settings.yaml 是遗留文档，只在 Loader 稳定后被一次性导入（dsh-settings/lib/index.js:343-363），不是活的配置层。

因此设置的落点是 $DSH_HOME/profiles/<profile>/cordis.patch.yml。home 级 $DSH_HOME/cordis.patch.yml 在层序里是更高的覆盖层（在 profile 层之后应用），不是设置的存储位置。

证据三：同一仓库的另一批 README 把它写对了

• dsh-llm-deepseek/README.zh.md:114 逐字写「请从 $DSH_HOME/profiles/<profile>/cordis.patch.yml 中 llm-deepseek 条目的 config 以及覆盖它的 home patch 或命令行 overlay 中删除 protocol」。
• dsh-web-app/README.zh.md:70 逐字写 agent 预设设置页的保存结果「持久化到 $DSH_HOME/profiles/web/cordis.patch.yml」。

即 profile patch 是设置的存储位置、home patch 是覆盖层，这一点在其他 README 里是一致的。

影响

1. 按这两份 README 去找刚刚改过的偏好，会去 $DSH_HOME 下找一个并不存在的文件，而真正被改写的是 profiles/<profile>/cordis.patch.yml。
2. 把它当作写入位置是有害的：home 级 patch 在每一个 profile 上生效并压过 profile 层，因此按 README 手写一条 ui-theme 覆盖会同时改变所有 profile 的外观设置，并会使 Web 设置页对该行的写入被拒绝（dsh-config-editor 在写盘前自检，报 Configuration for "<id>" is overridden by a home patch or command-line overlay）。
3. 这与同一批文档里「home patch 是覆盖层」的表述互相矛盾，读者无法从文档判断该把偏好写在哪一层。

建议

把两处的 $DSH_HOME/cordis.patch.yml 改为 $DSH_HOME/profiles/<profile>/cordis.patch.yml；如需同时说明覆盖关系，可沿用 dsh-llm-deepseek README 的既有写法补一句「home 级 patch 可覆盖它」。

环境

• 操作系统：Windows 11 家庭版 25H2（内部版本 26200.8246，x64）。
• @deepseek-ai/dsh 0.2.0-rc.2，经 npx 安装；profile 组合为 @deepseek-ai/dsh-base + @deepseek-ai/dsh-web-app。
• 证据分层：源码位置取自本机安装树的发布产物（逐行回读）；$DSH_HOME/cordis.patch.yml 不存在、profiles/ 下只有 web 为本机实测。本文没有对 locale 与 theme 这两个键做运行期观测，因此「实际落点是 profile patch」这一结论建立在源码链路与同一机制下已发生的设置写入之上（本机同日一次界面设置改动确实落进了 profiles/web/cordis.patch.yml）。