配置、版本与扩展边界
- 文档状态
- draft
- 文档 Owner
- DOC
- 事实源
- canonical-docs
- 更新
- 2026/10/16
读配置时先确认“哪个实现、哪个 revision、哪个实例、哪份有效 WORKFLOW”。官方规范、官方参考实现、团队扩展和目标部署不是同一个事实。本文固定引用官方 be10a1b79df723d6d7612b5651c8522704dafb2e，不把它宣称为团队当前运行版本。
WORKFLOW 由两部分组成
WORKFLOW.md 的 YAML front matter 决定 tracker、目录、调度与 Agent 设置，Markdown 正文作为任务提示模板。配置解析会应用默认值及环境变量引用，正文可以使用 issue.identifier、issue.title 等任务字段。
| 配置领域 | 作用 | 阅读时要核对 |
|---|---|---|
tracker / tracker.provider | 选择适配器、来源范围与认证；定义活跃、终态及所需标签 | 状态名与来源相符；读取 scope 不替代工具写权限 |
polling | 轮询节奏 | 实际生效值及 tracker 限流，不从示例推断线上频率 |
workspace / hooks | 目录根与生命周期脚本 | 路径、宿主权限、超时、保留和清理策略 |
agent | 全局 / 按状态并发、单次连续轮数、重试上限 | 默认值不是团队部署值；轮数上限不等于任务结束 |
codex | app-server 命令、审批、沙箱与超时 | 对应 Codex 版本接受的字段，以及认证与工具是否齐备 |
| Markdown 正文 | 任务目标、行动约束、验证及结果回写要求 | 项目授权和完成判据，避免把不可信任务内容作为高权限指令 |
来源：固定版本 Elixir README · Configuration与 SPEC §5–6。可替换占位符的入门示例见首次运行；不应直接复制上游仓库自用 WORKFLOW 的项目标识、状态、模型或发布权限。
配置加载与热更新
该固定参考版本在启动时要求 WORKFLOW 存在且可解析；缺失或无效时无法正常启动。运行后会重新加载变更，后续派发、重试、核对和新会话使用有效配置；不保证自动重启正在运行的 Agent，也不保证 HTTP 监听端口热重绑定。
运行中的无效重载保留最近一次有效配置，并记录错误。 不能看到文件已改就认定服务已采用新值。团队审核写操作另有读取 live-host WORKFLOW 并 fail-closed 的扩展合同，这与核心的 last-known-good 重载行为不同，不能混写成一条通用规则。
官方来源支持与团队接入
此固定版本的官方 Elixir README 列出 Linear、GitHub Issues、Jira Cloud、Asana 与 GitLab 适配器。这个结论只说明该 revision 的官方参考实现；不证明团队部署含有这些适配器、具备相应认证或已完成真实任务闭环。Plane 是团队接入路径，不列作该官方版本自带适配器。
本站现有自用文档说明 AutoDev 开发实例直接使用官方 Linear adapter，不通过 Plane fallback 或状态同步。团队 Plane Tracker、CAS 与业务工具按自己的合同阅读。来源选择及这些证据层次见任务来源。
团队扩展与历史方案
| 内容 | 如何定位 | 不能据此推出什么 |
|---|---|---|
| Plane Tracker、CAS、委托及业务动作 | 接入协议与产品合同 | 所有 tracker 都有相同状态、委托按钮或写入协议 |
| Backlog 处理、独立自动审核 | 团队的 backlog.enabled、review.enabled 合同及项目有效配置 | 官方核心默认执行 Backlog 或默认启用自动审核 |
| Slack 审核桥、GitLab guarded merge、多后端、私有镜像 | 团队实施说明与Code Map | 这些都是官方规范的必备组件，或当前实例均已启用 |
| 旧 Coordinator、Worker Action、Plane Run 与 callback | 保留的历史技术资料及迁移说明 | 它们仍是当前执行的备用路线，或应恢复旧同步 |
| Plane materializer | 物化合同 | write_enabled: false 可以执行写入或一键派单 |
团队资料保留各自的 revision、locator 与限制。本文未直接读取团队私有运行仓库及 live-host 配置，不把这些资料中的实现定位升级为当前部署可用性；不同历史提交也不能合成为一个虚构的“已安装版本”。
容器实例的项目配置
团队通用镜像把项目差异放在外部 WORKFLOW、Codex/Git 配置和凭据目录中，每个项目独立持久卷。准备清单、七项 Compose 变量、认证种子、首次启动和日常修改步骤见Docker 独立项目实例。该路径直接维护宿主配置文件；镜像/启动器源码仍按外部 CI 交付。
怎样判断证据足够
源码说明“该 revision 如何实现”，有效配置说明“此实例准备如何运行”，运行快照说明“查询时观察到了什么”。还需要分别核对所选来源权限、工具认证、依赖可达性以及交付链路。只拥有其中一层证据时，就在该层得出结论。