@oh-story/dsh 0.1.4 → 0.1.5

package/lib/novel-to-game/skills/game-world-design/references/world-design-method.md

@@ -0,0 +1,124 @@
+# 游戏世界设计方法
+
+## 先写可被推翻的体验假设
+
+把每条体验支柱写成玩家动作、可见变化和失败现象，并尽早放进一段粗糙但完整的切片。先解决最危险
+的体验问题，再增加内容和包装；时间或资产冲突时，保护最能体现原作转化的玩家动作。
+
+验证路径只记录输入、状态、反馈、结果和重开。主观喜欢与否不是机器结论。
+
+原型保真度只覆盖最大风险：`narrative-led` 可用文本/场景白盒验证知识、承诺与回响；`system-led` 可用
+回合状态板验证资源、门槛与反制；`hybrid` 让两层在最短路径中互相读写；实时动作、视线、导航、物理或
+镜头风险直接进入目标引擎灰盒。不能用文字顺畅证明操作、空间或镜头成立。
+
+## 类型合同与因果循环
+
+只写影响玩家决策的类型规则。回合制关心信息、行动顺序和结算；实时动作关心输入、时机、空间与
+恢复；经营关心时间、资源流和延迟反馈；叙事关心信息权限、介入时机、不可撤回选择和人物回响。
+不要把任何一套字段固定给所有项目。
+
+关键规则都用同一因果句描述：
+
+```text
+当前状态 + 玩家选择 + 世界规则 → 新状态 + 可读反馈 + 后续选择变化
+```
+
+对关键动作补齐稳定 id、前置条件、确定性效果、观察者/知情者、揭示或消耗、不可突破不变量与后续回读。
+只对秘密、证词、欺骗和关系误判等高风险事实维护 `world fact / player knows / character knows or believes`；
+不要为普通事实制造多层心智模型。
+
+短循环闭合一次动作和即时反馈，长循环组合多个动作并带来新压力、信息或阶段结果。优秀玩家与新手
+的差异可以是操作、资源判断、空间阅读、人物判断或一次性知识；只有项目承诺复玩时才要求可再生的
+不确定性。
+
+## 身份专属命令、执行链与延期回响
+
+只有 CONCEPT 选中 `signature_command` 时才设计本节。先定义一项身份动作和最小有限意图，不从通用聊天
+框开始：
+
+```text
+玩家表述 → 解析候选 → 缺槽/歧义/冲突处理 → 规则验证 → 执行阻力 → 提交实际结果
+→ 反馈证物与知情者 → 到期后果重新进入决策面
+```
+
+GAME_DESIGN 固定写出 `id / label / intents / slots / validators / commit` 六组最小结构；具体意图、槽位、
+验证器与提交项服从本项目，不设跨项目固定数量。候选动作可按项目包含执行人、动作、对象、物件、地点、
+可见范围、期限等；不要求所有项目共享同一字段全集。否定、条件、互斥要求或超出支持语义时澄清或拒绝，
+不靠命中关键词静默改成相反行动。
+规则器分别裁决资源、执行人在场/意愿、空间权限、人物知识、冲突承诺与原作边界，因此实际结果可以是
+完成、部分完成、拒绝、走样或泄露。反馈并列“你的安排 / 实际执行 / 留下的物与见证 / 后续到期事项”，
+不能只用一段生成叙事掩盖结算。
+
+延期事项至少声明来源行动、到期条件、携带的执行人/物件/见证/承诺、当前状态、重新上桌方式和结清事件；
+它必须在到期时改变当前选择或要求再次裁决，不能只追加一句装饰回声。若私人谈话也是玩法通道，谈话只
+提出事实、承诺、权限、拒绝和见证候选，经同一规则验证后进入事件账；原始聊天文本和模型数值都不是状态
+权威。
+
+## 决策深度与能动性
+
+为最重要的决策写一个代表性例子：列出可选动作和至少两种真实局面，说明为什么原本合适的动作会在
+另一局面失效。不存在跨局面永远正确的默认动作，玩家也能从界面、空间、人物或前路信息预判后果。
+
+不要用固定选项数、百分比阈值或跨项目数值比冒充深度。项目先声明什么现象表示取舍不存在，再用
+实际规则和代表路径去证伪。
+
+玩家能动性同时要求：选择改变事情的原因或方向，结果又会回读玩家做过的具体事。总分、旁白总结、
+随机救场或花资源放行既定剧情都不能代替这两项。
+
+## 世界必须主动回应
+
+作为卖点的规则不能只供玩家单向利用。对手、环境或人物至少读取一种玩家状态并改变策略：敌人根据
+站位或资源反应，环境根据工具改变路线，人物根据承诺、证词或旧账主动试探、提条件、抢先公开或
+拒绝。只会等待玩家点击、始终完整回答或按固定脚本行动的对象没有形成对抗。
+
+所有随时间增长的资源、等级、好感和进度，都要带来新的决策类型、可达空间、人物行为或组合方式；
+只涨读数就是空转。
+
+## 系统与内容预算
+
+第一版只保留一个核心系统、最多两个支持系统和一个标志性场面。库存、制作、技能树、天气、开放
+世界和额外关系线只有在增加核心决策时存在；自动替玩家处理后体验不变的成长系统应删除或降级。
+
+角色与事件按承诺分层：
+
+| 层级 | 最小深度 |
+|---|---|
+| 氛围人物 | 身份、位置、可辨识反应 |
+| 支持短线 | 自身诉求、一次有后果的选择、一次下游回响 |
+| 核心路线 | 多阶段关系、独立筹码、高潮与结局回收 |
+
+短线先证明会产生后续差异；升级为核心路线是新的产品范围，不由内容数量自动决定。
+
+## 关卡与场景节拍
+
+用“教会 → 变式 → 组合 → 检验 → 命运回收”组织最短闭环：
+
+1. **教会**：给清楚目标，让玩家尽快做出核心动作并看到后果；
+2. **变式**：改变空间、信息、对手意图或资源，使机械重复失效；
+3. **组合**：让两个已知规则产生原作特有的场面或取舍；
+4. **检验**：减少提示，让玩家迁移所学，并显示失败原因和可改之处；
+5. **命运回收**：结果读取玩家的关系史、知识、资源与关键选择，而非只看一个总分。
+
+逐拍用最省事的默认打法走一遍；若忽略该拍规则仍得到近似结果，就给它一条可见的局面约束，或把
+这拍删掉。修复优先复用已教系统，不为中段另造新系统。
+
+## 空间、首屏与反馈
+
+每个空间说明镜头可见范围、主路线、可选风险路线和地标。第一帧只保留一个主要焦点；次级面板的
+折叠、隐藏或常驻都要有触发或产品理由。
+
+核心动词的输入、画面/声音反馈和状态变化应在同一节拍内闭合。高压后安排恢复；失败说明发生了什么
+以及玩家下次能改变什么。优先通过空间、人物反应和后果传递设定，不用百科文本替代世界响应。
+
+叙事承载体验时的场景、知识、分支和人物方法见
+[narrative-design-method.md](narrative-design-method.md) 与
+[dialogue-design-method.md](dialogue-design-method.md)。
+
+## 白盒试玩与局部修订
+
+白盒运行至少留下初始状态、内容/规则版本、seed、输入序列、事件日志与终态摘要。每次反馈定位为：
+`观察位置 → 预期/实际差异 → 状态/动作/知识/回响节点 → owner → 最小修改 → 重放路径`。自然语言可表达
+问题，问题标签便于聚类，结构化字段只修改被定位的节点；不要每次重写整份设计。
+
+文本、标签与表现资产通常可局部替换；变量语义、节点 id、行动效果、知识权限或不可逆承诺改变时，声明
+存档/日志迁移或明确失效。修订后先重放原失败路径，再跑一条会揭露分支污染的相邻路径。

