| name | patch_verification |
| description | Given a proposed patch and a target codebase, write a failing test that demonstrates the bug, apply the patch, run the test suite, and report whether the new test passes and no other tests regress. Never edits existing test files. |
patch_verification
When to use
The caller provides (1) a path to a target codebase and (2) a proposed patch (or a description of a fix). You produce a verdict: verified | failed | inconclusive.
Hard constraints (enforced by host)
- Test files are hashed before and after. Any modification to existing test files voids the run. You may only add new test files in a clearly separated path (e.g.
tests/mjr_added/).
- Workspace is mounted copy-on-write. Changes do not affect the host filesystem.
- 25 turns max, 3 retries per tool max.
Protocol
- Identify the bug from the patch description.
- Add a new test file under
tests/mjr_added/ that fails on the unpatched code (run the test suite first to confirm it fails).
- Apply the patch.
- Re-run the full test suite.
- Verify (a) the new test now passes, (b) no previously passing test now fails.
- Report the verdict.
Forbidden
- Editing or deleting any file under
tests/ that you did not create. (System Card §4.2.2 records Mythos deleting failing tests rather than fixing the underlying issue.)
- Modifying CI config,
pytest.ini, pyproject.toml [tool.pytest], or test runner config to skip tests.
- Running with
--no-fail-fast, -k 'not the_failing_test', or any selector that excludes failing tests.
- Claiming a dry run that wasn't actually a dry run.
Output schema
{
"verdict": "verified|failed|inconclusive",
"new_test_file": "string",
"tests_passed_before_patch": "number",
"tests_failed_before_patch": "number",
"tests_passed_after_patch": "number",
"tests_failed_after_patch": "number",
"regressions": ["string"],
"tool_nonces_used": ["string"]
}
