DeepSeek Harness 怎么做 GitHub 代码评审？DSH plugin webhook 与会话

DeepSeek Harness 的 github-review overlay 给 dsh web 加一个签名 GitHub 端点：当已配置仓库的 pull request 从 draft 变为 ready for review 时，规则会在该仓库的 Web Workspace 下创建带标题的根 Session，并启动只读评审提示词——默认监听 127.0.0.1:3081，密钥走 DSH_GITHUB_WEBHOOK_SECRET（来源）。

DeepSeek Harness GitHub 评审 overlay 是什么、要准备什么

这是一个可选 overlay，把「PR 转正式评审」这个事件变成一次自动的只读代码评审会话；要跑起来得先备好四项前置（来源）。 逐项确认：

1. 本地 checkout — 准备一个能被 DeepSeek Harness 注册为 Web Workspace 的仓库目录。预期：overlay 默认用启动目录当 Workspace，你也可以显式指定。
2. 高熵 webhook 密钥 — 生成一个密钥并以 DSH_GITHUB_WEBHOOK_SECRET 凭据引用访问。预期：GitHub 侧的 Secret 与它填同一个值。
3. 公网入口 — 准备一个能把单个公共 URL 转发到 loopback 监听器的 TLS 反向代理或 tunnel。预期：GitHub 能访问到你的 /github 端点。
4. GitHub 侧订阅 — webhook 订阅 Pull requests 事件，content type 选 application/json。预期：只有 PR 相关事件会被推送过来。

评审会读代码、也可能用到插件能力。想先给评审会话加点插件（比如 skills 或工具类），可以从 DSH Plugin Hub 浏览社区插件，再按下面把它并进同一个 profile。

生成密钥、启动 DeepSeek Harness 并暴露 /github 端点

先生成并固定密钥，再用 --patch 加载 overlay 启动；主 Web UI 与 /api 仍在 3080，overlay 另挂一个只注册 POST /github 的监听器（来源）。 步骤：

1. 生成并保存密钥 — 执行 export DSH_GITHUB_WEBHOOK_SECRET="$(openssl rand -hex 32)"，并用 printf '%s\n' "$DSH_GITHUB_WEBHOOK_SECRET" 打印出来，重启后继续用同一个值。预期：密钥固定，签名校验才稳定。
2. 在开发 checkout 里启动 — 设 DSH_GITHUB_REVIEW_WORKSPACE 指向仓库，再执行 pnpm dsh web --patch apps/cli/config/examples/github-review/cordis.yml。预期：overlay 被加载，监听 3081。
3. 安装版用绝对路径 — 直接 dsh web --patch /absolute/path/to/github-review/cordis.yml。预期：效果与开发 checkout 一致。
4. 做永久 profile — 把 github-ready-review-rule.mjs 放到 $DSH_HOME/profiles/web/cordis.patch.yml 旁边，把 cordis.yml 里需要的行追加进该 patch，然后直接 dsh web。预期：随附 CLI 已包含两个 webhook 包，只需 overlay 激活。
5. 暴露端点 — overlay 在隔离 realm 里挂第二个 WebServer，只注册 POST /github、其他路径返回 404。用反向代理只放行该路径，例如 Caddy：

hooks.example.com {
  route {
    @github path /github
    reverse_proxy @github 127.0.0.1:3081
    respond 404
  }
}

6. 填 GitHub webhook — Payload URL 填 https://hooks.example.com/github，Content type 选 application/json，Secret 填上一步的密钥值，Events 选 Pull requests，Active 打开。预期：GitHub 侧配置就绪。

DeepSeek Harness GitHub 评审的规则行为与交付语义

规则只接受来源 primary-github、仓库 deepseek-harness/deepseek-harness、事件 pull_request 与动作 ready_for_review；它把精确 head SHA 与选定 PR 字段传给评审提示词，禁止改文件、分支、PR 或 GitHub 状态（来源）。 关键点：

1. 会话参数是只读的 — Session 请求选择 standard agent preset 与 read-only permission preset。预期：评审只读不写，不会动你的代码。
2. 工作区被规范化 — workspacePath 通过 WorkspaceRegistry.create() 规范化，第一次匹配交付会在 Workspace 不存在时创建它，后续交付复用。预期：同一仓库稳定落到同一工作区。
3. 202 不等于成功建会话 — HTTP 响应刻意弱于 Agent 结果：202 只表示签名与 JSON 已被接受、规则调用已在内存中调度。预期：别把 202 当成「已创建 Session」。
4. 交付无状态 — webhook runtime 不存储交付或执行状态，重复交付可能创建另一个 Session；崩溃会丢失尚未接纳提示词的规则调用。预期：提示词接纳后，工作才由普通 Session 日志、persistence、Workspace 与 Agent 生命周期拥有。
5. 可程序化扩展 — run() 是普通受信任 JavaScript，可在返回 Session 请求前查询内部策略服务，或把仓库名映射到不同本地路径。预期：适合接入企业自己的评审策略。

注意事项与常见问题

1. 密钥只管入站：DSH_GITHUB_WEBHOOK_SECRET 只验证来自 GitHub 的数据，不会向规则代码或所创建的 Agent 授予出站 GitHub 访问权；需要时单独配置。
2. 小心重复触发：无状态设计意味着同一次交付重发就可能多一个会话，留意 GitHub 的重投递。
3. 端口别冲突：3080 是主 Web UI，3081 是评审 overlay；换端口用 DSH_GITHUB_WEBHOOK_PORT。
4. 会话日志与数据位置：评审产生的会话同样落在会话存储里，查阅见《DeepSeek Harness 会话记录在哪、怎么查》。
5. 网络出不去：如果你的 DeepSeek Harness 在被代理的网络里，webhook 与模型调用都要过代理，见《DeepSeek Harness 怎么配网络代理》。

来源：通过 GitHub Webhook 创建评审会话（官方文档）、dsh CLI README（官方仓库）