package/lib/novel-to-game/skills/novel-game-analyze/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: novel-game-analyze
+description: "Deconstruct a novel for game adaptation. Compress a raw novel, deconstruction library, or writing project into a SOURCE_BIBLE with cited textual evidence, extracting world rules, player verbs, spaces, character will, systems, and visual anchors — without inventing a genre yet. Use for gameable book analysis, analyze a novel for game adaptation, extract game systems from a book. 游戏化拆书。把原始小说、拆文库或写作工程压缩成有必要原文证据的 SOURCE_BIBLE，提取世界规则、玩家动词、空间、角色意志、系统和视觉锚点，不提前发明游戏类型。用于游戏化拆书、分析小说的游戏改编基础等需求。"
+---
+# 小说游戏化拆解
+
+建立游戏设计所需的事实层，不评价文笔，也不在此阶段选择游戏类型。
+
+读取 [gameability-protocol.md](references/gameability-protocol.md)。
+
+产物语言由 `PRODUCT_BRIEF.md` 锁定；未锁定时跟随对话语言，不默认产出中文。
+
+原文可以是任意语言。引用保留原文；策划语言或界面语言与原文不同时附必要译文，并建立角色名、
+地名、物件和规则的统一术语表；礼制、宗教和叙事惯例不替换成另一文化的近似类型标签。
+
+## 输入
+
+优先复用现有写作工程或**全量**拆文产物，只回原文补关键证据；只有原始小说时才执行
+本 skill 的全书管道。已有分析若只覆盖黄金三章或快速预览，只能帮助判断开篇，不能
+证明理解了全书。除非用户明确只改编某一卷或片段，否则来源未覆盖全文时不得进入概念设计。
+
+不因目录看起来完整就直接信任；按协议「来源清点」清点来源与已有拆文后，再判定是否算全量。
+
+若存在 `PRODUCT_BRIEF.md`，先读取：分级、核心幻想与已锁类型决定取证优先级——优先为
+核心幻想涉及的动作、关系、场面取证；对已锁类型需要而原作未系统提供的体系（如属性相克、
+数值成长），在设计空白中写明「原作无系统化的对应体系，属下游发明」，供下游改编边界如实
+引用。仍不在本阶段发明或评价类型。
+
+## 全书管道
+
+建立边界 → 逐单元提取 → 覆盖门禁 → 分层聚合 → 回查原文 → 压缩交付。各步做法以
+gameability-protocol.md 为准，此处只列顺序，不重述。选定改编段落的核对在概念选定后二次
+进入时做，产出逐事实表（见「输出」）。工作卡只服务覆盖、恢复和复核，不把过程日志包装成策划成果。
+
+可以在运行时并行处理互不重叠的章节批次，但每批必须使用同一提取契约，聚合和事实回查
+保持串行。环境不支持并行时逐批串行完成，不能改成抽样。
+
+## 提取维度
+
+只保留会影响玩家动作、世界响应或视听身份的内容；字段以协议「逐章游戏化卡」的十行为准，不得
+只取其中一部分，该表即并行批次共用的提取契约。另记不可改的原作事实、授权风险和原作未定义的设计空间。
+
+若作品反复出现命令、委托或代办，同样落回既有十行：记录谁有资格下令、谁实际执行、所需权限与物件、
+可能拒绝或走样的环节、谁会见证，以及什么债务或后果会延期返回。此阶段只提取身份动作的原作依据，
+不预设运行时必须有自由输入，也不把一句命令直接等同于事情已经发生。
+
+为硬规则、关键角色目标、玩家身份依据、转折结局和标志性锚点记录章节或文件位置。
+普通候选项不必机械附带置信度对象；推断必须明确标成推断或开放设计空间。
+
+## 输出
+
+生成一份 `analysis/SOURCE_BIBLE.md`，包含来源范围、**全书覆盖**、世界身份、原作事实与
+证据、改编边界、玩家身份候选（PRODUCT_BRIEF 已锁身份时改为该身份的动作空间验证）、
+可玩动词、可下达/承接的身份动作及其执行阻力、世界模型、空间与角色能动性、文化语境、
+术语表（语言条件见上）、视觉锚点、风险和设计空白。全书覆盖按连续范围列出每一阶段的关键变化、
+强弱节奏、反例/回收与游戏化意义，
+表头写明来源单元数与成功数，使覆盖集合与来源单元集合完全一致。短表格优先于重复文档、
+结构化数据和证据索引。
+
+改编边界必须是表格：`条目 | 边界类型 | 证据位置`，边界类型只用协议的四种标签；涉及
+名分、座次、官阶或队伍序列的作品必须附人物名册行（`姓名 | 身份/次序 | 结局 | 证据回目`），
+作为下游各交接门逐项比对的名册基准。
+
+概念阶段选定改编段落后，二次进入本 skill 为该段落补一张逐事实表并追加进 SOURCE_BIBLE：
+`事实 | 证据位置 | 边界类型`，含入镜角色的外观要点（服饰、兵器、体量及位置；原文无描写
+写「原文未明确」）。此表是下游交接门的段落级比对基准；下游仍可回原文补证，发现出入时
+回上游修正此表，不得各自改写。追加这类原作事实与证据是概念选定后对 SOURCE_BIBLE 的
+唯一允许更新——SOURCE_BIBLE 不得包含下游发明物，游戏状态键名、回合或日程编号、
+scene_id、Hub/界面结构、QA 与范围计划只属于 GAME_DESIGN，不得把既有事实改写成
+切片说辞。
+
+来源范围只记录会影响复核的版本、覆盖范围和授权边界。下载日期、字节数、校验值和
+本地路径只有在复现契约确实需要时才写，不把获取日志当策划内容。
+
+完成前确认：覆盖数与来源数一致且无未处理失败；核心规则可追溯；改编边界成表且证据位置
+齐全；能回答玩家可能做什么、在哪里做、世界如何回应；理解开篇、中段、结局和跨段回收；
+没有把一次性剧情冒充核心循环，也没有提前选定游戏类型。

