Detect repeated overlapping reads of the same unchanged file

[yablokolabs]

Summary

Atomic's loop tracker detects identical (tool, args) calls and identical results, but repeated reads of the same unchanged file can bypass it when offsets or limits differ. In a long coding run, this consumed substantial steps before exact-repeat protection eventually fired.

This is the file-read half of finding §11 from Yabloko Labs' evaluation. Repeated test commands are tracked separately because they require a different progress signal.

Current behavior

The tracker hashes the exact canonical arguments for the call signature:

• loop-detector.ts

os.fs.read is deliberately excluded from the distinct-argument wandering detector because scanning many files is legitimate:

• loop-detector.ts

That default is sound for multi-file scans, but overlapping ranges of one unchanged file remain invisible when their raw arguments differ.

Proposed behavior

Add a read-specific semantic progress tracker for successful os.fs.read results:

• key history by resolved canonical path and a content/version fingerprint;
• record the actual returned startLine/endLine range, not only requested offset/limit;
• treat a repeated or fully contained range for the same unchanged fingerprint as no progress;
• treat newly covered lines as progress;
• reset coverage when content changes.

The content/version fingerprint must detect same-size replacement and must not rely only on size or coarse modification time.

Acceptance criteria

• Re-reading an already covered range of the same unchanged file contributes to a semantic no-progress streak even when requested offset/limit differ.
• A partially overlapping read counts only its newly covered range as progress.
• Reading a disjoint range is progress.
• Reading the same range from a different resolved file is independent.
• Content changes reset coverage, including a same-size replacement with an unchanged/coarse timestamp.
• Multi-file scans remain legitimate and do not activate a wandering detector merely because many files are read.
• Failed or truncated reads do not create misleading full-range coverage.
• Events identify the read-semantic detector, resolved path, returned range, and fingerprint transition without logging file contents.
• Tests cover containment, partial overlap, pagination, symlink/canonical-path behavior, same-size replacement, truncation, and file mutation.