adapt-game-mobile

name	adapt-game-mobile
description	BoardGame 单游戏移动端适配入口。用于 mobileProfile、横竖屏、mobile shell、hover/拖拽替代、游戏层手机/平板验收；不重写原生 App 或框架层。

适配游戏移动端

概览

• 本 skill 的第一原则是 PC 版是权威布局，移动端只能在不影响 PC 的前提下做条件化适配。
• 默认目标是 手机横屏尽量可用，不是强行把所有游戏都压成手机竖屏。
• 默认复用现有 React + Vite + UI Engine Framework，不重写第二套 MobileBoard。
• App WebView、小程序 web-view 只是分发容器，不是移动端适配方案本身。
• 移动端适配验收对象始终是同一套 H5 / PWA 在移动视口下的真实交互。
• 移动端适配不是 UI 重构；除非用户明确要求，否则不得借适配顺手重做阴影、边框、质感、色彩语言、动效节奏或整体视觉风格。

基线分辨率

• 本项目默认 PC 对照分辨率固定为 1920x1080。
• 本项目默认手机横屏真实设备基线固定为 2340x1080（13:6）。
• E2E / 浏览器采样视口如果不直接使用 2340x1080，也必须保持同样 13:6 宽高比；推荐使用仍落在移动断点内的 936x432。
• 如果用户明确说明“平板按 PC 看”或“这轮不关心平板”，则可以只保留 PC + 手机横屏 两档，不强制补平板横屏。

自适应单一方案

• 本项目固定构图类游戏只保留一种自适应方案：设计画布尺寸 + 壳层统一等比缩放。
• 标准公式是：scale = min(availableWidth / designWidth, availableHeight / designHeight)。
• 横屏、竖屏不各自发明单位体系；横屏通常更容易被高度约束，竖屏通常更容易被宽度约束，但这只是上述统一公式算出来的结果。
• vh / vw 不能作为固定构图主单位：不得用“横屏 vh、竖屏 vw”替代壳层统一缩放去重算卡牌、棋盘、HUD 或操作轨。
• px 在主体画布内只表示设计坐标，不表示最终显示像素；最终显示尺寸必须由壳层缩放、容器约束或同等适配层统一承接。
• vw / vh 只允许用于局部辅助：安全区、壳层可用高度、装饰偏移、非关键视觉细节；一旦影响主体画布、主按钮、主字号、手牌轨道、中央牌区或 HUD 尺度，就视为错误方案。
• 对 board-shell / 固定牌桌类游戏，顶栏、分数、阶段提示、手牌、中央牌区、主按钮、主操作区都默认属于同一张 PC 牌桌构图；移动端不得把这些区域拆开另算坐标、另排一套按钮轨道或另缩一套字号。
• 按钮的 right / bottom、手牌偏移、顶栏宽度这类定位关系，只能在 PC 设计坐标系内定义，再交给壳层统一缩放；不得在手机媒体查询里把按钮改成新的右下角浮动按钮、底部 action rail 或独立操作区，除非用户明确要求新移动 UI。

核心硬规则

0. 先过 PC 门禁，再谈移动端

• 任何“移动端适配 / 横屏压缩 / 低高度布局 / 手机首屏重排 / 触控补入口”任务，默认都必须先确认 PC 版当前实现已经达标。
• 这里的 PC 达标 不是指“能打开页面”，而是至少满足：
  • 主信息层级正确，没有仍在影响桌面端判断的明显视觉/交互缺口；
  • 关键区域尺寸、比例、阅读顺序、主次关系已收口；
  • 本轮正在接入的新桌面素材/新桌面布局，已经通过桌面真图或桌面测试证据确认。
• 只要 PC 端还存在明确缺口，本轮默认动作就是继续收 PC，不得提前展开移动端压缩、断点重排、横屏特化或触控补丁。
• 只有两种情况可以越过这个门禁：
  • 用户当轮明确说“这轮先看移动端 / 可以先做移动端试探 / PC 问题后补”；
  • 当前动作本身就是在修一个已锁定的移动端回归，且不会扩大或改变 PC 语义。
• 最终汇报必须明确写出：
  • PC 是否已达标
  • 本轮是否因此启动了移动端适配
  • 若未启动，当前挡住移动端阶段的 PC 缺口是什么

1. PC 优先，不得回归

