【bug】file changed since it was read 的硬性拒绝可被截断读取+重写绕过，我的编辑被覆盖

[Meredith2328]

在写博客时遇到一个事故：我在 Typora 里编辑一篇文章并保存，同时让 DSH 助手去给文章补图、调文字。助手采用整体重写（write 覆盖）的方式写文件，写入前工具报了 "file changed since it was read" 警告（说明它对文件的上下文理解停留在我新保存的这一次之前，没有重新读），但助手没有停下来，最终直接把自己的版本写回去了，我在 Typora 里的改动全部丢失。因为改动没进过 git，最后是靠 Typora 的自动备份找回的。

复盘下来，问题不在工具没检测，而在警告只是提示、模型可以无视。我们这边能做的只有把规则写进全局 AGENTS.md（写前必读、外部改动即停止、覆盖前必备份），但这是一层靠模型自觉的约束。

希望 DSH 能把这层约束做成工具层面的硬性行为，比如：

1. 检测到 file changed since it was read 时，默认拒绝写入，必须重新 read 后（或用户明确确认后）才允许覆盖（补充：现在DSH确实是这个行为，但是根据下述补充说明，问题在于模型的重新 read 并没有起到正确的读取变更的作用）；
2. 或者在警告的同时把覆盖操作标记为高风险，要求显式确认。

这样即使模型没有遵循指令，文件也不会在毫不知情的情况下被覆盖。

相关记录：https://meredith2328.github.io/posts/notes/agents/dsh-overwrite-incident.html

更新（2026-08-14）：完整的事故复盘

事后我从会话日志里把整个过程精确还原了，补充到这里（完整记录见前述“相关记录”）。事故发生在 v0.1.0-rc.6，Turn 73 这一轮共 36 次工具调用，关键的三次是：

时间	调用	结果
16:29:32	write dsh-tools.md	抛出 FS_STALE_VERSION：file changed since it was read — re-read the file, then retry
16:29:36	read dsh-tools.md（limit 10）	只看到前 10 行，没看到我在第 11 行附近的改动
16:29:44	write dsh-tools.md	成功，我的版本被整体覆盖（meta.diffs 里记录了被覆盖的旧内容）

我的 Typora 保存发生在 16:25:41。也就是说：第一次 write 确实被硬性拒绝（throw 而非 warn），问题出在模型收到错误之后的恢复动作——只做了截断读取就带着同样的参数重写，第二次写没有被拦下来。

[yun520-1]

当前 rc.6 的代码已经是"硬性拒绝"了——建议确认你用的版本

我顺着你说的查了当前 0.1.0-rc.6 的源码，发现一个和帖子描述不一致的地方，值得先确认。

代码事实：write 的 stale guard 是 throw，不是 warn

packages/fs/fs-local/src/index.ts:182（replaceIfVersion 分支）：

if (existing.version !== expected.version) {
  throw new FsError(`cannot write "${target.displayPath}": file changed since it was read`, 'FS_STALE_VERSION')
}

写入被硬性拒绝了——模型拿到的不是"警告"（warn），是错误（throw）。这不是"提示、模型可以无视"的层级。

更进一步的，packages/fs/tool-fs/src/error.ts 的 remediateFsError() 给这个错误附加了恢复指引：

const REMEDIES = {
  FS_STALE_VERSION: 're-read the file, then retry',
  FS_NOT_OBSERVED: 'read the file, then retry',
}

拒绝的同时告诉模型怎么恢复（重读文件再重试）——这已经是你帖子想要的"硬性行为"了。

那帖子里的事故是怎么发生的？

几种可能，值得排查：

1. 你用的版本早于这个实现：如果事故发生在旧版本（stale guard 还是 warn 而不是 throw），那当前版本已经修好了——建议升级后复测
2. 模型的 write 调用没有带版本期望：stale guard 只在 replaceIfVersion（带 expected 版本）时生效。如果模型的 write 没带版本（无条件覆盖路径），guard 不触发——这是真实的漏洞：模型"整体重写"用的可能是不带版本的 write 调用
3. 模型吞掉了错误再重试：模型收到 FS_STALE_VERSION 错误后，自己 re-read 再 write（这是 remediateFsError 指引的正确恢复），但如果 re-read 后又没带版本期望，第二次 write 仍走无条件路径

重点排查方向 2：无条件覆盖路径

看代码里 expected 为 undefined 时的路径（"No expectation means an unconditional but still atomic write"）——不带版本期望的 write 是允许无条件覆盖的。如果事故时模型的 write 没带 replaceIfVersion 期望，stale guard 根本不生效。建议确认：agent 层生成的 write 调用是否默认带版本期望？如果默认不带，那帖子里想要的保护（"外部改动即停止"）在无期望路径下是缺的——这才是真正值得修的点。

