diff --git a/local-docs/【修复记录】Issue226跨Origin重定向标记泄漏修复-2026-09-02.md b/local-docs/【修复记录】Issue226跨Origin重定向标记泄漏修复-2026-09-02.md
deleted file mode 100644
index ca6b18e5b..000000000
--- a/local-docs/【修复记录】Issue226跨Origin重定向标记泄漏修复-2026-09-02.md
+++ /dev/null
@@ -1,84 +0,0 @@
-# Issue #226:跨 origin 重定向标记泄漏复审修复
-
-更新时间:2026-09-02
-关联 Issue:`#226 添加客户端特殊标识`;交接 Issue:`#225 添加客户端埋点统计`
-
-## 1. 修复结论
-
-采纳评审意见:AGC 主站 Client 的默认重定向策略不能继续使用 reqwest 的“任意 origin 默认跟随”,否则 `default_headers` 中的 `X-Genarrative-Client: agc` 可能被复制到 OSS 或第三方 origin。
-
-本次修复将工厂默认策略调整为:
-
-- 目标 URL 与原始请求 URL 的完整 origin(scheme + host + effective port)相同:委托 reqwest 默认 redirect policy。
-- origin 不同:`stop`,返回当前 3xx,不发起下一跳请求。
-- 无法取得原始 URL 或 origin 无法确认:按 fail-closed 处理,停止重定向。
-
-这不是把 factory 改成全局 `Policy::none()`。同 origin 的 redirect 仍保留原有默认限制、方法和请求体处理;调用点显式设置的 `Policy::none()` 继续有效。
-
-另针对评审发现的同名 Header 覆盖缺口,补充了主站请求终结器:`default_headers` 继续负责普通请求的默认注入;所有已审计的 AGC 主站请求在发送前统一调用 `with_agc_main_site_marker`,使用 `RequestBuilder::headers` 替换调用方可能传入的同名 Header,确保最终值固定为 `agc`。
-
-## 2. 修改范围
-
-修改 AGC Rust HTTP Client factory、主站请求终结器、已审计主站直发调用点和定向测试:
-
-- `apps/ai-game-creator-shell/src-tauri/src/http_client.rs`
-- 已审计主站请求所在的 `assets.rs`、`commands.rs`、`canvas_generation.rs`、`direct_runtime.rs`、`direct_tool_bridge.rs`、`project/asset_canvas/generation.rs`、`project/resource_editor.rs`
-- 本地实施方案、阶段计划和本复审记录
-
-不修改:
-
-- #225 的主站 tracking、数据库和后台代码。
-- OSS/签名下载、Provider、受控搜索、loopback、更新下载等第三方 Client。
-- 各业务调用点的 timeout、connect timeout、认证、幂等或请求体逻辑。
-
-## 3. 重定向行为契约
-
-| 场景 | 处理 | 标记是否到达下一跳 |
-|---|---|---:|
-| 同 scheme、host、effective port | 继续按 reqwest 默认策略 | 是,仍是主站 origin |
-| scheme、host 或端口任一不同 | 返回当前 3xx,不 follow | 否,不发起请求 |
-| 调用点显式 `Policy::none()` | 继续不 follow | 否 |
-
-使用 `Url::origin()` 比较,不比较 URL 字符串前缀;路径、查询参数和 fragment 不参与 origin 判断。
-
-## 4. 同名 Header 覆盖契约
-
-`reqwest` 的 `ClientBuilder::default_headers` 只会为请求补充缺失字段,请求级同名 Header 默认优先。因此不能把 `default_headers` 单独当作“不可伪造”的约束。
-
-当前实现由两层组成:
-
-- factory 设置 `default_headers`,覆盖普通未显式设置 Header 的请求;
-- `with_agc_main_site_marker(request)` 在主站请求发送前用 `RequestBuilder::headers` 替换同名字段。`external_editor_json_request` 已内置该终结器,直接 `.send()` 的主站路径也显式经过该终结器。
-
-这样既保留方案一的 Client factory 形态,又满足“调用方传入同名 Header 时最终仍为 `X-Genarrative-Client: agc`”的冻结契约。
-
-## 5. 测试证据
-
-新增或调整 `http_client` 定向测试,覆盖:
-
-- 完整 origin 比较:默认端口等价,scheme/host/非默认端口变化视为跨 origin。
-- 同 origin 302:下一跳实际收到 `X-Genarrative-Client: agc`,最终响应成功。
-- 跨 origin 302:当前响应为 302,外部 listener 没有收到连接。
-- 显式 `Policy::none()`:仍然覆盖 factory 默认策略。
-- 请求级伪造同名 Header:终结器覆盖调用方值,服务端只收到 `agc`。
-
-验证命令及结果:
-
-```text
-cargo test --locked --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml http_client -- --nocapture
-8 tests passed
-```
-
-## 6. 对 #225 的交接
-
-本修复不改变 Header 契约:
-
-```http
-X-Genarrative-Client: agc
-```
-
-主站只会收到客户端实际发出的主站请求;跨 origin 3xx 不会产生第二个第三方请求,因此不会出现客户端把该标记发送到 OSS/第三方 origin 的情况。#225 不需要回改 tracking、数据库或后台设计。
-
-## 7. 后续限制
-
-`agc_main_site_client_builder()` 仍返回原始 `reqwest::ClientBuilder`,理论上调用方可以再次覆盖 redirect policy,或新增请求时绕过终结器。当前已审计生产调用点均已经过终结器,只有显式 `Policy::none()` 的 redirect 覆盖,没有重新启用任意 origin follow 的调用。若未来需要类型级不可绕过,再单独评估 `AgcMainSiteClient` wrapper,不在本次复审修复中扩大范围。
diff --git a/local-docs/【实施方案】Issue225-AGC主站请求标记埋点统计-2026-09-02.md b/local-docs/【实施方案】Issue225-AGC主站请求标记埋点统计-2026-09-02.md
deleted file mode 100644
index 45311511f..000000000
--- a/local-docs/【实施方案】Issue225-AGC主站请求标记埋点统计-2026-09-02.md
+++ /dev/null
@@ -1,342 +0,0 @@
-# Issue #225:AGC 主站请求标记埋点统计实施方案
-
-更新时间:2026-09-02
-关联 Issue:
-
-- `#225 添加客户端埋点统计`:本文全部实施范围
-- `#226 添加客户端特殊标识`:客户端侧已完成;本文只接收其固定交接契约,不回改客户端
-
-当前状态:阶段 0~6 已完成。主站生产代码和定向测试已按阶段提交;阶段 6 仅补充最终门禁、交接与验收文档。未修改 SpacetimeDB schema、OpenAPI 或后台页面。
-
-## 1. 一句话交付结果
-
-主站 `api-server` 能识别 AGC 发来的 `X-Genarrative-Client: agc`,并在本期新增的 AGC 专用成功路由埋点写入 `tracking_event.metadata_json` 的 `client: "agc"`,同时按真实登录用户或 External API Key 的 `owner_user_id` 归属,后台可以通过现有 tracking 事件查询看到这类请求;既有 route tracking 和手工资产事件保持原有全客户端统计口径,不改变鉴权、计费、幂等和响应语义。
-
-## 2. Issue 边界
-
-### 2.1 本次只做 #225
-
-本次主改动限定在主站后端:
-
-- `server-rs/crates/api-server/src/app.rs` 的 tracking middleware 入口。
-- `server-rs/crates/api-server/src/tracking.rs` 的标记识别、主体归属、metadata 合并和 route tracking 覆盖。
-- 必要的 `api-server` 定向测试、External v1 路由测试和后台 tracking 读取验证。
-- 方案、验收、交接文档。
-
-### 2.2 本次不做 #226 的回改
-
-不修改:
-
-- AGC TS 的 `fetchClientHttp` 标记注入。
-- AGC Rust 主站 Client factory、请求终结器和 redirect policy。
-- AGC 主站/第三方请求边界、timeout、认证、幂等和请求体语义。
-
-`#226` 已冻结并合入的客户端契约直接作为本 Issue 的输入。
-
-### 2.3 明确不做项
-
-- 不新增 `tracking_event` 列、索引、migration 或生成 bindings;第一阶段复用已有 `metadata_json`。
-- 不新增平行的 `agc_client_request` 事件、平行表或平行统计口径。
-- 不改变 `/api/external/v1` 的路由、HTTP 方法、DTO、状态码、鉴权或异步语义,因此不改 OpenAPI 契约。
-- 不把 `generationInputs.source`、User-Agent、请求体中的 owner 字段当作客户端来源或主体。
-- 不记录 access token、External API Key 明文、Cookie、签名 URL、项目绝对路径或其他秘密。
-- 不把 OSS 上传、签名 URL 实际下载、LLM/Codex Provider、受控搜索、loopback、更新下载和任意外部网页请求当成主站业务 tracking。
-- 不默认把失败响应改造成新的 tracking 事实;先保持现有“成功响应才写 route tracking”语义。
-- 不默认新增后台筛选控件;后台先复用现有 tracking 原始事件查询展示 `metadata_json`。
-
-## 3. 当前实现基线与缺口
-
-### 3.1 现有 tracking 流程
-
-当前全局链路位于:
-
-- `server-rs/crates/api-server/src/app.rs`
-- `server-rs/crates/api-server/src/tracking.rs`
-
-流程为:
-
-```text
-请求进入
- → tracking middleware 保存 method/path
- → next.run(request)
- → 从 response extensions 读取认证主体
- → 仅对成功响应解析 RouteTrackingSpec
- → 生成 TrackingEventDraft.metadata
- → 本机 tracking outbox
- → SpacetimeDB tracking_event / tracking_daily_stat
-```
-
-现有 `AuthenticatedAccessToken` 和 `ExternalApiPrincipal` 都会在认证 middleware 成功后写入 response extensions;但 tracking middleware 目前只消费前者。
-
-### 3.2 当前缺口
-
-- tracking middleware 尚未读取 `X-Genarrative-Client`。
-- route metadata 尚未写入 `client`。
-- External API Key 的 `ExternalApiPrincipal.owner_user_id` 尚未接入 route tracking 归属。
-- `/api/external/v1/*` 没有完整的 route tracking spec。
-- 账号态实际被 AGC 使用的 `/api/editor`、`/api/assets`、`/api/runtime` 路径也有未覆盖项。
-
-## 4. 冻结的 #226 交接契约
-
-### 4.1 Header 识别
-
-```http
-X-Genarrative-Client: agc
-```
-
-规则:
-
-- Header 名按 HTTP 规则大小写不敏感。
-- 值去除首尾空白后,精确等于小写 `agc` 才认定为 AGC。
-- 缺失、空值、`AGC`、其他未知值均按“未标记”处理。
-- 未标记请求不被拒绝,也不改变业务行为。
-- Header 只用于来源审计和统计,不参与鉴权、权限、计费、幂等或账号归属。
-
-### 4.2 metadata 形态
-
-第一阶段复用已有 `tracking_event.metadata_json`,在原对象上追加固定键:
-
-```json
-{
- "route": "/api/editor/images/generations",
- "method": "POST",
- "status": 202,
- "operation": "generateExternalEditorImage",
- "client": "agc"
-}
-```
-
-约定:
-
-- JSON key 固定为 `client`,值固定为 `agc`。
-- 有效标记时追加 `client`;未标记时不写 `client`,不写空字符串或 `null`。
-- 已有 `route`、`method`、`status`、`operation` 以及资产类嵌套 metadata 必须保留。
-- `route` 使用主站实际收到的 method/path;External v1 不得只记录客户端账本中的内部映射路径。
-
-### 4.3 认证主体归属
-
-| 请求类型 | `user_id` | `owner_user_id` | `scope_kind/scope_id` | 说明 |
-|---|---|---|---|---|
-| 登录账号态 | 沿用 `AuthenticatedAccessToken.claims().user_id()` | 沿用现有行为,通常与 user_id 相同 | 沿用 route spec;User scope 使用真实用户 | Header 不能覆盖真实认证主体 |
-| External API Key 态 | 不伪造登录用户,可为空 | `ExternalApiPrincipal.owner_user_id()` | User scope 使用 owner_user_id | 归属 API Key 所属账号 |
-| 无认证的公开/站点请求 | 为空 | 为空 | 沿用 Site/公开 route spec | 只在已有公开 route spec 时记录 |
-
-第一阶段不把 API Key 明文写入 metadata。`key_id` 是安全的内部标识,但只有在后续明确需要按单个 Key 统计或审计时才增加 `externalApiKeyId`,不作为本期客户端交接前提。
-
-### 4.4 成功与失败语义
-
-本期先保留当前 route tracking 的成功响应语义:
-
-- 2xx 成功响应按 route spec 写入 tracking。
-- 3xx、4xx、5xx 和 transport failure 不因为 AGC 标记而自动新增 route 事件。
-- 生成提交、异步轮询、重试请求使用同一标记;是否落库仍由现有 route tracking 规则决定。
-
-如果产品后续要求统计失败调用,应另立失败事件的 event key、幂等键、容量和报表口径,不在本期隐式扩展。
-
-## 5. 推荐实现:扩展现有 route tracking
-
-本期采用方案一:在现有 route tracking 上追加来源和主体信息,不创建通用 AGC 请求事件。
-
-```text
-请求 Header
- → tracking middleware 在 next.run 前白名单解析 marker
- → next.run(request)
- → 从 response extensions 读取 AuthenticatedAccessToken / ExternalApiPrincipal
- → 按实际 method + path 解析 RouteTrackingSpec
- → 计算 user/owner/scope
- → 在现有 metadata 对象追加 client=agc
- → 复用现有 outbox、tracking_event、tracking_daily_stat
- → 现有后台 tracking 查询读取 metadata_json
-```
-
-### 5.1 为什么不新增通用 AGC 事件
-
-- 不会与现有 route event 重复计数。
-- 不会改变 `tracking_daily_stat` 的 event key 和历史统计口径。
-- 仍能看到实际 path、method、status、operation 和 client 的组合。
-- 继续复用现有 outbox、SpacetimeDB procedure 和后台原始事件查询。
-- 新增或确认 AGC 路由时只需补齐 route spec 和测试,不需要引入第二套事件系统。
-
-代价是 route coverage 必须显式审计;因此阶段 3 将以 AGC 客户端调用清单和 External v1 router/OpenAPI 交叉核对,禁止“标记已经发送但主站没有 route spec”的漏项。
-
-### 5.2 实现边界
-
-推荐保持最小抽象:
-
-- `app.rs` 在消费 request 之前解析 marker,并从 response extensions 取两类主体。
-- `tracking.rs` 提供小型白名单解析函数和主体归属逻辑。
-- `RouteTrackingSpec` 明确区分既有全客户端 route 与本期新增的 AGC-only route;新增 AGC route 只有在 marker 有效时才允许落库。
-- `build_route_tracking_metadata` 只在有效 marker 时追加 `client`,不重写既有字段。
-- `record_route_tracking_event_after_success` 继续负责 route spec、outbox 和失败日志策略。
-- 不把 marker 放进 `RequestContext`,除非阶段 1 证明同一请求的其他统一 tracking 入口确实需要它;避免扩大公共上下文结构。
-
-既有 route spec 默认保持全客户端语义;本期新增、仅为 AGC 调用清单补齐的 route spec 使用 AGC-only 策略。已有 `handled_by_existing_event` 的详细资产事件不改记录范围,只在有效 marker 时追加 `client`。
-
-## 6. Route 覆盖范围
-
-### 6.1 必须覆盖的账号态路径
-
-按 AGC 当前扫描清单,至少核对并覆盖:
-
-- `/api/auth/*`:当前登录用户查询、refresh、登录入口、发送验证码、手机号登录、logout 等实际调用。
-- `/api/profile/*`:dashboard、recharge center、recharge order/confirm、wallet ledger、API Key 管理。
-- `/api/assets/*`:direct-upload-tickets、objects/confirm、read-url、read-bytes 以及 AGC 实际使用的资产操作。
-- `/api/editor/*`:projects、assets/library、assets/folders、项目 resources、图片/编辑/去背景/图集/角色动画/视频/音效/BGM 生成和轮询相关内部路径。
-- `/api/runtime/external-generation/jobs/{operationId}`:账号态生成任务轮询。
-
-已有 route spec 的 event key 和 scope 语义保持不变;新增项使用稳定、可读、与路径/operation 对应的 event key。
-
-### 6.2 必须覆盖的 External API Key 业务路径
-
-按 `server-rs/crates/api-server/src/modules/external_api.rs` 和实际 AGC 使用情况核对:
-
-- `/api/external/v1/assets/direct-upload-tickets`
-- `/api/external/v1/assets/objects/confirm`
-- `/api/external/v1/assets/read-url`
-- `/api/external/v1/editor/projects` 及项目读取/资源登记相关路径
-- `/api/external/v1/editor/assets/library`、folders、asset CRUD 中实际被 AGC 使用的路径
-- `/api/external/v1/editor/images/generations`
-- `/api/external/v1/editor/images/edits`
-- `/api/external/v1/editor/images/background-removals`
-- `/api/external/v1/editor/icon-spritesheets/generations`
-- `/api/external/v1/editor/character-animations/generations`
-- `/api/external/v1/editor/videos/generations`
-- `/api/external/v1/editor/audios/sound-effects/generations`
-- `/api/external/v1/editor/audios/background-music/generations`
-- `/api/external/v1/generations/{operationId}`
-
-External v1 路由的 tracking 必须记录外部实际 path,不把它改写成 `/api/editor`、`/api/assets` 或 `/api/runtime`。
-
-### 6.3 明确排除的 External v1 路径
-
-以下是公开发现或集成协议入口,不属于普通 AGC 主站业务调用,本期不新增普通 route tracking spec:
-
-- `GET /api/external/v1/openapi.json`
-- `GET /api/external/v1/agent-integration.json`
-- `GET /api/external/v1/skill/SKILL.md`
-- `GET /api/external/v1/skill.zip`
-- `POST /api/external/v1/mcp`
-
-如果未来 AGC 明确接入远程 MCP/Skill,再单独定义集成流量的事件语义,不把它们隐式混入普通业务统计。
-
-## 7. 数据库与后台承接
-
-### 7.1 数据库
-
-沿用现有链路:
-
-```text
-TrackingEventDraft.metadata
- → RuntimeTrackingEventInput.metadata_json
- → tracking outbox
- → record_tracking_event procedure
- → tracking_event.metadata_json
-```
-
-不增加字段、不改 migration、不重新生成 bindings。现有 JSON object 校验足以容纳 `client` 键;`tracking_daily_stat` 继续按原 event key/scope/day 聚合,不按 client 另建统计表。
-
-### 7.2 后台
-
-现有后台 tracking 查询已经返回 `metadata_json`,第一阶段只做数据可见性验证:
-
-- 管理员能在原始事件详情中看到 `client: "agc"`。
-- 原有 event key、scope、user/owner、日期查询不回归。
-- 不新增客户端筛选器、导出列或新的后台路由。
-
-如果后续需要高频按 client 筛选,再评估新增结构化列和索引;那将是独立 schema 变更,不应在本期偷偷引入。
-
-## 8. 安全与兼容性约束
-
-- 来源 Header 是可伪造的审计标签,不能当作安全边界。
-- 主体必须来自已验证的 `AuthenticatedAccessToken` 或 `ExternalApiPrincipal`,不能信任请求体 owner、客户端账本或 Header 中的身份。
-- 不记录 Bearer token、API Key 原文、Cookie、签名 URL 或请求体中的敏感字段。
-- Header 缺失/未知时继续走原有业务和 tracking 逻辑,只是不追加 `client`。
-- metadata 合并必须保留既有资产嵌套字段,不得用新对象覆盖旧 metadata。
-- outbox 入队、SpacetimeDB 写入失败继续只记录 warning,不阻断主业务响应。
-- 不修改 route normalization、dynamic id 归一化、event id 幂等或 daily stat 聚合规则。
-
-## 9. 定向测试方案
-
-### 9.1 Marker 解析
-
-表驱动测试覆盖:
-
-- `X-Genarrative-Client: agc` → `Some("agc")`。
-- Header 名大小写变化 → 仍识别。
-- 缺失、空值、首尾空白、`AGC`、未知值 → 未标记。
-
-### 9.2 Metadata 与主体归属
-
-- 有效 marker 的账号态成功路由:metadata 含 `client: "agc"`,user_id/owner_user_id 保持真实用户。
-- 有效 marker 的 External v1 成功路由:metadata 含 `client: "agc"`,owner_user_id 等于 `ExternalApiPrincipal.owner_user_id()`,scope_id 不落到 `anonymous`。
-- 未标记请求:metadata 不含 `client`。
-- 请求体伪造 owner 或 marker 不改变主体归属。
-- metadata 原有 route/method/status/operation 和资产嵌套字段仍存在。
-
-### 9.3 AGC-only 记录门禁
-
-- 本期新增的账号态和 External v1 AGC route:带有效 marker 的 2xx 响应才记录。
-- 同一批新增 route:缺失、非法或未知 marker 时不记录,也不拒绝业务请求。
-- 既有 route spec 和已有详细资产事件保持原有全客户端记录语义。
-- 4xx/5xx 即使带有效 marker 也不新增成功 route event。
-- `build_router` middleware 集成测试验证 marker、账号认证主体、成功 route tracking 和隔离 outbox 可以串联,且 metadata 保留 `client`、实际 route 和 user/owner。
-
-### 9.4 Route 覆盖
-
-- 当前 AGC 调用清单中的账号态路径全部能解析到 route spec。
-- 当前 AGC 使用的 External v1 业务路径全部能解析到 route spec。
-- `/api/external/v1` 发现、Skill 和 MCP 路径不被普通业务 spec 误收录。
-- dynamic project/asset/operation ID 仍按现有 normalize 规则归一化。
-
-### 9.5 持久化与后台读取
-
-- 构造 tracking event input 后,`metadata_json` 是合法 JSON object 且含 `client`。
-- outbox 入队/回退直写路径不丢失 `client`。
-- tracking_event 读回及后台 tracking API 解析不丢失 metadata。
-- 现有 daily stat、event id 幂等和失败不阻断语义保持不变。
-
-### 9.6 状态码语义
-
-至少保留一组回归:
-
-- 2xx 成功响应写入 route tracking。
-- 4xx/5xx 不因为 marker 自动新增成功 route event。
-- 认证失败不伪造 ExternalApiPrincipal 或用户归属。
-- 轻量 middleware 成功链路测试通过;不依赖真实 SpacetimeDB,不纳入完整环境型 E2E。
-
-## 10. 实施顺序
-
-1. 阶段 0:确认基线、交接契约、路径边界和不做项。
-2. 阶段 1:加入 marker 白名单解析,并将解析结果传入现有 route tracking。
-3. 阶段 2:接入 `AuthenticatedAccessToken` / `ExternalApiPrincipal`,完成 owner/user/scope 归属和 metadata 合并。
-4. 阶段 3:按 AGC 调用清单补齐账号态与 External v1 业务 route spec,明确排除发现/MCP。
-5. 阶段 4:验证 outbox、SpacetimeDB `tracking_event` 和现有后台原始查询,无 schema 变更。
-6. 阶段 5:完成 marker、主体、route 覆盖、状态码、安全和持久化定向测试。
-7. 阶段 6:执行最终门禁,更新交接材料并把结果回传 Issue #225;不要求 #226 回改。
-
-## 11. 完成判据
-
-只有同时满足以下条件,#225 才算完成:
-
-- 主站精确识别 `X-Genarrative-Client: agc`,未知/缺失值不拒绝请求。
-- 有效标记进入现有 route tracking metadata,写入 `client: "agc"`。
-- 已有 route、method、status、operation、资产 metadata 和 event key 语义不丢失。
-- 登录账号态按真实用户归属,External API Key 态按 `owner_user_id` 归属。
-- 当前 AGC 实际使用的账号态和 External v1 业务路径均有 tracking spec。
-- 本期新增的 AGC route spec 未携带有效 marker 时不产生 route tracking event;既有 route spec 和手工资产事件保持原有全客户端统计语义。
-- External v1 discovery/Skill/MCP、OSS、签名下载、Provider、搜索、loopback、更新下载不被误纳入普通 AGC 业务统计。
-- outbox、SpacetimeDB 写入、daily stat、幂等和失败不阻断语义无回归。
-- 后台现有 tracking 查询可以看到 `metadata_json.client`,无需新增 schema 或页面。
-- 定向测试和必要的格式/编码/空白检查通过。
-
-## 12. 评审与提交节奏建议
-
-建议按阶段分组提交或至少在一个 PR 中保持以下逻辑顺序:
-
-1. 阶段 0 文档与契约冻结。
-2. marker 解析、metadata 合并和账号态主体接入。
-3. External API Key 主体接入与 External v1 route spec。
-4. 持久化/后台读取验证和定向测试。
-5. 最终文档、交接评论和门禁记录。
-
-每个阶段先通过自身验收,再进入下一阶段;不需要等待 #226 再次修改,也不需要先新增数据库字段。
diff --git a/local-docs/【实施方案】Issue226-AGC客户端主站请求统一标记-2026-09-01.md b/local-docs/【实施方案】Issue226-AGC客户端主站请求统一标记-2026-09-01.md
deleted file mode 100644
index 3cdbc576d..000000000
--- a/local-docs/【实施方案】Issue226-AGC客户端主站请求统一标记-2026-09-01.md
+++ /dev/null
@@ -1,470 +0,0 @@
-# Issue #226:AGC 客户端主站请求统一标记实施方案
-
-更新时间:2026-09-02
-关联 Issue:
-
-- `#226 添加客户端特殊标识`:本方案实际实施范围
-- `#225 添加客户端埋点统计`:主站接收、落库和后台统计,本文只冻结交接契约,不在本次实施
-
-状态:阶段 6 已完成;已补齐跨 origin 重定向安全复审修复
-本方案包含 #226 客户端代码修改,不包含 #225 主站接收、落库和后台统计代码
-
-## 1. 一句话交付结果
-
-让 AGC 客户端发往当前选定 Genarrative 主站 origin 的业务 HTTP 请求统一携带 `X-Genarrative-Client: agc`,同时保持同源重定向及现有认证、幂等、timeout、connect timeout 和上传/下载安全边界;跨 origin 重定向不继续请求,第三方请求不携带该标记。
-
-## 2. Issue 边界
-
-### 2.1 本次只做 #226
-
-本次只修改 AGC 客户端:
-
-- Web/TS 统一请求出口。
-- Tauri/Rust 主站专用 HTTP Client 构造方式。
-- 主站请求与第三方请求的 Client 边界。
-- 客户端侧定向测试。
-
-### 2.2 本次不做 #225
-
-本次不修改:
-
-- `server-rs` 请求上下文。
-- 主站 `tracking.rs`、tracking middleware 或 route tracking 规格。
-- SpacetimeDB `tracking_event` schema、migration、bindings 或索引。
-- 后台埋点查询、筛选和报表。
-- External v1 OpenAPI、请求 DTO 和响应 DTO。
-
-### 2.3 不恢复或扩展其他旧标记
-
-AGC 当前已有部分 body 内来源值:
-
-- `ai-game-creator-client`
-- `game-creator-account-binding`
-- `game-creator-resource-editor`
-
-本次不删除、不改写这些现有业务字段,也不把它们扩展成统一调用标记。它们继续服务各自的生成/资源登记语义;统一来源以 HTTP Header 为准。
-
-## 3. 冻结的客户端标记契约
-
-### 3.1 Header
-
-```http
-X-Genarrative-Client: agc
-```
-
-约定:
-
-- Header 名按 HTTP 规则大小写不敏感;客户端发送时固定使用上面的拼写。
-- 值固定为小写 `agc`。
-- 客户端应覆盖调用方传入的同名 Header,避免业务层伪造其他值。
-- 不携带 token、用户 ID、API Key、版本号或项目 ID。
-- 不将该 Header 用作鉴权、权限、计费或账号归属证明。
-
-### 3.2 发送范围
-
-只要请求目标是当前选定的 Genarrative 主站 origin,并且属于主站业务/API 请求,就携带该 Header。
-
-包括:
-
-- 登录、刷新、登出和用户查询。
-- 账户、钱包和充值接口。
-- 项目、画布、素材库和素材读取接口。
-- 上传凭证、对象确认和项目资源登记接口。
-- 图片、图集、去背景、角色动画、视频、音效和背景音乐生成接口。
-- 生成任务异步轮询接口。
-- 登录账号态映射后的 `/api/editor`、`/api/assets`、`/api/runtime` 请求。
-- 开发者 API Key 态的 `/api/external/v1` 请求。
-- 创建本机开发者 API Key 的 `/api/profile/api-keys` 请求。
-
-不包括:
-
-- 更新清单和更新包下载。
-- OSS/对象存储 multipart 上传。
-- `read-url` 返回的签名地址下载。
-- LLM Provider 请求。
-- AGC 受控搜索。
-- loopback 工具桥。
-- 浏览器试玩页面和任意外部网页请求。
-
-### 3.3 主站 origin
-
-主站 origin 必须来自当前选定的 `serverBaseUrl` / `apiBaseUrl`,包括:
-
-- 发布地址。
-- 开发地址。
-- 用户配置的合法自定义地址。
-
-不能只根据硬编码域名判断,也不能因为 URL 路径包含 `/api` 就认定它是主站。
-
-## 4. 方案一的落地结构
-
-本次采用“统一 Client 工厂 + `default_headers` + origin-safe redirect policy”方案,不引入 origin-aware RequestBuilder 包装器。
-
-总体结构:
-
-```text
-TS 主站请求
- → fetchClientHttp
- → 解析当前选定主站目标
- → 注入 X-Genarrative-Client: agc
- → fetch / Tauri HTTP plugin
-
-Rust 主站请求
- → 主站 Client Builder factory
- → default_headers 注入 X-Genarrative-Client: agc
- → 请求发送前由主站请求终结器覆盖同名 Header
- → 默认只跟随同 origin 重定向,跨 origin 返回当前 3xx
- → 保留调用方原有 Client 配置
-
-Rust 第三方请求
- → 独立 Client
- → 不携带主站标记
-```
-
-## 5. TS 实施方案
-
-### 5.1 统一入口
-
-文件:
-
-- [clientHttp.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientHttp.ts)
-
-在 `fetchClientHttp` 中:
-
-1. 按当前已有逻辑解析最终目标 URL。
-2. 保持现有的服务器地址校验和 transport 选择。
-3. 使用 `Headers` 合并 `init.headers`。
-4. 设置 `X-Genarrative-Client: agc`。
-5. 按现有逻辑调用浏览器 `fetch` 或 Tauri HTTP plugin。
-
-### 5.2 需要保持的 Header
-
-不得覆盖或删除:
-
-- `Authorization`
-- `Content-Type`
-- `x-genarrative-response-envelope`
-- 调用方已有的 `X-Request-ID`
-
-### 5.3 TS 侧不应修改的请求
-
-[appUpdate.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/appUpdate.ts) 中直接访问更新清单的请求不经过 `fetchClientHttp`,继续保持现状,不纳入主站业务标记。
-
-## 6. Rust 实施方案
-
-### 6.1 主站 Client Builder factory
-
-在 AGC Tauri/Rust 侧增加一个小型、无业务语义的主站 Client Builder 入口。推荐职责只有:
-
-- 创建 `reqwest::ClientBuilder`。
-- 设置 `X-Genarrative-Client: agc` 默认 Header。
-- 设置只允许同 origin 的默认重定向策略;同源时委托 reqwest 默认策略,跨 origin 时停止。
-- 不负责 token、API Key、幂等键、请求体、重试或错误解析。
-
-由于 `reqwest::ClientBuilder::default_headers` 只补充请求中缺失的字段,主站请求在发送前还必须经过 `with_agc_main_site_marker(request)`。该终结器使用 `RequestBuilder::headers` 替换调用方可能传入的同名 Header,保证最终值固定为 `agc`;`external_editor_json_request` 已内置该步骤,直接 `.send()` 的主站路径显式调用该终结器。
-
-示意结构:
-
-```rust
-fn agc_main_site_client_builder() -> reqwest::ClientBuilder {
- let mut headers = reqwest::header::HeaderMap::new();
- headers.insert(
- reqwest::header::HeaderName::from_static("x-genarrative-client"),
- reqwest::header::HeaderValue::from_static("agc"),
- );
- let default_policy = reqwest::redirect::Policy::default();
- let redirect_policy = reqwest::redirect::Policy::custom(move |attempt| {
- let same_origin = attempt
- .previous()
- .first()
- .map(|initial| initial.origin() == attempt.url().origin())
- .unwrap_or(false);
- if same_origin {
- default_policy.redirect(attempt)
- } else {
- attempt.stop()
- }
- });
- reqwest::Client::builder()
- .default_headers(headers)
- .redirect(redirect_policy)
-}
-```
-
-实际实现可放在 AGC Rust 已有的客户端公共模块中;本 Issue 只增加轻量请求终结器,不新增完整 `AgcMainSiteClient` RequestBuilder 包装器,不提前实现方案二。
-
-### 6.2 保留现有 Client 配置
-
-主站请求原有 builder 配置必须在 factory 返回的 builder 上继续设置:
-
-```rust
-let client = agc_main_site_client_builder()
- .connect_timeout(Duration::from_secs(10))
- .timeout(Duration::from_secs(60))
- .redirect(reqwest::redirect::Policy::none())
- .build()?;
-```
-
-必须保留的语义包括:
-
-- connect timeout。
-- request timeout。
-- 调用方显式设置的 redirect policy;未显式设置时保留同源默认重定向、默认限制和方法处理,跨 origin 重定向由 factory 停止。
-- `no_proxy` 或其他已有网络策略(仅属于原请求的情况下保留)。
-- Bearer access token/API Key 的设置方式。
-- `Idempotency-Key` 的设置方式和原值。
-- Content-Type、multipart、JSON body 和响应解析方式。
-
-`reqwest::Client::new()` 不能配置 `default_headers`。如果它被用于生产主站请求,需要改为从 builder 创建;不能为了少改一行而遗漏标记。
-
-### 6.3 只替换主站请求的创建点
-
-潜在涉及的生产文件:
-
-- [assets.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/assets.rs)
-- [commands.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/commands.rs)
-- [canvas_generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/generation/canvas_generation.rs)
-- [direct_runtime.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/direct_runtime.rs)
-- [direct_tool_bridge.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/direct_tool_bridge.rs)
-- [asset_canvas/generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/asset_canvas/generation.rs)
-- [resource_editor.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/resource_editor.rs)
-
-替换原则:
-
-- 主站 API Client 的 `Client::builder()` 改用 AGC 主站 builder。
-- 生产主站 API 中使用 `Client::new()` 的位置改用 AGC 主站 builder,并保留原 timeout 等配置。
-- 只访问主站的专用 Client 仍使用 factory 的默认 Header,并在最终 `.send()` 前经过 `with_agc_main_site_marker`;不能依赖 `default_headers` 覆盖请求级同名 Header。
-- 一个 Client 如果同时访问主站和第三方地址,不得直接改成主站 Client;应拆分用途或保持第三方 Client 独立。
-
-### 6.4 不应替换的 Client
-
-以下请求明确保持独立 Client,不加主站标记:
-
-- [codex_provider_proxy.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/codex_provider_proxy.rs) 的 Provider 请求。
-- `build_external_asset_download_client` 创建的签名素材下载 Client。
-- OSS 表单直传 Client。
-- [direct_tool_bridge.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/direct_tool_bridge.rs) 的受控搜索 Client。
-- loopback 客户端工具桥 Client。
-- [main.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/main.rs) 的更新下载请求。
-
-### 6.5 阶段 3 实施记录
-
-- 已将生产代码中明确用于主站 API 的 Client 创建点切换为 `crate::http_client::agc_main_site_client_builder()`,覆盖 `assets.rs`、`commands.rs`、`canvas_generation.rs`、`direct_runtime.rs`、`direct_tool_bridge.rs`、`asset_canvas/generation.rs` 和 `resource_editor.rs`。
-- 主站项目、素材库、素材目录、上传凭证、对象确认、资源登记、图片生成/编辑/抠图、视频/动画/音频生成以及 generation 查询请求复用带 `X-Genarrative-Client: agc` 的 Client。
-- `assets/read-url` 换签请求使用主站 factory;签名 URL 媒体下载仍使用独立的 `build_external_asset_download_client`,不会携带主站标记。
-- OSS multipart 上传、Provider、受控搜索、loopback 工具桥和更新下载没有切换到主站 factory。
-- 保留原有 timeout、connect timeout、`no_proxy`、Bearer/API Key、Idempotency-Key、请求体和响应处理;同源重定向保持默认语义,跨 origin 重定向由 factory 阻断;未修改 `ExternalEditorBindingAccess` 的路由映射语义。
-- 阶段 3 请求捕获验证:`sync_canvas_project_assets_downloads_external_resources`(1 test passed)确认账号态项目请求和 `assets/read-url` 带标记,签名媒体下载不带标记。
-- 阶段 3 验证命令:`cargo test --locked --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml http_client -- --nocapture`(2 tests passed);`cargo test --locked --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml sync_canvas_project_assets_downloads_external_resources -- --nocapture`(1 test passed);`cargo fmt --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml -- --check`、`npm run check:encoding` 和 `git diff --check` 均通过。
-
-### 6.6 阶段 4 实施记录
-
-- 保持第三方请求的独立 Client 边界:`build_external_asset_download_client`、Codex Provider 代理、受控搜索、loopback 工具桥和更新下载均未接入主站 factory。
-- 为搜索、loopback 和更新下载提取独立的 Client 构造点,保留原有 `no_proxy`、timeout 和 redirect 配置,并明确验证这些 Client 不携带 `X-Genarrative-Client`。
-- 新增 OSS/签名传输 Client、受控搜索 Client、loopback 工具桥 Client 和更新下载 Client 的本地 TCP 负向测试;Provider 代理转发测试增加无标记断言。
-- 阶段 4 验证结果:`omits_agc_marker` 负向测试 4 个通过;Provider 代理测试 1 个通过;阶段 3 的画板同步请求捕获测试继续作为签名 URL 媒体下载无标记证据。
-- 未修改主站 API、`ExternalEditorBindingAccess` 路由映射、认证语义、OSS/Provider/搜索/loopback/更新的网络安全策略或 #225 代码。
-
-### 6.7 阶段 5 实施记录
-
-- 账号态回归使用真实平台会话 fixture,验证 `/api/editor`、`/api/assets` 和 `/api/runtime` 实际路径均携带 `X-Genarrative-Client: agc`。
-- 账号态生成请求继续携带 Bearer、UUID Idempotency-Key 和原有 `generationInputs.source = ai-game-creator-client`;排队、运行中和完成状态仍按原语义轮询,提交只发生一次。
-- External Key 态回归清除平台会话,使用 `tnr_sk_phase5_fixture` 和本地自定义 `apiBaseUrl`,验证 `/api/external/v1/editor/projects/*` 与 `/api/external/v1/assets/read-url` 携带相同标记和 API Key,签名媒体下载不带标记。
-- External v1 endpoint、账号态路由映射、请求体、认证、幂等、异步轮询和结果未知语义均未改变。
-- 阶段 5 验证:`background_agent_runtime_can_generate_platform_art_asset`、`sync_canvas_project_assets_with_developer_key_uses_external_route_and_marker` 和 `generation_submit_response_loss_is_not_retried` 均通过;Rust fmt、编码检查和 `git diff --check` 通过。
-
-### 6.8 同名 Header 覆盖复审修复记录(2026-09-02)
-
-- 评审确认 `reqwest` 的 `default_headers` 只补充缺失字段,请求级同名 Header 会优先,不能单独满足“标记值固定为 `agc`”的契约。
-- 新增 `crate::http_client::with_agc_main_site_marker`,在主站请求发送前用 `RequestBuilder::headers` 替换 `X-Genarrative-Client`;`external_editor_json_request` 内置该终结器,直接发送的主站请求也显式接入。
-- 已补齐账号态、External Key 态、生成/轮询、资源编辑、素材读取、对象确认和抠图等主站直发路径;OSS/签名下载、Provider、搜索、loopback 和更新下载仍保持独立 Client。
-- 新增回归测试验证调用方传入伪造同名 Header 时最终只发送 `X-Genarrative-Client: agc`;`http_client` 定向测试共 8 个通过。
-
-## 7. 调用语义和现有路由边界
-
-本次不改变 `ExternalEditorBindingAccess` 的职责:
-
-- 继续负责平台账号态/开发者 Key 态的凭据访问。
-- 继续负责 `/api/external/v1` 到 `/api/editor`、`/api/assets`、`/api/runtime` 的路径映射。
-- 继续负责冻结会话和账号切换校验。
-
-统一标记只附加在 HTTP Client 层,不改变:
-
-- External v1 语义 endpoint。
-- 账号态实际 endpoint。
-- 请求体中的 `generationInputs`。
-- operationId、Idempotency-Key 或本地账本。
-
-主站后续记录时必须使用实际到达的 HTTP path;不能仅使用客户端账本中保存的 External v1 endpoint。
-
-## 8. #225 的交接契约(本次不实现,但现在冻结)
-
-以下内容是为了让 `#225` 可以直接按固定契约接收,不需要反向修改 `#226` 的设计。
-
-### 8.1 主站接收规则
-
-主站读取:
-
-```http
-X-Genarrative-Client: agc
-```
-
-规则:
-
-- Header 名大小写不敏感。
-- 精确值 `agc` 视为 AGC 客户端。
-- 缺失、空值或未知值视为“未标记”,不拒绝请求,也不改变业务行为。
-- Header 不参与权限和计费。
-- 不从请求体中的 `generationInputs.source` 推导统一客户端标记。
-
-### 8.2 tracking metadata 形态
-
-为避免 #225 重新设计字段,建议固定写入现有 tracking metadata JSON:
-
-```json
-{
- "route": "/api/editor/images/generations",
- "method": "POST",
- "status": 202,
- "operation": "generateExternalEditorImage",
- "client": "agc"
-}
-```
-
-约定:
-
-- JSON key 固定为 `client`。
-- AGC 值固定为 `agc`。
-- 缺失时不写 `client`,不写空字符串。
-- 第一阶段复用 `metadata_json`,不要求 `tracking_event` 新增列。
-
-### 8.3 认证主体
-
-主站记录标记时仍以真实认证主体为准:
-
-- 登录账号态:记录现有 `AuthenticatedAccessToken` 解析出的用户维度。
-- External API Key 态:记录 `ExternalApiPrincipal` 的 `owner_user_id`,必要时保留 `key_id` 维度。
-- 不记录 access token 或 API Key 明文。
-
-### 8.4 路由覆盖
-
-`#225` 应同时考虑:
-
-- `/api/auth/*`
-- `/api/profile/*`
-- `/api/assets/*`
-- `/api/editor/*`
-- `/api/runtime/*`
-- `/api/external/v1/*`
-
-特别是 `/api/external/v1/*` 当前没有完整 route tracking spec,不能只依赖已有内部 `/api/editor` 路由规格。
-
-### 8.5 成功与失败
-
-`#226` 会给成功、失败、重试和轮询请求使用同一个来源标记。`#225` 是否继续只记录成功响应,或扩展为记录失败请求,应由 #225 按埋点目标决定,但不能要求 #226 为失败请求换另一种标记。
-
-建议 #225 至少保留:
-
-- 实际 method/path。
-- response status。
-- request_id。
-- client=`agc`。
-- user/owner/key principal 的安全维度。
-
-## 9. 定向测试方案
-
-### 9.1 主站请求带标记
-
-TS 层:
-
-- mock `fetchClientHttp` 的最终 transport。
-- 验证认证、素材和钱包请求均出现 `X-Genarrative-Client: agc`。
-- 验证已有 Authorization、envelope Header 和自定义 request ID 仍存在。
-
-Rust 层:
-
-- 使用主站 mock server 接收项目查询、素材读取、生成提交和任务轮询。
-- 验证账号态映射路径携带标记。
-- 验证开发者 API Key 态 External v1 路径携带标记。
-- 验证长 timeout/短 timeout 的不同 Client profile 都携带标记。
-
-### 9.2 第三方请求不带标记
-
-使用 mock 或请求捕获断言以下请求没有 `X-Genarrative-Client`:
-
-- OSS multipart 上传。
-- 签名 URL 下载。
-- LLM Provider。
-- 受控网页搜索。
-- loopback 工具桥。
-- 更新清单/更新包下载。
-
-### 9.3 语义保持
-
-定向测试还应确认:
-
-- 原有 Authorization 仍被发送。
-- 原有 Idempotency-Key 仍被发送且值不变。
-- 请求体和 Content-Type 不变。
-- 同源 redirect policy 的默认跟随、限制和方法处理保持不变;跨 origin 3xx 不发起下一跳。
-- timeout 和 connect timeout 不被统一 factory 覆盖成单一值。
-- 第三方请求没有因共享 Client 改造而意外继承主站 Header。
-
-## 10. 实施顺序
-
-1. 固定 Header 常量和文档契约。
-2. 在 TS `fetchClientHttp` 加统一注入。
-3. 增加 Rust 主站 Client Builder factory。
-4. 按用途盘点并只替换主站 Client 创建点。
-5. 检查所有 `Client::new()` 主站生产调用是否已迁移到 builder。
-6. 检查 OSS、签名下载、Provider、搜索、loopback、更新下载仍使用独立 Client。
-7. 增加主站正向测试和第三方负向测试。
-8. 运行定向测试、类型检查、Rust check/test、`npm run check:encoding` 和 `git diff --check`。
-9. 将本方案中的第 8 节交给 `#225`,主站按该契约接收,不要求客户端二次改设计。
-
-## 11. 完成判据
-
-只有同时满足以下条件,`#226` 才算完成:
-
-- TS 主站业务请求统一带 `X-Genarrative-Client: agc`。
-- Rust 主站业务请求统一带同一 Header。
-- 账号态和开发者 API Key 态均覆盖。
-- 生成提交和异步轮询均覆盖。
-- 主站专用 Client 保留原有网络和业务语义。
-- OSS、签名 URL、Provider、搜索、loopback 和更新下载不带标记。
-- 客户端测试覆盖正向和负向边界。
-- 不修改 `#225` 所需的主站数据设计;`#225` 可直接读取 Header 并按本文约定写入 tracking metadata。
-
-## 12. 阶段 6 实施记录与交接状态
-
-更新时间:`2026-09-02`
-
-阶段 6 已完成,`#226` 客户端侧可以交付评审;`#225` 不需要因客户端实现回改设计。固定交接材料如下:
-
-- 请求 Header:`X-Genarrative-Client: agc`。
-- tracking metadata:复用现有 `metadata_json`,写入 `client: "agc"`;缺失时不写空字符串。
-- 主站记录实际收到的 method/path;不能只记录客户端账本中的 External v1 endpoint。
-- 登录账号态按真实用户维度记录;External API Key 态按 `ExternalApiPrincipal.owner_user_id` 记录,必要时保留 `key_id` 维度。
-- Header 只用于来源审计/统计,不参与鉴权、权限、计费或账号归属;不记录 token、API Key 明文或签名 URL。
-- `#225` 应同时覆盖账号态 `/api/auth/*`、`/api/profile/*`、`/api/assets/*`、`/api/editor/*`、`/api/runtime/*` 和 API Key 态 `/api/external/v1/*`。
-- Header 缺失、空值或未知值按未标记处理,不拒绝业务请求;客户端不需要为失败、重试或轮询请求更换标记。
-
-最终门禁结果:
-
-| 门禁 | 结果 |
-|---|---|
-| TS `clientHttp` 定向测试 | 通过,14 tests passed |
-| AGC TS 类型检查(含 skill-pack/config 检查) | 通过 |
-| Rust `http_client` factory 测试 | 通过,7 tests passed;覆盖同源跟随、跨 origin 阻断、链式重定向和显式 `Policy::none()` |
-| Rust OSS/签名 URL/Provider/搜索/loopback/更新下载负向测试 | 通过,`omits_agc_marker` 4 tests passed;loopback 认证边界 1 test passed |
-| Rust 账号态主站 mock 捕获 | 通过,1 test passed |
-| Rust External Key 态主站 mock 捕获 | 通过,1 test passed |
-| Rust 签名 URL 下载边界 | 通过,1 test passed |
-| Rust 提交响应丢失幂等回归 | 通过,1 test passed |
-| Rust fmt、编码、diff 空白检查 | 通过 |
-
-本阶段未执行真实发布环境线上 smoke;账号态和 External Key 态证据来自本地 mock/custom `apiBaseUrl` fixture。真实发布环境 smoke 属于发布前或 `#225` 联调门禁,不改变本次 `#226` 客户端契约。跨 origin 重定向复审已通过本地双 listener 和链式重定向测试确认不会发起第三方下一跳。
-
-可直接粘贴到 `#225` 的交接评论:
-
-> `#226` 客户端侧已完成并冻结交接契约:AGC 主站业务请求统一发送 `X-Genarrative-Client: agc`。账号态 `/api/auth/*`、`/api/profile/*`、`/api/assets/*`、`/api/editor/*`、`/api/runtime/*` 与 External API Key 态 `/api/external/v1/*` 均覆盖;OSS/签名下载、Provider、受控搜索、loopback、更新下载和外部网页请求不带该标记。主站可按实际 method/path 读取 Header,并在现有 tracking `metadata_json` 中写入 `client: "agc"`;Header 缺失/空值/未知值按未标记处理且不拒绝请求。登录态按真实用户维度记录,External Key 态按 `owner_user_id`(必要时 `key_id`)记录,不记录 token/API Key 明文或签名 URL。客户端正向、负向、账号态、External Key 态和幂等回归均已通过,`#225` 不需要让 `#226` 回改设计。`
diff --git a/local-docs/【实施计划】Issue225-AGC主站请求标记埋点分阶段验收-2026-09-02.md b/local-docs/【实施计划】Issue225-AGC主站请求标记埋点分阶段验收-2026-09-02.md
deleted file mode 100644
index 2acdebf32..000000000
--- a/local-docs/【实施计划】Issue225-AGC主站请求标记埋点分阶段验收-2026-09-02.md
+++ /dev/null
@@ -1,398 +0,0 @@
-# Issue #225:AGC 主站请求标记埋点分阶段实施与验收计划
-
-更新时间:2026-09-02
-关联 Issue:
-
-- `#225 添加客户端埋点统计`:本计划全部实施范围
-- `#226 添加客户端特殊标识`:客户端已完成;仅作为固定交接输入
-
-当前状态:阶段 0、阶段 1、阶段 2、阶段 3、阶段 4、阶段 5、阶段 6 已完成。阶段 1~5 的实现已提交:`2296f79fd`、`2a23ba657`、`01159a269`、`c75c61521`、`c5170669e`;日登录埋点构造器回归修复为 `0a06b4988`。阶段 6 仅补充最终验收、交接和门禁文档,不新增生产代码。
-
-## 1. 交付目标
-
-主站识别有效的:
-
-```http
-X-Genarrative-Client: agc
-```
-
-并在已有 route tracking 的 `tracking_event.metadata_json` 中记录:
-
-```json
-{
- "client": "agc"
-}
-```
-
-同时按真实认证主体归属:登录账号态使用 `AuthenticatedAccessToken` 的用户,External API Key 态使用 `ExternalApiPrincipal.owner_user_id()`;不新增平行事件体系,不改鉴权、计费、幂等和 API 契约。
-
-## 2. 固定不做项
-
-本计划不修改:
-
-- AGC 客户端 Header 注入和 Rust Client factory。
-- `tracking_event` schema、migration、bindings 或索引。
-- `/api/external/v1` OpenAPI、DTO、HTTP 方法、状态码和鉴权。
-- 失败请求的全新 tracking 事实。
-- 公开 discovery、Skill、MCP、OSS、签名下载、Provider、搜索、loopback 和更新下载的普通 AGC 业务统计。
-- 后台新筛选器或报表页面;第一阶段只复用原始 metadata 查询。
-
-## 3. 阶段总览
-
-```text
-阶段 0 现状基线与交接契约冻结(已完成)
- ↓
-阶段 1 Marker 解析与 tracking 入口接入
- ↓
-阶段 2 认证主体归属与 metadata 合并
- ↓
-阶段 3 账号态 / External v1 route coverage
- ↓
-阶段 4 tracking_event、outbox 与后台读取验证
- ↓
-阶段 5 定向测试、安全边界与语义回归
- ↓
-阶段 6 最终门禁与 #226 交接收口
-```
-
-每阶段先通过本阶段验收,再进入下一阶段。阶段 1~6 均只改主站或相关测试/文档,不要求 #226 回改。
-
-## 4. 阶段 0:现状基线与交接契约冻结
-
-### 4.1 工作内容
-
-- 确认当前分支、HEAD、工作树和 `origin/master` 关系。
-- 核对 `app.rs` tracking middleware、`tracking.rs` route spec、outbox 和 `tracking_event` 写入链路。
-- 核对 `AuthenticatedAccessToken` 和 `ExternalApiPrincipal` 的 response extension 传播。
-- 读取 AGC 调用清单和 External v1 router,冻结正向/排除路径。
-- 固定 Header、metadata、未知值行为、主体归属和成功响应语义。
-
-### 4.2 阶段边界
-
-- 不修改生产代码。
-- 不新增 schema 或后台代码。
-- 不把 Issue226 的客户端实现重新打开。
-
-### 4.3 验收标准
-
-- [x] 当前基线和代码缺口已记录。
-- [x] `X-Genarrative-Client: agc` 的识别规则已固定。
-- [x] `metadata_json.client = "agc"` 的落库形态已固定。
-- [x] 账号态与 External API Key 态的主体归属已固定。
-- [x] External v1 discovery/Skill/MCP 与第三方边界已列明。
-- [x] 未修改主站生产代码、schema、OpenAPI 或后台。
-
-### 4.4 阶段产物
-
-- [【阶段验收】Issue225阶段0现状基线与边界冻结-2026-09-02.md](C:/projects/narrative/Genarrative/local-docs/【阶段验收】Issue225阶段0现状基线与边界冻结-2026-09-02.md)
-- 本实施方案。
-- 本分阶段验收计划。
-
-## 5. 阶段 1:Marker 解析与 tracking 入口接入
-
-### 5.1 工作内容
-
-修改范围限定在 `api-server` tracking 入口及定向测试:
-
-- 在 `record_api_tracking_after_success` 的 `next.run(request)` 之前读取请求 Header。
-- 增加白名单解析:首尾空白可清理,值必须精确为小写 `agc`。
-- 将解析结果传入现有 `record_route_tracking_event_after_success`。
-- 不把原始未知值、完整 Header、token 或请求体写入日志/metadata。
-
-### 5.2 阶段验收
-
-定向单元测试必须证明:
-
-- 有效 `agc` 能被识别。
-- Header 名大小写变化仍能识别。
-- 缺失、空值、`AGC`、未知值均按未标记处理。
-- 未标记请求仍走原有 route tracking 逻辑,不被拒绝。
-- 认证、响应状态和现有 request context 行为不变。
-
-### 5.3 阶段完成判据
-
-- [x] marker 只在统一 tracking 入口解析一次。
-- [x] 业务 handler 无需逐个读取 Header。
-- [x] 尚未接入主体归属和 External v1 route 扩展之外,不发生无关改动。
-
-### 5.4 阶段 1 实现与验证记录
-
-- `app.rs` 在 `next.run(request)` 前调用统一 marker 解析函数,并把解析结果传入 route tracking。
-- `tracking.rs` 只接受 Header 名 `X-Genarrative-Client`(HTTP 名称大小写不敏感)和值 `trim` 后精确等于小写 `agc` 的请求。
-- 解析结果以内部 `TrackingClientMarker::Agc` 保存到 `TrackingEventDraft`,本阶段不改变 metadata 内容;metadata 合并由阶段 2 完成。
-- 未标记、未知值和无效 Header 值均得到 `None`,不会写入日志,也不会拒绝请求。
-- 定向测试:`tracking::tests::tracking_client_marker_accepts_only_trimmed_lowercase_agc` 通过。
-- `cargo fmt --manifest-path server-rs/crates/api-server/Cargo.toml`、`git diff --check` 通过。
-- 当前未运行完整 `api-server` 测试套件;现有编译过程已通过,完整测试按阶段 5/CI 统一执行。
-
-## 6. 阶段 2:认证主体归属与 metadata 合并
-
-### 6.1 工作内容
-
-- 从最终 response extensions 读取 `AuthenticatedAccessToken`。
-- 同时读取 `ExternalApiPrincipal`。
-- 账号态沿用现有 user_id/owner_user_id 语义。
-- External API Key 态设置 `owner_user_id = principal.owner_user_id()`,User scope 的 scope_id 使用 owner,避免回退到 `anonymous`。
-- 在 `build_route_tracking_metadata` 原有 JSON object 上追加 `client: "agc"`,保留原字段和资产嵌套 metadata。
-- 第一阶段不写 API Key 明文;不新增 `externalApiKeyId`,除非评审明确要求单 Key 统计。
-
-### 6.2 阶段验收
-
-- 账号态成功请求的 user_id 与现有 access token 用户一致。
-- External v1 成功请求的 owner_user_id 与 `ExternalApiPrincipal.owner_user_id()` 一致。
-- Header 不能覆盖、伪造或替换认证主体。
-- 有效 marker 时 metadata 含 `client: "agc"`;无效/缺失时不含该键。
-- `route`、`method`、`status`、`operation` 和已有嵌套字段均保留。
-- token、API Key 明文和签名 URL 不进入 metadata 或日志。
-
-### 6.3 阶段完成判据
-
-- [x] route tracking draft 在两类主体下都能生成正确的结构化归属。
-- [x] metadata 合并逻辑有独立测试,不能只依赖端到端偶然覆盖。
-- [x] 不改变 event id、outbox 和 daily stat 逻辑。
-
-### 6.4 阶段 2 实现与验证记录
-
-- `app.rs` 从最终 response extensions 同时读取 `AuthenticatedAccessToken` 和 `ExternalApiPrincipal`。
-- `tracking.rs` 优先使用已验证的 External API Key owner;External API Key 请求不伪造 `user_id`,User scope 的 `scope_id` 使用 `owner_user_id`。
-- 账号态继续使用 access token claims 的 user id,同时写入 `user_id` 和 `owner_user_id`,保持原有语义。
-- `build_route_tracking_metadata` 只在有效 marker 时追加 `client: "agc"`,保留 route、method、status、operation 和 asset 嵌套 metadata;无 marker 不写 client。
-- 定向测试覆盖账号态主体、External API Key owner 优先级、User scope owner 和 metadata 字段保留。
-- 当前未修改 External v1 route spec、schema、OpenAPI、outbox 或后台页面。
-
-## 7. 阶段 3:账号态与 External v1 Route Coverage
-
-### 7.1 工作内容
-
-以 `local-docs/【扫描清单】AGC客户端主站调用与可标记点-2026-09-01.md` 和 `modules/external_api.rs` 为输入,补齐显式 route spec:
-
-- 账号态 `/api/auth/*`、`/api/profile/*`、`/api/assets/*`、`/api/editor/*`、`/api/runtime/external-generation/jobs/{id}` 的实际 AGC 路径。
-- External API Key 态 `/api/external/v1/assets/*`、`/editor/*`、`/generations/{id}` 的实际业务路径。
-- 生成提交、轮询、项目读取/资源登记、素材库、上传凭证、对象确认、换签读取等当前已确认调用。
-- 每个新增 spec 固定 event key、module key、scope kind 和动态路径归一化方式。
-
-本阶段新增的 route spec 统一使用 AGC-only 记录策略:只有带有效 marker 的 2xx 请求才写入;既有 route spec 保持原有全客户端语义,上传票据/对象确认等 `handled_by_existing_event` 路径继续由手工资产事件负责。
-
-同时明确不加入:
-
-- `/api/external/v1/openapi.json`。
-- `/api/external/v1/agent-integration.json`。
-- `/api/external/v1/skill/SKILL.md`、`skill.zip`。
-- `/api/external/v1/mcp`。
-
-### 7.2 阶段验收
-
-- AGC 当前实际调用清单中的每个 method + path 都能解析到 spec。
-- External v1 记录实际外部 path,不被映射为内部 `/api/editor` 等路径。
-- 发现/MCP 路径不会误进入普通业务 route tracking。
-- project/asset/operation 动态 ID 仍按现有规则归一化。
-- 原有 route spec 的 event key、scope 和统计口径不变。
-- 新增 AGC route 在未携带有效 marker 时不产生 route tracking event,且不影响业务响应。
-
-### 7.3 阶段完成判据
-
-- [x] 有一张可审计的“AGC 调用清单 → route spec → event key”矩阵。
-- [x] 新增路径均有 resolver 测试;未确认的 OpenAPI 潜在路径单独记录,不混入已实现范围。
-- [x] 没有用 catch-all `agc_client_request` 取代显式 route tracking。
-
-### 7.4 阶段 3 实现与验证记录
-
-- `tracking.rs` 补齐当前 AGC 实际使用的账号态 `/api/auth`、`/api/profile`、`/api/assets`、`/api/editor`、`/api/runtime/external-generation/jobs/{id}` 路径。
-- `tracking.rs` 补齐当前 AGC 实际使用的 External v1 资产、项目、素材库、生成提交和任务轮询路径;External v1 使用独立的实际外部 path 进入 metadata,不映射回账号态内部路径。
-- 上传票据和对象确认已有详细资产事件,route spec 以 `handled_by_existing_event` 标记为复用现有事件,统一 route tracking 不再重复写入;tracking middleware 将有效 marker 放入 request extensions,由共享资产 handler 将 `client: "agc"` 合并到既有资产 metadata,并补齐实际 route/method/status/operation。
-- 共享资产事件沿用真实主体:账号态写入 user/owner;External API Key 态只写 `owner_user_id`,不伪造登录 `user_id`,User scope 使用 owner。
-- 扩展动态路径归一化的静态段白名单,使 project、generation、asset 和 external v1 路径按既有 `{id}` 规则正确匹配;未引入 catch-all AGC 事件。
-- discovery、agent-integration、Skill、skill.zip 和 MCP 路径没有业务 route spec。
-
-已执行定向验证:
-
-```text
-cargo fmt --manifest-path server-rs/crates/api-server/Cargo.toml -- --check
-cargo check --locked --manifest-path server-rs/Cargo.toml -p api-server
-cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server tracking::tests:: -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server assets::tests::asset_tracking_metadata_receives_only_valid_agc_marker -- --nocapture
-git diff --check
-```
-
-结果:tracking 定向测试 13 个通过,资产 marker/route metadata 与 External owner 归属测试 2 个通过,api-server 编译检查通过。
-
-## 8. 阶段 4:tracking_event、outbox 与后台读取验证
-
-### 8.1 工作内容
-
-- 验证 `TrackingEventDraft.metadata` 经 `build_tracking_event_input` 后仍是合法 JSON object。
-- 验证本机 tracking outbox 入队和 SpacetimeDB 回退直写都保留 `client`。
-- 验证既有 `tracking_event` 行和 `tracking_daily_stat` 聚合未改变。
-- 验证现有后台 tracking API 返回 `metadata_json` 中的 `client`。
-- 不新增 schema/migration/bindings,不修改后台页面。
-
-### 8.2 阶段验收
-
-- AGC 成功事件可在 tracking_event 读回 `client: "agc"`。
-- unmarked 事件不会被补写 `client`。
-- owner_user_id、user_id、scope_id、event_key 和 occurred_at 不丢失。
-- 后台原始事件查询和已有 event key 查询不回归。
-- `npm run check:spacetime-schema` 不因本阶段产生 schema 变更;若未改 schema,可记录为无需运行。
-
-### 8.3 阶段完成判据
-
-- 至少有一条账号态和一条 External Key 态从 tracking draft 到后台读取的完整证据。
-- 已确认第一阶段不需要新增数据库字段。
-
-### 8.4 阶段 4 实现与验证记录
-
-- `api-server` tracking 测试分别构造账号态和 External API Key 态输入,验证 `TrackingEventDraft → build_tracking_event_input` 后 metadata 仍是合法 JSON object,`client: "agc"`、route、status、event key、module、scope 和 user/owner 字段均保留;未标记输入不补写 `client`。
-- tracking outbox 测试使用 External v1 AGC 事件完成 NDJSON 入队和读取 round-trip,验证 `metadata_json.client`、实际 External v1 route、`owner_user_id` 和“不伪造 `user_id`”均保留。
-- `spacetime-client` active mapper 测试验证送往生成绑定的 `RuntimeTrackingEventInput` 不丢失 `client`、External owner、scope、event key 和 module;module-runtime 的统一输入校验测试验证 metadata 必须是 JSON object,标记对象可正常通过。由于本地未启动 SpacetimeDB,未把确定性 input/mapper 验证扩大解释为真实远端库 E2E。
-- 后台 tracking SQL response parser 测试分别覆盖账号态与 External API Key 态,并增加 draft/input → SQL row → parser 组合回归,验证管理员现有原始事件读取能保留 `metadata_json.client`、实际 route 和 user/owner 归属。
-- 未修改 tracking schema、migration、bindings、outbox 失败回退策略、daily stat 聚合逻辑或后台页面;SpacetimeDB 的实际入库仍复用既有 `record_tracking_event` / `record_tracking_events` procedure,未新增字段。
-
-已执行定向验证:
-
-```text
-cargo fmt --manifest-path server-rs/Cargo.toml --all -- --check
-cargo test --locked --manifest-path server-rs/Cargo.toml -p module-runtime tracking_input_ -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server tracking::tests:: -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server tracking_outbox::tests:: -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server admin::tests::parse_admin_tracking_events_sql_response_ -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p spacetime-client tracking_input_mapper_preserves_agc_metadata_and_external_owner -- --nocapture
-```
-
-结果:module-runtime 2 个、api-server tracking 15 个、tracking outbox 8 个、后台 readback parser 5 个、spacetime-client mapper 1 个定向测试全部通过;格式检查通过。未运行完整工作区测试和 `npm run check:spacetime-schema`,因为本阶段未修改 schema。
-
-## 9. 阶段 5:定向测试、安全边界与语义回归
-
-### 9.1 工作内容
-
-补齐并运行与改动直接相关的测试:
-
-- marker 解析表驱动测试。
-- route metadata 合并测试。
-- 账号态主体归属测试。
-- ExternalApiPrincipal owner 归属测试。
-- External v1 route resolver 覆盖测试。
-- discovery/MCP 排除测试。
-- 2xx 记录、4xx/5xx 不新增成功 route 事件测试。
-- `build_router` 轻量 middleware 成功链路测试:真实 HTTP request 经认证、tracking middleware 后写入隔离 outbox,并断言 `client`、route 和主体归属。
-- outbox/SpacetimeDB input 和后台 tracking readback 测试。
-
-CI 已覆盖且与本改动无直接关系的全量测试可交给 CI;本阶段仍必须运行能直接证明本 Issue 契约的 targeted tests。
-
-### 9.2 阶段验收
-
-- 有效 marker 正向场景全部通过。
-- 缺失/空值/未知 marker 负向场景全部通过。
-- 登录账号态和 External Key 态主体归属均通过。
-- 未发生鉴权、状态码、幂等、请求体或异步轮询回归。
-- 测试输出不包含 token、API Key 明文、Cookie、签名 URL 或本地私密路径。
-
-### 9.3 阶段完成判据
-
-- 测试矩阵覆盖“标记/未标记 × 账号态/External Key 态 × 已覆盖/排除路由”。
-- 所有失败都能定位到 marker、主体、route、持久化或后台读取中的具体层。
-
-### 9.4 阶段 5 实现与验证记录
-
-- `tracking.rs` 抽出 `should_record_route_tracking` 判定,明确新增 AGC-only route 只有在带有效 marker 的 2xx 响应下才进入统一成功 route tracking;既有全客户端 route 保持原语义,4xx/5xx 和上传确认等复用事件均不新增重复成功事件。
-- 新增 2xx、4xx/5xx 状态矩阵测试,覆盖 `OK / CREATED / ACCEPTED / NO_CONTENT` 与认证、权限、客户端、服务端失败状态。
-- 新增 AGC-only route 正反向门禁测试:有效 marker 记录,缺失或无效 marker 不记录;既有 route 和手工资产事件策略保持不变。
-- 新增 `app::tests::agc_marker_flows_through_auth_tracking_middleware_to_outbox`,不启动真实 SpacetimeDB,仅验证 middleware 到 outbox 的最小闭环。
-- 新增 `app.rs` 路由回归:带有效 `X-Genarrative-Client: agc` 的未认证业务请求仍返回 `401`,marker 不绕过鉴权,也不改变失败状态。
-- 新增 route metadata 安全边界测试,确认统一 route metadata 只包含既有 route/method/status/operation 和可选 `client`/资产字段,不出现 authorization、token、API Key、Cookie、签名 URL 或 request body 字段。
-- 阶段 4 的账号态、External API Key、outbox、后台 readback 和 mapper 测试全部复跑;SpacetimeDB 既有 event-id 幂等回归也通过。未修改鉴权、请求体、异步轮询、event id、daily stat 或失败回退实现。
-
-已执行定向验证:
-
-```text
-cargo fmt --manifest-path server-rs/Cargo.toml --all -- --check
-cargo test --locked --manifest-path server-rs/Cargo.toml -p module-runtime tracking_input_ -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p spacetime-client tracking_input_mapper_preserves_agc_metadata_and_external_owner -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server tracking::tests:: -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server app::tests::agc_marker_does_not_bypass_authentication_or_change_failure_status -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server assets::tests::asset_tracking_metadata_receives_only_valid_agc_marker -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server assets::tests::external_asset_tracking_keeps_owner_without_forging_user -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server tracking_outbox::tests:: -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server admin::tests::parse_admin_tracking_events_sql_response_ -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server admin::tests::tracking_inputs_round_trip_to_admin_readback_for_both_subjects -- --nocapture
-cargo test --locked --manifest-path server-rs/Cargo.toml -p spacetime-module duplicate_tracking_event_ids_are_treated_as_idempotent_replays -- --nocapture
-```
-
-结果:module-runtime 2 个、spacetime-client 1 个、api-server tracking 18 个、app 鉴权回归 1 个、资产 marker/owner 2 个、tracking outbox 8 个、后台 readback 5 个、spacetime-module 幂等 1 个定向测试全部通过;格式检查通过。未运行与本 Issue 无直接关系的完整工作区测试,按约定交给 CI。
-
-## 10. 阶段 6:最终门禁与 #226 交接收口
-
-### 10.1 工作内容
-
-- 汇总阶段 1~5 的测试和 readback 证据。
-- 更新本方案、验收记录和 Issue #225 评论草案。
-- 复核 #226 交接契约不需要客户端回改。
-- 检查 diff、编码、格式、敏感信息和无关文件。
-
-### 10.2 最终门禁
-
-按实际改动范围运行:
-
-- `cargo fmt --manifest-path server-rs/Cargo.toml -- --check`。
-- `cargo test --locked -p api-server` 的 tracking/External v1 定向测试。
-- 必要时 `cargo check --locked -p api-server`。
-- `npm run check:encoding`。
-- `git diff --check`。
-- `git status --short`,确认没有构建产物、日志、凭据或无关文件。
-
-未修改 schema 时不运行 schema 生成;若实现阶段意外需要 schema,必须停在阶段 4 重新确认迁移范围,不能顺手修改。
-
-### 10.3 阶段完成判据
-
-- 主站可以在现有 tracking_event metadata 中看到 `client: "agc"`。
-- 两类认证主体归属正确。
-- 当前 AGC 实际业务路径无漏记,发现/MCP/第三方边界无误记。
-- 后台现有查询可读,无需新 schema 或新页面。
-- 所有必要 targeted tests、格式/编码/空白检查通过。
-- 向 #225 交付固定 Header、metadata、主体归属、路由覆盖和验证证据;不要求 #226 回改。
-
-### 10.4 阶段 6 实际执行与结果
-
-阶段 6 以当前分支 `feat/agc_call_rec`、`HEAD=5aa38d9f3` 为基线;该提交已合并最新 `origin/master`(`8932f0b27`)。本阶段未修改 `server-rs`、SpacetimeDB schema、OpenAPI 或后台页面,只更新验收和交接文档。
-
-最终门禁结果:
-
-| 验收项 | 命令/证据 | 结果 |
-|---|---|---|
-| api-server 编译 | `cargo check --locked --manifest-path server-rs/Cargo.toml -p api-server` | 通过;仅有仓库既有 dead-code warning |
-| api-server tracking/资产/后台/outbox 定向测试 | `cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server tracking -- --nocapture` | 通过,43 tests passed |
-| marker 不绕过鉴权回归 | `cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server app::tests::agc_marker_does_not_bypass_authentication_or_change_failure_status -- --nocapture` | 通过,1 test passed |
-| module-runtime tracking input | `cargo test --locked --manifest-path server-rs/Cargo.toml -p module-runtime tracking_input_ -- --nocapture` | 通过,2 tests passed |
-| spacetime-client mapper | `cargo test --locked --manifest-path server-rs/Cargo.toml -p spacetime-client tracking_input_mapper_preserves_agc_metadata_and_external_owner -- --nocapture` | 通过,1 test passed |
-| SpacetimeDB event-id 幂等 | `cargo test --locked --manifest-path server-rs/Cargo.toml -p spacetime-module duplicate_tracking_event_ids_are_treated_as_idempotent_replays -- --nocapture` | 通过,1 test passed |
-| Rust 格式 | `cargo fmt --manifest-path server-rs/Cargo.toml --all -- --check` | 通过 |
-| 中文编码 | `npm run check:encoding` | 通过,5662 个文件 |
-| Diff 空白与分支基线 | `git diff --check`、`git merge-base --is-ancestor origin/master HEAD` | 通过 |
-
-上述测试合计 48 个与本 Issue 直接相关的测试通过。完整工作区测试按用户约定交由 CI;本阶段未启动真实 SpacetimeDB,也未执行发布环境线上写入,因此最终证据是本地确定性 input/mapper、outbox、后台 parser 和 route tracking 回归,不把本地测试表述为线上 E2E。
-
-### 10.5 阶段 6 交接结论
-
-- 主站只对白名单值 `X-Genarrative-Client: agc` 追加 `metadata_json.client = "agc"`;缺失、空值、`AGC` 和未知值按未标记处理,不拒绝请求。
-- 本期新增的 AGC route spec 只有在带有效 marker 的 2xx 响应下才记录;既有 route spec 与手工资产事件保持原有全客户端统计语义。
-- 账号态沿用真实 access token 用户;External API Key 态使用 `ExternalApiPrincipal.owner_user_id()`,不伪造 `user_id`。
-- 当前 AGC 实际账号态和 External v1 业务路径均有显式 route spec;动态 ID 继续归一化,External v1 保留实际外部 path。
-- OSS、签名下载、Provider、受控搜索、loopback、更新下载、公开 discovery/Skill/MCP 不进入普通 AGC 业务 route tracking。
-- 最终记录仍落在现有 SpacetimeDB `tracking_event.metadata_json`,经过本机 `server-rs/.data/tracking-outbox/` 临时缓冲后由既有 tracking procedure 写入;不新增 schema、索引、后台页面或独立事件体系。
-- `#226` 的客户端标记注入和 origin-safe redirect 契约已满足本 Issue 输入要求,不需要回改 #226 设计。
-- 另有一个独立于 #225 的客户端后续项:自定义 origin 使用显式默认端口或大写主机名时,`clientHttp.ts` 的字符串与 `URL.origin` 比较可能误判为跨 origin;它只会拒绝合法请求,不会泄漏 marker,应单独在 #226 跟踪。
-
-阶段 6 详细验收记录与可直接粘贴到 Issue #225 的交付评论见:
-
-- [【阶段验收】Issue225阶段6最终门禁与交接收口-2026-09-02.md](C:/projects/narrative/Genarrative/local-docs/【阶段验收】Issue225阶段6最终门禁与交接收口-2026-09-02.md)
-
-## 11. 建议提交分组
-
-建议按以下逻辑分组提交,便于逐阶段验收:
-
-1. 阶段 1:marker 解析与 tracking 入口。
-2. 阶段 2:主体归属与 metadata 合并。
-3. 阶段 3:route spec 与 External v1 覆盖。
-4. 阶段 4~5:持久化/后台验证、定向测试和安全回归。
-5. 阶段 6:验收记录、Issue 交接评论和最终门禁。
-
-如仓库要求单提交,也应在 PR 描述中按上述五组列出,确保每组都有独立验收标准。
diff --git a/local-docs/【实施计划】Issue226-AGC客户端主站请求标记分阶段验收-2026-09-01.md b/local-docs/【实施计划】Issue226-AGC客户端主站请求标记分阶段验收-2026-09-01.md
deleted file mode 100644
index e0a9eb589..000000000
--- a/local-docs/【实施计划】Issue226-AGC客户端主站请求标记分阶段验收-2026-09-01.md
+++ /dev/null
@@ -1,408 +0,0 @@
-# Issue #226:AGC 客户端主站请求标记分阶段实施与验收计划
-
-更新时间:2026-09-02
-关联 Issue:
-
-- `#226 添加客户端特殊标识`:本计划全部实施范围
-- `#225 添加客户端埋点统计`:只接收交接契约,不在本计划实现
-
-当前状态:阶段 6 已完成;跨 origin 重定向复审修复已完成;阶段 0 的证据与验收记录见
-[【阶段验收】Issue226阶段0现状基线与契约冻结-2026-09-01.md](C:/projects/narrative/Genarrative/local-docs/【阶段验收】Issue226阶段0现状基线与契约冻结-2026-09-01.md)。
-
-## 1. 交付目标
-
-AGC 客户端发往当前选定 Genarrative 主站 origin 的业务 HTTP 请求统一携带:
-
-```http
-X-Genarrative-Client: agc
-```
-
-同时保持同源重定向及现有认证、幂等、timeout、connect timeout、`no_proxy`、请求体和响应处理语义;跨 origin 3xx 不继续请求;OSS、签名下载、Provider、搜索、loopback 和更新下载请求不携带该标记。
-
-## 2. 明确不做项
-
-本计划不修改:
-
-- 主站 `server-rs`。
-- `/api/external/v1` OpenAPI 或 DTO。
-- SpacetimeDB schema、migration、bindings。
-- 主站 tracking middleware、route tracking 或后台查询。
-- `#225` 的数据库字段和管理页实现。
-- 现有 `generationInputs.source` 等业务 body 字段。
-
-## 3. 阶段总览
-
-```text
-阶段 0 现状基线与契约冻结
- ↓
-阶段 1 TS 统一出口
- ↓
-阶段 2 Rust 主站 Client Builder factory
- ↓
-阶段 3 主站 Client 创建点迁移
- ↓
-阶段 4 第三方请求隔离与负向验证
- ↓
-阶段 5 账号态/External 态和请求语义回归
- ↓
-阶段 6 #225 交接与最终门禁
-```
-
-每个阶段都应先完成本阶段验收,再进入下一阶段;阶段之间不依赖 `#225` 已经实现。
-
-## 4. 阶段 0:现状基线与契约冻结
-
-### 4.1 工作内容
-
-- 确认当前工作树无其他相关未提交修改。
-- 复核 AGC TS 主站统一出口:`fetchClientHttp`。
-- 复核 Rust 主站请求和第三方请求的 Client 创建点。
-- 固定 Header 名和值:`X-Genarrative-Client: agc`。
-- 固定主站 origin 判定依据:当前选定的 `serverBaseUrl` / `apiBaseUrl`。
-- 固定第三方排除列表。
-- 固定 #225 接收时使用的 metadata 约定:`metadata.client = "agc"`。
-
-### 4.2 不应发生的改动
-
-- 不修改生产代码。
-- 不修改主站代码或 OpenAPI。
-- 不新增数据库字段。
-
-### 4.3 验收标准
-
-- 已有调用清单和实施方案文档可定位到实际源码。
-- 正向范围和排除范围没有未决歧义。
-- Header 契约、metadata 交接字段和未知值行为已写入 Issue/方案文档。
-- `git status --short` 只反映预期的文档或无相关修改。
-
-### 4.4 阶段产物
-
-- 本方案文档。
-- Issue #226 的实现范围评论草案(正式评论待外部 Issue 操作确认)。
-- 交给 #225 的固定 Header/metadata 交接说明。
-- 阶段 0 基线与验收记录。
-
-## 5. 阶段 1:TS 统一出口注入
-
-### 5.1 工作内容
-
-修改范围限定在:
-
-- [clientHttp.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientHttp.ts)
-- 对应的 `clientHttp` 定向测试或现有测试 fixture
-
-在 `fetchClientHttp` 中:
-
-1. 保持现有目标 URL 解析和服务器地址校验。
-2. 使用 `Headers` 合并原有 `RequestInit.headers`。
-3. 注入 `X-Genarrative-Client: agc`。
-4. 保持浏览器 `fetch` 与 Tauri HTTP plugin 两条 transport 行为不变。
-
-认证和业务函数不逐个添加 Header:
-
-- `clientAuth.ts` 继续调用 `fetchClientHttp`。
-- `clientApi.ts` 继续调用 `fetchClientHttp`。
-
-更新清单请求 [appUpdate.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/appUpdate.ts) 不迁移到该统一出口,也不纳入主站业务标记。
-
-### 5.2 阶段验收
-
-TS 定向测试必须证明:
-
-- `/api/auth/*` 请求带 `X-Genarrative-Client: agc`。
-- `/api/profile/*` 请求带 `X-Genarrative-Client: agc`。
-- `/api/editor/*` 请求带 `X-Genarrative-Client: agc`。
-- `/api/assets/*` 请求带 `X-Genarrative-Client: agc`。
-- 原 `Authorization` 保留。
-- 原 envelope Header 保留。
-- 原 `X-Request-ID` 保留。
-- 调用方传入其他同名值时,最终值仍为 `agc`。
-- 更新清单请求不因本阶段被改为携带主站业务标记。
-
-### 5.3 阶段完成判据
-
-- TS 层所有已确认的主站业务请求经过 `fetchClientHttp` 并可观察到标记。
-- 没有在业务 API 文件中出现重复 Header 注入。
-- 相关 TS 定向测试通过。
-
-### 5.4 阶段 1 实施记录
-
-- `clientHttp.ts` 新增固定 Header 常量,并在 `fetchClientHttp` 内通过 `Headers` 合并并覆盖同名调用方 Header。
-- Web `fetch` 与 Tauri HTTP plugin 都接收同一份带标记的 `RequestInit`;原始 `RequestInit.headers` 不被修改。
-- `clientHttp.test.ts` 已覆盖 `/api/auth/*`、`/api/profile/*`、`/api/editor/*`、`/api/assets/*`,并分别验证 Web/Tauri transport、Authorization、envelope Header、`X-Request-ID` 和同名 Header 覆盖。
-- 阶段 1 验证命令:`npm exec vitest run apps/ai-game-creator-shell/tests/clientHttp.test.ts`(14 tests passed);`npm run ai-game-creator-shell:typecheck` 通过。
-- `appUpdate.ts` 未接入 `fetchClientHttp`,更新下载边界保持不变。
-
-## 6. 阶段 2:Rust 主站 Client Builder factory
-
-### 6.1 工作内容
-
-在 AGC Tauri/Rust 侧增加小型主站 Client Builder 入口,职责限定为:
-
-- 创建 `reqwest::ClientBuilder`。
-- 通过 `default_headers` 注入 `X-Genarrative-Client: agc`。
-- 不负责认证、幂等、重试、请求体、错误解析或账本。
-
-建议抽象为 builder 工厂而不是完整 RequestBuilder facade,以保持当前方案一的低复杂度:
-
-```rust
-fn agc_main_site_client_builder() -> reqwest::ClientBuilder;
-```
-
-工厂返回的 builder 允许调用方继续设置原有配置;未显式覆盖时,factory 默认只跟随同 origin 重定向:
-
-- connect timeout
-- request timeout
-- 显式 redirect policy(覆盖 factory 默认策略)
-- 原有 `no_proxy` 或其他网络策略
-
-### 6.2 阶段验收
-
-增加最小单元测试或 mock 请求测试,证明:
-
-- 从 factory build 出的 Client 默认带 `X-Genarrative-Client: agc`。
-- 请求级 Authorization 和 Idempotency-Key 仍可正常设置。
-- factory 不改变 timeout 或 proxy 配置;默认 redirect 只跟随同 origin,调用方显式 `Policy::none()` 仍可覆盖。
-- 不新增完整 `AgcMainSiteClient` 类型。
-- 不把第三方下载或 Provider Client 接入该 factory。
-
-### 6.3 阶段完成判据
-
-- 主站 Client 的统一构造入口已经存在。
-- factory 的职责没有扩展到业务编排。
-- 现有测试或新增测试能锁定 Header 默认值。
-
-### 6.4 阶段 2 实施记录
-
-- 新增 `src-tauri/src/http_client.rs`,提供 `agc_main_site_client_builder()`。
-- factory 仅通过 `default_headers` 注入 `x-genarrative-client: agc`,不接管认证、幂等、请求体、重试或错误解析。
-- 调用方仍可在返回的 builder 上继续配置 connect timeout、request timeout、显式 redirect policy 和 `no_proxy`;未显式配置时跨 origin 重定向不会被跟随。
-- 新增两个本地 TCP fixture 单元测试,验证真实发送请求带标记、请求级 Authorization/Idempotency-Key 保留,且 factory 不自动注入认证信息。
-- 阶段 2 验证命令:`cargo test --locked --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml http_client -- --nocapture`(2 tests passed);`cargo fmt --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml -- --check` 通过。
-- 阶段 2 未迁移任何业务 Client 创建点;迁移属于阶段 3。
-
-## 7. 阶段 3:主站 Client 创建点迁移
-
-### 7.1 工作内容
-
-只替换生产代码中用于主站 API 的 Client 创建方式:
-
-- 主站用途的 `reqwest::Client::builder()` 改用 AGC 主站 builder factory。
-- 主站用途的 `reqwest::Client::new()` 改为 builder 创建,以便设置默认 Header。
-- 保留每个调用原有 timeout、connect timeout、认证和幂等设置;同源 redirect 语义保留,跨 origin redirect 统一阻断。
-
-重点检查文件:
-
-- [assets.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/assets.rs)
-- [commands.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/commands.rs)
-- [canvas_generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/generation/canvas_generation.rs)
-- [direct_runtime.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/direct_runtime.rs)
-- [direct_tool_bridge.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/direct_tool_bridge.rs)
-- [asset_canvas/generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/asset_canvas/generation.rs)
-- [resource_editor.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/resource_editor.rs)
-
-### 7.2 主站请求覆盖清单
-
-迁移后应覆盖:
-
-
-- `/api/profile/api-keys`
-- `/api/editor/projects`
-- `/api/editor/projects/{projectId}`
-- `/api/editor/assets/library`
-- `/api/editor/assets/folders`
-- `/api/assets/direct-upload-tickets`
-- `/api/assets/objects/confirm`
-- `/api/assets/read-url`
-- `/api/editor/projects/{projectId}/resources`
-- `/api/editor/images/generations`
-- `/api/editor/images/edits`
-- `/api/editor/images/background-removals`
-- `/api/editor/icon-spritesheets/generations`
-- `/api/editor/character-animations/generations`
-- `/api/editor/videos/generations`
-- `/api/editor/audios/sound-effects/generations`
-- `/api/editor/audios/background-music/generations`
-- `/api/runtime/external-generation/jobs/{operationId}`
-- 开发者 API Key 态对应的 `/api/external/v1/*` 路径
-
-### 7.3 阶段验收
-
-代码审查和请求捕获必须证明:
-
-- 上述主站请求均使用带默认 Header 的 Client。
-- 登录账号态路径带标记。
-- 开发者 API Key 态 External v1 路径带标记。
-- 生成提交和任务轮询都带标记。
-- 请求体、Bearer/API Key、Idempotency-Key、timeout 和同源 redirect 处理未变化;跨 origin redirect 不发起第二跳。
-- 没有为了加标记而修改 `ExternalEditorBindingAccess` 的路由映射语义。
-
-### 7.4 阶段完成判据
-
-- 主站生产请求的 Client 创建点完成迁移。
-- 没有把所有 Rust Client 粗暴替换成主站 Client。
-- 旧的第三方 Client 边界仍然清晰。
-
-### 7.5 阶段 3 实施记录
-
-- 已迁移 7 个生产 Rust 文件中的主站 Client 创建点:`assets.rs`、`commands.rs`、`agent/generation/canvas_generation.rs`、`agent/direct_runtime.rs`、`agent/direct_tool_bridge.rs`、`project/asset_canvas/generation.rs` 和 `project/resource_editor.rs`。
-- 迁移覆盖账号态实际 `/api/editor`、`/api/assets`、`/api/runtime` 路径,以及开发者 Key 态 `/api/external/v1` 路径;`assets/read-url` 的主站换签请求也通过 factory 创建。
-- 签名 URL 下载和 OSS multipart 上传仍由独立安全下载 Client 负责;Provider、搜索、loopback 和更新下载保持裸 Client。
-- 未修改 `ExternalEditorBindingAccess` 路由映射、凭据、请求体、operationId、Idempotency-Key 或本地账本语义。
-- 请求捕获测试已验证账号态画板同步的项目请求和换签请求带 `X-Genarrative-Client: agc`,签名媒体下载不带该 Header。
-- 阶段 3 验证:`http_client` 定向测试 2 个通过;`sync_canvas_project_assets_downloads_external_resources` 通过;Rust fmt、编码检查和 `git diff --check` 通过。
-
-## 8. 阶段 4:第三方请求隔离与负向验证
-
-### 8.1 工作内容
-
-逐项确认以下 Client 不使用主站 factory:
-
-- [codex_provider_proxy.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/codex_provider_proxy.rs)
-- `build_external_asset_download_client`。
-- OSS multipart 上传 Client。
-- 受控搜索 Client。
-- loopback 工具桥 Client。
-- 更新清单/更新包下载 Client。
-
-### 8.2 阶段验收
-
-为每类请求配置 mock 或请求捕获,断言:
-
-- OSS multipart 上传没有 `X-Genarrative-Client`。
-- 签名 URL 下载没有 `X-Genarrative-Client`。
-- LLM Provider 没有 `X-Genarrative-Client`。
-- 搜索请求没有 `X-Genarrative-Client`。
-- loopback 工具桥没有 `X-Genarrative-Client`。
-- 更新下载没有 `X-Genarrative-Client`。
-
-同时断言这些请求原有的 `no_proxy`、redirect、超时和安全校验仍生效。
-
-### 8.3 阶段完成判据
-
-- 所有明确排除项均通过负向测试。
-- 没有出现“为了复用 factory,把第三方请求也带上 Header”的情况。
-- 负向测试失败时能定位到具体请求类别,而不是只报告一个总失败。
-
-### 8.4 阶段 4 实施记录
-
-- `build_external_asset_download_client` 的 OSS/签名传输 Client 保持独立;新增 `external_asset_transfer_client_omits_agc_marker` 本地 TCP 测试。
-- 受控搜索 Client 提取为独立构造点,新增 `controlled_search_client_omits_agc_marker` 测试。
-- loopback 工具桥 Client 提取为独立构造点,新增 `loopback_tool_bridge_client_omits_agc_marker` 测试。
-- 更新下载保留独立裸 Client,新增 `update_download_client_omits_agc_marker` 测试。
-- Codex Provider 代理转发测试增加 `x-genarrative-client` 缺失断言;阶段 3 的画板同步测试继续确认签名媒体下载无标记。
-- 阶段 4 验证命令:`cargo test --locked --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml omits_agc_marker -- --nocapture`(4 tests passed);`cargo test --locked --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml loopback_proxy_strips_false_codex_limit_headers_and_requires_bearer -- --nocapture`(1 test passed);`cargo fmt --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml -- --check` 和 `git diff --check` 通过。
-
-## 9. 阶段 5:账号态、External 态和语义回归
-
-### 9.1 工作内容
-
-覆盖以下身份和地址组合:
-
-| 场景 | 认证 | 路径形态 |
-|---|---|---|
-| 平台账号态 | access token | `/api/editor`、`/api/assets`、`/api/runtime` |
-| 开发者 Key 态 | `tnr_sk_...` | `/api/external/v1` |
-| 开发环境 | 当前开发主站 origin | 主站实际路径 |
-| 发布环境 | 当前发布主站 origin | 主站实际路径 |
-| 自定义服务器 | 合法自定义 `apiBaseUrl` | 自定义主站实际路径 |
-
-### 9.2 阶段验收
-
-- 账号态和开发者 Key 态都收到相同 Header 值 `agc`。
-- External v1 语义 endpoint 不因加 Header 改变。
-- 账号态路由映射不因加 Header 改变。
-- 自定义合法主站地址仍能携带标记。
-- 非主站地址不会被主站 Client 使用。
-- 认证失败、幂等重试、异步轮询和结果未知语义不变。
-- 现有 body 内 `generationInputs.source` 值保持原样。
-
-### 9.3 阶段完成判据
-
-- 关键请求矩阵全部有正向或负向证据。
-- 没有发生 token、API Key、Cookie、签名 URL 或项目绝对路径泄漏到日志/测试输出。
-- 没有因为 Header 增加而改变业务状态码或重试策略。
-
-### 9.4 阶段 5 实施记录
-
-- 账号态生成回归:`background_agent_runtime_can_generate_platform_art_asset` 捕获并检查 `/api/editor`、`/api/assets`、`/api/runtime` 请求,确认统一标记、Bearer、UUID Idempotency-Key、单次提交和三阶段轮询;同时锁定 `generationInputs.source = ai-game-creator-client`。
-- External Key 态与自定义服务器回归:`sync_canvas_project_assets_with_developer_key_uses_external_route_and_marker` 在无平台会话下使用 `tnr_sk_phase5_fixture` 和自定义本地 `apiBaseUrl`,确认 External v1 项目/换签请求带标记,签名媒体下载不带标记。
-- 结果未知语义回归:`generation_submit_response_loss_is_not_retried` 通过,确认提交响应丢失时保留原 Idempotency-Key 且不重复提交。
-- 账号态画板同步测试继续覆盖主站项目请求、`assets/read-url` 和签名下载的正负边界。
-- 阶段 5 定向测试均通过;阶段 6 只剩 #225 交接材料复核与最终门禁,不在本阶段修改主站代码。
-
-## 10. 阶段 6:#225 交接与最终门禁
-
-### 10.1 交给 #225 的固定契约
-
-`#225` 可以直接按以下约定实现,不需要要求 #226 回改客户端设计:
-
-```text
-请求 Header:X-Genarrative-Client: agc
-tracking metadata:client = "agc"
-```
-
-主站处理规则:
-
-- Header 名大小写不敏感。
-- 值为 `agc` 时识别为 AGC。
-- 缺失、空值或未知值按未标记处理,不拒绝业务请求。
-- 记录实际收到的 method/path,而不是客户端账本中的 External v1 endpoint。
-- 登录态使用真实登录用户维度。
-- External API Key 态使用 `ExternalApiPrincipal.owner_user_id`,必要时保留 `key_id`。
-- 不记录 token、API Key 明文或签名 URL。
-- External v1 不能因为当前没有 route spec 而漏记。
-
-### 10.2 #226 最终门禁
-
-完成 #226 前,不要求 #225 已经合并;但必须把以下材料交给 #225:
-
-- Header 名和值。
-- 主站/第三方请求边界。
-- 账号态和 External Key 态路径说明。
-- 正向测试结果摘要。
-- 负向测试结果摘要。
-- `metadata.client = "agc"` 的落库约定。
-
-### 10.3 最终验证命令
-
-按改动范围运行:
-
-- AGC TS 相关定向测试。
-- AGC Rust 相关定向测试或 `cargo test` 子集。
-- 必要的 mock HTTP 请求捕获测试。
-- `npm run check:encoding`。
-- `git diff --check`。
-- 检查 `git status --short`,确保没有构建产物、日志、凭据和无关文件。
-
-### 10.4 阶段 6 实施记录
-
-阶段 6 已完成,跨 origin 重定向复审修复已收口;交给 `#225` 的固定材料已在
-[【实施方案】Issue226-AGC客户端主站请求统一标记-2026-09-01.md](C:/projects/narrative/Genarrative/local-docs/【实施方案】Issue226-AGC客户端主站请求统一标记-2026-09-01.md)
-第 12 节集中确认:Header 为 `X-Genarrative-Client: agc`,tracking metadata 使用 `client: "agc"`,主站按实际 method/path 和真实认证主体记录;缺失/空值/未知 Header 不拒绝请求。该交接不要求 `#226` 再回改客户端,也不要求本阶段实现 `#225` 的主站 tracking、数据库或后台代码。
-
-最终门禁已通过:
-
-- TS `clientHttp` 定向测试:14 tests passed。
-- AGC TS 类型检查:通过。
-- Rust `http_client` factory:7 tests passed,覆盖同源跟随、跨 origin 阻断、链式重定向和显式 `Policy::none()`。
-- Rust `omits_agc_marker`:4 tests passed;loopback 认证边界:1 test passed。
-- 账号态主站 mock 捕获:1 test passed。
-- External Key 态主站 mock 捕获:1 test passed。
-- 签名 URL 下载边界:1 test passed。
-- 提交响应丢失幂等回归:1 test passed。
-- Rust fmt、`npm run check:encoding`、`git diff --check`:通过。
-
-发布环境说明:本阶段没有执行真实发布环境线上 smoke;账号态/External Key 态使用本地 mock 和自定义 `apiBaseUrl` fixture 验证。真实发布环境 smoke 留给发布前或 `#225` 联调门禁,不影响 `#226` 客户端实现完成判定。
-
-## 11. 建议提交/评审节奏
-
-为方便阶段验收,建议在同一个 `#226` PR 内按以下逻辑组织提交或至少按阶段分组:
-
-1. 契约常量、TS 统一出口和 TS 测试。
-2. Rust 主站 Client Builder factory。
-3. Rust 主站 Client 创建点迁移。
-4. 第三方请求隔离和负向测试。
-5. 账号态/External 态回归、文档和最终门禁。
-
-如果仓库提交策略要求单提交,也应在 PR 描述中按上述五组列出,确保每组都能单独 review 和验收。
diff --git a/local-docs/【扫描清单】AGC客户端主站调用与可标记点-2026-09-01.md b/local-docs/【扫描清单】AGC客户端主站调用与可标记点-2026-09-01.md
deleted file mode 100644
index 5cbe08b61..000000000
--- a/local-docs/【扫描清单】AGC客户端主站调用与可标记点-2026-09-01.md
+++ /dev/null
@@ -1,228 +0,0 @@
-# AGC 客户端主站调用与可标记点清单
-
-更新时间:2026-09-01
-范围:`apps/ai-game-creator-shell` 对 Genarrative 主站的调用扫描
-状态:只读盘点,未修改客户端、主站、OpenAPI 或数据库代码
-
-## 1. 使用说明
-
-本清单把调用分成三类:
-
-1. **已在 AGC 源码中发现的实际主站调用**:后续应纳入统一客户端标记范围。
-2. **主站 External v1 契约存在、但本次没有在 AGC 非测试源码中发现直接调用的接口**:作为潜在漏项保留,落地前需再次确认调用方。
-3. **明确不是主站的请求**:不应计入 AGC 主站调用统计,也不应加主站调用标记。
-
-同一 AGC 能力可能有两套真实路径:
-
-- 登录账号态:使用平台账号 access token,External 语义路径会映射到站内 `/api/editor`、`/api/assets`、`/api/runtime`。
-- 开发者 API Key 态:使用 `tnr_sk_...`,保留 `/api/external/v1/...` 路径。
-
-因此记录时应以主站实际收到的 `method + path + marker + request_id` 为准,不要只依赖客户端账本中的 External v1 endpoint。
-
-## 2. 建议的统一标记
-
-推荐先使用一个稳定请求头:
-
-```http
-X-Genarrative-Client: agc
-```
-
-可继续复用已有 `X-Request-ID` 作为单次请求关联 ID。若后续需要区分一次客户端请求与重试,可另加每请求唯一的 `X-Genarrative-Client-Request-Id`,但不属于本次必须项。
-
-标记只用于来源审计和统计,不得用于鉴权、权限、计费或账号归属判断。主站仍应以登录 access token 或 External API Key 的真实认证主体为准。
-
-## 3. 已发现的实际调用:Web/TS 层
-
-统一网络出口:
-
-- [clientHttp.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientHttp.ts)
-- `fetchClientHttp` 根据环境使用浏览器 `fetch` 或 Tauri HTTP 插件。
-- 这一层适合统一注入标记,但不能覆盖 Tauri/Rust 的 `reqwest` 直连。
-
-### 3.1 认证调用
-
-统一封装:`clientAuth.ts` 的 `requestAuthJson`。
-
-| 编号 | 方法 | 路径 | 用途 | 认证 | 标记建议 | 代码位置 |
-|---|---|---|---|---|---|---|
-| TS-A01 | GET | `/api/auth/me` | 获取当前用户 | Bearer,可选 | 应加 | [clientAuth.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientAuth.ts:169) |
-| TS-A02 | POST | `/api/auth/refresh` | 刷新 access token | 无 Bearer | 应加 | [clientAuth.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientAuth.ts:183) |
-| TS-A03 | POST | `/api/auth/entry` | 手机号+密码登录 | 无 Bearer | 应加 | [clientAuth.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientAuth.ts:210) |
-| TS-A04 | POST | `/api/auth/phone/send-code` | 发送登录验证码 | 无 Bearer | 应加 | [clientAuth.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientAuth.ts:232) |
-| TS-A05 | POST | `/api/auth/phone/login` | 手机号+验证码登录 | 无 Bearer | 应加 | [clientAuth.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientAuth.ts:253) |
-| TS-A06 | POST | `/api/auth/logout` | 退出登录;失败时可能刷新后重试 | Bearer | 应加 | [clientAuth.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientAuth.ts:275) |
-
-### 3.2 素材、账户和钱包调用
-
-统一封装:`clientApi.ts` 的 `requestClientApi` / `requestClientApiBytes`。
-
-| 编号 | 方法 | 路径 | 用途 | 标记建议 | 代码位置 |
-|---|---|---|---|---|---|
-| TS-B01 | GET | `/api/editor/assets/library` | 读取平台素材库 | 应加 | [clientApi.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientApi.ts:164) |
-| TS-B02 | GET | `/api/assets/read-url?objectKey=...` | 获取素材签名读取地址 | 应加 | [clientApi.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientApi.ts:176) |
-| TS-B03 | GET | `/api/assets/read-bytes?objectKey=...` | 读取素材二进制 | 应加 | [clientApi.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientApi.ts:190) |
-| TS-B04 | GET | `/api/profile/dashboard` | 读取余额/账户概览 | 应加 | [clientApi.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientApi.ts:198) |
-| TS-B05 | GET | `/api/profile/recharge-center` | 读取充值中心 | 应加 | [clientApi.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientApi.ts:206) |
-| TS-B06 | POST | `/api/profile/recharge/orders` | 创建充值订单 | 应加 | [clientApi.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientApi.ts:214) |
-| TS-B07 | POST | `/api/profile/recharge/orders/{orderId}/wechat/confirm` | 确认微信支付订单 | 应加 | [clientApi.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientApi.ts:229) |
-| TS-B08 | GET | `/api/profile/wallet-ledger` | 读取钱包流水 | 应加 | [clientApi.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientApi.ts:237) |
-
-## 4. 已发现的实际调用:Tauri/Rust 层
-
-Rust 层直接使用 `reqwest`,不会经过 TS 的 `fetchClientHttp`,必须单独覆盖。
-
-### 4.1 开发者 Key 与项目/素材上下文
-
-核心路由分流在:
-
-- [external_editor_bindings.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/external_editor_bindings.rs:88)
-
-| 编号 | External v1 语义路径 | 账号态实际路径 | 用途 | 标记建议 | 代码位置 |
-|---|---|---|---|---|---|
-| RS-C01 | `POST /api/profile/api-keys` | 同路径 | 创建本机 AGC 开发者 API Key | 应加 | [assets.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/assets.rs:384) |
-| RS-C02 | `GET /api/external/v1/editor/projects` | `GET /api/editor/projects` | 列出/查找画布项目 | 应加 | [canvas_generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/generation/canvas_generation.rs:1119) |
-| RS-C03 | `POST /api/external/v1/editor/projects` | `POST /api/editor/projects` | 创建画布项目 | 应加 | [canvas_generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/generation/canvas_generation.rs:1151) |
-| RS-C04 | `GET /api/external/v1/editor/projects/{projectId}` | `GET /api/editor/projects/{projectId}` | 读取项目、恢复或同步 | 应加 | [assets.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/assets.rs:717) |
-| RS-C05 | `GET /api/external/v1/editor/assets/library` | `GET /api/editor/assets/library` | 读取账户素材库 | 应加 | [canvas_generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/generation/canvas_generation.rs:1196) |
-| RS-C06 | `POST /api/external/v1/editor/assets/folders` | `POST /api/editor/assets/folders` | 创建素材文件夹 | 应加 | [canvas_generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/generation/canvas_generation.rs:1224) |
-| RS-C07 | `POST /api/external/v1/assets/direct-upload-tickets` | `POST /api/assets/direct-upload-tickets` | 获取对象存储直传凭证 | 应加 | [canvas_generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/generation/canvas_generation.rs:1532) |
-| RS-C08 | `POST /api/external/v1/assets/objects/confirm` | `POST /api/assets/objects/confirm` | 确认已上传对象 | 应加 | [canvas_generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/generation/canvas_generation.rs:1629) |
-| RS-C09 | `GET /api/external/v1/assets/read-url` | `GET /api/assets/read-url` | 换签读取素材 | 应加 | [assets.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/assets.rs:1245) |
-| RS-C10 | `POST /api/external/v1/editor/projects/{projectId}/resources` | `POST /api/editor/projects/{projectId}/resources` | 登记项目画布资源 | 应加 | [canvas_generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/generation/canvas_generation.rs:1659) |
-
-### 4.2 生成、去背景和异步轮询
-
-| 编号 | 方法 | External v1 语义路径 | 账号态实际路径 | 用途 | 标记建议 | 代码位置 |
-|---|---|---|---|---|---|---|
-| RS-G01 | POST | `/api/external/v1/editor/images/generations` | `/api/editor/images/generations` | 图片生成 | 应加 | [canvas_generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/generation/canvas_generation.rs:941) |
-| RS-G02 | POST | `/api/external/v1/editor/images/edits` | `/api/editor/images/edits` | 图片编辑/重绘 | 应加 | [generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/asset_canvas/generation.rs:2827) |
-| RS-G03 | POST | `/api/external/v1/editor/images/background-removals` | `/api/editor/images/background-removals` | 图片去背景 | 应加 | [direct_tool_bridge.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/direct_tool_bridge.rs:1818) |
-| RS-G04 | POST | `/api/external/v1/editor/icon-spritesheets/generations` | `/api/editor/icon-spritesheets/generations` | 图标图集/切片生成 | 应加 | [canvas_generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/generation/canvas_generation.rs:6290) |
-| RS-G05 | POST | `/api/external/v1/editor/character-animations/generations` | `/api/editor/character-animations/generations` | 角色动画生成 | 应加 | [resource_editor.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/resource_editor.rs:2344) |
-| RS-G06 | POST | `/api/external/v1/editor/videos/generations` | `/api/editor/videos/generations` | 视频生成 | 应加 | [resource_editor.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/resource_editor.rs:2373) |
-| RS-G07 | POST | `/api/external/v1/editor/audios/sound-effects/generations` | `/api/editor/audios/sound-effects/generations` | 音效生成 | 应加 | [resource_editor.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/resource_editor.rs:2391) |
-| RS-G08 | POST | `/api/external/v1/editor/audios/background-music/generations` | `/api/editor/audios/background-music/generations` | 背景音乐生成 | 应加 | [resource_editor.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/resource_editor.rs:2408) |
-| RS-G09 | GET | `/api/external/v1/generations/{operationId}` | `/api/runtime/external-generation/jobs/{operationId}` | External Key/账号态生成任务轮询 | 应加 | [external_editor_bindings.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/external_editor_bindings.rs:100) |
-
-资源编辑器统一提交和轮询还位于:
-
-- [resource_editor.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/resource_editor.rs:2498)
-- [resource_editor.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/resource_editor.rs:2614)
-
-### 4.3 Direct Runtime 恢复与账户素材导入
-
-| 编号 | 方法 | 路径 | 用途 | 标记建议 | 代码位置 |
-|---|---|---|---|---|---|
-| RS-R01 | GET | `/api/external/v1/editor/projects/{projectId}` 或 `/api/editor/projects/{projectId}` | Direct Runtime 只读恢复项目资源 | 应加 | [direct_runtime.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/direct_runtime.rs:2487) |
-| RS-R02 | GET | `/api/external/v1/assets/read-url` 或 `/api/assets/read-url` | 账户素材导入前换签 | 应加 | [commands.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/commands.rs:3833) |
-| RS-R03 | GET | `/api/external/v1/editor/assets/library` 或 `/api/editor/assets/library` | 查询当前账号素材并按 assetId 选择 | 应加 | [commands.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/commands.rs:3283) |
-| RS-R04 | GET | `/api/external/v1/editor/projects/{projectId}` 或 `/api/editor/projects/{projectId}` | 读取项目画布资源清单 | 应加 | [commands.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/commands.rs:3327) |
-
-## 5. 已知的现有 body 内来源字段
-
-这些字段不是统一 Header,且不会被全局 HTTP tracking middleware 自动读取,只能作为业务请求内部来源信息:
-
-| 来源值 | 出现位置 | 覆盖范围 | 说明 |
-|---|---|---|---|
-| `ai-game-creator-client` | [canvas_generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/generation/canvas_generation.rs:951) | 部分图片生成请求 | 账号态图片生成 helper 会写入 `generationInputs.source` |
-| `game-creator-account-binding` | [generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/asset_canvas/generation.rs:2311) | 项目资源登记 | 表示 AGC 账户绑定上下文 |
-| `game-creator-resource-editor` | [generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/asset_canvas/generation.rs:2796) | 资源编辑生成输入 | 表示 AGC 资源编辑链路 |
-
-这些 body 字段不能替代统一请求标记,因为它们不覆盖登录、列表、素材读取、钱包、上传凭证、对象确认和任务轮询等请求;并且主站 tracking 当前不会解析生成请求 body 中的 `generationInputs.source`。
-
-## 6. External v1 契约中存在、但本次未发现 AGC 直接调用的潜在接口
-
-这些接口在 [genarrative-external-v1.openapi.json](C:/projects/narrative/Genarrative/docs/openapi/genarrative-external-v1.openapi.json) 中存在。它们应保留在后续核对清单中,但本次不把它们误报为 AGC 已实际调用:
-
-### 6.1 项目管理
-
-- `GET /api/external/v1/editor/projects/recent`
-- `DELETE /api/external/v1/editor/projects/{projectId}`
-- `PATCH /api/external/v1/editor/projects/{projectId}/metadata`
-- `PATCH /api/external/v1/editor/projects/{projectId}/canvas`
-
-### 6.2 素材文件夹和素材记录管理
-
-- `PATCH /api/external/v1/editor/assets/folders/{folderId}`
-- `DELETE /api/external/v1/editor/assets/folders/{folderId}`
-- `POST /api/external/v1/editor/assets`
-- `PATCH /api/external/v1/editor/assets/{assetId}`
-- `DELETE /api/external/v1/editor/assets/{assetId}`
-
-### 6.3 UI 设计图素材提取
-
-- `POST /api/external/v1/editor/ui-designs/assets/extractions`
-
-当前 AGC Prompt 明确要求不要误用这个接口,而是通过图片生成链路生成 UI 原型,因此它目前属于契约潜在接口,不属于已确认实际调用。
-
-### 6.4 External API 发现和协议接口
-
-这些是公开契约/集成发现能力,不属于普通 AGC 主站业务调用;若未来 AGC 直接接入 MCP 或远程 Skill,再单独纳入:
-
-- `GET /api/external/v1/openapi.json`
-- `GET /api/external/v1/agent-integration.json`
-- `GET /api/external/v1/skill/SKILL.md`
-- `GET /api/external/v1/skill.zip`
-- `POST /api/external/v1/mcp`
-
-## 7. 明确排除的请求
-
-以下请求不是 AGC 调用主站,不应进入主站调用标记统计:
-
-- LLM Provider:`POST {provider}/responses`,见 [codex_provider_proxy.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/codex_provider_proxy.rs)。
-- OSS/对象存储上传:主站返回直传票据后,客户端向票据 host 发出的 multipart POST。
-- 签名素材下载:`read-url` 返回临时地址后,对签名地址发出的二进制 GET。
-- AGC 受控网页搜索:见 [direct_tool_bridge.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/direct_tool_bridge.rs:2201)。
-- 本地 Tauri IPC、文件读写、浏览器试玩页面请求。
-
-## 8. 主站承接标记的现状
-
-### 8.1 请求上下文
-
-主站请求上下文位于:
-
-- [request_context.rs](C:/projects/narrative/Genarrative/server-rs/crates/api-server/src/request_context.rs)
-
-当前已有 `request_id`、operation 和计时信息,但没有 client/source/marker 字段。
-
-### 8.2 全局 tracking
-
-主站全局 middleware 和 route tracking 位于:
-
-- [app.rs](C:/projects/narrative/Genarrative/server-rs/crates/api-server/src/app.rs)
-- [tracking.rs](C:/projects/narrative/Genarrative/server-rs/crates/api-server/src/tracking.rs)
-
-当前特点:
-
-- 主要在成功响应后写 route tracking event。
-- `/api/auth`、`/api/profile`、`/api/assets`、`/api/editor`、`/api/runtime` 已有部分 route spec。
-- `/api/external/v1/*` 当前没有 route spec,所以 External API Key 模式的 AGC 调用不会自动进入现有 route tracking。
-- External API 鉴权中间件已有 `ExternalApiPrincipal`,可提供 `owner_user_id` 和 `key_id`,但现有成功 route tracking 只显式读取登录态 `AuthenticatedAccessToken`,需要单独确认 External principal 的接入方式。
-
-### 8.3 数据库和后台
-
-现有 SpacetimeDB `tracking_event` 已有 `metadata_json`,适合第一阶段记录:
-
-```json
-{
- "client": "agc",
- "route": "/api/editor/images/generations",
- "method": "POST",
- "status": 202
-}
-```
-
-后台当前 tracking 查询支持 event、user、scope、日期等结构化条件,不能直接按 `metadata_json.client` 高效筛选。若后续需要高频按客户端筛选,再考虑新增独立 `client_marker` 字段和索引;这会涉及 schema、migration、绑定和相关门禁。
-
-## 9. 后续实现前的核对顺序
-
-本文件只作为调用盘点,不代表已经授权改造。真正落地前建议按以下顺序重新核对:
-
-1. 以本清单的“实际调用”表为准,逐个确认非测试源码仍有调用。
-2. 先覆盖 TS `fetchClientHttp`。
-3. 再覆盖 Rust 的公共 External Editor 请求构造点和剩余直接 `reqwest` 调用。
-4. 确认账号态映射路径与开发者 Key External v1 路径都能携带同一标记。
-5. 主站解析 Header 时使用白名单值,未知值按未标记处理,不影响业务请求。
-6. route tracking 同时补充 External v1 路径和 External API principal 维度。
-7. 第一阶段优先写 `metadata_json`,暂不急于改 SpacetimeDB schema。
-8. 验证成功、失败、重试、异步轮询、401、上传凭证和钱包请求是否都能按预期区分。
diff --git a/local-docs/【技术方案】AGC主站请求标记统一注入两种方案-2026-09-01.md b/local-docs/【技术方案】AGC主站请求标记统一注入两种方案-2026-09-01.md
deleted file mode 100644
index 7c938c0ab..000000000
--- a/local-docs/【技术方案】AGC主站请求标记统一注入两种方案-2026-09-01.md
+++ /dev/null
@@ -1,414 +0,0 @@
-# AGC 主站请求标记统一注入两种方案
-
-更新时间:2026-09-01
-关联 Issue:`#226 添加客户端特殊标识`、`#225 添加客户端埋点统计`
-状态:方案说明,未实施代码修改
-
-## 1. 背景
-
-AGC 客户端同时存在两套 HTTP 出口:
-
-1. Web/TS 层,通过 `fetchClientHttp` 使用浏览器 `fetch` 或 Tauri HTTP 插件。
-2. Tauri/Rust 层,通过多个 `reqwest::Client` 直接调用主站、对象存储、签名下载地址、LLM Provider 和本地工具桥。
-
-目标是让 AGC 发往主站的请求统一携带来源标记,而不是在每个业务 API 调用点重复写 Header。
-
-推荐标记:
-
-```http
-X-Genarrative-Client: agc
-```
-
-该标记只用于来源审计、埋点和统计,不参与鉴权、权限、计费或账号归属判断。
-
-## 2. 目标与不做项
-
-### 2.1 目标
-
-- AGC 发往当前选定主站 origin 的请求统一携带客户端标记。
-- 同时覆盖登录账号态和开发者 API Key 态。
-- 同时覆盖普通业务请求、生成提交和异步任务轮询。
-- 避免在每个 `/api/...` 调用点重复设置 Header。
-- 不把标记发送给 OSS、签名资源地址、LLM Provider、网页搜索或本地工具桥。
-- 保持现有 access token、API Key、幂等键和请求体语义不变。
-
-### 2.2 不做项
-
-- 本方案不定义主站数据库字段和后台页面实现,主站接收与落库属于 `#225`。
-- 不使用客户端标记替代真实认证主体。
-- 不修改 External v1 请求 DTO 或 OpenAPI 请求体。
-- 不通过 DNS、系统代理或网络抓包层注入 Header。
-- 不给进程内所有 `reqwest` 请求无差别设置默认 Header。
-
-## 3. 两种方案的共同部分
-
-无论 Rust 层选择哪种方案,Web/TS 层都可以直接在统一出口注入。
-
-### 3.1 Web/TS 统一出口
-
-文件:
-
-- [clientHttp.ts](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src/services/clientHttp.ts)
-
-处理方式:
-
-1. `fetchClientHttp` 解析最终请求地址。
-2. 确认目标 origin 等于当前选定的 `serverBaseUrl`。
-3. 在传给浏览器 `fetch` 或 Tauri HTTP 插件前设置:
-
-```http
-X-Genarrative-Client: agc
-```
-
-示意代码:
-
-```ts
-const headers = new Headers(init.headers);
-headers.set('X-Genarrative-Client', 'agc');
-
-return transport(target.url, {
- ...init,
- headers,
-});
-```
-
-需要保留调用方原有 Header,尤其是:
-
-- `Authorization`
-- `Content-Type`
-- `x-genarrative-response-envelope`
-- `X-Request-ID`,如果调用方已提供
-
-### 3.2 主站 origin 的定义
-
-不能只写死以下两个地址:
-
-```text
-https://dev.genarrative.world
-https://www.genarrative.world
-```
-
-AGC 还支持自定义服务器,判断依据应是当前请求绑定的权威 `serverBaseUrl` / `apiBaseUrl`,并比较规范化后的 origin:
-
-```text
-scheme + host + effective port
-```
-
-路径、query 和 fragment 不属于 origin 判断条件。
-
-### 3.3 必须排除的请求
-
-以下请求不能携带主站客户端标记:
-
-- `direct-upload-tickets` 返回的对象存储 multipart 上传地址。
-- `read-url` 返回的临时签名下载地址。
-- LLM Provider 的 `/responses` 等请求。
-- AGC 受控网页搜索请求。
-- 本地 loopback 工具桥请求。
-- 游戏试玩页面、外部网页或用户输入的任意 URL。
-
-### 3.4 CORS
-
-浏览器环境向不同 origin 的主站发送自定义 Header 时可能触发 CORS 预检。主站及自定义部署需要允许:
-
-```http
-Access-Control-Allow-Headers: X-Genarrative-Client
-```
-
-Tauri HTTP 插件和 Rust `reqwest` 不受浏览器 CORS 限制,但仍应遵守相同的目标 origin 边界。
-
-## 4. 方案一:专用主站 HTTP Client 工厂
-
-### 4.1 核心思路
-
-为 Rust 层建立一个只允许服务于主站 API 的 `reqwest::Client` 构造函数,并通过 `default_headers` 自动加入客户端标记;请求发送前再由轻量终结器覆盖同名 Header,确保调用方不能伪造标记值。
-
-第三方上传、签名下载、Provider 和搜索继续使用现有独立 Client,不带标记。
-
-示意代码:
-
-```rust
-fn build_agc_main_site_client(timeout: Duration) -> Result {
- let mut headers = reqwest::header::HeaderMap::new();
- headers.insert(
- reqwest::header::HeaderName::from_static("x-genarrative-client"),
- reqwest::header::HeaderValue::from_static("agc"),
- );
-
- let default_policy = reqwest::redirect::Policy::default();
- let redirect_policy = reqwest::redirect::Policy::custom(move |attempt| {
- let same_origin = attempt
- .previous()
- .first()
- .map(|initial| initial.origin() == attempt.url().origin())
- .unwrap_or(false);
- if same_origin {
- default_policy.redirect(attempt)
- } else {
- attempt.stop()
- }
- });
-
- reqwest::Client::builder()
- .default_headers(headers)
- .connect_timeout(Duration::from_secs(10))
- .timeout(timeout)
- .redirect(redirect_policy)
- .build()
- .map_err(|error| format!("创建 AGC 主站 HTTP 客户端失败:{error}"))
-}
-```
-
-调用代码仍然保持普通 `reqwest` 写法:
-
-```rust
-let client = build_agc_main_site_client(Duration::from_secs(60))?;
-
-let response = with_agc_main_site_marker(
- client
- .get(format!("{api_base_url}{route}"))
- .bearer_auth(token),
-)
- .send()
- .await?;
-```
-
-业务请求不再逐个调用 `.header("X-Genarrative-Client", "agc")`;由统一终结器在发送前覆盖调用方同名值。
-
-### 4.2 预计改动范围
-
-主要改动是把主站用途的 `reqwest::Client::new()` / `Client::builder()` 替换为统一工厂,而不是修改每个 API endpoint。
-
-潜在涉及文件:
-
-- [assets.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/assets.rs)
-- [commands.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/commands.rs)
-- [canvas_generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/generation/canvas_generation.rs)
-- [direct_runtime.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/direct_runtime.rs)
-- [direct_tool_bridge.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/direct_tool_bridge.rs)
-- [generation.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/asset_canvas/generation.rs)
-- [resource_editor.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/project/resource_editor.rs)
-
-不应迁移到主站 Client 的文件或请求:
-
-- [codex_provider_proxy.rs](C:/projects/narrative/Genarrative/apps/ai-game-creator-shell/src-tauri/src/agent/codex_provider_proxy.rs)
-- `build_external_asset_download_client` 创建的签名资源下载 Client。
-- OSS multipart 上传 Client。
-- 受控搜索和 loopback 工具桥 Client。
-
-### 4.3 优点
-
-- 实现简单,符合当前仓库优先简单设计的原则。
-- 业务请求代码基本不变。
-- Header 由 factory 默认注入,终结器在发送前统一覆盖同名值。
-- 不需要新增 HTTP middleware 框架或复杂泛型包装。
-- 便于为普通请求和长时间生成提交提供不同 timeout,但共享同一标记配置。
-- 可以通过单元测试检查 Client 发出的请求自动带标记。
-
-### 4.4 缺点和风险
-
-- `default_headers` 对该 Client 发出的所有请求生效,不会再次判断目标域名。
-- `default_headers` 不能覆盖请求级同名 Header;新增的主站直发路径若绕过请求终结器,仍可能发送错误值。
-- 如果后续有人误用主站 Client 请求 OSS、签名 URL 或 Provider,标记会被带到第三方。
-- 当前存在多个不同 timeout 的 Client,需要提供少量参数或几个明确的工厂函数。
-- 仍需要替换现有主站 Client 的创建点,无法做到完全零调用点改动。
-
-### 4.5 风险控制
-
-保持控制简单,不引入复杂网络状态机:
-
-- 主站 Client 只在持有权威 `apiBaseUrl` 的模块中创建。
-- 主站 Client 不传给通用下载函数。
-- 签名下载继续由 `build_external_asset_download_client` 单独创建。
-- OSS 上传继续使用单独 Client。
-- 工厂名称明确包含 `main_site`,避免误用。
-- 所有 AGC 主站请求的最终 `.send()` 前统一经过 `with_agc_main_site_marker`;新增直发路径必须同步接入该终结器。
-- 定向测试断言主站 mock 收到标记、第三方 mock 未收到标记。
-
-## 5. 方案二:按目标 origin 的请求包装器
-
-### 5.1 核心思路
-
-不依赖 Client 的默认 Header,而是统一通过一个请求构造入口创建主站 RequestBuilder。
-
-包装器在构造请求时:
-
-1. 解析目标 URL。
-2. 解析当前权威 `apiBaseUrl`。
-3. 比较两者 origin。
-4. 只有同源时加入 AGC 标记。
-5. 非同源时拒绝,或明确返回不带标记的普通请求。
-
-更安全的做法是主站包装器直接拒绝非同源 URL。
-
-示意代码:
-
-```rust
-fn main_site_request(
- client: &reqwest::Client,
- method: reqwest::Method,
- api_base_url: &str,
- route: &str,
-) -> Result {
- let base = url::Url::parse(api_base_url)
- .map_err(|_| "AGC 主站地址无效".to_string())?;
- let target = base
- .join(route)
- .map_err(|_| "AGC 主站请求路径无效".to_string())?;
-
- if target.origin() != base.origin() {
- return Err("AGC 主站请求越出当前服务器 origin".to_string());
- }
-
- Ok(client
- .request(method, target)
- .header("X-Genarrative-Client", "agc"))
-}
-```
-
-调用示意:
-
-```rust
-let response = main_site_request(
- &client,
- reqwest::Method::GET,
- access.api_base_url(),
- &route,
-)?
-.bearer_auth(access.bearer_token())
-.send()
-.await?;
-```
-
-### 5.2 预计改动范围
-
-所有主站 `.get(...)`、`.post(...)`、`.patch(...)`、`.delete(...)` 构造点需要切换为包装器,或统一封装为一个 `AgcMainSiteHttp` 类型。
-
-例如:
-
-```rust
-struct AgcMainSiteHttp {
- client: reqwest::Client,
- base_url: url::Url,
-}
-
-impl AgcMainSiteHttp {
- fn get(&self, route: &str) -> Result;
- fn post(&self, route: &str) -> Result;
-}
-```
-
-下载、OSS 和 Provider 请求继续直接使用普通 `reqwest::Client`。
-
-### 5.3 优点
-
-- 每次请求都会校验真实目标 origin。
-- 即使包装器被误用于第三方 URL,也可以失败关闭,不会泄漏标记。
-- 主站 URL 拼接和 origin 校验有单一权威实现。
-- 适合未来出现更多动态 URL、多个部署 origin 或更严格的请求来源策略。
-- 可以在同一个入口继续注入 request ID、客户端版本等非敏感请求元信息。
-
-### 5.4 缺点和风险
-
-- 需要修改更多请求构造点。
-- 容易把简单的 Header 注入扩大成新的 HTTP 抽象层。
-- 现有代码已经有 `ExternalEditorBindingAccess`、路由映射、冻结会话校验等概念,再新增完整 HTTP facade 会增加概念数量。
-- 如果包装器同时承接鉴权、重试、错误解析、幂等和下载,很容易过度设计。
-- 对只需要固定来源标记的当前需求,复杂度高于方案一。
-
-### 5.5 风险控制
-
-- 包装器只负责 URL 构造、origin 校验和固定 Header,不负责业务错误解析。
-- 不在包装器中自动重试 POST。
-- 不把 token、API Key 或幂等键保存到长生命周期对象。
-- `ExternalEditorBindingAccess` 继续负责账号态/开发者 Key 路由映射和冻结会话校验。
-- 业务层继续明确设置 Bearer、Idempotency-Key 和请求体。
-
-## 6. 两种方案对比
-
-| 对比项 | 方案一:专用主站 Client 工厂 | 方案二:origin 请求包装器 |
-|---|---|---|
-| Header 注入位置 | `reqwest::Client::default_headers` | 每次构造 RequestBuilder 时 |
-| 业务调用点改动 | 较少,主要替换 Client 创建点 | 较多,需要替换请求构造点 |
-| 第三方泄漏防护 | 依赖 Client 使用边界 | 每次请求显式 origin 校验 |
-| 实现复杂度 | 低 | 中 |
-| 新增概念数量 | 少 | 较多 |
-| 支持不同 timeout | 通过工厂参数或少量变体 | 共用 Client 或包装器配置 |
-| 对动态 URL 的安全性 | 一般 | 高 |
-| 当前需求适配度 | 高 | 中 |
-| 后续扩展请求元信息 | 可以,但仍是 Client 级别 | 更灵活,可按请求控制 |
-| 误用后的行为 | 可能把标记发给非主站 | 可拒绝非同源请求 |
-
-## 7. 推荐选择
-
-当前推荐 **方案一:专用主站 HTTP Client 工厂**。
-
-理由:
-
-- 当前需求只是给主站请求增加稳定来源标记。
-- 主站、签名下载、OSS 和 Provider 已有相对明确的客户端边界。
-- 不需要为一个固定 Header 引入新的 HTTP facade。
-- 改动集中在 Client 创建点,业务请求路径和错误语义变化较小。
-- 更符合仓库“优先简单、避免过度设计”的约束。
-
-方案一需要明确遵守:主站 Client 不能用于签名下载、OSS 上传和 Provider 请求。如果实施时发现多个模块无法可靠维持这条边界,或存在大量由外部数据生成的动态目标 URL,再改选方案二。
-
-不建议一开始同时实现两种方案。二选一即可,避免形成“Client 默认 Header + RequestBuilder 再加一次 Header”的重复机制。
-
-## 8. 建议的 PR 边界
-
-### 8.1 `#226 添加客户端特殊标识`
-
-负责:
-
-- TS `fetchClientHttp` 统一注入标记。
-- Rust 按选定方案统一注入标记。
-- 主站请求携带标记。
-- 第三方请求不携带标记。
-- 必要的 CORS Header 配置验证。
-
-不负责:
-
-- tracking event 落库。
-- External v1 route tracking。
-- 后台筛选和统计展示。
-
-### 8.2 `#225 添加客户端埋点统计`
-
-负责:
-
-- 主站读取并校验客户端标记。
-- 结合登录用户或 `ExternalApiPrincipal` 记录认证主体。
-- 将标记写入 `tracking_event.metadata_json` 或后续确定的结构化字段。
-- 补齐 `/api/external/v1/*` tracking。
-- 后台查询、筛选或统计。
-
-## 9. 验收清单
-
-### 9.1 正向请求
-
-- TS 登录请求带 `X-Genarrative-Client: agc`。
-- TS 素材、钱包请求带标记。
-- Rust 账号态 `/api/editor/*` 请求带标记。
-- Rust 账号态 `/api/assets/*` 请求带标记。
-- Rust 账号态 `/api/runtime/external-generation/jobs/*` 轮询带标记。
-- Rust API Key 态 `/api/external/v1/*` 请求带标记。
-- `/api/profile/api-keys` 请求带标记。
-- 自定义主站 origin 的请求带标记。
-
-### 9.2 排除请求
-
-- OSS multipart 上传不带标记。
-- 签名 URL 下载不带标记。
-- LLM Provider 请求不带标记。
-- AGC 受控搜索不带标记。
-- 本地工具桥请求不带标记。
-
-### 9.3 兼容性
-
-- 原 Authorization 不变。
-- 原 Idempotency-Key 不变。
-- 原请求 body 不变。
-- 原 timeout 不变;同源 redirect policy 语义不变,跨 origin redirect 由主站 Client factory 阻断。
-- 浏览器跨域预检允许 `X-Genarrative-Client`。
-- 未识别 marker 时主站业务请求不受影响。
diff --git a/local-docs/【阶段验收】Issue225阶段5定向测试与安全边界-2026-09-02.md b/local-docs/【阶段验收】Issue225阶段5定向测试与安全边界-2026-09-02.md
deleted file mode 100644
index a2e7d1003..000000000
--- a/local-docs/【阶段验收】Issue225阶段5定向测试与安全边界-2026-09-02.md
+++ /dev/null
@@ -1,105 +0,0 @@
-# Issue225 阶段 5:定向测试与安全边界
-
-更新时间:2026-09-02
-关联分支:`feat/agc_call_rec`
-
-## 1. 阶段交付结果
-
-本阶段补齐 Issue #225 直接相关的状态码、鉴权、安全 metadata 和幂等回归,确认 `X-Genarrative-Client: agc` 只是来源审计标签,不改变认证、权限、计费、请求体、异步轮询或成功事件语义。
-
-## 2. 新增回归
-
-### 2.1 成功状态语义
-
-`tracking.rs` 新增 `should_record_route_tracking` 判定测试:
-
-- `200 / 201 / 202 / 204` 的显式业务 route 可以进入成功 tracking;
-- `400 / 401 / 403 / 404 / 500 / 502` 即使带 AGC marker,也不会新增成功 route event;
-- 已由详细资产事件处理的上传票据和对象确认不重复生成统一 route event。
-
-### 2.2 AGC-only 路由门禁
-
-本期新增、仅为 AGC 调用清单补齐的账号态和 External v1 route spec 均要求有效 `X-Genarrative-Client: agc`:
-
-- 带有效 marker 的 2xx 响应才写入 route tracking;
-- 缺失、非法、未知或大小写不符合契约的 marker 不写入这些新增 route event,也不拒绝业务请求;
-- 既有 route spec 和已有详细资产事件保持原有全客户端记录语义。
-
-### 2.3 鉴权边界
-
-`app.rs` 通过真实 router 发起未认证的:
-
-```text
-GET /api/editor/projects
-X-Genarrative-Client: agc
-```
-
-响应仍为 `401 Unauthorized`。marker 不会获得权限,也不会改变失败状态。
-
-### 2.4 metadata 安全边界
-
-route metadata 测试确认不会写入:
-
-```text
-authorization
-accessToken
-token
-apiKey
-cookie
-signature
-signedUrl
-requestBody
-```
-
-有效 marker 只产生固定的 `client: "agc"`,并保留既有 route/method/status/operation 与资产嵌套字段。
-
-### 2.5 既有链路复回归
-
-阶段 4 的以下路径在阶段 5 再次顺序执行:
-
-- `TrackingEventDraft → RuntimeTrackingEventInput`;
-- tracking outbox NDJSON round-trip;
-- `spacetime-client` mapper;
-- module-runtime metadata object 校验;
-- 后台 tracking SQL response parser;
-- 账号态 / External API Key owner 归属;
-- SpacetimeDB tracking event-id 幂等回归。
-
-## 3. 验收结果
-
-- [x] marker 有效值、缺失值、空值、大小写和未知值测试通过。
-- [x] 账号态 `user_id = owner_user_id` 归属测试通过。
-- [x] External API Key 态只写真实 `owner_user_id`,不伪造 `user_id`,scope 使用 owner。
-- [x] 当前账号态和 External v1 业务 route coverage 测试通过。
-- [x] discovery、Skill、MCP 排除测试通过。
-- [x] 2xx 成功记录和 4xx/5xx 不新增成功 route event 测试通过。
-- [x] AGC marker 不绕过鉴权、不改变失败状态。
-- [x] route metadata 不包含 token、API Key、Cookie、签名 URL 或请求体字段。
-- [x] outbox、mapper、runtime input 和后台 readback 回归通过。
-- [x] event-id 幂等回归通过。
-
-## 4. 定向验证结果
-
-| 测试范围 | 通过数 |
-|---|---:|
-| `module-runtime` tracking input | 2 |
-| `spacetime-client` tracking mapper | 1 |
-| `api-server` tracking | 18 |
-| `api-server` app 鉴权回归 | 1 |
-| `api-server` 资产 marker / owner | 2 |
-| `api-server` tracking outbox | 8 |
-| `api-server` 后台 readback | 5 |
-| `spacetime-module` event-id 幂等 | 1 |
-| 合计 | 38 |
-
-另外通过:
-
-- `cargo fmt --manifest-path server-rs/Cargo.toml --all -- --check`
-- `git diff --check`
-- `npm run check:encoding`
-
-未运行与本 Issue 无直接关系的完整工作区测试,按约定交给 CI。没有启动真实 SpacetimeDB,因此没有把确定性 procedure input/mapper 和 admin parser 回归扩大解释为远端数据库 E2E。
-
-## 5. 后续阶段
-
-阶段 6 汇总阶段 1~5 的证据,复核 #226 交接契约、执行最终门禁并准备 Issue #225 交付说明。阶段 5 代码已提交为 `c5170669e`;日登录埋点构造器回归修复补充提交为 `0a06b4988`。
diff --git a/local-docs/【阶段验收】Issue225阶段6最终门禁与交接收口-2026-09-02.md b/local-docs/【阶段验收】Issue225阶段6最终门禁与交接收口-2026-09-02.md
deleted file mode 100644
index a36a13acd..000000000
--- a/local-docs/【阶段验收】Issue225阶段6最终门禁与交接收口-2026-09-02.md
+++ /dev/null
@@ -1,148 +0,0 @@
-# Issue225 阶段6:最终门禁与 #226 交接收口
-
-更新时间:`2026-09-02`
-实施范围:`#225 添加客户端埋点统计`
-交接输入:`#226 添加客户端特殊标识`
-
-执行结论:阶段 6 通过,Issue #225 的主站接收、tracking metadata、主体归属、路由覆盖、持久化/后台读取验证和安全语义回归已收口。本阶段没有新增生产功能,没有修改 #226 客户端实现,不需要 #226 回改设计。
-
-## 1. 阶段边界
-
-本阶段只完成:
-
-1. 汇总阶段 1~5 的实现提交、定向测试和 readback 证据。
-2. 复核 `#226` 交接的 Header、origin、认证和第三方边界。
-3. 执行与本 Issue 直接相关的最终编译、测试、格式、编码和空白门禁。
-4. 更新实施方案、分阶段计划和 Issue #225 交付评论草案。
-
-本阶段明确不做:
-
-- 不修改 `AGC` 客户端的 `fetchClientHttp`、Rust Client factory、请求终结器或 redirect policy。
-- 不新增 `tracking_event` 列、索引、migration、生成 bindings 或新的统计表。
-- 不修改 `/api/external/v1` 的 OpenAPI、DTO、HTTP 方法、状态码、鉴权或异步语义。
-- 不新增后台筛选器、报表页面或真实发布环境线上写入。
-
-## 2. 当前仓库基线
-
-阶段 6 开始时仓库状态:
-
-| 项目 | 结果 |
-|---|---|
-| 分支 | `feat/agc_call_rec` |
-| HEAD | `5aa38d9f3`(已合并最新 `origin/master`) |
-| `origin/master` | `8932f0b27` |
-| 工作树 | 开始阶段 6 时干净;本记录及计划/方案更新属于本阶段待提交文档变更 |
-
-阶段 1~5 的实现提交:
-
-| 阶段 | 提交 |
-|---|---|
-| 阶段 1:marker 解析与 tracking 入口 | `2296f79fd` |
-| 阶段 2:主体归属与 metadata | `2a23ba657` |
-| 阶段 3:路由覆盖 | `01159a269` |
-| 阶段 4:持久化与后台读取 | `c75c61521` |
-| 阶段 5:安全与语义回归 | `c5170669e` |
-| 日登录埋点构造器回归修复 | `0a06b4988` |
-
-## 3. 最终交付行为
-
-### 3.1 Marker 与 metadata
-
-主站识别:
-
-```http
-X-Genarrative-Client: agc
-```
-
-规则:
-
-- Header 名按 HTTP 规则大小写不敏感。
-- Header 值去除首尾空白后,必须精确等于小写 `agc`。
-- 缺失、空值、`AGC` 或未知值按未标记处理,不拒绝请求。
-- 有效标记只追加到已有成功 route tracking 的 `tracking_event.metadata_json`:
-
-```json
-{
- "route": "/api/editor/projects",
- "method": "GET",
- "status": 200,
- "operation": "listEditorProjects",
- "client": "agc"
-}
-```
-
-不写入 Header 原文、token、API Key、Cookie、签名 URL、请求体或项目绝对路径。
-
-本期新增的 AGC route spec 只有在请求带有效 marker 时才记录;既有 route spec 与手工资产事件沿用原有全客户端记录策略。
-
-阶段 6 后续补充了一条轻量 middleware 成功链路回归:真实 `build_router` 请求经过账号认证和 tracking middleware 后写入隔离 outbox,并验证 `client`、实际 route、user/owner 归属;该测试不启动真实 SpacetimeDB,不改变完整环境型 E2E 仍作为发布前 smoke 的边界。
-
-### 3.2 主体归属
-
-- 登录账号态:使用已验证 access token 的真实用户,保留既有 `user_id`、`owner_user_id` 和 scope 语义。
-- External API Key 态:使用 `ExternalApiPrincipal.owner_user_id()`;不伪造登录 `user_id`,User scope 的 `scope_id` 使用 owner。
-- Header 只是来源审计标签,不能绕过认证、权限、计费或替换主体。
-
-### 3.3 路由覆盖与排除
-
-已覆盖的实际业务路径:
-
-- 账号态:`/api/auth/*`、`/api/profile/*`、`/api/assets/*`、`/api/editor/*`、`/api/runtime/*`。
-- External API Key 态:`/api/external/v1/*` 的当前资产、项目、素材库、生成提交和任务轮询业务路径。
-- 动态 project/generation/asset ID 继续按显式静态段规则归一化;External v1 metadata 保留实际外部 path。
-- 上传票据和对象确认沿用已有详细资产事件,不重复生成普通 route event,但会保留有效 AGC metadata。
-
-明确排除:
-
-- OSS multipart 上传、签名 URL/OSS 媒体下载。
-- LLM/Codex Provider、AGC 受控搜索、loopback 工具桥。
-- 更新清单、更新包下载和任意外部网页请求。
-- `/api/external/v1/openapi.json`、`agent-integration.json`、Skill 文档/压缩包和 MCP 入口。
-
-### 3.4 落库与读取位置
-
-AGC 调用记录最终落在主站 SpacetimeDB 的 `tracking_event` 表,标识位于 `tracking_event.metadata_json.client`。普通 route tracking 默认先进入 api-server 本机:
-
-```text
-server-rs/.data/tracking-outbox/active.ndjson
-server-rs/.data/tracking-outbox/sealed-*.ndjson
-```
-
-worker 使用既有 `record_tracking_events_and_return` 批量 procedure 写入 SpacetimeDB;outbox 不可用时沿用同步 `record_tracking_event_and_return` 回退。后台 `GET /admin/api/tracking/events` 读取同一 `tracking_event` 的 `metadata_json`,当前没有单独的 `client=agc` 查询参数,需要从返回 JSON 中识别 `"client": "agc"`。
-
-## 4. 最终门禁证据
-
-| 验收项 | 命令 | 结果 |
-|---|---|---|
-| api-server 编译 | `cargo check --locked --manifest-path server-rs/Cargo.toml -p api-server` | 通过;仅仓库既有 warning |
-| api-server tracking/资产/后台/outbox 定向测试 | `cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server tracking -- --nocapture` | 43 passed,0 failed |
-| marker 不绕过鉴权回归 | `cargo test --locked --manifest-path server-rs/Cargo.toml -p api-server app::tests::agc_marker_does_not_bypass_authentication_or_change_failure_status -- --nocapture` | 1 passed,0 failed |
-| module-runtime tracking input | `cargo test --locked --manifest-path server-rs/Cargo.toml -p module-runtime tracking_input_ -- --nocapture` | 2 passed,0 failed |
-| spacetime-client mapper | `cargo test --locked --manifest-path server-rs/Cargo.toml -p spacetime-client tracking_input_mapper_preserves_agc_metadata_and_external_owner -- --nocapture` | 1 passed,0 failed |
-| SpacetimeDB event-id 幂等 | `cargo test --locked --manifest-path server-rs/Cargo.toml -p spacetime-module duplicate_tracking_event_ids_are_treated_as_idempotent_replays -- --nocapture` | 1 passed,0 failed |
-| Rust 格式 | `cargo fmt --manifest-path server-rs/Cargo.toml --all -- --check` | 通过 |
-| 中文编码 | `npm run check:encoding` | 通过,5662 个文件 |
-| Diff 空白/分支基线 | `git diff --check`、`git merge-base --is-ancestor origin/master HEAD` | 通过 |
-
-与本 Issue 直接相关的本轮定向测试合计 48 个通过。完整工作区测试不在本地重复运行,按约定交给 CI;本地未启动真实 SpacetimeDB,因此没有把 input/mapper/readback parser 测试表述为线上 E2E。
-
-## 5. #226 交接复核
-
-`#226` 已提供并冻结以下输入:
-
-- 发往当前 Genarrative 主站 origin 的业务请求带 `X-Genarrative-Client: agc`。
-- OSS、签名下载、Provider、受控搜索、loopback、更新下载和外部网页请求不带该标记。
-- 同源重定向继续允许;跨 origin 重定向被阻断,避免标记泄漏到第三方 origin。
-- 请求级同名 Header 不能伪造最终值,主站业务请求最终仍为 `agc`。
-
-主站 #225 已按上述契约消费 Header;不存在要求 #226 重新设计或回改的接口缺口。
-
-补充记录一个不属于 #225 的客户端后续项:`clientHttp.ts` 当前把自定义服务器地址的规范化字符串直接与 `URL.origin` 比较;显式默认端口(例如 `https://example.com:443`)或主机名大小写可能导致合法自定义 origin 被误判为跨 origin。该问题表现为请求被客户端拒绝,不会造成 AGC 标记泄漏,也不影响当前 release/dev 默认地址;应作为 #226 的独立客户端修复跟踪,不能在 #225 中偷偷回改客户端设计。
-
-## 6. 可直接粘贴到 Issue #225 的交付评论
-
-> `#225` 主站侧已完成并收口:统一识别 `X-Genarrative-Client: agc`,本期新增的 AGC-only 成功 route 只有在带有效 marker 时才写入 `tracking_event.metadata_json.client = "agc"`;既有 route tracking 和手工资产事件保持原有全客户端统计语义。账号态按已验证 access token 的真实用户归属,External API Key 态按 `ExternalApiPrincipal.owner_user_id()` 归属,不伪造 `user_id`,不记录 token/API Key/Cookie/签名 URL。当前 AGC 实际使用的账号态 `/api/auth/*`、`/api/profile/*`、`/api/assets/*`、`/api/editor/*`、`/api/runtime/*` 与 External v1 业务路径均有显式 route spec;动态 ID 继续归一化,External v1 保留实际外部 path。OSS/签名下载、Provider、受控搜索、loopback、更新下载、公开 discovery/Skill/MCP 不进入普通 AGC 业务统计。记录最终复用既有 outbox、SpacetimeDB procedure、daily stat、event-id 幂等和后台 `GET /admin/api/tracking/events` 读取,不新增 schema、页面或独立事件体系。阶段 1~5 的定向实现和回归已提交,阶段 6 最终门禁通过:api-server tracking/资产/后台/outbox 43 个、鉴权回归 1 个、module-runtime 2 个、spacetime-client 1 个、spacetime-module 1 个定向测试全部通过,Rust 编译/格式、编码和 diff 检查通过;完整工作区测试按 CI 执行。`#226` 客户端标记、origin-safe redirect 和第三方边界契约无需回改。`
-
-## 7. 后续发布前事项
-
-本 Issue 代码和本地确定性验证已完成;发布或联调时由主站环境补做一次真实链路 smoke:使用已部署的 AGC 客户端请求主站业务接口,确认 Header 被接收、`tracking_event.metadata_json.client` 可由后台原始查询读回。该 smoke 是环境验证,不改变本 PR 的设计或代码范围。
diff --git a/local-docs/【阶段验收】Issue226阶段0现状基线与契约冻结-2026-09-01.md b/local-docs/【阶段验收】Issue226阶段0现状基线与契约冻结-2026-09-01.md
deleted file mode 100644
index 533a5f401..000000000
--- a/local-docs/【阶段验收】Issue226阶段0现状基线与契约冻结-2026-09-01.md
+++ /dev/null
@@ -1,184 +0,0 @@
-# Issue #226 阶段 0:现状基线与契约冻结验收记录
-
-更新时间:2026-09-01
-关联 Issue:`#226 添加客户端特殊标识`;交接 Issue:`#225 添加客户端埋点统计`
-执行结论:阶段 0 本地基线与契约冻结通过;未修改生产代码、主站、OpenAPI 或数据库。
-远程 Issue 评论未直接提交,本文第 7 节提供可直接粘贴的评论草案。
-
-## 1. 本阶段边界
-
-阶段 0 只完成四件事:
-
-1. 记录当前工作树和源码基线。
-2. 核对 TS 统一请求出口,以及 Rust 主站/第三方 Client 创建边界。
-3. 冻结客户端 Header、主站 origin 和正负向范围。
-4. 冻结交给 `#225` 的 tracking metadata 约定。
-
-本阶段明确不做:
-
-- 不改 `apps/ai-game-creator-shell` 生产实现。
-- 不改 `server-rs`、OpenAPI、SpacetimeDB schema、migration、bindings 或后台。
-- 不把现有 body 内 `generationInputs.source` 等字段升级成统一请求标记。
-- 不把所有 `reqwest::Client` 粗暴替换成主站 Client。
-
-## 2. 当前仓库基线
-
-| 项目 | 结果 |
-|---|---|
-| 工作目录 | `C:\projects\narrative\Genarrative` |
-| 当前分支 | `feat/agc_call_header` |
-| 当前 HEAD | `b14e42d9b` — `AGC支持安装扩展skill、MCP (#233)` |
-| 阶段开始前工作树 | `git status --short` 为空 |
-| 编码检查 | `npm run check:encoding` 通过,检查 5647 个文件 |
-| Diff 空白检查 | `git diff --check` 通过 |
-| 阶段 0 代码改动 | 无 |
-
-说明:本记录和相关方案/清单属于预期本地文档变更。当前仓库通过 `.git/info/exclude` 忽略整个 `local-docs/`,因此这些材料不会出现在 `git status` 或 `git diff` 中;生产代码工作树仍保持干净。
-
-## 3. 源码边界核对
-
-### 3.1 TS 统一出口已确认
-
-AGC Web/TS 侧的统一网络入口是:
-
-- `apps/ai-game-creator-shell/src/services/clientHttp.ts:163` 的 `fetchClientHttp`。
-- `clientAuth.ts` 通过 `requestAuthJson` 调用该入口。
-- `clientApi.ts` 通过 `requestClientApi` / `requestClientApiBytes` 调用该入口。
-
-因此阶段 1 只需要在 `fetchClientHttp` 统一注入 Header,即可覆盖认证、素材、账户和钱包等 TS 请求;更新下载 `clientHttp` 之外的独立路径仍需保持排除。
-
-### 3.2 Rust 不是统一 Client
-
-Rust 侧已确认存在多个独立 `reqwest::Client::new()` / `Client::builder()` 创建点,不能依赖 TS 入口覆盖。主站相关的生产创建点主要分布在:
-
-- `assets.rs:377`、`:712`:开发者 Key、项目同步/恢复。
-- `commands.rs:3283`、`:3833`:账户素材库和素材下载前换签。
-- `agent/generation/canvas_generation.rs:2404`、`:2408`:External Editor 生成轮询/提交。
-- `project/asset_canvas/generation.rs:3729`、`:3733`:画布生成轮询/提交。
-- `project/resource_editor.rs:3101`:资源编辑生成/轮询公共入口。
-- `agent/direct_runtime.rs:2487`:Direct Runtime 只读恢复。
-- `agent/direct_tool_bridge.rs:1813`:受控去背景调用前的主站上下文准备。
-
-公共路由与凭据映射抽象已确认存在于:
-
-- `project/external_editor_bindings.rs:40` 的 `ExternalEditorBindingAccess`。
-- `ExternalEditorBindingAccess::api_route(...)` 负责账号态 `/api/editor`、`/api/assets`、`/api/runtime` 与 API Key 态 `/api/external/v1` 的路径映射。
-
-### 3.3 明确的第三方/非主站边界
-
-以下调用保留原有 Client,不进入主站标记范围:
-
-- OSS/对象存储 multipart 上传。
-- `read-url` 返回的签名 URL 二进制下载。
-- LLM Provider `/responses`:`agent/codex_provider_proxy.rs:207`。
-- AGC 受控网页搜索:`agent/direct_tool_bridge.rs:2191`,带有独立 `no_proxy` 语义。
-- loopback 工具桥、本地 IPC、试玩页面请求。
-- 更新清单和更新包下载:`main.rs:120`。
-
-完整的实际调用表、潜在 External v1 接口和排除项以
-[【扫描清单】AGC客户端主站调用与可标记点-2026-09-01.md](C:/projects/narrative/Genarrative/local-docs/【扫描清单】AGC客户端主站调用与可标记点-2026-09-01.md)
-为准。
-
-## 4. 冻结的客户端标记契约
-
-### 4.1 Header
-
-```http
-X-Genarrative-Client: agc
-```
-
-固定规则:
-
-- Header 名按 HTTP 规则大小写不敏感;客户端发送时固定使用 `X-Genarrative-Client`。
-- 值固定为小写 `agc`。
-- 统一出口/主站 Client 应覆盖调用方传入的同名 Header,避免业务层伪造其他值。
-- 不携带 token、API Key、用户 ID、项目 ID 或版本号。
-- 只用于来源审计和统计,不参与鉴权、权限、计费或账号归属判断。
-
-### 4.2 Origin 与发送范围
-
-主站判断依据固定为当前选定并已规范化的 `serverBaseUrl` / `apiBaseUrl`,比较完整 origin(scheme + host + port),而不是只看路径或字符串前缀。
-
-应带标记的请求包括:
-
-- `/api/auth/*`、`/api/profile/*`、`/api/assets/*`、`/api/editor/*`、`/api/runtime/*`。
-- API Key 态 `/api/external/v1/*`。
-- 项目、画布、素材库、上传凭证、对象确认、资源登记、图片/图集/去背景/角色动画/视频/音频生成和异步轮询。
-- `/api/profile/api-keys`。
-
-不得带标记的请求包括:OSS、签名下载、Provider、受控搜索、loopback、更新下载及任意外部网页请求。
-
-### 4.3 保留的请求语义
-
-后续实现必须保留每个调用点已有的:
-
-- `timeout`、`connect_timeout`、redirect policy 和 `no_proxy`。
-- Authorization/Bearer、External API Key、Idempotency-Key 和既有业务 Header。
-- Content-Type、请求体、响应状态处理、重试和异步轮询语义。
-
-## 5. 冻结给 #225 的交接契约
-
-主站接收同名 Header:
-
-```http
-X-Genarrative-Client: agc
-```
-
-主站规则:
-
-- 精确值 `agc` 识别为 AGC。
-- Header 缺失、空值或未知值按“未标记”处理,不拒绝请求,不改变业务行为。
-- 不从 `generationInputs.source` 推导统一客户端标记。
-- 认证主体仍以真实账号态或 `ExternalApiPrincipal` 为准,不记录 token/API Key 明文。
-
-第一阶段建议复用现有 `tracking_event.metadata_json`,固定 JSON key/value:
-
-```json
-{
- "route": "/api/editor/images/generations",
- "method": "POST",
- "status": 202,
- "operation": "generateExternalEditorImage",
- "client": "agc"
-}
-```
-
-交接要求:
-
-- 记录主站实际收到的 method/path,不只记录客户端账本中的 External v1 endpoint。
-- `/api/external/v1/*` 也要纳入 tracking 覆盖,不能只依赖内部 `/api/editor` 路由规格。
-- 缺失标记时不写 `client` 空字符串;未知值按未标记处理。
-- 成功、失败、重试和轮询请求沿用同一 Header;是否记录失败请求由 `#225` 的埋点目标决定,不要求 `#226` 回改标记设计。
-
-## 6. 阶段 0 验收结果
-
-| 验收项 | 结果 | 证据 |
-|---|---|---|
-| 当前工作树基线已确认 | 通过 | 本文第 2 节;阶段开始前 `git status --short` 为空 |
-| TS 统一出口已定位 | 通过 | `clientHttp.ts:163`、`clientAuth.ts`、`clientApi.ts` |
-| Rust 主站/第三方 Client 边界已定位 | 通过 | 本文第 3 节;完整清单见扫描文档 |
-| 正向范围无未决歧义 | 通过 | 本文第 4.2 节 |
-| 排除范围无未决歧义 | 通过 | 本文第 3.3、4.2 节 |
-| Header、metadata、未知值行为已冻结 | 通过 | 本文第 4、5 节;实施方案第 3、8 节 |
-| 未修改生产代码/主站/契约/数据库 | 通过 | `git diff --check`;本阶段仅新增/更新被本地忽略的 `local-docs` |
-
-阶段 0 可退出,允许进入阶段 1。阶段 1 的入口条件是直接按本文契约实现 TS `fetchClientHttp`,无需等待 `#225`。
-
-## 7. Issue #226 实现范围评论草案
-
-> 本次 #226 只做 AGC 客户端侧请求标记,不修改 #225 的主站 tracking、数据库或后台实现。
->
-> 冻结 Header:`X-Genarrative-Client: agc`。TS 在 `fetchClientHttp` 统一注入;Rust 增加主站专用 Client builder factory,通过 `default_headers` 注入,并只替换主站请求的 Client 创建点。账号态 `/api/editor`、`/api/assets`、`/api/runtime` 与 API Key 态 `/api/external/v1` 都发送同一标记。
->
-> 保留各调用点现有 timeout、connect timeout、redirect、no_proxy、Authorization/Bearer、API Key、Idempotency-Key、请求体和响应语义。OSS 上传、签名 URL 下载、LLM Provider、受控搜索、loopback、更新下载和外部网页请求不得带标记。
->
-> #225 接收约定:精确值 `agc` 识别为 AGC;缺失/空值/未知值按未标记处理且不拒绝请求。第一阶段复用 `tracking_event.metadata_json`,写入 `client: "agc"`,并按主站实际 method/path 记录;不要求 #226 为 #225 回改设计。
-
-正式提交评论前,应将本文草案与 #226 当前讨论串核对一次;本阶段未直接执行远程 Issue 写操作。
-
-## 8. 阶段 1 入口与风险提示
-
-- 阶段 1 只改 TS `fetchClientHttp` 及其定向测试,先验证 Header 合并、同名 Header 覆盖和两条 transport 行为。
-- 阶段 2/3 再处理 Rust factory 与生产创建点;测试 fixture 中的裸 Client 不应被机械替换。
-- `default_headers` 只放稳定来源标记;Authorization、Idempotency-Key 和每请求动态 Header 继续保留在调用点。
-- 后续定向测试必须同时覆盖账号态和 API Key 态,以及主站正向和第三方负向请求。
diff --git a/local-docs/【阶段验收】Issue226阶段6交接与最终门禁-2026-09-02.md b/local-docs/【阶段验收】Issue226阶段6交接与最终门禁-2026-09-02.md
deleted file mode 100644
index 1f879b1b8..000000000
--- a/local-docs/【阶段验收】Issue226阶段6交接与最终门禁-2026-09-02.md
+++ /dev/null
@@ -1,119 +0,0 @@
-# Issue #226 阶段 6:#225 交接与最终门禁验收记录
-
-更新时间:`2026-09-02`
-实施范围:`#226 添加客户端特殊标识`
-交接范围:`#225 添加客户端埋点统计`
-执行结论:阶段 6 通过;#226 客户端实现、跨 origin 重定向安全复审、边界回归、交接材料和最终门禁已收口。未修改 #225 主站代码、数据库、OpenAPI 或后台实现。
-
-## 1. 阶段边界
-
-本阶段只完成:
-
-1. 复核并固定交给 `#225` 的 Header、tracking metadata、认证主体和路径边界。
-2. 汇总阶段 1~5 的正向、负向和语义回归证据。
-3. 执行最终定向测试、编码/格式/空白检查和工作树检查。
-4. 更新实施方案与分阶段计划的完成状态。
-
-本阶段明确不做:
-
-- 不修改 `server-rs`、主站 tracking middleware、route tracking 或后台。
-- 不修改 SpacetimeDB `tracking_event` schema、migration、bindings 或索引。
-- 不修改 External v1 OpenAPI、DTO 或请求响应语义。
-- 不执行真实发布环境线上写入或埋点验证。
-
-## 2. 当前仓库状态
-
-阶段 6 开始时:
-
-| 项目 | 结果 |
-|---|---|
-| 分支 | `feat/agc_call_header` |
-| HEAD | `8059bbcb5`(已合并最新 `origin/master`) |
-| 工作树 | 干净 |
-| `origin/master` | `4a2f5be6c`,同步 AGC 更新下载域名门禁 |
-
-阶段 0~5 的提交保持不变,本阶段只补充交接/验收文档。
-
-## 3. 给 #225 的固定交接契约
-
-### 3.1 客户端请求标记
-
-```http
-X-Genarrative-Client: agc
-```
-
-- Header 名大小写不敏感;值精确为小写 `agc` 时识别为 AGC。
-- 缺失、空值或未知值按未标记处理,不拒绝请求,也不改变业务行为。
-- Header 只用于来源审计和统计,不参与鉴权、权限、计费或账号归属。
-- 不记录 access token、API Key 明文、签名 URL、项目绝对路径、用户隐私或客户端版本号。
-
-### 3.2 tracking metadata
-
-第一阶段复用现有 tracking `metadata_json`,固定 JSON key/value:
-
-```json
-{
- "route": "/api/editor/images/generations",
- "method": "POST",
- "status": 202,
- "operation": "generateExternalEditorImage",
- "client": "agc"
-}
-```
-
-约定:
-
-- `client` key 固定;AGC 值固定为 `agc`。
-- Header 缺失时不写 `client` 空字符串。
-- 记录主站实际收到的 method/path,不只记录客户端账本中的 External v1 endpoint。
-- `/api/external/v1/*` 不能因为缺少完整 route spec 而漏记。
-
-### 3.3 认证主体
-
-- 登录账号态:沿用主站现有 access token 解析出的用户维度。
-- External API Key 态:使用 `ExternalApiPrincipal.owner_user_id`,必要时保留 `key_id` 维度。
-- Header 与认证主体独立处理;不能用 Header 代替认证,也不能从 `generationInputs.source` 推导客户端标记。
-
-### 3.4 路由和边界
-
-应识别的主站请求:
-
-- 账号态 `/api/auth/*`、`/api/profile/*`、`/api/assets/*`、`/api/editor/*`、`/api/runtime/*`。
-- External API Key 态 `/api/external/v1/*`。
-- 生成提交、异步轮询、项目/素材/资源登记和 `/api/assets/read-url` 换签。
-
-明确不应识别为 AGC 主站业务请求:
-
-- OSS multipart 上传。
-- 签名 URL/OSS 媒体下载。
-- LLM/Codex Provider。
-- AGC 受控搜索。
-- loopback 工具桥。
-- 更新清单、更新包下载和任意外部网页请求。
-
-## 4. 最终门禁结果
-
-| 验收项 | 命令/证据 | 结果 |
-|---|---|---|
-| TS 统一出口正向测试 | `npm exec vitest run apps/ai-game-creator-shell/tests/clientHttp.test.ts` | 通过,14 tests passed |
-| AGC TS 类型和配置检查 | `npm run ai-game-creator-shell:typecheck` | 通过;skill-pack/config 检查通过 |
-| Rust 主站 Client factory、请求终结器与 origin-safe redirect policy | `cargo test --locked --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml http_client -- --nocapture` | 通过,8 tests passed;同源跟随、跨 origin 阻断、链式重定向、显式 `Policy::none()` 和请求级同名 Header 覆盖均覆盖 |
-| 第三方请求负向矩阵 | `cargo test --locked --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml omits_agc_marker -- --nocapture` | 通过,4 tests passed |
-| loopback 认证/请求边界 | `cargo test --locked --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml loopback_proxy_strips_false_codex_limit_headers_and_requires_bearer -- --nocapture` | 通过,1 test passed |
-| 账号态主站请求捕获 | `cargo test --locked --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml background_agent_runtime_can_generate_platform_art_asset -- --nocapture` | 通过,1 test passed |
-| External Key 态和自定义 origin | `cargo test --locked --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml sync_canvas_project_assets_with_developer_key_uses_external_route_and_marker -- --nocapture` | 通过,1 test passed |
-| `read-url` 与签名下载边界 | `cargo test --locked --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml sync_canvas_project_assets_downloads_external_resources -- --nocapture` | 通过,1 test passed |
-| 结果未知/幂等语义 | `cargo test --locked --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml generation_submit_response_loss_is_not_retried -- --nocapture` | 通过,1 test passed |
-| Rust 格式 | `cargo fmt --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml -- --check` | 通过 |
-| 中文编码 | `npm run check:encoding` | 通过,5653 个文件 |
-| Diff 空白 | `git diff --check` | 通过 |
-
-Rust 测试输出包含仓库既有的 unused/dead-code warning;本任务相关测试均无 error 或 failure。
-
-## 5. 发布环境限制与后续交接
-
-本阶段没有执行真实发布环境线上 smoke。账号态和 External Key 态的路径、Header、认证/幂等语义来自本地 mock/custom `apiBaseUrl` fixture;OSS/签名 URL/Provider/搜索/loopback/更新下载边界来自本地请求捕获;跨 origin 重定向来自双 listener 和链式重定向 fixture。发布前或 `#225` 联调时,应由主站侧补做真实环境 Header 接收、tracking metadata 写入和后台查询验证,不要求客户端回改本次设计。
-
-## 6. 可直接粘贴到 #225 的评论
-
-> `#226` 客户端侧已完成并冻结交接契约:AGC 主站业务请求统一发送 `X-Genarrative-Client: agc`。账号态 `/api/auth/*`、`/api/profile/*`、`/api/assets/*`、`/api/editor/*`、`/api/runtime/*` 与 External API Key 态 `/api/external/v1/*` 均覆盖;OSS/签名下载、Provider、受控搜索、loopback、更新下载和外部网页请求不带该标记。主站可按实际 method/path 读取 Header,并在现有 tracking `metadata_json` 中写入 `client: "agc"`;Header 缺失/空值/未知值按未标记处理且不拒绝请求。登录态按真实用户维度记录,External Key 态按 `owner_user_id`(必要时 `key_id`)记录,不记录 token/API Key 明文或签名 URL。客户端正向、负向、账号态、External Key 态和幂等回归均已通过,`#225` 不需要让 `#226` 回改设计。`