远程基础设施

需要了再开远程权威#

常规的本地工作流不需要服务端。远程基础设施带来的是三项相互独立的 能力，前提是它们真能解决具体问题：

• 通过共享、持久的工作流权威做远程管理；
• 把已记录的 Snapshot 和 Line 状态异地保存下来，用于恢复；以及
• 通过带类型的 Worker Job 执行仓库自己的 CI。

它同时也把认证、TLS、网络暴露面、数据根备份、升级和兼容性这些责任 压到运维身上。完整的数据流、保护边界和恢复步骤，读 `ait-server`：远程权威与恢复。

组件边界#

• ait-server 拥有仓库注册表、共享的工作流状态、策略、证据和 Worker Job 队列。
• ait-runner 认领兼容的带类型 job，物化出确切的 Snapshot 内容， 执行仓库声明的 CI 入口，返回有界的结果。

runner 不会变成仓库权威，也不会替你挑某种语言专属的构建系统。

在本地试用 1.0.0 服务端#

除非已经有一条经过评审的安全入口，否则把评估用的容器绑到 loopback。

docker network create ait-native-rc
docker volume create ait-native-rc-data
docker run --detach \
  --name ait-server \
  --network ait-native-rc \
  --publish 127.0.0.1:8088:8088 \
  --restart unless-stopped \
  --volume ait-native-rc-data:/var/lib/ait \
  ghcr.io/weita2026/ait-server:1.0.0

curl --fail http://127.0.0.1:8088/healthz

公开的容器索引覆盖 Linux amd64 和 arm64。

注册并配置仓库#

本地仓库还没有数字 Repository 权威时，remote add 会注册一个，然后 把这个 remote 存下来。如果已经配了仓库索引，它就去核验那个确切的 权威，而不是再分配一个。

ait remote add origin <server-url> --default
ait remote list --json
ait config show --json
ait repo show --remote origin --json

别把别的仓库的索引抄过来。这个索引是远程权威路由的一部分。光注册 不会传任何 Snapshot；要做出一份可恢复的异地副本，得走配置好的远程 工作流，或者明确执行一次 ait push。

Runner 契约#

runner 接收某个已注册仓库的版本兼容 job，执行它确切的 ci/run.sh 或 ci/run.ps1 入口。源码根目录、尝试目录、worker 身份和仓库索引 都是运维自己选的值。

尝试用的存储要隔开，投递失败要盯着，终态结果之后还得确认尝试目录 自己那份数据已经清干净。

专门的 `ait-runner`：原生 CI 执行面 一章，展开讲了 1.0.0 的确切命令、Worker Job 生命周期、带类型的契约、 物化上限、租约、证据、部署和排查。

就绪与收尾#

远程工作会发布一个选定的 Patchset，并在 Task 最终收尾之前记录下 CI、attestation、评审和策略这几类完成的证据。

ait workflow ready <change-id> --apply
ait task land <task-or-change-id>

某道关卡还没过时，就绪命令会报出确切的下一步动作。

恢复这件事是明确的#

ait-server 只能作为送达过它的那部分状态的恢复源。脏文件、未跟踪 文件以及其他没被记录下来的工作区文件，都在这条边界之外；而且一台 服务端并不提供自动故障切换。把确切的 Repository 索引留在恢复清单 里，单独保护好服务端数据根，并按 `ait-server` 那一章里带版本的 恢复流程演练一遍。