package/lib/novel-to-game/skills/novel-game-analyze/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Gameable Book Analysis"
+  short_description: "Extract gameable canon from a novel · 从小说中提取可玩的原作事实"
+  default_prompt: "Use $novel-game-analyze to extract a source bible this novel's game design can build on."

package/lib/novel-to-game/skills/novel-game-analyze/references/gameability-protocol.md

@@ -0,0 +1,65 @@
+# 游戏化全书拆解方法
+
+长篇分析采用稳定边界、逐单元提取、分层聚合和原文回查。这里只提炼游戏设计事实，不评价文风，
+也不提前选择游戏类型。
+
+## 一、来源与覆盖
+
+记录作品版本、改编范围、单元边界、缺失部分和授权边界。除非用户明确限定范围，分析集合应与
+来源边界集合一致；无法读取的部分要标为部分分析，不能用抽样冒充全书覆盖。
+
+长篇可把稳定边界表写入 `analysis/_coverage.md`，用于分批、恢复和缺号检查。已有拆文产物只有在
+逐单元覆盖与原文边界一致时才可复用为全量分析；临时工作卡完成聚合后可以删除。
+
+## 二、逐单元游戏化卡
+
+每个单元使用同一紧凑记录；没有新信息时写“无新增”，仍计入覆盖：
+
+| 字段 | 只记录什么 |
+|---|---|
+| 客观变化 | 谁做了什么，哪项状态、关系、资源、位置或认知因此变化 |
+| 动作候选 | 可被玩家重复执行且允许选择、反馈或熟练度差异的动作；含有原作依据的命令、委托或代办 |
+| 规则证据 | 触发条件、代价、例外、反制和可观察后果 |
+| 行动者 | 目标、默认行动、资源、底线、可下达/承接的事及其变化 |
+| 空间 | 入口、出口、门槛、地标、风险和可改变部分 |
+| 物件与能力 | 输入、效果、限制、归属和是否只出现一次 |
+| 知识与信息差 | 谁知道、误信、隐瞒或说谎，靠什么载体建立 |
+| 节奏与感受 | 压力怎样建立、释放或反转，玩家通过何种行动感受 |
+| 视听锚点 | 有原文依据且服务识别或反馈的轮廓、材质、声音和场面 |
+| 证据与边界 | 原文位置、推断、冲突、未定义和衍生混入风险 |
+
+逐单元卡不是剧情摘要。评价句应改写成可观察事实及其造成的状态变化；删除“游戏化意义”后若
+只剩剧情复述，就继续压缩。
+
+## 三、从事实得到系统候选
+
+不要把叙事元素自动映射成类型。对反复动作、世界规则、关系、地点、信息差和情绪承诺分别问：
+玩家能做什么决定，世界如何反馈，什么状态会持续到下一步，重复后能否产生学习或不同结果。
+一次性高潮可以保留为标志性场面，不能假装成核心循环。
+
+对命令或代办再区分：提出者想做什么、实际执行者能做什么、经过哪些人物/空间/权限、留下什么证据与
+见证、何时重新成为问题。原文中反复成立的“下令不等于办成”可成为系统候选；单次传话不能据此推断
+通用自由输入或完整委托系统。
+
+原作事实只用四种边界：`immutable`、`adaptable`、`open`、`conflicted`。玩家身份未锁定时，
+比较主角、原创角色、势力或聚落、观察者能访问的动作和决策空间；已锁定时只验证该身份。
+
+## 四、分层聚合
+
+按三层压缩：
+
+1. **单元层**：保留局部事实、变化和证据位置；
+2. **阶段层**：按剧情目标、地点、能力阶段或规则簇整理压力、转折和可重复结构；
+3. **全书层**：找反复成立的因果、角色能动性、空间语法、情绪承诺和独有视听身份。
+
+全书层主动找反例和最终回收，避免把只在开篇成立的现象写成硬规则。秘密、谎言、证词或立场
+冲突驱动原作时，再整理知识权限和铺垫回收；原作没有这类结构就不为凑表格编造。
+
+## 五、事实保真与交付
+
+数值、能力边界、人物关系、死亡和结局必须回查原文。聚合结论引用最早建立、典型运作、重要
+反例和最终回收位置；冲突保留各自证据并标为 `conflicted`，未定义内容进入开放设计空间。
+角色断言不自动等于世界事实，相邻实体的属性也不能互相挪用。
+
+`SOURCE_BIBLE.md` 只保留会影响概念选择的事实、边界和必要证据。交付时确认来源范围明确、
+覆盖集合完整、核心规则可追溯，并能回答玩家可能做什么、在哪里做、世界如何回应。

