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."

# 需求 intake：先给推荐，再处理高风险歧义

intake 的目的不是举行逐项审批会，而是尽早锁住会让下游返工的产品边界。先读来源，替用户写一页
推荐草案；低风险空白列为未确认假设并继续，只有 materially branching 或安全相关决定才停靠。

## 默认动作

1. 速读到足以判断语言、题材、情绪内核、时代设定和内容尺度。
2. 依据原作与用户用途给出一个完整推荐，而不是连续抛空问题。
3. 只在平台、核心玩法、核心幻想、成人内容、真实人物、版权、资产授权、付费服务或不可逆制作投入
   存在实质分支时停下来问。
4. 其余未定项写进 `PRODUCT_BRIEF.md` 的「未确认假设」，标注推荐依据和影响；下游若要改变，回到
   brief 显式修订。

联网只用于会影响真实决定且可能变化的事实，例如当前引擎导出能力、许可证、渠道限制和新服务规格。
不要为了给每个常识默认值找出处而把 intake 变成研究项目。

## 产品框架

引擎由目标交付物、现有工程、输入/显示、性能和导出约束决定，不在这里重复平台常识。
玩法先例说明借用的动作与循环，视觉参考只约束声明的表现维度，两者都不以题材相似代替依据。
尚未选定的玩法留给概念阶段，不提前锁死。

| 维度 | 最小锁定内容 |
|---|---|
| 平台与形态 | 交付物、目标/最低显示模式、输入方式、性能预算 |
| 市场与语言 | 目标市场、首发界面语言 |
| 类型与先例 | 已锁玩法或开放方向、相关玩法先例、候选动作、空间形态 |
| 主要承载 | `experienceProfile`：`system-led` / `narrative-led` / `hybrid` |
| 美术与完成度 | 画风、`targetFinish`、参考维度、投入边界 |
| 内容尺度 | 分级、成人内容范围与平台约束 |
| 核心幻想 | 玩家扮谁、追求什么、何时产生什么情绪 |
| 时长与结构 | 验证切片时长、单局/长线结构 |
| 发行定位 | 买断、免费、N/A；只记录会影响玩法的部分 |
| 引擎与运行时 | 生产引擎、目标运行时、可用的实际测试运行时 |
| 玩家结构 | 单人/多人/异步/实时，以及切片内真实范围 |
| 受众 | 硬核度、主要动机、上手与信息密度 |

未适用的维度写 `N/A`，表示明确不做，不允许下游自行补默认。

## 安全边界

- 成人内容显式锁定上限和发行边界；不涉及真实人物，不性化任何未成年角色。
- 目标与实际测试运行时分开；替代结果只证明实际覆盖层。
- 参考只借已声明维度，不顺手搬入角色、UI、世界设定或未经授权资产。

## 输出

`PRODUCT_BRIEF.md` 紧凑写清上述产品边界、`targetFinish`、明确非目标、合规/权利边界、未确认假设和
需要用户裁决的阻断项。只有阻断项为空才进入拆解；普通未确认假设不阻断 `quick`。

# 流程契约

## 最小工作区

```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` 补记一次并继续；不得据此重做
已批准概念。

## 证据角色

构建准备候选与 verify 入口。QA 可诊断、修复后复跑；最终事实源原子记录当前同一次完整运行，
不拼接旧 PASS。不要求真人试玩、逐项人工批准、重复证据对象或第二份 QA 报告。

白盒试玩是设计回流，不是第七道顶层 QA 门。反馈至少记录观察位置、玩家输入、预期与实际差异、受影响
的状态/动作/知识/回响节点和 owner；修订后用可复现的初态与输入路径复查，随机性相关时固定 seed。
已有存档/日志因节点标识、变量语义、动作效果或知识权限变化而失效时，迁移或明确拒绝兼容，不能静默解释成新历史。

预算或工具耗尽只会留下 `NOT_RUN` / `FAIL`、缩小范围或延期，不会生成 PASS。

## resume 与回流

QA 发现按 owner 回流：

- product：回 `PRODUCT_BRIEF.md`；
- design/art：修订批准文档后重建受影响范围；
- build：修实现并复跑同一验证路径。

品类认不出、体验弧不存在、核心前提未上屏不是小缺陷；停止打磨并请求产品裁决。