mc-spec git:20261010.79a4f96A

Immutable. This exact content never changes and is served at /api/v1/blob/5d734e99985bd85d.

---
name: mc-spec
description: 把当前对话凝成规格文档。当 mc-grill 共识清单确认后、或用户说「写成文档 / 定个规格 / 沉淀成 spec / 归档这个方案」时激活：只综合本轮已拍板的决定，产出目标、范围、可验收行为条目、数据资源清单、平台约束、未决项与验收层级，供归档和 mc-review 对照。不开新提问——发现还有没问清的分支，先回去走 mc-grill。
---

# mc-spec — 对话凝成规格

一句话目标：把「我们谈定了什么」变成一份**零本会话记忆的人也能照做**的文档；之后的验收有锚。

## 规则先行

- **综合，不采访**：每条内容必须对应本轮对话里真实拍过板的东西，写不出来源的句子不许写。
- 还有未决分支 → 停，先 mc-grill 补完再回来；规格不藏问号，问号进「未决项」。
- 已代劳的 API / 版本取舍原样列入决定记录，带理由与回退。

## 文档结构（六节）

1. **目标与用户视角** —— 两三句「玩家能做什么 / 得到什么」，不写实现细节。
2. **范围** —— in-scope 与**明确 out-of-scope** 各一栏（防范围蔓延；没谈过的功能宁可立在这边）。
3. **行为条目** —— 每条写成可验收的「玩家做 X → 看到 Y」；一条一个分支，含糊的拆成两条。
4. **数据与资源清单** —— 方块 / 物品 / 实体 / 配方 / loot / lang 键（en_us + zh_cn）/ 模型纹理，逐项带注册名。
5. **平台与约束** —— 加载器 + 精确版本 + mappings 口径 + 物理端注意；这节直接决定实现选型。
6. **未决项与验收** —— 拍不了板的留此（每条写等谁定）；写明本改动按游玩测试阶梯要测到哪层（改玩家可见行为 ≥ L4+L5）。

## 落盘与接续

- 先输出全文给用户过目，**确认后**才写盘；默认 `<用户工程>/docs/spec-<主题>.md`，用户可改路径。
- 尾部固定两行：「验收时对照本文件跑 mc-review」「跨会话继续前先 mc-handoff」。