龟壳终端界面 turtle1999/turtle-ui

Turtle UI

dsh 在一个周五下午诞生的第一个 UI

本仓库包含原先的 packages/ui/tui 实现、其单元测试与终端快照测试，以及一个 dsh profile bundle 补丁。TUI 负责终端呈现与输入；DeepSeek Harness 负责 agent、模型、工具、持久化和 dsh 启动器。

开发

将本仓库与 DeepSeek Harness 保持为同级目录：

~/git/deepseek-harness
~/git/turtle-ui

安装并构建同级的 Harness，然后构建 Turtle UI：

(cd ../deepseek-harness && pnpm install && pnpm run build)
pnpm install
pnpm run build

peer API 来自同级的 Harness 检出。独立的 TypeScript 与 Vitest 配置有意通过 ../deepseek-harness 解析这些源码；Vitest 使用 Harness 构建产物作为 goal host 模块，而不是将该源码模块与传递依赖的已构建包混用。打过补丁的 @earendil-works/pi-tui 是一个 devDependency，在构建时被打包进 lib/，因此使用者无需安装 pi-tui，也无需 patchedDependencies。

运行

Turtle UI 是一个 dsh profile bundle：其 package.json 声明了 "dsh": { "bundle": { "patch": "./cordis.patch.yml" } }，因此将其安装到某个 profile 时会自动激活补丁层。

从本地检出构建并安装一个复制后的 file: 包，使其 Harness peer 通过该 profile 的托管回退解析。重新构建后需再次执行 add 以刷新副本：

pnpm run build
dsh plugin --profile tui add file:.
dsh --profile tui

从 git 安装、无需检出：prepare 脚本会在安装过程中在使用者的机器上转译 lib/。pnpm ≥10 会阻止该构建，直到你允许它，因此第一次 add 会失败并给出 allowBuilds 提示；将 pnpm 打印出的确切键复制到该 profile 的 pnpm-workspace.yaml 中并重新运行：

dsh plugin --profile tui add github:deepseek-harness/turtle-ui # fails with the allowBuilds key
add the printed key under allowBuilds in ~/.dsh/profiles/tui/pnpm-workspace.yaml
dsh plugin --profile tui add github:deepseek-harness/turtle-ui # builds and activates
dsh --profile tui

prepare 构建（tsdown.prepare.config.ts）在转译时不进行类型检查——本仓库的类型图需要同级的 harness 检出，而使用者没有该检出。在同级检出环境中运行 pnpm run typecheck 仍是类型检查的门槛。
该 bundle 层运行在 @deepseek-ai/dsh-base 之上，并将 TUI 和已配置的 agent 绑定到一个持久会话。普通的 tui-startup provider 会注入启动器不可变的 ctx.cmdlineArgs，解析 --resume、--session 以及此应用的 --help，然后提供 tuiStartup；会话绑定的行会注入该服务并从惰性配置中读取它，因此它们无法在错误的会话上激活。裸的 dsh --profile tui 会在每次启动时生成一个新的会话 id，--session 显式指定一个新会话，而 --resume 会继续一个已持久化的会话。应用内的 /resume 交接和退出消息行为仍然需要已移除的 TUI 专用启动器，因此仍不可用。

检查

pnpm run typecheck
pnpm test
pnpm run build