package/lib/novel-to-game/skills/novel-to-game/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: novel-to-game
+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 写作工程转成有原著依据、可在目标平台完整游玩的游戏，编排游戏化拆解、概念选择、游戏与视觉设计、目标运行环境构建和证据化质量验证。用于小说转游戏、把这本书做成游戏、把小说改成互动小说 / 互动叙事 / 文字冒险游戏等需求。"
+---
+# NovelToGame 总入口
+
+你是小说游戏化总导演：守住改编判断、阶段边界和完成证据，不把普通原型包装成趣味、平衡、权利或
+发布质量结论。开始前读取 [pipeline-contract.md](references/pipeline-contract.md)。
+
+## 默认策略
+
+先速读来源并替用户起草 `PRODUCT_BRIEF.md`，再按
+[intake-method.md](references/intake-method.md) 只处理会实质改变方向或带来权利、尺度、平台风险的
+歧义。低风险空白集中列为未确认假设，不逐项拦停。
+
+`targetFinish` 只表示想做到的成色：`graybox`、`playable-prototype`、
+`polished-vertical-slice` 或 `showcase`。所有项目使用同一最小 QA：真实启动、渲染、输入、核心循环、
+至少一个设计结果和重开。连续 3D、语音、生成媒体、多语言或无障碍只在实际采用时运行项目自己的
+效果回归，不形成第二套验收等级。
+
+`PRODUCT_BRIEF.md` 与 `SOURCE_BIBLE.md` 是上游事实，下游不得静默改写。brief 必须锁定平台、生产
+引擎、实际交付物、目标运行时和可用的实际测试运行时。工具链不可用时，只能使用 brief 已批准的
+替代运行时；替代结果不证明目标平台已通过。
+
+## 模式
+
+- `quick`：默认；用推荐草案推进，比较三个概念后自动选择并完成全流程。
+- `director`：给出三个概念和推荐后停靠，等待用户选方向。
+- `resume`：读取 `_progress.md` 和实际产物，从最早未完成的交接继续。
+
+## 流程
+
+1. 建立工作区，记录来源、模式、当前阶段和未确认假设。
+2. 生成 `PRODUCT_BRIEF.md`；高风险歧义未解决时才停靠。
+3. 调用 `novel-game-analyze` 生成有原文依据的 `SOURCE_BIBLE.md`。
+4. 调用 `game-concept` 生成三个真正不同的方向并选定 `CONCEPT.md`；同时判断是否存在一项值得开放的
+   角色专属命令，实时/空间/精确操作不适合时明确 `N/A`；`director` 在此停靠。
+5. 调用 `game-world-design` 生成 `GAME_DESIGN.md`，其中锁定最大设计风险与最小可执行切片。
+6. 在完整美术生产前调用 `game-build` 做与风险匹配的白盒候选：叙事风险用状态/场景沙箱，系统风险用
+   回合或桌面板，实时操作与空间风险直接用目标引擎灰盒。固定初态、seed 与输入序列试玩；把偏差定位到
+   具体状态、动作、知识边界或回响，再交回 design owner 局部修订并重放受影响路径。
+7. 调用 `game-art-direction` 生成 `ART_DIRECTION.md`；只有目标成色需要时再制作视觉目标包。
+8. 再由 `game-build` 将验证后的因果语义实现为完整候选，`game-qa` 验证最小闭环；问题按
+   product/design/art/build 归属回流，不让实现阶段静默重做策划。
+
+编排器只记录两项完成结果：
+
+- `scope`：上游范围和阶段 owner 齐全且不冲突；
+- `playable`：六项最小玩家效果均有真实运行证据。
+
+## 语言与文化
+
+接受任意语言小说。产物使用用户指定语言，未指定时跟随对话语言；原文证据保留原语言，跨语言只补
+决策所需译文并维护一个术语表。原作文化语境、目标市场和界面语言分别记录，不用逐字翻译替代本地化判断。
+
+## 不可删除的判断
+
+- 剧情必须转成玩家动词、选择和世界反馈，而非逐章复演。
+- `experienceProfile`（`system-led` / `narrative-led` / `hybrid`）由 brief 起草、概念阶段确认，之后
+  贯穿设计、美术、构建与 QA；它只改变判据表达，不降低完成要求。
+- 玩家选择要拥有因果权与结算权，不能用卡牌、回合或资源条伪装能动性。
+- 概念、体验/关卡设计、美术方向分别拥有自己的批准边界；构建只能实现，不能暗中重选方向。
+- 低保真原型服从最大风险而非统一做成文游；它只证明被实际模拟的叙事、规则、空间或操作问题。
+- 生成模型可以解释输入和写表达，状态提交、知识披露、资源结算与不可逆承诺必须由可重放规则裁决。
+- 自然语言只在能体现玩家身份的专属命令上按需开放；它先编译成有限候选，再经过执行阻力、规则提交、
+  证物/见证反馈与延期回响，不能退化成通用聊天或“说了就发生”。
+- 验证切片必须在实际运行环境中完整走通；范围服从 brief，不默认扩成长篇全量游戏。
+- 完成以运行、画面、真实输入、结果和重开证据为准；AI 不能客观证明趣味、长期平衡或商业价值。
+
+六项必需检查全部 PASS 才报告当前候选完成最小 QA。`NOT_RUN` 可以诚实结束本次执行，但不能满足
+完成声明；`qa/verification.json` 是唯一机器事实源。

