open-design-game-ui-concept

Open Design 游戏 UI 概念

将 Open Design 用作共享且可检查的设计工作区。将设计生成和运行时实现分为两个阶段：在渲染后的概念经过审查并获批之前，不允许修改运行时 UI。

此技能会协调两个更严格的工作流：

• 生成前使用 open-design-game-ui-handoff，在 preservation-contract.json 中记录当前的视觉标识、动效、源代码锚点和各组件的权威归属；
• 仅在所有者批准后使用 open-design-game-ui-takeover，整合获批的设计方向，同时不损害运行时负责的行为。

阅读 docs/hard-rules/ui-adaptation-upgrade-only-contract.md。Open Design 中的遗漏始终表示 unspecified-preserve-runtime；绝不表示移除现有动画，或用静态占位内容替换动画。

必需工作流

1. 首先阅读 darkbone-visual-language.md，并在浏览器中打开 exemplar-craft.html——它们定义了工艺标准（真实调色板、材质方案和游戏手感检查清单）。然后阅读相关功能文档、当前覆盖层源代码和设计令牌。说明每个屏幕面向玩家的用途。生成目标是打造一件精美的游戏作品，其工艺水平要与范例相当；保留契约只界定边界，不定义设计本身。

2. 提出布局前，捕获实时运行状态：

   node .agents/skills/open-design-game-ui-concept/scripts/capture_meta_ui_design_audit.mjs \
     --base-url=http://127.0.0.1:5173 \
     --out-dir=.omc/artifacts/open-design-meta-ui-audit/<run>
   

   将此操作视为源代码完整性证据，而非尽力而为的图库。若出现页面或控制台错误、渲染图像损坏、区域设置漂移、视口溢出、缺少主要界面或没有可见操作，捕获流程就会阻止继续。它会遍历嵌套的 Shadow DOM，默认运行必须提取所有五个预期的角色骨架。

3. 以实际尺寸审查具有代表性的捕获结果。评估初看时的易理解程度、玩家幻想、层级、空间利用、组件关系、交互距离和细节打磨。阅读 meta-ui-design-contract.md。 对于新的 Steam 标题外壳，使用单独的 steam-title 配置，并阅读 steam-title-design-contract.md。不要更改六屏默认设置，也不要重复使用六屏作品名称。

4. 运行 open-design-game-ui-handoff。在 .handoff/<timestamp>-<feature>/ 下构建一个完整的交接文件夹。包含 README.md、brief.md、DESIGN.md、 preservation-contract.json、source-manifest.json、截图清单、当前状态的 WebP 截图、动效 WebM/MP4 及带时间戳的 WebP 关键帧、选定的真实素材、相关文档，以及负责当前 UI 的源文件。

5. 验证并打包为 zip：

   node .agents/skills/open-design-game-ui-concept/scripts/package_open_design_handoff.mjs \
     --dir=.handoff/<timestamp>-<feature>
   

   打包工具会拒绝绝对路径引用和路径遍历引用。清单中声明的每张截图、每个源文件、每个配置、每个角色素材、每个地图/蒙版素材目录以及主要作品都必须位于交接文件夹内，并且必须包含在最终生成的 zip 中。

6. 将文件夹导入 Open Design 并启动 Codex 运行。先阅读 open-design-control.md。此工作流固定使用 Codex gpt-5.6-sol 和 ultra 推理。不要接受其他模型、较低的推理等级或请求级覆盖。

7. 返回运行 ID 后，立即开始捕获生成证据。捕获流程必须观察实时子进程，然后将成功的结果包绑定到不可变的作品版本：

   node .agents/skills/open-design-game-ui-concept/scripts/capture_open_design_generation_evidence.mjs \
     --run=<run-id> \
     --artifact=<artifact.html> \
     --out=.omc/artifacts/open-design-generation-evidence/<run-id>.json
   

   若实际进程命令中包含 gpt-5.6-sol 以外的模型覆盖，或包含 model_reasoning_effort=ultra 以外的推理覆盖，则证据无效。长时间思考并不代表失败；不要仅仅因为运行需要几分钟就取消健康运行。监听器默认最多等待两小时；只有在有文档说明的运行需要不同限制时，才使用 --timeout-ms=<milliseconds>。

