Mkl Verify Fix

---
name: "mkl-verify-fix"
description: "Verify a proposed bug fix against an unchanged regression test and the relevant existing tests, reporting baseline and candidate outcomes separately. Use for fix verification, not a general claim that software is bug-free."
---

# Verify a fix with comparable evidence

Identify the baseline revision, candidate revision, regression test, and expected behavior. If any is unavailable, narrow the conclusion instead of inventing missing evidence.

Use equivalent environments and identical test inputs for both versions. Keep the regression test and expected result outside the changes under evaluation or otherwise verify that they are unchanged. Inspect which source file the test actually imports; an installed package can hide the checkout being tested.

Check the baseline first. Distinguish an expected assertion failure from setup, import, collection, timeout, and execution errors. Then run the same test against the candidate and run existing tests appropriate to the affected behavior. Prefer token-efficient runners: `pytest -q --tb=short -x` or `python3 tools/test_fast.py` (unittest: `python3 -m unittest discover -s tests -q -f`; Node: `npm test -- --bail --silent`; Rust: `cargo test -- --nocapture=false`).

Report:

- Baseline and candidate identifiers and commands.
- The observed reason for the baseline failure.
- The candidate result and any relevant existing-test results.
- Environment differences, instability, and checks not performed.

Conclude "verified for this reproduction" only when the test fails for the reported behavioral reason on the baseline and passes on the candidate. A test that passes on both versions does not establish that it detects this regression. Avoid broad correctness or security claims from a small test suite.

If the candidate fails, report the evidence and return it to the implementer. Do not silently edit the verifier or loosen tolerances.