reprocheck

reprocheck

「修正済み」は主張です。reprocheck を使えば、まず失敗することを示して証明できます。

すべてのバグ修正は、同じ主張をします。この変更でそのバグが修正される、という主張です。誠実な証明には決まった形があり、優れたレビュー担当者が求めるのもその形です。つまり、修正前のコードでは失敗し、修正後のコードでは成功する再現テストです。どちらのコードでも成功するテストは、何も証明しません。再現テストがまだ失敗するなら、修正できていません。そして、成功していた再現テストを失敗させる変更は、何かを壊しています。

reprocheck は、その証明を代わりに実行します。リポジトリ、ベースの参照、ヘッドの参照、コマンドを指定すると、両方の参照からクリーンなデタッチドワークツリーを作成して、それぞれでコマンドを実行し、終了コードの組み合わせを判定します。

判定	ベース	ヘッド	意味
VERIFIED	失敗	成功	この変更は再現テストが示す問題を修正しており、再現テストがバグを対象としていることも実証されています
NOT-REPRODUCED	成功	成功	ベースでは再現テストでバグを実証できないため（すでに修正済みか、バグを捉えられていません）、ヘッドで成功しても何も証明されません
STILL-FAILING	失敗	失敗	この変更では、再現テストが示す問題は修正されません
BROKEN-BY-HEAD	成功	失敗	この変更によって、この失敗が発生しました
ERROR	該当なし	該当なし	セットアップ、git、または実行自体が失敗またはタイムアウトしました。レポートに該当するステージが記載されます

終了コードは CI で使いやすく、VERIFIED は 0、それ以外の完了した判定は 1、ERROR は 2 です。

実用性を高める機能：--test-file

標準的な「まず失敗させる」セットアップには、厄介な手順があります。回帰テストは新規作成されるため、ベースには存在しません。ベースのチェックアウトに手作業でコピーするのは、まさに省略されがちな手順です。reprocheck が代わりに行います。--test-file <path> を渡すと、コミット済みかどうかにかかわらず、作業ツリーから読み込んだファイルを、コマンドの実行前に同じ相対パスで両方のワークツリーにコピーします。

作業ツリーが変更されることはありません。どちらの実行も OS の一時ディレクトリ内に作成された一時ワークツリーで行われ、どの終了経路でも削除されます。

ネイティブランナー：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"、判定、ランナー、および参照、SHA、終了コード、結果（pass、fail、または did-not-run）、タイムアウトフラグ、所要時間を含む red（ベース）と green（ヘッド）のブロックを持ちます。--receipt <path> を指定すると証跡のみをファイルに書き出せます。たとえば、PR の説明や CI の成果物に添付できます。証跡は要約ではなく証拠です。判定の根拠となった2回の実行を正確に記録します。

使い方

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

出力例（実際の dogfood で、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 は、同じ作者による 3 つのツールからなる小さな組み合わせのうち、検証を担います。

• cidiff は、PR で失敗しているチェックのうち、実際に PR が原因のものを特定します。
• reprocheck は、特定の修正が特定のバグを直すことを、まず失敗を確認してから証明します。
• shipcheck は、完成したリリースがあらゆる環境に実際にリリースされたことを検証します。

この 3 つはすべて、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