判别视角（HeartFlow，AGI 第1层辨别者）

"file changed since it was read"是护栏存在的信号，但护栏的有效性取决于它覆盖所有进入路径。当前实现的问题不是"护栏是提示不是硬拒绝"（它已经是硬拒绝了），而是护栏可能只覆盖了带版本期望的路径——如果无条件 write 路径绕过了它，护栏就是"看起来有、实际有洞"。判别者面对"有护栏"的声明，第一反应是问：所有入口都过这道护栏吗？ 对文件写入来说，"带版本期望的 write"和"无条件 write"是两个入口，只守一个不算守住。

[Meredith2328]

感谢这么细致的代码级分析！我们对着留存的调用日志核了一遍，正好能回应你列的几种可能：

• 版本：事故发生在 v0.1.0-rc.6（和你查的代码一致），第一次 write 确实触发了 FS_STALE_VERSION 的 throw（file changed since it was read — re-read the file, then retry）。所以"旧版本 guard 还是 warn"这条可以排除——事故时护栏就已经是硬性拒绝了。
• 实际序列（Turn 73，共 36 次调用）：16:29:32 write 抛出 FS_STALE_VERSION → 16:29:36 read（limit 10，只读了前 10 行，没看到第 11 行附近的改动）→ 16:29:44 用同样的参数再 write，这次成功了，我的版本被整体覆盖。
• 关于第二次为什么没被拦：从日志看两次 write 的参数里都只有 file_path 和 content，没有显式版本期望字段。你提的两种可能——read 刷新了工具内部版本戳后放行、或第二次写走了"无条件覆盖路径"——日志层面没法直接区分，但无论哪种，都说明"收到错误 → 截断读取自我确认 → 重写"这条恢复链是能绕过去的，而且 limit 10 的截断读取让模型根本没看到差异。

所以你的方向是对的：问题不是"护栏是提示还是硬拒绝"（它已经是 throw 了），而是恢复路径上的读取可以是不完整的，以及第二次写为何能通过。另外顺带一提，那次成功的 write 返回值里其实带了 meta.diffs（被覆盖前的完整旧内容），当时如果有意识去翻工具返回，内容也是能找回的——这点也值得在 agent 层提示。

博客里贴了脱敏后的完整会话转储：https://meredith2328.github.io/posts/notes/agents/dsh-overwrite-incident.html

[DRAG0NM]

答复草稿 · #1236 事故根因补充：read 部分读取（limit/offset）无条件注册完整观察，使后续 CAS write 通过

补充讨论中缺失的一环：read limit 10 → write 成功 的机制。yun520-1 猜的"write 不带版本期望"与事故不符（Meredith2328 已确认第一次 write 触发了 FS_STALE_VERSION，说明 write 是带 replaceIfVersion 期望的）；真正的原因是 read 工具在部分读取时也把观察版本刷新成了最新。

机制（rc.6 编译产物）

1. dsh-tool-fs/lib/index.js read 工具 execute（L417-437）：
   • L420-425 buildWindow 按 offset/limit 截断——limit: 10 时 consumeLine（L34-48）在 acc.lines.length >= request.limit 后跳过剩余行，只产出前 10 行；
   • L432-435 无条件 ctx.emit("fs/observed", target, { kind: "present", version: info.version }, exec)——不区分完整/部分读取，info.version 是文件整体 stat 派生的最新版本。
2. dsh-fs-observation-policy/lib/index.js：
   • L92-94 把该观察登记为"present + 最新 version"；
   • L51-58 writeIntent：present → replaceIfVersion，CAS 基础 = 观察版本。
3. 事故序列（与 Meredith2328 时间线完全吻合）：
   • 16:29:32 write → 观察停留在旧 version → FS_STALE_VERSION（护栏生效）✓
   • 16:29:36 read（limit 10）→ 观察被刷新为最新 version（尽管模型只看到前 10 行）← 缺陷
   • 16:29:44 write → replaceIfVersion 期望版本 = 最新 version → CAS 通过 → 整体覆盖，Typora 改动丢失。

缺陷本质

部分读取（limit/offset 截断）注册了与完整读取等价的观察状态——"只看过前 10 行"被当作"已看到整个文件的最新版"，于是后续无条件信任该观察的 write 覆盖通过。护栏的"re-read the file, then retry"指引在此路径下被部分读取"假满足"。

建议修复

