dsh-plugin-beyond-simulator 2.0.3 → 2.0.5

package/README.md

@@ -1,30 +1,10 @@
 # 千星沙箱模拟器
 
-面向千星奇域 **2D + Lua 脚本驱动的游戏开发**，提供一套在游戏之外运行的模拟工具：执行客户端 Lua 脚本、显示 UI、响应操作，并让 AI 直接试玩游戏。
+面向千星奇域 **2D + Lua 脚本驱动的游戏开发**的独立模拟器：在游戏之外执行客户端 Lua 脚本、显示 UI、响应操作，并让 AI 直接试玩游戏。
 
-你可以在浏览器中编辑界面、调试脚本，也可以让 AI 读取工程、修改控件、点击按钮、发送按键、查看截图与日志，完成“编写 → 试玩 → 检查 → 修改”的开发循环。日常调试无需反复打开游戏和官方编辑器，完成后再导出资产进行真机验证。
-
-## 用 Agent 七步制作游戏
-
-Harness 插件附带“千星 2D+Lua 游戏制作”Agent 预设。新建会话时选择它，提供游戏想法、参考图或已有工程，按下面七步与 Agent 协作完成游戏。
-
-| 步骤 | Agent 会做什么 | 你会得到什么 |
-|---|---|---|
-| **1. 策划案** | 明确核心玩法、操作方式、计分与胜负规则，以及首版功能范围。 | 指导后续制作的游戏策划案。 |
-| **2. TDD 制定测试用例** | 制定测试用例，测试驱动开发；先写清开局、成功、失败、重开及边界情况的操作与预期结果。 | 与策划规则对应、用于驱动实现的测试用例。 |
-| **3. HTML 效果展示** | 制作可以打开试玩的 HTML 演示，与你确认画面、操作和节奏。 | 在正式编码前可以体验和调整的效果展示。 |
-| **4. 准备千星美术参考图和素材** | 根据确认的效果整理或制作参考图，核对可用的千星图片资源与图元，规划素材的使用方式。 | 美术参考图、素材清单和 UI 还原方案。 |
-| **5. Lua 编码实现** | 按策划案和测试用例编写 Lua，搭建 UI、接入素材，在模拟器中逐项实现功能并验证。 | 可以在模拟器运行的 Lua 游戏与完整存档。 |
-| **6. 测试** | 执行测试用例，让 AI 实际操作游戏，检查画面、日志、交互和设备适配，修复问题并回归。 | 测试结果、问题记录与通过模拟器验证的游戏版本。 |
-| **7. 真机试玩验证与 bug 修复** | 导出资产供你在千星奇域中试玩，根据真机回传复现并修复 bug，再验证修复结果。 | 经真机验证的游戏资产、修复记录及尚待处理的问题说明。 |
+提供 **Web 编辑器、MCP 服务和 DeepSeek Harness 插件**三种接入方式，共用同一套模拟器核心。可以独立在浏览器中使用，也可以通过 MCP 接入 OpenCode、WorkBuddy、Codex 等 AI 工具，配合 Web 查看和试玩。
 
-先用策划案和测试用例明确目标，再用 HTML 展示确认体验，随后准备千星美术参考图和素材，进入 Lua 编码与测试。最终交付的是 Lua、完整存档和可导出的游戏资产；真机试玩发现的问题继续进入修复与回归。
-
-可以这样开始：
-
-> 我想做一个适合手机操作的 2D 小游戏：点击躲避障碍，连续成功会加分。请先写策划案并制定 TDD 测试用例，再做 HTML 效果展示。确认后准备千星美术参考图和素材，完成 Lua 编码与测试，最后配合我真机试玩并修复 bug。
-
-已有工程可以从需要补齐的环节继续；玩法变化时同步更新策划案与测试用例，修复 bug 后重新执行相关测试。
+你可以在浏览器中编辑界面、调试脚本，也可以让 AI 读取工程、修改控件、点击按钮、发送按键、查看截图与日志，完成“编写 → 试玩 → 检查 → 修改”的开发循环。日常调试无需反复打开游戏和官方编辑器，完成后再导出资产进行真机验证。
 
 ## 包含什么
 
@@ -35,45 +15,21 @@ Harness 插件附带“千星 2D+Lua 游戏制作”Agent 预设。新建会话
 | **独立试玩窗口** | 启动、暂停、继续和单步运行，通过鼠标、触摸或按键测试交互，查看运行状态、日志和错误。 |
 | **多设备与多玩家模拟** | 在 5 种 PC / 手机画布上检查布局；在本地模拟 1–8 名玩家，切换视角检查变量与信号交互。 |
 | **AI 试玩与自动测试** | 通过工具直接编辑工程、驱动操作、获取截图；记录操作时间线，回放用例并检查控件、变量和日志。 |
