--- name: booking-desk-event description: Use after the Main Agent has validated source_message_id and prepared at least one current-evidence-backed coarse candidate for a hotel booking desk email, attachment, image, PDF, spreadsheet, OCR result, or message thread. This skill has final authority over active event type, subtype, target splitting, linked/derived events, and type-known versus type-unknown business review. It outputs candidate MessageEvents and display metadata to the Main Agent only; it never calls the final-result submission MCP tool, creates TaskCards, or writes Opera/PMS. --- # 预订部业务事件识别 ## 1. 业务目的 用本 skill 读取 Main Agent 按 `references/04-main-skill-input-contract.md` 整理的当前邮件素材包,验证粗候选,并最终判断这封邮件里有哪些预订部业务事件。 它处理的不是一个固定任务类型,而是一封邮件可能带来的完整预订部动作和补充业务信息:新订、改单、取消、付款凭证、名单、改团号、Trace、TA Recorder、发票、控房/配额,以及无法安全处理时的人工复核。与具体预订对象相关的补充事实即使只是告知,也可以生成 Trace;意图清楚但现有任务类型无法承接的其他当前内容必须通过邮件级展示字段保留。 本 skill 对最终 active event type、subtype、目标拆分、事件合并和 linked/derived events 拥有唯一裁决权。Main Agent 的 `candidate_events` 只是内部粗信号,不是最终事件,也不要求一对一映射。 本 skill 只输出候选 `MessageEvent`、未覆盖当前意图展示信息、候选目标 key、抽取字段、证据和结构化人工复核原因。它不创建真实 TaskCard,不写 Opera/PMS,不确认 Payment,不更新 Reservation Type,不生成 Invoice 或 Receipt。 本 skill 不是公开最终结果 finalizer,绝不能调用 `th-hotel-simple-superagent_th_hotel_submit_task_res`。它只把业务根或内部 disposition 交回 Main Agent;只有 Main Agent/最外层 finalizer 在形成、校验并冻结公开 `final_result` 后调用一次 mandatory submit。 ## 2. 输入素材 期望 Main Agent 提供: - `source_message` - `body_current` - 当前附件、图片、PDF、Excel、OCR、表格和文件链接摘要 - 合法取得的 `body_thread_evidence` - 历史查询摘要,如适用 - 信息系统上下文摘要,如适用 - 符合 `references/04-main-skill-input-contract.md` 的 `candidate_events` - `unknowns` 中由 Main Agent 保留的未覆盖当前业务内容 - 不可读证据和冲突点 `source_message.source_message_id` 必须来自上游且为非空、非空白字符串;不得猜测。该校验是 Step 0,发生在正文、附件、历史和系统处理前。缺失或空白时不得继续业务处理,固定返回 `00-output-contract.md` 定义的 `infrastructure_input_error`。 Main Agent 只有在 `candidate_events` 至少包含一个 current evidence 支持的合法粗候选时才调用本 skill。`possible_event_types` 只能引用 `00-output-contract.md` 的 `active_emittable_event_types`;legacy event、review outcome、S10 和 S99 均不得进入粗候选。 业务 event type 和 subtype 已知但 current 证据、目标、字段、映射或 current/history 边界不安全时,不要猜:保留原 active `event_type`,并附非空 `manual_review`。只有 active 业务方向已确认、但 event type 或 subtype 仍无法确定时,才输出 type-unknown `Need Manual Review`。输入可理解但没有 active 事件时由 Main Agent 输出 `S10`;输入不足、无法判断是否存在 active 信号时由 Main Agent 输出 `S99`。 ## 3. 处理流程 1. 校验 `source_message_id`,并读取 `references/04-main-skill-input-contract.md` 验证素材包和粗候选。 2. 读取 `references/00-output-contract.md`,确认 active/legacy/review 三集合和输出结构。 3. 读取 `references/01-current-history-boundary.md`,确认 current 与历史证据边界。 4. 读取 `references/03-current-content-completeness.md`,确认当前内容没有被事件路由静默丢弃。 5. 读取 `references/02-event-routing-map.md`,选择最终业务事件。 6. 按事件类型读取 10-18 业务事件 references。 7. 涉及供应商表格、控房配额、房型、Rate Code、Fix Charge、手工价格或 stay date parsing 时,读取 30-54 规则 references。 8. 存在业务不安全点时读取 `references/90-manual-review.md`:类型已知则保留业务 event 并附 `manual_review`,类型未知才使用 `Need Manual Review`。 ## 4. Reference 分区 基础契约: - `00-output-contract.md` - `01-current-history-boundary.md` - `02-event-routing-map.md` - `03-current-content-completeness.md` - `04-main-skill-input-contract.md` 业务事件: - `10-new-booking.md` - `11-update-booking.md` - `12-cancel-booking.md` - `13-voucher-payment.md` - `14-rooming-list.md` - `15-amend-group-code.md` - `16-trace-notes.md` - `17-ta-recorder-note.md` - `18-invoice.md` 供应商和业务对象场景: - `30-qbd-liantai-workflow.md` - `31-allotment-control-block.md`:Allotment / Control Block、Parent Group identity 与完整 split 的权威定义 共享规则: - `50-room-type-mapping.md` - `51-rate-code.md` - `52-fix-charge.md` - `53-manual-rate-code.md` - `54-stay-date-parsing.md` 异常和人工复核: - `90-manual-review.md` ## 5. 硬边界 - 只有当前邮件证据能触发新的业务事件。 - 历史只能绑定目标、旧值或上下文,不能单独触发普通业务。 - Main Agent 的粗候选不是最终结论;本 skill 必须重新验证 current evidence,并对最终 event type、subtype 和拆分作唯一裁决。 - 只有 `active_emittable_event_types` 可以由当前邮件新生成。`legacy_accepted_event_types` 只读兼容,`business_review_outcomes` 不能充当粗候选。 - 一个事件只承载一个目标对象;同一目标可以同时有主事件和一个按目标合并后的 linked Trace。 - `Allotment / Control Block = Parent Group`;Parent 是 split 关系角色,不是第二种对象。Parent 事件的 `case_keys.group_code` 与 `case_keys.block_code` 必须相同。 - 完整 Parent split 固定输出每个 Child 的 `New Booking + Group Block` 和一个 Parent `Cancel Allotment`;同一 parent 的显式取消合并证据。当前 producer 禁止输出 linked Parent `Cancel Booking`。 - QBD/LianTai 当前有效行使用行级隔离,不得跨行合并主事件;同一行仍可按目标拆分,并可产生契约明确的 linked/derived events。 - 不得把多个 `group_code` 合并到一个事件。 - Voucher 必须有当前图片、PDF 或文件证据。 - Rooming List 必须能证明是名单,不得把 booking update 表当名单。 - Extra bed 是 Trace / Guest Request,不是房量,不是房型,不决定 Rate Code。 - Meeting、meal、arrival notice、room preference/setup、已确定的 payment information 或其他具体预订补充信息,即使只是告知,也按目标生成 Trace;普通补充信息不输出 `Note`。 - 同一封邮件、同一目标对象的多条补充信息合并成一个 Trace;多个目标对象分别生成 Trace。 - 主任务已经完整承接的核心参数不得重复生成 Trace。 - `notify_departments` 不清时使用空数组,不得仅因此输出人工复核。 - 需要酒店批准的价格、退款、账期、付款政策或合同条件询问不是 Trace,且不得静默忽略。 - 当素材包同时包含支持事件和 `unknowns[].category=unhandled_current_business_content` 时,普通事件或人工复核照常输出,并把每个 unknown 一对一规范化到顶层 `unhandled_current_intents`。 - `unhandled_current_intents` 只承载意图清楚但当前不支持的业务内容;它不是事件,不得创建任务,也不得与 `extraction_warnings` 混用。 - 房型和 Rate Code 必须由 reference 唯一支持。业务 type/subtype 已知但映射不唯一时,保留原业务 event、将未确认目标字段置为 `null`,并附非空 `manual_review`;不得用 downstream hard validation 代替本次人工确认。 - event type 和 subtype 已知但业务字段或证据不安全时,保留原 active event 并附非空 `manual_review`;只有 type 或 subtype 未知时才输出 `Need Manual Review`。 - 所有粗候选经验证都没有 active 事件时,返回 `04-main-skill-input-contract.md` 定义的内部 `no_supported_event`;素材包非法时返回内部 `candidate_package_contract_error`。两者都不得直接对外,也不得伪装成业务复核。 - `S10` 和 `S99` 都属于 Main Agent 入口结果,不由本 skill 直接输出;Main Agent 只把内部 `no_supported_event` 转换成 S10。 - 本 skill、内部 `no_supported_event` 和内部 `candidate_package_contract_error` 均不得调用 mandatory submit MCP 工具。业务根返回 Main 后由最外层 finalizer 提交;内部对象必须先转换成正式公开结果才可能进入提交钩子。 - 本 skill 只判断候选业务事件,不替用户决定是否回复邮件或进行其他非预订沟通。 - 不输出真实 TaskCard ID、最终 Case 裁决、执行状态、Payment 确认、Block Status 转换、Receipt 或 Opera/PMS 写入结果。 ## 6. 输出 将以下结构化 JSON 参数对象作为内部调用结果直接返回给 Main Agent;此时不得调用最终结果提交工具: ```json { "source_message": { "source_message_id": "" }, "message_events": [], "case_candidates": [], "extraction_warnings": [], "unhandled_current_intents": [] } ``` 该结果是内存中的参数对象,不是 JSON 字符串或文件产物。根对象必须直接使用上述结构,不得增加 `booking_data`、`file`、`filename`、`artifact`、`download_url` 或其他文件包装层。 Main Agent 收到业务根后负责最终校验、冻结、调用一次 `th-hotel-simple-superagent_th_hotel_submit_task_res`,再原样返回。工具响应和提交状态不得回写到本 skill 的业务根。 如果没有业务输出,只能使用 `04-main-skill-input-contract.md` 定义的内部 `no_supported_event` 或 `candidate_package_contract_error`。内部结果不是最终输出:前者由 Main Agent 转换成 S10,后者报告给编排层并停止处理。不得把 `internal_route` 放进业务根或最终对外 JSON。 不得创建、写入、上传、附加或返回 `.json` 结果文件,不得用结果文件名、文件路径、下载链接、artifact 或文件引用代替该对象,不得使用 Markdown 代码块包装最终返回值,也不得增加 `output_mode`、`filename` 等交付控制字段。 以上限制不影响输入附件处理。事件中的 `attachments` 和 `file_references` 可以继续保存 Excel、PDF、图片等输入证据,但不能替代最终 JSON 参数对象。 每个事件必须包含: - `event_type` - `event_role` - `current_or_history` - `source_event_index` - `case_keys` - `relevant_message_excerpt` - `attachments` - `file_references` - `context_used` - `extracted_fields` - `manual_review`:普通候选固定为 `null`;业务复核时为完整 `business_event_review` ## 7. 判断原则 能安全拆分就拆分;不能安全拆分时先保留已经确定的业务类型,再附结构化人工复核。 能输出 `manual_review=null` 的普通候选事件,前提是:动作型事件的当前动作明确;Trace 的当前补充事实或安排明确;目标绑定明确;必要证据可读;业务 reference 支持;系统上下文没有明显阻塞。 业务 event type 和 subtype 已知但上述字段级条件不满足时,仍输出该业务 event,并使用非空 `manual_review` 说明缺失字段、阻塞点和待确认信息;`manual_review.missing_fields[]` 使用 RFC 6901 JSON Pointer。只有 event type 或 subtype 本身无法确定时,才使用 `Need Manual Review`。 输出前必须执行内容完整性检查:每项有业务意义的当前内容已经进入普通事件、业务人工复核或 `unhandled_current_intents`;不得仅因原文仍可在源邮件中查看而省略未覆盖意图。 人工复核也是有效业务结果。必须写清原因、缺失字段、冲突点、需要人工查看的证据和已确认字段;不得因为进入复核就丢失已经安全抽取的业务字段或同邮件的 `unhandled_current_intents`。