zizi-al/games-development-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
games-development-ai/docs/agent-specs/2026-06-11-community-biz前端入口-评审纪要.md
zizi d7eee53fa5 docs(fe-cmbiz): community/biz 前端入口 review版spec定稿(HJ-FE-CMBIZ-001·Ultracode) 
给 Wave4 后端配前端(no-orphan闭合+B端可演示):community消息中心+biz客户询单看板(game-studio)+biz admin处理队列(game-admin),消费已入库契约零后端改动。10 agents(4 recon→起草→四镜头评审含design-lens→定稿,接受18/重定向1/记录2)。
- 评审逮:D5 biz demo试玩取包 owner-agnostic 契约缺口(卡AC-FE-4 B端现金线命脉,升跨前后端硬前置)/§0端点17→19矛盾(blocker)/清除invent契约引用(runtime实查仅1-102-001-001无owner-agnostic端点)/D1「我的中心」承载页(design-lens补,本波唯一动导航处)
- scope收敛=纯前端·消费已入库契约·零后端·不做M4资金流UI;三块可拆(最小必交=①消息中心+②biz客户侧,③admin受7权限点staging闸门约束未过则顺延)
- 待创始人拍:D1客户入口位置/D2等级奖励是否做/D3 admin队列是否本波接/D5⚠️demo取包路径

待创始人审review+UI走查→拍4口径→开execution。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-11 14:20:08 +00:00

14 KiB
Raw Blame History

community / biz 前端入口 · 评审纪要（四镜头 findings 逐条处置）

编号 HJ-FE-CMBIZ-001-MIN ｜ 2026-06-11 ｜ 关联：2026-06-11-community-biz前端入口-review.md（定稿后） 范围：feasibility(5) + scope-guardian(3) + coherence(6) + design-lens(7)，共 21 条 findings 逐条处置。 处置原则：接受的→直接改 review.md（标具体落点）；拒绝/重定向的→说明理由。所有契约引用均经 2026-06-11 实查仓库核实（runtime.yaml / biz.yaml / community.yaml / biz_menu.sql / TabBar.vue / Project.vue / components/index.ts）。

处置统计

处置 条数 findings
接受（已改 review.md） 18 feas#1/#2/#3/#4/#5；scope#1；coh#1/#2/#3/#4/#6；design#1/#2/#3/#4/#5/#6/#7
重定向（采纳但反转/降级推荐结论） 2 scope#2（D7 抽组件→反转为默认页内联）；design#7 的「时间线复用」隐含项同源（并入 D7 重定向）
记录/无改动（FYI 或文档已自洽） 2 scope#3（FYI 范围确认）；coh#5（「客户三态」概念，文档自洽无对应物）

注：design#7 本体（提单提交后流向）为接受；其与 scope#2 共享「单消费者抽组件」信号的部分并入 D7 重定向。按 finding 主体归类：接受 18 / 重定向 1（scope#2）/ 记录 2（scope#3、coh#5），合计 21。

一、feasibility（可行性，5 findings）

feas#1 [major·接受] biz demo 取包路径=契约缺口，非「路由选择/中风险」

  • 核实：runtime.yaml:35-36/56 实查 = 仅 scene=preview（校验调用者为版本 owner，status∈{0,1}）+ scene=play（仅 status=1），错误码仅 1-102-001-001，且 :239 明文「不在前端兜底」。无 owner-agnostic 端点。运营代建 demo 的 owner≠客户客户 → preview 必被 owner 校验拦、play 又要 status=1。证据成立。
  • 处置：D5 从「execution 自决/中风险」升格为「开 execution 前须与 runtime owner 协调拍定的硬前置」。§0.1 新增 D5⚠️ 决策行（二选一：(a) demo 走正式发布使 status=1 用 play / (b) runtime 补 owner-agnostic 能力=后端改动升跨模块协调项），§6.2 风险级别由「中」改「高」，§8 D5 谁定改「runtime owner + 创始人」，§3.2/§3.3 取包路径引用全部指向 D5。路径未通前 AC-FE-4 标受阻、demo 试玩可能降级占位。

