Issue 转 PR 演示仓 yintaocheng/dsh-github-harness-demo

dsh-github-harness-demo

这是 dsh-github-harness 插件的独立目标项目，不是插件源码，也不是另一个安装包。任务、代码变更和具体执行证据放在这里；安装与通用配置请看插件主仓库。

2026-10-04 的具体演示

所有任务都由独立 DSH headless 会话实际执行，随后由可信 harness 另外运行 node --test test/.test.mjs，成功后才发布。下列数字来自对应提交的独立验收，不是模型口述：

| 任务 / 阶段 | 实际交付 | 验收 | 提交与审查 |
| Issue #1，v0.2.0 首轮 | parseIssueReference 解析 owner/repo#N；拒绝非法类型、空白、路径和编号 | 9 tests / 9 pass / 0 fail | 006bdd0 → PR #2 |
| 同一任务升级到 v0.3.0 后续跑 | 按审查反馈增加 GitHub Issue URL 支持；拒绝外站、HTTP、凭据、端口、query/fragment 和编码路径 | 13 tests / 13 pass / 0 fail | e3fd624，仍是 PR #2 |
| Issue #3，v0.3.0 新任务 | summarizeChecks 汇总通过/失败数量；验证输入类型与不修改输入 | 11 tests / 11 pass / 0 fail | 4882a95 → PR #4 |

这些是三个不同执行阶段，不能把 9、13、11 相加当作一个版本的测试总数。它们都包含一个基线测试，且对应准确 head 的 GitHub CI 均成功，见完整证据。

这轮实际验证的边界

- 插件源码留在另一个仓库，执行目录是本仓库，没有把插件复制进目标项目。
- 第一个任务从 v0.2.0 升级到 v0.3.0，并把执行者标识从 solo 改为 executor-b，仍复用原会话、旧分支和 PR #2。这里验证的是标识更改兼容，不是多个智能体协作。
- 第二个任务使用另一条分支、另一会话和 PR #4，没有借用第一个任务的代码或会话。
- 安装后的同一个 Host 工具还读取了两个不同仓库的 Issue #1，任务 key 与会话不同，进程 cwd 未改变。
- 两个演示 PR 均未合并。不自动 approve、投票或 merge，也没有给智能体授予仓库权限。

查看成果或复现

main 只保留目标项目基线和演示说明；成果保留在 PR，所以直接在 main 执行测试得到 1 个基线测试，不是上表的 PR 分支结果。

例如只读检出 Issue #1 的最终提交进行验证：

git fetch origin
git switch --detach e3fd624339d706690c376d4a674504f7b23802cd
node --test test/.test.mjs
git switch main

要自己运行 harness：

1. 按插件说明安装固定版本。
2. Fork 本仓库并准备本地 checkout；按需要启用 Fork 的 Issues / Actions。
3. 修改目标 owner/repo、实际 GitHub 操作身份及本地模型配置，确保 origin 指向自己的 Fork；不要提交 token。
4. 创建自己的任务 Issue，要求 github_harness 对该目录和 Issue执行。不要向本演示仓库发布你的测试任务。

证据与许可证

- 本轮逐项证据、固定 SHA、会话与 CI
- 机器可读记录
- 分离前的历史验证：原插件仓库的旧 Issue/PR 保留原址，没有转移或改写历史。
- MIT 许可证

智能体内部曾报告标准 Node 测试受到 spawn EPERM 限制；外层 harness 随后按原验收命令成功执行并绑定提交树。发布依据是外层退出码和验证记录，不是智能体自述。 没有为了演示关闭权限保护或弱化验收命令。