If the Patch Authored the Test, Score the Overlap

In software development, tests are not evidence of a successful implementation. If an agent writes a production hunk and assertions are included in a single pass, a green build does not necessarily mean that the public contract is being met. It is essential to score the overlap between production code and test code before rewriting the oracle in a session that does not have access to the patch.

This approach is not a flake policy or a fixture lock; it is a gate that asks whether a test is independent. A stable, overlapping oracle is worse than a noisy one because it fails closed on the wrong question. The failure mode occurs when agents patch the code in a repeatable way, and the model emits the source file and the corresponding test file together.

Shared literals appear in both the production code and the test code, such as the same timeout, error substring, and a sentinel UUID. The test does not probe the API; it merely echoes the implementation. A second pattern is more subtle, where the production function grows an extra branch to satisfy a comment in the test. While coverage may increase, the behavior for real callers does not change.

Token overlap can catch the first pattern, while literal mutation combined with an isolated oracle session can detect the second. Both scenarios should be treated as merge smells. It is crucial not to treat a passing Pytest run as a property of the code. Instead, use an artifact that combines the overlap score and literal mutation as a proposed pre-merge check.

This gate is not based on a published benchmark and has not been tested against a private corpus. Label it as a method rather than a result.