# Trace 与预订补充信息

## 定义

`Trace` 用于保存当前邮件中与具体预订对象相关、但不属于主任务核心参数的补充业务信息。

补充信息可以是要求、安排、备注或单纯告知。只要当前内容包含具体预订业务信息并能绑定目标，就生成 `Trace`；不要判断发件人是否明确要求酒店记录、执行或转交。

主任务已经完整表达的核心参数不得重复生成 `Trace`。例如 New Booking 的入住日期、房型和房量仍属于 New Booking；同邮件中的 meeting、meal、arrival notice 或 room preference 才作为补充信息生成 `Trace`。

## 触发条件

普通 `Trace` 必须同时满足：

- 信息来自当前邮件正文、当前附件、当前图片/OCR、当前表格或当前明确继续处理指令。
- 信息包含具体预订业务内容，不是只有礼貌或收件确认文字。
- 信息能唯一绑定 `group_code`、confirmation number、reservation number，或能关联同邮件中目标明确的主事件。
- 信息不属于主任务已经完整承接的核心参数。

历史内容只能补充目标 key 或解释当前信息，不能单独触发 `Trace`。

事件类型固定为：

- `Trace`

普通预订补充信息不再输出 `Note`。`Note` 仅为旧契约兼容保留，除非后续任务卡映射另有明确规则。

## 子类型

- `extra_bed`：同一 Trace 的全部条目都是 extra bed。
- `general_request`：包含任意非 extra-bed 条目，包括 mixed Trace。

## Trace 输出

`extracted_fields` 固定使用：

```json
{
  "trace_subtype": "extra_bed | general_request",
  "trace_text": "<按当前证据顺序合并的完整补充信息原文>",
  "trace_items": [
    {
      "category": "extra_bed | room_preference | room_setup | meeting | function | meal | transport | payment_information | general_information",
      "text_raw": "<单条原文>",
      "service_date": "YYYY-MM-DD | null",
      "service_period_raw": "FULL DAY | null",
      "pax": 110,
      "notify_departments": []
    }
  ],
  "notify_departments": []
}
```

规则：

- `trace_text` 必须完整保留所有补充信息原文，按当前证据中的出现顺序使用换行连接；结构化字段不能替代原文。
- `trace_items` 每条补充信息一个 item，顺序与 `trace_text` 一致。
- `category` 只能使用上述枚举；没有更具体类别时使用 `general_information`。
- `service_date`、`service_period_raw` 和 `pax` 只在当前证据或合法日期上下文可以唯一支持时填写，否则为 `null`。
- item 的 `notify_departments` 只保留当前证据明确指定或本规则可以唯一确定的部门；无法确定时使用空数组。
- 事件级 `notify_departments` 是所有 item 已知部门的去重合集；全部未知时使用空数组。
- `notify_departments` 为空不阻塞 Trace，不得仅因此输出人工复核。

## General Request

`general_request` 包括但不限于：

- Meeting、conference、function、banquet。
- Meal arrangement。
- Airport transfer 或其他 transport arrangement。
- Non-smoking、high floor、away from elevator、same floor 等 room preference。
- Honeymoon、房间布置、amenity placement 等 room setup。
- Guide arrival、到店安排、接待信息或其他具体预订补充事实。
- 已确定的补充付款安排，例如“剩余款项将在入住时支付”。
- 其他能绑定具体预订对象、且不属于主任务核心参数的补充业务信息。

以上是开放示例，不是封闭白名单。即使当前内容只是告知，没有出现 `please note`、`please arrange`、`please inform` 等动作词，也按本规则生成 Trace。

`payment_information` 只表示已经确定、需要随预订保留的补充付款安排。它不包括付款凭证、到账结果、Payment Notice、Invoice、催款、价格或付款条件审批询问；这些内容继续按各自业务规则路由，不得为了生成 Trace 任务卡而改名。

例如 New Booking `HD260510A` 同邮件出现 `12/5 FULL DAY Meeting 110 PAX` 时，额外生成 linked `Trace.general_request`，并保留：

```json
{
  "trace_subtype": "general_request",
  "trace_text": "12/5 FULL DAY Meeting 110 PAX",
  "trace_items": [
    {
      "category": "meeting",
      "text_raw": "12/5 FULL DAY Meeting 110 PAX",
      "service_date": "2026-05-12",
      "service_period_raw": "FULL DAY",
      "pax": 110,
      "notify_departments": []
    }
  ],
  "notify_departments": []
}
```

## Extra Bed

Extra bed item 使用通用 item 结构：

```json
{
  "category": "extra_bed",
  "text_raw": "<extra bed 原文>",
  "service_date": null,
  "service_period_raw": null,
  "pax": null,
  "notify_departments": ["FO", "HSK"]
}
```

同时继续在事件级 `extracted_fields` 保留原有业务意图字段，不得移动或删除：

