zenstory-ai/novel-to-game

Before Instructions only → After Instructions only

9dddcd2dfdf0 → 48226e391b31

- 3 description: "Direct game art and creative vision. Turn GAME_DESIGN into ART_DIRECTION defining a recognizable visual identity, functional visual and audio feedback, and key in-game moments. Use for what should the game look like, set the art direction, define the visual style. 游戏美术与创意方向。把 GAME_DESIGN 转成 ART_DIRECTION，定义可辨识的视觉身份、服务玩法的视听反馈和关键游戏时刻。用于判断游戏应该长什么样、制定游戏美术方向等需求。"
+ 3 description: "Direct game art and creative vision. Turn GAME_DESIGN into ART_DIRECTION defining a recognizable visual identity, functional visual and audio feedback, and key in-game moments. Use for what should the game look like, set the art direction, define the visual style. 游戏美术与创意方向。把 GAME_DESIGN 转成 ART_DIRECTION，定义可辨识的视觉风格、服务玩法的视听反馈和关键游戏时刻。用于判断游戏应该长什么样、制定游戏美术方向等需求。"
- 7 定义玩家最终看见、听见和读懂的体验；资产怎样生产、使用什么渲染库、模型或供应商由构建阶段决定。
+ 7 定义玩家在游戏里看见、听见和读懂的视听体验；至于资产用什么工具生产、采用哪个渲染库或调用哪家模型，留给构建阶段决定。
- 9 读取 [art-direction-method.md](references/art-direction-method.md)。必须已有 `GAME_DESIGN.md` 与
- 10 `PRODUCT_BRIEF.md`；视觉服务玩法，不能用漂亮参考图重写游戏。
+ 9 读取 [art-direction-method.md](references/art-direction-method.md)。输入必须包含 `GAME_DESIGN.md` 与 `PRODUCT_BRIEF.md`；视觉表现服务于玩法决策，不得为了迁就好看的参考图而改写玩法规则。
- 14 继承目标平台、视口/朝向、画风、内容尺度、`targetFinish` 与 `experienceProfile`。视觉参考只借
- 15 声明的构图、材质、色光或信息原则，不复制他作角色、地图、界面和资产。原作文化与目标市场分别
- 16 研究，不用流行刻板符号替代原作身份。
+ 13 直接继承目标平台、视口与屏幕朝向、画风、`targetFinish`、内容尺度与 `experienceProfile`。视觉参考只借鉴已声明的构图、材质、色光或信息层级，不得照搬其他作品的角色、地图、界面与美术资产。原著文化背景与目标发行市场分开考证，不用泛化的流行刻板符号替代原著自身的时代与文化气质。
- 20 1. 定义能区分正确与错误方案的视觉原则；身份与审美校准见参考方法同名一节；
- 21 2. 为玩家、目标、威胁、奖励和地标建立镜头、焦点、轮廓、尺度与密度语法；
- 22 3. 让颜色、光、材质和运动编码真实状态，并提供不依赖颜色的提示、低动效表达与清晰的明度对比；
- 23 4. 定义首屏焦点、HUD 信息层级、输入反馈、结果分级、失败与结果状态；
- 24 5. 为环境、角色、交互物和关键道具定义共享世界语法与各自识别锚点；
- 25 6. 定义目标语言的字体覆盖、阅读顺序、文本密度与文化符号边界；
- 26 7. 为核心循环或最高视觉风险定义关键游戏时刻，说明玩家动作、压力、焦点和前后状态；
- 27 8. 定义声音世界、功能反馈层级和音乐边界；语音只在确有独特价值时选择，并始终保留字幕/静音路径。
+ 17 1. 确立能明确区分“符合本作”与“偏离本作”的核心视觉原则（校准方法见参考文档「身份与审美校准」）；
+ 18 2. 为主角、目标点、威胁、奖励和场景地标建立清晰的镜头机位、视觉焦点、剪影轮廓、体型比例与画面疏密规则；
+ 19 3. 让色彩、光影、材质和动效准确传达真实游戏状态，同时提供不依赖颜色辨识的图形提示、低动效替代方案与充足的明暗对比度；
+ 20 4. 明确首屏视觉重心、HUD 信息层级、操作即时反馈、结果强弱分级、失败提示与结算画面；
+ 21 5. 为场景环境、角色造型、可交互物和关键道具制定统一的视觉语言与各自的标志性识别特征；
+ 22 6. 规定目标语言的字体覆盖、阅读视线顺序、单屏字数上限与文化符号使用边界；
+ 23 7. 针对核心玩法循环或视觉风险最高的环节定义「关键游戏时刻」，写清当下玩家操作、局势压力、画面焦点及操作前后的画面变化；
+ 24 8. 设定声音风格、功能音效层级和配乐边界；仅在确有独特体验价值时启用角色配音，且全程保证纯字幕与静音模式下可正常游玩。
- 29 `narrative-led` 或 `hybrid` 的叙事层还要说明人物距离、朝向、遮挡和姿态如何表现关系变化，以及对白区
- 30 怎样保证阅读、历史回看、跳过与加速。
+ 26 `narrative-led` 或 `hybrid` 项目的叙事层还需说明：人物站位距离、朝向、前景遮挡与肢体姿态如何外化人物关系变化，以及对话框区域如何兼顾顺畅阅读、历史回看、跳过与快进。
- 32 不要写着色器、拓扑、贴图规格、接口、文件格式教程或供应商参数。
+ 28 不要在美术方向文档里写着色器代码、模型拓扑、贴图分辨率参数、API 接口、文件格式教程或供应商调用配置。
- 38 - `targetFinish` 与视觉原则；
- 39 - 镜头/构图、世界/角色/道具语法、功能性色光材质；
- 40 - HUD、反馈、运动/转场、语言/文化与声音方向；
+ 34 - `targetFinish` 与核心视觉原则；
+ 35 - 镜头构图、世界/角色/道具视觉语言、服务玩法的色光与材质规则；
+ 36 - HUD 布局、操作反馈、动效与转场、语言文化规范及声音方向；
- 42 - 必需与可降级资产，以及原创/授权边界和仍未确定的视觉风险。
+ 38 - 必需资产与可降级资产清单、原创与授权边界，以及尚待验证的视觉风险。
- 44 是否追加 `design/VISUAL_TARGETS.md` 与少量持久目标图，条件见方法「关键游戏时刻与目标图」。
+ 40 是否额外产出 `design/VISUAL_TARGETS.md` 及少量目标样张，按参考文档「关键游戏时刻与目标图」的条件决定。
- 46 交付前在目标视口检查动作、压力与反馈可辨；关键时刻在实际界面而非概念海报中成立；
- 47 方向覆盖核心循环、失败和结果，构建无需重新发明风格或反馈，但仍保有实现自由。
+ 42 交付前在目标视口尺寸下核查：玩家操作、局势压力与状态反馈是否一眼可辨；关键游戏时刻是否在真实的带 UI 游戏画面中成立（不能拿概念宣传海报顶替）；美术规范是否完整覆盖核心循环、失败与结局，让构建阶段无需自行揣测画风或反馈形式，同时保有所需的工程实现自由。

Compare on GitHub

Before Not checked yet → After Instructions only

First observation → 9dddcd2dfdf0

No earlier version was observed for comparison.

Compare on GitHub

Before Instructions only → After Instructions only

9dddcd2dfdf0 → 48226e391b31

