docs: 同步 v0.1 backend profile 规格
This commit is contained in:
Codex
@@ -41,10 +41,11 @@
|
||||
- 真实 `v0.1-gitops` artifact catalog 与 `deploy/gitops/g14/runtime-v01/**`。
|
||||
- 真实 Argo CD Application `agentrun-g14-v01` 同步到 `agentrun-v01`。
|
||||
- 真实 `agentrun-v01-postgres` StatefulSet、PVC、Service 和 migration ledger。
|
||||
- 真实 Kubernetes SecretRef 注入 Postgres DSN 和 Code Agent provider credential；Codex 测试凭据必须来自 `~/.codex/auth.json` 与 `~/.codex/config.toml` 的 Kubernetes Secret projection。
|
||||
- 真实 Kubernetes SecretRef 注入 Postgres DSN 和 Code Agent provider credential；Codex stdio profile 测试凭据必须来自 profile 专属 `auth.json` 与 `config.toml` 的 Kubernetes Secret projection。
|
||||
- Codex Secret projection 必须先保持只读，再复制到 writable `CODEX_HOME` 后启动 app-server；综合联调不得把只读 Secret volume 直接当作 `CODEX_HOME` 的通过证据。
|
||||
- 真实 `agentrun-mgr`、runner Job 或受控 runner process、真实 backend adapter。
|
||||
- 至少一个真实 Code Agent provider turn；Codex backend 必须通过 `codex app-server --listen stdio://` 的 JSON-RPC stdio turn 完成，mock、fixture、source-only、dry-run、fake provider、直接 Responses HTTP 或 `codex exec` 一次性输出不能作为通过证据。如果 provider credential SecretRef 缺失，综合联调必须标记 blocked，不能降级为 mock pass。
|
||||
- 至少一个真实 Code Agent provider turn；Codex stdio backend 必须通过 `codex app-server --listen stdio://` 的 JSON-RPC stdio turn 完成，mock、fixture、source-only、dry-run、fake provider、直接 Responses HTTP 或 `codex exec` 一次性输出不能作为通过证据。如果 provider credential SecretRef 缺失，综合联调必须标记 blocked，不能降级为 mock pass。
|
||||
- 若变更涉及 backend profile，综合联调必须分别覆盖 `backendProfile=codex` 与 `backendProfile=deepseek`，并按 `codex -> deepseek -> codex` 顺序证明 profile 切换不互相污染。
|
||||
|
||||
综合联调最小闭环：
|
||||
|
||||
@@ -112,7 +113,7 @@ CLI 与 RESTful API 可以复用同一个真实 run 做联调。若两者观察
|
||||
|
||||
### T2 综合联调真实性
|
||||
|
||||
阅读本文，然后执行一次综合联调，确认所有关键依赖均为真实 `agentrun-v01` runtime、Postgres、SecretRef、runner、backend 和 provider credential；Codex 测试凭据必须通过 Kubernetes Secret projection 注入 `~/.codex/auth.json` 与 `~/.codex/config.toml`。任何缺失必须返回 blocked 或 failed。
|
||||
阅读本文，然后执行一次综合联调，确认所有关键依赖均为真实 `agentrun-v01` runtime、Postgres、SecretRef、runner、backend 和 provider credential；Codex stdio profile 测试凭据必须通过 Kubernetes Secret projection 注入当前 profile 的 `auth.json` 与 `config.toml`。任何缺失必须返回 blocked 或 failed。
|
||||
|
||||
### T3 发布判定
|
||||
|
||||
@@ -138,18 +139,32 @@ CLI 与 RESTful API 可以复用同一个真实 run 做联调。若两者观察
|
||||
- 对同一 run 使用相同 idempotency key 提交相同 command 两次，再用相同 key 提交不同 payload，确认前两次返回同一个 command，第三次结构化失败。
|
||||
- 对同一 pending run 启动两个真实 runner 或重复 claim，确认只有一个 owner 成功，失败方为 `runner-lease-conflict` 或等价 failureKind，且不继续调用 backend。
|
||||
- 用不存在的 provider SecretRef 创建 run 并启动 runner，确认失败为 `secret-unavailable`，不会降级为 mock pass，也不会打印 Secret value。
|
||||
- 用 `backendProfile=deepseek` 但只提供 `codex` SecretRef 的 run 启动 runner，确认失败为 `secret-unavailable`，不会 fallback 到 `codex`。
|
||||
- 对同一 run 分页读取 events，确认 `seq` 单调、`afterSeq` 翻页无重复、重复读取同一页不会改变 durable facts。
|
||||
|
||||
T7 只定义人工验收的检查面和判定口径。若后续为减少人工操作引入 helper 命令，它只能输出手动步骤、当前证据或 dry-run 计划，不能把这些负向场景改造成阻断发布的自动门禁。
|
||||
|
||||
### T8 Backend profile 真实切换验收
|
||||
|
||||
阅读本文、[spec-v01-services.md](spec-v01-services.md)、[spec-v01-backend-codex.md](spec-v01-backend-codex.md) 和 [spec-v01-secret-distribution.md](spec-v01-secret-distribution.md)，然后在真实 `agentrun-v01` 运行面用正式 CLI 和 RESTful API 手动验证以下内容：
|
||||
|
||||
- `GET /api/v1/backends` 和 `./scripts/agentrun backends list` 同时列出 `codex` 与 `deepseek`，并显示两者共享 `backendKind=codex-app-server-stdio`、`protocol=codex-app-server-jsonrpc-stdio`、`transport=stdio`。
|
||||
- 用 `backendProfile=codex` 完成一个真实 app-server stdio turn，记录 runId、commandId、terminal_status 和 redacted backend_status。
|
||||
- 用 `backendProfile=deepseek` 完成一个真实 app-server stdio turn，确认 SecretRef 为 `agentrun-v01-provider-deepseek`，runtime `CODEX_HOME` 与 `codex` run 隔离，assistant 回复非空或失败被正确归类为 provider blocker。
|
||||
- 再次用 `backendProfile=codex` 完成真实 turn，确认没有继承 DeepSeek model/base URL/config。
|
||||
- 删除或替换 `deepseek` SecretRef 后复测，必须 `secret-unavailable`，不能使用 `codex` SecretRef 或默认 Codex config。
|
||||
|
||||
T8 是涉及 backend profile 变更时的综合联调标准；不涉及 backend profile 的普通发布仍至少执行已有真实主闭环。
|
||||
|
||||
## 规格的实现情况
|
||||
|
||||
| 规格项 | 状态 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| 两层验证模型 | 已定义 | 本文为 v0.1 验证权威。 |
|
||||
| 自测试 task | 已实现 | `src/selftest/run.ts` 自动发现 `src/selftest/cases/*.ts`；覆盖 redaction/Postgres contract、manager memory、runner Job render/create、Codex fake app-server stdio 和 Secret render。 |
|
||||
| 综合联调验收规格 | 已增强 | 本文保留人工交互验收模型；T4-T7 定义 CLI、RESTful、一致性和负向场景的手动验收标准，不新增自动脚本或门禁。 |
|
||||
| 综合联调验收规格 | 已增强 | 本文保留人工交互验收模型；T4-T8 定义 CLI、RESTful、一致性、负向场景和 backend profile 切换的手动验收标准，不新增自动脚本或门禁。 |
|
||||
| CLI 交互联调标准 | 已定义 | 必须只使用正式 CLI，验证真实 run 生命周期和可观测输出。 |
|
||||
| RESTful API 交互联调标准 | 已定义 | 必须直连真实 manager HTTP JSON API，验证服务合同和 durable facts。 |
|
||||
| 真实主闭环 | 已通过 | 当前 v0.1 已通过真实 Tekton/Argo、Postgres、SecretRef、Kubernetes runner Job、Codex stdio turn、RESTful API 和 CLI 主闭环；每次发布仍需按本文手动复验。 |
|
||||
| `deepseek` profile 切换验收 | 已定义/待执行 | 实现 deepseek profile 后必须按 T8 做 100% 真实综合联调。 |
|
||||
| mock 作为发布证据 | 不采用 | mock 只能证明自测试通过。 |
|
||||
|
||||
Reference in New Issue
Block a user