games-development-ai/docs/agent-specs/2026-06-08-wave3创作补全与发布闸门-review.md

Wave3 创作补全与发布闸门 并行建设 — Review 版 Master Plan

编号：HJ-BUILD-003 ｜ 生成 2026-06-08 ｜ 类型：review 版（结论先行，供决策，不含代码级细节） 配套执行版（本 review 批准后写）：2026-06-08-wave3创作补全与发布闸门-execution.md 上游依据：Wave1 脊柱已建（HJ-BUILD-001）、Wave2 变现已建（HJ-PAR-002）、studio 裁定（建最小版）、Doc A/B/C、契约登记 contracts/README.md、克隆 playbook .agents/skills/add-business-module.md。 复用方法：三相并行 + 主 agent 验证门（不采信子 agent 自报）；双 spec 铁律（memory wave-needs-review-and-execution-spec-pair）。

---

⚡ 接力锚点（压缩后从这里续）

• 已建并 push：Wave1 脊柱 5 模块（project/aigc/runtime/feed/telemetry）+ Wave2 变现 2 模块（ad/trade）+ 前端 game-studio 脊柱 + game-admin 运营台。
• 本轮 = Wave3：studio(最小版) + compliance(MVP切片) + ip(薄壳)，解锁 M2 创作链路 / M3 发布闸门关键路径。
• 创始人决策（2026-06-08，AskUserQuestion）：①studio = 建最小版独立模块（非折进 aigc/project）；②Wave3 范围 = studio+compliance+ip(薄壳)，community+biz 归 Wave4。
• 进度（LIVE）：📝 review 版起草中（本文件） → 待两轮 review → 执行版 → 三相 Workflow。尚未锁契约、未建任何 Wave3 模块。
• 命名/验证门铁律：全栈 wanxiang（cn.wanxiang.game）；后端 mvn -pl <模块> -am test，前端 npm run build（vue-tsc --noEmit 是假门禁）。

---

一、结论（先行）

1. Wave3 与前两波本质不同：它是"接入已建模块"，不再是孤立新建。 锁风门要焊进 project.publish、审核状态机要与 project 既有 review 切分归属、studio 要焊进 aigc/project、降权信号要进 feed。最大风险在集成面（blast radius），不在新建本身——review 版把"接入已建模块"列为一等公民工作流，带回归门。
2. 三个模块必须狠切到 MVP 范围，否则必过建：
   • studio：只建最小版 7 项核心（资产图/六资产调度/附件上下文/草稿移交/线性任务链/轻量会话/进度），砍 rig/对白树/可视化工作流（P1）。
   • compliance：Doc B 有 38 个 T-CMP，MVP 只做 6-7 项 P0 切片（锁风门+审核状态机+人工队列+分级+封禁/降权）；RBAC/审计/安全基线复用 yudao，安全硬化（T-CMP-20~38）+ 防沉迷/实名/GDPR 整体延后。
   • ip：自身 0 个 P0，薄壳——只供 T-IP-04 风格原子给锁风门 + 锁定契约 seam；素材库/授权/市场（P-MAT/P-IPX）全是 P1，延后。
3. 波内有依赖，非全平铺：ip 是 studio 与 compliance 的共同上游（风格原子/素材 seam），其 -api/契约须先锁；之后 studio ∥ compliance 并行。
4. 复用 Wave1 三相骨架 + 钉死 Wave2 六条教训（见 §八）：独立 execution.md、Phase C 写到命令粒度、LIVE 逐相回填、跨已建模块改动带回归门、studio 先入错误码/契约登记。
5. 本计划抗漂移：目标/决策/seam 写入本 doc + 执行版 + 各模块 .agent，不依赖会话记忆。

---

二、范围与非范围（每模块狠切 MVP）

2.1 studio（最小版 · 错误码 112 · Flyway V8）