- 3 description: "Build a risk-matched whitebox or the approved production game for its target runtime. Turn GAME_DESIGN, and ART_DIRECTION when production begins, into a minimal BUILD_BRIEF and a runnable candidate that can be iterated with replayable evidence. Use for prototype the riskiest design question, implement the approved game design, or turn this design into a running game. 游戏构建执行。先按最大风险做白盒，或在正式生产时把批准后的 GAME_DESIGN 与 ART_DIRECTION 压缩成最小 BUILD_BRIEF，在目标运行环境中实现可运行候选并用可回放证据迭代。用于验证高风险设计问题、构建游戏原型或实现批准方案。"
+ 3 description: "Build a risk-matched whitebox or the approved production game for its target runtime. Turn GAME_DESIGN, and ART_DIRECTION when production begins, into a minimal BUILD_BRIEF and a runnable candidate that can be iterated with replayable evidence. Use for prototype the riskiest design question, implement the approved game design, or turn this design into a running game. 游戏构建执行。先针对头号设计风险搭建白盒原型，或在正式生产时将已批准的 GAME_DESIGN 与 ART_DIRECTION 提炼为精简的 BUILD_BRIEF，在目标运行环境中实现可运行版本并用可复现的实机记录迭代。用于验证高风险设计问题、构建游戏原型或实现已批准的设计方案。"
- 7 保护已批准的体验边界；正式生产时再保护已批准的美术边界。驱动实现模型完成真实可玩的候选，不在
- 8 构建阶段重新做概念、关卡或美术方向。
+ 7 守住已批准的体验设计边界（正式生产阶段同时守住已批准的美术方向），驱动代码实现产出真实可玩的构建版本，不在构建阶段私自重做概念选型、关卡设计或美术方向。
- 10 读取 [build-brief-contract.md](references/build-brief-contract.md)。白盒阶段必须已有 `GAME_DESIGN.md`；
- 11 完整候选还必须已有 `ART_DIRECTION.md`。缺产品决定时回对应 owner，不在 BUILD_BRIEF 就地发明。
+ 9 读取 [build-brief-contract.md](references/build-brief-contract.md)。白盒阶段必须已有 `GAME_DESIGN.md`，正式生产阶段还必须已有 `ART_DIRECTION.md`；若发现上游产品或设计决策缺失，退回对应负责环节补齐，不在 `BUILD_BRIEF.md` 里临时拍脑袋发明。
- 17 按 PRODUCT_BRIEF 锁定的平台、生产引擎、目标运行时、显示/输入、范围、分级和联网边界交付。
- 18 目标工具链不可用时不得自动改做网页；只有 brief 已批准替代运行时才可使用，并分开记录
- 19 `targetRuntime`、`testedRuntime` 与未覆盖项。
+ 15 严格按 `PRODUCT_BRIEF.md` 锁定的目标平台、生产引擎、运行环境、显示与输入方式、项目范围、内容分级和联网边界交付。当目标工具链在当前环境不可用时，不得擅自改做成网页版顶替；只有在 `PRODUCT_BRIEF.md` 明确批准了替代运行环境时才可使用，且必须分别记清 `targetRuntime`、`testedRuntime` 与尚未覆盖的目标平台特性。
- 21 正式生产继承 `ART_DIRECTION.md` 的可观察视觉约束与批准目标图，在实际运行中验证焦点资产。
+ 17 正式生产阶段继承 `ART_DIRECTION.md` 的视觉约束与已批准的目标图，并在实机运行画面中逐项核验核心资产。当正式生产需要新绘位图且项目内无合适现成素材时，直接调用当前环境的图像生成工具（在 Codex 环境中优先使用内置 ImageGen）；已有的成套图标与适合用代码绘制的简洁几何图形可继续复用。生成的成品文件必须落盘保存到项目目录并接入真实游戏界面，不得拿文字徽章、Emoji 或未执行的生成提示词冒充已完工美术；白盒阶段的临时占位图须明确标明阶段属性。
- 23 BUILD_BRIEF 只压缩产品边界、必须保真的体验事实、运行方式与完成证据，实现细节交给实现模型。
+ 19 `BUILD_BRIEF.md` 只提炼产品边界、必须保真的核心体验事实、启动与验证命令以及完成证据，具体代码组织方式交由实现模型自主决定。
- 25 先声明 `buildStage: whitebox|production` 与 `buildPath: template|custom`。已有交互语法只有在能保留原作
- 26 独有动作、代价和世界回应时才采用；实时手感、空间、视线、物理或模板覆盖不了的核心动词走 custom。
- 27 白盒也必须选择能验证最大风险的形态，不能把所有项目降成文游。
+ 21 构建前先声明 `buildStage: whitebox|production` 与 `buildPath: template|custom`。只有在成熟交互模板能够完整保留原著独有的动作、代价和世界反馈时，才可走 `template`；凡是核心体验依赖实时操作手感、空间走位、视线遮挡、物理碰撞或现有模板覆盖不了的独创动词，一律走 `custom`。白盒阶段同样必须选用能真实检验最大设计风险的交互形态，绝不能把所有项目都降级成纯文字选项游戏。
- 29 当前会话能编码时直接实现；外部模型不可用时只交付构建说明，不声称游戏已生成。不要发送与原型
- 30 无关的完整受版权保护原文。
+ 23 若当前会话具备代码与资产实现能力则直接动手构建，否则调用其他可用的实现工具；若确实没有任何可用实现途径，如实报告阻塞原因并交付构建说明文档，绝不谎称可玩版本已生成。调用外部工具时，切勿上传与当前原型无关的受版权保护原著全文。
- 32 ## 按能力读取可选合同
+ 25 ## 按需读取专项规范
- 34 - 已选择 Blender 制作或修改可编辑三维资产时，读取 [blender-asset-workflow.md](references/blender-asset-workflow.md)；
- 35   不因项目是 3D 就默认采用 Blender 或安装 MCP。
- 36 - 采用生成式自由输入、知识权限、事件回放、存档迁移或 `signature_command` 时，读取
- 37   [playable-model-contract.md](references/playable-model-contract.md) 的相关部分。
- 38 - 语音策略不是 `none` 时读取 [tts-production-contract.md](references/tts-production-contract.md)。
- 39 - 实际采用动态媒体时读取 [generative-media-pipeline.md](references/generative-media-pipeline.md)。
- 40 - 2.5D 角色或物件需要多方向、多动作且身份一致的序列帧时，读取
- 41   [baked-sprite-workflow.md](references/baked-sprite-workflow.md)。
+ 27 - 选用 Blender 制作或修改可编辑 3D 资产时，读取 [blender-asset-workflow.md](references/blender-asset-workflow.md)（不要一见 3D 项目就默认绑定 Blender 或强装 MCP 插件）。
+ 28 - 涉及生成式自由输入、人物知情权限、事件回放、存档迁移或 `signature_command` 时，读取 [playable-model-contract.md](references/playable-model-contract.md) 的对应章节。
+ 29 - 语音策略非 `none` 时，读取 [tts-production-contract.md](references/tts-production-contract.md)。
+ 30 - 实际采用动态媒体（视频短片、生成式音乐或音效）时，读取 [generative-media-pipeline.md](references/generative-media-pipeline.md)；需要在玩家选择后播放剧情过场（互动影游）时，再读 [cutscene-production.md](references/cutscene-production.md)。
+ 31 - 2.5D 角色或物件需要多朝向、多动作且造型高度一致的序列帧时，读取 [baked-sprite-workflow.md](references/baked-sprite-workflow.md)。
- 45 1. 先实现一个最小但完整的核心循环：启动、真实输入、状态变化、结果和重开。范围不足时修范围，
- 46    不先堆审计材料。
- 47 2. 实现 GAME_DESIGN 的状态、动作与结果；使用生成模型时，模型只解释输入和结果，规则器拥有提交权。
- 48    存在 `signature_command` 时再执行可选合同的专属边界。
- 49 3. 保留能复现问题的初态与输入路径，涉及随机性时固定 seed；修订后重放失败路径与相邻反例。
- 50    同一手感或表现问题连续两次修复无效时停止换方案，先查成熟作品处理同类问题的公开资料（开发者
- 51    演讲、技术复盘或开源实现），理解其原理后再实现。
- 52 4. 回写实际工具链、install/build/start 命令和版本；未知值写 `NOT_AVAILABLE: 原因`，不猜。
- 53    实际候选与 GAME_DESIGN、ART_DIRECTION 的事实描述不符时，交回对应 owner 修订或在 BUILD_BRIEF 标明冲突，
- 54    不留下描述已不存在的玩法、表现或声音的文档。
+ 35 1. **按阶段落地可玩版本**：`whitebox` 阶段只实现验证核心设计风险所需的真实输入、状态流转与界面反馈；`production` 阶段先打通「启动游戏 → 核心操作 → 达成设计结局 → 重开回到初始状态」的完整闭环。
+ 36 2. **兑现设计状态与规则**：完整实现当前阶段涉及的 `GAME_DESIGN.md` 状态、动作与结算结果；若接入生成式模型，模型只负责解析输入和润色反馈文本，状态变更的唯一提交权归属确定性规则引擎。启用 `signature_command` 时同步落实专项规范中的专属校验边界。
+ 37 3. **固定复现路径与卡点排查**：保留能稳定复现问题的初始状态与输入序列（涉及随机因素时固定 `seed`），修改后重跑原失败路径及相邻分支反例。若同一个操作手感或画面表现问题连续两次修改仍未见效，立即停止盲目试错，先查阅同类成熟商业作品处理该问题的公开技术分享（开发者演讲、技术复盘或开源实现），吃透底层原理后再动手实现。
+ 38 4. **回写工具链与对齐文档**：在 `BUILD_BRIEF.md` 中如实回写实际使用的工具链、安装/构建/启动命令及版本号（无法获取的版本填 `NOT_AVAILABLE: 原因`，严禁臆测）。若实机实现与 `GAME_DESIGN.md`、`ART_DIRECTION.md` 的描述出现偏差，必须退回对应负责环节修订文档，或在 `BUILD_BRIEF.md` 中明确标出冲突，绝不留下描述与实机表现脱节的过期文档。
- 56 `whitebox` 到此按 build-brief-contract「完成证据」运行最窄检查并交回 design owner；设计修订后
- 57 重放受影响路径，直到最大风险已被实际暴露或当前方向被否决。
+ 40 `whitebox` 阶段执行完第 4 步后，按 [build-brief-contract.md](references/build-brief-contract.md)「完成证据」运行最精简的风险检查并交回设计负责人；待设计局部修订后重跑受影响路径，直至核心风险验证完毕或该概念方向被正式否决。
- 59 `production` 继续：
+ 42 `production` 阶段继续往下执行：
- 61 5. 提供一条权威验证命令和最小可观察状态，使 `game-qa` 能一次走完
- 62    `clean start → 核心动作 → 设计结果 → restart`。
- 63 6. 运行最窄的开发检查与启动 smoke，修复构建失败、阻断日志、资源失败和崩溃；替代运行时未覆盖的
- 64    目标平台输入、性能、打包或设备项写入 limitation。
- 65 7. 达到 brief 的 `targetFinish`；更高完成度只处理已批准的焦点资产和招牌时刻，不制造与可玩闭环
- 66    无关的发布审计。有批准目标图的界面与焦点资产，在目标视口截取实际运行画面与目标图并排比对，
- 67    逐项列出布局、比例、字体、色光与层级差异后修正；连续两轮没有改善就停止，把剩余差异写进
- 68    BUILD_BRIEF 的限制，不修改目标图去迁就实现。
- 69 8. 交给 `game-qa`；诊断、复跑与事实源规则见契约「完成证据」。
+ 44 5. 提供一条权威验证命令（`verify`）与最小可观察状态接口，使 `game-qa` 能在单次运行中一气呵成走完 `clean start → 核心动作 → 设计结果 → restart`。
+ 45 6. 运行开发自检与启动冒烟测试，清零构建报错、控制台阻断异常、资源加载失败与运行时崩溃；因使用替代运行环境而无法覆盖的目标平台专属输入、真机性能、安装包打包或硬件特性，如实记入 `limitations`。
+ 46 7. 兑现 `PRODUCT_BRIEF.md` 锁定的 `targetFinish`；高完成度打磨集中在已批准的核心焦点资产与关键游戏时刻上，不搞脱离实机体验的纸面合规审查。凡是配有批准目标图的界面与核心资产，必须在目标视口尺寸下截取实机运行画面，与目标图并排逐项比对布局、比例、字体、色光与前后层级差异并做修正；若连续两轮调整仍无明显改善则果断停手，将剩余差异如实记入 `BUILD_BRIEF.md` 的限制说明，绝不篡改目标图去迁就实现缺陷。
+ 47 8. 将构建产物移交 `game-qa`；问题排查、重跑测试与验收结果覆盖规则见「完成证据」。
- 73 生成 `build/BUILD_BRIEF.md` 与实际候选；production 还生成权威验证入口。截图、录制与 raw trace 只保留
- 74 调试所需的最小集合。
+ 51 产出 `build/BUILD_BRIEF.md` 与可运行的游戏工程；`production` 阶段还须交付一键权威验证入口。调试截图、录屏与原始日志只保留定位问题所必需的最小集合。

