---
name: inbox-process
description: Use when processing inbox files, archiving eureka notes, updating bible from new information, running inbox workflow. 处理 inbox、处理 eureka、挨个跑 inbox 流程、处理并归档 inbox. 执行「处理 Inbox / Eureka」全流程（识别实体、更新/新建 bible 与 beat、Beat→Bible 反向同步、归档），归档为流程最后一步。
---

# Inbox 处理与归档

## 流程概览

```
阶段一：分析（只读，不修改任何文件）
  ↓ 输出分析报告，等待人确认
阶段二：执行（收到确认后）
  ↓ 更新/新建 bible 与 beat → Beat→Bible 反向同步 → 标记 TBD → 归档 → 输出摘要
```

---

## 阶段一：分析（不修改任何文件）

1. 完整阅读该 inbox 文件
2. 识别其中提到的所有实体（角色、世界观、节拍）
3. 对每个实体，判断需要执行什么操作
4. **暂停，输出分析报告，等待人确认**

### 分析报告格式

```
📥 Inbox 分析：{文件名}

**涉及实体**
- 角色：xxx、xxx
- 设定：xxx、xxx
- Beat：xxx（inbox 内容直接涉及具体场景或对话时列出）

**建议操作**
| 实体 | 类型 | 操作 | 具体内容 | 是否有冲突 |
|------|------|------|---------|-----------|
| 佩佩 | 角色 | 更新 | 年龄改为22岁，职称改为广告部画师 | ⚠️ 与现有年龄25冲突 |
| 原型 | 设定 | 无需变更 | inbox 内容已在 bible 中覆盖 | — |
| 新设定名 | 设定 | 新建 | 从模板新建 kb/bible/设定/xxx.md | — |
| 佩佩-维修1 | beat | 更新 | Fiction 补充医生台词 | — |
| 佩佩-维修4 | beat | 新建 | inbox 描述了新场景，尚无对应 beat | — |

**待人确认的判断**
- [ ] 冲突裁决：佩佩年龄 22 vs 25，是否以本次为准？
- [ ] 新建 beat 佩佩-维修4：Fiction 草稿是否符合预期？
- [ ] xxx

**请回复以下选项：**
- `执行全部` — 执行所有建议，冲突项记录到冲突表不自行解决
- `逐条确认` — 逐条列出，逐条回复是/否
- `跳过` — 不处理，直接移入 inbox/archived/，不更新任何 bible 或 beat
- 或直接告诉我你的修改意见
```

---

## 阶段二：执行（收到确认后）

### 步骤 1：更新或新建 bible 与 beat

**已有 bible → 更新**
- 将新信息加入对应 SSOT 小节，用 **加粗关键词** 领起，句末标来源
- 同步更新「叙事时间线」表格：新增剧情点、补全关联 Beat、更新状态
- 与现有信息冲突 → 在「冲突」小节记录两版 + 来源，不自行解决

**没有 bible → 新建**
- 角色：从 `template/tpl-character.md` 复制到 `kb/bible/角色/{名称}.md`
- 设定：从 `template/tpl-worldbuilding.md` 复制到 `kb/bible/设定/{名称}.md`
- 替换所有 `{{name}}`、`{{term_name}}` 占位符，不要写 Templater 标签
- 在 frontmatter 加 `created_by: ai`

**已有 beat → 更新**
- 若涉及 Fiction 内容：更新正文，在变更日志注明来源
- 若涉及 reveals：按步骤 2 的反向同步逻辑处理
- 若涉及 status 变更：更新 frontmatter

**没有 beat → 新建**
- 从 `template/tpl-beat.md` 复制到 `kb/beats/{id}.md`
- 替换占位符，填写 frontmatter 中能确定的字段
- Fiction 必须有至少一句话的草稿，不能只有 YAML
- 在 frontmatter 加 `created_by: ai`，`status` 设为 `draft`
- **新建后必须回到对应角色 bible 的叙事时间线加一行，状态标 `🚧 草稿`**

### 步骤 2：Beat → Bible 反向同步

若 reveals 包含角色/设定的事实性信息（身份、关系、机制、规则），同步更新对应 bible 的 SSOT 区，并检查叙事时间线：

| 情况 | 处理方式 |
|------|---------|
| 叙事时间线已有对应行，内容一致 | 补上 beat 链接，状态改 `✅` |
| 叙事时间线已有对应行，内容有出入 | 状态改 `⚠️`，在冲突表记录 |
| 叙事时间线没有对应行 | 新增一行，状态标 `🆕 仅Beat` |

叙事时间线状态含义：
- `✅` 已落地：bible 与 beat 双向一致
- `🔹` 无Beat：bible 有、beat 未承载
- `🆕` 仅Beat：beat 有揭示、bible 未记录
- `⚠️` 有出入：双方内容/粒度不一致
- `🚧` 草稿：beat 为 draft 状态

### 步骤 3：标记不确定处

不确定的信息标记 `[#TBD: 说明]`，不要凭猜测写入 SSOT 或 Fiction。

### 步骤 4：归档 inbox 文件

确认主要内容已归纳到对应 bible 或 beat 后，在文件最顶部加归档 frontmatter，再移动文件：

```yaml
---
archived: true
archived_date: YYYY-MM-DD
aggregated_to: [佩佩, 原型, kb/beats/佩佩-维修1.md]
note: 可选；仅在不完整时写「内容已聚合，但XX部分未处理」
---
```

- `aggregated_to`（必填）：已聚合到的 bible/beat 条目名或相对路径
- `note`（可选）：仅当部分内容未处理时填写

| 情况 | 动作 |
|------|------|
| 内容已归纳到位 | 移入 `inbox/archived/` |
| 明显未落地 | **留在 inbox**，不归档 |
| 不确定是否完整处理 | `note` 注明未处理部分后移入 archived |

### 步骤 5：git commit

```
git add .
git commit -m "inbox: 处理并归档 {文件名}，更新 {涉及实体}"
```

### 步骤 6：输出处理摘要

```
## 处理摘要 [日期]

### 新建
- kb/bible/角色/xxx.md（AI 新建，来源：{inbox文件名}）
- kb/beats/xxx.md（AI 新建，来源：{inbox文件名}）

### 更新
- kb/bible/角色/yyy.md：补充了{具体内容}
- kb/beats/zzz.md：Fiction 补充台词；叙事时间线状态更新为 ✅

### 无需变更
- xxx：inbox 内容已在 bible 中覆盖，无新增信息

### 发现的冲突
- [冲突主题]：版本A（来源）vs 版本B（来源），已记录到冲突表，待人裁决

### 已归档
- inbox/{文件名} → inbox/archived/{文件名}（aggregated_to: [xxx, yyy]）

### 需人类决定
- [ ] 问题1
- [ ] 问题2
```

---

## 约束（任何情况下均适用）

- **不自行解决冲突**：记录两版 + 来源，等人裁决
- **不做创意判断**：只做信息整理，不评价设定对错
- **不确定不写入 SSOT 或 Fiction**：标 `[#TBD]` 而非猜测
- **每次变更必须写 changelog**：日期、内容、来源三列必填
- **阶段一不修改任何文件**：收到确认前只分析不执行
- **AI 新建的文件必须标记**：bible 和 beat 均在 frontmatter 加 `created_by: ai`