• 任何移动端适配都不得改变 PC 的视觉层级、尺寸基线、布局流和主交互路径。
• 任何移动端适配都不得偷偷替换 PC 或既有 H5 的默认交互语义；尤其不能把原本存在的 点击查看 / 点击放大 / 点击展开 静默改成 仅长按、仅 hover 或 仅额外按钮。
• 只要用户反馈 “PC 端出问题了”，优先回查最近移动端改动，默认按回归处理。
• 不允许为了塞进手机屏幕而全局调小 clamp(...)、统一缩放桌面按钮、压缩桌面主面板。
• 不允许把桌面常驻结构直接改成抽屉或折叠，除非该变化只在移动条件下生效。

2. 移动端只能条件覆盖

• 所有移动端尺寸压缩、触控入口、面板折叠、底部 action rail、hover 替代入口，都必须只在移动条件下启用。
• 但“只能条件覆盖”不等于“默认可以重排主牌桌”。对固定构图 / board-shell / live 牌桌，移动条件覆盖的默认职责是修安全区、触控入口、无遮挡和壳层缩放参数；不得借移动端条件覆盖创造一套和 PC 不同的主 UI 布局。
• 底部 action rail、右侧 dock、抽屉化、按钮搬家只适用于已经被判定为流式信息区、次要工具区或用户明确要求的移动专版；不得用于承接 PC 牌桌里的主按钮、手牌、顶栏、分数和中央牌区。
• 移动条件优先级：

1. 窄视口：以 mobileSupport.ts 中的 1023px 断点为准。
2. manifest / mobile shell：用于页面级结构切换。
3. 粗指针 / 触控：只用于 hover 替代入口显隐，不可单独作为压缩 PC 尺寸的依据。

• 触屏笔记本仍然属于 PC 布局范围；不能因为 (pointer: coarse) 就缩小桌面 UI。

3. 交互目标的命中区不等于视觉盒子

• 任何触控交互目标都可以按需补命中区，但默认不能把对应元素的可见尺寸一起改大或改胖。
• 这里的“交互目标”不只包括按钮，也包括图标入口、卡牌预览热点、状态徽记、标签页、列表项、头像入口、抽屉开关、操作轨道项等一切可点击或可触达元素。
• 禁止在移动媒体查询里对通用交互元素选择器、共享组件基类或全局图标类直接施加统一的 min-width、min-height、额外 padding 等规则来“顺带解决触控”。
• 如果确实要补命中区，优先用显式 opt-in 类、透明 hit area、伪元素、外层点击盒或局部包装层；不要污染整类交互目标的视觉基线。
• 命中区方案必须和桌面视觉尺寸解耦；“更容易点到”不等于“看起来更大”。

4. 主体画布默认必须等比缩放

• 棋盘、地图、卡面、牌桌背景、立绘、预渲染面板、带格子或固定几何关系的战区，默认都属于 主体画布；移动端适配时必须优先保持等比缩放。
• 禁止为了“塞进手机视口”单独改主体画布的 width / height、横纵向比例、格子宽高或背景图比例，造成非等比拉伸、压扁、拉长。
• 正确顺序始终是：先保证主体画布等比，再通过 scale / translate / pan / 裁切 / 留白 / 局部滚动 / HUD 重排 解决视口容纳问题。
• 如果主视图已经进了视口，但肉眼看起来被压扁、拉高、格子比例失真、点击热点和视觉位置错位，这轮适配仍然算失败。
• UI 区域不得笼统默认 重排：先区分它是不是固定牌桌的一部分。顶栏、分数、阶段提示、手牌、主按钮、中央牌区、主操作区属于同一固定构图时，默认跟随主体画布等比缩放，不能重排成另一套手机布局。
• 只有日志、说明、帮助、设置、聊天、反馈、规则页、次要侧栏等非主牌桌信息区，才可以在移动端折叠、让位、悬浮或抽屉化；这类重排不得改变主牌桌的相对位置和缩放来源。
• 只有用户明确要求“允许牺牲原比例换更大可视面积”，或者该区域本来就是纯流式 UI 容器而不是固定画布，才允许不按此条处理；否则一律按回归看待。

5. 优先记录根因，不只记录现象

• 审查时不要只写“按钮变胖了”“图标变大了”“移动端整体缩水了”，必须继续追到导致现象的真实来源。
• 记录问题时，优先写成“哪条全局样式 / 哪个共享组件基类 / 哪个媒体查询 / 哪个布局条件判断”导致视觉膨胀、缩水或挤压，而不是只写结果描述。
• 高频根因模式通常只有几类：全局选择器污染、共享交互基类叠加移动规则、命中区要求和视觉盒子耦合、把 coarse pointer 误当布局条件、把桌面 token 全局替换成更小值。
• 如果一次异常同时出现在多个区域，默认先怀疑根因在全局 CSS、共享组件或公共条件判断，而不是多个游戏组件刚好同时写错。

