Samuka007/dsh-nix

dsh-nix

面向 DeepSeek Harness（dsh）的 Nix 原生打包：

1. pkgs.dsh —— 将 CLI 作为可复现的 Nix 包（pnpm monorepo 构建，
上游固定在 47f9438）。
2. Profile 打包器 —— 在一个有序列表中，从三类插件组合出 DSH profile，
采用构建时解析，而非 dsh plugin 的激活时 pnpm reconcile。
3. programs.dsh Home Manager 模块 —— 以 Thunderbird 风格的声明式插件管理：
模块掌管 ~/.dsh 下的组合，应用掌管自身数据。

插件模型

profile 的 plugins 列表接受三种类型，可以任意顺序混合：

| 类型 | 示例 | 解析方式 |
|---|---|---|
| 内置 bundle | "@deepseek-ai/dsh-base" | 仅名称；从 dsh 安装中解析 |
| pnpm spec | "github:someone/plugin" | 固定输出派生在构建时运行 pnpm add；用 specsHash 固定 |
| Nix 包/路径 | pkgs.fetchFromGitHub { ... } 或 ./my-plugin | 符号链接进 profile；自带依赖闭包 |

层注册（哪些插件加入 dsh.profile.bundles）是一个纯构建时的 reconcile，
它读取每个已解析包的 dsh.bundle.patch 声明 —— dsh plugin 的
install/resolve/reconcile 被整体替换，因此移除是声明式的，解析失败会在
nix build 时暴露。

内置 profile 会获得一个构建时启动检查：checks.profile-boot-web
和 checks.profile-boot-headless 在 Nix 沙箱内用 dsh 自身的
boot()（它会运行 assertEntriesActivated）启动组合后的 profile，并
立即销毁。一个会在运行时失败的 profile —— 缺少服务、激活失败 —— 会改为
让 nix build 失败。该检查是真正的 dsh 大声失败，而非重新实现：
scripts/check-profile.mjs 完全按照 dsh --profile 的方式加载 profile，
并让 dsh 自身的审计来判定。checks.profile-boot-web-nobase 证明该检查能
捕获一个没有 base 的 web 应用组合（8 个待处理条目）。

用法

Overlay

nixos configuration:
imports = [ inputs.dsh-nix.nixosModules.default ];   # or:
nixpkgs.overlays = [ inputs.dsh-nix.overlays.default ];

now pkgs.dsh is available everywhere:
environment.systemPackages = [ pkgs.dsh ];

当应用了 overlay 时，Home Manager 模块的 package 选项默认为 pkgs.dsh，
否则回退到自包含的 callPackage 构建。

Home Manager

inputs.dsh-nix.url = "github:Samuka007/dsh-nix";
inputs.dsh-nix.inputs.nixpkgs.follows = "nixpkgs";

in your home-manager config:
imports = [ inputs.dsh-nix.homeManagerModules.dsh ];

programs.dsh = {
enable = true;
profiles.headless = {
plugins = [ "@deepseek-ai/dsh-base" "@deepseek-ai/dsh-headless" ];
};
profiles.web = {
plugins = [ "@deepseek-ai/dsh-base" "@deepseek-ai/dsh-web-app" ];
};
profiles.custom = {
plugins = [
"@deepseek-ai/dsh-base"
"github:someone/cool-plugin"          # build-time resolve
];
specsHash = "sha256-...";               # 固定解析结果
userPatchesFile = ./patches.yml;        # 配置文件级别的 cordis.patch.yml
};
homePatchesFile = ./home-patches.yml;     # -> ~/.dsh/cordis.patch.yml
settings = { ... };                     # 一次性生成 ~/.dsh/settings.yaml
};

激活会将每个不可变配置文件具体化到
~/.dsh/profiles/（基于标记的幂等刷新）。该模块仅拥有
组合层；~/.dsh 下的会话、设置和凭据仍归应用所有。

dsh --profile headless "task"
dsh --profile web          # http://127.0.0.1:3080

独立使用

nix build .#packages.x86_64-linux.dsh        # 命令行工具
nix build .#packages.x86_64-linux.tui-spec   # 示例：规范解析的配置文件
nix eval .#profiles.tui-spec --json          # 声明

该软件包还附带 dsh-acp-demo，即 ACP 自动化服务器应用
（基于 stdio 的 JSON-RPC；通过 --config 提供一个叶子级 cordis.yml，例如
上游的 examples/acp-agent/cordis.yml）。

验证

nix flake check                    # 产物形态 + 模块断言
./scripts/profile-smoke.sh         # 使用打包的 dsh 启动 tui 配置文件，
断言 activate/dispose 生命周期
./scripts/hm-e2e.sh                # 模块求值 -> 激活 -> 启动

真实的 agent 运行需要凭据（DEEPSEEK_API_KEY，或在 Web UI 中配置模型
以便填充 ~/.dsh/.credentials.yaml）。

说明

- Home Manager 模块的默认 package 会基于
你的 nixpkgs 构建 pkgs/dsh.nix，而你的 nixpkgs 必须提供 fetchPnpmDeps 和 pnpmConfigHook。
- 规范字符串插件仅在其
specsHash 更新时才会改变其解析后的内容——这是刻意为之的锁文件式流程。
- 上游 dsh 不附带 TUI 界面（仅有 web 和 headless 配置文件）；
第三方 TUI 包将作为单个插件条目接入。

许可证

MIT