package/lib/novel-to-game/skills/novel-to-game/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "NovelToGame"
+  short_description: "Turn a novel into a playable game · 把小说转成可玩的游戏"
+  default_prompt: "Use $novel-to-game to turn this novel into a fully playable game on the most suitable target platform."

package/lib/novel-to-game/skills/novel-to-game/references/intake-benchmark-reference.md

@@ -0,0 +1,42 @@
+# 玩法先例与平台约束参考
+
+本参考帮助 intake 给出可执行默认值，不维护游戏名单、销量排名或按语言划分的固定市场表。
+
+## 先分开四个问题
+
+- **原作语言与文化语境**：决定术语、人物关系和文化符号如何保真。
+- **目标市场与界面语言**：由用户用途、发行计划和受众决定，不从原作语言自动推出。
+- **玩法先例**：证明玩家会反复做什么、循环怎样产生取舍，不要求题材相同。
+- **视觉参考**：只约束构图、材质、色光或信息密度，不自动成为玩法先例。
+
+## 最小先例选择
+
+先选一个最接近核心动词与循环结构的**主要玩法先例**。只有它无法回答另一个独立风险时，才补一个
+辅助先例；不要为凑数量建立对标矩阵。
+
+每个被采用的先例只记录：
+
+`作品 | 解决的问题 | 借用的动词/循环/结构 | 明确不借 | 事实来源或不确定性`
+
+- 先例用于解释玩法可识别性，不要求提供销量、在线峰值或评论数量。
+- 题材相似但玩法不同只能帮助文化或视觉判断，不能冒充玩法先例。
+- 互动叙事是成熟玩法：读局面、追问/调查、比对信息、表态或行动、承受回响都可成为核心动词。
+- 原作规则可以改变动作对象、顺序、代价和世界回应；先例是起点，不是禁止改编创新的模板。
+- 只核实会改变当前决定的外部事实。较新、小众或版本敏感信息用当前可靠来源；常识性玩法结构不
+  为了仪式感重复研究。
+
+## 平台只锁真实约束
+
+| 形态 | intake 要锁的约束 |
+|---|---|
+| PC / 主机 | 键鼠或手柄、目标性能、窗口/全屏、打包系统 |
+| 浏览器 | 首次加载、最低视口、鼠标/触控、静态托管或服务端边界 |
+| 移动 App | 朝向、触控、机型性能、安装包与离线需求 |
+| 小程序 / 小游戏 | 当前渠道包体、输入、联网、审核与分包限制 |
+
+平台能力、许可或渠道规格可能变化时查当前官方文档；仓库不保存版本号、价格或包体上限快照。
+
+## 交给概念阶段
+
+PRODUCT_BRIEF 只需写明主玩法、3–5 个候选核心动词、一个主要先例、目标平台和最大未知。若玩法仍
+有多个合理方向，把差异留给三个概念比较，不在 intake 提前锁死；低风险空白继续列为未确认假设。

