[Bug Report] 分叉（fork）会话丢失父会话的读取观察状态，edit 工具系统性报 "edit requires reading ... first"

[DRAG0NM]

摘要

@deepseek-ai/dsh-fs-observation-policy 的读取观察状态（"哪些文件已被本会话读过"）是按 session 对象弱引用的内存态（WeakMap<session, Map<targetKey, observation>>），只通过 read 工具运行时的 fs/observed 事件写入。分叉会话（fork）在 dsh-session 里会新建一个 session 对象，只复制事件日志（对话历史），不继承任何观察状态。于是 fork 子会话的观察表从空开始：模型看到的历史里明明有"读过该文件"的结果，实际 edit 却每次都抛 FS_NOT_OBSERVED（"edit requires reading ... first"），形成"历史说读过、策略说没读过"的矛盾。这与 #275 报告的「分叉会话下每次调用 edit 工具都报错」完全吻合。

根因（源码定位，rc.6）

1. dsh-fs-observation-policy/lib/index.js：
   • ObservedStateGate.observed = new WeakMap()（L22），按 owner = actor.agent.session（L29-31）分会话记录；
   • editIntent()（L64-70）：!owner || prior === void 0 → 抛 FsError("edit requires reading ... first", "FS_NOT_OBSERVED")；
   • 只有 fs/observed 事件（read 工具执行时 ctx.emit，见下）会写入状态。
2. dsh-tool-fs/lib/index.js L432-435：read 工具成功读取后 ctx.emit("fs/observed", target, { kind: "present", version }, exec)，actor 是当前会话的 exec 上下文——所以 fork 子会话里新读的文件会正常记账，但fork 点之前（父会话里）读过的文件不会。
3. dsh-session/lib/index.js fork()（L1840+）：_forkSeed 复制事件日志生成子会话，没有任何观察状态的搬运/重建逻辑（观察状态在 fs-observation-policy 插件内部，session 层根本不可见）。
4. 触发链路：父会话 read 文件 A → fork → 子会话上下文包含"已读 A"的历史 → 模型直接 edit A → editIntent 查子会话观察表（空）→ FS_NOT_OBSERVED。策略的错误文案又指示模型"先读再改"，模型在子会话重读后 edit 能通过——但历史与策略的矛盾已经造成一轮失败/重试，且模型并不总按提示重读（它认为读过了），于是表现为"每次 edit 都报错"。

复现步骤（逻辑复现 + 最小验证）

1. 任意会话中 read 一个已有文件（记下内容）。
2. 对该会话执行 fork（分叉）。
3. 在分叉子会话中直接对同一文件发起 edit（不重新 read）。
4. 结果：edit requires reading "<path>" first（FS_NOT_OBSERVED）——尽管对话历史中该文件已被读过。
5. 对照：子会话中先重新 read 再 edit → 成功（证明状态只缺"继承"一步）。

建议修复

方案 A（推荐）· fork 时重建观察状态：fs-observation-policy 监听会话 fork（或 dsh-session 在 fork 时发出携带种子事件的通知），从被复制的事件日志中重放 read 工具调用，把对应文件的观察记录（present/absent + version）写入子会话的观察表。version 可安全取事件里记录的版本；若担心版本过期，edit 的 CAS 校验会兜底拒绝为 stale，语义上等价于"子会话继承了父会话的读取事实"——与"历史里读过了"一致。

方案 B · 策略放宽：fork 子会话对"历史中出现过 read 结果的文件"视为已观察（由会话层在 fork 时打标）。改动面大、语义更松散，不推荐。

方案 C（兜底性提示改进）：若短期不修，至少让 FS_NOT_OBSERVED 的错误文案区分"从未读过"与"在父会话读过（fork 继承缺口）"，并明确指示重读一次即可。低成本、可立即缓解。

影响

• 分叉是"对比不同方案/让子代理继续探索"的高频工作流；在该工作流里 edit 全部系统性先失败一轮
• 模型可能在"按提示重读"与"历史已读"之间反复，浪费 token 甚至陷入循环
• 与只读内存态同源的既有边界：会话 resume 后观察态同样清零（现状靠系统提示兜底），fork 缺口使该矛盾在更日常的路径上暴露

环境

• 源码定位与逻辑复现：0.1.0-rc.6（npx 缓存安装包，Node v24.16.0，Windows 11）
• 原报告：edit 工具在分叉会话下出现异常错误 #275（分叉会话中每次 edit 报错，0 评论，此前无人分析）

验证材料

• 源码行号引用见"根因"节（3 个文件的精确位置）
• 逻辑复现步骤可随时在任意工作区按第 2 节 5 步执行
• 关联：观察态按会话弱引用的设计注释（dsh-fs-observation-policy L3-9）明确其为内存态；fork 复制事件日志的实现（dsh-session L1833-1868）确认无观察态搬运

---

First analysis of discussion #275. Happy to open a PR with fix option A.

[aka-danielZhang]

补充一个同机理但触发面更广的维度：进程重启 / 会话 resume。

• fork 之外，桌面形态每次启动都 spawn 新 harness 进程——resume 的会话里 transcript 明确记录「我读过 / 我刚改过」，但 fs-observation-policy 的 WeakMap 随旧进程消失，模型的第一个 edit 必撞 FS_NOT_OBSERVED。对模型不可证伪（tool:edit 提示的 "unless you just created or edited it in this session" 在 resume 后字面为真），prompt 层无法修复。

• 楼里方案（从 fork seed 重建观察 / 放宽 policy / 改善报错）之外，提供一个已落地验证的插件侧修法，供参考：

  1. mirror fs/observed 的 present 观察到按会话分的 JSONL sidecar（首行记 fork parent，血缘自包含）；
  2. tools/pre-execute（edit/write）发现本进程未观察过该 target 时，查会话及血缘 evidence，ctx.fs.stat 重验；
  3. 版本 token 逐字节相等才补发 fs/observed，让 stock policy 正常记录、走原有 CAS。文件被改 / 删除 / 无 evidence ⇒ 不恢复，照旧拒绝。

  关键前提已核实：本地 backend 的 FsVersion 是 dev:ino:size:mtimeNs:ctimeNs（fs-local/src/fsio.ts），未变文件跨进程稳定，所以「重验版本相等」是可靠判定，guard 语义零削弱。集成测试（真实 fs-local + stock policy + tool-fs，双进程模拟）验证了三个场景：重启后未变文件 edit 成功恢复；文件被外部改动仍拒绝；fork 子会话经血缘继承同样恢复。

详细机理与上游侧的设计选项（含「观察态随 resume/fork seed 重放」的正解形态）见新开的 #3853。