docs(arch): 回填创始人 4 拍板(k8s收窄缓做 / P-FED-12升P0 / 同款不分成 / 审核台信用降权放第一期)

创始人 2026-06-22 拍板,逐条落档: - k8s:收窄(单节点 k3s + 数据库不进集群 + 推迟多节点/高可用/prod)+ 缓做(排 W-G1 之后) → k8s迁移 §7/§9/§6 收口、运维 README §4 修正 - P-FED-12 同款创作升 P0:Doc A 需求清单 P1→P0(P0 总数 55→56 待全局同步)、数据飞轮开放问题#6 + 正文收口、前端 README §7.3 口径校准 - 同款创作首期不分成、纯展示溯源:数据飞轮开放问题#1 + 正文收口 - 审核台 feed 自动降权 + 创作者信用模型放第一期(覆盖原"建议降 P1"):审核台 §4 第一期/§3.5/§5.3 收口为放第一期、单独做(均待 contract-first 补新 -api/新表) 验证:待拍板残留 grep 全 0;Doc A 已 P0;审核台"放第一期"7 处。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-22 01:12:11 +00:00 · 2026-06-22 01:12:11 +00:00 · 15b707fd2a
commit 15b707fd2a
parent 3e71715af9
6 changed files with 26 additions and 26 deletions
--- a/docs/architecture/产品/需求清单.md
+++ b/docs/architecture/产品/需求清单.md
@ -123,7 +123,7 @@ flowchart TB
 | P-FED-09 | 原生分享 / 复制链接 | 玩家 | P1 | v2.0 |
 | P-FED-10 | 加载进度反馈(封面/进度条/跳过) | 玩家 | P0 | v2.0 |
 | P-FED-11 | 首屏封面展示(封面/标题/作者/玩法/开始) | 玩家 | P0 | v2.0 |
-| P-FED-12 | 同款创作跳转工作坊 | 玩家 | P1 | demo |
+| P-FED-12 | 同款创作跳转工作坊 | 玩家 | P0 | demo |
 | P-FED-13 | 信息流推荐池 | 玩家 | P0 | demo/v2.0 |
 | P-FED-14 | 多端适配操控(触控+键盘) | 玩家 | P0 | v2.0 |
 | P-FED-15 | 低端设备低画质模式 | 玩家 | P1 | v2.0 |