6. 默认裁决

• PC 是唯一权威版本；移动端做的是“适配”，不是“重做一套更小的桌面版”。
• 如果某项改动会让 PC 和移动端共用一套更小的尺寸 token，这个方案默认错误。
• 如果某项能力未来会被多个游戏复用，优先沉到框架层或通用 hook，不要在单个游戏里硬写。
• 优先修的是触控尺寸、视口条件、局部放大入口、关键路径可达性，不是桌面视觉语言本身。
• 如果用户只说“移动端看起来怪 / 被压扁 / 比例不对”，默认先怀疑是主体画布非等比缩放，而不是先去调按钮大小或全局缩字。

先读权威来源

• docs/mobile-adaptation.md
• openspec/specs/game-registry/spec.md
• docs/ai-rules/ui-ux.md
• docs/ai-rules/engine-systems.md

如需补充理解当前设计背景，再读：

• openspec/changes/add-pc-first-mobile-adaptation-framework/design.md
• openspec/changes/add-pc-first-mobile-adaptation-framework/specs/mobile-support-framework/spec.md

按需阅读 references/：

• 字段与命名：references/manifest-fields.md
• 审查与验收：references/checklist.md
• DiceThrone 试点：references/dicethrone-pilot.md

如果用户这次要的是提案、spec、proposal，而不是直接接入，先走 OpenSpec 流程。

默认交互裁决

hover

• 卡牌 hover：默认改为 长按看大图，优先复用 useLongPressAction.ts。
• 面板 hover：默认改为 点击查看详情 或 点击进入放大层。
• 影响决策的 hover 信息：必须变成稳定入口，不能只存在悬停态。
• 长按 默认是新增的触控 fallback，不是替换既有 点击 语义；如果原本已经存在 点击查看 / 点击放大 / 点击展开，移动端适配后默认仍要保留。
• coarse pointer、触控 hook、inspect 手势只能决定“补什么移动端入口”，不能单独作为“取消原 click 行为”的依据；除非用户明确要求重编排交互。

侧栏

• 核心信息侧栏：PC 默认保持原有桌面结构，不主动改成抽屉。
• 次要信息侧栏：只有在移动窄屏下确实挡主战区时，才折叠为抽屉、标签页或切换面板。
• 日志、说明、帮助：优先判断为次要信息后，再在移动端降级为可切换面板。

拖拽

• 关键操作不能只靠拖拽。
• 默认补一条 点击选中 -> 点击目标 -> 点击确认 的回退路径。
• 只有拖拽本身就是玩法核心语义时，才保留拖拽为主路径并单独设计触控方案。

工作流

1. 确认边界

• 默认采用 PC 优先 + 方向跟随 manifest + 通用 shell 优先。
• 默认不新建 MobileBoard.tsx，不重写第二套移动端 UI。
• 默认不把问题转移到 React Native、Flutter 或原生小程序重写。
• 用户未明确要求时，默认不做完整竖屏布局。
• 用户未明确要求时，默认不做视觉重设计；不要把“适配”扩写成“换一套更像移动 App 的 UI”。

1.5 先锁定桌面验收口径

• 在任何移动端断点尝试之前，先拍或先读当前 PC 主态真图；本项目默认使用 1920x1080 作为桌面对照基线。
• 先回答“这轮桌面端还差什么”再决定是否进入移动端阶段；不能一边桌面端仍明显未收口，一边提前做横屏/窄屏特化。
• 如果桌面端刚接入新资源、新布局或新信息层级，默认先完成桌面 evidence，再开始移动端。
• 若用户明确要求跳过此顺序，必须在汇报里点明“这是按用户明确豁免执行，不是默认流程”。

2. 审查游戏层

先读：

• src/games/<gameId>/manifest.ts
• src/games/<gameId>/Board.tsx
• src/games/<gameId>/ui/

如果用户反馈的是“移动端所有按钮都肥了 / 都缩了 / 多个区域一起异常”，先补读：

• src/index.css
• 相关通用按钮组件、共享布局组件或全局媒体查询入口

优先用 rg 搜这些风险点：

