A3S 项目族谱

定义

A3S 不是单一单体仓库，而是一组用 Rust 编写、以 git revision 互相固定的项目。理解 Box，必须先分清「谁拥有用户体验」与「谁拥有进程状态」。ROADMAP.md 给出的目标方向是严格单向的：

A3S Cloud
    │  将 Box 作为节点本地执行与镜像构建提供者（BX0）
A3S Box
    │  准备好的 OCI bundle + 期望隔离
    │  a3s-oci-sdk（有界本地 IPC）
A3S OCI Runtime 主机服务
    ├── native Linux driver
    └── KVM / HVF / WHPX utility-VM drivers

Box 不得导入 OCI Runtime 的驱动内部类型；OCI Runtime 不得导入 Box 的产品类型。

问题背景

若产品 CLI、镜像仓库客户端、Compose、CRI 与内核隔离原语写在同一个可执行文件里，则任何一层的替换都会迫使全部上层重编。拆成「产品平面 / 执行平面 / 编排平面」之后，Box 可以在迁移期同时保留 libkrun 后端与 OCI SDK 后端，而 Cloud 只需认定节点上的 Box 版本，不必理解 KVM ioctl。

机制说明

各仓库的职责

项目	职责	明确不负责
Box	Docker 式 CLI 与四语言 SDK；镜像拉取与构建；卷、网络、快照、健康、重启、日志、审计；将请求映射到确切运行时代际	不充当多节点控制面；不实现 registry 协议的服务端
OCI Runtime	OCI 校验、容器与 VM 状态、代际、操作日志、终态、驱动、客户机代理、运行时清理	不 pull / build 镜像；不实现 Compose；不管理产品网络与卷
ACL	配置语言与结构化策略文本	不执行工作负载
Runtime（`a3s-runtime` crate）	跨项目的能力与生命周期契约	不是 hypervisor
Sandbox（独立仓库）	轻量、跨平台的命令沙箱，面向 Agent	不是 Box 的 `--isolation sandbox`
Cloud	多节点编排；把 Box 当作 `BX0` 节点引擎	不在节点上直接实现隔离

Box v3.2.7 的 src/Cargo.toml 将依赖固定为：

a3s-acl revision 5317e166；
a3s-runtime =0.5.0 revision aeb1dd96；
a3s-oci-sdk =0.3.1 revision 931def0b。

阅读代码时应以这些 revision 为准，而不是各仓库的浮动 main。

当前与目标的差距

当前 3.2 执行模型仍是双路径：默认 MicroVM 由 Box + libkrun 拥有；Linux Sandbox 由 OCI Runtime 拥有。目标是 Box 只提交 bundle 与期望隔离，由 OCI Runtime 统一选择 native 或 utility-VM 驱动。未完成的迁移不得写成已经交付的平台能力。路线图中的 Cloud 义务包括 BX0.3（Sandbox + 硬件 MicroVM/TEE 证据，禁止静默降级）以及与锁定 Runtime 版本的配对认证。

在 Box 中的位置

产品合同：ROADMAP.md 的 Product Contract 与 Responsibility Boundary。
架构图：README.zh-CN.md 的「架构：当前与目标」。
依赖钉扎：src/Cargo.toml 的 [workspace.dependencies]。

验证命令

无。本词条是结构说明。核对应打开上述三个文件，确认依赖 revision 与职责表仍与本页一致。