-| **游戏制作 Agent** | 从策划案与测试用例出发，展示 HTML 效果、准备千星美术素材，再完成 Lua 编码、测试与真机反馈修复。 |
+| **七步游戏制作工作流** | 从策划案与测试用例出发，展示 HTML 效果、准备千星美术素材，再完成 Lua 编码、测试与真机反馈修复。 |
 | **存档与资产交换** | 用完整 JSON 存档保存工程，导入导出 UI、Lua 脚本及已支持的 GIA 内容，衔接后续编辑与交付。 |
 
 ## 集成方式
 
-按你的开发环境选择一种接入方式，也可以组合使用：
+按你的开发环境选择接入方式。Web 可以独立使用；让 AI 直接编辑和测试工程时使用 MCP；需要边对话边看画面时组合 MCP + Web：
 
 | 方式 | 适合谁 | 使用体验 |
 |---|---|---|
-| **DeepSeek Harness 插件** | 希望在 AI 对话中完成游戏开发的人 | 在 Harness 内打开编辑器，让 Agent 操作同一份工程并试玩。 |
-| **Web 部署** | 希望直接在浏览器中编辑、调试的人 | 启动一个包含前后端的服务，通过浏览器编辑和试玩，无需 Harness。 |
-| **MCP 接入** | 使用其他支持 MCP 的 AI 客户端的人 | 向 AI 提供工程编辑、试玩、截图和保存工具，可配合 Web 查看结果。 |
+| **[Web 编辑器](#web-部署)** | 在浏览器中编辑、调试，或配合外部 AI 工具查看结果 | 独立运行 UI/Lua 编辑器与试玩窗口，预览磁盘中的工程存档。 |
+| **[MCP 服务](#mcp-接入)** | 使用 OpenCode、WorkBuddy、Codex 等支持本地 MCP stdio 的 AI 工具 | 向 AI 提供工程编辑、试玩、截图和保存工具，可独立使用或配合 Web。 |
+| **[DeepSeek Harness 插件](#deepseek-harness-插件)** | 使用 DeepSeek Harness | 在 Harness 内嵌编辑器、注册模拟器工具，并提供 Skill 与 Agent 预设。 |
 
 三个包已发布到 npm，也可从 GitHub 源码或本地构建的 `.tgz` 安装。Web 包名和启动命令均为 `beyond-simulator-web`。本地安装包路径以仓库根目录为基准；当前版本及文件名见 `release/manifest.json`。
 
-### DeepSeek Harness 插件
-
-准备 Node.js 22+ 和 DeepSeek Harness，选择下面一种安装方式。GitHub 安装还需要 Git，会自动从源码构建；本地安装包路径以仓库根目录为基准，可按文末的[构建说明](#从源码构建)生成，文件名以 `release/manifest.json` 为准。
-
-```sh
-# 从 npm 安装
-dsh plugin --profile web add dsh-plugin-beyond-simulator
-# 或，从 GitHub 默认分支源码安装
-dsh plugin --profile web add github:1475505/miliastra-beyond-simulator
-# 或，从本地安装包安装
-dsh plugin --profile web add ./release/dsh-plugin-beyond-simulator-1.0.10.tgz
-
-dsh --profile web --dump-config
-dsh web
-```
-
-为会话绑定游戏项目工作区，打开“模拟器”视图，即可编辑 UI 和 Lua 并启动试玩。插件同时提供模拟器操作 Skill，以及“千星 2D+Lua 游戏制作”Agent 预设；新建会话时可以选择该预设。
-
-更新已有插件时，执行同一条安装命令，再重启 Harness。已有的用户 Agent 预设会保留，不会随插件升级自动覆盖。
-
-安装配置与工具说明见 [Harness 插件指南](dsh-plugin/README.md)。
-
-GitHub 安装使用仓库默认分支，安装时由 `prepare` 自动构建。首次安装若 pnpm 提示需要批准构建，请按提示允许该插件的构建脚本，再重新执行安装命令。安装入口是整个仓库，不需要指定子目录。详见 [分发说明](DISTRIBUTION.md#harness-安装入口)。
-
 ### Web 部署
 
 准备 **Node.js 22+**，从 npm 安装后即可启动完整前后端：
@@ -103,7 +59,7 @@ Web 也支持安装预构建包运行，仓库提供了 Docker 部署配置。
 
 ### MCP 接入
 
-在支持本地 MCP stdio 服务的 AI 客户端中配置模拟器，指定游戏工作区后，AI 即可打开、编辑和保存工程，控制试玩并获取画面。
+在 OpenCode、WorkBuddy、Codex 等支持本地 MCP stdio 服务的 AI 工具中配置模拟器，指定游戏工作区后，AI 即可打开、编辑和保存工程，控制试玩并获取画面。各客户端的配置入口和格式不同，共用以下服务命令与参数：
 
 从 npm 安装：
 
@@ -111,12 +67,72 @@ Web 也支持安装预构建包运行，仓库提供了 Docker 部署配置。
 npm install -g beyond-simulator-mcp
 ```
 
-然后在客户端中将服务命令设为 `beyond-simulator-mcp`，参数设为 `--workspace` 和已有游戏目录的绝对路径。
+然后在客户端中添加本地 stdio 服务：
+
+| 配置项 | 值 |
+|---|---|
+| 服务名（自定） | `qxqy-simulator` |
+| 命令 | `beyond-simulator-mcp` |
+| 参数 | `--workspace`、已有游戏目录的绝对路径，例如 `E:/my-game` |
+
+客户端配置可参考 [OpenCode MCP 文档](https://opencode.ai/docs/mcp-servers/)、[WorkBuddy MCP 连接器文档](https://open.workbuddy.cn/docs/connector)及本仓库的 [Codex 配置示例](mcp/README.md#codex-接入)。接入后先检查 `qxqy_project_open`、`qxqy_studio_play` 等工具是否可见；安装 MCP 包不会自动安装游戏制作 Skill。
+
+MCP 可以独立使用。组合 Web 时，让两者的 `--workspace` 指向同一个本地目录：AI 用 MCP 修改工程并显式保存 JSON，Web 的“存档预览”重新加载当前文件，用户在浏览器中查看和试玩。切换到另一份存档时可调用 `qxqy_preview_open`。Web 编辑器中的未保存草稿不会被自动覆盖。
 
-MCP 可以独立使用。需要同时看画面时，让 Web 指向同一个工作区，打开“存档预览”；AI 保存 JSON 后，预览会自动更新。Web 编辑器中的未保存草稿不会被自动覆盖。
+只使用 Web 时，AI 也可以在工作区编辑 Lua 和工程文件，由用户在 Web 中加载检查；能否直接操作网页取决于 AI 客户端实际提供的浏览器工具。Web 服务本身不注册 MCP 工具。
 
 安装方式、客户端配置和工具示例见 [MCP 接入指南](mcp/README.md)。
 
+### DeepSeek Harness 插件
+
+准备 Node.js 22+ 和 DeepSeek Harness，选择下面一种安装方式。GitHub 安装还需要 Git，会自动从源码构建；本地安装包路径以仓库根目录为基准，可按文末的[构建说明](#从源码构建)生成，文件名以 `release/manifest.json` 为准。
+
+```sh
+# 从 npm 安装
+dsh plugin --profile web add dsh-plugin-beyond-simulator
+# 或，从 GitHub 默认分支源码安装
+dsh plugin --profile web add github:1475505/miliastra-beyond-simulator
+# 或，从本地安装包安装
+dsh plugin --profile web add ./release/dsh-plugin-beyond-simulator-1.0.10.tgz
+
+dsh --profile web --dump-config
+dsh web
+```
+
+为会话绑定游戏项目工作区，打开“模拟器”视图，即可编辑 UI 和 Lua 并启动试玩。插件同时提供模拟器操作 Skill，以及“千星 2D+Lua 游戏制作”Agent 预设；新建会话时可以选择该预设。
+
+更新已有插件时，执行同一条安装命令，再重启 Harness。已有的用户 Agent 预设会保留，不会随插件升级自动覆盖。
+
+安装配置与工具说明见 [Harness 插件指南](dsh-plugin/README.md)。
+
+GitHub 安装使用仓库默认分支，安装时由 `prepare` 自动构建。首次安装若 pnpm 提示需要批准构建，请按提示允许该插件的构建脚本，再重新执行安装命令。安装入口是整个仓库，不需要指定子目录。详见 [分发说明](DISTRIBUTION.md#harness-安装入口)。
+
+## 用 Agent 七步制作游戏
+
+仓库提供可供 AI 按需读取的[七步制作 Skill](agent/wonderland-lua-builder/skills/qxqy-game-studio/SKILL.md)。提供游戏想法、参考图或已有工程后，AI 按当前步骤读取对应 Markdown，逐步完成制作。
+
+在 OpenCode、WorkBuddy、Codex 等工具中，可让 AI 读取该 Skill 和随附的 `references/`，并通过 MCP 操作模拟器；在 Harness 中，可直接选择插件附带的“千星 2D+Lua 游戏制作”Agent 预设。工作流内容和 Harness 注册配置分开维护，接入方法见 [Agent / Skill 使用说明](agent/wonderland-lua-builder/README.md)。
+
+启动制作时，AI 先检查工作区和当前 AI 工具配置中的 `miliastra-toolbox` 系列、其他知识库服务或本地资料，确认能否读取所需的官方 2D/Lua API 文档与使用指南。已有资料直接复用，只在缺项时提示补充；具体规则见[启动前知识库检查](agent/wonderland-lua-builder/skills/qxqy-game-studio/references/workflow.md#知识库发现与可用性核验)。模拟器安装包不捆绑官方知识库。
+
+| 步骤 | Agent 会做什么 | 你会得到什么 |
+|---|---|---|
+| **1. 策划案** | 明确核心玩法、操作方式、计分与胜负规则，以及首版功能范围。 | 指导后续制作的游戏策划案。 |
+| **2. TDD 制定测试用例** | 制定测试用例，测试驱动开发；先写清开局、成功、失败、重开及边界情况的操作与预期结果。 | 与策划规则对应、用于驱动实现的测试用例。 |
+| **3. HTML 效果展示** | 制作可以打开试玩的 HTML 演示，与你确认画面、操作和节奏。 | 在正式编码前可以体验和调整的效果展示。 |
+| **4. 准备千星美术参考图和素材** | 根据确认的效果整理或制作参考图，核对可用的千星图片资源与图元，规划素材的使用方式。 | 美术参考图、素材清单和 UI 还原方案。 |
+| **5. Lua 编码实现** | 按策划案和测试用例编写 Lua，搭建 UI、接入素材，在模拟器中逐项实现功能并验证。 | 可以在模拟器运行的 Lua 游戏与完整存档。 |
+| **6. 测试** | 执行测试用例，让 AI 实际操作游戏，检查画面、日志、交互和设备适配，修复问题并回归。 | 测试结果、问题记录与通过模拟器验证的游戏版本。 |
+| **7. 真机试玩验证与 bug 修复** | 交接导入与脚本挂载，协助校准真实索引、绑定脚本更新目录，再根据真机回传修复和回归。 | 游戏资产、导入与后续更新说明、真机结果及待处理项。 |
+
+先用策划案和测试用例明确目标，再用 HTML 展示确认体验，随后准备千星美术参考图和素材，进入 Lua 编码与测试。最终交付的是 Lua、完整存档和可导出的游戏资产；真机试玩发现的问题继续进入修复与回归。
+
+可以这样开始：
+
+> 我想做一个适合手机操作的 2D 小游戏：点击躲避障碍，连续成功会加分。请先写策划案并制定 TDD 测试用例，再做 HTML 效果展示。确认后准备千星美术参考图和素材，完成 Lua 编码与测试，最后配合我真机试玩并修复 bug。
+
+已有工程可以从需要补齐的环节继续；玩法变化时同步更新策划案与测试用例，修复 bug 后重新执行相关测试。
+
 ## 使用指南
 
 ### 1. 准备工程
@@ -127,7 +143,7 @@ MCP 可以独立使用。需要同时看画面时，让 Web 指向同一个工
 - 继续已有工程：从顶栏“工作区存档”选择已保存的项目，或点击“导入”打开本地文件。
 - 迁入现有资产：导入支持的 UI JSON、GIA 或 Lua，再检查布局和脚本挂载关系。
 
-编写 Lua 时，请让 AI 同时参考工作区中的千星 2D/Lua API 文档；模拟器安装包不包含官方知识库。需要从参考图制作美术时，也可以配合工作区已有的像素画、图元拟合、UI 制作或帧动画 Skill。
+编写 Lua 时，AI 使用启动前已经核验的知识来源，按当前需求读取官方 API、指南和实战经验；“已配置知识库”还需核实当前会话能否读取所需资料。需要从参考图制作美术时，也可以配合工作区已有的像素画、图元拟合、UI 制作或帧动画 Skill。
 
 ### 2. 编辑并试玩
 
@@ -162,6 +178,14 @@ AI 可以直接获取工程状态、发送输入、读取日志和截图，无
 
 编辑和试玩不会自动把完整存档写入磁盘。Web 用户请显式保存，Harness 用户可导出 JSON，MCP 用户可让 AI 调用保存工具；关闭服务前先保存未完成的工作。
 
+### 5. 导入真机并持续更新
+
+首次交付时，AI 会根据工程给出需要导入的文件、脚本映射与挂载位置，以及试玩步骤。你需要在千星沙箱完成导入，核对实际控件/模板索引；索引变化可通过对话告知 AI，或在模拟器中修改后让 AI 同步脚本。直接手改脚本时也应将最终修改同步回工程。
+
+后续更新可以在 Web/DSH 的“Lua 脚本 → 实机脚本同步”绑定该关卡导入后的脚本目录。AI 准备修改并预览差异，你检查目标路径、选择文件并确认复制，然后在千星沙箱保存并重新试玩。目录绑定随完整存档保存，便于下次复用；新增脚本仍需建立映射和必要挂载。
+
+如果模拟器服务无法访问游戏所在电脑的目录，可按交付说明手动更新。完整分工见 [真机交付与验证](agent/wonderland-lua-builder/skills/qxqy-game-studio/references/07-device-validation.md)，目录配置与复制说明见 [实机脚本同步](studio/docs/script-sync.md)。
+
 ## 当前支持边界
 
 - **模拟器通过不等于真机通过。** 它用于提前发现脚本、布局和交互问题，最终仍需在千星奇域中验证。

package/dsh-plugin/cordis.patch.yml

@@ -20,9 +20,10 @@
           # standing scope; every session naming it joins by scope parentage. The host
           # composition keeps the registries, sandbox, approval stack, persistence, and
           # the model route. Simulator Tools come from `dsh-plugin-beyond-simulator`.
-          # 2D Lua knowledge is the user's workspace (AGENTS.md / knowledge docs they
-          # place when creating the agent workspace). Do not bundle a corpus in this
-          # preset and do not route through miliastra-knowledge (3D sandbox nodes).
+          # 2D Lua knowledge comes from the user's knowledge plugin or local workspace.
+          # Discover configured miliastra-toolbox variants, other knowledge sources,
+          # and local Lua API docs before asking the user to add documentation.
+          # Do not bundle a corpus or route through miliastra-knowledge (3D sandbox nodes).
           #
           # A service row here MUST sit inside a group carrying an `isolate` realm.
 
@@ -34,7 +35,7 @@
               prefix: |-
                 You are a 千星奇域 2D+Lua game studio director powered by the {{model}} model. Your working directory is {{cwd}}.
 
-                You make playable UI+Lua games for 原神千星奇域 (Miliastra Wonderland): client UI controls, client Lua, and a thin server of custom variables/signals. You are not a 3D level-graph designer. Load `qxqy-game-studio` before creating, changing, reviewing, or polishing a game, then load only the stage skills it routes to. Read 2D API and observed pitfalls from the current workspace (AGENTS.md and knowledge docs the user placed there). Never use `miliastra-knowledge` for 2D UI+Lua and never invent official APIs, imageIds, GIA fields, or simulator support. If the workspace has no API docs, ask the user to add them before writing Lua that depends on editor APIs.
+                You make playable UI+Lua games for 原神千星奇域 (Miliastra Wonderland): client UI controls, client Lua, and a thin server of custom variables/signals. You are not a 3D level-graph designer. Load `qxqy-game-studio` before creating, changing, reviewing, or polishing a game, then read its PREFLIGHT/recovery reference and only the Markdown reference for the current step. Read another step only when transitioning or resolving missing evidence; do not preload all seven references. Load supporting skills only as needed. Follow PREFLIGHT to inspect workspace guidance and the current AI host's relevant plugin/MCP/Skill configuration and available tools for miliastra-toolbox variants, other knowledge services, and local documentation. Verify access to the required official client 2D/Lua API docs and usage guides, record the source and available version, and reuse it before asking for missing material. Configured, callable/readable, and sufficient API coverage are separate states; unavailable configuration does not prove no knowledge base exists. Inspect only relevant configuration and never echo credentials. Read observed pitfalls and follow workspace AGENTS.md. Never use `miliastra-knowledge` for 2D UI+Lua and never invent official APIs, imageIds, GIA fields, or simulator support. If the discovered sources still lack required API docs, ask only for the missing content or connection before writing Lua that depends on editor APIs.
 
                 Keep one current step after PREFLIGHT: (1) game design document, (2) TDD test cases before production code, (3) playable HTML effect showcase, (4) Miliastra art reference images and assets, (5) Lua implementation in the simulator, (6) simulator testing and fixes, (7) real-device play validation and bug fixes. Follow this order for new games. Existing projects resume from the earliest missing evidence; narrow fixes need not repeat unrelated steps.
 
@@ -44,6 +45,10 @@
 
                 First milestone is one complete game session. Saves: workspace/<slug>/<slug>.save.json with qxqy-simulator-save near the file head. Simulator green is not ship. Ask the user only for meaningful design or experience decisions, art direction forks, and real-device observations. Inspect the repo and tools yourself.
 
+                When GIA import remaps client control indices, follow the qxqy-simulator index workflow: inspect controlGuidChanges, update the relevant semantic references in saved script sources and corresponding Lua files, then acknowledge only verified changes, save, and restart playtests. A control GUID change alone is incomplete; do not blindly replace equal numbers or confuse template indices with runtime control IDs.
+
+                In step 7, prepare project-specific import, script mapping/mount, real index calibration, and script update instructions. Reuse confirmed device information. Offer binding the imported script directory for later updates; AI prepares source fixes, saved configuration, and diffs, while the user checks and confirms copying in the simulator editor, then saves and playtests in the real editor. Reconcile manual script edits back into the project before later updates. Binding a directory or copying files is not proof the game loaded the new code; follow the step 7 reference for handoff and verification.
+
                 Maintain a living tech-architecture doc (docs/tech-architecture.md) throughout development, in the spirit of Karpathy's llm.c dev wiki: module breakdown, what each Lua file, client control/container, and server variable/signal is responsible for, key data flow and mount points. Update it with every structural change — it is the operability manual after delivery, and stale entries are worse than none.
 
           - id: agent-instructions
@@ -124,7 +129,7 @@
 
                         Resolve discoverable facts by inspection. Use ask_user_question only for user-owned choices or material ambiguity that inspection cannot answer. Do not ask the user where code lives or how current behavior works when you can find out.
 
-                        For 千星奇域 games, plan the seven-step workflow in order: (1) 策划案, (2) TDD 制定测试用例, (3) HTML 效果展示, (4) 准备千星美术参考图和素材, (5) Lua 编码实现, (6) 测试, (7) 真机试玩验证与 bug 修复. Steps 1–4 do not use the simulator; first valid TDD Red comes after a runnable Lua skeleton exists in step 5. The ship artifact is a game that runs in the simulator and on device, not HTML. Never translate DOM/CSS/JS to Lua, never copy HTML coordinates (top-left) into 千星 (bottom-left, Y up). Official imageIds are allowed; simulator missing-box is a preview limit. Cover the three-asset split, workspace/<slug>/<slug>.save.json, canvases, budgets, GIA warnings, and real-device pass. Route Lua/API through workspace knowledge docs the user provides, never miliastra. State entry/exit evidence and rollbacks so another engineer need not invent design.
+                        For 千星奇域 games, plan the seven-step workflow in order: (1) 策划案, (2) TDD 制定测试用例, (3) HTML 效果展示, (4) 准备千星美术参考图和素材, (5) Lua 编码实现, (6) 测试, (7) 真机试玩验证与 bug 修复. Steps 1–4 do not use the simulator; first valid TDD Red comes after a runnable Lua skeleton exists in step 5. The ship artifact is a game that runs in the simulator and on device, not HTML. Never translate DOM/CSS/JS to Lua, never copy HTML coordinates (top-left) into 千星 (bottom-left, Y up). Official imageIds are allowed; simulator missing-box is a preview limit. Cover the three-asset split, workspace/<slug>/<slug>.save.json, canvases, budgets, GIA warnings, and real-device pass. Route Lua/API through sources actually discovered and verified during PREFLIGHT (configured miliastra-toolbox variants, other knowledge services, or local docs), never the 3D miliastra-knowledge skill. State entry/exit evidence and rollbacks so another engineer need not invent design.
 
                         When ready, call exit_plan_mode with the complete plan markdown, starting with a # title. Make exit_plan_mode the only and final tool call in that assistant response: it presents the plan for approval, and implementation begins only in a later step after approval. Do not paste the final plan as a plain reply or ask "should I proceed?" through prose or ask_user_question. If review rejects it, incorporate the feedback and present again. If the review channel is unavailable or aborted, stay in plan mode and ask the user to switch modes manually; do not proceed with implementation.