rg -n "hover|onMouse|mouseenter|mouseleave|drag|draggable|pointer|tooltip|sidebar|drawer|panel|absolute|fixed|clamp" src/games/<gameId>

如果怀疑是全局样式污染，再搜：

rg -n "@media|button|min-width|min-height|padding|coarse|hover|clamp" src/index.css src/components src/games/<gameId>

至少记录这些问题：

• hover 依赖：信息、预览、状态说明是否只能悬停查看。
• drag 依赖：关键路径是否只能靠拖拽完成。
• 固定尺寸：是否把桌面尺寸直接压缩到了所有视口。
• 主体画布比例：棋盘 / 地图 / 卡面 / 战区背景是否仍保持等比。
• 常驻侧栏：是否在手机横屏下挡住主战区。
• 信息密度：是否要求用户先缩放再操作。
• 全局样式污染：是否由 src/index.css、共享按钮样式、全局媒体查询或 reset 把多个区域一起改胖 / 改瘦。
• 命中区与视觉混淆：是否把 touch target 要求直接写成了一整类交互元素的可见尺寸变化。
• 根因定位：是否已经定位到具体选择器、共享组件、媒体查询或条件判断，而不是只停留在“看起来变胖 / 变小”。

每个问题必须归类为：

• framework：应沉到通用移动壳或公共 hook。
• game：需要游戏层声明或轻量修正。
• blocked：当前框架能力不足，必须先补框架层。

3. 选定 manifest

不要自创字段名。只使用已批准的字段和值，详见 references/manifest-fields.md。

复杂桌游默认推荐：

mobileProfile: 'landscape-adapted'
preferredOrientation: 'landscape'
mobileLayoutPreset: 'board-shell'
shellTargets: ['pwa']

• 移动端主验收方向必须跟 preferredOrientation 一致；landscape 游戏用横屏作为主验收，portrait 游戏用竖屏作为主验收。
• 不要把“统一横屏”或“统一竖屏”当成通用规则；错误方向视口只能用于旋转提示或降级行为验证。
• 只有 H5 主方向适配和对应 E2E 通过后，才考虑把 shellTargets 扩到 app-webview 或 mini-program-webview。

4. 接入移动端时的正确方式

• 进入本节前，默认视为 PC 门禁已通过；若未通过，只能回到桌面端继续收口。
• 先保持 PC 桌面尺寸 token 不变，再为移动窄视口补一套条件化 token。
• 先排查 src/index.css、共享按钮组件和全局媒体查询，再决定是否真的需要改游戏组件 token。
• 先保证棋盘/地图/卡面等主体画布等比，再谈 HUD、侧栏、说明区怎么让位；不要靠压扁主体画布解决空间问题。
• 如果目标游戏已经使用 board-shell 统一缩放，优先删除或收敛游戏内部移动横屏特化 CSS；不要在 Board 内再写一套顶栏、手牌、分数、主按钮的手机坐标。
• 判断按钮异常时，先看它是否被移动媒体查询从 PC 坐标系中拿出去另排；如果是，根因是“脱离统一缩放体系”，不是按钮本身需要新的右下角布局。
• 尺寸压缩要通过 1023px 视口判断或 shell 条件启用，不能全局覆盖。
• hover 替代入口可以用粗指针判断显隐，但按钮尺寸不能因此误伤桌面端。
• 如果要补触控命中区，优先补“不可见命中区”或显式 opt-in 命中区类，不要直接把可见交互元素做胖。
• 面板折叠、操作轨道、触控替代入口都必须先证明目标对象不是固定牌桌主构图的一部分，再证明“只在移动条件下生效”。
• 对 mobileLayoutPreset: 'board-shell' 的游戏，全屏设置面板、选人/选派系面板、结算面板等如果在 PC 上已有明确布局，移动端主效果默认必须与 PC 保持同构。
• 在该游戏的 preferredOrientation 方向下，优先采用整面板等比缩放，让移动端呈现 PC 布局的缩小版；不要先改成另一套单栏手机稿，再把主操作藏到滚动末端。
• 允许保留 CSS fallback 缩放作为最后兜底，但不能把它当成适配完成。

5. 只做最小必要的游戏层例外

通常只在这些点上写游戏层代码：

• 触屏预览入口。
• 非拖拽备选路径。
• 移动端折叠后仍需保留的核心摘要信息。
• 某些特殊交互的确认顺序、文案或操作轨道排序。

如果某个例外未来大概率会被多个游戏复用，优先回推到框架层。

验收