feas#2 [major·接受] D3 admin 闸门缺可执行验证手段

  • 核实：biz_menu.sql 实查不进 Flyway、需手动 mysql 执行；id 实为 7100~7107（7100 父菜单 + 7101-7107 七权限点，共 8 行），review 原文仅写「7101-7107」漏父菜单。全文无可执行校验命令。证据成立。
  • 处置：§4.2 补可执行闸门校验 SQL：SELECT id,permission FROM system_menu WHERE id BETWEEN 7100 AND 7107（期望 8 行），不足则 mysql --default-character-set=utf8mb4 ... < biz_menu.sql 再复验；§0.1-D3 / §8-D3 同步补「8 行 / id 7100-7107 / 可执行 SQL」。

feas#3 [minor·接受] GamePlayer.vue 位置标注错误

  • 核实：components/index.ts 实查 7 组件（TabBar/GameCard/LoadingBar/EmptyState/InteractBar/AppButton/Placeholder），不含 GamePlayer；GamePlayer.vue 实在 src/host/GamePlayer.vue，Play.vue:20 即 import ... from '../../host/GamePlayer.vue'。证据成立。
  • 处置：§4.1 地基组件行更正——7 组件清单照实列，GamePlayer 单列「不在 components/、在 src/host/」+ props 签名（gameId/versionId/mode/可选 manifest/可选 fetchPackage）+ 照 Play.vue:20 挂载；§3.2 demo 试玩行复用路径改为 src/host/GamePlayer.vue。

feas#4 [minor·接受] 端点计数 17 vs 19 自相矛盾

  • 核实：§0 同句「17 个」与「共 19」打架；实查 community app=5 + biz app=7 + biz admin=7=19。与 coh#1 同源。
  • 处置：见 coh#1（§0 改 19 + 计数基准声明）。

feas#5 [minor·接受] feedback 强制 demoVersionId 与 confirm 字段贯穿未说明

  • 核实：BizFeedbackReqVO required:[demoVersionId]（:430）；confirm requestBody required:false（:178）。lead.demoVersionId 在 BizLeadDetailRespVO（:377/387）。证据成立。
  • 处置：新增 D9（§8）：两步 demoVersionId 同取自 GET /biz/leads/{id} 详情的 demoVersionId，feedback 提交前校验非空；§5.3 补 feedback/confirm 先后行（确认弹窗内含选填反馈，一次提交先 feedback 后 confirm，允许空反馈直接确认）。

二、scope-guardian（范围守卫，3 findings）

scope#1 [minor·接受] §0 端点总数自相矛盾

  • 与 coh#1/feas#4 同源。处置：见 coh#1。

scope#2 [minor·重定向] D7 抽 Timeline.vue 基于推测性复用

  • 核实：game-studio 实查无任何 Timeline 组件；project 审核/发布流用 StatusBadge.vue（非时间线）；本波时间线唯一确定消费者只有 biz 询单进度一处。「单消费者抽接口=抽象未挣到工钱」信号成立。
  • 处置（重定向：反转原推荐）：原 review 倾向「可复用 Timeline.vue（community 审核流可能复用）」；按 rule-of-three 反转为默认「页内联」。§5.3 时间线行 + §8-D7 改为「默认页内联，待 community 审核流真要时间线再抽」。

scope#3 [minor·记录无改动] 三块是否本波全交（FYI/范围确认）

  • 核实：计划已正确处理可拆性（③受闸门约束未过即降级、①等级/奖励自标增强）。范围守卫认可，仅作记录。
  • 处置（采纳建议补一句，非改 scope）：§0 交付清单后补**「交付范围分层」一句**——最小必交集=①消息中心三件+②biz 客户侧；条件增强=③admin（前置权限点闸门）+①等级/奖励（前置 D2）。便于实现 agent 按闸门结果裁剪。

三、coherence（内部一致性，6 findings）

coh#1 [blocker·接受] §0 一句话结论 17 vs 19 自相矛盾

  • 核实：§0 line 13「17 个」被自身括号「共 19」否定；全文其余（§4.4/§7 AC-FE-6）一律 19；契约实测 5+7+7=19。body 权威，「17」是错数。
  • 处置（blocker 必修）：§0 改「19 个对外可封装端点-操作」+ 删「共 19」歧义；新增端点计数基准声明（以 HTTP operation 计，quotes 同 path 含 POST+GET=2，admin 7 operation/6 path），全文统一 19。

