reprocheck

reprocheck

“已修复”是一种声明。reprocheck 要你拿出证据，而且先让测试变红。

每个 Bug 修复都在作出同一个声明：这项更改修复了那个 Bug。可信的证明有特定形式，也是优秀的评审者会要求的形式：一个在修复前的代码上失败、在修复后的代码上通过的复现测试。在两边都通过的测试证明不了任何事。复现测试仍然失败的修复，什么也没修好。而让原本通过的复现测试变红的更改，则破坏了某些东西。

reprocheck 会为你运行这项证明。提供一个仓库、一个基础 ref、一个头部 ref 和一条命令。它会为两个 ref 分别创建干净的分离式工作树，在各自的工作树中运行命令，并根据两次退出码对结果进行分类：

结论	基础 ref	头部 ref	含义
VERIFIED	失败	通过	这项更改修复了复现测试所展示的问题，而且复现测试确实覆盖了该 Bug
NOT-REPRODUCED	通过	通过	复现测试未能展示基础 ref 上的 Bug（该 Bug 在那里已修复，或者测试未覆盖该 Bug），因此头部 ref 上的通过毫无证明力
STILL-FAILING	失败	失败	这项更改没有修复复现测试所展示的问题
BROKEN-BY-HEAD	通过	失败	这项更改引入了这个故障
ERROR	不适用	不适用	设置、Git 或运行本身失败或超时；报告会指出具体阶段

退出码适用于 CI：VERIFIED 为 0，其他已完成的结论为 1，ERROR 为 2。

让它切实可用的功能：--test-file

标准的先红后绿流程有个不太方便的步骤：回归测试是新写的，因此在基础 ref 上并不存在。手动将它复制到基础检出目录，恰恰是人们容易跳过的步骤。reprocheck 会替你完成：传入 --test-file <path>，它就会从你的工作树中读取该文件（无论是否已提交），并在命令运行前将其复制到两个工作树中相同的相对路径。

你的工作树绝不会被修改。两次运行都会在操作系统临时目录下的临时工作树中进行，无论以何种方式退出，临时工作树都会被删除。

原生运行器：pytest 和 Go

对于 Python 或 Go 仓库，你不必手动编写测试命令。传入 --runner pytest、--runner go 或 --runner auto，reprocheck 就会检测仓库的测试设置，构建实际命令，并在两个工作树中运行：

• pytest 检测：存在 pytest 配置（pytest.ini、pyproject.toml、setup.cfg、tox.ini）或 test_*.py / *_test.py 文件。命令为 python3 -m pytest '<file>::<test name>' -q（未指定名称时运行文件或整个测试套件）。
• Go 检测：存在 go.mod 文件或 *_test.go 文件。命令为 go test <package> -run '^<TestName>$' -count=1 -v，其中 -count=1 可确保 Go 测试缓存绝不会把过期的通过结果当作证据。
• --test-name <name> 可指定一个名称对应的测试（pytest 使用 test_add，Go 使用 TestAdd）。检测会查找定义该测试的文件。
• 如果指定了错误的运行器、测试文件属于另一种运行器、测试名称不存在，或者仓库中完全没有测试，那么在运行任何内容之前就会报出对应的具体错误。不会将任何结果勉强归入它本不应得到的结论。
• reprocheck detect --repo <path>（或 MCP detect_test_runners 工具）会报告检测到的运行器及每个运行器对应的文件系统证据，不会运行任何目标代码。

# Python: one named pytest test, red on main and green on HEAD
npx @reneturcios/reprocheck run --repo . --base main --head HEAD \
  --runner pytest --test-file test_calc.py --test-name test_add

# Go: one named test, package inferred from the test file
npx @reneturcios/reprocheck run --repo . --base main --head HEAD \
  --runner go --test-file calc_test.go --test-name TestAdd

# See what a repo supports before choosing
npx @reneturcios/reprocheck detect --repo . --json

回执

每份报告都会附带机器可读的红/绿回执：--json 输出中的 receipt，包含 schemaVersion: 1、kind: "reprocheck.receipt"、结论、运行器，以及 red（基础 ref）和 green（头部 ref）区块；每个区块都包含 ref、SHA、退出码、结果（pass、fail 或 did-not-run）、超时标记和运行时长。使用 --receipt <path> 可将回执单独写入文件，例如将其附加到 PR 描述或 CI 产物中。回执是证据，不是摘要：它会准确记录结论所依据的两次运行。

用法

CLI

# Verify a fix on the current branch against main, using the new regression test
npx @reneturcios/reprocheck run \
  --repo . --base main --head HEAD \
  --test-file test/radar.test.ts \
  --setup "npm install" \
  --cmd "npx tsx --test test/radar.test.ts"

# Simpler: a committed repro script, no setup
npx @reneturcios/reprocheck run --repo . --base HEAD~1 --head HEAD --cmd "node repro.mjs"

# Machine readable output, with the receipt written to a file
npx @reneturcios/reprocheck run --repo . --base main --head HEAD --cmd "npm test" --json --receipt receipt.json

示例输出（实际项目中的真实验证：验证 Greenlight v0.15.1 的雷达精度修复，其中 test/radar.test.ts 中的回归测试是按照修复后的行为编写的）：

reprocheck: VERIFIED
  command: npx tsx --test test/radar.test.ts
  test file copied into both worktrees: test/radar.test.ts
  setup: npm install --no-audit --no-fund
  base (a33c55e3 @ a33c55e39010): exit 1 in 18512ms
  head (9492844b @ 9492844bf6b6): exit 0 in 12015ms
The repro fails on the base and passes on the head. The change fixes what the repro demonstrates, and the repro demonstrably covers the bug

MCP 服务

添加到 MCP 客户端配置中：

{
  "mcpServers": {
    "reprocheck": {
      "command": "npx",
      "args": ["-y", "@reneturcios/reprocheck", "mcp"]
    }
  }
}

工具：run_repro_check（repoPath、baseRef、headRef，以及原始命令或 pytest、go、auto 的原生 runner；还可选填 testFile、testName、setupCommand 和 timeoutSeconds；以 JSON 格式返回完整报告，包括收据、各阶段的退出代码、耗时和输出末尾内容）和 detect_test_runners（repoPath；返回检测到的原生运行器及其依据和测试文件）。

Docker

CLI 可在本地 git 仓库上运行，因此请挂载要检查的仓库：

docker run -i ghcr.io/cloudcorprecords/reprocheck mcp
docker run --rm -v "$PWD:/repo" ghcr.io/cloudcorprecords/reprocheck \
  run --repo /repo --base main --head HEAD --cmd "npm test"

reprocheck 的定位

reprocheck 是同一作者打造的小型三件套中的验证环节：

• cidiff 会告诉你 PR 中哪些失败检查确实是由该 PR 引起的。
• reprocheck 会先让测试失败，再证明特定修复确实修复了特定漏洞。
• shipcheck 会验证已完成的发布确实在每个渠道上发布。

这三款工具都秉持同一套准则，也就是运行 Greenlight 的准则：证据优先、如实判定、不编造答案。对于 reprocheck 无法支持的判定，它不会输出。

开发

npm install
npm run build
npm test   # 27 tests: verdict classification, full runs against a real temp git repo, and native pytest / go runner detection, command building, and end to end fixture runs through the real binaries (skipped when a binary is unavailable)

许可证

MIT