audit on SOW

事务与恢复

Mon, 01 Jan 0001 00:00:00 +0000

本页说明 Managed 模式如何防止 live 指针指向缺失内容，以及如何协调 SQLite 状态与文件系统变更。

在受支持的本地 POSIX 文件系统上，沿 Managed 协议指针读取的客户端只会得到完整旧视图或完整新视图，包括进程中断之后。

Mon, 01 Jan 0001 00:00:00 +0000

每个读取表面回答不同问题。

命令	问题	写入？
`status`	Repository 当前是什么状态？	否
`check`	所选 Repository 是否满足完整交付契约？	否
`changes`	两个 Built Generation 之间哪些物理文件不同？	否
`log`	记录了哪些操作与处置结果？	否
`retain ls`	哪些 Generation 是显式本地 GC root？	否

sow status -r local

它报告 Desired revision、Built Generation、dirty Dist、pending 包体计数、锁状态与 ready_to_copy。它不哈希公共树，不恢复操作，也不构建。

Mon, 01 Jan 0001 00:00:00 +0000

sow status 是低成本的 Repository 状态查询。它读取状态，但不哈希文件、不验签、不恢复 Operation、不构建元数据，也不获取写锁。

sow status [-C|--workdir DIR] [-r|--repo NAME] [-d|--dist NAME]... [--json]

每个 Repository 同时跟踪 SQLite 中的 Desired Revision，以及公开 dists/ 树对应的 Built Generation。

Mon, 01 Jan 0001 00:00:00 +0000

sow check 是 Managed Repository 的深度只读门禁。它哈希包体、校验状态、重建期望视图并验证已声明签名；不会修复、构建、恢复 Operation，也不会获取写锁。

sow check [-j|--jobs N] [-C|--workdir DIR] [-r|--repo NAME] [-d|--dist NAME]... [--json]

稳态下，checker 按顺序报告九层校验：

Mon, 01 Jan 0001 00:00:00 +0000

仓库内的每条写命令，都会先在该仓库的 SQLite 中提交一条应用级 Operation，然后才产生任何外部文件副作用。这条记录让崩溃恢复成为可能——而当 Operation 进入终态之后，同一条记录就是你的审计轨迹。 sow log 读的就是它。