真实读图门禁（强制）

• 移动端适配验收必须先跑出 test-results/evidence-screenshots/_shared/ 的显式截图，再逐张人工阅读截图内容；只看断言、日志、DOM、locator、控制台输出，一律不算验收完成。
• 任何“先进入教程/调试态，再用 display: none、移除节点、覆盖样式、跳过浮层”的截图都不能作为主状态证据；这类截图默认判定为无效证据。
• 主状态截图必须来自真实目标状态本身，而不是“靠隐藏遮挡物伪装成主状态”的页面。
• 只要截图里仍有教程浮层、调试面板、临时提示、系统菜单、toast、模态层，或任何明显遮挡棋盘/主按钮/关键信息区的大面积覆盖层，这张截图就不能用于宣布移动端通过。
• 最终汇报必须明确写出：
  • 看了哪些截图
  • 每张截图里看到了什么
  • 哪些截图有效，哪些无效
  • 无效原因是什么
• 没有逐张真实看图，就视为没有完成移动端适配验收。

按 references/checklist.md 验收。最低要求：

• 主验收方向下不依赖 hover 也能完成核心回合。
• 玩家能查看手牌、状态、日志、说明，不必先手动缩放。
• 主要按钮达到触控目标尺寸。
• 竖屏要么有明确引导，要么清晰降级。
• PC 前后对比无布局回归、无尺寸基线变化、无主流程退化。
• 对 board-shell 全屏面板，主方向下主要布局结构不变，主操作首屏可见，信息层级与 PC 一致。
• 主体画布保持等比：棋盘 / 地图 / 卡面 / 战区背景不能被压扁、拉长或改变格子比例。
• PC 与移动端都必须核对“交互语义矩阵”：原本的 点击、新增的 长按、hover 替代入口分别是否仍符合预期；禁止只验布局，不验交互退化。
• 先看真实截图再宣布通过：移动端适配不能只因为 E2E 通过、locator 存在或元素在视口内就算验收完成。
• 看图验收是强制项：跑完移动端 E2E 后，必须实际打开 test-results/evidence-screenshots/_shared/ 中的显式截图，逐张阅读；没有逐张看图，就视为没有完成移动端验收。
• 汇报必须基于图片内容：最终结论必须明确写出“看了哪几张图、从图里看到了什么、图里还剩什么问题”；禁止只复述断言、日志或“测试通过”。
• 截图一旦遮挡主状态就判无效：如果主状态图里仍有教程气泡、引导浮层、调试面板、模态框、toast、系统菜单或任何会遮挡棋盘/主按钮/主信息区的大面积覆盖层，这张图不能作为“主状态通过证据”。
• 主状态截图里只要肉眼能看出明显问题，例如棋盘纵向锚点不对、结束回合按钮和棋盘不在同一缩放体系、底部预留空间不匹配、桌面 hover 入口在手机上常驻、关键区域被遮挡或出屏，本轮验收直接判失败。
• 主状态截图里只要肉眼能看出主体画布被压扁、拉长、格子比例失真、卡面比例异常或背景图明显变形，本轮验收直接判失败。
• 必须对照同场景 PC 主态图验收：移动端主状态图不能只和手机/平板彼此互比，必须先拍同一场景的 PC 主态参考图，再逐张对照判断。
• 本项目默认 PC 对照分辨率为 1920x1080：用户未另行指定时，移动端对照截图一律使用 1920x1080 的桌面主态，不再混用 1440x900、1600x900 等非项目基线分辨率。
• 手机横屏验收默认使用 16:9 基线：用户未另行指定时，手机横屏证据与对照默认使用 16:9 视口；禁止再用 812x375 这类超宽横屏把“画面关系不一致”误当成产品问题。
• 判断标准是“和 PC 看起来差不多”：这里指主体画布占比、主 UI 层级、棋盘与阶段区/手牌/结束阶段按钮的相对关系应基本一致；允许移动端做让位与重排，但不能把画面关系改成另一套。
• 对固定牌桌 / board-shell 游戏，“和 PC 看起来差不多”优先解释为同一构图等比缩放；不得把主按钮搬到新 rail、把手牌另缩一套、把顶栏另排一套后再声称只是移动端让位。
• 如果和 PC 对照后仍肉眼可见明显偏离，直接判失败：例如手机主态里棋盘明显比 PC 缩得更小、底部手牌相对更肥、阶段区脱离同一套缩放体系、主画面 framing 明显不同，都不能因为“元素还在视口里”就判通过。

