取各主题官方色值，不做主观发挥——One Dark Pro 深色用 Darker 档（对话底取 peekViewEditor.background #1B1D23、面板/代码块取编辑器色 #23272E、再往上 #2C313A/#323842 是官方悬浮/选中色，正文 #ABB2BF，语法色取自扩展自带的 OneDark-Pro-darker.json），Dracula / Nord / GitHub Primer / Catppuccin 同理。

层级按各主题自己的关系排：最暗的一档给对话底，面板/代码块取编辑器色，越往前的表面越亮。这样既有面板感（对话底与内容差 8~11 级），整窗观感又和 VS Code 一致——早先两次偏差都出在这一层：一次把悬浮色当表面色（整窗偏亮），一次底色不够深（代码块和卡片跟背景糊在一起）。

只有两处偏离，都写在代码注释里：① 主题没公布的第四级灰阶按它自己的灰阶插值；② 浅色档里对比度不达标的原版彩色会压暗（例如 Latte 的粉彩）。

代码块底色取主题的面板/控件表面（VS Code 里 markdown 代码块就是这一层），所以代码块和对话底色一定分得开。另外四个 --dsw-static-neutral-* 填充（卡片头 / 悬停）也一并接管：deliverables / plan / schedule 这类卡片把它们写在元素级，不接管的话标题栏会停在 DSH 的固定近黑色（#212123）上，和卡片其它部分对不上。

仍未覆盖：菜单/浮层的模糊背板、终端 ANSI 色。明暗由「设置 → 通用」的外观切换决定，插件不另设开关。

在 $DSH_HOME/profiles/<profile>/ 下做三件事：

1. package.json：dependencies 加 "@hmkk/dsh-appearance": "link:<本仓库绝对路径>"，dsh.profile.bundles 数组追加 "@hmkk/dsh-appearance"；
2. node_modules/@hmkk/dsh-appearance 建目录联接（junction / symlink）指向本仓库根（scoped 名要先建 @hmkk/ 目录）；
3. 在仓库根补一个 peer 链接：node_modules/@deepseek-ai/schemastery → <profile>/node_modules/@deepseek-ai/schemastery。

少了第 3 步会踩坑：目录联接会让 Node 按真实路径（本仓库）向上找依赖，而 DSH 的运行时包在 profile 里，宿主半侧的 import '@deepseek-ai/schemastery' 会直接 ERR_MODULE_NOT_FOUND。

校验（在 profile 目录里跑，解析链与真实 loader 一致）：

node -e "import('@hmkk/dsh-appearance').then(m => console.log(m.name, typeof m.apply, Object.keys(m.Config({}))))"

回滚：删掉依赖与 bundles 条目、删掉两个链接即可（安装前请备份 package.json）。

仓库根 = 插件包本体（awesome-dsh-plugin 的 CI 只从根 / packages / plugins / apps 读 package.json）
├─ package.json          dsh.bundle.patch + dsh.client 两半侧的声明，以及开发用 scripts
├─ cordis.patch.yml      组合包层：插入插件行（行 id = 设置命名空间）
├─ index.js              宿主半侧：Config schema + 首屏字体注入
├─ client.js             浏览器半侧：设置页 + token 覆盖层（无构建）
├─ locale/{zh,en}.json   插件卡片的显示名与描述
├─ screenshots.json      插件市场详情页的截图清单
├─ assets/               截图与配色预览图
└─ tools/                开发工具（零依赖纯 Node）
   ├─ smoke-test.mjs     假 React + 假 ctx，把插件真跑一遍
   ├─ verify.mjs         token 名校验 + 配色对比度校验
   ├─ gen-presets.cjs    色板 → 42 个 token 字面量的生成器
   └─ asar.mjs           直接读取 DSH 的 app.asar（排查内部实现用）

两件事只有宿主（Node）能做：

1. 设置命名空间。DSH 的设置命名空间就是 Loader 行的 id，客户端插件无法自建。所以持久化必须由宿主半侧导出 Config（volatile 字段），浏览器半侧才能用 ctx.configForms.get('dsh-appearance') 读写。
2. 首屏注入。webserver/index-inject 是宿主侧的扩展点；客户端 CSS 要等 JS 模块图加载完才到。没有这一步，每次刷新都会先看到默认字体、再跳成用户选的字体。

数据流：

用户改动
  └─> ctx.configForms.get('dsh-appearance').set/unset
        └─> Host 校验 + 写入 profile 的 cordis.patch.yml（volatile 字段，带 revision）
              └─> 快照回流（subscribe）
                    ├─> 宿主：下次渲染 index 时把字体写进 <head>（首屏即正确）
                    └─> 客户端：ctx.theme.overrideTokens('dsh-appearance', {...})
                          └─> ui-layout 把 token 写成 body 内联样式，即时生效

• 终端字体：xterm 面板硬编码 fontSize: 13 与自己的字体名，并按自测字符宽度算 cols/rows；纯 CSS 改字体会让终端网格错位（终端 ANSI 配色同理不在覆盖范围内）。
• UI 全局字号：组件高度由字号轴阶梯推导，整体缩放会错位；只做官方支持的对话字号（10–22 px）。
• 自带字体文件：现在只用系统已装字体 + 精选字体栈（零文件、零许可风险）。字体包与 @font-face 放在后续版本。
• 配色不做首屏注入：配色是明暗双态的，需要把预设表同时给到两半侧；现在只在插件加载后即时应用（会有极短的默认配色过渡）。