Compare on GitHub

Before Not checked yet → After Instructions only

First observation → 9dddcd2dfdf0

No earlier version was observed for comparison.

Compare on GitHub

Before Instructions only → After Instructions only

9dddcd2dfdf0 → 48226e391b31

- 3 description: "Design game concepts from a novel. From SOURCE_BIBLE and PRODUCT_BRIEF, compare meaningful alternatives on the dimensions still unlocked, then select a playable direction using hard vetoes and explicit trade-offs. Use for what game should this novel become, compare game concepts, choose a game direction for this book, decide whether this novel should become an interactive story. 小说游戏概念设计。根据 SOURCE_BIBLE 与 PRODUCT_BRIEF 比较未锁定维度上的有效替代方案，用硬否决和关键取舍选择可玩方向。用于判断小说适合做成什么游戏、该不该做成互动叙事、比较游戏方案等需求。"
+ 3 description: "Design game concepts from a novel. From SOURCE_BIBLE and PRODUCT_BRIEF, compare meaningful alternatives on the dimensions still unlocked, then select a playable direction using hard vetoes and explicit trade-offs. Use for what game should this novel become, compare game concepts, choose a game direction for this book, decide whether this novel should become an interactive story. 小说游戏概念设计。根据 SOURCE_BIBLE 与 PRODUCT_BRIEF 对比尚未确定维度上的可行方案，通过硬性淘汰与关键取舍选定可玩方向。用于判断小说适合做成什么游戏、该不该做成互动叙事、比较游戏方案等需求。"
- 7 决定做成什么游戏，不写代码、数值表或逐场关卡脚本。
+ 7 决定把原著做成什么游戏，不写代码、数值表或逐场关卡脚本。
- 9 读取 [concept-method.md](references/concept-method.md)。输入必须包含 `SOURCE_BIBLE.md` 与
- 10 `PRODUCT_BRIEF.md`；缺任一项就停止并说明缺口，不代替上游补写。
+ 9 读取 [concept-method.md](references/concept-method.md)。输入必须包含 `SOURCE_BIBLE.md` 与 `PRODUCT_BRIEF.md`；缺任一份即停止并说明缺口，不越权替上游补写。
- 16 直接继承 brief 已锁的平台、输入、受众、分级、时长、目标市场和非目标；发现它们与原作明显冲突
- 17 时回总入口修订，不在概念阶段静默改值。原作语言、文化语境、目标市场和界面语言分别处理，不从
- 18 其中一个自动推出另一个。
+ 15 直接沿用 `PRODUCT_BRIEF.md` 已锁定的平台、输入方式、目标受众、分级、时长、目标市场和明确非目标；若发现上述约束与原著明显冲突，退回总入口修订，不在概念阶段私自改值。原著语言、文化背景、目标发行市场和界面语言分开处理，不拿其中一项强推另一项。
- 20 互动叙事是成熟玩法，不因以阅读和对白承载就降低标准；它的动词可以是读局面、追问、比对信息、
- 21 表态、隐瞒、交出与承担回响。
+ 17 互动叙事是成熟的游戏品类，不因以文本阅读和对白抉择为主就降低可玩性标准；玩家的核心动作同样包括审视局势、追问、比对线索、表态、隐瞒、交出证物并承担后续连锁反应。
- 23 概念还要判断验证形态：可用成熟交互语法表达时说明“已有语法 + 原作如何改变它”；核心依赖实时手感、
- 24 空间、视线、物理或独特操作时明确走自定义灰盒。不要把文本原型当所有体验的统一前置层，也不要因有
- 25 模板可用就让模板替原作决定玩法。
+ 19 概念阶段还需敲定白盒验证形态：可复用成熟品类交互时，写明「借用哪套成熟交互 + 原著如何改写其规则」；若核心体验高度依赖实时操作手感、空间走位、视线遮挡、物理反馈或独创操作，则明确采用定制白盒（`custom`）。不要把纯文字原型当成所有品类的通用前置步骤，也不要为了套现成模板而削足适履。
- 29 先列 brief 的锁定维度和仍开放的维度，只比较能揭示真实取舍的方向，不凑概念数量或差异维度。
- 30 仅在方向仍开放时考察可信替代；用户已选定方向或不存在有效替代时说明原因，改为验证该方向的风险，
- 31 不重开选择。
+ 23 先列出 `PRODUCT_BRIEF.md` 已锁定的维度和仍开放的维度，只围绕真正存在取舍差异的方向做对比，不硬凑方案数量或对比维度。仅在玩法方向尚未锁定时比较可行方案；若用户已指定方向或只存在唯一合理方向，写明依据后直接转向剖析该方向的设计风险，不再虚设陪跑方案。
- 35 先按 concept-method 的硬否决逐个淘汰，不计算总分，再按其比较维度选择。`quick` 自动选证据最强的
- 36 方向；`director` 只对尚未决定的方向给出推荐并等待用户选择。
+ 27 先对照 [concept-method.md](references/concept-method.md) 的「硬否决」逐一筛除不合格方案（不搞加权打分），再按其中的比较维度做出取舍。`quick` 模式自动选定证据最扎实的方案；`director` 模式针对尚未锁定的方向给出推荐意见并停下等待用户拍板。
- 40 生成一个 `concepts/CONCEPT.md`，只含：
+ 31 生成一份 `concepts/CONCEPT.md`，包含：
- 42 1. brief 锁定值与开放维度；
- 43 2. 体验承诺及其可观察现象和失败现象；
- 44 3. 紧凑先例说明；
- 45 4. 候选概念卡：主类型、`experienceProfile`、借用/拒绝的玩法先例、核心动作与循环、压力、失败、
- 46    世界响应；说明玩家身份如何形成反复行动、执行阻力与可观察变化。
- 47    `signature_command` 按方法「身份专属命令」写值或 `N/A`；最后说明原作张力如何由玩家行动体现、
- 48    招牌画面、最小验证切片、最大风险和否决观察；
- 49 5. 硬否决结果、关键取舍、推荐与选择状态；
- 50 6. 选定方向的玩家能动性合同、不可妥协体验承诺；
- 51 7. 最小验证问题与开放问题。
+ 33 1. `PRODUCT_BRIEF.md` 已锁定值与仍开放的维度；
+ 34 2. 核心体验承诺，以及兑现成功与失败时的可见表现；
+ 35 3. 简明对标先例说明；
+ 36 4. 候选概念卡：主品类、`experienceProfile`、借用与舍弃的对标设计、核心动作与循环、压力来源、失败后果、世界反馈；写明玩家角色身份如何驱动反复行动、面临什么执行阻力并带来哪些看得见的局面变化；`signature_command` 按方法「身份专属命令」填写具体定义或 `N/A`；最后写明原著冲突如何通过玩家操作体现、招牌画面、最小验证片段、最大设计风险及推翻该方向的观察判据；
+ 37 5. 硬否决筛查结果、核心取舍、推荐方案与当前选定状态；
+ 38 6. 选定方向的玩家能动性保障与不可妥协的体验底线；
+ 39 7. 最小验证问题与待解开放问题。
- 53 `narrative-led` 或 `hybrid` 的叙事层还要选择一种分支结构语法并说明内容预算。交接前确认选定方向
- 54 可在 brief 范围内做成完整切片。
+ 41 `narrative-led` 或 `hybrid` 项目的叙事层还需选定一种分支结构并说明内容体量预算。交接前确认选定方向可在 `PRODUCT_BRIEF.md` 限定的预算和范围内做完完整可玩版本。

