配置档核心套件 Vensus137/Coreness-DSH

DeepSeek Harness 的 Coreness

给 DeepSeek Harness 配置档一张脸、一段记忆和一副刹车。

Coreness 是一个包，配置档靠它活着。它给配置档在应用里开一页自己的页面，记录配置档和它的会话做了什么，给配置档的 MCP 服务器一张脸，拦住服务商本来会拒绝的请求，再给 Qoder 模型加一条路由。

装完就能用：浏览器加载的那部分就是普通文件，放在哪就从哪提供——不构建，不编译，装的是什么跑的就是什么。

⚡ 安装

应用自己装插件。 Plugins → Add plugin 接受包名、tarball、git 地址或本地路径，包会装进应用正在运行的配置档——桌面应用和网页端走同一扇门，不用指定配置档：

github:Vensus137/Coreness-DSH

同一个页面可以把包关掉而不删除，也可以再卸掉。

这个地址跟着最新 release 走，而发布出来的就是 release——所以在这里，地址和最新 release 是一回事。固定某个 release 就用它自己的 tag——…Coreness-DSH#v0.3.0——已发布的 tag 永不移动：那行代码无论何时运行，拿到的都是同一份。

用命令行 —— 给终端用的；上面的步骤都不需要它

这行命令可以直接跑，因为桌面应用自己的配置档就叫这个名字：

dsh plugin --profile desktop add github:Vensus137/Coreness-DSH

其他配置档就写它自己的名字——网页端的是 web——指定一个还不存在的配置档会把它创建出来。

dsh 是应用自带的命令，Windows 和 macOS 都不带，所以在应用把它放进 PATH 之前，终端只会回一句 not recognized。应用从自己的菜单里做这件事：窗口标题栏里应用图标旁边，Application → Manage dsh Command…——对话框会显示它管理的位置，同一个对话框也能把命令从 PATH 里拿掉。在那之前打开的终端还是用它启动时的 PATH，所以之后要新开一个。

配置档的组成在应用启动时读取，所以包要到下次启动才生效，平台自己会说明它做的改动什么时候需要重启。装进来的时候不构建任何东西，也不申请安装脚本的权限：包就是普通文件，安装只取 manifest 里写的目录，别的都不碰，地址走应用本来就在用的网络去取，不用 git 客户端——没装 git 的机器也能装上。

✨ 配置档能得到什么

- 🗂 自己的一页 —— 配置档的概览：它带着什么，哪些 bundle 和行是开着的、哪些是关的，以及会话或插件必须被告知的设置。
- 🔌 看得见、改得了的 MCP 服务器 — 每台服务器一张卡片：类型、地址、需要的环境，还有几个开关，拨动后生效的是配置档本身，而不是副本。
- 📓 日志 — 环境的记忆：配置档里改了什么、某个参与者做了什么，都留成记录，每条带着类型、区域、名称和作者。
- 🚦 会排队、不会拒绝的限流器 — 超出限额的调用去队列里排队；包刚发布时，什么都不限。
- 🧠 通往 Qoder 模型的路 — 账号自己的模型，每个都带着它接受的推理档位和允许的输出预算。账号的 token 只在页面上填一次，由平台自己的存储保管；包里不留它的任何值。
- 📜 它自己那棵树的规则，始终生效 — 一个提示词段落，通过平台自己的提示词注册表注册，从 plugins/rules/section.md 读取，所以配置档的每个会话都会在每次请求里带上它们，任何压缩都拿不走，模型始终看得见。每次请求都要为它们付费 —— 按平台自己的算法是 243 tokens —— 不想要它们的配置档，把这一行从 bundle 里删掉即可。

🧩 它需要什么

- DeepSeek Harness。 这个包构建时对应的版本写在 manifest 里，配置档导入插件之前，应用会拿这份声明和自己的版本比对：对不上就不导入该插件，并明确说明，而不是之后悄悄失败。

📦 会落地什么

就是包的 manifest 里列出的那些 —— 装配件和插件，每个的代码旁边都有自己的 README。构建它们的工作间不留任何部分：本项目的契约、检查项和笔记都留在干活的地方 —— 只有一个刻意的例外，就是这棵树想要生效的那段规则，它随包发布，因为一条必须生效的规则，没有别的结构上安全的容身之处。

🧭 它刻意不做什么

- 它不是通往平台自身操作的第二个入口：启用、停用、安装、卸载都归应用的 Plugins 页面，这个包只报告现状，不与它争。
- 它不管 MCP 那一侧：服务器、连接和注册表归平台，这个包只管画面和表单。
- 没有声明限额之前，它什么都不限。

📄 License

MIT。