internal/adequacy at 9f824f73d1, reviewed by antigravity:gemini-3.1-pro-high, verified by claude-code.
Apply silently accepts overlapping SEARCH anchors instead of rejecting them, applying the mutant to the first occurrence because strings.Contains on the remaining string misses the overlap.
cat << 'EOF' > repro.go
package main
import (
"fmt"
"os"
"github.com/pdbethke/corralai/internal/adequacy"
)
func main() {
m := adequacy.Mutant{
ID: "m1",
Search: "aba",
Replace: "c",
}
original := "ababa"
res, err := m.Apply(original)
if err != nil {
fmt.Printf("Expected Apply to falsely succeed, got: %v\n", err)
os.Exit(1)
}
if res != "cba" {
fmt.Printf("Unexpected result: %q\n", res)
os.Exit(1)
}
fmt.Printf("Defect reproduced: overlapping match ignored and mutated output is %q\n", res)
os.Exit(0)
}
EOF
go run repro.goDefect reproduced: overlapping match ignored and mutated output is "cba"
The uniqueness guard at score.go:323 resumes its scan at i+len(m.Search), which structurally cannot see an occurrence overlapping the first, so the 'occurs EXACTLY ONCE' invariant documented at score.go:298 is not enforced for self-overlapping anchors; for the named input the second match at index 2 is missed and Apply silently mutates the first occurrence. I searched the whole scope for any other occurrence-counting or uniqueness check that might reject the mutant before or after Apply and found none — the only other copy of this logic (mutant_apply_test.go:23-27) reproduces the same non-overlapping test, so it would agree with the bug rather than expose it. Neither the ParentSHA256 check (307-312) nor the whole-file shortcut (313-315) intercepts this shape. I could neither show the claim false nor show it narrower than stated.
ref 1072abdbec8e27d9aaa50cec8eb48f64d7aac71b46340f1cd6b6ab7c58f0b2c7#R1
Recorded so that "found nothing here" can be told apart from "never looked here".
The codebase is extremely well-defended, addressing numerous edge cases around concurrency, resource exhaustion, and execution isolation with explicit comments and safe abstractions like `os.Root` and ring-buffered writers. However, the exact uniqueness check for mutant anchors permits a flaw via overlapping substring search.
R1 is the only finding, and it is correct as stated. internal/adequacy/score.go:319-325 locates the anchor with strings.Index and then tests uniqueness with strings.Contains(original[i+len(m.Search):], m.Search) — a scan that resumes at the END of the first match, so any second occurrence that OVERLAPS the first is invisible to it. For the named input (Search "aba", original "ababa") the anchor matches at index 0 and again at index 2, yet the remainder is "ba" and the guard does not fire; Apply returns "cba". That contradicts the invariant the function's own doc comment states at line 298, that Search 'must occur EXACTLY ONCE in original', and the rationale at 299-301 that an unanchored mutant must never be scored silently. I tried three routes to refute or narrow it: (1) looking for a second, correct uniqueness check upstream that would reject such a mutant before Apply — a grep across the whole scope for strings.Count / strings.Contains / 'occurs more than once' / 'uniquely' finds the check only at score.go:323, and the only other instance is mutant_apply_test.go:23-27, which is a test-side reimplementation of the SAME non-overlapping logic and therefore cannot catch the case; (2) arguing 'exactly once' legitimately means 'non-overlapping occurrences', which would make the code correct by definition — but that reading defeats the stated purpose, since index 2 is a real alternative anchor and the mutant is genuinely ambiguous about which bytes it edits; (3) checking whether the ParentSHA256 or IsWholeFile paths at 307-315 short-circuit the case — they do not, an empty ParentSHA256 is explicitly checked against nothing (lines 283-284) and Search is non-empty here. The reviewer's script proves exactly what the claim says, no more and no less: overlapping anchor accepted, first occurrence mutated. I have no refutation. The four items the reviewer listed as checked and sound are not findings and I express no verdict on them.