elmersky/dsh-plugin-trellis-workflow

dsh-plugin-trellis-workflow

为 DeepSeek Harness（dsh）提供 Trellis 工作流强制执行：每轮工作流状态注入，外加一个 trellis-start 入口门禁，用以替代 dsh 未提供的 session-start 和 user-prompt 钩子。

它填补的空白

Trellis 将 dsh 归类为 class-2 拉取式平台，并带有 hasHooks: false。它会写入技能和脚本，但没有 SessionStart 钩子，也没有 UserPromptSubmit 钩子。在 dsh 上这意味着：

- 没有任何东西提醒 agent 当前有 Trellis 任务工作流正在生效，因此除非用户点名某个技能，否则工作流会被跳过；
- trellis-start 是一个用户可调用的技能，但它永远不会自行触发。

Trellis 自己生成的 .dsh/DSH.md 也是这么说的：“没有 session-start 钩子自动注入工作流上下文，因此 agent 按需加载 Trellis 技能。”

本插件用 dsh 原生机制——无需钩子——补上了缺失的通道：

| 缺失的 Trellis 通道 | 此处使用的机制 |
| --- | --- |
| SessionStart 上下文注入 | agent/created 和 agent/inbox/inserted 监听器刷新状态 |
| UserPromptSubmit 面包屑 | 一个 systemPrompt.context 贡献，其 text 是一个函数，在每个模型步骤重新求值 |
| 入口路由到 trellis-start | 渲染出的状态块本身，以 no_task 为门控条件 |

行为

- 项目感知。 从 session.header.cwd 向上遍历来解析 Trellis 项目根目录，并通过组合文件系统服务确认目录包含关系。没有 .trellis/ 的工作区完全不会获得任何注入，因此无关项目不受影响。
- 只读。 读取会话作用域的活动任务指针 .trellis/.runtime/sessions/.json，然后读取该任务的 task.json。它从不写入 .trellis/，也从不运行 shell 命令。
- 状态。 每个步骤贡献一个块：task_active（任务路径和状态）、no_task（trellis-start 入口门禁）、task_error（指针不可读）、unknown（状态无法测量）。在首次测量完成之前，它什么都不贡献，而不是凭空捏造一个状态。
- 会话隔离。 状态按会话为键，因此并发会话不会相互污染。
- 开销低。 每个会话一次缓存查找，在指针可能已移动时刷新（会话开始、新用户消息，或模型调用前的步骤）。

渲染出的块看起来像这样：

[trellis-workflow-state]
project=/path/to/trellis-project
status=task_active
task=.trellis/tasks/09-18-example
task_status=in_progress

强制路由：本任务处于 Trellis 任务流程中。
- 动手改代码前：先加载 trellis-before-dev，读 .trellis/spec/ 对应层规范。
- 改完代码：走 trellis-check。
- 收尾：走 trellis-finish-work 归档任务并写 journal。

状态来源=dsh 主机侧缓存。确切当前态：
python3 ./.trellis/scripts/task.py current --source
本平台没有 SessionStart / UserPromptSubmit hook，此块即官方面包屑的等价物。

路由文本用中文书写，以匹配目标项目的惯例；块的其余部分是语言中立的。

要求
- 已组合 systemPrompt 服务的 dsh（存在于随附的基础包中）
- 一个由 Trellis 管理的工作区（一个包含 .trellis/ 的项目）
- Node.js >= 20

安装

dsh plugin --profile  add dsh-plugin-trellis-workflow

无需编辑 profile 文件。该命令会写入依赖项，将包追加到 dsh.profile.bundles，并且 profile 启动时会将该包的 cordis.patch.yml 作为一个 insert 合并。

之后重启 profile。Node 会缓存已导入的模块，因此在编辑 src/index.js 后也需要重启。

配置

行配置在组合中设置，而不是通过设置页面：

| 键 | 默认值 | 含义 |
| --- | --- | --- |
| enabled | true | false 会保持该行挂载但不贡献任何内容 |
| contextOrder | 900 | 在提示运行时上下文中的位置；dsh 的内置项位于 110 / 115 / 120，因此此块会在沙箱、审批和委派通知之后渲染。必须是有限数字。 |

要覆盖配置，请在 profile 自己的 cordis.patch.yml 中修补该行：

- id: trellis-workflow
config:
contextOrder: 950

卸载

dsh plugin --profile  remove dsh-plugin-trellis-workflow

开发

git clone git@github.com:elmersky/dsh-plugin-trellis-workflow.git
cd dsh-plugin-trellis-workflow
npm test                                  # 冒烟测试
npm publish --dry-run                     # 检查发布载荷

将检出目录直接挂载到 profile 中。pnpm 会记录一个绝对的 file: 规范并链接该目录，因此对 src/index.js 的编辑会立即对 profile 可见——但仍需要重启才能重新加载模块：

dsh plugin --profile  add /absolute/path/to/dsh-plugin-trellis-workflow

验证实际组合的内容：

dsh --profile  --dump-config | grep -A4 trellis-workflow

预期会看到一个 # == dsh-plugin-trellis-workflow 层标记，并且恰好有一个 trellis-workflow 行。出现两行意味着仍存在一条过时的手写挂载行与本包并存。

包布局及其为何如此设计

package.json 声明了 dsh.bundle.patch，这正是使该包成为 profile bundle 而非普通依赖项的原因。同一份声明同时服务于 npm 安装和本地 file: 安装，因此发布只会改变依赖项规范——绝不会改变组合。

行 id 有意与包名相同：该行通过 profile 的 node_modules 按包名解析其模块，因此保持两者一致可以让组合后的行与依赖项行一眼就能对应起来。

提示上下文是在 ctx.inject(['systemPrompt'], scope => …) 内部注册的，
而不是直接从 apply() 注册。这不是风格问题。systemPrompt.context()
会将贡献归入属于调用上下文作用域的层，而 agent 通过合并全局层加上
沿其自身的 scope-parent 链逐层向上。profile-row 插件自身的上下文不在该链上，因此在 apply() 期间注册会把贡献存储到 agent 永远不会读取的地方：该行会激活，但不记录任何日志，也不注入任何内容。改为注入该服务则会得到一个已经按 agent 限定作用域的上下文——与 dsh 自身的 sandbox:policy 和 approval:policy 上下文所采用的路径相同。test/smoke.js 断言了注入形式，因此这里的回归会在无需重启的情况下失败。

状态

0.1.0 — 首个版本。已验证：组合可解析、模块可加载，且上述行为由 test/smoke.js 以及 systemPrompt.context 和 assemble.agent.session 的运行时契约所覆盖。尚未在公共注册表安装上验证；跟踪情况见仓库 issues。

许可证

MIT