文件审查

文件审查用于处理 Foya 的 write 和 edit 工具已经完成的修改。它发生在操作执行 之后，与执行前的权限审批是两个独立阶段。

记录内容

当文件内容实际发生变化时，Foya 会记录：

• 文件绝对路径；
• 修改前是否存在；
• 修改前后文件模式；
• 修改前后内容的 SHA-256；
• 可恢复的内容 Blob；
• 用于界面展示的 Unified Diff。

完整文件内容不会重复写入消息 JSON，而是按 Hash 压缩存储。

待审查集合

尚未处理的 File Change 会进入当前 Session 的待审查集合。只有仍属于有效消息历史 的变更会显示。

查看待审查内容时，Foya 会读取当前磁盘文件并与记录状态比较，生成文件状态令牌。 这个令牌用于防止用户查看 Diff 后，文件又被其他程序修改。

保留修改

选择保留后，Foya 会把当前待审查集合标记为 kept，不再显示为待处理。

保留不会重新写入文件，因为修改已经由 Tool 完成。它只确认用户接受当前结果。

提交时必须携带待审查集合的最新事件边界。如果审查期间又产生新修改，旧请求会被 拒绝，客户端需要重新读取。

撤销修改

撤销前，Foya 会为每个文件判断：

状态	处理方式
未被外部修改	直接恢复到修改前内容
可以合并	使用安全的合并结果
已冲突	要求用户明确保留或强制恢复

确认撤销时，客户端必须提交：

• 预览时的事件边界；
• 文件状态令牌；
• 需要强制恢复的冲突文件集合。

任一状态已经变化时，撤销不会继续。

恢复 Journal

多文件撤销无法与 SQLite 共用一个文件系统事务。Foya 因此先保存 File Rewind Journal，再修改实际文件。

如果进程在恢复过程中退出，内核下次启动时会读取未完成 Journal，并尝试恢复到 可判断的一致状态。

数据库提交失败时，Foya 也会尝试撤销已经执行的文件恢复，避免数据库状态和工作区 状态无声分离。

与历史回退的关系

把一条 User 消息回退到输入框时，Foya 会检查该消息之后的 File Change，并使用 同一套预览、冲突检测和 Journal 机制。

历史回退和文件恢复是一次确认流程，但逻辑上仍是两个动作：

• 事件投影改变哪些消息有效；
• 文件系统恢复到哪个版本。

保留期限

未置顶 Session 的 File Change 恢复数据保留：

• 最近 100 条 User 消息对应的范围；
• 最长 30 天。

超过范围后 Blob 可能被垃圾回收。置顶 Session 不执行自动裁剪。

文件审查不是版本控制系统。重要项目仍应使用 Git 和独立备份。

使用建议

1. Agent 完成任务后先查看 Diff。
2. 在其他编辑器继续修改前处理待审查集合。
3. 出现冲突时先比较当前文件，不要直接强制覆盖。
4. 对重要改动使用 Git Commit 建立长期恢复点。

当前边界

• 只跟踪通过 Foya write 和 edit 完成的文本文件变化。
• delete 会把文件或目录移入系统废纸篓，不进入文件审查；需要撤销时从废纸篓恢复。
• Shell 命令自行修改的文件不会自动形成同等 File Change。
• 恢复数据存在保留期限。
• 强制恢复会覆盖审查后发生的外部修改，需要用户明确确认。