8. 通过 Open Design 的预览 URL 找到生成的作品，然后捕获它：

   node .agents/skills/open-design-game-ui-concept/scripts/capture_open_design_preview.mjs \
     --preview-url=<immutable-preview-url> \
     --contract-profile=<meta-ui|steam-title> \
     --contract=.handoff/<timestamp>-<feature>/preservation-contract.json \
     --generation-evidence=.omc/artifacts/open-design-generation-evidence/<run-id>.json \
     --out-dir=.omc/artifacts/open-design-preview/<run>
   

   默认的 --scenario-set=full 是验收门槛；--scenario-set=defaults 仅用于冒烟测试。完整矩阵在 40 个默认语言环境／视口／屏幕渲染的基础上，增加了详情、锁定、资源不足、加载、确认、结果和完成状态，以及键盘、控制器、悬停、Escape/B、模态框焦点陷阱和减少动态效果探测。

   将 manifest.ok !== true 视为设计运行失败。捕获门禁会独立检查请求的屏幕／语言环境／状态／响应模式是否与可见 DOM 哨兵和本地化主要操作相符，然后检查每个视口的页面／控制台错误、图像加载、文档溢出、祖先元素裁切、标签裁切和可操作元素重叠。手机和 iPad 还要求每个可见的可操作目标至少为 44x44 CSS 像素。

   完整模式会拒绝经过筛选的语言环境／屏幕／视口、可变 URL、不涵盖保留契约的状态集，或与精确项目、修订版、文件和工件 SHA-256 不匹配的生成证据。保留不可变的 projectId、预览 revisionId、工件 SHA-256、契约 SHA-256、生成证据 SHA-256、每张截图的 SHA-256，以及预览清单。接管审批必须绑定到这些确切值；仅有可变 URL 或文件名是不够的。

9. 使用 screenshot-review-artifact 生成中文所有者审阅 HTML。打开 Open Design GUI 项目和审阅 HTML。任何独立／盲审评分都使用 codex exec -m gpt-5.6-sol -c model_reasoning_effort=high（匿名标签）；包含动态效果的工件需基于驱动视频／实时证据评分，并确保每个候选项具有一致性，绝不能只看静态图（参见 open-design-control.md 中的 Review Loop）。

10. 在同一个 Open Design 项目中迭代。在最终清单中保留项目、对话、运行、工件文件、交接 zip、模型、推理和审阅路径。

交接规则

• 每个交接文件夹都必须包含 darkbone-visual-language.md 和 exemplar-craft.html（从此技能的 references 中复制），且 DESIGN.md 必须先阐明创意方向（身份、工艺标准、“匹配范例”），之后才能说明需要保留的内容。简报的第一页如果先列约束，产出的网页仪表板就会显得畏首畏尾——先讲愿景，再讲边界。
• 使用真实渲染的截图，而非根据源代码猜测。
• 保留或提升七个质量维度：身份、构图、信息、交互、动效、材质和可读性。技术矩阵不能推翻肉眼可见的审美退步。
• 为布局、身份、动效、交互、文案和数据分别指定权威来源。默认以运行时为准；数据始终由运行时掌控。
• 如果此任务只更改布局，即使独立版本没有展示当前动画，也要保留现有动画实现和时序。
• 对动效至关重要的界面必须在交接材料中包含基准视频和至少三个带时间戳的关键帧。
• 手机横屏、iPad 横屏、1440 桌面和 1920x1080 Steam 必须视为不同的构图，而不是缩放副本。
• 包含 zh 和 en；每次渲染只使用一种语言。
• 适用时，包含悬停、键盘焦点、手柄焦点、触控、减少动态效果、加载、空状态、锁定、资源不足和破坏性操作确认等行为。
• 保留 Darkbone 的法老石刻哥特式身份。不要把元界面变成普通的网页仪表板。
• 对于拥有角色艺术、地图艺术、面具或成长对象的界面，将其作为主要视觉信号。
• 要求提供一个自包含的 HTML 成品，其中包含六个可切换界面，以及设计契约中定义的评审 API。
• steam-title 配置是六界面成品结构的唯一例外：它返回独立的 bone-halls-steam-title-concept.html，将全部六个元界面保留为仅契约定义的冻结上下文，并捕获完整的标题状态 x 语言环境 x 五视口矩阵。默认配置仍为六界面。
• 设计阶段不要要求 Open Design 编辑运行时源代码。

质量门槛

出现以下任一情况时，拒绝或重新运行该概念：

• 眯眼测试未通过：任何界面看起来都像普通的网页／SaaS 仪表板（扁平圆角卡片、Bootstrap 配色、裸露的左对齐标题、纯 #fff 文字），而非 darkbone-visual-language.md §6-§7 中定义的骨雕鎏金与灵魂青绿祭坛风格；
• 第一眼无法看出界面的用途或主要操作；
• 桌面端大部分视口闲置，或只是拉大手机端的间距；
• 重要图标、角色、地图、节点或面具在桌面端仍是手机端大小；
• 主要按钮变成很长的文字条，而非采用适合桌面端的操作样式；
• 控件在不同视口或语言环境下发生碰撞、偏移或失去分组；
• 概念缺少游戏专属标志、响应式状态模型，或手柄／焦点模型；
• 运行时特征变得普通（例如 Wedjat 之眼变成圆圈），或实时动画变成静态占位内容；
• 当前版本与概念的证据未按视口、状态和动画节拍对齐；
• 成品无法渲染并独立进行截图测试。
• 任意截图断言失败，包括触控目标小于 44x44、视口溢出、页面错误、图像未加载、独立 DOM 哨兵不匹配、输入探测失败、可操作标签被裁切，或可操作控件互相重叠。

此技能的交付物是可供负责人评审的设计成品和证据包。运行时接管属于后续任务。