本地工作区备份

要解决的具体问题

本地工作区备份的风险往往不在“有没有备份”，而在“以为备份了但其实没有”。比如用 rsync 手写命令时遇到版本识别错误就猜参数，导致复制失败却没发现；备份中途断掉（撕裂运行），下次没检查目标盘是否被换过就用旧计划继续；备份后没独立校验，目标盘被误删或拔了，源数据删了就无法恢复——这种“绿色但错误”的失败比没备份更隐蔽。另外，误写 Time Machine 目标会毁掉唯一历史；把 node_modules 当“可再生成”删除，会删掉用户没纳入版本控制的本地数据。

技能如何工作

这个技能用固定链路处理备份，每一步只负责一件事，退出码是最终裁决——文档里的 prose 可能被用户输入或长运行的上下文压缩影响，但非零退出码不会说谎。

• scripts/inventory.py：只读盘点源工作区，生成 inventory.json，记录单元、属性和 UNCOVERED 列表，同时标记上一次是否为撕裂运行。
• scripts/guard_destination.py：对每个目标盘做守卫，是独立进程，能证明“零字节、未建目录”——所有能写的进程启动前，它必须 exit 0。它会拒绝 Time Machine 目标（exit 20）、目标路径在源根内（exit 21）等风险。
• scripts/plan.py：对单元分类：A（无远程的 git repo、非 repo、被 gitignore 的研究资料）→ 所有通过守卫的目标；B（有远程的 repo）→ 所有通过的目标，校验更轻；C（单元名匹配排除规则）→ 不复制，只报告可回收空间。它会重新观察目标盘上源指纹标记为“未变”的单元，发现差异就标记为“已变”，生成 plan.json。
• scripts/copy.py：只有加 --go 才会复制，否则是 dry-run。它只复制“已变”单元，目标路径必须来自守卫过的配置，plan.json 里路径不对就 exit 11。
• scripts/verify.py：唯一能标记单元“安全”的脚本。它从文件系统独立重新枚举目标盘，不是用 copy 的列表，只有校验通过才写 memo。
• scripts/status.py：生成最终报告，回复里的所有事实都来自这里。

关键规则：默认 dry-run，只有第4步展示计划并等待确认后才写；plan.json 不是权限，copy/verify 只认“守卫过的配置目的地+单元ID”；绝不手写 rsync/ditto/cp 替代 copy.py，处理不了就是缺陷，不是临时绕过去的借口。

适用边界与注意点

• 只问状态时不写盘：像“还有哪些没备份”“上次备份是什么时候”这种问题，只会跑 inventory + plan + status.py，永远不碰 copy——plan 会重新观察目标盘，报告的安全状态才可信。
• 中断恢复要从守卫重来：上次运行被撕裂（比如复制中途拔盘），恢复时要重新跑 guard_destination.py，因为盘可能已经被换过了。
• Time Machine 目标没有例外：这是唯一没有 override 的规则，--force 也没用，会直接打印“force does not apply here”。
• 源永远只读：排除目录（比如 node_modules）不会被复制，也不会被删除；copy.py 会拒绝任何目标路径在源根内的命令。
• 按需读参考文档：比如 copy.py 遇到未识别的 rsync --version、guard 非零退出、ledger 解析失败、首次运行没配置文件时，才需要读对应的 references/ 文件，干净运行时不需要。