看图验收顺序默认如下：

1. 先看同场景 PC 主态参考图，确认权威布局长什么样；本项目默认该图来自 1920x1080。
2. 再看 test-results/evidence-screenshots/_shared/ 里的手机/平板主状态图，逐张和 PC 对照“整体比例、锚点、遮挡、主次关系”。
3. 先用主状态图判断“整体比例、锚点、遮挡、假 hover”是否过关，再看局部交互截图。
4. 如果首张主状态图被任何浮层遮挡，先判这张图无效，再补拍新的无遮挡主状态图；不要带着无效截图继续宣布通过。
5. 汇报时必须同时写明：看了哪张图、从图里确认了什么、和 PC 比还差什么、是否还有肉眼可见问题。

涉及 UI / 交互修改时，验收必须同时覆盖：

• PC 视口人工对比：确认桌面布局没有被移动端改动带歪。
• H5 移动视口 E2E：至少覆盖 1 个 manifest 主方向手机视口，再按风险补 1 个同方向补充视口（例如平板横屏或更小手机竖屏）。

如已改动 UI，则这轮 E2E 是强制收口项；不能只做人工检查。

输出要求

执行这个 skill 时，最终至少输出：

1. 审查过的文件与风险点。
2. 选定的 manifest 字段值。
3. PC 权威布局与移动条件覆盖的边界。
4. 需要修改的组件列表。
5. PC 验收结果、移动验收结果，或尚未通过的阻塞项。
6. 已补的 E2E 证据，或尚未补齐的缺口。
7. 明确的读图结论：哪些截图有效、哪些截图无效、无效原因是什么。

不要做

• 不要把 WebView 当成“自动获得移动端支持”。
• 不要把小程序 web-view 当成第一个落地方向。
• 不要为了移动端复制一套完整桌面 UI。
• 不要发明另一套 manifest 命名。
• 不要只看宽度压缩，不检查真实交互路径。
• 不要用“全局改小 clamp”去做移动适配。
• 不要在移动媒体查询里给整类交互元素或共享交互组件统一加 min-width / min-height / padding 来放大视觉尺寸。
• 不要接受任何会影响 PC 布局的移动端方案。
• 不要把“补一个长按入口”当成“可以删掉原点击入口”的理由；没有用户明确要求时，移动端适配默认只能增量补入口，不能重写既有交互语义。
• 不要在共享触控 hook、共享 inspect 入口或 coarse pointer 分支里静默吞掉 onClick / inspect / expand 的原有兜底。
• 不要借移动端适配顺手重做视觉风格；没有明确需求时，不改 PC 端的阴影、边框、质感、色彩和整体观感。

2026-03 追加：横向溢出防回归（DiceThrone 试点）

A. 缩放表达式必须返回无单位数字

• 禁止写法：transform: scale(calc(100vw / 1280))。
• 原因：scale() 需要 Number；calc(100vw / 1280) 是长度值，浏览器会把 transform 退化为 none。
• 正确写法：transform: scale(calc(100vw / 1280px))，或先定义变量后使用 scale(var(--mobile-board-shell-scale))。

B. board-shell 缩放选择器默认使用后代命中

• 规则：默认写 [data-game-page... ] .mobile-board-shell，不要默认写 > .mobile-board-shell。
• 原因：MatchRoom / LocalMatchRoom / TestMatchRoom 层级不同，直系子选择器容易漏命中。

C. 缩放壳层内禁止再用 dvh 锁死内部主容器高度

• 规则：在被缩放的壳层内，内部主容器优先使用 h-full，让高度跟随外层 shell。
• 禁止模式：外层 scale + 内层 h-dvh / 100dvh 双重锁高。
• 典型后果：底部出现大块空白，交互区视觉错位。

D. 允许按 gameId 覆盖设计宽度

• 通用默认可用 1280px，复杂游戏允许按 data-game-id 覆盖（例如 DiceThrone 的 940px）。
• 覆盖必须是移动条件下的局部策略，不得改变 PC 设计基线。

E. 移动端 E2E 必须增加布局硬断言

• 除功能断言外，新增以下断言：
  1. documentElement/body/#root 满足 scrollWidth <= innerWidth + 1。
  2. .mobile-board-shell 的 left/right 边界必须落在视口内。
  3. 关键入口（Roll / Confirm / 放大入口）必须位于视口内。
• 没有这些断言时，截图“看起来正常”不能作为布局通过依据。