ARC 有多个面向开发者的入口。它们彼此相关，但并不共用一份没有边界的合同。先用这个 board 选定层次，再进入具体任务的指南。
| 想理解什么 | 下一步阅读 | 不应由此推断什么 |
|---|---|---|
| 路径式资源和 Provider 行为 | AFS | 某个目标运行时尚未写明的全局搜索、存储或 Provider 能力 |
| 声明式界面 tree、state 或 renderer 边界 | AUP | 每个 AUP node 都会在每个目标上以相同方式受支持 |
| 由 AFS 路径支持的静态网站 | Web Device | 站点 layout 就是一段交互式 AUP session |
| Package 和 Instance 的生命周期 | Blocklets | Blocklet Server 的所有旧行为都仍属于 ARC |
| 身份、DID Space 或 Data Space 术语 | Identity & Data Spaces | 尚未端到端核验的完整远端生命周期或信任模型 |
| CLI 命令如何对应这些层次 | ARC CLI | 每个 CLI 分组都是另一套独立公开 API 的产品 |
系统地图
需要资源时自下而上读；需要产品边界时从外向内读：
| 层次 | 回答的问题 | 主要开发者表面 |
|---|---|---|
| AFS | 如何用路径寻址数据与能力？ | 操作、挂载、Provider |
| AFS UI | UI 关注点如何与 AFS 资源相关？ | 仅架构视角（本 board） |
| AUP | 如何描述交互式界面 tree？ | 声明式 UI 合同与 DSL |
| Web Device | 如何构建并渲染静态站点？ | 站点目录、内容、组件 |
| Blocklet | 如何打包并运行应用？ | Package、Instance、本地运行、发布边界 |
| 身份 / 数据空间 | 谁在调用，得到哪份数据视图？ | Caller 上下文、DID Space、session 视图 |
| ARC + CLI | 如何启动、检查并操作运行时？ | arc 命令与宿主进程 |
AFS 是资源与能力层。ARC 是挂载 Provider、运行 Blocklet、暴露 CLI 与服务入口的运行时与产品外壳。AFS UI 不是与 AUP、Web Device 并列的第三套大型 authoring board；它说明这些目标如何回到 AFS。
所有权与分层图见产品层次。ARC 与 AFS 为何分别命名见 ARC 与 AFS。
这是一张地图，不是合同的替代品
架构图可以解释两部分为什么相关。它不能把内部计划、旧产品页或源码目录变成公开 API。只有当前源码、目标版本测试和本地运行，才可以支持现在时的能力陈述。分类规则见合同与证据。
ARC 的架构材料用 AFS UI 描述 UI 关注点与 AFS 导向资源之间的关系。在本 board 中，它只是架构视角，不是独立的公开扩展 API。AUP 和 Web Device 仍是各自面向目标的文档表面。
按任务阅读
| 目标 | 从这里开始 |
|---|---|
| 建立术语与阅读顺序 | 心智模型 |
| 区分 ARC（运行时）与 AFS（文件系统） | ARC 与 AFS |
| 判断任务归哪个 board | 产品层次 |
| 把交互 UI 与静态站点放回 AFS | AFS UI |
| 判断陈述是当前合同还是沿革 | 合同与证据 |
| 解析旧 ArcBlock 产品名 | 产品沿革与边界 |
| 收集公开 board 链接与术语 | 参考 |
版本边界
本 board 事实核验于：
- 已安装 CLI：
arc2.0.0-beta.28（arc --version） - ARC 源码快照：
44fbd616f（packages/core、packages/aup、providers/runtime/ui、providers/runtime/web-device、providers/basic/did-space、providers/basic/members） - 该树中的包名：
@aigne/afs、@aigne/afs-aup、@aigne/afs-ui、@aigne/afs-web-device、@aigne/afs-did-space（源码中均为2.0.0-beta.31）
具体命令、字段与 renderer 支持属于各专题 board。若你安装的 arc 版本不同，以专题 board 的重新核验为准。