# 本局创作方案

## meta

```meta
name: 本局创作方案
id: creation-plan
artifact: 设计.本局创作方案
declaration: >
  先抽出用户要的核心体验，再主动找出有帮助的内容能力并分档，形成本局专用创作方法；它指导取舍，不规定固定流程。
when: |
  尚无本局创作方案，且用户已经给出有效创作方向；或用户改口、新增方向，导致现有方案明显不再成立。
when_not: |
  只是在既定方向内补充局部材料，现有方法与能力分档仍成立时，不重复改写。
boundary: |
  本能力只决定本局怎么做、哪些内容能力重要以及还缺什么；不代替任何能力生成正文，不安排 DAG，不进入游玩上下文。
feeds: design_only
```

## task

```task
根据用户当前材料生成或整份重写「本局创作方案」，写入 `设计.本局创作方案`。方案用于指导后续创作取舍：先定本局要兑现的体验，再形成针对这份体验的方法，并把程序提供的全部内容能力各分到一个档位。

先抽出核心体验，再扫能力目录找有帮助的能力，最后才写方法和分档。核心体验是用户想反复感到、扮演或达成的那一件事；从角色、限制、例子和题材里抽，即使用户没把它叫做体验。写进 `brief`。不要停在原话点到的题材词和能力名上。

然后用这份体验逐项看能力目录。用户没点名、但缺了会使体验立不住、持续不了或跑不起来的能力，标成「必须」或「有必要」，把还没选定的具体内容写进 `missing`。用户点到、却不承载这份体验的能力，降到「有一定效果」或「没有意义」。只写真实语义依赖；`items` 的排列不表示执行顺序，也不是本轮要写完的清单。缺口留给后续询问，不在生成方案的同一轮起草那些能力。

必须原样覆盖能力目录中的每个 `module_id` 各一次。目录外 id、本能力、机械工具节点和旧工序节点都不纳入。用户改变目标且旧方案不再成立时，按新的核心体验重写完整方案，不在旧 JSON 上追加补丁。
```

## principles

```principles
1. 配方必须针对抽出的核心体验：说明靠什么方法兑现它，不复述通用创作常识，也不复述用户点到的词表。
2. 四档按对这份体验和可运行性的贡献分，不按原话有没有出现这个能力：
   - 必须：缺少后无法运行，或核心体验会崩。用户没点名、但体验直接压在上面的能力也放这里。
   - 有必要：缺少仍可运行，但体验明显变弱。主动把有帮助、用户没提到的能力放这里。
   - 有一定效果：对体验有增益，缺了核心仍在。可顺带询问一次。
   - 没有意义：对这份核心体验没有帮助。不是「用户没提到」。
3. `why` 写该能力怎样服务抽出的核心体验；`missing` 只写仍会影响实施的具体缺口，没有则写空字符串。前三档里还没选定的做法，用能直接拿去问的具体选择写入 `missing`。
4. `instances` 只列已经能判断的具体实例需求；生成规则、具体实例等可反复能力可以列多项，其余通常为空数组。
5. 旧配方只能作为方法案例引用、混合或改写；公共规则不从案例复制进本局配方。案例里的档位倾向只供对照，与本局体验冲突时以本局体验为准。
6. 材料少时仍形成方案：从已有材料推断核心体验，不编造世界设定。推断出的有帮助能力照样上档，还没定的具体内容写进对应 `missing`。这些缺口在后续对话里按用户原话和已抽出的体验给 2～3 个选项询问，选定后再写对应能力。
```

## output

```output
{
  "schema": "creation-plan.v1",
  "技能": "本局创作方案",
  "brief": "一句话写出抽出的核心体验，以及靠什么兑现它",
  "recipe": {
    "primary": "主要创作方法",
    "secondary_traits": ["可混合的次要体验特征"],
    "method": ["针对本局的做法，不是固定节点顺序"],
    "references": ["采用或改造过的旧配方案例 id"]
  },
  "items": [
    {
      "module_id": "variable-design",
      "tier": "必须",
      "why": "任务时限与暴露度必须跨轮保存",
      "missing": "暴露度达到哪一档会被识破尚未确定",
      "instances": []
    }
  ]
}
```

硬规则：
1. 输出合法 JSON，`schema` 固定为 `creation-plan.v1`，`技能` 固定为 `本局创作方案`。
2. `recipe.method` 描述本局做法，不写节点序列、阶段编号或统一流水线。
3. `items` 必须覆盖程序给出的全部能力各一次；`tier` 只能是四档之一。
4. `why`、`missing`、`instances` 每项都必须存在；没有缺口时 `missing` 写空字符串。
5. 产物中不写自评分、追问、回复话术或游玩正文。

## score

```score
能力覆盖：
- 5：全部应覆盖能力恰好一次，排除项正确，档位合法。
- 3：主体齐全，但有边界能力误分、重复或理由过于笼统。
- 1：明显漏项，或纳入机械工具与旧工序节点。

配方针对性：
- 5：`brief` 里的核心体验能解释主要方法；用户没点名但承载体验的能力已在「必须」或「有必要」，换一个作品就不成立。
- 3：体验可辨，但分档仍主要跟着原话点到的词走。
- 1：只有用户原话的复述或泛泛原则，没有主动找出有帮助的能力。

依赖克制：
- 5：只表达真实语义依赖，不暗示固定执行顺序。
- 3：大体灵活，但夹有弱顺序或阶段暗示。
- 1：恢复成统一流水线或 DAG。

缺口可行动性：
- 5：前三档缺口具体，涉及选择时能给出明确实例方向。
- 3：部分缺口笼统，仍需再次解释才能行动。
- 1：缺口缺失、虚构，或变成无差别问卷。
```

## checklist

```checklist
- [ ] brief 先写出抽出的核心体验，而不是复述用户点到的题材词？
- [ ] recipe 是兑现这份体验的本局方法，而不是固定节点流程？
- [ ] 用户没点名、但缺了体验会明显变差的能力，已在「必须」或「有必要」，并写了具体 missing？
- [ ] 「没有意义」表示对这份体验没有帮助，而不是「用户没提到」？
- [ ] 能力目录中的每个 module_id 恰好出现一次，且没有目录外 id？
- [ ] missing 具体且不重复 why，没有缺口时为空字符串？
- [ ] 产物不含评分、追问、回复话术或游玩正文？
```