Compare on GitHub

Before Not checked yet → After Instructions only

First observation → 9dddcd2dfdf0

No earlier version was observed for comparison.

Compare on GitHub

Before Instructions only → After Instructions only

9dddcd2dfdf0 → 48226e391b31

- 3 description: "Verify a game with evidence on its selected target runtime. Launch the actual build and prove real rendering, input, the core loop, at least one designed outcome, restart, and explicit limitations without dressing subjective fun up as a certain verdict. Use for test a generated game, QA a game build, check whether the game is fully playable, or verify the build. 游戏证据化质量验证。在选定的目标运行环境中启动实际构建，证明真实渲染、输入、核心循环、至少一个设计结果、重开和明确限制，不把主观趣味包装成确定性结论。用于测试生成游戏、检查游戏能否完整游玩或验证构建。"
+ 3 description: "Verify a game with evidence on its selected target runtime. Launch the actual build and prove real rendering, input, the core loop, at least one designed outcome, restart, and explicit limitations without dressing subjective fun up as a certain verdict. Use for test a generated game, QA a game build, check whether the game is fully playable, or verify the build. 游戏实机运行验收。在选定的目标运行环境中启动游戏，验证真实画面渲染、操作输入、核心循环、至少一个设计结局、重新开始及已知限制，不把主观好玩程度包装成确定性结论。用于测试生成的游戏、检查游戏能否完整通关或验收构建版本。"
- 5 # 游戏质量验证
+ 5 # 游戏实机运行验收
- 7 验证当前候选能否完成最小可玩闭环，不把自动化结果包装成趣味、平衡、权利或发布质量结论。
+ 7 通过实机运行记录验证当前构建版本能否走通最小可玩闭环，不把自动化测试通过包装成“好玩、数值平衡、版权合规或达到上线水准”的定论。
- 9 读取 [qa-contract.md](references/qa-contract.md) 定判据，按
- 10 [test-design-method.md](references/test-design-method.md) 设计最少但有区分力的检查。
+ 9 先读 [qa-contract.md](references/qa-contract.md) 明确验收标准，再按 [test-design-method.md](references/test-design-method.md) 设计精简且有区分度的验证用例。
- 14 ## 唯一必需合同
+ 13 ## 必测六项指标
- 16 每个候选都必须用真实运行证据覆盖：`launch`、`render`、`input`、`coreLoop`、`outcome`、`restart`。
- 17 `targetFinish` 描述成色，不改变这组六项。
+ 15 任何构建版本都必须通过实机运行跑通以下六项检查：`launch`、`render`、`input`、`coreLoop`、`outcome`、`restart`。`targetFinish` 只代表视觉与制作完成度，不增减这六项基础门禁。
- 21 1. 读取 `targetRuntime`、`testedRuntime` 和权威 verify；与 PRODUCT_BRIEF/BUILD_BRIEF 冲突时先报错，
- 22    不由 QA 猜值。
- 23 2. 运行权威 verify：它在 testedRuntime 从 clean start → 核心动作 → 设计结果 → restart
- 24    完成整条路径，并记录 command、exit code、环境、六项结果、最小证据和实际失败。
- 25 3. 对照 GAME_DESIGN 中会改变结果的不变量和结束标记；只验证批准的设计承诺，不遍历所有
- 26    代码路径。
- 27 4. 若候选有可执行模型、事件日志、patch 或 `signature_command`，按 test-design-method 的对应合同把
- 28    项目回归嵌入权威 verify；允许定向诊断、修复和复跑，最终六项证据必须来自同一次完整运行。
- 29    失败映射到已有 checks 或 limitation。
- 30 5. 记录 limitation 和问题的 product/design/art/build 归属。
+ 19 1. 读取 `BUILD_BRIEF.md` 中的 `targetRuntime`、`testedRuntime` 和权威 `verify` 命令；若与 `PRODUCT_BRIEF.md` 或 `BUILD_BRIEF.md` 前后矛盾，立即报错退回，不由 QA 自行猜测填补。
+ 20 2. 在 `testedRuntime` 中运行权威 `verify` 命令：从纯净初始状态（`clean start`）出发，依次走完「核心动作 → 达成设计结局 → 重开回到初始状态」整条路径，如实记录执行的命令、退出码、运行环境、六项检查结果、实机观察记录和暴露的实际故障。
+ 21 3. 对照 `GAME_DESIGN.md` 中会改变结局走向的硬规则和通关标记，只验证已批准的设计承诺，不追求走遍每一行底层代码分支。
+ 22 4. 若项目包含可执行改编模型、事件日志、热修补丁或 `signature_command`，按 [test-design-method.md](references/test-design-method.md) 的对应要求把回归用例并入权威 `verify` 命令；排查期间允许做单点诊断、修复和重跑，但最终写入 `qa/verification.json` 的六项结果必须来自同一次完整运行。任何专项回归失败均需映射到上述六项检查或记入 `limitations`。
+ 23 5. 如实记录未覆盖的限制项（`limitations`），并将发现的问题按 product / design / art / build 职责归属指派回对应环节。
- 32 优先使用已有可观察状态；只有无法判断结果时才增加最小测试钩子。
+ 25 验证时优先读取游戏已有的可见状态与 DOM/画面输出；只有在外部完全无法观测关键结果时，才添加最小化的测试钩子。
- 36 - `qa/verification.json`：唯一 QA 事实源；字段与证据要求见 qa-contract.md。
+ 29 - `qa/verification.json`：唯一的实机验收记录文件（字段要求与记录格式见 [qa-contract.md](references/qa-contract.md)）。
- 38 缺口写结构化 limitation，不发明 `PASS_WITH_GAPS`；未运行或失败的必需项不能满足整体 PASS。
+ 31 尚未覆盖的测试盲区统一写入结构化的 `limitations` 数组，绝不生造 `PASS_WITH_GAPS` 之类的折中状态；只要有任一必测项未运行（`NOT_RUN`）或失败（`FAIL`），顶层状态就不得标为 `PASS`。

