[business-logic] unread_edit_guard.go: stale-read warning is once-per-run forever — second external modification after re-read never re-warns (contradicts 'exact mtime' comment)

[topcheer]

File/Line

• internal/agent/unread_edit_guard.go L172-180 (checkStaleRead warn gate), L91-103 (recordRead)

Problem

Comment contract: "allow re-warning if the file changes again after a stale warning... only skip if the stale warning was already issued for this exact mtime". Implementation keys warnedFiles[n+"\x00stale"] — mtime is not part of the key, and no code path ever clears it (recordRead updates readMtime but not warnedFiles; only reset() per run clears it).

Trigger scenario (false negative, data-loss direction)

Step	Event	State	Warning
T1	agent reads file (mtime=T1)	readMtime=T1	—
T2	external edit (mtime=T2); agent edit_file	stale key set	fired
T2'	agent re-reads (mtime=T2)	readMtime=T2, stale key still set	—
T3	second external edit (mtime=T3); agent edit_file	gate returns ""	silent

Agent now edits T3 content with old_text from T2 — edit fails (wasted iterations) or, with write_file/other whole-file paths, silently clobbers external changes.

Expected vs actual

• Expected (per comment): re-warn when mtime advances past the newly-read mtime
• Actual: one stale warning per file per run regardless of subsequent changes

Fix

Include mtime generation in the key (e.g. n+"\x00stale\x00"+readAt.String()) or clear the stale key in recordRead.

Severity

High in shared-workspace / concurrent-edit scenarios (the product's core multi-agent collab mode); single-user impact is medium (edit_file mismatch usually fails loudly).

Verified by independent review subagent (sa-14: all warnedFiles write sites enumerated — no clearing path exists; interleaving table constructed).

[topcheer]

已修复并推送（commit 443b9c2）。

根因

warnedFiles[n+"\x00stale"] 键一旦设置永不清除——recordRead 更新 readMtime 但不动 warnedFiles，与注释契约"仅当同一 mtime 已警告过才跳过"矛盾。issue 中的时序表准确：T2' 重读后 T3 的第二次外部修改永远静默。

修复

采用 issue 建议的第二种方案：recordRead 时 delete(warnedFiles, n+"\x00stale")，重读即刷新 staleness 基线，后续外部修改可再次告警。（相比在键中拼接 mtime，此方案更简单且语义等价——重读后 mtime 必然已同步。）

测试

TestStaleRead_RewarnAfterReread：首次外部修改告警 → 重读 → 第二次外部修改必须再次告警（修复前静默）。全包测试通过。