纳入 MVP（建）	关联 P0	砍出（P1，留 seam 不实现）
T-STU-02 资产图模型（可视化资产树）	P-CRT-02	T-STU-03 角色 rig 编辑（P-CRT-06）
T-STU-09 六类资产模块化生成调度	P-CRT-02	T-STU-04 对白分支树（P-CRT-05/P-LIC-04）
T-STU-06 附件上下文装配	P-CRT-04	T-STU-05 agentic/对话式任务链（P-CRT-05）
T-STU-08 草稿装配与 project 移交	P-TPL-03	T-STU-10/11 可视化工作流/批量（远期未映射）
T-STU-05 任务链（MVP=固定线性）	P-CRT-01/09
T-STU-01 创作会话（轻量持久化）	P-CRT-10
T-STU-07 进度推送（MVP 可先轮询，不急上 SSE）	P-CRT-12

边界（Doc B §71-76）：studio = 有状态创作工作台后端，不跑 LLM/扩散（委托 aigc）、不持久化项目版本（交 project）、不做锁风裁决（调 compliance）。

2.2 compliance（MVP 切片 · 错误码 109 · Flyway V9）

纳入 MVP（建）	关联 P0	非范围（复用/延后）
T-CMP-12 锁风门 Gate（聚合 aigc T-AGC-19 + ip T-IP-04 → pass/review/block + 标准/严格/人工）	P-LIC-05	RBAC（T-CMP-16）= 复用 yudao，不重建
T-CMP-06 审核决策与状态机 + T-CMP-09 人工队列	P-OPN-01/P-ACC-04	安全基线 T-CMP-20~32（OWASP/SSRF/CORS/Secrets/加密/漏扫）= 复用 yudao + 延后硬化
T-CMP-18 封禁 + T-CMP-11 举报降权（产降权信号给 feed）	P-OPN-04	T-CMP-36/37 防沉迷/实名、T-CMP-33~35 GDPR/数据权 = 延后（P-BIZ-11/P-ACC-02 多为展示或 B 端，MVP 轻量/mock）
T-CMP-13 分级标签判定	P-ACC-03	渠道合规库 T-CMP-14/15 = 仅留接口，渠道真实规则 P1

边界（Doc B §272-277）：compliance = 安全审核中枢，不自产风格原子（aigc/ip 供给）、不拥有项目实体（读 project）、不做推荐（产降权信号给 feed）、不展示隐私/申诉 UI（交 studio 前端）。 关键防过建：38 个 T-CMP 里 MVP 只碰锁风门链与审核状态机；安全硬化是"运维/安全专项"，不是 MVP 业务 P0。

2.3 ip（薄壳 · 错误码 108 · Flyway V10）

纳入 MVP（建）	用途	非范围（P1，全延后）
T-IP-04 IP 风格一致性校验原子	供 compliance 锁风门聚合	素材库/UGC 库（P-MAT-01/02）
契约 seam（ip.yaml 风格原子 -api）	studio/compliance 消费	授权链/分成（T-IP-02/03、P-MAT-04/05/06）
（视实现）最小风格校验或 mock 原子	锁风门可跑通	素材市场（P-IPX-01/02）、Zone 双轨归类（T-IP-10，与 P-MAT 一起 P1）

ip 自身 0 个 P0；薄壳的唯一职责 = 让锁风门 seam 闭合。若评审认为 MVP 锁风门用 aigc 风格原子 + ip mock 即可，ip 甚至可退化为"仅契约 + mock 原子"，待 P-MAT（P1）落地再补全 → 见 §十 待确认 D2。

---

三、依赖与 seam 图

flowchart TD
  subgraph NEW[Wave3 新建]
    STU[studio 112/V8<br/>资产图·六资产调度·附件·草稿移交·线性任务链]
    CMP[compliance 109/V9<br/>锁风门·审核状态机·人工队列·分级·封禁降权]
    IP[ip 108/V10 薄壳<br/>T-IP-04 风格原子]
  end
  subgraph BUILT[已建模块（本波要焊接，带回归门）]
    AIGC[aigc ✅]
    PRJ[project ✅<br/>publish 门禁=Wave1 mock]
    FEED[feed ✅]
  end

  STU -->|按类调度生成 seam| AIGC
  STU -->|草稿移交 T-STU-08 seam| PRJ
  STU -.->|读素材/风格 薄| IP
  CMP -->|聚合风格原子| AIGC
  CMP -->|聚合风格原子| IP
  CMP -->|锁风门替换 publish mock| PRJ
  CMP -->|降权信号| FEED
  IP -->|T-IP-04 原子| CMP

