故事转游戏编排器
一句话定位：把「一段文本 IP」变成「可玩、可量化、可变现」的游戏——不是一句话换皮剧情摘要。
改编必须以源为本（每个设计决策引用源证据），且只在目标机真能跑通的 runtime 上证明（缺工具链不回退、不假装测过）。
〇、能力边界（能做什么 / 不做什么，严格对齐）
| 做 | 不做（红线） |
|---|---|
| 源文本 → 可玩 Web 游戏（静态/零依赖或 Node，浏览器直接开） | 不代清版权/IP 权利（只出权利链核验清单，商用前必须自行确认归属） |
| 章节级证据 + 命名 hard-veto + 6 项可重放 QA | 不夸大 QA：乐趣/平衡/其他设备/上线质量永远写 limitation，不标 PASS |
| 可玩性量化（难度曲线/分支命中/复玩率/时长偏差，Python 统计） | 缺目标工具链（如 Godot/Unity 本机没装）不悄悄回退成 Web，记 targetRuntime/testedRuntime 差异 |
| 商业化设计（付费点/定价/埋点，纯文档） | 不承诺销量/上线质量 |
| 多端输出设计 + 代码生成脚本（Web 可本机 build；引擎/移动出导出说明） | 本地化配音默认关（opt-in 外部 TTS，不上传源文本） |
| 轻联机（异步/双人）仅设计 | 实时多人/持续运营/原生主机端：不实现 |
开始前必答三问：① 源文本是什么（小说/漫画/剧本/品牌故事）？② 目标 runtime（Web 静态 / Godot / Unity / 移动，缺工具链要提前说）？③ 权利状态（公版 / 自有 / 需授权，需授权先核验）？
一、三纪律（继承层，逐字保留，这是护城河）
纪律 1：SOURCE_BIBLE 章节级证据
- 读全部源文本，写
analysis/SOURCE_BIBLE.md：每条硬规则 / 关键角色目标 / 转折点 / 结局 / 标志性锚点都带章节或文件位置引用。 - 源事实分 4 类标签：
immutable（不可改）/adaptable（可改编）/open（开放）/conflicted（冲突）。 - 源文本未定义的内容标「设计发明（design invention）」，绝不偷换为源事实。
- 引文与证据保留原语言，只翻译决策所需部分；一张术语表统一人名/地名/物/规则。
纪律 2：命名 hard-veto（概念阶段）
- 概念阶段比较真实备选方向，每个被杀方向写明触发哪条否决。6 条命名否决：
1. 核心循环忽视源文本中心张力；
2. 去掉专有名词后只剩通用模板；
3. 玩家只花资源去解锁固定剧情（无重复博弈）；
4. 关键张力在源文本里由外部裁定（玩家无法可靠操作）；
5. 机制依赖源文本没有的信息（凭空加 tell）；
6. 与源文本结局/核心承诺矛盾。 - 被杀方向逐条记录进
concepts/CONCEPT.md。
纪律 3：一次可重放 6 项 QA
- 构建后在tested runtime 上跑一次完整运行，同一 run 内证明 6 项：
launch / render / input / coreLoop / outcome / restart。 - 状态只有
NOT_RUN / FAIL / PASS；未验证不算通过，旧 PASS 被重跑覆盖。 - 乐趣/平衡/其他浏览器/版权/上线质量 → 写进
limitations（scope + reason），绝不 PASS。
二、流水线（7 阶段 + 1 商业化，对应 artifacts）
源文本 → 源分析(SOURCE_BIBLE) → 概念(CONCEPT, hard-veto) → 世界设计(GAME_DESIGN)
→ 白盒(风险匹配 ↺) → 美术方向(ART_DIRECTION) → 生产构建(BUILD_BRIEF + app) → QA(verification.json)
→ 商业化(MONETIZATION) → 可玩 + 可量化 + 可变现
每次运行产出一个自包含工作区 game-adaptations/<project>/：
PRODUCT_BRIEF.md # 一页需求：锁平台/引擎/目标 runtime/可测 runtime/权利状态/export_targets
analysis/SOURCE_BIBLE.md# 带引用源事实圣经（4 类标签）
concepts/CONCEPT.md # 概念 + 备选否决记录（哪条 hard-veto 杀掉谁）
design/GAME_DESIGN.md # 玩家承诺/核心循环/系统/关卡/失败/结局（引擎无关）
design/ART_DIRECTION.md # 镜头/色彩/光/HUD/声音 + 图像·配音 opt-in 决策
build/BUILD_BRIEF.md # 构建简报 + 唯一权威验证命令
build/app/ # 可运行源（Web 静态或 Node）
qa/verification.json # 6 项 QA + playability 段 + limitations + completeRun
monetization/MONETIZATION.md # 付费点/定价/埋点
_progress.md # 进度（resume 模式读它）
设计文档是引擎无关 Markdown，归用户所有；目标 runtime 由 brief 锁定，决定实现与 QA 环境。
三种模式
quick（默认）：agent 起草 brief，仅在平台/权利/成人内容等阻断项停下问，其余一路跑到 QA。director：停在概念阶段，给候选 + 推荐，让用户挑方向。resume：读_progress.md与真实存在的文档，算出最后真正完成的阶段继续；测试结论只从qa/verification.json读。
三、可玩性量化层（本技能独有，Python 统计，零外部依赖）
在 6 项 QA 之上，qa_run.py 额外统计并写进 verification.json 的 playability 段：
| 指标 | 含义 | 阈值未达标 → |
|---|---|---|
| 关卡难度曲线 | 各关通关率分布 | limitation（难度失衡） |
| 分支命中率 | 各选择被选/被弃比例 | limitation（玩家不感兴趣的分支） |
| 复玩率 | 重开是否走不同分支 | limitation（无复玩价值） |
| 时长偏差 | 实测通关时长 vs brief 目标时长 | limitation（节奏不符，参考 Plateau 55.2s 推翻 5–8min 案例） |
> 纪律：指标未达标写 limitation 不掩盖；「好不好玩」只给数据，不下主观结论（乐趣永远不算 PASS）。
3.1 项目级 limitation 扩展点
除脚本自动判定的条目外，每个项目必须自己交代真实短板。在项目根放 limitations.json：
{ "items": [ { "scope": "源证据等级", "reason": "…", "severity": "high|medium|low|blocker" } ] }
qa_run.py 会把它合并进 verification.json.limitations。
必须写明的 4 类：① 源证据等级（是否无章节引用/含【设计发明】）② 权利状态（未核验即 blocker，商业化阻断）
③ 未实现功能 ④ 多端导出的工具链缺口（哪些端只出设计不 build）。
四、商业化设计层（把"能玩"变"能卖"，纯文档）
monetization/MONETIZATION.md：
- 付费点位置：解锁分支 / 解锁角色 / 解锁结局 / 完整版。
- 定价逻辑：免费试玩 → 付费解锁 → 完整版阶梯。
- 数据埋点：哪个付费点转化最高（接可玩性的分支命中率数据）。
- 边界：只出设计，不承诺销量/上线质量；权利未核验的 IP 不出商业化方案（先补权利链）。
五、多端输出层（设计一次，多端复用；诚实标注能做/不能做）
PRODUCT_BRIEF.export_targets 声明目标端，构建按能力分层：
| 端 | 本机可做 | 诚实标注 |
|---|---|---|
| Web（静态/零依赖） | ✅ 本机可 build + 可跑 QA | 默认交付 |
| Web（Node 构建） | ✅ 本机可 build | — |
| Godot / Unity | ⚠️ 出引擎无关设计 + 导出说明 + 代码生成脚本 | 本机无工具链时不 build，写 targetRuntime≠testedRuntime limitation |
| 小程序/移动 | ⚠️ 出代码 + 说明 | 需对应 IDE/工具链 |
| 轻联机（异步/双人） | ⚠️ 仅设计 | 需 WebRTC/服务器，默认关 |
> 纪律（继承 novel-to-game）：缺目标工具链不悄悄回退 Web；用 brief 已批准的替代 runtime 时，targetRuntime/testedRuntime/未覆盖项分别记录。
六、权利链 + 本地化层（出清单不代清，源文本不上传）
- 权利链核验：输出「源 IP 归属 / 商用授权 / 素材 license / 是否涉真人」清单；不代清版权——商用前由用户确认。权利未核验的 IP 不出商业化方案（E3 阻断）。
- 本地化：继承「术语表 + 原语言引文 + 只译决策所需」；多语言/配音默认关，opt-in 时只送逐句对白，源文本与设计文档永不上传。
七、错误码（E0–E4）
| 码 | 含义 | 处置 |
|---|---|---|
| E0 | 未答三问（源文本/runtime/权利） | 先问后做 |
| E1 | 源证据缺失（关键机制无章节引用） | 回 SOURCE_BIBLE 补证据，不凭空发明 |
| E2 | 概念未过 hard-veto（触某条否决仍推进） | 退回概念，写明触发哪条否决 |
| E3 | 权利未核验即要商业化 | 阻断，先出权利链清单 |
| E4 | 目标 runtime 缺工具链 / QA 任一 6 项 FAIL | 记 targetRuntime≠testedRuntime；不回退不造假，列 limitation |
八、标准工作流（照做）
Step1 答三问 → Step2 源分析(SOURCE_BIBLE, 4类标签+章节引用)
→ Step3 概念(CONCEPT, 列备选+命名 hard-veto 杀方向)
→ Step4 世界设计(GAME_DESIGN: 承诺/核心循环/系统/关卡/失败/结局)
→ Step5 白盒(只测最大单一风险，结果回灌设计 ↺)
→ Step6 美术方向(ART_DIRECTION, 图像/配音 opt-in 决策)
→ Step7 生产构建(BUILD_BRIEF + app, 锁 runtime, 唯一权威验证命令)
→ Step8 QA(qa_run.py: 6 项 + playability + limitations, 同一 completeRun)
→ Step9 商业化(MONETIZATION: 付费点/定价/埋点; 权利未核验则 E3 阻断)
每阶段各写一份文档，build 阶段不得悄悄重做上游设计（继承纪律：concept/design/art 分阶段分文档，不可越权）。
九、边界与 FAQ
- Q 一定要多人/主机端吗？ A 不。MVP 交付可玩 Web 游戏 + 可玩性指标 + 商业化设计；多端/联机按
export_targets出设计，缺工具链只出脚本+说明，不 build。 - Q 数据/版权是真的吗？ A 权利链只核验不代清；源 IP 商用授权、素材 license 由用户确认；QA 证明「能跑+可量化」，不证明乐趣/上线质量。
- Q 和 novel-to-game 什么区别？ A 继承其三纪律做底座，补它明确不做/做不深的 5 层（多端/可玩性量化/商业化/权利链·本地化/轻联机）；它停在静态单局，本技能打「IP 试水→上线变现」的完整管线。
- Q 改编我没版权的 IP 行吗？ A 技能不代清版权，商用前必须自行核验权利链（E3）；学习/研究用途可在 brief 记权利边界。
十、版本历史
- 1.0.0（2026-10-01）：MVP 首发（收窄到本机 Node/Python 可跑通）。继承层（三纪律 + 7 阶段 + 6 项 QA + 3 模式 + 引擎无关 artifacts）+ 可玩性量化层（qa_run.py，零外部依赖）+ 商业化设计层（MONETIZATION）+ 多端/权利链/本地化/轻联机（出设计不出 build，诚实标注 limitation）。端到端 demo：番茄小说《槐蚀》→ 可玩 Web 游戏 + verification.json + 商业化设计（权利未核验，E3 标注仅研究用途）。
