Fix Verify

Verify — Confirm the Fix Works

Runs the test with the fix applied and reports whether the fix is effective. A fix that has to be compiled in is verified against a source build — never a nightly wheel, which cannot see local code.

Contents

• Inputs
• Shell helpers
• Step 1: Classify whether a rebuild is needed
• Step 2: Verify the fix
• Step 3: Run test
• Step 4: Lint
• Output

Inputs

• refined_command — the exact test command from fix-reproduce's output.
• PYTORCH_DIR — path to local PyTorch checkout.
• target_repo_dir — path to the checkout that holds the staged fix (same derivation rule as in fix-implement: equals PYTORCH_DIR for target_repo=pytorch, <PYTORCH_DIR>/third_party/torch-xpu-ops for target_repo=torch-xpu-ops). All git operations run against target_repo_dir. The rebuild (Step 2) still runs from PYTORCH_DIR because pip install -e . builds pytorch and pulls its submodule pin.
• changed_files — list of changed files from fix-implement's output; if any are C++/SYCL (.cpp, .h, .cu, .sycl) or CMake (CMakeLists.txt, *.cmake), a rebuild is required before running.

This skill always rebuilds if needed (Step 2) and runs the test with the fix applied (Step 3), then lints a passing result (Step 4); there are no flags to toggle any of these off.

Shell helpers

The recipes below call abort (exit non-zero with a diagnostic). It is not a shell builtin — define it once at the top of your shell, same as the orchestrators do:

abort() { echo "ABORT: $*" >&2; exit 1; }

An abort in this skill means "return CANNOT_VERIFY to the orchestrator with that message as the blocker", never "continue silently".

Step 1: Classify whether a rebuild is needed

This step only classifies; the rebuild itself happens in Step 2.

If any of changed_files are C++/SYCL (.cpp, .h, .cu, .sycl) or CMake (CMakeLists.txt, *.cmake), a rebuild is required so the fix is compiled in before the test runs. On the first rebuild (Step 2), clean the build cache and retry once if xpu-build-pytorch reports a cache-related failure. For a torch-xpu-ops fix the rebuild also needs the third_party/xpu.txt pin override that makes CMake see the fix (done in Step 2).

If all changed files are python-only, no rebuild is needed — nothing has to be compiled for the edit to take effect.

Step 2: Verify the fix

Reaching this skill means fix-reproduce already ran the test and observed the failure (the "before" state). This step rebuilds with the fix applied (when needed) and sets up for the Step 3 test run that confirms it now passes. fix-implement always leaves the fix staged; the caller may additionally have committed it onto a branch before invoking this skill. Both arrangements are accepted — do not assume either. No stash/checkout dance is needed.

Assert the tested tree is the tree that gets handed off. The caller either exports base_sha..branch (committed) or picks up git diff --cached (staged), so the fix must live entirely in one of those two places — never partly in the worktree. Before rebuilding:

# Nothing may be left in the worktree: an unstaged edit would be tested
# here but excluded from both hand-off paths. Check this first, so a fix
# that was edited but never staged reports the precise cause.
git -C "$target_repo_dir" diff --quiet || \
  { echo "FAILED reason=unstaged_changes_present"; exit 1; }

unstaged_changes_present catches a re-implement retry that edited a file without staging or amending it, which would make the tested tree differ from what the caller hands off.

All git commands here run against target_repo_dir (not PYTORCH_DIR); these can differ when target_repo == "torch-xpu-ops".

When any changed_files are C++/SYCL or CMake, the fix must be compiled in before the test (per Step 1). Python-only changes need no rebuild.

# For torch-xpu-ops fixes, point the pin at the working branch so the
# rebuild sees the fix (Commit Pin & Development Override in AGENTS.md;
# do NOT stage or commit this file).
if [ "$target_repo_dir" != "$PYTORCH_DIR" ]; then
    git -C $target_repo_dir rev-parse HEAD > $PYTORCH_DIR/third_party/xpu.txt
fi
# Rebuild WITH the fix (only if C++/SYCL or CMake changed):
#   invoke xpu-build-pytorch skill here
# Then run the test in Step 3; its result is the "after" output.

Confirm the tree under test is the source build. A fix that the running interpreter does not pick up cannot be verified. Checking torch.version.git_version is NOT sufficient: released and nightly wheels also carry a real commit hash. Check where torch is imported from:

python -c "import torch, os; print(os.path.realpath(torch.__file__))"

• A rebuild was required (C++/SYCL/CMake): the printed path must be under $(realpath $PYTORCH_DIR)/torch/ — the rebuild above is what produces that source build. If it still resolves into site-packages of an unrelated prefix, the rebuild did not take effect: return CANNOT_VERIFY(reason=wheel_install_not_source) with blocker="torch imported from <path>; verify requires a source build".
• No rebuild was required (python-only): a wheel install is fine for files the interpreter reads from the checkout (test files, skip lists), which is where python-only fixes normally live. A python fix inside the installed package (torch/) is not picked up by a wheel — same CANNOT_VERIFY(reason=wheel_install_not_source).

The "before" cell of the comparison table (Output section) is filled from fix-reproduce's recorded failure, not re-run here; "after" is the result from Step 3 with the fix applied. The two come from different phases (reproduce may have run against a nightly wheel, verify against the rebuilt tree), so the table is a before-fix-vs-after-fix summary, not a single-build A/B.

Caveat (read before trusting a PASSED verdict): because the "before" is a nightly-wheel failure and the "after" is a source build with the fix, a PASSED verdict means "the test passes on a source build that includes the fix" — it does not prove the fix is what made it pass. If the bug was already resolved upstream after the nightly was cut, the source build passes regardless of the fix. This skill does not re-run the source build without the fix to rule that out (that would cost a second cold build). State this limitation in the report; a human reviewing the patch should confirm the change is actually responsible.