[bug] fs-local 的 writeFileAtomic 在 link/rename 发布后缺少父目录 fsync，与仓库自身持久化契约不一致

[Johnixr]

概述

packages/fs/fs-local 的 writeFileAtomic 只对临时文件内容做了 handle.sync()，发布（link / rename）之后没有对父目录 fsync。POSIX 崩溃持久性语义下，目录项（rename/link 的结果）不随文件内容的 fsync 落盘：断电窗口内，write/edit 工具已返回成功的写入可能整体丢失——新建文件彻底消失，或被替换的文件回退为旧内容。

位置

packages/fs/fs-local/src/fsio.ts:570-600（基于 master 47f943859）

• await handle.sync()（:571）是整个包中唯一的 fsync（grep 验证）
• await linkFile(tempPath, absolutePath) / await rename(tempPath, absolutePath)（:580-594）之后只有 best-effort 的 staging 目录清理
• 调用方 LocalFileSystem.writeText/editText（fs-local/src/index.ts:200-244）没有补充 fsync

与仓库自身的持久化契约不一致

1. packages/storage/storage-json/src/atomic.ts:34-35 在 rename 之后显式执行 fsyncDirectory(dirname(path))，并注释 "fsync a POSIX directory so a just-renamed entry is crash-durable"；
2. packages/session/session-persistence-jsonl/src/index.ts:556-560 同样实现了 syncDirPosix；
3. 仓库 Agent Note .agents/notes/rejected/simplification/2026-07-26-dependency-swaps-rejected-by-nih-audit.md:42 在论证不引入 write-file-atomic 依赖时，声称手写实现包含 "parent-dir fsync — each the point of the hand-roll"——当前代码与这条记录不符（文档/代码漂移）。

同一仓库内两套原子写实现一个有目录 fsync、一个没有，说明这不是有意的设计分歧，而是实现时遗漏。

建议修复

POSIX 上发布成功后 fsync 父目录，直接镜像 storage-json/atomic.ts 的 fsyncDirectory 做法即可。

影响

agent 通过 write/edit 工具"成功"完成的文件修改在断电/内核崩溃后可能丢失。对以文件编辑为主要交付物的 agent harness 来说，这是核心持久性契约上的缺口。

---

本问题由多轮 AI 辅助代码审查发现，并经两个独立外部模型（Claude Opus 4.8 / GPT-5.6，均 high reasoning）交叉读码复核，三方一致确认（严重度评估 P1/P2）。