coh#2 [major·接受] biz admin「封 7」计数基准未声明（§0头/§3.3表/§4.4图打架）

  • 核实：§0.1/§4.2/§4.4 称 admin「7」，但 §3.3 表 6 行、§4.4 图 6 节点（d4=POST/GET quotes 1 节点 2 操作）。「7」按 operation、「6」按 path，文档未点明。与 coh#1 同根。
  • 处置：§0/§4.4 加计数基准声明（operation vs path）；§4.4 图把 d4 拆 d4a/d4b 两节点显式呈现 7 operation；§3.3 表上方补「6 行=6 path，报价行承载 POST+GET 两 operation=admin 封 7 operation」。

coh#3 [major·接受] §6.2 引用 runtime.yaml 未定义的错误码/能力

  • 核实：runtime.yaml 全文仅 1-102-001-001，无 1-102-001-003、无 RUNTIME_PACKAGE_PREVIEW_NOT_OWNER、无 getStatus、无 owner-agnostic 端点。§6.2/§3.2/§3.3 均 invent 了不存在的契约面。证据成立（execution agent 会照抄查不到的码）。
  • 处置：§6.2 D5 行删除 1-102-001-003 / RUNTIME_PACKAGE_PREVIEW_NOT_OWNER，改「具体错误码待与 runtime owner 确认，runtime.yaml 现仅定义 1-102-001-001」；§3.2 line 204 删「getStatus owner-agnostic」改「validateDemoPreviewable + 依赖 D5 钉定契约、runtime 现无 owner-agnostic 端点」；§8-D5 同步去 getStatus 措辞。

coh#4 [minor·接受] 「待验收必就绪」与「待验收要兜不就绪」表观对立

  • 核实：line 201「待验收态前后端必保证 demo 就绪」与 AC-FE-4「负路径 demoPreviewable=false 置灰」并存，未点破「门后包可能被驱逐/失效」。
  • 处置：§3.2 关键 UX 降级态补一句**「正常路径待验收恒就绪（advance→3 硬守门保证）；负路径仅覆盖包就绪后被驱逐/失效的少数情形」**，消除对立。

coh#5 [minor·记录无改动] 全文不存在「客户三态」概念

  • 核实：文档对 biz 客户建模为「只读看状态/报价/进度 + 唯一写=确认验收」，状态机=五态，文中「三态」均指 UI 渲染三态（loading/空/列表）。文档自身自洽，无「客户三态」对应物。
  • 处置（记录，不改）：确认文档内部自洽，无遗漏的客户侧状态分类（客户视角=五态只读 + 单写动作，已在 §3.2 充分表达）。若上游另有「客户三态」聚合口径，属上游术语，本文无需引入。

coh#6 [minor·接受] 「端点数」与「P0 数」相邻易混（line 82 biz 6 vs biz app 7）

  • 核实：line 82「biz 6」=P0 功能数（P-BIZ-01/02/03/04/08/12）；biz app 7=端点数。两轴不同但贴近且都冠「biz」。
  • 处置：§2 line 82 补注**「P0 功能数（biz 6）≠端点数（biz app 7），1 个 P0 可对应多端点（如 P-BIZ-03 进度看板=leads/my+leads/{id}+progress 三端点）」**。

四、design-lens（设计缺失，7 findings）

design#1 [major·接受] 信息架构断层：「我的」承载页不存在

  • 核实：TabBar.vue:27-29 实查三入口写死 /feed //create /project；/project→Project.vue 自述「我的项目列表」、无入口区/卡片栏结构；router meta.title='我的项目'。D1/D2/D6 四个二级入口无聚合落点。与 §2 非目标「不改既有导航」冲突。证据成立。
  • 处置：D1 升格涵盖「我的中心承载页落点」——§0.1-D1 / §8-D1 改为二选一（(a) 新建 /me 个人中心页、TabBar 第三入口改指 /me、/project 降二级；或 (b) Project.vue 顶部加聚合入口区 banner）；§2 非目标放宽为「不动 feed/create 两区」+ 例外说明；§6.1 影响面新增 T1b（『我的』承载页改造）节点 + 专条说明「会动既有导航的唯一处」+ 补承载页空态/加载/角标刷新时机。

