同步图片 provider 路由白名单与启动日志文档

ADR 补充业务名与 gpt-image-2-c 的拒绝规则

决策记录补充启动报错点名环境变量与启动日志

docs/adr/【ADR】GPT Image 2.5模型路由与历史值兼容-2026-09-18.md

@@ -6,6 +6,8 @@
 
 图片协议执行逻辑保持 provider-neutral：请求 body、multipart、尺寸约束、重试、响应解码和审计由共享 image executor 承担；VectorEngine 与 Tiantoken client 只提供相同协议所需的 base URL、API key 和 provider identity。platform-image 根据 concrete model 做严格白名单路由：`gpt-image-2.5-flare-c` 与 `gpt-image-2.5-sunburst-c` 走 Tiantoken，`gemini-3.1-flash-image-preview`（nanobanana）走 VectorEngine；未知 model 直接拒绝。已持久化的 `gpt-image-2` / `gpt-image-2-c` 只在新任务提交边界按兼容规则解析为当前 GPT Image 2.5 任务，不改写历史资源，也不进入旧 VectorEngine 图片路由。
 
+provider 白名单同时拒绝两类非 provider model：业务模型名 `gpt-image-2.5` 必须先由 api-server 在任务边界解析成 `gpt-image-2.5-flare-c` / `gpt-image-2.5-sunburst-c`；`gpt-image-2-c` 自兜底移除后只是历史 fallback / 审计字符串，永不作为 provider 或业务 model 传入，命中即拒绝。`gpt-image-2` 继续作为历史可读值接受。历史值仍只出现在审计与提交边界兼容层，不进入 provider 路由。
+
 普通主站前端只接触业务模型和新生成展示名 `GPT Image 2.5`，admin Web/API 可以查看和编辑两个具体定价 key；普通生成即使因参考图使用 edits multipart，仍按生成 concrete model。旧 `gpt-image-2-c` 审计记录原样保留，新代码不再跨模型或跨 provider fallback。
 
 主站前端只把原本明确使用 GPT Image 2 的专用新任务改为业务模型值 `gpt-image-2.5`；普通图片、角色、场景、图标等原有 nanobanana 默认行为保持不变。画布参数或编辑布局读到 `gpt-image-2` / `gpt-image-2-c` 时，在使用端解析为 `gpt-image-2.5` 并触发参数迁移警告，原始资源、审计、metadata 和历史 fixture 不回写。AGC 现有资源生成界面与请求默认保持不变，不因本决策新增模型字段、选择器或尺寸行为。
@@ -15,5 +17,6 @@
 - 定价配置的活动 key 是两个具体 provider model；旧单 key 配置只允许受控 backfill，并留下兼容 TODO。
 - 新任务的同模型重试固定使用 api-server dispatch 的具体 model，不切换到另一个 model。
 - 两套 provider client 在 api-server 启动阶段同时构造；任一 required provider 配置缺失，启动失败而不是延迟到首次图片请求。
-- provider routing 只依据 concrete model 的白名单；provider client 不复制共享协议执行逻辑。
+- 两套 provider client 的缺失配置报错点名对应环境变量（`VECTOR_ENGINE_BASE_URL` / `VECTOR_ENGINE_API_KEY`、`TIANTOKEN_BASE_URL` / `TIANTOKEN_API_KEY`），构造成功后用启动日志记录已启用的 provider。
+- provider routing 只依据 concrete model 的白名单，业务名与已退役的 `gpt-image-2-c` 一律拒绝；provider client 不复制共享协议执行逻辑。
 - 公开资源、`generationInputs` 和普通前端契约不包含具体 provider key；admin 定价管理是明确例外。

docs/project-memory/shared-memory/decision-log.md

@@ -1,5 +1,18 @@
 # 决策记录
 
+## 2026-09-21 图片 provider 路由白名单拒绝业务名与已退役的 gpt-image-2-c
+
+- 背景：GPT Image 2.5 迁移后，`resolve_image_provider` 仍把业务模型名 `gpt-image-2.5` 与历史 `gpt-image-2-c` 一起判为 Tiantoken，等于把「非 provider model」留在 provider 边界的白名单里。`gpt-image-2-c` 自 2026-07-21 起只是首选模型失败时的兜底 provider model，兜底移除后仅剩历史审计字符串；api-server 的图片请求一律传具体 `provider_model`（`gpt-image-2.5-flare-c` / `gpt-image-2.5-sunburst-c` / nanobanana）。
+- 决策：`resolve_image_provider` 白名单只接受现役具体 provider model；业务名 `gpt-image-2.5` 与 `gpt-image-2-c` 命中即拒绝（`不支持的图片模型`）。业务名仍由 api-server 在任务边界解析成具体 key；`gpt-image-2-c` 只作为历史 fallback / 审计字符串存在，永不参与路由；`gpt-image-2` 继续作为历史可读值接受。
+- 影响范围：`server-rs/crates/platform-image/src/image_provider/protocol/request.rs` 与其集成测试。提交边界（画布参数、Agent 工具参数、External v1 请求 DTO、前端历史布局恢复）对 `gpt-image-2` / `gpt-image-2-c` 的兼容解析保持不变。
+- 验证：`cargo test -p platform-image` 22 项通过，新增 `resolve_image_provider_rejects_business_model_and_accepts_concrete_models`；`cargo test -p api-server` 1115 项通过。
+
+## 2026-09-21 图片 provider 启动期缺配置的报错点名环境变量
+
+- 背景：两个图片 provider client 都在 `AppState::new` 构造，缺 base URL / API key 即阻止 api-server 启动；旧报错只写「tiantoken 图片 provider 缺少 BASE_URL 配置」，没有点名变量名，而 `TIANTOKEN_*` 已不再从 `VECTOR_ENGINE_*` 回退，运维迁移时不易定位。
+- 决策：保持「不回退、缺失即启动失败」，但报错文案补上具体变量名（`VECTOR_ENGINE_BASE_URL` / `VECTOR_ENGINE_API_KEY` 或 `TIANTOKEN_BASE_URL` / `TIANTOKEN_API_KEY`）；client 构造成功后用 `info` 记录 provider、base_url、超时与对应 env 变量名，便于确认实际生效的 provider 配置。
+- 验证：`cargo check -p api-server` 通过；`cargo test -p api-server` 1115 项通过（0 失败）。
+
 ## 2026-09-21 渠道进安装身份：不同渠道的 AGC 包体在同一台设备并存
 
 - 背景：渠道此前只决定更新端点（`plugins.updater.endpoints`）与渲染层平台 origin，`productName` / `identifier` 与渠道无关，于是所有渠道共用 `%LOCALAPPDATA%\陶泥儿` 安装目录、同一个卸载项（`HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall\陶泥儿`，另有 `HKCU\Software\genarrative\陶泥儿`）以及同一份 `%APPDATA%\world.genarrative.ai-game-creator` 数据目录。本机 0.1.48 安装实测：主程序二进制里只有 1 处 `agc/dev-win/latest.json`、0 处 release 端点，说明渠道在产物里只体现为端点。后果是后装的渠道静默顶掉先装的渠道，并接管更新端点、平台服务器与本地登录态/项目数据。