--- a/docs/architecture/前端/README.md
+++ b/docs/architecture/前端/README.md
@ -194,7 +194,7 @@ token 还承担一个长期使命:**做跨端的单一事实源**(single source

 这套能力的后端已经是现行真相——`/studio/modify`、`/studio/extend` 端点和 SAA 的 modify 节点都建好了,studio 三路由 `/studio/{create,modify,extend}` 也在。当前缺的是前端承载:对话框、把六类素材传进去当生成上下文、系统解析意图后的目标确认卡、以及差量修改的入口和"改了哪、其余没动"的差异展示(对应[历史回收清单](../_recall/前端-历史设计点.md)的前端 C01–C04)。所以这块不是"descope 勿返工",而是**产品形态已经定调、前端 UI 待补设计**。

-> 一处口径校准:产品域需求清单里"智能体对话式创作"(P-CRT-05)、素材中心(P-MAT 整组)、同款创作(P-FED-12)目前仍标 P1。把它们定调为产品形态讲的是**方向**,不等于把验收优先级一次性提到 P0——验收范围的调整另走评审,别因这条定调就擅自改动验收契约。
+> 一处口径校准:产品域需求清单里"智能体对话式创作"(P-CRT-05)、素材中心(P-MAT 整组)仍标 P1;同款创作(P-FED-12)已由创始人 2026-06-22 拍板升 P0(数据飞轮网络效应核心杠杆,Doc A 已改)。把 P-CRT-05 / P-MAT 定调为产品形态讲的是**方向**,不等于把它们的验收优先级一次性提到 P0——这两项的调整仍另走评审,别擅自改动验收契约。

 ---

--- a/docs/architecture/架构/生成引擎/数据飞轮.md
+++ b/docs/architecture/架构/生成引擎/数据飞轮.md
@ -12,7 +12,7 @@

 设计要落在现状上,所以先核清这三条飞轮当前在库里有什么、缺什么。

-**溯源链——契约层零血缘,产品层 P-FED-12 还压在 P1。** 翻遍 `contracts/agent-loop/source-project.schema.json` 和 `contracts/events.schema.json`,跨游戏的血缘字段一个都没有(grep `lineage`/`origin`/`parent`/`remix` 零命中)。后端 `game_aigc_task` 表里有一个 `retry_of` 列,但那记的是"同一款游戏的某次重生成"的血缘,不是"玩家 A 照着创作者 B 的游戏做了个新游戏"这种跨项目派生。`game_source_project.base_version_id` 记的也只是 modify/extend 在同一款游戏内的版本血缘。所以"这款游戏是谁的同款、原作是哪一款、原作者是谁"这条信息,当前在库里**完全无处落脚**。产品侧,`P-FED-12 同款创作跳转工作坊` 在现行 Doc A(`docs/architecture/产品/需求清单.md`)里仍标 **P1 · 来源 demo**,RTM(`需求模块映射.md`)也只登记了它到 studio 模块的映射、没标 P0;两次历史审计(三向审计、demo 审计)都建议它升 P0,理由是它是玩家流量导回创作供给的唯一杠杆、网络效应飞轮的关键一环,但这个建议至今没落进 Doc A。创始人 2026-06-21 定了这条飞轮先落——但"先做设计与接缝"不等于"P-FED-12 已是 P0":升 P0 要走 RTM 同步改 Doc A 的优先级,前端档也明示优先级调整另走评审。本稿只做溯源链的设计接缝,不声称这条已升 P0,升级动作挂进文末开放问题。
+**溯源链——契约层零血缘,产品层 P-FED-12 还压在 P1。** 翻遍 `contracts/agent-loop/source-project.schema.json` 和 `contracts/events.schema.json`,跨游戏的血缘字段一个都没有(grep `lineage`/`origin`/`parent`/`remix` 零命中)。后端 `game_aigc_task` 表里有一个 `retry_of` 列,但那记的是"同一款游戏的某次重生成"的血缘,不是"玩家 A 照着创作者 B 的游戏做了个新游戏"这种跨项目派生。`game_source_project.base_version_id` 记的也只是 modify/extend 在同一款游戏内的版本血缘。所以"这款游戏是谁的同款、原作是哪一款、原作者是谁"这条信息,当前在库里**完全无处落脚**。产品侧,`P-FED-12 同款创作跳转工作坊` 在现行 Doc A(`docs/architecture/产品/需求清单.md`)里仍标 **P1 · 来源 demo**,RTM(`需求模块映射.md`)也只登记了它到 studio 模块的映射、没标 P0;两次历史审计(三向审计、demo 审计)都建议它升 P0,理由是它是玩家流量导回创作供给的唯一杠杆、网络效应飞轮的关键一环,但这个建议至今没落进 Doc A。创始人 2026-06-21 定了这条飞轮先落——但"先做设计与接缝"不等于"P-FED-12 已是 P0":升 P0 要走 RTM 同步改 Doc A 的优先级,前端档也明示优先级调整另走评审。P-FED-12 已由创始人 2026-06-22 拍板升 P0、Doc A 已改(见开放问题#6);本稿做溯源链的设计接缝。

 好消息是地基不空:生成入口的三条路由 `/studio/{create,modify,extend}` 已经建好(`AppStudioController`),feed 卡片、试玩页都已经在跑,`game_feed_interact_log` 已有点赞/收藏/分享/举报四种互动埋点。同款创作要补的是"从 feed 卡片发起一次带血缘的 create",链路两端都现成,缺的是中间那段血缘的记录与回放。

@ -133,7 +133,7 @@ sequenceDiagram

 **网络效应漏斗要有埋点,否则升 P0 的核心 KPI 量不出来。** P-FED-12 升 P0 的理由是它是"玩家流量导回创作供给的唯一杠杆",可这个杠杆的转化率要能度量才能验证它配得上 P0。血缘边只记结果态(谁最终生成了同款),量不出"feed 曝光→点了做同款→真的提交了生成"这条漏斗的衰减——点了做同款但没提交、提交了但生成失败,这些都不会留下血缘边。现状是 `events.schema.json`(契约⑤)里只有 `feed_view/like/favorite/share/report` 这类互动事件,没有任何 remix/做同款事件。所以阶段一 additive 新增两个事件:`remix_click`(在 feed/试玩页点了"做同款",props 带 parentGameId)、`remix_submit`(真的提交了带 remixFrom 的生成,props 带 parentGameId+新 taskId)。它们与 like/share 同构(走同一条 envelope、同一批量上报通道),老消费者忽略未知事件,零兼容风险。有了这两个事件,"曝光→点同款→提交→生成成功"的漏斗才连得起来,P-FED-12 升 P0 后才有可观测的转化指标。

-> 一处要和创始人确认的产品口径:同款创作出来的游戏,**是否要在发布时对原作者做收益分成**(类似"翻唱分成"),还是纯展示溯源、不涉及钱。本稿默认**首期纯展示溯源、不分成**(assetRefs 字段为资产市场分成预留但同款本身不触发),把钱的事留到资产市场那条线统一处理。这条挂进开放问题。
+> 产品口径(创始人 2026-06-22 已定):同款创作出来的游戏**首期纯展示溯源、不对原作者分成**(assetRefs 字段为资产市场分成预留,但同款本身不触发),钱的事留到资产市场那条线统一处理。

 ### 3.2 资产市场:与素材契约、支付的对接边界

@ -240,7 +240,7 @@ flowchart TB
  style TRACE fill:#fff7e6,stroke:#d90
 ```

-**阶段一(溯源链 + 同款创作)排在第一步,但"最轻"的前提是同款取轻量跳转形态。** 同款的产品形态不先定一个默认值,阶段一的工程量就是浮动的——两种形态工程量差一个量级:一种是**轻量跳转**——点"做同款"就跳到工作坊、预填一句话 brief(可带原作标题/品类提示),不读父游戏的源项目,生成走的还是普通一句话生成那条已验过的路,只多挂血缘;另一种是**真 remix**——携带父游戏的 gameDefinition 作生成上下文,让模型基于已有玩法做变体,这要撞上"便宜模型在受约束的变体生成下能不能稳产"这个还没过的 80% 门(见 §5 风险二),工程与验证成本高得多。**本稿默认取轻量跳转形态**,把真 remix 列为后续(待便宜模型变体能力验过再上)。只有在轻量跳转形态下,阶段一才当得起"最轻":链路两端(feed 卡片、生成路由)都现成,新增项是源 schema 的 `lineage` 字段、一张 `game_lineage_edge` 血缘边表、`/studio/create` 的 `remixFrom` 入参、试玩页溯源展示、创作者中心"被 N 人做了同款"的去重聚合 API 与入口、以及 `remix_click/remix_submit` 两个漏斗事件。配套的 P-FED-12 升 P0 不在本稿权限内:本稿只做溯源链的设计接缝,升 P0 要走 RTM 同步改 Doc A 优先级、前端档另走评审(挂文末开放问题)。另外,血缘的 `assetRefs` 不会"顺带"攒出素材复用归因——素材复用要等创作者真的走选素材通道(P-CRT-04)才产生,阶段一攒下的是血缘本身,不是分成依据。
+**阶段一(溯源链 + 同款创作)排在第一步,但"最轻"的前提是同款取轻量跳转形态。** 同款的产品形态不先定一个默认值,阶段一的工程量就是浮动的——两种形态工程量差一个量级:一种是**轻量跳转**——点"做同款"就跳到工作坊、预填一句话 brief(可带原作标题/品类提示),不读父游戏的源项目,生成走的还是普通一句话生成那条已验过的路,只多挂血缘;另一种是**真 remix**——携带父游戏的 gameDefinition 作生成上下文,让模型基于已有玩法做变体,这要撞上"便宜模型在受约束的变体生成下能不能稳产"这个还没过的 80% 门(见 §5 风险二),工程与验证成本高得多。**本稿默认取轻量跳转形态**,把真 remix 列为后续(待便宜模型变体能力验过再上)。只有在轻量跳转形态下,阶段一才当得起"最轻":链路两端(feed 卡片、生成路由)都现成,新增项是源 schema 的 `lineage` 字段、一张 `game_lineage_edge` 血缘边表、`/studio/create` 的 `remixFrom` 入参、试玩页溯源展示、创作者中心"被 N 人做了同款"的去重聚合 API 与入口、以及 `remix_click/remix_submit` 两个漏斗事件。配套的 P-FED-12 升 P0 已由创始人 2026-06-22 拍板:走 RTM 正式升,Doc A 的 P-FED-12 已由 P1 改 P0(见开放问题#6)。另外,血缘的 `assetRefs` 不会"顺带"攒出素材复用归因——素材复用要等创作者真的走选素材通道(P-CRT-04)才产生,阶段一攒下的是血缘本身,不是分成依据。

 **阶段二、三(资产市场)拆成只读半和流通半,被两道前置卡着。** 只读半(跨创作者素材货架、浏览、自有授权范围内选用)依赖素材中心 P-MAT 那组把素材结构化、加授权类型——这是素材中心模块的活,生成侧只等它就绪后做薄薄的"选用素材透传"。流通半(授权采购、分成结算)依赖真实支付收单接通,而支付受日历闸门(牌照/二清)约束,**物理上做不快**。所以资产市场绝不能排进 MVP 第一步——它的前置不是工程量,是外部闸门。

@ -274,7 +274,7 @@ flowchart TB

 ## 6. 开放问题(留给创始人拍板)

-1. **同款创作要不要对原作者收益分成?** 本稿默认首期纯展示溯源、不分成(类似"致敬"而非"翻唱分成"),把素材/IP 的分成统一留到资产市场那条线。但如果定位上希望"被同款=原作者也能赚钱"来强化创作激励,就要在阶段一就把同款分成接进 trade。这直接影响阶段一的范围大小。
+1. **同款创作要不要对原作者收益分成?(创始人 2026-06-22 已定:首期不分成)** 首期纯展示溯源、不对原作者分成(类似"致敬"而非"翻唱分成"),素材 / IP 的分成统一留到资产市场那条线。已拍板,阶段一不接同款分成、保持最轻。

 2. **同款的产品形态——本稿默认取轻量跳转,确认是否接受、真 remix 何时上。** 两种形态:轻量跳转(跳工作坊预填一句话 brief、不读父源项目,实现轻、但"同款"相似度弱)和真 remix(携带父游戏 gameDefinition 作生成上下文做变体,血缘与复用关系强、但要撞便宜模型受约束变体生成那个还没过的 80% 门)。§4 已默认取轻量跳转、把真 remix 列后续,据此 lineage 阶段一不携带父 gameDefinition。需要创始人确认:是否接受首期只做轻量跳转的弱相似度同款,真 remix 是否等便宜模型变体能力验过(W-G1 之后)再排期。

@ -284,4 +284,4 @@ flowchart TB

 5. **收益回流语料的归属与使用授权。** 把创作者的生成数据、玩家的留存数据用作训练语料,需要在用户协议层面拿到授权(尤其未来用于自训小模型)。这条是产品/法务口径,工程上随 trace 脱敏规则走,但"能不能用、怎么告知用户"要创始人和律所定。

-6. **P-FED-12 正式升 P0 的流程动作。** 现状:P-FED-12 在 Doc A(`docs/architecture/产品/需求清单.md`)仍标 P1·demo,RTM(`需求模块映射.md`)只登记映射、未标 P0,两次历史审计建议升 P0 但没落进 Doc A。创始人 2026-06-21 定了这条飞轮先做,但本稿只做溯源链的设计接缝、不替代优先级裁定。要把 P-FED-12 真正升 P0,需要走 RTM 同步改 Doc A 的优先级、前端档明示的优先级调整另走评审。请创始人确认是否正式批准升 P0 并启动这套同步动作——这决定阶段一的范围是按"已是 P0 的核心功能"投入,还是按"P1 的设计预研"投入。
+6. **P-FED-12 正式升 P0(创始人 2026-06-22 已定:走 RTM 升 P0)。** 创始人拍板正式升 P0:Doc A(`产品/需求清单.md`)的 P-FED-12 已由 P1 改 P0,前端档 §7.3 口径校准同步。阶段一据此按 P0 核心功能投入。注:升 P0 使 P0 总数 55→56,全局"55 P0"口径(AGENTS / knowledge)待同步。
--- a/docs/architecture/运维/README.md
+++ b/docs/architecture/运维/README.md
@ -114,12 +114,12 @@ flowchart TB
 - **admin 侧补观测入口**:在 admin 控制台补"观测跳转 / 观测大图",让运营和排查能从后台一键进到监控大盘,而不是各看各的散件。
 - **部署形态**:观测栈与服务编排往 **k8s** 收;可参考 **yudao-cloud / vue-pro** 已有的监控集成(它本身带了一套可观测性接入,能省掉从零搭的工夫)。

-**范围(创始人 2026-06-21 定:全做 + 本阶段上 k8s)**:
+**范围(创始人 2026-06-21 定全做 → 2026-06-22 修正:观测全做,k8s 收窄 + 缓做)**:

 1. **采集**:OpenTelemetry 全栈埋点(trace / metrics / log 统一)。
 2. **看板告警**:Grafana + 夜莺(Nightingale),关键告警含可用性 / 错误率 / 生成失败率。
 3. **admin 观测入口**:控制台补观测跳转 / 观测大图,一键进监控大盘。
-4. **k8s 编排**:观测栈与服务编排上 k8s;可参考 yudao-cloud / vue-pro 已有的监控集成省搭建工。
+4. **k8s 编排(收窄 + 缓做)**:创始人 2026-06-22 定 k8s 收窄为单节点 k3s + staging 应用 + 观测栈、数据库不进集群、推迟多节点 / 高可用 / prod;时机排在 W-G1 生成质量告一段落之后。观测栈先在单体 staging 上裸 docker 跑、不被 k8s 阻塞。详见 [k8s迁移.md](k8s迁移.md)。

 > ⚠️ **blast radius(我作为工程师的提示)**:上 k8s 是**部署架构的大变更**——当前是单体 staging(mini-desktop 容器),迁 k8s 会改动 [staging-ops](../../../.agents/skills/staging-ops.md) 整套部署链与四机分工,影响面远大于其余三件观测工作。建议把"k8s 迁移"**单独立一个设计 / 实施项**,与观测埋点解耦推进,别让观测大盘被 k8s 迁移阻塞(观测栈本身在单体 staging 上也能先跑起来)。

--- a/docs/architecture/运维/k8s迁移.md
+++ b/docs/architecture/运维/k8s迁移.md
@ -3,7 +3,7 @@
 > 本文配套[运维主文档](./README.md) §4。主文档定了"本阶段上 k8s、观测栈与服务编排都往 k8s 收"的方向,本文给出具体的迁移路径:迁到什么形态、分几步、哪一步能回滚,以及对"是否现在就全迁"的工程评估。
 > 读者:做这次迁移的执行工程师(Mac 侧编码 + mini-desktop 落地)、关心可用性与运维成本的创始人。
 >
-> 推荐范围 = 单节点 k3s 跑在 mini-desktop 上,只迁 staging 应用与观测栈,mini-infra 的共享基建不进集群。这个范围由两个硬事实约束:当前机器内存余量有限(mini-infra free 仅剩 569Mi),且内网阶段没有 prod 环境。把范围收窄到这里,迁移过程不必返工,后续要扩多节点也是平滑长上去。但"是否现在就把这套全做"是一个取舍判断,涉及运维投入与生成主线的优先级,留到 §7 作为开放问题交创始人定。
+> 推荐范围 = 单节点 k3s 跑在 mini-desktop 上,只迁 staging 应用与观测栈,mini-infra 的共享基建不进集群。这个范围由两个硬事实约束:当前机器内存余量有限(mini-infra free 仅剩 569Mi),且内网阶段没有 prod 环境。把范围收窄到这里,迁移过程不必返工,后续要扩多节点也是平滑长上去。范围与时机创始人 2026-06-22 已定(见 §7):范围收窄如上,时机缓做、排在 W-G1 之后。

 ---

@ -256,13 +256,13 @@ spec:

 ---

-## 7. 范围与时机:待创始人拍板
+## 7. 范围与时机:创始人已定(收窄 + 缓做)

-运维主文档 §4 已定方向是"本阶段上 k8s"。在这个方向下,还有一个范围与时机的取舍没有定,本节如实摆出现状与可选项,交创始人拍板,不在文档里替创始人做决定。
+运维主文档 §4 原定"本阶段上 k8s"。范围与时机两个取舍,创始人 2026-06-22 拍板:**范围收窄、时机缓做**——下面两条是结论与依据。

-**[待创始人拍板] 取舍一:把"全做"收窄到哪个范围。** 本方案推荐的范围是单节点 k3s + staging 应用层 + 观测栈,数据库不进集群,多节点/高可用/prod 全部推迟。理由在 §2(范围外)与 §6(风险三)已展开:多节点缺第二台有余量的 x86 机器,硬凑要动 mini-infra(已挤)或 6c6g(会 OOM);数据库进集群是另一个量级的风险,和应用迁移捆在一起一旦出错可能损数据,而 staging 库是长期手工累积、从没被一键重建过(运维基建-026)。按这个范围迁,收益清晰(声明式 + 一键回滚 + 共存保护 + 观测编排)、风险可控、随时可退;范围若扩到多节点或数据库,投入与风险都会显著上一个台阶。**是否就按这个收窄范围执行,请创始人确认。**
+**取舍一·范围(创始人 2026-06-22 已定:收窄)。** 本方案推荐的范围是单节点 k3s + staging 应用层 + 观测栈,数据库不进集群,多节点/高可用/prod 全部推迟。理由在 §2(范围外)与 §6(风险三)已展开:多节点缺第二台有余量的 x86 机器,硬凑要动 mini-infra(已挤)或 6c6g(会 OOM);数据库进集群是另一个量级的风险,和应用迁移捆在一起一旦出错可能损数据,而 staging 库是长期手工累积、从没被一键重建过(运维基建-026)。按这个范围迁,收益清晰(声明式 + 一键回滚 + 共存保护 + 观测编排)、风险可控、随时可退;范围若扩到多节点或数据库,投入与风险都会显著上一个台阶。**创始人已定:就按这个收窄范围执行——单节点 k3s + staging 应用 + 观测栈,数据库不进集群,多节点 / 高可用 / prod 推迟。**

-**[待创始人拍板] 取舍二:现在做,还是排在生成主线之后。** 这一项是 §6 风险五的延伸,需要单独点出来交创始人定。客观事实是:k8s 迁移是运维基建投入,它兑现的价值(共存保护、声明式部署、观测编排)是真实的,但**它不直接提升生成质量**,而当前项目的关键路径是 W-G1(把生成质量做到 80%)。迁移与观测埋点解耦后,可以排在生成主线的空隙做;但这几天的工程带宽花在迁移上,就不在生成上。所以"现在就做这次迁移、还是等生成主线告一段落再做"是一个优先级取舍,**请创始人定时机**。
+**取舍二·时机(创始人 2026-06-22 已定:缓做)。** 这一项是 §6 风险五的延伸,需要单独点出来交创始人定。客观事实是:k8s 迁移是运维基建投入,它兑现的价值(共存保护、声明式部署、观测编排)是真实的,但**它不直接提升生成质量**,而当前项目的关键路径是 W-G1(把生成质量做到 80%)。迁移与观测埋点解耦后,可以排在生成主线的空隙做;但这几天的工程带宽花在迁移上,就不在生成上。创始人已定:**这次迁移缓做,排在 W-G1 生成质量告一段落之后**(阶段0 容器化零 k8s 风险、是上云前提,可先行)。

 **两项取舍下,各阶段的工程判断(供决策参考,非结论):**

@ -288,11 +288,11 @@ spec:

 ---

-## 9. 开放问题(待创始人拍板)
+## 9. 范围与时机:创始人已定

-下面两项是文档不替创始人定的取舍,执行前需要先有结论。详细背景见 §7。
+创始人 2026-06-22 拍板,两项都定了(依据见 §7):

-1. **范围**:本方案推荐把"全做"收窄为"单节点 k3s + staging 应用层 + 观测栈,数据库不进集群,多节点/高可用/prod 全部推迟"。这个收窄范围是否就是执行范围?(若要扩到多节点或数据库进集群,投入与风险都会显著上一个台阶,需另行评估。)
-2. **时机**:k8s 迁移是运维基建投入,不直接提升生成质量,而当前关键路径是 W-G1(生成质量到 80%)。这次迁移是现在就排期做,还是等生成主线告一段落再做?
+1. **范围 = 收窄**:单节点 k3s + staging 应用层 + 观测栈,数据库不进集群,多节点 / 高可用 / prod 全部推迟。
+2. **时机 = 缓做**:排在 W-G1(生成质量到 80%)告一段落之后;其中阶段0 容器化零 k8s 风险、是上云前提,可先行。

 此外有一项与本设计无关、由现状暴露出来的独立议题,顺带记录、不在本方案处理:后端现为"Java 17 编译、JDK21 运行"(上游 yudao 既定组合,M1 已验证可跑);要不要把编译目标也提到 Java 21 与本迁移解耦,留作单独议题。
--- a/docs/architecture/运营/审核台运营.md
+++ b/docs/architecture/运营/审核台运营.md
@ -45,7 +45,7 @@ flowchart LR

 而且这个降权接缝是上一波**刻意没建**的:封禁联动的代码注释(`UserBanServiceImpl`,R5 降权出流屏蔽)写明"P1 本波不生效——不注入 feed、不建 FeedDownweightApi 孤儿 seam"。所以处置联动 feed 这件事,**下架**走现有 `offlineRank` 就够,**降权**则要么新建一个 feed 降权 `-api`(把 `setExposureLimit` 提升到跨模块契约),要么改走"下架 + 内容安全处置台账"的组合而不单独做降权——这是 §3.5 要定的事,别声称接缝已经焊好。

-**community 模块:创作者信用的宿主是等级引擎,但信用本身零实现。** "创作者信用"这个概念目前没有独立实体。community 有一个等级引擎(`LevelDO`,表 `game_community_level`,T-CMU-11),现有字段是 `level/publishedCount/lastMilestone` 这些,**没有 `credit_score`**,MVP 只维护发布计数 + 新人里程碑、分层留 P1;`CommunityNotifyApi` 也没有任何扣分端点。信用分要么挂上这条等级线(加列),要么另立一张独立扣分台账——两条路在 §3.5 里展开,放不放第一期见文末开放问题。
+**community 模块:创作者信用的宿主是等级引擎,但信用本身零实现。** "创作者信用"这个概念目前没有独立实体。community 有一个等级引擎(`LevelDO`,表 `game_community_level`,T-CMU-11),现有字段是 `level/publishedCount/lastMilestone` 这些,**没有 `credit_score`**,MVP 只维护发布计数 + 新人里程碑、分层留 P1;`CommunityNotifyApi` 也没有任何扣分端点。信用分要么挂上这条等级线(加列),要么另立一张独立扣分台账——两条路在 §3.5 里展开,创始人 2026-06-22 定放第一期、建简单扣分台账。

 **完全没有的:** 双层机审的两层都没接——既没有自部署快检模型,也没有阿里云内容安全客户端(全仓只有 OSS 用到阿里云);人审队列只有"申诉"这一种工单,没有"内容初审/复审"的工作队列(带认领、分派、SLA);锁风三档强度只有分级(rating)这个结果字段,没有"按 IP 敏感度选标准/严格/人工复核档"的策略配置,IP 库本身还是 seam(寄宿 compliance,授权链未建)。

@ -207,7 +207,7 @@ stateDiagram-v2
 - **下架/屏蔽**(内容违规,彻底踢出流):compliance 调 feed 现有的跨模块接缝 `FeedApi.offlineRank(gameId)`,把该游戏全分区排序行 `status` 置 `0`,`buildStream` 出流时直接踢掉。这条**现成可用**,封禁联动下架已经在走它。
 - **降权**(内容有问题但不到下架,压低曝光):理想效果是把 `exposureLimit` 调高、`sort_score = quality + boost − exposureLimit` 自动下沉,内容还在流里但排得很后。但 `setExposureLimit` 现在只是 `AdminFeedController` 的**管理端 HTTP 端点**(给运营手动调用),**不在跨模块 `FeedApi` 上**,compliance 调不到。要让 compliance 自动降权,得 contract-first 新建一个 feed 降权 `-api`(把 `setExposureLimit` 的能力提升到跨模块契约层)。

-这里有个 [待创始人拍板] 的取舍:降权这条要不要单独做。一种做法是新建 feed 降权 `-api`(契约面新增,见下);另一种是 MVP 不单独做自动降权,违规内容统一走"`offlineRank` 下架 + 内容安全处置台账记录"组合,把"降权但不下架"这种中间态留到后面再补。这关系到要不要现在就给 feed 开一个新的跨模块写入口,如实摆进文末开放问题。
+降权这条创始人 2026-06-22 定**放第一期、单独做**:新建 feed 降权 `-api`(契约面新增,见下)让 compliance 能自动降权,不只靠"`offlineRank` 下架"——"降权但不下架"这种中间态第一期就有。代价是现在就给 feed 开一个新的跨模块写入口(contract-first 补 FeedApi 降权方法 + compliance-server 补 feed-api 依赖)。

 若采用新建降权 `-api` 这条路,contract-first 清单是:在 `game-module-feed-api` 的 `FeedApi` 上加一个方法(如 `downweight(gameId, exposureLimit)`)+ 对应 DTO,`FeedApiImpl` 委托既有 `FeedService.setExposureLimit`(实现已在,不重写);compliance-server 的 pom 补 `game-module-feed-api` 依赖(现在没有,见 §2 编译缺口)。无 DB 迁移(`exposure_limit` 列 V25 已落)。

@ -223,7 +223,7 @@ stateDiagram-v2
 - **跨模块 `-api`**:在 `community-api` 的 `CommunityNotifyApi`(或另立一个信用专用 api)上加一个扣分方法,**带幂等键**(同一处置事件重复投递不重复扣分);compliance 处置后调它注入扣分。
 - **compliance 编译依赖**:compliance-server 的 pom 补 `game-module-community-api` 依赖(现在没有,见 §2 编译缺口)。

-[待创始人拍板] 信用模型放第一期还是降到 P1。它牵涉新表 + 新跨模块端点 + 误伤治理(一次误判处置可能连累创作者长期曝光),工作量和风险都不小。一种选择是第一期就把"简单扣分台账(只记不连带)"建起来;另一种是把整个信用模型降到 P1、第一期先不做,违规约束先靠单次处置和封禁兜着。两条都和等级引擎"MVP 仅计数、分层留 P1"的口径相容,如实摆进文末开放问题。
+信用模型创始人 2026-06-22 定**放第一期**:第一期就把"简单扣分台账(只记不连带)"建起来——它牵涉新表 + 新跨模块端点(带幂等键)+ 误伤治理。第一期取保守形态(只扣分、不做激进连带封禁),复杂规则(信用分联动曝光基线等)留后细化,和等级引擎"MVP 仅计数、分层留 P1"的口径相容。

 ```mermaid
 flowchart TB
@ -306,7 +306,7 @@ flowchart TB

 - 内容安全原子(文本/图像)落地为**自部署快检 + 桩位的阿里云接缝**——快检真跑,阿里云实现挂 feature flag。原子接进现有锁风门聚合。
 - 审核工单台账 + 轻量状态机 + admin 审核队列/详情/处置页。把"机审 review → 建工单 → 人审认领裁决 → 回写驱动"主干打通。
- 违规处置联动:下架走 feed 现有的 `FeedApi.offlineRank`(现成);封禁联动补两块断链——封账号时置 `game_player.status=DISABLE`(让 `validateCreator` 拦得住)+ 按 creatorId 批量下架其全部已发布内容。降权是否单独做、以及创作者信用模型放不放第一期,见文末开放问题(都涉及新建跨模块写入口/新表)。
+- 违规处置联动:下架走 feed 现有的 `FeedApi.offlineRank`(现成);封禁联动补两块断链——封账号时置 `game_player.status=DISABLE`(让 `validateCreator` 拦得住)+ 按 creatorId 批量下架其全部已发布内容。**feed 自动降权与创作者信用模型也放第一期(创始人 2026-06-22 定)**:新建 feed 降权 `-api` 让 compliance 自动降权、建简单信用扣分台账(只记不连带),两者都 contract-first 补新跨模块写入口 / 新表(见 §3.5)。
 - 锁风三档用过渡的 `lock_strength_policy` 配置表起步(admin 可配),先按题材黑名单 + 手配 IP 映射选档。

 这一期做完,自有端邀请制内测就有了一套能日常运转的内容安全运营——机审挡大面、人审兜疑难、违规真下架真拦创作。
@ -344,12 +344,12 @@ flowchart LR
 - **人审是真正随产能咬人的成本**,且舆情内容有"2 小时内下架"的 SLA(历史回收 021)。MVP 轻量状态机能不能扛住放量后的审核积压、SLA 告警够不够及时,要在放量灰度时压测,必要时提前引 BPM。
 - **创作者信用是新机制,要防误伤**。信用扣分若规则太硬,一次误判处置可能连累创作者的长期曝光,而申诉救济的时效要跟上。信用规则若做,MVP 也要保守(只扣分、不做激进的连带封禁),复杂规则留 P1 再细化。

-### 5.3 待创始人拍板的开放问题
+### 5.3 拍板结论与剩余开放项

-下面三件涉及新建跨模块写入口或新表,工作量和风险都不小,设计稿不替创始人定,如实摆出现状和取舍:
+原本三件待拍板,创始人 2026-06-22 已定前两件(feed 自动降权 + 创作者信用模型都放第一期、单独做);剩第三件(锁风记录升不升列)是工程细节,倾向写 JSON:

-1. **feed 自动降权要不要单独做(§3.5)。** 现状:feed 有 `exposureLimit` 字段和 admin 手动降权端点,但没有供 compliance 调的跨模块降权 `-api`,而上一波(`UserBanServiceImpl` R5 注释)是刻意没建这个 seam 的。取舍:要么 contract-first 新建 feed 降权 `-api` 让 compliance 能自动降权;要么 MVP 不做自动降权,违规内容统一走"`offlineRank` 下架 + 内容安全处置台账"组合,把"降权但不下架"的中间态留后。
-2. **创作者信用模型放第一期还是降 P1(§3.5)。** 现状:`LevelDO` 没有 `credit_score`,`CommunityNotifyApi` 没有扣分端点,整套是零实现。它要新表 + 新跨模块端点(带幂等键)+ 误伤治理。取舍:第一期就建"简单扣分台账(只记不连带)",还是整个降到 P1、第一期先靠单次处置和封禁兜着。
+1. **feed 自动降权(创始人 2026-06-22 定:放第一期、单独做)。** contract-first 新建 feed 降权 `-api`(FeedApi 加降权方法 + DTO、compliance-server 补 feed-api 依赖)让 compliance 能自动降权,而非只靠 `offlineRank` 下架——"降权但不下架"的中间态第一期就有。
+2. **创作者信用模型(创始人 2026-06-22 定:放第一期)。** 第一期建简单扣分台账(只记不连带,保守形态),contract-first 补新表(独立台账或 `LevelDO` 加 `credit_score` 列)+ community-api 带幂等键的扣分端点 + compliance-server 补 community-api 依赖。
 3. **锁风裁决记录升不升列(§3.3)。** 现状:`game_compliance_gate_result` 没有 `lock_strength`/`ip_id` 列。取舍:MVP 把档位和命中 IP 写进已有的 `details` JSON(不改表),还是补一次 Flyway 迁移加两列(为了按档位做报表查询)。倾向写 JSON,但若确有报表需求需创始人点头升列。

 ---