package/lib/novel-to-game/skills/novel-to-game/references/intake-method.md

@@ -0,0 +1,51 @@
+# 需求 intake：先给推荐，再处理高风险歧义
+
+intake 的目的不是举行逐项审批会，而是尽早锁住会让下游返工的产品边界。先读来源，替用户写一页
+推荐草案；低风险空白列为未确认假设并继续，只有 materially branching 或安全相关决定才停靠。
+
+## 默认动作
+
+1. 速读到足以判断语言、题材、情绪内核、时代设定和内容尺度。
+2. 依据原作与用户用途给出一个完整推荐，而不是连续抛空问题。
+3. 只在平台、核心玩法、核心幻想、成人内容、真实人物、版权、资产授权、付费服务或不可逆制作投入
+   存在实质分支时停下来问。
+4. 其余未定项写进 `PRODUCT_BRIEF.md` 的「未确认假设」，标注推荐依据和影响；下游若要改变，回到
+   brief 显式修订。
+
+联网只用于会影响真实决定且可能变化的事实，例如当前引擎导出能力、许可证、渠道限制和新服务规格。
+不要为了给每个常识默认值找出处而把 intake 变成研究项目。
+
+## 产品框架
+
+填表前按需读取 [intake-benchmark-reference.md](intake-benchmark-reference.md)，用它选择同玩法先例、
+平台与视觉维度。引擎由目标交付物、团队现有工程、输入/显示、性能和导出约束决定；frontier 模型已知
+主流框架，不在仓库维护版本、价格或渠道规格目录。只有许可、导出能力或平台限制会实质改变决定时，
+才核实当前官方文档。
+
+| 维度 | 最小锁定内容 |
+|---|---|
+| 平台与形态 | 交付物、目标/最低显示模式、输入方式、性能预算 |
+| 市场与语言 | 目标市场、首发界面语言 |
+| 类型与先例 | 主玩法、一个主要玩法先例、3–5 个候选核心动词、空间形态 |
+| 主要承载 | `experienceProfile`：`system-led` / `narrative-led` / `hybrid` |
+| 美术与完成度 | 画风、`targetFinish`、参考维度、投入边界 |
+| 内容尺度 | 分级、成人内容范围与平台约束 |
+| 核心幻想 | 玩家扮谁、追求什么、何时产生什么情绪 |
+| 时长与结构 | 验证切片时长、单局/长线结构 |
+| 发行定位 | 买断、免费、N/A；只记录会影响玩法的部分 |
+| 引擎与运行时 | 生产引擎、目标运行时、可用的实际测试运行时 |
+| 玩家结构 | 单人/多人/异步/实时，以及切片内真实范围 |
+| 受众 | 硬核度、主要动机、上手与信息密度 |
+
+未适用的维度写 `N/A`，表示明确不做，不允许下游自行补默认。
+
+## 安全边界
+
+- 成人内容显式锁定上限和发行边界；不涉及真实人物，不性化任何未成年角色。
+- 目标与实际测试运行时分开；替代结果只证明实际覆盖层。
+- 参考只借已声明维度，不顺手搬入角色、UI、世界设定或未经授权资产。
+
+## 输出
+
+`PRODUCT_BRIEF.md` 一页写清十二维推荐、`targetFinish`、明确非目标、合规/权利边界、未确认假设和
+需要用户裁决的阻断项。只有阻断项为空才进入拆解；普通未确认假设不阻断 `quick`。

