# 当前邮件内容完整覆盖 ## 用途 确保当前邮件中每一项有业务意义的内容都有明确去向。不得因为已经匹配一个支持业务事件,就停止读取或静默丢弃同一邮件中的其他当前意图。 本规则是邮件级共享规则,优先于具体事件 reference。它不扩大任务卡能力,也不把当前不支持的内容伪装成 `Trace` 或业务人工复核。 ## 当前内容盘点 盘点范围包括: - `body_current` 中的请求、询问、安排、事实和告知。 - 当前附件、inline image、PDF、spreadsheet、OCR、表格和文件链接中的业务内容。 - 当前邮件明确继续处理的上文对象。 不作为独立业务内容: - greeting、signature、disclaimer 和纯礼貌文字。 - HTML 与 plain-text MIME alternatives 中语义相同的重复内容。 - quoted thread、forwarded old mail 和其他 history-only 内容。 一个连续请求即使跨多句话,仍作为一个意图;互相独立的请求必须拆开,并按当前证据顺序保留。 ## 完整覆盖不变量 每项有业务意义的当前内容必须且只能进入以下一个结果路径: 1. 匹配支持事件并安全处理:普通 `message_event`,包括 linked `Trace`。 2. 已匹配 active event 且业务类型和 subtype 已知,但参数、目标或证据不安全:保留该业务 `message_event` 并使用非空 `manual_review`。 3. 已确认存在 active 业务方向,但业务类型或 subtype 本身无法安全确定:输出 `event_type=Need Manual Review` 的 Fallback 复核。 4. 意图清楚但现有事件或任务卡不支持,且同邮件还有至少一个支持事件:最终 `unhandled_current_intents`。 5. 意图清楚但整封邮件没有任何支持事件:Main Agent 输出 `S10`。 6. 输入不足,无法判断是否匹配支持事件:Main Agent 输出 `S99`。 `Need Manual Review` 不是 active event,也不能用于满足 Main→Skill 调用门槛。路径 2 与路径 3 的区别是:路径 2 已知业务卡型,因此保留原业务 event;路径 3 连业务类型或 subtype 都不能确定,因此才使用 Fallback。 不得用 `relevant_message_excerpt`、源邮件仍可查看或 `extraction_warnings` 代替上述覆盖结果。 ## Main Agent 内部 unknowns 当同邮件已经匹配至少一个支持事件,以下当前内容进入素材包 `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": [] } ``` `case_keys` 只能使用当前证据或允许的历史证据唯一支持的值;不能唯一绑定时保持全 `null`。目标不清本身不阻止邮件级展示,也不得为了填写 key 而猜测。 ## 业务输出映射 `booking-desk-event` 必须把上述 `unknowns` 按原顺序一对一规范化到业务输出顶层 `unhandled_current_intents`: ```json { "category": "unhandled_current_business_content", "current_or_history": "current", "reason_code": "requires_business_approval_or_unsupported_task_card", "text_raw": "<当前证据原文>", "visible_message": "当前邮件包含未被现有任务类型覆盖的业务意图:<忠实中文概述>。请查看原邮件并决定后续处理。", "requires_user_decision": true, "case_keys": { "group_code": null, "confirmation_number": null, "reservation_number": null, "block_code": null }, "attachments": [], "file_references": [] } ``` 规则: - `text_raw` 必须原样保留,不得只留翻译或摘要。 - `visible_message` 必须忠实说明原意,不得增加批准、拒绝、执行或业务结论。无法安全翻译时使用“当前邮件包含未被现有任务类型覆盖的业务意图,请查看原文并决定后续处理。” - `requires_user_decision` 固定为 `true`。 - 只保留当前附件和当前 file reference;历史附件不得带入。 - `source_message_id` 只使用业务输出根对象中的值,不在 item 内重复。 - 该 item 不是 `MessageEvent`,没有 `event_type`,不得创建 TaskCard 或触发业务外部写入;整个最终结果按 00 契约执行 mandatory submit 不改变该边界。 ## 去重与边界 - HTML/plain MIME 重复、相同 OCR 重复和签名引用不得生成重复 item。 - 每个独立未覆盖意图一个 item;不得把不同问题压成模糊摘要。 - 已由主事件或 Trace 完整承接的内容不得再次进入该数组。 - 已确定的补充付款安排可以是 `Trace.payment_information`;询问酒店是否批准付款安排进入未覆盖意图。 - 内容不可读或语义不足时,不得伪装成清楚的未覆盖意图;按事件上下文使用 `extraction_warnings`、type-known business review、type-unknown Fallback review 或 `S99`。 - `extraction_warnings` 只承载解析、OCR、抽取和证据质量问题,不承载清楚但不受支持的业务意图。 ## 当前不支持的配额维护 - 独立新建 Allotment/Control Block 仍属于 active `New Booking`。 - 明确整块取消仍属于 active `Cancel Allotment`。 - 明确减少部分房量、修改部分日期或保留剩余配额继续使用,不再属于 active event;整封邮件只有该意图时输出 S10,与其他 active event 同现时进入 `unhandled_current_intents`。 - 无法判断是完整 Parent split/整块取消还是部分维护时,业务类型或 subtype 不明确,使用 Fallback 业务复核;不得生成 Parent Cancel 候选。 ## 示例 - 当前付款凭证 + “余款能否入住时支付”:输出 `Payment Evidence`,并输出一个未覆盖意图。 - “余款将在入住时支付”且目标唯一:输出 `Trace.payment_information`,不输出未覆盖意图。 - 当前只有清楚的付款政策询问,没有任何支持事件:Main Agent 输出 `S10`,不调用业务 skill。 - 历史中有审批询问、当前只有 `Thanks`:不得从历史生成未覆盖意图。