AMR 生产发布影响报告

生成时间：2026-10-14 10:12（本地，UTC+8）；EKS 观察时刻 2026-10-14T02:00:42Z；分析对象：如果现在从 origin/main（HEAD a96eefe50）发布 Web、API、Link、Admin 与 DB migration 的影响分析，Admin 模型配置操作单独核验，独立 Public Pricing 发布流程单独判断。四个服务以 EKS Pod 实际运行镜像为生产发布点，DB migration 以对应 Forgejo workflow 最近一次成功运行的 commit_sha 为生产发布点；五个发布维度分别计算变更范围。模型目录由 Admin 管理，现有环境无需运行 Catalog workflow。

当前生产发布点（EKS 实态 + Forgejo workflow 记录）

Web、API、Link、Admin 的发布点来自 Grafana / Prometheus 观察到的 Ready EKS Pod 镜像（namespace nexu，datasource prometheus，由 kube-state-metrics 采集，全部样本新鲜度在 29 秒内）；DB migration 的发布点来自对应 Forgejo workflow 最近一次成功运行。四个服务均已校验：同一服务所有 Ready Pod 的 commit 与 digest 一致、副本数 spec = updated = available（无滚动中 / 回滚中的混合状态）、Ready Pod 数等于 spec 副本数。四个服务的 workflow 最近成功记录与 Pod 实态全部一致（仅作审计对照）。 feature 表里只列出发布点之后的变更；发布点之前的内容属于已生效，归入「已在生产生效」一节。目标 commit 为 a96eefe50（feat(billing): expose independent funding feedback for AMR (#248)，2026-10-13 14:00，lefarcen），本地 main 与 origin/main 相同。

本轮采样说明：本次采样一次成功，四个服务均处于稳定状态（无滚动 / 回滚中的混合状态，无新旧 Pod 并存），直接采用该快照作为发布点。与上一份报告（2026-10-13 16:19 本地）相比，六个生产发布点全部前进了：Web 27e00e635 → 72252761d、API 3b3ea92c1 → 72252761d、Link e9d02aa9b → 72252761d、Admin 92ef6744c → 72252761d、DB f1b0d7643 → 806b12365（Catalog 仍为 f3ab9fccd）。也就是说：上一份报告列出的待发布项（#243、#164、#253、#254、#245 等）已经在 2026-10-13T08:24–08:34Z 的发布中上线（DB run #4711，API run #4725，Link run #4726，Admin run #4727，Web run #4732），全部归入下面「已在生产生效」一节。四个服务现在都停在同一个 commit 72252761d 上（即 HEAD 之前的第 2 个 commit），origin/main 从那以后只前进了 2 个业务 commit（c07e72e0a #258、a96eefe50 #248），即本报告的两个 feature。

Web · EKS Pod 实态
Workload：nexu/amr-web · container web
观察时间：2026-10-14T02:00:42Z（Grafana / Prometheus kube_pod_container_info，image 过滤 amr-web:prod-[0-9a-f]{40} 且仅取 Ready Pod）
Ready Pods：2 / 2（updated 2，available 2）
实际 commit：72252761d
镜像 digest：sha256:54a3225c93637ff7a2e4893e5dc1898dce5260a813f02a2b4bd4265a559bcc3f
Pod：amr-web-5fbc7d6c48-6prlv, amr-web-5fbc7d6c48-lzmbm
Workflow 审计（仅供参考）：deploy-web-eks-prod.yml 最近成功 run #4732 @ 72252761d；与 Pod：一致（workflow 最近成功运行的 commit_sha 与 Pod 实态相同）
本次新增（72252761d...a96eefe50）：2 commits；触及该服务目录的变更 0 个触及该服务目录的变更
发布点之后 2 个 commit 中 0 个触及 apps/web/：c07e72e0a（fix(link): normalize provider parameters and tool IDs (OPEND-3756) (#258)）、a96eefe50（feat(billing): expose independent funding feedback for AMR (#248)） —— 本轮 Web 无净变更。
API · EKS Pod 实态
Workload：nexu/amr-api · container api
观察时间：2026-10-14T02:00:42Z（Grafana / Prometheus kube_pod_container_info，image 过滤 amr-api:prod-[0-9a-f]{40} 且仅取 Ready Pod）
Ready Pods：2 / 2（updated 2，available 2）
实际 commit：72252761d
镜像 digest：sha256:9108f206817cac71ddb939988614a77dff4379b26c5edd7d9e451d61c7d3f705
Pod：amr-api-696dfb78db-h6jhq, amr-api-696dfb78db-x6vkp
Workflow 审计（仅供参考）：deploy-api-eks-prod.yml 最近成功 run #4725 @ 72252761d；与 Pod：一致（workflow 最近成功运行的 commit_sha 与 Pod 实态相同）
本次新增（72252761d...a96eefe50）：2 commits；触及该服务目录的变更 a96eefe50 feat(billing): expose independent funding feedback for AMR (#248)
发布点之后 2 个 commit 中 1 个触及 services/api/：a96eefe50（#248 独立资金状态提示，feature 表第 1 行）；另一个 c07e72e0a 只改 services/link/。
Link · EKS Pod 实态
Workload：nexu/amr-link · container link
观察时间：2026-10-14T02:00:42Z（Grafana / Prometheus kube_pod_container_info，image 过滤 amr-link:prod-[0-9a-f]{40} 且仅取 Ready Pod）
Ready Pods：8 / 8（updated 8，available 8）
实际 commit：72252761d
镜像 digest：sha256:7ac11c23bee3bcb15525b8c6982cb433823d280810e6316b30ff474ac14b4795
Pod：amr-link-688b4fff6d-nzqfb, amr-link-688b4fff6d-wzh87, amr-link-688b4fff6d-4hmx9, amr-link-688b4fff6d-zv46z, amr-link-688b4fff6d-2qm9z, amr-link-688b4fff6d-p4zmr, amr-link-688b4fff6d-5pt8c, amr-link-688b4fff6d-c4vs8
Workflow 审计（仅供参考）：deploy-link-eks-prod.yml 最近成功 run #4726 @ 72252761d；与 Pod：一致（workflow 最近成功运行的 commit_sha 与 Pod 实态相同）
本次新增（72252761d...a96eefe50）：2 commits；触及该服务目录的变更 c07e72e0a fix(link): normalize provider parameters and tool IDs (OPEND-3756) (#258)
发布点之后 2 个 commit 中 1 个触及 services/link/：c07e72e0a（#258 供应商参数与工具 ID 兼容修复，feature 表第 2 行）；另一个 a96eefe50 只改 services/api/、apps/cli/。
Admin · EKS Pod 实态
Workload：nexu/amr-admin · container admin
观察时间：2026-10-14T02:00:42Z（Grafana / Prometheus kube_pod_container_info，image 过滤 amr-admin:prod-[0-9a-f]{40} 且仅取 Ready Pod）
Ready Pods：2 / 2（updated 2，available 2）
实际 commit：72252761d
镜像 digest：sha256:75548e75345199ca24e3f241ac917ac22870bfe273f4a151ac4b6e4e3fcd964d
Pod：amr-admin-74dd9479cf-68rrt, amr-admin-74dd9479cf-r2rcg
Workflow 审计（仅供参考）：deploy-admin-eks-prod.yml 最近成功 run #4727 @ 72252761d；与 Pod：一致（workflow 最近成功运行的 commit_sha 与 Pod 实态相同）
本次新增（72252761d...a96eefe50）：2 commits；触及该服务目录的变更 0 个触及该服务目录的变更
发布点之后 2 个 commit 中 0 个触及 apps/admin/：c07e72e0a、a96eefe50 —— 本轮 Admin 无净变更。
DB migration · workflow 记录
最近成功：run #4711 @ 2026-10-13T08:24:04Z（trigger workflow_dispatch）
发布点 commit：806b12365
本次新增（806b12365...a96eefe50）：3 commits，其中触及 db/migrations/ + db/schema/ 的变更 0 个
数据源：Forgejo run 列表（tea api /repos/core/amr/actions/runs），不使用 GitHub Actions。该基线已包含仓库最新一份 migration db/migrations/20261012113538_coding_plan_quota_resets.sql（#243）；基线之后到 HEAD 没有任何新的 migration / schema 变更。
模型目录 · Admin 配置（非代码发布维度）
管理入口：Admin → Models → Model list（Provider / 模型 / 价格 / 发布状态）与 Model routing（路由）；数据库是配置事实源。
配置事实源：目标环境数据库；核验状态：本轮无 feature 依赖模型目录配置操作，未做独立只读核验（待核验）。
证据与观察时间：未核验（本轮发布判断不依赖该配置）；如需确认请以目标环境 Admin / 数据库只读结果及审计记录为证。
现有环境无需运行 deploy-model-routing-catalog-prod.yml；该 workflow 仅用于全空目录初始化，任一目录表已有数据即跳过。上次成功 run #3923 @ 2026-10-08T06:37:30Z（f3ab9fccd）不能作为目录配置已生效的证据。
发布点之后有 2 个 commit 触及 catalog 源（db/seeds/、data/json/）：cb6e014f4（#159 bootstrap 守卫）与 5b655e207（#170 输出上限 metadata）。两者都是 seed / 生成器侧改动，对已初始化的生产目录是 no-op，不构成现有环境待发布的目录数据。data/json/public_pricing.json（#146 / #158 / #209 更新）属该 catalog 生成器源数据，不是 Public Pricing API 的发布源。
Public Pricing · 独立发布流程（核验结论）
发布点：最近成功 run #2813 @ 2026-09-24T09:03:05Z（trigger workflow_dispatch，commit 0ab43a985）。
核验 1（本次采样）：本地 main（a96eefe50）执行 pnpm --filter @vela/api pricing:plan 得到目标 revision 93e51aaf…（planCount 9 = 5 personal + 4 team），与生产 active revision 完全一致。
核验 2：生产 GET /api/v1/public/pricing/latest（amr-api.open-design.ai）返回 revision=93e51aaf86617b5314a5ed9a08aa8fd5c24413a9c0357aa402c8773a15a9acfb、publishedAt=2026-09-24T09:07:34.435Z、schemaVersion=1、9 个 plan；ETag 与 body revision 一致、Cache-Control: public, max-age=300。
结论：本轮不需要重新发布 Public Pricing（源与生产一致）。观察时间：2026-10-14T02:04Z 前后（本地命令 + 生产只读 GET）。

此次发布真正新增的 feature 和影响面

feature 表只包含「各维度生产发布点之后」的变更：四个服务以 EKS Pod 实态为基线，DB migration 以 workflow 记录为基线；Admin 模型配置操作与核验证据单独列出。发布点之前已生效的内容见 「已在生产生效」，不要重复列入。

结论：本轮共 2 个 feature 有待发布内容，实际只落在 API 与 Link 两个维度（Web / Admin / DB migration 三个维度发布点之后没有净变更）： ① a96eefe50（#248，lefarcen）AMR 独立资金状态提示 fundingCheck——在既有认证预检端点上新增只读三态字段，同时给这个既有端点加上并发上限 / 2 秒截止 / 503 卸载与正向缓存，属 API 契约 + 端点可用性语义变更；要真正在用户侧生效还需 Vela CLI 稳定版发布与 OD 侧消费，属跨仓库交付； ② c07e72e0a（#258，Liu Yi）Link 供应商参数与工具 ID 兼容修复（OPEND-3756）——一次性修掉 7 类已在真实上游复现的 400 失败，只改 Link（含 2 个 vendor patch），无 schema、无配置依赖。 按影响面排序：#248（XL，API 既有端点语义 + 跨仓库依赖）> #258（L，Link 线上失败修复）。

Feature / Author / Commits Web API Link Admin DB schema / migration Admin 模型配置操作
XLAMR 独立资金状态提示：预检新增 fundingCheck 只读三态（#248）

在既有的已认证预检端点 GET /api/v1/workspaces/{workspaceId}/billing/preflight 上新增可选字段 fundingCheck: available | insufficient | unknown，让 Open Design 能在 agent 启动的同时给出「资金是否可用」的早期提示，而不再只能等网关准入失败。既有 funding（coding_plan / wallet / gateway）字段与 Link 准入逻辑不变。判定规则：

① 三态语义：Coding Plan 配额可用优先于空钱包，钱包余额为正也算 available；只有同时满足「Coding Plan 配额不可用 + 钱包非正 + 每条 active 模型路由都可证明确实收费 + 该 member 没有 enabled 或在途的自动充值」才给 insufficient；缺模型 / 配置 / 价格证据时保持 unknown。只读：不预留额度、不扣卡、不取消执行、不授予准入；PR 自述 insufficient 只是早期提示，永远不是取消指令。

② 既有端点的可用性语义变更（本轮真正的风险点）：同一个 handler 现在在认证触达数据库之前限流——每 API 实例最多 min(8, floor(PG_POOL_MAX / 4)) 个并发预检（PG_POOL_MAX 代码默认 10 → 每实例 2 个，本 Run 未核验生产环境变量实际取值），不排队，超出直接 503 billing_preflight_unavailable + Retry-After: 1；每请求 2 秒截止，超时的工作仍占用槽位直到底层操作真正结束；PG_POOL_MAX < 4 时该能力被禁用。此前这个端点是无并发上限、无截止时间的。

③ 缓存与身份边界：只有新鲜通过认证 + 工作区授权的请求可以共享 member/model 读结果或命中 5 秒正向缓存（键含 user + workspace + member + model，每实例最多保留 1,000 条正例）；负例与错误不缓存，缓存不绕过成员撤销；Cache-Control: private, no-store 现在覆盖所有分支（含错误分支）。

④ 消费端与降级：OD 把该字段当纯早期 UI 反馈，遇到 503 / 超时按 unknown 处理，不 await 该预检、不自动重试；Link 仍然拥有准入权——过载只会抑制早期提示，不会拒绝或取消 agent run。旧版 API / CLI 没有该字段时 OD 退化为 unknown 并最终由网关错误兜底，因此 API 与 Vela CLI 必须一起发布才能拿到独立早期反馈。

Author：lefarcen

  • a96eefe50 feat(billing): expose independent funding feedback for AMR（#248）

PR 自述验证范围：root pnpm lint（Biome + 全工作区类型检查）；make -C apps/cli test-ci（格式化 / vet / 全量 Go 测试 / Python 打包测试 / 原生与 Windows 交叉构建）；50 个聚焦 preflight 测试；托管 PostgreSQL E2E services/api/test/e2e/billing-funding-constraints.test.ts（paid / free / missing pricing、personal-team 隔离、member override、已删除 override、禁用策略下的在途充值、identity mismatch）；HTTP 突发回归在旧实现上 red（1,000 个请求全部进入 auth）、修复后 green（2 admitted / 998 shed，同 member 读合并）。这些是确定性故障 / 突发测试与 mock 依赖，不是生产 QPS 基准；PR 明确说明限流是每实例而非集群级，生产吞吐与数据库争用需要代表性压测与监控后才能断言容量。

 无（该提交未改 apps/web/）。 待发布：services/api 7 files，+742 / −80：src/billing/http/routes.ts（+111 / −60，预检 handler 重构为限流 + 截止 + 缓存 + 新字段）、新增 src/billing/preflight-load.ts（91 行，BillingPreflightUnavailableError / 并发与正向缓存）、src/billing/preflight.ts（+104，billingFundingCheck 三态判定）、src/persistence/users.ts（+16，funding constraints 读取）；测试 test/billing-preflight-load.test.ts（+119）、test/billing-preflight.test.ts（+173 / −20）、test/e2e/billing-funding-constraints.test.ts（+128）。
同一提交另改 packages/shared/src/index.ts（+2，schema 新增可选 fundingCheck）与 apps/cli（2 files，+3 / −1，BillingPreflightResponse 透出字段）——后者属 Vela CLI 独立发布通道，见「发布建议」。
发布后要盯 503 比例：按默认连接池只有每实例 2 个并发预检名额。		 无（该提交未改 services/link/）。 无（该提交未改 apps/admin/）。 无 schema / migration（PR 明确「不含部署、数据库 migration 与网关策略变更」）。 无模型目录配置操作：该字段仅只读现有 Provider / 模型 / 价格 / 路由与 member 充值策略，不需要也不应该在 Admin 里改任何配置。
但 insufficient 的正向判定依赖「每条 active 路由都可证明确实收费」与在途充值证据，该配置现状本轮未做独立只读核验（待核验）；证据缺失时该字段按设计退化为 unknown，不影响准入，因此不阻塞发布。
LLink 供应商参数与工具 ID 兼容修复（OPEND-3756，#258）

修复 OPEND-3756 下 7 类已在本地真实供应商链路复现的上游拒绝，全部只落在 Link（含 2 个必要的 vendor patch），无 schema、无 Admin 配置依赖：

① ZAI GLM（glm-5.3-flash / glm-5.3-flashx）：把 minimal → low、xhigh → high 的兼容别名移到「校验原生 GLM 档位」之前，让兼容写法能走到 OpenAI 兼容序列化器；原先是 16/16 本地 400。

② DeepSeek 显式 json_object（deepseek-flash）：上游要求提示里必须出现 json，本次在结构化输出准备阶段补一条固定格式 system 指令（幂等，已存在则不重复追加），不新增 schema 校验、不做流式缓冲。

③ Vertex Gemini Flash（gemini-3.7-flash / gemini-3.8-flash）：这两个版本最低档是 low，把 minimal → low；disabled / 未知档位与其它 Gemini 模型保持不变。

④ Bedrock Opus 5.5 thinking + temperature：上游在 thinking 生效时只接受 temperature=1；本次在 Chat 与 Responses 两条入站路径上省略冲突的 temperature，同时保留显式关闭 thinking 与已经兼容的取值，不改 reasoning 本身。

⑤ Bedrock 历史里的超长工具 ID：超过 64 字符的 toolUseId 会被上游按精确长度拒绝。本次只改最终供应商报文——先保留已有短 ID，再把超长 ID 稳定映射为 50 字符别名（排序保证碰撞处理与历史顺序无关），call / result 配对一致，回显时按请求映射恢复原 ID。

⑥ Aliyun Kimi（kimi-k2.7-code，Chat 上游）：与 DeepSeek 同一处 Provider 边界，把上游不支持的 developer 角色在保留内容与顺序的前提下改为 system。

⑦ Chat-backed Responses 工具流：item id 原先直接等于 call_id = call_…，原生 OpenAI Responses 回放要求 item id 以 fc 开头；本次改成独立 fc_… item ID（added / delta / done / completed 全流程一致），call_id 继续保留 call_…，工具结果回放不变。

明确不改：ZAI 不支持的 effort 仍显式失败；Bedrock 别名只作用于最终报文，不补造缺失的工具结果或参数；工具流测试不承诺「同一 chunk 多工具起始」。两个 vendor patch 的失败证据、维护与移除条件记录在 specs/link/bifrost-patches.md 与当前 provider / Bedrock 契约中。

Author：Liu Yi

  • c07e72e0a fix(link): normalize provider parameters and tool IDs (OPEND-3756)（#258）

PR 自述验证（本地 named sandbox → 真实收费上游）：Red 阶段 ZAI 16/16 400、DeepSeek 2/2 400、Vertex 4/4 400、Opus 2/2 400、Bedrock 工具 ID 3 次精确长度 400 + 1 次超时、Kimi 2/2 400、原生 OpenAI 回放 400（item ID 必须以 fc 开头）；Green 阶段共 33 次成功请求，均经过认证 / 路由 / 网关与真实计费上游，返回完成内容与非零 usage；make -C services/link check、vendor go test ./schemas ./providers/bedrock、Python 编译与 git diff --check 通过。是与错误条件一致的合成请求，不声称重放了客户私有 payload；修复尚未部署。OPEND-3820 按要求暂停，不含其候选修复；OPEND-3774（其余供应商策略）仍待调查。

 无。 无（该提交未改 services/api/）。 待发布：services/link 15 files，+611 / −21：internal/providercompat/（adapter.go +6 / −3、structured_output.go +17 / −1、text.go +39 / −1，新增 Opus temperature 处理与 GLM / Vertex 别名）+ 3 个新测试（+147 / −2）；internal/bifrostengine/ 2 个回归测试（+69 / −5）；third_party/bifrost-core/ 4 files +304 / −7（新增 providers/bedrock/tool_ids.go 80 行 + 132 行测试、schemas/mux.go 的 fc_ item ID、providers/bedrock/{chat,responses}.go 的 ID 归一 / 恢复）；e2e/link 4 files（+232 / −3，含 provider-compat-followup.sql / zai-effort.sql fixtures 与 138 行复现脚本）；3 个 spec 文档（+56）。
必须确认全部 8 个副本滚动完成（同一 commit、同一 digest、spec = updated = available = 8）后才算发布完成。		 无。 无 schema / migration。 无模型目录操作：参数归一与 tool ID 别名都在 Link 代码 / vendor patch 内完成，不需要在 Admin 里改 Provider / 模型 / effort 默认值 / 路由。未核验（无需核验）。

范围内其余 commit 不产生五个维度的净变更： Web 的 compare range（72252761d...a96eefe50）覆盖 2 个 commit（c07e72e0a、a96eefe50），0 个触及 apps/web/； API 的 compare range（72252761d...a96eefe50）覆盖 2 个 commit，只有 a96eefe50 触及 services/api/（c07e72e0a 只改 services/link/）； Link 的 compare range（72252761d...a96eefe50）覆盖 2 个 commit，只有 c07e72e0a 触及 services/link/； Admin 的 compare range（72252761d...a96eefe50）覆盖 2 个 commit，0 个触及 apps/admin/； DB 的 compare range（806b12365...a96eefe50）覆盖 3 个 commit（72252761d、c07e72e0a、a96eefe50），0 个触及 db/migrations/ + db/schema/。 另有两处不在五个维度内：① 72252761d（#151，Siri-Ray）只改 apps/cli/（在静默 turn 上主动结束而不是等满 30 分钟上限），Vela CLI 走独立发布通道 vela-cli-release.yml（npm 版本发布，手动 dispatch），不属于 EKS 服务 / DB 发布维度——它恰好是四个服务当前镜像的构建 commit，但对该四个服务无 runtime 变更，且 Web / Admin 的 compare range 里已经包含它；② #248 里的 apps/cli/ + packages/shared/ + .forgejo/workflows/vela-cli-package.yml 部分同样属 CLI 独立通道（详见 feature 表第 1 行与「发布建议」）。

已在生产生效（发布点之前，本次不重复发布）

以下 feature / commit 均在对应生产发布点之前，已在生产运行。四个服务以 EKS Pod 实态为基线，DB migration 以 Forgejo workflow 记录为基线；若从 main 重新发布，只分析各自基线之后的净新增。

发布建议

  1. Migration 判断：本次不需要跑 migration。BASE_DB 806b12365（2026-10-13T08:24:04Z apply）已包含仓库最新一份 migration（db/migrations/20261012113538_coding_plan_quota_resets.sql），基线之后到 HEAD 的 3 个 commit 0 个触及 db/migrations/ / db/schema/，因此不要 dispatch deploy-db-migrations-prod.yml。
  2. 服务发布顺序（本轮）：只有 API 与 Link 有净变更，两者互不依赖，可任意顺序或并行滚动；Web / Admin 无净变更，重新发布只是把同一份代码再滚动一次（不产生行为变化），可以跳过：
    • 1) API：触发 deploy-api-eks-prod.yml 发布 a96eefe50（#248，services/api 7 files +742 / −80 + packages/shared schema）。注意这是对既有预检端点的行为变更：默认 PG_POOL_MAX=10 时每 API 实例只允许 2 个并发预检，超出 503 + Retry-After: 1，且有 2 秒响应截止。发布前请确认生产实际 PG_POOL_MAX 取值（本 Run 未核验），并按 min(8, floor(PG_POOL_MAX/4)) 复核每实例名额；若观察到 OD 早期提示频繁退化为 unknown，先判断是否被 billing_preflight_unavailable 卸载（这是可选提示的预期降级路径，不需要立刻回滚 API）。
    • 2) Link：触发 deploy-link-eks-prod.yml 发布 c07e72e0a（#258，services/link 15 files +611 / −21，含 2 个 vendor patch）。必须确认 8 个副本全部滚动完成（同一 commit、同一 digest、spec = updated = available = 8）——本轮无 migration、无配置依赖，发布本身没有前置条件。
    • 3) Vela CLI（跨仓库前置条件，不是 EKS 发布）：#248 的字段要在用户侧真正可用，需要走 vela-cli-release.yml（手动 dispatch + npm 发布）出一个带 fundingCheck 的稳定版。本 Run 只读观察 npm registry：@powerformer/vela-cli 的 latest 仍是 0.1.3（2026-09-20T08:37Z，早于本仓库所有 apps/cli 十月份改动），test 通道为 0.1.4-test.1（2026-10-13T08:44Z，source 6ec4e93b4）。结论：带该字段的 CLI 尚未进入稳定通道，需要单独安排 CLI 版本发布；在那之前 OD 会按 unknown 降级。
    • 4) OD（外部仓库）：消费端在 nexu-io/open-design（草稿 PR #8688，commit 16fcf2b），不属于 AMR 发布范围；AMR 侧 API + CLI 到位后，OD 才能拿到独立早期提示。
  3. Catalog / Admin 模型配置判断：不需要触发 deploy-model-routing-catalog-prod.yml，也不需要任何 Admin 模型目录操作——#248 只读现有 Provider / 模型 / 价格 / 路由配置（证据缺失时退化为 unknown），#258 完全在 Link 代码内完成。现有环境若触发该 workflow 只会打印跳过提示；不要用历史 seed 或手工 SQL 去「回填」或回滚既有配置。配置现状（含 insufficient 判定所依赖的路由收费 / 充值策略证据）本轮未核验（待核验），不阻塞本次发布。
  4. Public Pricing 判断：不需要发布。本地 pricing:plan 计算出的 revision 与生产 active revision 93e51aaf… 一致（见上，2026-10-14T02:04Z 核验），因此不要为本次发布 dispatch deploy-public-pricing-prod.yml——该 workflow 没有只读模式，每次 dispatch 都是真实生产写入。
  5. 发布后观测：
    • Pod 实态：API 应从 72252761d 滚动到 a96eefe50，Ready 恢复 2/2；Link 应从 72252761d 滚动到 a96eefe50，Ready 恢复 8/8；两者都应满足同一 commit、同一 digest、spec = updated = available。
    • #248（API）：观察 GET /api/v1/workspaces/{workspaceId}/billing/preflight 的 503 billing_preflight_unavailable 比例与 Retry-After、2 秒截止命中率、以及被占满的并发槽是否能在底层 SQL 结束后释放；确认 fundingCheck 三态分布与 funding 自洽（available 与「Coding Plan 可用或钱包为正」一致，insufficient 必须同时满足四个条件）；确认负例 / 错误未被缓存、5 秒正向缓存没有跨身份泄漏、缓存未绕过成员撤销；确认 Cache-Control: private, no-store 在成功与失败分支都存在；如果这是一个新引入的容量瓶颈，先看是否只影响这次新增的可选预检调用方（Link 准入不依赖该端点，agent run 不应因此被拒绝）。
    • #258（Link）：对 glm-5.3-flash / glm-5.3-flashx、deepseek-flash（显式 json_object）、gemini-3.7/3.8-flash（minimal）、Bedrock claude-opus-5-5（thinking + temperature）、Bedrock 超长工具 ID 历史、kimi-k2.7-code（developer 角色）、Chat-backed Responses 工具流 7 类场景，确认上游 400 归零并返回非零 usage；确认 Responses 流里 item id 为 fc_…、call_id 仍为 call_…，Bedrock 回显按原 ID 恢复；确认 ZAI 不支持的 effort 仍然显式失败（不应被静默改成合法档位），Bedrock 工具结果的缺失参数没有被补造。
    • 回归项（已生效，仅抽查）：#243 的 Admin 重置页面 / coding_plan_quota_resets 表、#164 的 Admin Activities Test 活动分页、#254 的 gateway_model_output_tokens_per_second 指标、#245 的定价页 Go 5 小时列 $10。
    • Public Pricing（仅核对，无需发布）：GET /api/v1/public/pricing/latest 应继续返回 revision=93e51aaf…，ETag 与缓存头正常。

备注：本报告所有 workflow、commit、PR 与 compare range 均指向 Forgejo code.powerformer.net/core/amr，不使用 GitHub Actions。四个服务的 compare range 基于 Grafana / Prometheus 观察到的 Ready Pod 镜像 commit（而非 GitOps / workflow 最近成功记录）；DB migration 的 compare range 基于 deploy-db-migrations-prod.yml 最近一次成功运行的 commit_sha；四个服务维度另附对应 deploy-*-eks-prod.yml 最近成功记录作为审计对照，本次四者与 Pod 实态全部一致。Admin 模型配置没有 Git compare range，本轮无依赖项，核验状态记为「待核验」；Public Pricing 为独立发布流程，按源 revision 与生产 active revision 的一致性判断。