package/lib/novel-to-game/skills/novel-to-game/references/pipeline-contract.md

@@ -0,0 +1,65 @@
+# 流程契约
+
+## 最小工作区
+
+```text
+game-adaptations/{project}/
+├── PRODUCT_BRIEF.md
+├── analysis/SOURCE_BIBLE.md
+├── concepts/CONCEPT.md
+├── design/GAME_DESIGN.md
+├── design/ART_DIRECTION.md
+├── build/BUILD_BRIEF.md
+├── build/app/
+├── qa/verification.json
+└── _progress.md
+```
+
+按需增加 `_coverage.md`、视觉目标、资产账本和最小证据目录。所有机器状态只取 `NOT_RUN` / `FAIL` /
+`PASS`；`NOT_RUN` 表示没有证据，不能满足完成声明。
+
+早期白盒候选、可执行模型、事件日志、回放与 patch 只在项目实际需要时增加。可执行模型必须被当前
+候选运行时消费，或作为测试合同逐项对照实际规则；不能把整份 `GAME_DESIGN.md` 再抄成一份无人读取的
+JSON/YAML。设计理由仍由 `GAME_DESIGN.md` 拥有，运行状态与动作由实现拥有，实际发生记录由事件日志拥有。
+
+## 阶段 owner 与完成检查
+
+概念、体验/关卡设计、美术方向分别由 `CONCEPT.md`、`GAME_DESIGN.md`、`ART_DIRECTION.md` 的 owner
+负责；构建不得静默改写它们。编排器只检查：
+
+| 检查 | 成立条件 |
+|---|---|
+| `scope` | brief、source bible 和三份设计交接存在；范围、原作事实、目标运行形态、`targetFinish` 与 `experienceProfile` 不冲突 |
+| `playable` | `qa/verification.json` 的 `launch`、`render`、`input`、`coreLoop`、`outcome`、`restart` 均有真实运行证据 |
+
+`_progress.md` 只记录来源、模式、当前阶段、未确认假设、回流和这两项结果。详细测试状态留在
+`qa/verification.json`，不要复制到多份状态表。
+
+早期工作区缺少 `experienceProfile` 时，`resume` 按现有 `CONCEPT.md` 补记一次并继续；不得据此重做
+已批准概念。
+
+## 证据角色
+
+`qa/verification.json` 是唯一 QA 事实源。schema v3 只写整体状态、权威命令、一次 complete run、
+六项游戏效果 checks 和包含 `scope` / `reason` 的 limitations。目标运行环境与实际环境不同就如实
+记录，不能用替代运行结果冒充目标平台通过。
+
+构建只准备候选与 verify 入口，QA 只运行一次完整路径；不要求真人试玩、逐项人工批准、重复机器
+证据对象或第二份 QA 报告。
+
+白盒试玩是设计回流，不是第七道顶层 QA 门。反馈至少记录观察位置、玩家输入、预期与实际差异、受影响
+的状态/动作/知识/回响节点和 owner；修订后固定同一初态、规则版本、seed 与输入序列重放受影响路径。
+若节点 id、变量语义、动作效果或知识权限改变，必须迁移旧存档/日志或明确拒绝兼容，不能静默解释成新历史。
+
+`targetFinish` 描述成色，不改变最小 QA。预算或工具耗尽只会留下 `NOT_RUN` / `FAIL`、缩小范围或
+延期，不会生成 PASS。主观趣味、平衡、权利合规和发布质量不由机器事实确定。
+
+## resume 与回流
+
+`resume` 读取 `_progress.md` 和实际产物，从最早未成立的完成检查继续。QA 发现按 owner 回流：
+
+- product：回 `PRODUCT_BRIEF.md`；
+- design/art：修订批准文档后重建受影响范围；
+- build：修实现并复跑同一验证路径。
+
+品类认不出、体验弧不存在、核心前提未上屏不是小缺陷；停止打磨并请求产品裁决。