seam 必须在 Phase A 评审门锁死：①studio→aigc 六资产编排；②studio→project 草稿移交（谁写资产图/GameConfig，照 Wave1 定 package_url 写者的方式定死归属）；③compliance 锁风门 -api（被 project.publish + aigc 调）；④ip T-IP-04 原子 -api（被 compliance 调）；⑤compliance 降权信号 → feed。

---

四、Blast radius — 接入已建模块（一等公民，带回归门）

Wave3 与 Wave1/2 最大差异：要改三个已验证模块。每处都是"改已建代码"，按 Wave2 F5 教训单列、带回归断言：

改动	已建模块	改什么	回归门
锁风门替换发布 mock	project.publish	Wave1 收口 §1 留的 T-PRJ-05 发布前门禁（当前 mock/清单）→ 改为调 compliance 锁风门 -api（P-PUB-03 锁风+性能+版权）	project 既有单测 + publish 流程仍绿
审核归属切分	project（已有 /admin-api/project/review + game_review_record）	明确：compliance 拥有审核状态机/人工队列/锁风裁决；project 持有游戏状态 + 接收审核结果回写。避免双写审核态	project review 既有行为不破坏；状态机单一权威
风格原子聚合	aigc	compliance 调 aigc T-AGC-19 风格原子（aigc 已建，确认 -api 暴露或新增对接点）	aigc 既有生成链不受影响
降权信号	feed	compliance 产降权信号 → feed 排序消费（feed 已建，确认消费入口）	feed 既有排序不破坏

这些"接入"由主 agent 在 Phase C 串行做（或独立小 agent + 主 agent 回归门），不挂在新建模块 agent 顺带——Wave2 F5 的教训。

---

五、三相编排 + 波内顺序

flowchart LR
  subgraph PA[Phase A 契约+评审门]
    direction TB
    a1[起草 studio.yaml+V8] & a2[compliance.yaml+V9] & a3[ip.yaml+V10]
    --> rv[主 agent 评审 5 条 seam 一致性 → 锁契约]
  end
  PA --> PB
  subgraph PB[Phase B 并行建设（互斥目录）]
    direction TB
    ipb[① ip 薄壳先建+install -api] --> par[② studio ∥ compliance<br/>各消费 ip-api / 互 mock seam]
  end
  PB --> PC[Phase C 主 agent 串行集成 + 接入已建模块]
  PC --> acc[全量编译+单测绿 / 回归门 / 验收 / LIVE 回填]

• 波内非全平铺：ip 是 studio/compliance 的上游 → ip -api 先建并 install，再 studio ∥ compliance（两侧消费 ip-api，互不依赖、可并行；compliance↔studio 无直接依赖）。
• Phase B 隔离：各 agent 只写互斥 game-module-{studio,compliance,ip}/，构建 mvn -pl game-module-{name}/... -am test；不碰根 pom/yudao-server/已建模块——这些 Phase C 主 agent 串行。
• 关键任务子 agent 跑 Opus（memory opus-subagents-critical-tasks）；锁风门/资产图编排是高风险点，主 agent 验证门兜底。

---

六、关键设计决策与取舍

