系统架构与授权边界
看清外部 coding client、原生绑定、ait-native 内核、Task worktree、Binary DB、服务器与 runner 如何跨本地与可选远程授权连接。
适用人群： 开发者、集成方与运维人员
按边界来读这套系统#
ait-native 只有一个原生工作流内核，外加两条明确的运行路径。常走的 是本地这条：外部 coding client或嵌入式宿主调用原生接口，实现发生在 Task 绑定的 worktree 里，再由一个 Snapshot 把结果记进本地的 Binary DB 权威。远程基础设施是可选的，而且只能通过明确的操作，去 扩展已经记录下来的状态。
Local authoring is primary. Optional remote infrastructure adds shared authority, offsite preservation, and CI through bounded native interfaces.
Local authoring and recorded authority
Snapshot records mutable work into local authority.
- surfaceExternal coding client or embedded hostInteractive authoring or an in-process caller outside ait-native.
- interfaceait CLI or native bindingCommand or in-process entry surface.
- coreait native coreWorkflow, protocol, and storage semantics.
- executionTask-bound worktreeIsolated mutable implementation workspace.
Remote authority, preservation, and CI
Recorded state enters the server; bounded evidence returns to it.
- queueWorker JobTyped durable request owned by server authority.
- executionait-runnerMaterializes exact Snapshot content and executes Repository CI.
- evidenceCI evidenceBounded result returned to the owning server Repository.
组件与权威对照#
| 组件边界 | 它拥有什么，又不拥有什么 |
|---|---|
| 外部 coding client与 Python/Node 宿主 | 负责 ait-native 之外的交互式或嵌入式使用体验。它们调用 AIT 接口，但不会取代原生的工作流或存储语义。 |
ait CLI、原生绑定与原生内核 | 负责命令接纳、工作流状态迁移、协议行为，以及对已记录权威的访问。Python 和 Node 是在进程内进入同一个内核，而不是另实现一套工作流。 |
| Task 绑定的 worktree 与本地 Binary DB | worktree 是一个隔离的、可变的实现工作区。Binary DB 拥有记录下来的 Plan、Task、Change、Snapshot、Line 和相关本地状态。Snapshot 就是可变编辑与持久 AIT 历史之间的那条界线。 |
ait-server | 拥有已注册的远程 Repository 权威、共享的远程工作流状态、带类型的 Worker Job、证据，以及对送达服务端的记录状态做异地保存。它不保存没进过 Snapshot 的本地改动。 |
ait-runner | 认领一个兼容的 Worker Job，物化出确切的 Snapshot 内容，在隔离的一次尝试中执行 Repository 声明的 CI 入口，然后返回有界的证据。它永远不会变成 Repository 权威。 |
主要的本地编写路径#
理解需求、写出实现，这些仍然是 coding client的事。AIT 给这份工作 提供的是稳定的仓库身份，和一条隔离的变更边界：
- 客户端通过 CLI 或受支持的原生绑定调用
ait。 - 原生内核解析出确切的 Repository、Plan 条目、Task、Change 和 Task 绑定的 worktree。
- 在创建 Snapshot 之前，代码改动一直是那个 worktree 里的可变 状态。
- Snapshot 和工作流记录进入本地 Binary DB 权威；配置好的收尾路径 随后就能基于这份记录状态做判断。
多个 agent 之间互不干扰，因为每个活动的 Task 各占一个 worktree 和 一把命令锁。AIT_RAM 可以加快放置速度，但它不改变权威边界：没进 Snapshot 的脏文件属于工作区状态，已记录的 Snapshot 才是可恢复的 AIT 状态。参见 并行 Task 隔离。
可选的远程权威与 CI 路径#
本地记录下来的状态，只有通过明确配置的远程操作才会到达 ait-server。一旦收下，服务端就拥有远程的 Repository 副本、共享的 工作流状态、证据和 Worker Job 队列。这样就能远程管理，也能对送达 服务端的那份确切状态做异地恢复。
要跑 CI，服务端会提交一个带类型的 Worker Job。ait-runner 认领这个 job，把它引用的 Snapshot 物化到隔离的尝试存储里，运行 Repository 声明的入口，然后返回有界的结果。服务端记录由此产生的证据；runner 的尝试目录用完即弃，不构成第二个权威。
远程保存不等于自动故障切换，也没法还原那些从未被捕获、从未传出去的 脏文件或未跟踪文件。参见 远程基础设施 和 `ait-runner`：原生 CI 执行面。
一个内核，通过原生嵌入复用#
ait-python 和 ait-node 在进程内加载已接纳的原生运行时。它们给 应用提供面向业务的入口，但不会另起一个工作流引擎，也不会重新定义 仓库权威。嵌入式应用同样得选定确切的 Repository 上下文，并遵守和 CLI 一样的 Task、Snapshot、远程和策略边界。
这张图有意只画到当前 1.0.0 的产品边界。Release 家族的组件、版本 证据和包的构成，仍然由 分发与发布 定义。