Compare on GitHub

Before Not checked yet → After Instructions only

First observation → 9dddcd2dfdf0

No earlier version was observed for comparison.

Compare on GitHub

Before Instructions only → After Instructions only

9dddcd2dfdf0 → 48226e391b31

- 3 description: "Design game experience, systems, and levels. Converge the chosen concept into one GAME_DESIGN defining the player promise, core loop, how the world responds, the systems actually needed, level pacing, feedback, failure, and the specification for a complete playable slice. Use for design the game world, deepen the gameplay and levels, write the game design document, design the branching story structure, scenes, dialogue and consequences. 游戏体验、系统与关卡策划。把选定概念收束为一份 GAME_DESIGN，定义玩家承诺、核心循环、世界响应、必要系统、关卡节奏、反馈、失败及可供构建的完整切片设计。用于设计游戏世界、深化玩法和关卡、设计互动叙事的场景对白与分支因果等需求。"
+ 3 description: "Design game experience, systems, and levels. Converge the chosen concept into one GAME_DESIGN defining the player promise, core loop, how the world responds, the systems actually needed, level pacing, feedback, failure, and the specification for a complete playable slice. Use for design the game world, deepen the gameplay and levels, write the game design document, design the branching story structure, scenes, dialogue and consequences. 游戏体验、系统与关卡策划。将选定概念收束为一份 GAME_DESIGN，定义核心体验目标、玩法循环、世界反馈、必要系统、关卡节奏、操作反馈、失败重开及可供构建的完整可玩范围。用于设计游戏世界、深化玩法和关卡、设计互动叙事的场景对白与分支因果等需求。"
- 7 把选定概念变成可实现的玩家体验，不写世界观百科、工程方案或美术方向。
+ 7 把选定的概念收束为可落地的玩家体验设计，不写空泛的世界观设定集、代码架构方案或美术设定稿。
- 9 输入必须包含 `SOURCE_BIBLE.md`、已选择的 `CONCEPT.md` 和 `PRODUCT_BRIEF.md`。读取
- 10 [world-design-method.md](references/world-design-method.md)；确有资源、门槛或难度时再读
- 11 [numeric-design-method.md](references/numeric-design-method.md)。
+ 9 输入必须包含 `SOURCE_BIBLE.md`、已选定的 `CONCEPT.md` 和 `PRODUCT_BRIEF.md`。先读 [world-design-method.md](references/world-design-method.md)；涉及资源消耗、数值门槛或难度曲线时，再读 [numeric-design-method.md](references/numeric-design-method.md)。
- 13 叙事实际承载体验时读取 [narrative-design-method.md](references/narrative-design-method.md)，
- 14 不为所有项目强制写长篇对白。
+ 11 当剧情分支与人物交锋实际承载核心体验时，读取 [narrative-design-method.md](references/narrative-design-method.md)（非叙事主导项目不必硬写长篇对白）。若玩家做出选择后需要播放一段演绎后果的剧情过场（即文字冒险与短剧结合的互动影游），再读 [interactive-film-method.md](references/interactive-film-method.md)。
- 20 - 保护 CONCEPT 的玩家承诺、`experienceProfile` 和不可妥协项；发现范围冲突时回上游修订。
- 21 - 切片时长与系统范围服从 brief，以暴露最大设计风险为准，不预设时长或系统数量。
- 22 - 不写文件名、函数、存储键、测试脚本、着色器或资产管线；实现结构由构建阶段决定。
+ 17 - 守住 `CONCEPT.md` 确定的核心体验目标、`experienceProfile` 和不可妥协的体验底线；若发现范围冲突，退回上游修订。
+ 18 - 试玩时长与系统数量服从 `PRODUCT_BRIEF.md`，以验证核心设计风险为准，不硬套固定时长或系统数量。
+ 19 - 不写代码文件名、函数名、存储键名、测试脚本、着色器或资产生产管线；具体工程结构留给构建阶段决定。
- 24 ## 输出合同
+ 21 ## 输出结构
- 26 生成一个 `design/GAME_DESIGN.md`，保持紧凑并包含：
+ 23 生成一份紧凑的 `design/GAME_DESIGN.md`，包含以下八节：
- 28 1. **体验与循环合同**：玩家身份、承诺、目标感受、`experienceProfile`、核心动作与循环和主要玩法先例，
- 29    以及原作如何改变动作对象、顺序、代价和世界回应；
- 30 2. **世界规则与进程**：玩家可见/隐藏信息、行动顺序、随机性、资源或持久状态及其读取点；
- 31    适合本项目的局面、能力或理解变化，以及可观察结束标记，不强套成长阶段；
- 32 3. **决策与关卡节拍**：关键局面如何要求玩家行动或取舍，玩家拥有何种因果权与结算权；
- 33 4. **反馈、失败与重开**：输入反馈、状态变化、失败原因、下次可改之处和定义初态；
- 34 5. **叙事附件**：仅在叙事实际承载体验时写场景脊柱、人物议程、知识/证词边界、持久回响、
- 35    分支汇流和结局回收；否则写 N/A；
- 36 6. **语言、文化与交接边界**：界面语言、术语、阅读顺序、内容尺度，以及交给美术和构建的玩家效果；
- 37 7. **可执行切片合同**：最大设计风险、匹配的原型形态、最小状态、动作前置/效果，以及初态、输入路径、
- 38    预期状态与反馈；随机性相关时固定 seed，知情差或事件回读相关时才补观察者与事件；若概念选择了
- 39    `signature_command`，按方法「身份专属命令与延期回响」补齐结构；
- 40 8. **验证切片**：范围、明确非目标、完整路径和会触发设计修改的观察结果。
+ 25 1. **体验与核心循环**：玩家扮演身份、核心体验目标、目标情绪、`experienceProfile`、核心动作与循环、主要玩法对标先例，以及原著设定如何改变动作对象、先后顺序、行动代价和世界反馈；
+ 26 2. **世界规则与进程**：玩家可见信息与隐藏信息、行动顺序、随机因素、资源或持久状态及其后续读取点；符合本项目特质的局势演进、能力变化或真相认知推进，以及清晰的通关/结局触发标记（不强套千篇一律的养成阶段）；
+ 27 3. **决策与关卡节拍**：关键局面如何迫使玩家行动或权衡取舍，玩家拥有怎样的因果权与结算权；
+ 28 4. **反馈、失败与重开**：操作即时反馈、状态变化表现、失败触发原因、重来时的改进空间，以及重开后的初始状态定义；
+ 29 5. **叙事附件**：仅在叙事实际承载核心体验时编写（含场景主线、人物动机与筹码、知情与证词边界、持久回响、分支汇流条件与结局回收），否则填 `N/A`；
+ 30 6. **语言、文化与交接边界**：界面语言、专有术语、阅读动线、内容尺度，以及交接给美术和构建阶段需兑现的玩家体验效果；
+ 31 7. **最小可运行规则与复现路径**：最大设计风险、匹配的白盒原型形态、最小状态集、动作前置条件与效果，以及可复现的初始状态、输入序列、预期终态与反馈（涉及随机性时固定 `seed`；涉及信息差或历史回读时补齐观察者与事件记录；若 `CONCEPT.md` 启用了 `signature_command`，按方法「身份专属命令与延期回响」补齐六组结构）；
+ 32 8. **验证范围与通关路径**：可玩范围、明确非目标、一条完整通关路径，以及一旦出现就必须回头修改设计的失败现象。
- 42 规则优先用短表表达，不复制成平行 JSON、go/no-go 表或第二份验收矩阵。
+ 34 规则优先用紧凑表格表达，不重复抄写成平行的 JSON、准入检查表或第二份验收矩阵。
- 46 按 world-design-method 反向走读可执行闭环、世界回响、设计进程、重放与范围；存在叙事或专属命令时，
- 47 再按对应方法检查知识、分支、人物行动、解析候选与实际执行没有串线。只交付设计合同，不替实现选技术，
- 48 也不把趣味或平衡写成确定性 PASS。
+ 38 对照 [world-design-method.md](references/world-design-method.md) 正向与反向走读可执行闭环、世界回响、推进节奏、重放一致性与范围边界；包含叙事分支或身份专属命令时，再按对应方法核查人物知情范围、分支汇流、角色行动、意图解析候选与实际结算之间有无串线。只交付设计方案，不替构建阶段选技术栈，也不把主观好玩或数值平衡包装成确定性 `PASS`。
- 50 输出交回总入口，不自行推进美术、构建或 QA。
+ 40 完成后将 `design/GAME_DESIGN.md` 交回总入口，不越权自行启动美术、构建或 QA。