```json
{
  "occupancy_update": "3adult",
  "requires_rate_update": true,
  "rate_adjustment_formula": "rate_code_price / 2 * 3"
}
```

只要合并后的 Trace 包含 extra bed item，就保留上述事件级字段；全部 item 都是 extra bed 时使用 `trace_subtype=extra_bed`，否则使用 `general_request`。

硬边界：

- 不计算最终价格。
- 不决定 Rate Code。
- 不把 extra bed 当 room quantity。
- 不把 `U-เตียงเสริม` 当 PMS room type。
- 原始 extra bed price text 只能作为 evidence。

## 部门规则

现有明确映射继续使用：

- Non-smoking、high floor、away from elevator、same floor：`FO`。
- Set Honeymoon、房间布置、amenity placement、需要 housekeeping 准备的要求：`FO` + `HSK`。
- Extra bed：`FO` + `HSK`。

Meeting、function、meal、transport、payment information 或其他类别没有明确部门映射时使用空数组，交由任务卡用户确认，不输出人工复核。

## 告知、礼貌文字与审批询问边界

以下当前内容生成 Trace：

- `FYI guide will arrive at 20:00` 等带有具体预订事实的告知。
- 已确定的安排或事实，即使没有要求酒店采取动作。

以下内容不生成 Trace：

- 只有 `Thanks`、`Noted`、`Received`、`FYI`、`confirmed receipt` 或同类礼貌/收件确认，没有任何具体预订业务信息。
- Booking Confirmation Request、`please confirm booking details` 或要求酒店核对并回复既有预订。
- 需要酒店批准或决定的价格谈判、退款、减免、豁免、账期、付款政策或合同条件询问。
- 例如“剩余款项可以入住时支付吗”属于付款政策审批询问，不是 Trace；“剩余款项将在入住时支付”属于已确定的 payment information，可以是 Trace。

不符合 Trace 但具有当前业务意义的内容不得静默忽略。必须在 Main Agent 素材包的 `unknowns` 中保留原文，并使用：

```json
{
  "category": "unhandled_current_business_content",
  "current_or_history": "current",
  "reason_code": "requires_business_approval_or_unsupported_task_card",
  "text_raw": "<当前原文>",
  "case_keys": {
    "group_code": null,
    "confirmation_number": null,
    "reservation_number": null,
    "block_code": null
  },
  "attachments": [],
  "file_references": []
}
```

同邮件存在至少一个支持事件时，按 `03-current-content-completeness.md` 输出到业务根对象的 `unhandled_current_intents`；整封邮件没有支持事件时由 Main Agent 输出 S10。未覆盖意图不是 Trace，也不创建任务。

## 独立、关联与合并

- 同一封邮件、同一目标对象只生成一个 `Trace`。
- 同一目标的多条补充信息合并进一个 `trace_text` 和多个 `trace_items`。
- 多个 `group_code` 必须分别生成 Trace，不得合并到数组型 `case_keys.group_code`。
- 独立 Trace 必须由当前证据或允许的历史证据唯一绑定目标。
- Trace 与 New Booking、Update Booking / Amendment 或 AMEND GROUP CODE 同现时，输出主事件和单独 linked Trace。
- linked Trace 保留 `related_source_event_index`、`related_event_type`、`relationship_type=linked_trace` 和 `requires_downstream_hard_validation=true`。
- 不得把 Trace 吞进主事件的普通备注字段。

## Cancel 边界

Cancel 行不会因为被取消对象历史上有补充信息就自动生成 Trace。只有当前邮件同时提供新的、需要保留的具体预订补充信息时才生成 Trace。

## 业务复核

当前证据已经能确定 `event_type=Trace` 和 `trace_subtype=extra_bed|general_request` 时，以下问题保留 `Trace` 及 subtype，并使用非空、完整的 `manual_review`：

- 当前信息无法唯一绑定目标对象。
- 历史目标候选冲突。
- 同邮件存在多个主事件，补充信息无法判断属于哪个目标。
- extra bed rate update 无法安全附着到目标。
- Trace 原文局部不可读，但可读部分已经足以唯一确定 Trace 和 subtype。

保留完整可读原文、`trace_items` 和目标候选；缺失字段使用 RFC 6901 JSON Pointer 写入 `manual_review.missing_fields[]`。

只有当前内容不可读到无法确定是否为 Trace、无法确定 `extra_bed`/`general_request` subtype，或 current/history 边界不清并且因此连业务类型或 subtype 也无法确定时，才输出 `event_type=Need Manual Review` 的 Fallback 复核。若 Trace 和 subtype 已知，只是当前证据边界仍需确认，则保留 `Trace` 并附非空 `manual_review`。

以下情况本身不构成人工复核：

- `notify_departments` 不清。
- `service_date`、`service_period_raw` 或 `pax` 缺失。
- 当前信息是要求还是单纯告知不清。