diff --git a/docs/agent-specs/2026-07-07-内测-WU1-注册登录用户名密码-设计.md b/docs/agent-specs/2026-07-07-内测-WU1-注册登录用户名密码-设计.md index c2217413..a7eb0174 100644 --- a/docs/agent-specs/2026-07-07-内测-WU1-注册登录用户名密码-设计.md +++ b/docs/agent-specs/2026-07-07-内测-WU1-注册登录用户名密码-设计.md @@ -1,7 +1,7 @@ --- date: 2026-07-07 topic: 内测-注册登录-用户名密码 -status: 草案 +status: 已实现（契约 987d489b／服务 d52696c5／端点+单测 28bd5339／前端 da05ecc0，随 Complete A 合入 dev/2.0.0；真机 e2e 复验待阶段2） sot-impact: 修订 topic 鉴权与权限（新增用户名+密码鉴权路径，与短信/邀请码并存）；修订 topic 数据模型（game_player 增 username/password 列、mobile 放宽可空、加 uk_username）。收口时把两条结论折进 后端/鉴权与权限.md 与 后端/数据模型.md，本档降为留痕。 上级: docs/mvp/MVP作战清单.md 关联: diff --git a/docs/agent-specs/2026-07-07-内测-WU2-newapi额度接入-设计.md b/docs/agent-specs/2026-07-07-内测-WU2-newapi额度接入-设计.md index 2aeec6c8..f680ae22 100644 --- a/docs/agent-specs/2026-07-07-内测-WU2-newapi额度接入-设计.md +++ b/docs/agent-specs/2026-07-07-内测-WU2-newapi额度接入-设计.md @@ -1,7 +1,7 @@ --- date: 2026-07-07 topic: newapi-per-user-quota -status: 草案 +status: 已实现（离线预置池+注册 claim；池表 c13595fb／claim 消费者 4cf0e14e／job userToken a069afb6／quota_exhausted 跨契约 fe6079ba／worker 取 token e8f7dc83，随 Complete A 合入 dev/2.0.0。落地方案=预置池，非早期设想的运行时管理 client 开户——后者 S0 实测撞 admin 不能替他人建 token 硬边界，创始人已否决，见 tech-decisions.md:254） sot-impact: 修订「生成引擎运行时」(§6.1 job 契约新增 userToken 位、§6.5 新增 quota_exhausted 失败因)；修订「数据模型」(新增额度池表 newapi_quota_pool——离线预建 FREE 条目 + 注册 claim 绑定)；关联「鉴权与权限」(不改注册路，仅消费 WU1 afterCommit 发出的「注册成功」事件从池 claim 一个条目绑定，运行时不调 new-api)；修订「契约#6 dify-workflow-io.json」与「aigc.yaml FailureReason」(跨契约共享枚举同批新增 quota_exhausted，须与 WU3 协调)。刻意不改「变现端到端」——本设计对接 new-api 网关额度，不在 game-cloud 自建 credits 钱包。 上级: docs/mvp/MVP作战清单.md 依赖: docs/agent-specs/2026-07-07-内测-WU1-注册登录用户名密码-设计.md（WU1 §3.6 是唯一注册接缝：afterCommit 发「注册成功」领域事件/RocketMQ 消息，载荷 userId/registerChannel/anonId。本设计是该事件的消费者，不在注册事务内挂点；WU1 迁移取 V31，本设计顺延取 V32） diff --git a/docs/agent-specs/2026-07-07-内测-WU3-dify游戏开发节点-设计.md b/docs/agent-specs/2026-07-07-内测-WU3-dify游戏开发节点-设计.md index 4895a029..368823e1 100644 --- a/docs/agent-specs/2026-07-07-内测-WU3-dify游戏开发节点-设计.md +++ b/docs/agent-specs/2026-07-07-内测-WU3-dify游戏开发节点-设计.md @@ -1,8 +1,8 @@ --- date: 2026-07-07 topic: 内测-dify游戏开发节点-形态A -status: 草案 -sot-impact: 无 canonical 修订——本设计不改 §6.1 job/result-out 契约、不改生产生成 runtime、不改契约#6(dify-workflow-io.json,反而澄清其历史身份)。仅两处收口回写:① 实施落地后回写《内网凭据与端点》(canonical)补 dify(nginx :18080/:18443、plugin_daemon :15003)与便宜档 cheap-worker(:9501)、cheap Service(:8300)的 dev 端点及 dify 专用 new-api token;② 若该内测通道日后转常设入口,再回写《生成引擎运行时》(agentic运行时架构图说,canonical)补一条「dify workflow 旁路 ingress」注记。本档阶段只申报影响面,不动 canonical。 +status: 已实现（形态A 于 2026-07-08 在 game 专属 dify 实例 LIVE 跑通，随 Complete A 合入 dev/2.0.0） +sot-impact: 无 canonical 修订——本设计不改 §6.1 job/result-out 契约、不改生产生成 runtime、不改契约#6(dify-workflow-io.json,反而澄清其历史身份)。仅两处收口回写:① 实施落地后回写《内网凭据与端点》(canonical)补 dify(nginx :28080/:28443、plugin_daemon :25003)与便宜档 cheap-worker(:9501)、cheap Service(:8300)的 dev 端点及 dify 专用 new-api token;② 若该内测通道日后转常设入口,再回写《生成引擎运行时》(agentic运行时架构图说,canonical)补一条「dify workflow 旁路 ingress」注记。本档阶段只申报影响面,不动 canonical。 上级: docs/mvp/MVP作战清单.md 关联: | cheap-worker/worker_service.py(:34 DEFAULT_PORT=9501、:192-204 try_enqueue 按 job_id/traceId 在 _seen 去重、:514-547 /generate 入口、:82-105 HMAC 签名、:229-256 落盘与回调 status=succeeded/failed、:570 main 硬编码 host=0.0.0.0 无 --host) · @@ -20,14 +20,16 @@ sot-impact: 无 canonical 修订——本设计不改 §6.1 job/result-out 契 # 内测 · dify 游戏开发节点直连 agentscope 生成线 —— 形态 A 落地设计 +> **2026-07-08 校正(实例归属)**：本档 07-07 初稿假设 dify 落在共享的 muse 实例（`:18080`）。创始人随后明确 muse 与 game 两项目 **workspace 必须分离**，据此已在 mini-infra 起一套 **game 专属 dify 实例**（`100.64.0.8:28080`，compose 部署位 `/root/dify-game/docker`、`COMPOSE_PROJECT_NAME=game-dify`），形态 A 一律落它、muse 的共享实例一字不碰、只读参照。凭据与操作留痕见《内网凭据与端点》§game 专属 dify 实例（已落 `b9d73ae3`）。下文端口已就地改为 game 专属实例（`:28080`/`:28443`/plugin `:25003`）。形态 A 已于 2026-07-08 在该实例 LIVE 跑通（游戏开发节点返 202 + worker 受理、`userToken=`→全局 key 回落），随 Complete A 实现并合入 dev/2.0.0。 + ## 0 一图看懂 -内测要交付的能力只有一句话：在 mini-infra 上那套已经部署好的 dify 里搭一条最小 workflow，其中一个「游戏开发节点」（一个 HTTP Request 节点）把用户的一句话创意组成后端生成线早已定义的 §6.1 job，直接 POST 给便宜档的 cheap-worker `:9501/generate`，由现成的 agentscope 生成线跑出一款小游戏。后端近零改动——不新增接口、不改生成主线、不碰契约。 +内测要交付的能力只有一句话：在 mini-infra 上 game 专属的 dify 实例（`:28080`）里搭一条最小 workflow，其中一个「游戏开发节点」（一个 HTTP Request 节点）把用户的一句话创意组成后端生成线早已定义的 §6.1 job，直接 POST 给便宜档的 cheap-worker `:9501/generate`，由现成的 agentscope 生成线跑出一款小游戏。后端近零改动——不新增接口、不改生成主线、不碰契约。 ```mermaid flowchart LR subgraph MI["mini-infra 100.64.0.8"] - D["dify 1.15.0
nginx :18080/:18443"] + D["dify 1.15.0
nginx :28080/:28443"] DN["游戏开发节点
(HTTP Request)"] NA["new-api :3000
(LLM 网关)"] D --> DN @@ -49,7 +51,7 @@ flowchart LR **边界**：内测形态 A 是一条**独立生成通道**——产物落在 worker 的 `game_dir` 与 dify 自己手里，**不进 game-cloud 的发布/feed**，**不扣任何用户的 new-api 个人额度**。要让 dify 产物进 feed 属于形态 B（需要一个能建 task 记录的服务间免登录触发/回调面），工作量与攻击面都上一个台阶，内测不做。 -**怎么算成功**：从 dify（`:18080`）触发一次 workflow → cheap-worker `:9501` 收到 job 并回 202 → agentscope 真跑一局 → worker 收口日志报 `status=succeeded`、`game_dir` 落定产物。注意成功判据是那行收口日志，**不是**「`src/` 非空」——scaffold 会在真生成前先把 `_template/src`（7 个文件）克隆进 `game_dir`，一次 scaffold 成功但生成失败的 run 同样「src/ 非空」，单看它区分不出成功与失败（详见 §5）。这一条端到端链路走通，即「内测前支持 dify workflow」成立。 +**怎么算成功**：从 dify（`:28080`）触发一次 workflow → cheap-worker `:9501` 收到 job 并回 202 → agentscope 真跑一局 → worker 收口日志报 `status=succeeded`、`game_dir` 落定产物。注意成功判据是那行收口日志，**不是**「`src/` 非空」——scaffold 会在真生成前先把 `_template/src`（7 个文件）克隆进 `game_dir`，一次 scaffold 成功但生成失败的 run 同样「src/ 非空」，单看它区分不出成功与失败（详见 §5）。这一条端到端链路走通，即「内测前支持 dify workflow」成立。 > §0 的门面 SVG 概览图随收口由图层子代理据本节文字与图1 派生补上；当前草案以 Mermaid 为事实源。 @@ -209,7 +211,7 @@ worker 往后的生成实际调的是 new-api（`100.64.0.8:3000`）来跑 LLM **第一步 · 生成栈就位并可被内网直连**。在 dev 生成机（如 mini-desktop）拉起 **dify 专属的** cheap-worker（`:9501`）与 cheap Service（`:8300`，其进程 `NEWAPI_KEY`=dify 专用 token，与真实 create 路隔离，见 §3.4），并确认该机无公网可达面（`:9501` 硬编码绑 `0.0.0.0`、无 `--host`，只能靠主机 Tailscale-only/NAT/防火墙收口，见 §3.5）。交付物 = 两个进程在跑、`:9501/generate` 与 `:8300/chat` 仅 Tailscale 内网可达。验证 = 从 dify 所在的 mini-infra 上 `curl --noproxy` 打一个最小 job 到 `:9501` 拿到 202；并实测非 Tailscale 来源打 `:9501` 不可达。依赖 = 生成栈现货、new-api 专用 token。风险 = 系统代理劫持内网 IP（用 `NO_PROXY`/`--noproxy` 绕过）。 -**第二步 · dify 建最小 workflow + 游戏开发节点**。在 dify（`:18080`）里建一条 workflow：一个开始节点收 `brief` 输入 → 一个 HTTP Request「游戏开发节点」按 §3.2 映射组 §6.1 job、POST 到 `:9501/generate`（超时握手级、`traceId` 带 `dify-` 前缀、`callback` 按 §3.3 决策默认省略）。交付物 = 一条可运行的 dify workflow，其定义 DSL 导出留痕（建议存 `spikes/` 或本档 assets，供可复现）。验证 = 在 dify 里手动跑一次，节点拿到 202。依赖 = 第一步就位。风险 = dify sandbox 出网未绕代理（同第一步）。 +**第二步 · dify 建最小 workflow + 游戏开发节点**。在 dify（`:28080`）里建一条 workflow：一个开始节点收 `brief` 输入 → 一个 HTTP Request「游戏开发节点」按 §3.2 映射组 §6.1 job、POST 到 `:9501/generate`（超时握手级、`traceId` 带 `dify-` 前缀、`callback` 按 §3.3 决策默认省略）。交付物 = 一条可运行的 dify workflow，其定义 DSL 导出留痕（建议存 `spikes/` 或本档 assets，供可复现）。验证 = 在 dify 里手动跑一次，节点拿到 202。依赖 = 第一步就位。风险 = dify sandbox 出网未绕代理（同第一步）。 **第三步 · 端到端取证 + 边界与凭据回写**。跑通 dify → worker → agentscope → game_dir 全链，取证（§5）。收口把 dify/worker/Service 端点与 dify 专用 token 回写《内网凭据与端点》，把 dify workflow DSL 留痕。交付物 = 一份真机取证记录 + 凭据回写。验证 = §5 验收门全绿。依赖 = 前两步。风险 = 无回调时忘了看 game_dir（落点提醒）。 @@ -217,7 +219,7 @@ worker 往后的生成实际调的是 new-api（`100.64.0.8:3000`）来跑 LLM 内测最小可行判据只有一条链：**从 dify workflow 触发一次 → cheap-worker 跑 agentscope → 拿到生成产物**。它可真机取证，取证点逐条可机器验或肉眼可查： -1. **触发**：在 dify（`http://100.64.0.8:18080`）运行 workflow，输入一句 brief。dify 侧显示游戏开发节点返回 202、body 含 `{"accepted":true,"job_id":"dify-...","traceId":"dify-...","queued":N}`。**注意 202 只证明「已受理」，不证明「生成成功」**——它甚至可能是同 `job_id` 重投被去重返的 202（此时 `queued` 不增、无新生成，§3.7）；真成功证据在第 4 步。所以每次要真生成必须换新 `job_id`/`traceId`。 +1. **触发**：在 dify（`http://100.64.0.8:28080`）运行 workflow，输入一句 brief。dify 侧显示游戏开发节点返回 202、body 含 `{"accepted":true,"job_id":"dify-...","traceId":"dify-...","queued":N}`。**注意 202 只证明「已受理」，不证明「生成成功」**——它甚至可能是同 `job_id` 重投被去重返的 202（此时 `queued` 不增、无新生成，§3.7）；真成功证据在第 4 步。所以每次要真生成必须换新 `job_id`/`traceId`。 2. **收单**：cheap-worker 日志出现 `收到 job trace_id=dify-..., templateId=generic, gameId=dify-... → 受理(202)`（`worker_service.py:544` 那行）。这是「dify 的 job 确实到了 worker」的直接证据。 3. **真跑 agentscope**：worker 日志显示后台线程驱动 cheap Service 生成（`:8300` 各 POST），生成过程有 LLM 调用痕迹；cheap Service 侧日志对应产出。 4. **生成成功（不是「产物可见」，别踩假绿）**：成功判据用 worker 的真状态信号，**不看 `src/` 是否非空**——因为 scaffold 会在真生成前先把 `_template/src`（实测 7 个文件：`assets/core/game-logic/game/host-config/main/render.js`）克隆进 `game_dir`，一次 scaffold 成功但生成失败的 run 同样「`src/` 非空、多文件」，单看它区分不出成败。可用的成功证据有三，任一即可：①grep worker 收口日志到 `status=succeeded`（`process_job` 在 `worker_service.py:254/256` 那两行本就打 `status={succeeded|failed}`）；②核 `_wg1-gen//evidence/verdict.json` 九门 pass；③核 `game_dir/src/game-logic.js` 已偏离 `_template` 基线（agent 真改过游戏本体）。产物落点目录是 **`game-runtime/games/amgen-/src/`**（`cheap_run.game_dir` 返 `games/amgen-/`，dify 令 `gameId=dify-` 时实际目录是 `amgen-dify-/`，`gameId` 已含 `dify-` 前缀，别按字面去找 `dify-`）。a-dify 下，额外在 dify 捕获入口看到 result-out 被接住、其 `status` 可读。 diff --git a/docs/plans/2026-07-08-内测上线闭环A段-plan.md b/docs/plans/2026-07-08-内测上线闭环A段-plan.md deleted file mode 100644 index 41d027d7..00000000 --- a/docs/plans/2026-07-08-内测上线闭环A段-plan.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: "feat: 内测上线闭环 A 段 — 注册赠额→生成→试玩→发布→飞轮的种子用户全链路" -date: 2026-07-08 -status: 执行中(创始人 2026-07-07 拍定四项决策 · 转入阶段0 三设计门) -topic: 内测上线闭环A段 -上级: docs/mvp/可行性方案16周-波次映射.md -关联: - - ~/.claude/plans/breezy-forging-rocket.md(本 plan 的仓外调研前身,六项并行读码坐实) - - docs/内网凭据与端点.md §game 专属 dify 实例(WU3 形态A 落点) - - contracts/dify-workflow-io.json(dify 节点 I/O 形状参考) ---- - -# 内测上线闭环 A 段 - -## 1 意图与目标 - -创始人把「7 月中旬内测」这条硬目标，具体化为一条种子用户能端到端走完的旅程：用户名加密码注册（不发短信、网关按 IP 限流）→ 得到一份生成额度 → 造一款游戏 → 试玩 → 发布进 feed → 玩法遥测回流、驱动生成持续变好。内测不接广告、不接渠道，核心只有一件事——把「生成→反馈→再生成」这台数据飞轮先转起来。 - -这条闭环里，生成核心、试玩预览、发布 feed、飞轮采集半环都已在代码里就绪、只等真机核实；真正缺的是三段开发：让用户能用账号密码进来、给每个用户一份可计量的额度、以及一条 dify 演示触发路。本 plan 把这三段各拆成一份设计门先锁契约，再并行实现，最后串行跑通一次真机 e2e。 - -## 2 现状全景（2026-07-07 六项并行读码坐实） - -### 已就绪，只等 staging 核实（非缺口） - -生成核心闭环已修复并 live：门面链从 `AppAigcTaskController.submitGenerate` 经 RocketMQ 生产者、消费者、`AigcGenerateExecutor` 生成流水线，到 `WorkerDispatchClient` POST 便宜档 worker `:9501/generate`，再由 HMAC 回调 `/dify/callback-internal` 三表同事务落包。agentscope 硬支持成立：便宜档 `:9501` 薄 adapter → `:8300` 真 AgentScope Service（agent loop＋工具面＋续修熔断）live 通。试玩预览（`AppRuntimeController` 匿名会话、status=0 预览态可玩）、发布 feed（`PublishOrchestrationServiceImpl.publish` 双写 zone0＋专区、审核 APPROVE 后 α 自动发布）、飞轮采集半环（play 遥测→quality_score→`FeedApi.upsertRank` 回灌，`EventIngestServiceImpl` live）均已实现。飞轮后半环（回流校准）是放量后的人工月度动作，不在内测硬闭环内。 - -### 真开发缺口（内测硬闭环） - -**注册登录只有短信码路径**：系统当前没有用户名加密码的概念，产品端玩家走自研 passport 模块、主键是 mobile、登录靠短信验证码（旁路是邀请码）。真达标要加密码列、mobile 改可空、开新端点、前端加登录 Tab。IP 限流有现成的 Redis 计数范式（`PassportSmsIpCounterRedisDAO`），但产品端是单体直连、链路里没有活体网关，「网关层限流」的字面落点要定。 - -**生成额度从零新建**：代码里没有额度/钱包/扣额的概念，当前生成闸门是「日款数配额」而不是钱。要给每个用户一份可计量、可扣减、耗尽即拒的生成额度。 - -### facade / dify（agentic 方向的内测收口） - -「Dify」在现有代码里只是命名血缘（huijing/ruoyi fork 遗留＋契约 `contracts/dify-workflow-io.json` 的形态），三处源码注记都坐实现行后端其实是 agentscope，真正的 dify 部署与自定义节点代码为零。agentscope 硬支持已成立，内测只剩两项小收口：旧路退役纪律（SAA、gamedef、旧 worker `:9401` 的代码在席但不接线，照搬陈旧 .env 即错，要靠配置纪律＋文档防误配）；以及回调 HMAC secret 内测必须配非空——现 dev 两端为空等于关掉验签，内网可伪造回调驱动落包，这是内测安全项。 - -### 内测非阻塞尾项（默认延后，不占关键路径） - -配置外置的三条 e2e（D11 真 Spring wiring、K3 真 Nacos 激活、ASSET-SRC T1 真落库）代码均已闭合、缺的只是真跑窗口；archetype 假旋钮清账是十几分钟的极小活；SVG 尾波、面二 metrics、admin 富编辑视图均已完工或已拍为二期。这些错峰做，不进 A 段关键路径。 - -## 3 创始人已拍决策（2026-07-07） - -1. **额度口径 = new-api per-user ¥100**。不在 game-cloud 自建钱包，而是对接 new-api 网关的按用户额度、每人 ¥100，生成消耗由 new-api 权威计量。 -2. **注册登录真做用户名＋密码**。加密码列、mobile 改可空、开新端点＋前端 Tab。 -3. **dify 走形态A**，落在 game 专属 dify 实例上（见决策补记）。建一个 HTTP「游戏开发节点」直连便宜档 worker `:9501/generate`，复用现成 agentscope 生成与 HMAC 回调写链，后端近零改。 -4. **发布审核＝人工审核台值守**。已实现零开发，守住内容合规「人工终审」红线。 - -### 决策补记（2026-07-08，dify 实例归属修正） - -breezy 前身调研里写的是「复用 mini-infra 已有的 dify（共享 muse 实例 `:18080`）」。创始人随后明确：这套 dify 由 muse 与 game 两个项目共用，**workspace 必须分离**，不得污染 muse。据此已在 mini-infra 起了一套 **game 专属 dify 实例**（`100.64.0.8:28080`，compose 部署位 `/root/dify-game/docker`，`COMPOSE_PROJECT_NAME=game-dify`），凭据与操作留痕已落 [`docs/内网凭据与端点.md`](../内网凭据与端点.md) §game 专属 dify 实例。WU3 形态A 一律落在这套专属实例上，muse 的共享实例只读参照、不改动。 - -## 4 三 WU 接线缺口（读码坐实） - -### WU-1 注册登录 用户名＋密码＋IP 限流 - -game_player 加密码列、mobile 改可空、开 `password-register`／`password-login` 端点（复用 admin 侧 BCrypt 范式）＋前端登录 Tab；IP 限流默认落应用层（复用 `PassportSmsIpCounterRedisDAO` 纯 IP 计数），若坚持网关字面口径则 nginx `limit_req`。约 4–6 人日。 - -### WU-2 new-api per-user ¥100 额度 - -new-api 原生就有按用户额度体系：`users`（quota／used_quota）＋`tokens`（属于 user，用该 token 调用即扣该 user 额度、used_quota 是权威消耗计量）。现状是全局单一共享 key、job 无用户与额度位、成本自估非权威、game_player 与 new-api 零映射、注册不碰 new-api。六个接线点：管理凭据（new-api root/system token 进凭据档）、管理 client（建 user/token、充值、查余额；¥100↔quota 折算定一处）、注册充值 hook（`registerPlayer` 成功建号后同事务开户充 ¥100、幂等）、映射持久化（game_player.id ↔ new-api user_id/token，新 Flyway）、job 加用户 token 位（`AigcGenerateExecutor` job 组装追加 userToken，源＝creatorUserId 查映射）、worker 取 job token（从全局 key 改读 `job["userToken"]`，new-api 按 token 天然按用户扣）。内测取最小闭环——new-api 侧余额耗尽即拒是天然兜底；入队前的余额门与权威对账作轻加项、可后置。约 5–8 人日。 - -### WU-3 dify 形态A 游戏开发节点 - -在 game 专属 dify 实例（`:28080`）建一个 workflow，其中一个 HTTP「游戏开发节点」直连便宜档 worker `:9501/generate`（复用 job 契约＋HMAC 回调），后端近零改。代价是绕过后端任务表与计费门——形态A 定位是演示触发路，真跑主路仍是直调 agentscope。形态B（走后端 generate 保留任务/计费）要补服务间免登录 generate 端点、是新攻击面，内测不做。 - -## 5 执行阶段（阶段间有创始人门） - -契约、schema、跨模块、外部服务变更按 AGENTS.md §6 必须先设计门＋双评审＋创始人批再实施。 - -**阶段0 · 三设计门（并行产出，产出即停等批）**。WU-1／WU-2／dify 各一份功能设计文档，含 contract-first 草案（WU-1 密码列＋端点、WU-2 new-api 管理 client 接口＋job userToken schema＋映射表、dify 节点 I/O 契约）、`sot-impact` 申报、失败模式；各过 protocol 检查单＋Codex+Opus 双评审＋docs-gate 七检。创始人门批三设计，尤其契约变更与 new-api 管理凭据这两处不可逆项。 - -**阶段1 · 并行实现（worktree 隔离，各自证 build/test/lint）**。三 WU 三 lane 并行落地，facade 安全收口（回调 HMAC secret 两端配非空＋旧路退役配置纪律）作串行小项并入。 - -**阶段2 · dev 单点串行 e2e**。mini-desktop 单栈重部署，种子用户端到端：用户名密码注册→开户充 ¥100→生成（扣该用户 new-api 额度、used_quota 增）→试玩→人工审核台 APPROVE→发布→feed 可见→遥测回灌 quality_score；同窗核实已就绪链路。真 e2e 严格串行，多 agent 禁并发踩同一后端/库。 - -## 6 验证 - -阶段0：docs-gate 七检绿＋Codex+Opus 双评审通过＋SoT 注册表 `sot-impact` 申报。阶段1：各切片 mvn/vitest/单测绿＋worktree 自检；契约 round-trip；WU-2 对 new-api 管理 API 先 staging 实测摸端点与鉴权再接。阶段2（真机取证，DONE 附真实 commit hash＋原样输出）：注册返 OAuth2 token；new-api `users`／`tokens` 表新增行、quota=¥100 折算；一次真 gen 后该用户 `used_quota` 增；余额耗尽 gen 被 new-api 干净拒绝；feed 出该游戏；telemetry 回灌刷新 quality_score。dev 内网直连绕系统代理（真 IP＋`--noproxy`／`NO_PROXY`）。 - -## 7 风险与回滚 - -new-api 管理凭据是不可逆授权项，阶段0 门必须由创始人明批。密码列与 mobile 改可空是 game_player 表结构变更，走新 Flyway、旧数据 mobile 保留、password 允许空以兼容既有短信用户，回滚＝停用新端点即可（列可留）。dify 形态A 绕过计费门，仅作演示、不进内测计量主路，风险自限。回调 HMAC 配非空是纯收紧、无回滚风险。