Compare on GitHub

Before Not checked yet → After Instructions only

First observation → 9dddcd2dfdf0

No earlier version was observed for comparison.

Compare on GitHub

Before Instructions only → After Instructions only

9dddcd2dfdf0 → 48226e391b31

- 7 建立游戏设计所需的事实层，不评价文笔，也不在此阶段选择游戏类型。
+ 7 提炼游戏设计所需的原著事实与原文依据，不做文学鉴赏，也不在此阶段敲定游戏类型。
- 13 原文可以是任意语言。引用保留原文；策划语言或界面语言与原文不同时附必要译文，并建立角色名、
- 14 地名、物件和规则的统一术语表；礼制、宗教和叙事惯例不替换成另一文化的近似类型标签。
+ 13 支持任意语言的原著。引用保留原文；当文档语言或游戏界面语言与原文不同时，附上必要译文并建立角色名、地名、器物和核心规则的统一术语表；原著中的礼制、宗教与叙事传统保留原有文化内涵，不替换成异域奇幻或现代类型标签。
- 18 优先复用现有写作工程或**全量**拆文产物，只回原文补关键证据；只有原始小说时才执行
- 19 本 skill 的全书管道。已有分析若只覆盖黄金三章或快速预览，只能帮助判断开篇，不能
- 20 证明理解了全书。除非用户明确只改编某一卷或片段，否则来源未覆盖全文时不得进入概念设计。
+ 17 优先复用现有的写作工程或覆盖**全书**的拆文产物，只针对缺失的关键证据回查原文；只有拿到纯文本原著时才从头运行全书拆解流程。若已有分析只覆盖开篇几章或局部速览，只能辅助判断开局，不能代表读完了全书。除非用户明确限定只改编某一卷或某几章，否则来源未覆盖全书前不得进入概念设计。
- 22 若存在 `PRODUCT_BRIEF.md`，先读取：分级、核心幻想与已锁类型决定取证优先级——优先为
- 23 核心幻想涉及的动作、关系、场面取证；对已锁类型需要而原作未系统提供的体系（如属性相克、
- 24 数值成长），在设计空白中写明「原作无系统化的对应体系，属下游发明」，供下游改编边界如实
- 25 引用。
+ 19 若已有 `PRODUCT_BRIEF.md`，先按其中的内容分级、核心代入感与已锁定玩法排定取证优先级：优先提取核心代入感涉及的动作、人物关系与关键场面；对已锁定玩法需要、但原著并未成体系描写的机制（如五行相克、数值成长），在「设计空白」中写明「原著无现成体系，属下游设计发明」，供下游对齐改编边界。
- 27 ## 全书管道
+ 21 ## 全书拆解流程
- 29 建立边界 → 逐单元提取 → 覆盖门禁 → 分层聚合 → 回查原文 → 压缩交付，各步做法见
- 30 gameability-protocol.md。选定改编段落的核对在概念选定后二次进入时做，产出逐事实表（见「输出」）。
- 31 工作卡只服务覆盖、恢复和复核，不把过程日志包装成策划成果。
+ 23 按 [gameability-protocol.md](references/gameability-protocol.md) 依次完成来源界定、逐章取证、覆盖率核对、分层汇总、原文回查与定稿交付；分批工作卡仅用于断点续跑与复核。
- 33 可以在运行时并行处理互不重叠的章节批次，但每批必须使用同一提取契约，聚合和事实回查
- 34 保持串行；环境不支持并行时逐批串行完成。
+ 25 互不重叠的章节批次可以并行提取（环境不支持并行时逐批串行处理），但每批必须遵循同一套提取标准，跨章汇总和原文回查必须串行完成。
- 38 只保留会影响玩家动作、世界响应或视听身份的内容；维度、覆盖状态与命令/委托的记录方式以协议
- 39 「逐单元取证」「从事实得到系统候选」为准。
+ 29 只提取会影响玩家操作、世界反馈或视听风格的内容；提取维度、覆盖状态与命令/委托关系的记录规格，以协议中的「逐章取证」和「从原著事实提炼系统候选」为准。
- 41 为硬规则、关键角色目标、玩家身份依据、转折结局和标志性锚点记录章节或文件位置；
- 42 推断必须明确标成推断或开放设计空间。
+ 31 世界硬规则、关键角色目标、玩家身份依据、重大转折结局和标志性视听锚点均须记录章节或文件位置；由分析者推演出的内容必须明确标为「推断」或「开放设计空间」。
- 46 生成一份 `analysis/SOURCE_BIBLE.md`，包含来源范围、**全书覆盖**、世界身份、原作事实与
- 47 证据、改编边界、玩家身份候选（PRODUCT_BRIEF 已锁身份时改为该身份的动作空间验证）、
- 48 可玩动词、可下达/承接的身份动作及其执行阻力、世界模型、空间与角色能动性、文化语境、
- 49 术语表（语言条件见上）、视觉锚点、风险和设计空白。全书覆盖按连续范围列出开篇、中段、结局和跨段
- 50 回收的关键变化、强弱节奏、反例与游戏化意义；表头写明来源单元数与成功数。短表格优先于重复文档、
- 51 结构化数据和证据索引。
+ 35 生成 `analysis/SOURCE_BIBLE.md`，包含：来源范围、**全书覆盖**、世界特质、原著事实与证据、改编边界、玩家身份候选（`PRODUCT_BRIEF.md` 已锁定身份时改为验证该身份的可执行动作空间）、可玩动词、可下达或承接的身份动作及其执行阻力、世界运行模型、空间与角色能动性、文化语境、术语表（跨语言时必填）、视听锚点、改编风险和设计空白。「全书覆盖」按连续章节区间列出开篇、中段、结局及跨段回收的关键变化、节奏起伏、反例与游戏化意义，并在表头写明总章节数与成功提取数。优先用紧凑表格表达，不拆成重复文档或单独的结构化索引。
- 53 改编边界必须是表格：`条目 | 边界类型 | 证据位置`，边界类型只用协议的四种标签；涉及
- 54 名分、座次、官阶或队伍序列的作品必须附人物名册行（`姓名 | 身份/次序 | 结局 | 证据回目`），
- 55 供下游回查人物身份与次序。
+ 37 「改编边界」必须使用 `条目 | 边界类型 | 证据位置` 表格，边界类型只用协议规定的四种标签；涉及妻妾名分、排座次、官阶品级或固定队伍序列的作品，必须附上人物名册表（`姓名 | 身份/次序 | 结局 | 证据回目`），供设计与构建阶段核对人物身份、次序和结局。
- 57 概念阶段选定改编段落后，二次进入本 skill 为该段落补一张逐事实表并追加进 SOURCE_BIBLE：
- 58 `事实 | 证据位置 | 边界类型`，含入镜角色的外观要点（服饰、兵器、体量及位置；原文无描写
- 59 写「原文未明确」）。此表供下游回查段落事实；下游发现出入时回上游修正此表，不各自改写。
- 60 概念选定后只补充或纠正有依据的原作事实——SOURCE_BIBLE 不得包含下游发明物，游戏状态键名、
- 61 回合或日程编号、scene_id、Hub/界面结构、QA 与范围计划只属于 GAME_DESIGN，不得把既有事实
- 62 改写成切片说辞。
+ 39 概念方向选定后，若该方向依赖的关键因果、人物外貌或时空方位缺少出处、前后冲突或尚未覆盖，再针对性回查原文并更新 `SOURCE_BIBLE.md`（可用 `事实 | 证据位置 | 边界类型` 表格列出补证结果）；原著未交代的服饰、兵器、体型或位置统一标为「原文未明确」。
- 64 来源范围只记录会影响复核的版本、覆盖范围和授权边界。下载日期、字节数、校验值和
- 65 本地路径只有在复现契约确实需要时才写，不把获取日志当策划内容。
+ 41 `SOURCE_BIBLE.md` 只记录有原文依据的原著事实。其他阶段的决策由各自文档负责：产品范围归 `PRODUCT_BRIEF.md`，玩法、可玩范围与界面结构归 `GAME_DESIGN.md`，代码键名与目录结构归构建阶段，测试方案归 QA 阶段，均不得反向混入原著事实层。
- 67 其余完成门禁见协议「事实保真与交付」。
+ 43 「来源范围」只记录影响内容复核的底本版本、章节覆盖范围和版权边界；除非复现脚本明确需要，否则不写下载日期、字节数、哈希校验值和本地路径。
+ 44 
+ 45 交付前的核对要求见协议「事实保真与交付」。