design#2 [major·接受] biz demo 产出桥接是隐藏断点（versionId 从哪来）

  • 核实：biz.yaml admin 7 端点无任何「生成 demo」端点；advance→3 的 demoVersionId 由运营手填，来源是运营另去创作流生成 version 再复制回。流程图全黑盒。证据成立。
  • 处置：§3.3 新增「demo 产出桥接」节点（运营先去 game-studio 创作流生成 game/version → 拿 versionId → 复制回 advance 弹窗；本波纯人工复制、不做一键跳创作流带 leadId 回链=超边界顺延；advance 弹窗只给 demoVersionId 输入框+「去创作流生成 demo」文案提示，不在 biz 内造生成入口）；§3.3 运营流程 mermaid 加 BR「demo 产出桥接」节点。

design#3 [major·接受] biz 列表项无 demoPreviewable，列表→详情态缺失

  • 核实：BizLeadRespVO（列表 VO，:368-379）仅 status/demoVersionId，无 demoPreviewable（仅在 BizLeadDetailRespVO :387）。列表无法预判哪单可试玩。证据成立。
  • 处置：§3.2 五态色后补「列表→详情 demo 可用性一致性」纪律——列表态不预判 preview，对 status=3 统一显「待验收·去试玩」引导，进详情后由 demoPreviewable 决定亮/灰；§3.2 my-orders 行标「列表态策略见下」。

design#4 [minor·接受] feedback 与 confirm 先后/依赖未定义

  • 核实：feedback required demoVersionId、confirm 可空，均作用于待验收 3 态，后端不强制先后。能否空反馈直接确认未说明。
  • 处置：并入 D9（同 feas#5）——反馈为确认的可选前置，确认弹窗内含选填反馈框，一次提交先 feedback 后 confirm，允许空反馈直接确认；§5.3 补 feedback/confirm 先后行。

design#5 [minor·接受] community type2 公告 tab 恒空无处置

  • 核实：community.yaml messages type enum[1,2,3,4]，但四类 notify RPC 只产 type1/3/4，无 type2 生产路径。§2 自承「type2 可能恒空」但未给空态/隐藏策略。
  • 处置：§3.1 补 type2 处置——推荐本波直接不渲染 type2 公告 tab（待有公告投递台再加）；若保留四 tab 则 type2 须给专属空态「暂无平台公告」（区别普通「暂无消息」）。

design#6 [minor·接受] 未读角标刷新/递减时机仅覆盖单条已读

  • 核实：§3.1 仅「点开单条已读 total--」；跨页返回/新信到达/批量已读的角标重拉时机未定义。community.yaml unread-count 需主动 GET 无推送。
  • 处置：D6 补刷新时机（§8-D6 + §5.3 角标行 + §6.1）——进入承载入口页 onMounted 拉一次 unread-count + 消息中心内已读后乐观递减；本波不做实时推送（无推送通道，轮询/进入即拉为准）。

design#7 [minor·接受] 提单表单提交后流向/字段引导未充分定义

  • 核实：BizLeadCreateReqVO 仅 bizType/title 必填，其余全可选，templateId 来自 GET /biz/templates。§3.2 仅列端点，未说提交后跳哪/模板是否必选/联系方式如何触达。证据成立。
  • 处置：§3.2 补「提单提交后流向 + 字段引导」段——成功 Toast 后跳 /biz-orders/my-orders 高亮新单 或 进 /biz-orders/:id 详情（二选一但必有明确落地页）；模板纯可选不做必选引导；联系方式契约可选但做软提示引导（B 端运营跟进唯一抓手）。§3.2 提单行标「提交后流向+字段引导见下」。

五、定稿后状态确认

  • blocker 全消：coh#1（17→19）已修 + 计数基准声明，全文 grep 无「17 个对外/共 19」。
  • invent 契约引用全清：1-102-001-003 / RUNTIME_PACKAGE_PREVIEW_NOT_OWNER / getStatus / owner-agnostic 端点 全文 grep 仅存于「runtime 现无此端点」的否定性表述，无既定契约误引。
  • scope 收敛：纯前端 UI·消费已入库契约·零后端改动·不做 M4 资金流 UI——非目标表保持（报价禁「立即支付」、奖励禁「已发放」），D1 仅放宽「我的承载页加聚合入口区」、未越界后端。
  • 真前置浮出：D5（demo 取包契约缺口）已从隐性 execution 自决升为显性跨模块协调硬前置，避免实现者在不可达路径上 block。