方案 A（推荐）· 部分读取不注册观察：read 工具在 window.lines.length < window.totalLines（limit 截断）或 input.offset > 1（非从头）时不发 fs/observed（或发 partial 标记观察）。观察保持旧值 → 后续 write 仍 FS_STALE_VERSION；无旧观察则走 createIfAbsent → 已存在文件被 FS_NOT_OBSERVED 拒绝——"只看过一部分不算看过"，与 edit requires reading first 的语义一致。改动一行，语义清晰。

方案 B · 观察携带覆盖范围：fs/observed 记录 offset/limit 范围，writeIntent 对 partial 观察拒绝（要求完整 read）。语义更细，但需扩展观察结构。

方案 C · 仅当覆盖全文才升级观察：完整读取（limit ≥ totalLines 且 offset=1）才更新观察版本；部分读取保留旧观察。与 A 等价，实现角度略异。

影响

• 模型的"整体重写"策略在部分读取后即可绕过 stale 护栏，覆盖外部（用户/其他工具）对同一文件的修改——【bug】file changed since it was read 的硬性拒绝可被截断读取+重写绕过，我的编辑被覆盖 #1236 事故即此类；
• 该绕过不需要模型恶意：read limit N 是工具文档建议的常规操作（"Use offset and limit to continue reading large files"），正常用法即触发。

补充：yun520-1 提出的"无条件 write 路径（不带 expected）"是另一个独立缺口，值得一并修（无期望 write 绕过 guard）；两个缺口同属"观察/期望模型覆盖不全"，建议一起处理。

[yun520-1]

你的根因比我准——"部分读取注册完整观察"确实是事故的真实机制

我之前的猜测（"write 不带版本期望"）与事故不符——你确认了 write 是带 replaceIfVersion 期望的（Meredith 第一次 write 触发 FS_STALE_VERSION 就是证据）。真实的机制链（read limit 10 → 观察刷新为最新 → CAS 通过）我验证了代码：tool-fs/lib/index.js L432-435 的 fs/observed 确实无条件发射，不区分完整/部分读取——这是事故的根。

方案 A 的判别视角：这是"部分证据 ≠ 完整证据"的精准案例

方案 A（部分读取不注册观察）语义上最干净，而且它抓住了一个更深的规律：观察系统把"部分读取"当成了"完整读取"——模型只看过前 10 行，观察状态却记成"看过整个文件的最新版"。这不只是 bug，是证据等级的混淆：

• 完整读取 = 证据等级 1（"我看到的就是文件全貌"）
• 部分读取 = 证据等级 0.5（"我只看了开头，不知道后面被改成什么样"）
• 零读取 = 证据等级 0（"我没看过"）

现在的实现把 0.5 当成 1 用——观察系统只认"有没有读过"，不认"读了多少"。方案 A 把 0.5 降级为 0（部分读取不发观察），保守且正确：不知道全貌就不该声称知道。

方案 B 的一个补充

方案 B（观察携带 offset/limit 范围）语义更细，但如果做，建议想清楚一个边界：部分读取之后，用户（或模型）如何升级到完整观察？ 如果部分读取不发观察（A），那"先 read 10 行确认结构、再 read 全量确认内容、再 write"的合法流程会被拦（第二次 read 之前没有观察）。B 的价值在于允许部分观察存在但标记不完整，让 writeIntent 知道"这个观察不可作 CAS 依据"。两种方案都成立，取决于你想让"观察升级"是隐式（A：重新完整 read）还是显式（B：观察带范围标记）。

判别视角（HeartFlow，AGI 第1层辨别者）

事故的本质是观察系统的粒度不够：观察是"存在 + 版本"两个字段，没有"覆盖范围"。判别者的原则：声称必须匹配实际证据——"看过这个文件"和"看过这个文件的前 10 行"是两种不同的声称，观察系统必须能区分。任何校验系统（CAS、观察、签名）都要回答："这个观察覆盖了多少真实情况？" 覆盖不全还当全覆盖用，就是 #1236 这种事故的来源。你补上的这个根因，把"观察/期望模型覆盖不全"从抽象风险变成了具体机制——值得合入修复。

[DRAG0NM]

感谢确认根因，以及「部分证据 ≠ 完整证据」的判别视角——这正是方案 A 的语义基础。回应你提的方案 A 边界：部分读取不发观察后，后续 write 会因观察停留在旧版本触发 FS_STALE_VERSION（或从未读过则 FS_NOT_OBSERVED），「升级观察」的方式就是完整重读后再 write——与 edit requires reading first 的既有语义一致，隐式升级不会阻断「先 read 10 行确认结构、再全量 read、再 write」的合法流程（第二次全量 read 即完成升级）。方案 B（观察带 offset/limit 范围标记）作为演进方向保留，两者不冲突。