Compare on GitHub

Before Not checked yet → After Instructions only

First observation → 9dddcd2dfdf0

No earlier version was observed for comparison.

Compare on GitHub

Before Instructions only → After Instructions only

9dddcd2dfdf0 → 48226e391b31

- 3 description: "Turn a novel into a fully playable game on the selected target platform. Orchestrates the whole adaptation pipeline — requirements intake, gameable deconstruction, concept selection, world and visual design, target-runtime build, and evidence-based QA — for a novel in any language. Use for novel to game, story to game, book to game, adapt this novel into a game, turn this book into a playable prototype, make an interactive story or text adventure from this novel. NovelToGame 总入口。把任意语言的原始小说、拆文库或 oh-story 写作工程转成有原著依据、可在目标平台完整游玩的游戏，编排游戏化拆解、概念选择、游戏与视觉设计、目标运行环境构建和证据化质量验证。用于小说转游戏、把这本书做成游戏、把小说改成互动小说 / 互动叙事 / 文字冒险游戏等需求。"
+ 3 description: "Turn a novel into a fully playable game on the selected target platform. Orchestrates the whole adaptation pipeline — requirements intake, gameable deconstruction, concept selection, world and visual design, target-runtime build, and evidence-based QA — for a novel in any language. Use for novel to game, story to game, book to game, adapt this novel into a game, turn this book into a playable prototype, make an interactive story, text adventure, or interactive film from this novel. NovelToGame 总入口。把任意语言的原始小说、拆文库或 oh-story 写作工程转成忠于原著、可在目标平台完整游玩的游戏，编排游戏化拆书、概念选型、世界与美术设计、按目标运行环境构建游戏与实机运行验收。用于小说转游戏、把这本书做成游戏、把小说改成互动小说 / 互动叙事 / 文字冒险游戏 / 互动影游等需求。"
- 7 你是小说游戏化总导演：守住改编判断、阶段边界和完成证据，不把普通原型包装成趣味、平衡、权利或
- 8 发布质量结论。开始前读取 [pipeline-contract.md](references/pipeline-contract.md)。
+ 7 你是小说改编游戏的总导演，负责把控改编方向、阶段分工与验收证据，不把跑通基础流程包装成好玩、数值平衡、版权合规或达到上线水准。开始前先读 [pipeline-contract.md](references/pipeline-contract.md)。
- 12 先速读来源并替用户起草 `PRODUCT_BRIEF.md`，再按
- 13 [intake-method.md](references/intake-method.md) 只处理会实质改变方向或带来权利、尺度、平台风险的
- 14 歧义。低风险空白集中列为未确认假设，不逐项拦停。
+ 11 先速读原著并替用户起草 `PRODUCT_BRIEF.md`，再按 [intake-method.md](references/intake-method.md) 只向用户确认会改变改编方向，或涉及版权、内容尺度、平台限制的分歧；其余低风险未定项统一记入「未确认假设」，不逐条打断推进。
- 16 `targetFinish` 只表示想做到的成色：`graybox`、`playable-prototype`、`polished-vertical-slice` 或
- 17 `showcase`，不改变六项最小 QA，也不形成第二套验收等级。
+ 13 `targetFinish` 只表示目标完成度（`graybox`、`playable-prototype`、`polished-vertical-slice` 或 `showcase`），不改变六项基础 QA 检查，也不另设第二套验收标准。
- 19 `PRODUCT_BRIEF.md` 与 `SOURCE_BIBLE.md` 是上游事实，下游不得静默改写。
+ 15 `PRODUCT_BRIEF.md` 与 `SOURCE_BIBLE.md` 是上游事实依据，后续阶段不得私自改写。
- 23 - `quick`：默认；用推荐草案推进，比较有效替代后自动选择并完成全流程。
- 24 - `director`：在概念方向、白盒试玩后的内容取舍（可在此请目标玩家试玩）和视觉目标候选（仅制作视觉目标包时）
- 25   给出候选与推荐后停靠，等待用户选择；已有明确选择时不重复停靠。
- 26 - `resume`：读取 `_progress.md` 和实际产物，从最早未完成的交接继续。
+ 19 - `quick`（默认）：按推荐草案推进，比较可行方案后自动选定方向并走完全流程。
+ 20 - `director`：在选定概念方向、白盒试玩后裁剪内容（可在此请目标玩家试玩）、挑选视觉目标图（仅在制作视觉目标包时）三个节点给出候选方案与推荐意见，停下等待用户拍板；用户此前已明确指定时不再重复询问。
+ 21 - `resume`：读取 `_progress.md` 和现有产物，从最早未完成的交接节点接着往下做。
- 30 1. 建立工作区，记录来源、模式、当前阶段和未确认假设。
+ 25 1. 建立工作区，记录原著来源、运行模式、当前阶段和未确认假设。
- 32 3. 调用 `novel-game-analyze` 生成有原文依据的 `SOURCE_BIBLE.md`。
- 33 4. 调用 `game-concept` 比较仍开放的方向并选定 `CONCEPT.md`；自然语言专属命令按玩法需要选择，
- 34    不适用时明确 `N/A`；`director` 的待决方向在此停靠。
- 35 5. 调用 `game-world-design` 生成 `GAME_DESIGN.md`，其中锁定最大设计风险与最小可执行切片。
- 36 6. 在完整美术生产前调用 `game-build` 做与最大风险匹配的白盒候选；试玩后把偏差交回 design owner
- 37    局部修订并重放受影响路径，不能用文本模拟结果冒充空间或操作验证；随后按流程契约做第一次预算与
- 38    范围复盘，据此请 design owner 调整剧情与关卡内容量。
- 39 7. 调用 `game-art-direction` 生成 `ART_DIRECTION.md`；只有高风险歧义或目标成色需要时再制作视觉目标包，目标图选定后
- 40    才进入批量资产生产。
- 41 8. 再由 `game-build` 将验证后的因果语义实现为完整候选，`game-qa` 验证最小闭环；问题按
- 42    product/design/art/build 归属回流。
+ 27 3. 调用 `novel-game-analyze` 生成带原文出处的 `SOURCE_BIBLE.md`。
+ 28 4. 调用 `game-concept` 比较尚未锁定的方向并选定 `CONCEPT.md`；按玩法需要决定是否启用自然语言专属命令（不适用填 `N/A`）；`director` 模式下若有待决方向在此停靠。
+ 29 5. 若选定方向依赖的原著事实缺少出处或前后矛盾，先调用 `novel-game-analyze` 回查原著补证；再调用 `game-world-design` 生成 `GAME_DESIGN.md`，锁定最核心的设计风险与最小可玩范围。
+ 30 6. 在批量制作美术资产前，调用 `game-build` 针对最大设计风险搭建白盒原型；试玩后把暴露的偏差交回设计负责人局部修订并重跑受影响路径（涉及空间或操作手感的问题不得拿纯文字推演冒充验证）；随后按流程规范做首轮预算与范围复盘，据此调整剧情与关卡内容量。
+ 31 7. 调用 `game-art-direction` 生成 `ART_DIRECTION.md`；仅在视觉方向存在高风险分歧或目标完成度需要时制作视觉目标包，选定目标图后再进入批量资产生产。
+ 32 8. 调用 `game-build` 将验证通过的因果规则与交互实现为完整可玩版本，再由 `game-qa` 验证最小可玩闭环；发现的问题按 product / design / art / build 职责归属退回修复。
- 46 接受任意语言小说。产物使用用户指定语言，未指定时跟随对话语言；原文证据保留原语言，跨语言只补
- 47 决策所需译文并维护一个术语表。原作文化语境、目标市场和界面语言分别记录，不用逐字翻译替代本地化判断。
+ 36 支持任意语言的小说。生成产物使用用户指定的语言，未指定时跟随对话语言；引用原文证据保留原语言，跨语言时只翻译影响决策的关键内容并维护一份统一术语表。原著文化语境、目标发行市场和界面语言分开记录，不能拿逐字直译代替本地化判断。
- 51 - 剧情必须转成玩家动词、选择和世界反馈，而非逐章复演。
- 52 - `experienceProfile`（`system-led` / `narrative-led` / `hybrid`）由 brief 起草、概念阶段确认，之后
- 53   贯穿设计、美术、构建与 QA；它只改变判据表达，不降低完成要求。
- 54 - 玩家选择要拥有因果权与结算权，不能用卡牌、回合或资源条伪装能动性。
- 55 - 生成模型可以解释输入和写表达，状态提交、知识披露、资源结算与不可逆承诺必须由可重放规则裁决。
- 56 - 自然语言只在能体现玩家身份的专属命令上按需开放；它先编译成有限候选，再经过执行阻力、规则提交、
- 57   证物/见证反馈与延期回响，不能退化成通用聊天或“说了就发生”。
+ 40 - 把原著剧情转化为玩家动词、抉择与世界反馈，不要按章节顺序把小说照搬成看戏流程。
+ 41 - `experienceProfile`（`system-led` / `narrative-led` / `hybrid`）由 `PRODUCT_BRIEF.md` 起草、在概念阶段确认，随后贯穿设计、美术、构建与 QA；它只决定用哪类判据衡量体验，不降低完成标准。
+ 42 - 玩家的选择必须真正改变事件原因或走向（因果权），并由世界具体兑现后果（结算权），不能只靠卡牌、回合或资源条伪装互动感。
+ 43 - 生成模型只负责解析输入和润色台词表现；状态变更、信息揭露、资源结算与不可逆承诺必须由可复现的规则裁决。
+ 44 - 自然语言输入只在能体现玩家角色身份的专属命令上按需开放：先把玩家表述解析为有限候选，再经过执行阻力判定与规则提交，产出物证、目击反应与延期回响，不能退化成通用闲聊或“玩家说什么就直接成真”。

Compare on GitHub

Before Not checked yet → After Instructions only

First observation → 9dddcd2dfdf0

No earlier version was observed for comparison.

Compare on GitHub