#	决策	理由 / 取舍
1	compliance 狠切 MVP 切片，安全硬化（T-CMP-20~38）延后、RBAC 复用 yudao	38 项全建 = 数周工作量且与 yudao 重叠；MVP 只需锁风门链路成立。照 Wave2 "pay 复用 yudao-pay" 的不重复造轮子
2	ip 薄壳（仅 T-IP-04 + seam）	自身 0 P0，素材库是 P1；薄壳让锁风门 seam 闭合即可，避免为 P1 提前造素材库
3	"接入已建模块" 主 agent 串行 + 回归门，不挂新建 agent 顺带	Wave2 F5 教训：改黄金模块无回归门有风险
4	锁风门 MVP 聚合 aigc 风格原子 + ip 原子（可 mock），真实内容安全 API 待闸门	内容安全 API/真实联盟是日历闸门（memory mvp-binding-constraint-calendar-gates），骨架先成立
5	studio 草稿移交归属 Phase A 定死（资产图/GameConfig 谁写）	防 studio↔project 双写、防 Wave1 同类（package_url 写者）问题重演
6	跨模块只依赖对方 -api（Feign 同步 / MQ 异步）	全项目铁律，防编译耦合/循环依赖

---

七、共享资源预分配（已查证 contracts/README §四 + pom）

• 错误码段：compliance=109 / ip=108（已预留）；studio=112 新开（现表 100-111 无 studio，须登记）。
• Flyway 主版本：V1-5 Wave1、V6 ad、V7 trade 已用 → studio=V8 / compliance=V9 / ip=V10（按建序）。
• 新契约（均不存在，Phase A 起草并锁）：api-schemas/studio.yaml+db-schemas/V8、compliance.yaml+V9、ip.yaml+V10；含 §三 五条 seam 的 x-feign-contracts。
• 登记动作：Phase A 同步更新 contracts/README §四（加 studio=112）与 §三波次清单。

---

八、吸收 Wave2 评审的六条教训（执行版必带）

Wave2 finding	Wave3 执行版对策
F1 无独立 execution.md	独立 …-execution.md，脚本不顶替规格
F2 LIVE 锚点失真	LIVE 锚点置于 execution.md，主 agent 验证门后逐相回填真实产物（filesWritten/单测/runId）
F3 Phase C 只有 bullet	Phase C 写到命令粒度 + 验收判据（加 pom/复制 Flyway diff-identical/全量 compile/回归门）
F4 admin 粒度过低	本波无新前端运营页（admin 已建）；如需补审核页，接口字段映射到 VO/权限码粒度
F5 跨模块改动无回归门	§四"接入已建模块"独立列 + install 顺序 + 回归断言
F6 studio 未登记	§七 先把 studio 入错误码 112 + Flyway V8 + 契约登记

---

九、验收标准

• 每模块：mvn -pl game-module-{name}/... -am test 编译 + Service 单测绿；契约文件入 contracts/；.agent 含"运行时未验证"标注。
• 整体：mvn -pl yudao-server -am compile + mvn install 全量绿；cn.wanxiang.game.module 下模块全部被扫描接入。
• 接入回归门：project/aigc/feed 既有单测仍绿；project.publish 走通"调锁风门"路径（mock 闸门下 pass/block 二态可演示）。
• 链路（staging 有基建时）：创作链路 studio 编排六资产→草稿（M2 方向）；发布链路 project.publish→compliance 锁风门→feed（M3 方向）≥1 条可走通。
• 文档：双 spec + 各 .agent + 契约/README 同步 + memory 更新；无信息只活在会话。

---

十、待确认决策项（批准本 review 前）

1. 本 review 方案是否采纳（Wave3=studio+compliance+ip 薄壳 / 三模块 MVP 切片 / 接入已建模块带回归门）？
2. ip 薄壳深度：MVP 锁风门用 aigc 风格原子 + ip mock 原子即可（ip 退化为"契约+mock"），还是 ip 须实现真实 T-IP-04 风格校验？（影响 ip 工作量）
3. 审核归属切分：compliance 拥有审核状态机/锁风裁决，project 既有 /admin-api/project/review 改为接收回写——是否认可这一归属（避免双写审核态）？
4. 执行载体：批准后执行版用 Workflow 三相编排（一次跑多 agent）还是手动逐相派 Agent（更可控）？

批准后我：①写执行版 spec（含 5 条 seam 的契约骨架、各模块 DoD、Phase C 命令、回归门）→ ②两轮 review → ③Phase A 起草+锁契约 → ④三相建设。