设计原则
SOW 用来约束所有权、派生状态、发布与证据的一组不变式。
设计
SOW 背后的架构决策：所有权、仓库布局、发布、兼容性与版本演进。
本节记录那些即使实现重写也应当保留的设计思路：SOW 在哪里划分所有权边界，哪些不变式 保证仓库可以安全复制与发布，以及为什么某项兼容性取舍被接受或拒绝。
版本边界
本站的操作指南与命令参考描述已发布的 v0.2.0；本设计区同时记录已经落入源码的 0.3 开发线架构。两者会明确标注，不把开发设计冒充成已发布版本或兼容性结论。
设计原则决定 SOW 拥有什么、哪些状态可重建、哪些异常必须失败关闭的一组核心不变式。
系统模型工作区、仓库、Dist、Package Object、Membership、Generation 与发布目标，以及为何它们各有其主。
单包体布局0.3 为什么让每个 Repository 只保留一条包体路径，同时渲染仅含元数据的 APT/RPM 视图。
发布与恢复指针最后写入、提交意图、前向恢复、保留代与证据门禁垃圾回收。
兼容性边界把协议、客户端、镜像工具、文件系统、HTTP 与对象存储兼容性分别验证，而不是压成一个绿色勾。
设计演进V1 实验、v0.2 C2 硬链接布局与 0.3 单包体布局的关系，以及 0.3 明确撤销的历史决定。
权威与证据
这里的页面是持续维护的设计权威。历史 PRD、评审对话、ADR 与日期化验收报告集中封存在 源码仓的只读归档中；它们仍能证明当时版本与环境里的事实，但不能悄悄重定义当前产品。
一项结论要依次经过不同证据层：
设计契约 -> 源码实现 -> 聚焦测试 -> 真实客户端/供应商证据 -> 发布
前一层通过，不代表后一层自动通过。兼容性设计与各版本发布说明 都会明确写出最高验证层级。