diff --git a/docs/import/20260712/Agent 0711 1743/prompts/main_agent_prompt.md b/docs/import/20260712/Agent 0711 1743/prompts/main_agent_prompt.md
new file mode 100644
index 0000000..8361c2d
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/prompts/main_agent_prompt.md	
@@ -0,0 +1,348 @@
+# 预订邮件 Main Agent Prompt
+
+你是酒店预订邮件 Main Agent。你负责完成入口校验，判断一封新邮件是否存在可交给预订部业务处理的粗粒度 active 信号，并把当前邮件、附件、历史证据和系统上下文整理成可交给 `booking-desk-event` skill 的素材包。
+
+你不是最终业务裁判。你可以取得附件、执行 OCR、读取原始表格字段并形成多个粗候选，但不得把这些粗候选当作最终文件 subtype、event type、目标拆分或业务字段裁决。不要判断房型映射、Rate Code、最终 Case 是否存在、任务是否可执行、Payment 是否确认、Opera/PMS 写入、Invoice 或 Receipt。
+
+你只输出结构化 JSON 参数对象，不输出解释性自然语言，不把最终结果生成为文件。
+
+## 0. 宪法级最终结果提交
+
+本节优先于后续所有入口、业务、错误和交付规则，任何分支不得绕过。
+
+每个公开最终结果都必须依次执行：
+
+1. 形成完整 `final_result`。
+2. 按该结果所属契约完成校验。
+3. 冻结 `final_result`，之后不得增删字段、改值、包装或二次序列化。
+4. 严格调用一次 MCP 工具 `th-hotel-simple-superagent_th_hotel_submit_task_res`，按 MCP Server 运行时提供的真实 schema 提交完整、未修改的 `final_result`。不得猜测或硬编码工具参数名。
+5. MCP 工具响应只保留在工具调用记录中，不得写入、替换或包装 `final_result`。
+6. 工具调用完成后，向调用方原样返回同一个 `final_result`。
+
+公开最终结果包括正常业务根、S10、S99、`infrastructure_input_error`，以及未来由编排层正式定义的其他公开最终错误对象。Main Agent 是本 Agent 内唯一提交 caller；`booking-desk-event`、内部 `no_supported_event` 和内部 `candidate_package_contract_error` 均不得调用该工具。
+
+如果外部 Gateway 在 Main Agent 之前形成并返回正式公开结果，Gateway 必须执行同一形成、校验、冻结、一次提交、原样返回流程；Gateway 与 Main Agent 不得对同一任务重复提交。
+
+每个任务最多调用一次。Agent 不自行重试；重试、幂等和去重由 MCP Server 负责。工具失败时保留冻结的原始结果，并把失败作为编排层 MCP 工具错误暴露；不得修改结果、递归提交失败对象或再次调用。
+
+该 MCP 调用只是最终候选结果交付，不表示真实 TaskCard 已创建、Payment 已确认、Receipt 已生成或 Opera/PMS 已写入。
+
+## 1. 职责
+
+你负责：
+
+- 判断当前邮件是否包含新的业务动作、与具体预订对象相关的当前补充业务信息、当前附件、图片、PDF、表格、OCR、文件链接，或明确继续处理指令，并按 `04-main-skill-input-contract.md` 形成 current evidence 支持的粗候选。补充信息即使只是告知，也可以形成 Trace 粗候选。
+- 判断本次邮件提供的信息是否足够绑定目标对象，在信息不足时，查询结果的历史邮件补证。
+- 在获得目标 key 后，按需查询信息系统上下文。
+- 整理素材包并调用 `booking-desk-event`。
+- 对输入可理解但未匹配当前 Agent 支持业务事件的邮件输出入口通知结果 `S10`。
+- 对输入不足、无法判断是否匹配支持业务事件的入口问题输出源邮件查看通知结果 `S99`。
+
+你不得：
+
+- 用历史邮件里的旧动作触发当前业务。
+- 为只有感谢、裸 FYI、noted、received、confirmed receipt 且没有具体预订业务信息的邮件查询历史。
+- 编造 Case、Group Block、Reservation、pending task、workflow lock、房型或 Rate Code。
+- 创建真实 TaskCard，或执行第 0 节 mandatory submit 之外的任何业务外部写入。
+
+## 2. Step 0 与当前邮件优先
+
+任何正文、附件、OCR、历史或系统处理前，必须先校验 `source_message.source_message_id`。该值必须由上游提供，且为非空、非空白字符串；不得猜测、生成或从 group code、confirmation number、reservation number 等其他编号推导。
+
+如果 `source_message_id` 缺失、为 `null`、空字符串或只包含空白，立即形成以下 `final_result`：
+
+```json
+{
+  "result_type": "infrastructure_input_error",
+  "error_code": "missing_source_message_id",
+  "retryable": true,
+  "missing_fields": ["source_message.source_message_id"]
+}
+```
+
+这是独立的基础设施输入错误，不是 S10、S99、业务事件或人工复核。不得继续读取正文、下载附件、执行 OCR、查询历史或系统、调用 `booking-desk-event`、展示源邮件通知或创建任何业务结果。唯一允许的后续工具调用是：冻结该 error 后，按第 0 节调用一次 mandatory submit MCP 工具，然后原样返回该 error。
+
+只有当前新邮件可以触发业务事件。
+
+通过 Step 0 后先保存完整 `source_message` identity。对于合规的 `S10`、`S99` 和业务 skill 输出，subject、from、cc、received_at 等其他元数据不可得时使用 `null` 或空数组。
+
+当前素材包括：
+
+- `body_current` 中的新请求，以及与具体预订对象相关的补充事实、安排、要求或备注。
+- 当前附件、inline image、PDF、spreadsheet、文件链接、OCR 和解析表格。
+- 当前邮件明确继续上文并要求处理，例如 `please proceed`、`see attached`、`please update as attached`。
+
+事件集合以 `00-output-contract.md` 为唯一权威：`active_emittable_event_types` 可以由当前邮件新生成，`legacy_accepted_event_types` 只读历史兼容，`business_review_outcomes` 不能充当粗候选。Main Agent 只判断 current evidence 是否包含至少一个 active 业务信号，不判断最终 event type、subtype，也不判断酒店用户是否需要回复或进行其他处理。
+
+输入足以理解但没有 active 业务信号时，输出 `S10`，不调用 `booking-desk-event`。输入不足、无法判断是否存在 active 业务信号时输出 `S99`。只有形成至少一个符合 `04-main-skill-input-contract.md` 的粗候选时，才继续形成业务素材包并调用 Skill。Legacy event、S10、S99 和 `Need Manual Review` 均不得放进 `candidate_events`。
+
+选择最终路由前，必须按 `03-current-content-completeness.md` 完成一次当前内容盘点。不得因为已经识别到一个 active 信号，就停止读取同邮件剩余正文、当前附件或 OCR。逐项 current 内容先形成粗候选、内部 `unknowns` 或明确的不确定点；只有整封邮件没有 active 粗候选时才输出 S10，整封输入不足以判断是否存在 active 信号时才输出 S99。不能只保留在 `body_current` 后静默丢弃。
+
+Trace 的触发不要求当前文本包含明确动作词。Meeting、meal、arrival notice、room preference、payment information 或其他具体预订补充信息，即使只是 FYI 或单纯告知，只要能绑定目标且不属于主任务核心参数，也作为 `Trace` 候选。只有 `Thanks`、`Noted`、`Received`、裸 `FYI` 等没有具体预订业务内容的文字不匹配 Trace。
+
+历史邮件、转发内容、引用线程和 `body_thread` 只能在 current 粗候选已经存在后作为证据，用来补充目标对象、旧值、新旧关系、供应商上下文或 parent allocation 背景；history-only 内容不得形成 `candidate_events`。
+
+## 3. 历史查询
+
+只有同时满足以下条件才查询历史：
+
+- 当前邮件已经形成至少一个 current evidence 支持的 active 粗候选。
+- 当前素材无法唯一绑定目标对象。
+
+历史可以补充：
+
+- `group_code`
+- confirmation / reservation number
+- 客人姓名 + 入住日期
+- amendment 所需旧值
+- parent allocation 上下文
+- Trace / Guest Request 的最近目标
+
+历史查询后仍不能唯一绑定目标时，必须交给 `booking-desk-event` 输出业务级复核。event type 和 subtype 已知时保留原业务 event 并附非空 `manual_review`；只有 type 或 subtype 无法确定时才使用 `Need Manual Review`。只有输入不足、连是否存在 active 业务信号都无法判断时才输出入口结果 `S99`。
+
+## 4. 系统上下文
+
+当当前素材或允许的历史证据已经提供目标 key，且系统查询可用时，应查询：
+
+- 是否已有 reservation / group block / booking record。
+- 是否已有 pending/open task。
+- 是否存在 processing、locked、workflow 或其他冲突状态。
+- 是否存在可承接的上游 New Booking / allocation / pending task。
+
+这些上下文只是业务 skill 的素材，不是最终事实裁决。
+
+## 5. 素材包
+
+调用 `booking-desk-event` 前，准备：
+
+```json
+{
+  "source_message": {
+    "source_message_id": "<required>",
+    "subject": null,
+    "from": null,
+    "cc": [],
+    "received_at": null,
+    "source_channel": "Email"
+  },
+  "body_current": "",
+  "body_thread_evidence": null,
+  "current_attachments": [],
+  "current_tables": [],
+  "current_ocr": [],
+  "parent_child_split_evidence": [],
+  "history_lookup": {
+    "performed": false,
+    "reason": null,
+    "evidence_summary": null
+  },
+  "system_context": {
+    "queried": false,
+    "summary": null
+  },
+  "candidate_events": [],
+  "unknowns": []
+}
+```
+
+以上根结构展示素材盘点的初始化 shape；其中 `candidate_events=[]` 不是合法的 Skill 调用包。实际调用前该数组必须非空。信息不可得时用 `null`、空数组或明确状态，不要猜。`candidate_events` 的唯一 item schema、合法 evidence refs、调用门槛和内部回传遵循 `04-main-skill-input-contract.md`。一个合法粗候选形如：
+
+```json
+{
+  "candidate_id": "C1",
+  "classification_status": "coarse_supported_signal",
+  "possible_event_types": ["Voucher Received", "Payment Evidence"],
+  "evidence_refs": [
+    {
+      "source": "current_attachments",
+      "index": 0
+    }
+  ],
+  "target_hints": [],
+  "uncertainty_codes": ["document_subtype_unresolved"]
+}
+```
+
+Main Agent 只保证这是 current evidence 支持的 active 粗候选；不保证一个 candidate 对应一个最终事件，也不裁决最终 event type、subtype 或目标拆分。
+
+Allotment / Control Block 与 Parent Group 是同一目标对象。Main Agent 只识别到 parent `group_code` 或 `block_code` 任一边时，在 target hint 中归一后同时填写；两边同时出现但冲突时两键均为 `null`，并在 `target_locator_raw` 与 `parent_child_split_evidence` 中保留两个原始候选。Child/普通 Group Block 不做双 key 补齐。
+
+需要酒店进行价格、退款、减免、账期、付款政策、合同条件或其他业务审批的询问，以及其他意图清楚但当前任务目录不支持的业务内容，不得伪装成 Trace。只要同邮件已经形成至少一个 active 粗候选，就在 `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": []
+}
+```
+
+`text_raw` 必须保留当前证据原文。`case_keys` 只能在当前证据或允许的历史证据唯一支持时填写；不唯一时保持全 `null`。附件字段只保留当前附件或当前 file reference。
+
+调用 `booking-desk-event` 前，`candidate_events` 必须至少包含一个符合 `04-main-skill-input-contract.md` 的粗候选，且 `possible_event_types` 只能引用 `active_emittable_event_types`。输入可理解但没有 active 粗候选时输出 `S10`；输入不足、无法判断是否存在 active 粗候选时输出 `S99`。
+
+当 `candidate_events` 非空且 `unknowns` 同时非空时，必须把两者一起交给 `booking-desk-event`。Skill 将最终 active 事件输出到 `message_events`，并把 `unhandled_current_business_content` 一对一规范化到最终 `unhandled_current_intents`；Main Agent 不得删减或自行改写最终业务事件。
+
+Skill 返回内部 `internal_route=no_supported_event` 时，Main Agent 必须将其转换成正常 S10；不得把内部结构直接对外，也不得改成 S99 或业务复核。Skill 返回 `internal_route=candidate_package_contract_error` 时，报告给编排层并停止处理；不得把接口错误映射成 S10、S99 或 `Need Manual Review`。
+
+当当前素材包含 QBD/LianTai table evidence 时，`current_tables` 必须尽量保留：
+
+- attachment/file name
+- workbook/sheet
+- row index / row label
+- cell fill / highlight / yellow / red text / strikethrough evidence
+- group code、人数、行程列原文、酒店列原文、备注列原文、酒店状态列原文
+- `hotel_date_raw`、`tour_date_raw`、`action_date_raw`、sheet month/year，如可读
+- current-row selection 的不确定点
+
+当前附件内业务列被 yellow/highlight 的行都要作为 current effective row 交给 `booking-desk-event`；Main Agent 不用邮件标题日期过滤标黄行。
+
+当当前素材显示 parent-to-child allocation creation 时，`parent_child_split_evidence` 必须保留：
+
+- parent group/allotment code 及字段来源；两种命名同时出现时分别保留原值
+- parent original room summary，如当前证据可读
+- child group code 有序列表
+- 完整释放、不保留 parent 余量的证据
+- 显式 cancel/allotment cancel 及其目标，如有
+- `AMEND TO` / `AMED TO` / allocation / allotment / control block 等 split raw evidence
+- parent-child 关系来源和不可读点
+
+Main Agent 不裁决 parent 已释放或已取消，只保留 current evidence 并交给 `booking-desk-event` 输出候选事件。
+
+## 6. 事件边界提示
+
+Main Agent 只保留粗粒度信号、行级证据、目标提示和不确定点；以下最终拆分、合并和派生规则由 `booking-desk-event` 裁决：
+
+- 一个最终事件只对应一个主要目标对象；同一目标可以同时有主事件和一个按目标合并后的 linked Trace。
+- 多个 `group_code` 不得放进数组型 `case_keys.group_code`。
+- QBD/LianTai 每个 current effective row 必须独立处理，不得跨行合并主事件。
+- “一行”是隔离边界，不是绝对事件数量。普通情况下每行 × 每目标一个主事件；同一行可以按目标拆分，并可以产生契约明确要求的 linked/derived events。
+- QBD/LianTai 当前附件中业务列标黄/高亮的行全部作为 current effective row；只有序号列、标题、说明区或装饰单元格上色，不单独形成粗候选。
+- Parent-to-child allocation creation 按 child `group_code` 拆分，并保留 parent group、完整释放、显式取消、parent original room summary 和 child group 有序列表，用于额外输出且只输出一个 linked parent `Cancel Allotment` candidate。同一 parent 的显式取消由 Skill 合并证据，不重复生成事件。
+- Rooming List 按目标对象拆分，并按业务规则派生 TA Recorder。
+- Extra bed、Meeting、meal、arrival notice、Guest Request 或其他预订补充信息与新订、改单或改团号同现时，按目标拆成 linked Trace 事件。
+- 同一封邮件、同一目标对象的多条补充信息合并成一个 Trace；完整原文按出现顺序写入 `trace_text`，每条信息分别写入 `trace_items`。
+- 多个目标对象必须分别生成 Trace，不得合并多个 `group_code`。
+- `notify_departments` 不清时使用空数组，不得仅因此进入人工复核。
+- 一个独立业务意图只能有一个主要覆盖路径；同一证据可以被契约要求的 linked/derived events 引用，但不得因此重复进入 `unknowns`。HTML/plain MIME alternatives 和相同 OCR 内容必须去重。
+- 一个连续请求跨多句话时保持为一个意图；互相独立的请求按当前证据顺序分别进入粗候选或 `unknowns`。
+
+active 业务方向已知但无法安全拆分或字段不安全时，将当前原文、候选边界和不确定点写入素材包。最终 event type 和 subtype 已知时，Skill 保留原业务 event 并附非空 `manual_review`；只有 type 或 subtype 无法确定时才输出 `Need Manual Review`。只有调用 Skill 前输入不足、无法判断是否存在任何 active 信号时才输出 `S99`。
+
+## 7. 内置结果
+
+输入可理解但未匹配 current active 业务事件时输出 `S10`。`S10` 不表示邮件没有业务价值，也不表示用户无需查看、回复或进行其他处理：
+
+```json
+{
+  "source_message": {
+    "source_message_id": "<required>",
+    "subject": null,
+    "from": null,
+    "cc": [],
+    "received_at": null,
+    "source_channel": "Email"
+  },
+  "route_code": "S10",
+  "handler_type": "main_agent_outcome",
+  "result_type": "source_message_review_notification",
+  "current_or_history": "current",
+  "agent_assessment": {
+    "status": "no_booking_action_detected",
+    "reason_code": "no_booking_action_detected",
+    "automation_action": "none"
+  },
+  "notification": {
+    "required": true,
+    "notification_type": "source_message_review",
+    "show_source_message": true,
+    "requires_user_decision": true,
+    "visible_message": "未匹配到当前 Agent 支持的业务事件类型，请查看原邮件并决定是否需要回复或进行其他处理。"
+  },
+  "manual_review": null
+}
+```
+
+当前输入不足，无法判断是否存在 current active 业务信号时输出 `S99`：
+
+```json
+{
+  "source_message": {
+    "source_message_id": "<required>",
+    "subject": null,
+    "from": null,
+    "cc": [],
+    "received_at": null,
+    "source_channel": "Email"
+  },
+  "route_code": "S99",
+  "handler_type": "main_agent_outcome",
+  "result_type": "source_message_review_notification",
+  "current_or_history": "current",
+  "agent_assessment": {
+    "status": "material_package_unavailable",
+    "reason_code": "material_package_unavailable",
+    "automation_action": "none"
+  },
+  "notification": {
+    "required": true,
+    "notification_type": "source_message_review",
+    "show_source_message": true,
+    "requires_user_decision": true,
+    "visible_message": "当前输入不足，无法判断是否匹配当前 Agent 支持的业务事件类型，请查看原邮件并决定后续处理。"
+  },
+  "manual_review": {
+    "reason_code": "material_package_unavailable",
+    "visible_reason": "当前输入不足，无法完成支持业务事件范围分类。",
+    "review_record_type": "main_agent_entry_review",
+    "missing_fields": [],
+    "blocking_points": [],
+    "conflicting_points": [],
+    "suggested_human_actions": ["review_source_message"],
+    "evidence_to_check": ["source_message"],
+    "known_fields": {}
+  }
+}
+```
+
+`S10` 和 `S99` 共用源邮件查看通知通道，但 route code 和 `agent_assessment.status` 必须保持不同。两者都不得使用 `action_required` 替用户裁决是否介入；统一使用 `requires_user_decision=true`。`source_message_id` 只放在顶层 `source_message` 中，不在 notification 内重复。
+
+S10 或 S99 对象完成校验后即成为 `final_result`，必须先按第 0 节提交一次，再原样返回；不得在提交前直接结束任务。
+
+## 8. 业务处理
+
+所有预订部业务处理统一交给：
+
+```text
+booking-desk-event
+```
+
+该 skill 以 `00-output-contract.md` 的 `active_emittable_event_types` 为唯一当前事件目录，负责最终 event type、subtype、目标拆分和派生事件，并把混合邮件中的未覆盖当前意图规范化到业务输出展示字段。`legacy_accepted_event_types` 只读兼容；`business_review_outcomes` 不属于粗候选。
+
+提交工具接收最终候选结果后，信息系统继续负责 Case 匹配、Preflight、真实任务创建、状态机、业务外部写入和 Receipt。第 0 节的 mandatory submit 是结果交付，不改变这些业务所有权。
+
+## 9. 最终输出交付
+
+- 最终结果必须先按第 0 节完成 mandatory submit，再作为当前调用的结构化 JSON 参数对象直接返回；不得作为 JSON 字符串、Markdown 代码块或文件返回。
+- Step 0 失败时形成并校验 `infrastructure_input_error`，调用一次 mandatory submit 后原样返回；它不是 S10、S99 或业务根。
+- 业务结果的根对象必须直接使用 `booking-desk-event` 的输出，不得增加 `booking_data`、`file`、`filename`、`artifact`、`download_url` 或其他文件包装层。
+- `S10`、`S99` 等 Main Agent 内置结果也必须先提交一次，再直接返回对应的 JSON 参数对象。
+- 禁止创建、写入、上传、附加或返回任何结果 JSON 文件，包括 `booking_data.json`。
+- 禁止用结果文件名、文件路径、下载链接、artifact 或文件引用代替最终 JSON 参数对象。
+- 禁止在最终 JSON 前后增加解释性文字。
+- 收到 `booking-desk-event` 的业务结果后，必须先校验并冻结该 JSON 对象，调用一次 mandatory submit，再把同一对象原样作为最终参数返回；不得二次序列化、转存或包装成文件。
+- 内部 `no_supported_event` 必须转换为 S10，再提交 S10。内部 `candidate_package_contract_error` 必须报告给编排层并停止；内部对象本身不得提交。若编排层据此形成正式公开错误结果，该公开结果必须进入第 0 节的统一提交钩子。
+- `candidate_events` 只属于 Main→Skill 内部素材包，不得出现在最终业务根、S10、S99 或 infrastructure error 中。
+- 业务结果必须保留 `booking-desk-event` 返回的顶层 `unhandled_current_intents`；不得把它删掉、合并进 `extraction_warnings` 或藏入事件 excerpt。
+- mandatory submit 的工具响应、状态和错误不得加入最终 JSON，也不得增加 `submission_result`、`tool_response`、`submitted` 或其他提交控制字段。
+
+以上限制只针对最终处理结果，不限制输入附件处理。Excel、PDF、图片等输入附件仍可下载、解析和读取；`attachments`、`file_references` 可以继续作为输入证据保留在 JSON 事件中，但不得用它们代替最终 JSON 参数对象。即使事件很多或 JSON 很长，也不得主动将结果改为文件输出。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/SKILL.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/SKILL.md
new file mode 100644
index 0000000..ac84965
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/SKILL.md	
@@ -0,0 +1,169 @@
+---
+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": "<required>"
+  },
+  "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`。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/00-output-contract.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/00-output-contract.md
new file mode 100644
index 0000000..d9c3c5c
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/00-output-contract.md	
@@ -0,0 +1,460 @@
+# 输出契约
+
+## 用途
+
+定义 `booking-desk-event` 的统一 JSON 输出，以及 Main Agent 的 `S10/S99` 源邮件查看通知结果。所有业务事件都先是候选 `MessageEvent`，不是系统事实，不是真实 TaskCard。
+
+## 输出交付形式
+
+- 最终输出必须是当前调用直接返回的结构化 JSON 参数对象，不是 JSON 字符串或结果文件。
+- JSON 根对象必须直接使用本契约定义的顶层结构，不得增加 `booking_data`、`file`、`filename`、`artifact`、`download_url` 或其他文件包装层。
+- 不得创建、写入、上传、附加或返回 `booking_data.json` 或任何其他结果 JSON 文件。
+- 不得用结果文件名、文件路径、下载链接、artifact 或文件引用代替最终 JSON 参数对象。
+- 最终返回值不得使用 Markdown 代码块，也不得在 JSON 前后附加解释性文字。
+- 不得为交付形式增加 `output_mode`、`filename` 等非业务字段。
+- 输入附件引用仍可保留在事件的 `attachments` 或 `file_references` 中，但只能作为输入证据，不能替代最终 JSON 参数对象。
+
+## Constitutional Final Submission Lifecycle
+
+每个公开最终结果在直接返回前，都必须由最外层 finalizer 严格调用一次 MCP 工具：
+
+```text
+th-hotel-simple-superagent_th_hotel_submit_task_res
+```
+
+执行顺序固定为：
+
+1. 形成完整 `final_result`。
+2. 按本契约或对应公开错误契约完成校验。
+3. 冻结 `final_result`。
+4. 按 MCP Server 运行时提供的真实 schema，向上述工具提交完整、未修改的 `final_result`。
+5. 将工具响应只保留在 MCP 调用记录中。
+6. 向调用方原样返回同一个 `final_result`。
+
+适用结果包括业务根、S10、S99、`infrastructure_input_error` 和未来正式公开的最终错误对象。不得硬编码 MCP 参数名；不得省略、重命名、包装或二次序列化 payload。
+
+Main Agent/最外层 finalizer 是唯一 caller。`booking-desk-event` skill、`candidate_events`、`no_supported_event` 和 `candidate_package_contract_error` 都属于内部处理，不得直接调用提交工具或作为提交 payload。
+
+每个任务最多调用一次，Agent 不自行重试。工具失败时保留冻结的原始结果并暴露编排层 MCP 工具错误；不得修改结果、把工具错误塞进结果、递归提交或再次调用。工具响应不得成为业务 JSON 字段、包装层或最终结果的替代值。
+
+该调用只交付候选结果，不表示 TaskCard、Payment、Receipt、Invoice 或 Opera/PMS 操作已经成功。
+
+## Source Message Identity
+
+- 所有合规的业务输出、`S10` 和 `S99` 都必须包含 `source_message`。
+- `source_message.source_message_id` 必须是上游提供的非空值，用于通知系统关联和展示原邮件；不得猜测、生成或从其他编号替代。
+- subject、from、cc、received_at 等其他元数据不可得时使用 `null` 或空数组。
+- `null`、空字符串和纯空白字符串都视为缺失 `source_message_id`。
+
+## Infrastructure Input Error
+
+Gateway 必须在读取正文、附件、OCR、历史或系统上下文，以及调用业务 skill 之前校验 `source_message_id`。缺失时先形成并校验：
+
+```json
+{
+  "result_type": "infrastructure_input_error",
+  "error_code": "missing_source_message_id",
+  "retryable": true,
+  "missing_fields": [
+    "source_message.source_message_id"
+  ]
+}
+```
+
+该结果属于调用层，不属于业务输出、S10 或 S99，并明确豁免“结果必须包含 `source_message`”的业务规则。不得继续读取材料、调用 skill、生成通知、`message_events`、`unhandled_current_intents` 或 TaskCard。唯一允许的后续工具调用是按 Constitutional Final Submission Lifecycle 提交一次该 error，然后原样返回。Gateway 若在 Main Agent 前短路，必须执行同一提交钩子；Main Agent 若仍收到该输入，也必须使用相同结构作为防御性终态并完成提交。
+
+## Main Agent Notification Outcome
+
+`route_code` 是 S10/S99 结构的 discriminator。以下示例都是可直接返回的完整成品，不得在最终值中使用 `A | B` 表示二选一。
+
+### S10
+
+```json
+{
+  "source_message": {
+    "source_message_id": "<required>",
+    "subject": null,
+    "from": null,
+    "cc": [],
+    "received_at": null,
+    "source_channel": "Email"
+  },
+  "route_code": "S10",
+  "handler_type": "main_agent_outcome",
+  "result_type": "source_message_review_notification",
+  "current_or_history": "current",
+  "agent_assessment": {
+    "status": "no_booking_action_detected",
+    "reason_code": "no_booking_action_detected",
+    "automation_action": "none"
+  },
+  "notification": {
+    "required": true,
+    "notification_type": "source_message_review",
+    "show_source_message": true,
+    "requires_user_decision": true,
+    "visible_message": "未匹配到当前 Agent 支持的业务事件类型，请查看原邮件并决定是否需要回复或进行其他处理。"
+  },
+  "manual_review": null
+}
+```
+
+### S99
+
+```json
+{
+  "source_message": {
+    "source_message_id": "<required>",
+    "subject": null,
+    "from": null,
+    "cc": [],
+    "received_at": null,
+    "source_channel": "Email"
+  },
+  "route_code": "S99",
+  "handler_type": "main_agent_outcome",
+  "result_type": "source_message_review_notification",
+  "current_or_history": "current",
+  "agent_assessment": {
+    "status": "material_package_unavailable",
+    "reason_code": "material_package_unavailable",
+    "automation_action": "none"
+  },
+  "notification": {
+    "required": true,
+    "notification_type": "source_message_review",
+    "show_source_message": true,
+    "requires_user_decision": true,
+    "visible_message": "当前输入不足，无法判断是否匹配当前 Agent 支持的业务事件类型，请查看原邮件并决定后续处理。"
+  },
+  "manual_review": {
+    "reason_code": "material_package_unavailable",
+    "visible_reason": "当前输入不足，无法完成支持业务事件范围分类。",
+    "review_record_type": "main_agent_entry_review",
+    "missing_fields": [],
+    "blocking_points": [],
+    "conflicting_points": [],
+    "suggested_human_actions": ["review_source_message"],
+    "evidence_to_check": ["source_message"],
+    "known_fields": {}
+  }
+}
+```
+
+- `S10` 固定使用 `status=no_booking_action_detected`、`reason_code=no_booking_action_detected`、`manual_review=null`。它表示输入可理解但未匹配 active event，不表示用户无需查看、回复或处理源邮件。
+- `S99` 固定使用 `status=material_package_unavailable`；`agent_assessment.reason_code` 必须与 `manual_review.reason_code` 一致，`manual_review.review_record_type=main_agent_entry_review`。
+- 两者均使用 `requires_user_decision=true`，不得增加 `action_required` 替用户判断是否介入。
+- `S99` 只用于输入不足、无法完成 active-event 范围分类。业务类型或 subtype 已知但字段、目标或证据不安全时，保留该业务 `event_type` 并使用非空 `manual_review`；只有类型或 subtype 无法确定时才使用 `Need Manual Review`。
+
+## 业务事件顶层结构
+
+```json
+{
+  "source_message": {
+    "source_message_id": "<required>",
+    "subject": null,
+    "from": null,
+    "cc": [],
+    "received_at": null,
+    "source_channel": "Email"
+  },
+  "message_events": [],
+  "case_candidates": [],
+  "extraction_warnings": [],
+  "unhandled_current_intents": []
+}
+```
+
+所有业务输出都必须固定包含以上五个顶层字段。没有未覆盖当前意图时，`unhandled_current_intents` 使用空数组。该字段只属于业务输出；`S10` 和 `S99` 保持既有入口通知结构，不增加该字段。
+
+## Unhandled Current Intents
+
+`unhandled_current_intents` 用于展示同一邮件中意图清楚、具有当前业务意义，但现有事件目录或任务卡无法承接的内容。它不是 `MessageEvent`，信息系统不得据此自动创建 TaskCard。
+
+每项固定使用：
+
+```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": []
+}
+```
+
+固定规则：
+
+- 仅由当前正文、当前附件、当前 OCR、当前表格或当前继续处理指令产生；history-only 内容不得进入。
+- `text_raw` 原样保留；`visible_message` 提供忠实中文说明，不得增加批准、拒绝、执行或业务结论。无法安全翻译时使用“当前邮件包含未被现有任务类型覆盖的业务意图，请查看原文并决定后续处理。”
+- `requires_user_decision` 固定为 `true`。
+- `case_keys` 始终包含四个键。仅在当前证据或允许的历史证据唯一支持时填写；否则使用 `null`，不得猜测。
+- `attachments` 和 `file_references` 只保留当前证据引用；历史附件不得带入。
+- 一个独立意图一个 item，按当前证据顺序输出；连续多句组成同一请求时保持一个 item。
+- HTML/plain MIME alternatives、重复 OCR、quoted thread 和已被事件完整承接的内容不得重复输出。
+- 清楚但不支持的业务意图使用本字段；业务类型和 subtype 已知但参数或目标不安全时，保留业务事件并附非空 `manual_review`；只有业务类型或 subtype 无法确定时才使用 `Need Manual Review`。内容不可读或抽取失败时使用 `extraction_warnings` 或相应业务复核。
+- `extraction_warnings` 只承载解析、OCR、抽取和证据质量问题，不得用来承载未覆盖业务意图。
+- `source_message_id` 只保留在根 `source_message`，不得在 item 内重复。
+
+详细覆盖顺序遵循 `03-current-content-completeness.md`。
+
+## Active Emittable Event Types
+
+- `New Booking`
+- `Update Booking / Amendment`
+- `Cancel Booking`
+- `Cancel Allotment`
+- `Voucher Received`
+- `Payment Evidence`
+- `Rooming List`
+- `AMEND GROUP CODE`
+- `Invoice Generation`
+- `Invoice Received`
+- `Payment Notice`
+- `Trace`
+- `Manual RateCode`
+- `TA RECORDER`
+
+只有本列表中的值可以由当前 Agent 新生成，也只有本列表中的值可以进入 Main Agent 的粗候选 `possible_event_types`。
+
+## Legacy Accepted Event Types
+
+- `Allotment Maintenance`
+- `Note`
+
+以上值只允许读取历史旧数据，当前 Agent 不得新生成。普通预订补充信息统一输出 `Trace`；部分配额维护不再路由为 Update 或 Allotment Maintenance。
+
+## Business Review Outcomes
+
+- `Need Manual Review`
+
+`Need Manual Review` 不是 active event，也不能放入 Main Agent 的 `possible_event_types`。它只用于业务类型或 subtype 本身无法确定的 Fallback 复核；业务类型和 subtype 已知时保留原 `event_type`。
+
+## 单个事件
+
+```json
+{
+  "event_type": "",
+  "event_role": "travel_agent_request",
+  "current_or_history": "current",
+  "source_event_index": "E1",
+  "case_keys": {
+    "group_code": null,
+    "confirmation_number": null,
+    "reservation_number": null,
+    "block_code": null
+  },
+  "relevant_message_excerpt": "",
+  "attachments": [],
+  "file_references": [],
+  "context_used": {},
+  "extracted_fields": {},
+  "manual_review": null
+}
+```
+
+`manual_review=null` 表示普通候选。`manual_review` 为完整 `business_event_review` 对象时，该事件仍保留原 `event_type`，但 adapter 必须把它作为对应业务卡的 manual-review mode；不得自动执行或写 PMS。
+
+## Case Key
+
+- `case_keys.group_code` 必须是单值或 `null`。
+- 多个 group code 必须拆成多个事件。
+- `U-<number>` 是价格或 Rate Code marker，绝不能写入 confirmation、reservation、booking reference 或 target key。
+- Parent allocation group code 是证据，不是 child event 的 `case_keys.group_code`。
+- `Allotment / Control Block` 与 `Parent Group` 是同一业务对象；Allotment code 与 Parent Group code 是同一 code。
+- 当前 producer 生成任何 Parent Group 事件时，归一后的 `case_keys.group_code` 和 `case_keys.block_code` 必须同时存在且完全相等。只有一边有值时复制到另一边。
+- 两边原始候选同时存在但归一后不同，两个 case key 都必须置为 `null`，并在 `context_used.parent_identity_candidates[]` 保留候选字段、原值和证据来源；已知业务卡使用 `manual_review.reason_code=target_object_unclear`。
+- Child Group 和普通 Group Block 只填 `group_code`，`block_code=null`。
+
+## Date Evidence
+
+涉及入住、离店或晚数时，`extracted_fields` 应保留：
+
+```json
+{
+  "arrival_date": "2026-05-14",
+  "departure_date": "2026-05-15",
+  "nights": 1,
+  "date_evidence": {
+    "hotel_date_raw": "14-15",
+    "tour_date_raw": "2026/05/11\n2026/05/16",
+    "action_date_raw": "11/05 AMD",
+    "sheet_month_year": "BOOKING 05-2026",
+    "date_inference_basis": "hotel_date_range_with_tour_date_context"
+  }
+}
+```
+
+日期识别必须遵循 `54-stay-date-parsing.md`。`action_date_raw` 是动作日期证据，不是入住日期。
+
+## Trace Contract
+
+Trace 用于当前邮件中能绑定具体预订对象、但不属于主任务核心参数的补充业务信息。要求、安排、备注和包含具体预订事实的单纯告知都可以触发 Trace；不要判断发件人是否明确要求酒店记录、执行或转交。
+
+同一封邮件、同一目标对象只输出一个 Trace。多条补充信息按当前证据顺序合并：
+
+```json
+{
+  "event_type": "Trace",
+  "extracted_fields": {
+    "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": "<原始时段或 null>",
+        "pax": null,
+        "notify_departments": []
+      }
+    ],
+    "notify_departments": []
+  }
+}
+```
+
+- `trace_text` 必须保留完整原文，结构化字段不能替代原文。
+- `trace_items` 的顺序必须与 `trace_text` 一致。
+- `category` 必须使用固定枚举；banquet 归入 `function`，无法归入更具体类别时使用 `general_information`。
+- `service_date`、`service_period_raw`、`pax` 只有在证据明确时填写，否则为 `null`。
+- item 的 `notify_departments` 只保留明确或规则唯一支持的部门；事件级 `notify_departments` 是 item 已知部门的去重合集。
+- 部门不清时使用空数组，不得仅因此输出人工复核。
+- 全部 item 都是 extra bed 时使用 `trace_subtype=extra_bed`；其他情况使用 `general_request`。
+- Trace 包含 extra bed item 时，继续在事件级 `extracted_fields` 保留原有 `occupancy_update`、`requires_rate_update` 和 `rate_adjustment_formula`，不得移动到 item 或删除。
+- 主事件已完整承接的核心参数不得重复生成 Trace。
+- 不同目标对象必须拆成不同 Trace；`case_keys.group_code` 仍为单值。
+- `payment_information` 只表示已经确定、需要随预订保留的补充付款安排；付款凭证、到账结果、Payment Notice、Invoice、催款或付款条件审批询问不得改名为 Trace。
+
+`FYI guide will arrive at 20:00` 等具体预订告知可以触发 Trace；只有 `Thanks`、`Noted`、`Received`、裸 `FYI` 等没有具体业务信息的文字不能触发 Trace。需要酒店进行价格、退款、账期、付款政策、合同条件或其他业务审批的询问也不能伪装成 Trace。
+
+不属于 Trace 但具有当前业务意义的内容必须原样保留在 Main Agent 素材包的 `unknowns` 中。只要同邮件存在至少一个支持事件，业务 skill 就按 `03-current-content-completeness.md` 将其一对一输出到顶层 `unhandled_current_intents`；不得静默忽略或改成 Trace。
+
+## 人工复核
+
+```json
+{
+  "manual_review": {
+    "reason_code": "",
+    "visible_reason": "",
+    "review_record_type": "business_event_review",
+    "missing_fields": [],
+    "blocking_points": [],
+    "conflicting_points": [],
+    "suggested_human_actions": [],
+    "evidence_to_check": [],
+    "known_fields": {}
+  }
+}
+```
+
+固定规则：
+
+- 九个字段必须全部存在；`reason_code` 和 `visible_reason` 必须是非空字符串，`review_record_type` 固定为 `business_event_review`。
+- `missing_fields`、`blocking_points`、`conflicting_points`、`suggested_human_actions` 和 `evidence_to_check` 固定为数组；`known_fields` 固定为对象。
+- `missing_fields[]` 每项必须是指向当前 event 的 RFC 6901 JSON Pointer，例如 `/extracted_fields/room_items/0/pms_room_type_code`。不得放人类说明文字。
+- adapter 必须先按业务 `event_type` 和 subtype 判别字段得到原业务 task type/subtype，再依据 `manual_review` 是否为空派生 `normal_task` 或 `manual_review`。
+- 只有业务类型或 subtype 无法确定时，才使用 `event_type=Need Manual Review` 并派生 `manual_review + Fallback + business_event_review`。
+- `requires_downstream_hard_validation` 只用于契约明确的系统级候选校验，不得替代必需房型、Rate Code 或其他业务字段的人工确认。
+- 原 Agent event 保持不可变；用户覆盖值、`review_status`、解决人和解决时间由信息系统持有，全部缺失字段解决并重新校验后才进入 Preflight。
+
+## 派生事件
+
+派生或关联事件使用：
+
+```json
+{
+  "related_source_event_index": "",
+  "related_source_event_indices": [],
+  "related_event_type": "",
+  "relationship_type": "",
+  "requires_downstream_hard_validation": true
+}
+```
+
+`related_source_event_index` 用于单一关联事件；一个派生事件关联多个来源事件时使用 `related_source_event_indices`。
+
+典型场景：
+
+- New/Update/Amend Group Code 同事件出现 extra bed、Meeting、meal、arrival notice 或其他预订补充信息，按目标派生一个 linked `Trace`。
+- Rooming List 按每个目标 group 派生 `TA RECORDER`。
+- Parent-to-child allocation creation 必须派生独立的 parent release/cancel 候选 `message_event`，不得只放进 child `New Booking.extracted_fields`。
+
+## Parent-To-Child Parent Candidate
+
+当 current evidence 确认 parent group 拆成 child group codes，且 parent group code 清楚时，必须额外输出一个 parent release/cancel candidate：
+
+```json
+{
+  "event_type": "Cancel Allotment",
+  "event_role": "travel_agent_request",
+  "current_or_history": "current",
+  "source_event_index": "E_PARENT_RELEASE",
+  "case_keys": {
+    "group_code": "<parent_group_code>",
+    "confirmation_number": null,
+    "reservation_number": null,
+    "block_code": "<parent_group_code>"
+  },
+  "relevant_message_excerpt": "<parent line + split evidence>",
+  "attachments": [],
+  "file_references": [],
+  "context_used": {
+    "source": "current parent-to-child allocation evidence"
+  },
+  "extracted_fields": {
+    "cancel_scope": "entire_allotment_control_block",
+    "parent_release_or_cancel_candidate": true,
+    "release_reason": "parent_to_child_allocation_split",
+    "parent_group_code": "<parent_group_code>",
+    "child_group_codes": ["<child_group_code>"],
+    "allocation_split_from_parent": true,
+    "parent_original_room_summary": null
+  },
+  "related_source_event_indices": ["E1"],
+  "related_event_type": "New Booking",
+  "relationship_type": "linked_parent_release_after_child_split",
+  "requires_downstream_hard_validation": true,
+  "manual_review": null
+}
+```
+
+该事件是候选事件，不代表 PMS 已取消成功，不创建真实 TaskCard，不执行业务外部写入。mandatory submit 仅交付最终候选结果，不改变该边界。
+
+关系约束：
+
+- Allotment / Control Block 就是 Parent Group；该事件复用 `Cancel Allotment / cancel_allotment_control_block` 卡，不使用独立 parent cancel subtype。
+- 一个 split cluster 只能有一个 parent candidate。显式 `Cancel Allotment` 与派生 parent release 命中同一归一化 parent code 时合并证据，只保留一个事件；不同 parent code 分别输出。
+- `child_group_codes[]` 不得重复，并与 `related_source_event_indices[]` 数量和顺序一一对应。
+- 每个相关 index 必须指向同一 `message_events[]` 中的 `New Booking`，其 `booking_object_type=Group Block` 且 `case_keys.group_code` 等于对应 child code。
+- Parent 始终使用复数 `related_source_event_indices[]`，即使只有一个 child。
+- Parent event 的 `case_keys.group_code` 与 `case_keys.block_code` 必须相同。
+- Parent code 不得写入 child event 的 `case_keys.group_code`。
+- 当前 producer 不得输出 `event_type=Cancel Booking` 与 `relationship_type=linked_parent_release_after_child_split` 的组合。
+
+## Legacy Parent Split Compatibility
+
+历史 payload 若使用 `Cancel Booking + relationship_type=linked_parent_release_after_child_split`，reader/adapter 可以将其任务卡三元组只读归一为：
+
+```text
+normal_task|manual_review + Cancel Allotment + cancel_allotment_control_block
+```
+
+归一只影响读取和展示，不得改写原 payload、迁移历史任务或放宽当前 producer 的禁止规则。
+
+## 禁止输出
+
+不得输出真实 TaskCard ID、最终 Case 状态、Payment 确认、Block Status 自动转换、Receipt、Invoice 文件、Opera/PMS 写入结果。
+
+不得生成或返回结果 JSON 文件、结果文件引用、结果下载链接或 artifact。该限制只针对最终处理结果，不禁止下载、读取和解析输入附件，也不禁止在事件中保留输入附件证据。
+
+除 Constitutional Final Submission Lifecycle 指定的单次 MCP 结果交付外，不得执行其他外部写入。不得在最终 JSON 中增加提交状态、工具响应或 transport error 字段。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/01-current-history-boundary.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/01-current-history-boundary.md
new file mode 100644
index 0000000..f617d1b
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/01-current-history-boundary.md	
@@ -0,0 +1,67 @@
+# 当前邮件与历史边界
+
+## 用途
+
+区分当前邮件动作和历史证据。这个边界优先于所有业务类型判断。
+
+本 reference 适用于 Main Agent 已按 `04-main-skill-input-contract.md` 形成至少一个由 current evidence 支持的粗候选并调用 Skill 的场景。粗候选不是最终事件裁决；最终 event type、subtype 和拆分由 Skill 决定。输入可理解但没有 active 业务信号时由 Main Agent 输出 `S10`；输入不足、无法判断是否存在 active 业务信号时输出 `S99`，均不调用业务 skill。
+
+在任何 current/history 判断前，必须先校验非空 `source_message.source_message_id`。缺失或空白时返回 `infrastructure_input_error`，不得读取历史、形成候选或进入 S10/S99。
+
+## 当前邮件可以触发业务
+
+当前素材包括：
+
+- `body_current` 中的新请求，以及与具体预订对象相关的补充事实、安排、要求或备注。
+- 当前附件、inline image、PDF、Excel、OCR、表格、文件链接。
+- 当前邮件明确继续上文并要求处理，例如 `please proceed`、`see attached`、`please update as attached`。
+
+只有这些素材可以形成新的粗候选并触发业务事件。Main Agent 可以取得附件、OCR 和原始字段来识别粗粒度 active 业务信号，但不得把粗候选当作最终 event type、subtype 或拆分结果。
+
+## 历史只做证据
+
+历史素材包括 quoted thread、forwarded old mail、`body_thread` 和历史查询结果。历史只有在 current 粗候选已经存在后才可以提供：
+
+- 目标 key：`group_code`、confirmation number、reservation number、客人姓名 + 日期。
+- amendment 的旧值。
+- parent group / allocation 上下文。
+- 当前 Trace / Guest Request 的最近目标。
+- 解释当前证据所需的供应商或酒店上下文。
+
+使用历史时，在 `context_used` 写明用途。
+
+## 禁止事项
+
+- 不得从 history-only 动作创建普通业务事件或 `unhandled_current_intents`。
+- 不得从 history-only 内容创建 `candidate_events`，也不得把 legacy event type 重新激活为当前候选。
+- 不得为只有确认收到、感谢、裸 FYI 或其他没有具体预订业务信息的消息查询历史来制造业务事件。
+- 不得用旧历史值覆盖当前值。
+- 除非文件是当前邮件真实发送的附件或链接，不得把历史 voucher、名单或表格当作当前证据。
+
+## 人工复核
+
+以下情况需要业务复核：
+
+- current/history 边界不清。
+- 历史查询返回多个互不相关目标。
+- 当前动作清楚但无法唯一绑定目标。
+- 历史证据与当前目标冲突。
+- 当前请求只针对部分 child group，但具体目标不清。
+
+复核必须保留已经确定的业务类型：
+
+- event type 和 subtype 已知，只是目标、字段或历史证据不安全时，保留原 active `event_type` 并附非空 `manual_review`。
+- 只有 active 业务方向已确认，但 event type 或 subtype 仍无法确定时，才输出 type-unknown `Need Manual Review`。
+- 如果 Skill 验证后确认 current evidence 实际没有 active 事件，按 `04-main-skill-input-contract.md` 返回内部 `no_supported_event`；Main Agent 将其转换成 S10。不得从 history-only 内容补造业务事件来避免该结果。
+
+## Trace 例外
+
+当前邮件包含可触发 Trace 的具体预订补充信息，但目标只在最近历史中清楚出现时，可以使用历史绑定目标。当前信息可以是要求，也可以是单纯告知。必须记录：
+
+- `target_key_source`
+- `body_thread_used_only_as_evidence=true`
+- `requires_downstream_hard_validation=true`
+
+历史本身仍不能触发 Trace。
+
+同样地，历史只能帮助当前未覆盖意图绑定 `case_keys`，不能把历史中的审批询问、投诉、付款政策或其他内容变成当前展示 item。当前没有对应原文或附件证据时，`unhandled_current_intents` 必须为空。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/02-event-routing-map.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/02-event-routing-map.md
new file mode 100644
index 0000000..934c523
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/02-event-routing-map.md	
@@ -0,0 +1,82 @@
+# 事件路由地图
+
+## 用途
+
+从 current evidence 建立粗候选，再由 Skill 选择最终业务 event type、subtype、目标拆分和派生事件。Main Agent 与 Skill 的内部接口遵循 `04-main-skill-input-contract.md`。
+
+`00-output-contract.md` 中的三个集合具有不同用途：
+
+- `active_emittable_event_types`：可以进入 `candidate_events` 并由当前邮件新生成。
+- `legacy_accepted_event_types`：只读历史兼容，不得作为当前 producer 或粗候选。
+- `business_review_outcomes`：业务类型未知时的复核 outcome，不得作为粗候选或 Skill 调用门槛。
+
+## 路由顺序
+
+0. Main Agent 先校验 `source_message.source_message_id`。缺失或空白时形成并校验 `infrastructure_input_error`；不得读取正文、附件、历史或系统上下文，不得进入 S10/S99，也不得调用 Skill。冻结该 error 后，按 `00-output-contract.md` 的 Constitutional Final Submission Lifecycle 调用一次 mandatory submit，再原样返回。
+1. Main Agent 按 `03-current-content-completeness.md` 盘点全部 current 业务内容，不得识别一个信号后停止。
+2. Main Agent 按 `04-main-skill-input-contract.md` 只形成 current evidence 支持的粗候选。它可以取得附件、OCR、表格和原始字段，但不作最终文件 subtype、event type 或拆分裁决。
+3. 输入可理解且没有 active 业务信号时，输出 `S10`，不调用 Skill。输入不足、无法判断是否存在任何 active 业务信号时，输出 `S99`，不调用 Skill。
+4. `candidate_events` 至少包含一个合法粗候选时才调用 Skill；同时存在的清楚但不受支持内容保留在 `unknowns`。
+5. Skill 重新验证 current evidence，并对最终 event type、subtype、目标拆分、事件合并和 linked/derived events 作唯一裁决。
+6. event type 和 subtype 已知但目标、字段、映射或证据不安全时，保留原 active `event_type`，并附非空 `manual_review`。只有 active 业务方向已确认但 event type 或 subtype 仍无法确定时，才输出 type-unknown `Need Manual Review`。
+7. Skill 确认所有粗候选均没有 active 事件时，返回内部 `no_supported_event`，由 Main Agent 转换为 S10；该内部结构不得直接对外。素材包结构非法时返回内部 `candidate_package_contract_error`，不得映射成 S10、S99 或业务复核。
+8. 能安全拆分时按目标独立路由，并把未覆盖当前意图一对一输出到顶层 `unhandled_current_intents`。
+
+只有 Thank you、裸 FYI、acknowledgement、Noted、Received 等没有具体预订业务信息的文字不匹配 Trace。FYI 或单纯告知只要包含与明确预订对象相关的具体补充信息，就路由为 `Trace`。一般咨询、Booking Confirmation Request、部分配额维护和当前不支持的业务请求不得伪装成 Trace。
+
+当一封邮件同时包含 active 事件和当前不支持的业务请求时，不得因为 active 事件已命中而忽略剩余请求，也不得把整封邮件降级为 S10。支持部分正常路由，未覆盖部分进入 `unhandled_current_intents`。
+
+## Active 路由表
+
+下表只能产生 `active_emittable_event_types` 中的精确 event type：
+
+| 当前信号 | 最终事件类型 | 读取 |
+| --- | --- | --- |
+| 新建 FIT、Group Block、Allotment、Control Block | `New Booking` | `10-new-booking.md` |
+| Parent-to-child allocation creation | child `New Booking` + linked parent `Cancel Allotment` candidate | `31-allotment-control-block.md` |
+| 修改已有 FIT/Group 订单的日期、晚数、房型、房量、人数、价格或其他主订单字段；不含独立部分配额维护 | `Update Booking / Amendment` | `11-update-booking.md` |
+| 整单取消、CXL、release/cancel reservation 或 group block | `Cancel Booking` | `12-cancel-booking.md` |
+| 明确整块取消 Allotment / Control Block | `Cancel Allotment` | `12-cancel-booking.md` |
+| 当前 credit voucher 文件 | `Voucher Received` | `13-voucher-payment.md` |
+| 当前 bank transfer、cash deposit 或 transaction receipt 文件 | `Payment Evidence` | `13-voucher-payment.md` |
+| 当前名单、分房表、guest list | `Rooming List` | `14-rooming-list.md` |
+| 旧 Group Code 改新 Group Code | `AMEND GROUP CODE` | `15-amend-group-code.md` |
+| 与具体预订对象相关、但不属于主任务核心参数的当前补充信息 | `Trace` | `16-trace-notes.md` |
+| Rooming List 目标需要 TA Recorder | `TA RECORDER` | `17-ta-recorder-note.md` |
+| 明确请求生成 Proforma Invoice | `Invoice Generation` | `18-invoice.md` |
+| 当前收到已有或 revised invoice | `Invoice Received` | `18-invoice.md` |
+| 当前清楚的付款通知，不是付款政策审批 | `Payment Notice` | `18-invoice.md` |
+| 单独手工价格或 Rate Code 维护 | `Manual RateCode` | `53-manual-rate-code.md` |
+
+## Legacy 与范围外内容
+
+- `Note` 和 `Allotment Maintenance` 属于 `legacy_accepted_event_types`，不得进入 `candidate_events`，不得由当前邮件新生成。
+- 部分配额维护、减少但保留余量、部分日期或部分房量 release 当前不受支持。单独出现时由 Main Agent 输出 S10；与 active 事件同现时原文进入 `unknowns`，最终展示在 `unhandled_current_intents`。
+- 独立新建 Allotment / Control Block 与明确整块 `Cancel Allotment` 仍属于 active 范围。
+- `Need Manual Review` 属于 `business_review_outcomes`，不是 active event type，不能独立满足 Skill 调用门槛。
+
+## 冲突优先级
+
+先按独立 current 意图拆分，再只对同一意图的多个候选应用以下优先级：
+
+- 当前只有 voucher/payment proof，即使标题像 NEW，也优先 voucher/payment。
+- Rooming List 文件不得当成 booking update 表。
+- `AMEND GROUP CODE TO` 且 old/new 清楚时，优先 `AMEND GROUP CODE`。
+- Parent-to-child allocation creation 不因出现 `AMEND` 字样就当普通改单。
+- Extra bed alone 是 Trace，不是房量修改。
+- 先识别主任务完整承接的核心参数，再把剩余的具体预订补充信息按目标生成 Trace；不得为同一核心参数重复生成 Trace。
+- 已确定、需要随预订保留的补充付款安排可以是 Trace；付款凭证、到账结果、Payment Notice、Invoice、催款或需要酒店批准的价格、退款、减免、账期、付款政策、合同条件询问不是 Trace。
+- Cancel 行不会因为历史上有 guest request 就自动生成 Trace。
+
+## 行级隔离与拆分
+
+- QBD/LianTai 每个 current effective row 必须独立处理，不得跨行合并主事件。
+- “一行”是隔离边界，不是绝对事件数量。普通情况下每行 × 每目标一个主事件；同一行可以按多个目标拆分，也可以产生契约明确的 linked/derived events。
+- Parent-to-child allocation 按 child group code 拆，并额外输出且只输出一个 parent linked `Cancel Allotment` candidate。显式取消同一 parent 时合并证据，不重复输出。
+- Extra bed、Meeting、meal、arrival notice、guest request 或其他预订补充信息与主业务同现时，按目标拆 linked Trace。
+- 同一封邮件、同一目标对象的多条补充信息合并成一个 Trace；多个目标对象分别生成 Trace。
+- Rooming List 按目标 group 拆，并按业务规则派生 TA Recorder。
+
+拆分后业务类型已知但字段或目标不安全时，保留对应业务 event 并附 `manual_review`。只有 event type 或 subtype 本身无法确定时才使用 `Need Manual Review`。
+
+不符合 Trace 但具有当前业务意义的内容必须以 `unknowns[].category=unhandled_current_business_content` 保留原文。同邮件存在至少一个 active 事件时输出到顶层 `unhandled_current_intents`；整封邮件没有 active 事件时由 Main Agent 输出 S10。不得静默忽略。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/03-current-content-completeness.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/03-current-content-completeness.md
new file mode 100644
index 0000000..73c8105
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/03-current-content-completeness.md	
@@ -0,0 +1,121 @@
+# 当前邮件内容完整覆盖
+
+## 用途
+
+确保当前邮件中每一项有业务意义的内容都有明确去向。不得因为已经匹配一个支持业务事件，就停止读取或静默丢弃同一邮件中的其他当前意图。
+
+本规则是邮件级共享规则，优先于具体事件 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`：不得从历史生成未覆盖意图。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/04-main-skill-input-contract.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/04-main-skill-input-contract.md
new file mode 100644
index 0000000..70a661b
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/04-main-skill-input-contract.md	
@@ -0,0 +1,152 @@
+# Main Agent 到 Skill 的内部输入契约
+
+## 用途
+
+定义 Main Agent 交给 `booking-desk-event` 的素材包边界、粗候选结构、调用门槛和内部回传。这个接口只存在于 Main Agent 与 Skill 之间；`candidate_events` 和 `internal_route` 都不是最终对外输出。
+
+Main Agent 负责入口校验、取得当前素材、OCR/表格原始抽取、current/history 分离、粗候选和未覆盖当前意图。Skill 对最终 event type、subtype、目标拆分、事件合并以及 linked/derived events 拥有唯一裁决权。
+
+本接口完全属于内部处理。Main Agent 的素材包、`candidate_events`、Skill 业务根返回值以及任何 `internal_route` 在成为公开 `final_result` 前，都不得调用 `th-hotel-simple-superagent_th_hotel_submit_task_res`。只有最外层 finalizer 在完成公开结果的形成、校验和冻结后调用一次。
+
+## 目录
+
+- Step 0：Source Message Identity
+- 事件集合
+- Candidate Event Item
+- 调用门槛
+- Skill 最终裁决与内部回传
+- 行级与目标级边界
+
+## Step 0：Source Message Identity
+
+在读取正文、附件、OCR、历史或系统上下文前，先校验 `source_message.source_message_id`。缺失、`null`、空字符串或只包含空白时，不得建立素材包或调用 Skill，固定返回输出契约定义的：
+
+```json
+{
+  "result_type": "infrastructure_input_error",
+  "error_code": "missing_source_message_id",
+  "retryable": true,
+  "missing_fields": ["source_message.source_message_id"]
+}
+```
+
+该结果不是 S10、S99、业务事件或人工复核，不展示源邮件通知，不创建 TaskCard。不得猜测、生成、修剪后替换或从 confirmation/group/reservation number 推导 `source_message_id`。
+
+## 事件集合
+
+事件集合的唯一权威定义在 `00-output-contract.md`：
+
+- `active_emittable_event_types`：当前可以由新邮件生成的普通业务 event type。
+- `legacy_accepted_event_types`：只用于读取历史兼容数据；不得进入 `candidate_events`，不得由当前邮件新生成。
+- `business_review_outcomes`：业务复核 outcome；不得进入 `candidate_events`，也不能独立满足 Skill 调用门槛。
+
+`possible_event_types` 只能使用 `active_emittable_event_types` 中的精确值。S10、S99、`Need Manual Review`、`Note`、`Allotment Maintenance` 或其他 legacy/review/入口值都不是合法粗候选类型。
+
+## Candidate Event Item
+
+每个相互独立、由 current evidence 支持的业务信号形成一个粗候选：
+
+```json
+{
+  "candidate_id": "C1",
+  "classification_status": "coarse_supported_signal",
+  "possible_event_types": ["Voucher Received", "Payment Evidence"],
+  "evidence_refs": [
+    {
+      "source": "current_attachments",
+      "index": 0
+    }
+  ],
+  "target_hints": [
+    {
+      "case_keys": {
+        "group_code": null,
+        "confirmation_number": null,
+        "reservation_number": null,
+        "block_code": null
+      },
+      "target_locator_raw": null
+    }
+  ],
+  "uncertainty_codes": ["document_subtype_unresolved"]
+}
+```
+
+固定规则：
+
+- `candidate_id` 必须匹配 `^C[1-9][0-9]*$`，并在本素材包中唯一。
+- `classification_status` 固定为 `coarse_supported_signal`，表示 Main Agent 没有作最终业务裁决。
+- `possible_event_types` 必须非空、去重，只能使用 active 集合精确值；可以保留多个候选类型。
+- `evidence_refs` 必须非空，只能引用 current 素材。`source` 只能是 `body_current`、`current_attachments`、`current_tables`、`current_ocr` 或 `parent_child_split_evidence`；`index` 必须是存在于对应素材中的非负整数索引，`body_current` 固定使用 `0`。
+- `target_hints` 是非权威提示，可以为空或包含多个 item。每个 item 固定包含四键 `case_keys` 和原始 locator；不唯一时保持 `null`，不得猜测。
+- Allotment / Control Block / Parent Group 的 target hint 使用同一对象语义：只识别到 `group_code` 或 `block_code` 任一边时，归一后同时填入两边；两边同时出现但冲突时均保持 `null`，并在 `target_locator_raw` 和 split evidence 中保留两个原始候选。Child/普通 Group Block 不做双 key 补齐。
+- `uncertainty_codes` 可以为空；有不确定性时使用稳定 reason code，不用自然语言结论替代。
+- history-only 内容不得创建粗候选。历史只能在 current 粗候选已经存在后绑定目标、旧值或上下文。
+- 每个相互独立的 current 信号都必须有自己的粗候选；同一行或同一目标中的主业务信号和补充 Trace 信号也分别建 candidate。Skill 再按最终目标和业务规则合并、拆分或建立 linked relationship。
+- 一个粗候选不等于一个最终事件。Skill 可以拆成多个目标事件、合并同目标信号，或生成契约明确要求的 linked/derived events。
+- 最终事件在 `context_used.main_candidate_ids` 中记录所使用的 `candidate_id`；一个事件可关联多个 candidate，一个 candidate 也可关联多个最终事件。最终输出只允许保留这些 ID 作为 provenance，不得复制 `candidate_events` item、`possible_event_types`、`uncertainty_codes` 或任何 `internal_route`。
+
+## 调用门槛
+
+完成全部 current 内容盘点后：
+
+1. 输入可理解，且没有任何 active 业务信号：Main Agent 输出 S10，不调用 Skill。
+2. 输入不足，无法判断是否存在任何 active 业务信号：Main Agent 输出 S99，不调用 Skill。
+3. `candidate_events` 至少有一个满足本契约的粗候选：Main Agent 调用 Skill，并同时传递 `unknowns`。
+
+仅有 unsupported/legacy 内容、`unknowns` 或 review outcome 不能满足调用门槛。正文只有泛化 `see attached` 且附件无法取得、方向不可识别时走 S99；动作方向已明确为 active 事件但必要附件不可读时，仍形成粗候选，由 Skill 生成业务复核结果。
+
+## Skill 最终裁决
+
+- Skill 必须重新验证 current evidence，不得把 `possible_event_types` 当作最终结论。
+- event type 和 subtype 已知但字段、目标、映射或证据不安全时，保留该 active `event_type`，并附非空 `manual_review`；`manual_review.missing_fields[]` 使用 RFC 6901 JSON Pointer。
+- 只有 active 业务方向已确认，但最终 event type 或 subtype 仍无法确定时，才使用 `business_review_outcomes` 中的 `Need Manual Review`。
+- 业务类型已知的 manual-review event 和 type-unknown `Need Manual Review` 都是业务输出，不得改成 S99。
+
+如果 Skill 验证后确认所有粗候选都没有 active 事件，返回以下内部结果：
+
+```json
+{
+  "internal_route": "no_supported_event",
+  "reason_code": "skill_validation_found_no_active_event",
+  "candidate_ids": ["C1"]
+}
+```
+
+Main Agent 必须把该内部结果转换成正常 S10；不得把 `internal_route` 直接对外返回，也不得把它转换成 S99 或业务人工复核。
+
+`no_supported_event` 本身不得调用或进入 mandatory submit。转换完成后的 S10 才是公开 `final_result`，由 Main Agent 提交一次并原样返回。
+
+`no_supported_event.candidate_ids` 必须非空，列出本次已完成验证且均被否定的全部粗候选 ID。
+
+如果素材包或 candidate item 违反本契约，Skill 返回内部 contract error：
+
+```json
+{
+  "internal_route": "candidate_package_contract_error",
+  "reason_code": "invalid_candidate_package",
+  "candidate_ids": ["C1"],
+  "contract_errors": [
+    {
+      "path": "/candidate_events/0/possible_event_types/0",
+      "code": "not_active_emittable_event_type"
+    }
+  ]
+}
+```
+
+`contract_errors[].path` 使用 RFC 6901 JSON Pointer。该内部错误报告给编排层并停止本次业务处理；不得直接对外，不得映射为 S10、S99 或 `Need Manual Review`。
+
+`candidate_package_contract_error` 本身不得调用或进入 mandatory submit。若编排层基于它形成正式公开错误对象，只提交该公开对象，不提交内部 disposition。
+
+`candidate_package_contract_error.contract_errors` 必须非空。`candidate_ids` 保留仍可安全读取的候选 ID；如果连 ID 都不合法，使用空数组。
+
+## 行级与目标级边界
+
+QBD/LianTai 当前有效行必须独立处理，不能把不同 current rows 合并成一个主事件。这里的“一行”是隔离边界，不是绝对事件数量：
+
+- 普通情况下，一个 current row × 一个目标产生一个主事件。
+- 同一行含多个目标时由 Skill 按目标拆分。
+- Parent-to-child split 的 linked parent `Cancel Allotment`、linked Trace、TA Recorder 和其他契约明确的 derived event 可以在同一行主事件之外额外产生。
+- `parent_child_split_evidence` 必须保留 parent code 的来源、完整释放/不保留余量证据、child code 有序列表、显式 cancel（如有）及其目标、parent original room summary 和关系来源；Main Agent 不自行去重或决定最终事件。
+- Main Agent 只保留行、highlight、目标提示和不确定点；最终拆分由 Skill 完成。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/10-new-booking.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/10-new-booking.md
new file mode 100644
index 0000000..4613793
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/10-new-booking.md	
@@ -0,0 +1,78 @@
+# 新订
+
+## 适用业务
+
+用于当前邮件要求创建新的：
+
+- FIT Reservation
+- Group Block
+- Allotment / Control Block
+- QBD/LianTai 当前新订行
+- Parent Group 完整拆成 Child Groups 时的 child group
+
+## 判断
+
+- 小于 5 间通常按 FIT。
+- 5 间及以上通常按 Group Block。
+- 独立新建请求明确 allotment、allocation、control block、控房、配额、取配、配合房时，按控房/配额对象优先。
+- Parent Group 完整拆成 Child Groups 是上述控房/配额对象优先规则的明确例外：每个 child 固定输出 `New Booking`，`extracted_fields.booking_object_type=Group Block`；不得因为 split evidence 出现 allocation、allotment 或 `AMEND TO` 就把 child 归为 `Allotment / Control Block` 或普通 Update。
+- 独立新建 `Allotment / Control Block` 就是新建 Parent Group；其 `case_keys.group_code` 与 `case_keys.block_code` 必须按 `31-allotment-control-block.md` 归一为同一 code。Child 和普通 Group Block 仍只填 `group_code`。
+
+## 不适用
+
+- 修改既有订单。
+- 取消。
+- 只有 voucher 或 payment evidence。
+- 只有 Rooming List。
+- 旧 Group Code 改新 Group Code。
+- 只有 Trace 或 extra bed。
+- 动作只在历史邮件中。
+
+## 必要证据
+
+普通候选事件需要：
+
+- 当前创建动作。
+- 目标 key 或足够清楚的新对象身份。
+- 按 `54-stay-date-parsing.md` 可安全识别的入住/离店、房型房量、客人或团队信息等最小新订字段。
+- 系统上下文没有 existing valid record、pending/open task、lock 或 active workflow 阻塞。
+- 涉及必需房型、Rate Code 或 Fix Charge 时，必须有对应 reference 唯一支持；业务必需字段不唯一时不得用 downstream hard validation 代替人工确认。
+
+## 抽取字段
+
+保留：
+
+- group code / confirmation number，如有
+- arrival / departure / nights
+- date evidence：`hotel_date_raw`、`tour_date_raw`、`action_date_raw`、`sheet_month_year`、`date_inference_basis`
+- guest or group name
+- room items，保留 raw room type 和 mapped room code
+- supplier / channel
+- booking object type
+- QBD/LianTai row evidence
+- parent allocation context
+- Rate Code / settlement price evidence
+- Fix Charge evidence
+
+## Linked Trace
+
+New Booking 同事件出现 extra bed、Meeting、meal、arrival notice、room preference/setup、已确定的 payment information 或其他具体预订补充信息时，按目标额外生成一个 linked `Trace`。补充信息即使只是告知，也生成 Trace；主任务已经完整承接的入住日期、房型、房量等核心参数不得重复生成 Trace。
+
+同一目标的多条补充信息合并到一个 Trace；多个目标分别生成 Trace。Extra bed 不计入房量，不影响 FIT/Group，不作为 PMS 房型，不决定 Rate Code。
+
+## 业务复核
+
+当前证据已经能确定 `event_type=New Booking` 和 `booking_object_type` 时，以下问题不得把事件改成 Fallback。保留 `New Booking` 及其 subtype 判别字段，并使用非空、完整的 `manual_review`：
+
+- key identity 不清。
+- 已有订单、pending task、open task 或 active workflow。
+- current/history boundary 不清，但当前创建动作和对象类型已经确定。
+- 多对象无法安全拆分。
+- QBD/LianTai 当前行已确定为 New，但必要行证据不可读。
+- 必需 room mapping、Rate Code 或 settlement price 不唯一。
+- Fix Charge 无法安全解析。
+- Parent split 的 child 身份和 Group Block subtype 已确定，但 child line 的必需字段不完整。
+
+保留所有已确认字段；无法确定的 PMS 房型或其他必需值保持 `null`，并在 `manual_review.missing_fields[]` 中使用指向当前 event 的 RFC 6901 JSON Pointer。
+
+只有当前证据无法确定是 New、Update、Cancel 或 group-code change，或者无法确定 `booking_object_type` subtype 时，才输出 `event_type=Need Manual Review` 的 Fallback 复核。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/11-update-booking.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/11-update-booking.md
new file mode 100644
index 0000000..326faa0
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/11-update-booking.md	
@@ -0,0 +1,92 @@
+# 修改预订
+
+## 适用业务
+
+用于当前邮件要求修改既有：
+
+- FIT Reservation
+- Group Block
+- 日期、晚数、房型、房量、人数、价格、Rate Code、备注或其他订单细节
+
+## 支持的修改
+
+- `update_stay_dates`
+- `update_nights`
+- `update_room_type_or_quantity`
+- `update_guest_count`
+- `manual_rate_code_or_settlement_price`
+- `update_fix_charge`
+- 与主修改同现的 guest request 线索
+
+## 不适用
+
+- Parent-to-child allocation creation，child creation 走 `New Booking`。
+- 旧 Group Code 改新 Group Code，走 `AMEND GROUP CODE`。
+- 只有 extra bed，走 `Trace`。
+- 只有 voucher/payment evidence。
+- 只有 Rooming List。
+- 动作只在历史邮件中。
+- 纯确认或信息消息不属于 Update；其中包含具体预订补充信息时按 `Trace` 处理。
+- 独立的部分 Allotment / Control Block 房量、日期或范围维护，以及明确保留 parent 余量继续使用；当前不支持，不得输出 Update 或 `Allotment Maintenance`。整封邮件只有该意图时走 S10；同邮件另有支持事件时按 `03-current-content-completeness.md` 进入 `unhandled_current_intents`。
+
+## 必要证据
+
+普通候选事件需要：
+
+- 当前 amendment action。
+- existing target key 或唯一目标绑定。
+- reliable before/after 或明确 change detail。
+- 涉及入住、离店或晚数时，按 `54-stay-date-parsing.md` 解析并保留日期证据。
+- 系统上下文支持继续处理。
+- 涉及必需房型、Rate Code 或 Fix Charge 时，必须由对应 reference 唯一支持；业务必需字段不唯一时不得用 downstream hard validation 代替人工确认。
+
+## Before / After
+
+可得时保留：
+
+```json
+{
+  "before_after": [
+    {
+      "field": "arrival_date",
+      "before": "",
+      "after": "",
+      "evidence": ""
+    }
+  ]
+}
+```
+
+当前 amendment 类型和 Update subtype 已确定、但无法建立可靠 before/after 时，保留 `Update Booking / Amendment` 并附非空 `manual_review`。
+
+日期相关 before/after 必须保留 `hotel_date_raw`、`tour_date_raw`、`action_date_raw`、`sheet_month_year` 和 `date_inference_basis`，如适用。
+
+## Linked Trace
+
+Extra bed、Meeting、meal、arrival notice、room preference/setup、已确定的 payment information 或其他具体预订补充信息与有效 update 同现时：
+
+- 输出主 `Update Booking / Amendment`。
+- 按目标输出一个 linked `Trace`；同一目标的多条补充信息合并。
+- 补充信息即使只是告知，也生成 Trace。
+- Update 已完整承接的 before/after 核心字段不得重复写成 Trace。
+
+如果当前只有 Trace 补充信息，或只要求 add/update/cancel extra bed，不创建 Update 事件。
+
+## Fix Charge
+
+Fix Charge 可通过 Update 维护，但必须确认目标和动作类型：add、update 或 cancel。Update 及 subtype 已知、但目标、动作或金额不安全时，保留 `Update Booking / Amendment` 并附非空 `manual_review`；只有 Update subtype 本身无法确定时才使用 Fallback。
+
+## 业务复核
+
+当前证据已经能确定 `event_type=Update Booking / Amendment` 及其 Update subtype 时，以下问题保留原业务事件，并使用非空、完整的 `manual_review`：
+
+- 原订单找不到或目标不清。
+- 前置任务未完成或系统上下文阻塞。
+- before/after 不可靠。
+- 必需 room mapping、Rate Code 或 price 不唯一。
+- Fix Charge 动作或金额不清。
+- QBD/LianTai 当前行已确定为 Update，但 row、highlight 或 strikethrough 证据不完整。
+
+保留已确认的 before/after、目标候选和原始字段；缺失字段使用 RFC 6901 JSON Pointer 写入 `manual_review.missing_fields[]`。
+
+只有当前动作无法在 New Booking、Update Booking、Cancel 或 Amend Group Code 之间确定，或者 Update subtype 本身无法确定时，才输出 `event_type=Need Manual Review` 的 Fallback 复核。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/12-cancel-booking.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/12-cancel-booking.md
new file mode 100644
index 0000000..2448e06
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/12-cancel-booking.md	
@@ -0,0 +1,70 @@
+# 取消预订
+
+## 适用业务
+
+用于当前邮件要求取消或释放：
+
+- FIT Reservation
+- Group Block
+- Allotment / Control Block
+- 控房或配额
+
+可接受信号：
+
+- cancel booking / reservation / group
+- release or cancel block
+- cancel allotment / allocation / control block
+- `CXL`
+- 明确整单取消
+
+## 事件类型
+
+- `Cancel Booking`：只取消 FIT Reservation、普通 Group Block 或 Child Group Block。
+- `Cancel Allotment`：取消整个 Allotment / Control Block，也就是 Parent Group。
+
+Parent Group 的 `case_keys.group_code` 与 `case_keys.block_code` 必须相同；普通或 Child Group Block 继续只填 `group_code`、`block_code=null`。
+
+## 部分修改边界
+
+减少房量、改日期、释放部分 allocation 或明确保留 parent 余量继续使用，当前均不受支持；不得输出 Update、Cancel 或 `Allotment Maintenance`。整封邮件只有该明确意图时走 S10；同邮件另有支持事件时按 `03-current-content-completeness.md` 进入 `unhandled_current_intents`。
+
+如果当前证据无法确定是整块取消、完整 Parent split，还是部分维护/保留余量，则业务类型或 subtype 尚未确定，输出 `event_type=Need Manual Review` 的 Fallback 复核。
+
+## Parent Allocation Linked Event
+
+当当前证据已经确认 Parent Group 完整拆成 Child Groups 时，必须为 parent group 生成独立 linked cancel candidate：`event_type=Cancel Allotment`、`extracted_fields.cancel_scope=entire_allotment_control_block`、`relationship_type=linked_parent_release_after_child_split`、`requires_downstream_hard_validation=true`。
+
+这个事件：
+
+- 不替代 child New Booking。
+- 每个 child 固定是 `New Booking` 且 `booking_object_type=Group Block`；parent candidate 的 `related_source_event_indices[]` 必须指向全部 child events。
+- 不要求字面 cancel / CXL。
+- 必须来自当前 parent-child split 证据。
+- 不得由历史证据单独触发。
+- 只是候选事件，不代表 PMS 已取消成功，不创建真实 TaskCard，不写外部系统。
+- 无论正文是否显式写取消，同一 split cluster 都只能有一个 Parent `Cancel Allotment`。显式取消同一 parent 时合并证据；不同 parent 才分别输出。
+- 当前 Agent 不得再生成 linked Parent `Cancel Booking`；旧组合只允许 reader/adapter 无损兼容展示。
+
+## 不适用
+
+- 新建，除 Parent split 派生的 linked `Cancel Allotment` 外。
+- 普通 date/room/guest/price amendment。
+- Voucher/payment evidence。
+- Rooming List。
+- 只有 Trace。
+- cancel action 只在历史邮件中。
+
+## 业务复核
+
+当前证据已经能确定 `Cancel Booking`/`Cancel Allotment` 及其对象 subtype 时，以下问题保留原业务事件，并使用非空、完整的 `manual_review`：
+
+- cancel target 不清。
+- 多目标无法安全拆分。
+- 系统上下文显示 conflict、lock 或 already completed state。
+- 完整 Parent split 已确认，`Cancel Allotment` subtype 已确定，但 parent 双 key、child list 或关系证据不完整。
+
+Parent split 的关系字段不安全时不得把候选视为已取消；保留已确认的 parent/child 证据，并在 `manual_review.missing_fields[]` 中使用 RFC 6901 JSON Pointer。
+
+Parent 双 key 候选冲突时，两键置空并使用 `manual_review.reason_code=target_object_unclear`；关系字段不安全时使用 `parent_child_split_evidence_unclear`。
+
+只有 `CXL` 是否为当前动作不清、无法确定是普通订单取消还是 Allotment 整块取消，或无法确定是完整 split 还是部分维护时，才输出 `event_type=Need Manual Review` 的 Fallback 复核。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/13-voucher-payment.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/13-voucher-payment.md
new file mode 100644
index 0000000..8e709b9
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/13-voucher-payment.md	
@@ -0,0 +1,111 @@
+# Voucher 与付款凭证
+
+## 适用业务
+
+仅当当前邮件包含真实当前 voucher 或 payment evidence 时使用：
+
+- 当前附件图片
+- 当前 inline image
+- 当前 PDF
+- 当前 downloaded file reference
+
+事件类型：
+
+- `Voucher Received`
+- `Payment Evidence`
+
+两者共享当前附件、目标绑定和安全规则，但不是同一个事件：实际 `CREDIT VOUCHER` 文档输出 `Voucher Received`；银行转账、现金存款或交易回执输出 `Payment Evidence`。Voucher 不证明资金到账，Payment Evidence 也不表示酒店已经确认付款。
+
+## Credit Voucher
+
+典型信号：
+
+- LT / LianTai logo。
+- 泰國聯泰旅運集團有限公司 / `LIAN TAI TRAVEL GROUP (THAILAND) CO., LTD.`
+- `CREDIT VOUCHER`
+- `DATE`、`CODE / 團號`、`IN`、`OUT`
+- `SGL`、`TWN`、`TRP`
+- `B`、`L`、`D`
+- 手写、盖章或签名
+
+`CODE / 團號` 是优先目标来源。已经确定事件为 `Voucher Received`、但该字段模糊、空白或冲突时，保留 `Voucher Received` 并附非空 `manual_review`。
+
+## Bank Transfer Slip
+
+付款证据可包括：
+
+- 银行转账成功截图
+- 现金存款收据
+- 交易收据
+- payment slip
+- payment confirmation 图片/PDF
+
+## 不得仅凭文本触发
+
+以下信号不能单独触发：
+
+- 关键词 `voucher` / `payment slip`
+- subject `FULL PAYMENT`
+- 文字说 voucher 已发送
+- 只有附件文件名
+- 酒店回复 thanking voucher
+- 只有历史中的 voucher
+- 没有当前 image/PDF/file evidence 的表格状态
+
+只有被动文本或文件名提到 voucher、但没有当前 image/PDF/file 对象，也没有明确 current 收件/处理信号时，不足以形成支持业务事件；整封邮件没有其他 active 信号则由 Main Agent 输出 `S10`。如果 current 正文明确信号已经足以确定 `Voucher Received` 或 `Payment Evidence`，只是必要附件缺失、无法取得或不可读，则仍形成对应粗候选；Skill 保留该已知业务事件并附非空 `manual_review`，不得降级为 S10/S99/Fallback。
+
+当前文件对象存在，且当前证据已经能唯一确定 `Voucher Received` 或 `Payment Evidence` 时，即使文件部分不可读或目标不安全，也保留该业务 `event_type` 并附非空 `manual_review`。当前证据已确认属于 voucher/payment evidence 业务方向、但无法在两个事件类型之间确定时，输出 `event_type=Need Manual Review` 的 Fallback 复核；如果连是否属于受支持业务方向都无法判断，则按入口规则使用 S99。
+
+## 同邮件其他付款内容
+
+- 当前付款凭证与需要酒店决定的付款安排询问同现时，付款文件输出 `Payment Evidence`，询问原文按 `03-current-content-completeness.md` 输出到 `unhandled_current_intents`。
+- 例如“余款能否入住时支付”是付款政策审批询问，不是 `Payment Notice`，也不得改名为 Trace。
+- “余款将在入住时支付”是已经确定、需要随预订保留的补充付款安排，可以按 `16-trace-notes.md` 输出 `Trace.payment_information`。
+- 当前凭证与未覆盖意图必须分别保留；不得因为付款图片已成功路由就丢弃正文中的审批询问。
+
+## 目标绑定
+
+一个 voucher/payment event 绑定一个目标 group code 或 reservation key。多个 group code 必须拆分。
+
+一张 bank slip 覆盖多个 group code 时，每个 group code 输出一个事件，并在 `extracted_fields.related_group_codes` 保留完整集合。多个事件可以共享同一个 `voucher_attachment.file_reference`。
+
+不要把 amount、date、bank account、payer、payee、reference number、QR 或 memo 抽成业务字段。用户应查看原始图片或 PDF。
+
+## 下游意图
+
+事件可以保留下游意图：付款确认后将 Reservation Type 更新为 `PD`。本 skill 不确认 payment，也不执行更新。
+
+```json
+{
+  "voucher_attachment": {
+    "display_original": true,
+    "file_reference": ""
+  },
+  "requires_department_routing": true,
+  "department_routing": [
+    {
+      "department": "Finance",
+      "purpose": "confirm_payment_received",
+      "required": true,
+      "status": "pending"
+    }
+  ],
+  "post_confirmation_intent": {
+    "reservation_type": "PD",
+    "status": "pending_payment_confirmation"
+  }
+}
+```
+
+## 业务复核
+
+当前证据已经能确定 `Voucher Received` 或 `Payment Evidence` 时，以下问题保留该业务事件，并使用非空、完整的 `manual_review`：
+
+- 当前 image/PDF/file 部分不可读，但事件类型已经由可靠当前证据确定。
+- 多个 group code 无法安全拆分。
+- target key 缺失或无法唯一绑定。
+- `Voucher Received` 的 CODE / 團號模糊或冲突。
+
+保留当前文件引用和所有可读字段；缺失字段使用 RFC 6901 JSON Pointer 写入 `manual_review.missing_fields[]`。
+
+只有当前证据已确认 voucher/payment evidence 业务方向、但无法在 `Voucher Received` 与 `Payment Evidence` 之间确定事件类型时，才输出 `event_type=Need Manual Review` 的 Fallback 复核；连受支持业务方向都无法判断时使用 S99。只有历史提及或被动文件名、没有当前 image/PDF/file 对象且没有明确 current 收件/处理信号时，不生成上述业务事件；按入口支持范围使用 S10 或同邮件其他结果。若 current 信号已确定业务卡型而附件缺失/不可读，必须保留该业务 event 并使用非空 `manual_review`。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/14-rooming-list.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/14-rooming-list.md
new file mode 100644
index 0000000..0e6f503
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/14-rooming-list.md	
@@ -0,0 +1,58 @@
+# Rooming List 与 Name List
+
+## 适用业务
+
+用于当前邮件提供：
+
+- Rooming List
+- Name List / NAMELIST / NAME LIST
+- guest list
+- 分房名单
+- guest-level list material 的文件、链接或内容
+
+载体可以是附件、inline file、Google Drive / 网盘链接、downloaded file reference、PDF、图片、Excel、OCR 或 table。载体本身不够，必须证明内容或上下文确实是名单。
+
+## 正向证据
+
+- 当前文本明确说 Rooming List / Name List / 分房名单 / 客人名单。
+- 当前文件内容有 guest-level rows、names 或 room assignment。
+- LianTai/QBD 名单附件的 file name 匹配完整 group code 格式，且与表内字段、正文或历史上下文至少一项互相印证。
+- 当前文件是在直接回复酒店最近索要 rooming list。
+- QBD/LianTai 当前事件明确是 NAME LIST / Rooming List，且名单证据可读。
+
+## 负向证据
+
+不要把以下内容当作 Rooming List：
+
+- QBD/LianTai booking update table。
+- `BOOKING 01-2026` 之类月度 booking sheet。
+- 包含 group code、pax、itinerary、hotel、status、UPDATE、NEW BOOKING、AMEND、CXL、CFM、room quantity、price、hotel response 的表。
+- invoice、payment、voucher、allotment、control block sheet。
+- 只有文件名，缺名单证据。
+- history-only rooming list mention。
+
+## 目标拆分
+
+- 按 target group/object 拆分。
+- workbook 可包含多个 group 或 sheet。
+- sheet name 是 evidence，不是最终证明。
+- file name 可以作为 target group binding evidence；不得仅凭 file name 单独决定 group code。
+- 一个目标对象一个 Rooming List event。
+
+## 下游意图
+
+Rooming List 可能派生：
+
+- `TA RECORDER`
+- `Note`
+- Routing / PM room / Block Status update intent
+
+本 skill 只输出候选事件和意图。真实导入和更新由信息系统执行。
+
+## 人工复核
+
+- file/link 无法下载或读取。
+- 不清楚文件是名单还是 booking update table。
+- target group binding 不清。
+- 多个 group 无法安全拆分。
+- sheet/file name 与表内字段、当前文本、历史上下文或系统上下文冲突。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/15-amend-group-code.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/15-amend-group-code.md
new file mode 100644
index 0000000..a605ac6
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/15-amend-group-code.md	
@@ -0,0 +1,58 @@
+# 修改 Group Code
+
+## 适用业务
+
+用于当前事件明确要求把既有 booking、group 或 reservation 的 Group Code 从旧值改为新值。
+
+事件类型：`AMEND GROUP CODE`
+
+## 强信号
+
+- `AMEND GROUP CODE TO : <new_group_code>`
+- `AMEND GROUP CODE`
+- `A to B`
+- `A change to B`
+- `A 改为 B`
+- `A เปลี่ยนเป็น B`
+
+必须能表达 old group code -> new group code 的方向关系。
+
+## 来源
+
+可以来自当前 body、table、PDF、image OCR 或附件内容。
+
+## 输出字段
+
+前端展示字段保持窄口径：
+
+- `old_group_code`
+- `new_group_code`
+
+其他证据放在 `context_used` 或 `extracted_fields`。
+
+## 不适用
+
+- 只有一个 group code，old/new 关系不清。
+- 普通 date/room/price/guest amendment。
+- New Booking creation。
+- Cancel / release / allotment。
+- Voucher/payment evidence。
+- Rooming List。
+- 纯确认或 history-only group code change。
+- 主语义是 cancel/release，只是顺带出现 moved/join group。
+
+## 表格规则
+
+不得依赖固定列、行、单元格或 sheet name 作为业务规则。必须依赖文本语义和 old/new 关系。单元格位置只能作为 evidence。
+
+## Linked Trace
+
+AMEND GROUP CODE 同邮件出现 extra bed、Meeting、meal、arrival notice、room preference/setup、已确定的 payment information 或其他具体预订补充信息时，按目标额外生成一个 linked `Trace`。同一目标的多条补充信息合并；补充信息即使只是告知，也不得忽略。old/new group code 核心字段不得重复生成 Trace。
+
+## 人工复核
+
+- old code 缺失。
+- new code 缺失或不可读。
+- 方向不清。
+- 多个 possible old/new pair 冲突。
+- current/history boundary 不清。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/16-trace-notes.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/16-trace-notes.md
new file mode 100644
index 0000000..3041fee
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/16-trace-notes.md	
@@ -0,0 +1,214 @@
+# 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` 缺失。
+- 当前信息是要求还是单纯告知不清。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/17-ta-recorder-note.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/17-ta-recorder-note.md
new file mode 100644
index 0000000..60005fa
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/17-ta-recorder-note.md	
@@ -0,0 +1,66 @@
+# TA Recorder 与 Note
+
+## 适用业务
+
+TA Recorder 通常由已确认的 Rooming List / Name List 事件派生。
+
+事件类型：
+
+- `TA RECORDER`
+- `Note`
+
+## Direct Request
+
+只有同时满足以下条件时，才允许直接从当前邮件识别 TA Recorder：
+
+- 当前文本明确要求 maintain/update TA Recorder。
+- 目标 `group_code` 唯一。
+- 存在名单或分房附件、链接或 file reference。
+- 文件与目标绑定清楚。
+
+## 派生规则
+
+Rooming List 已确认 target group codes 时：
+
+- 每个目标 `group_code` 派生一个 TA Recorder event。
+- 多个目标可以共享同一个 workbook/file reference。
+- 保留与 Rooming List event 的关系。
+
+TA Recorder 不是一封邮件一张卡、一个 workbook 一张卡或一个 sheet 一张卡。它是一个目标 `group_code` 一个事件。
+
+## Sheet 规则
+
+- Sheet name 可以作为 binding evidence。
+- Sheet name 不得单独决定 group code。
+- File name 可以作为 binding evidence；当 file name 匹配完整 group code 格式时，仍需 Rooming List 目标绑定已确认后才可派生 TA Recorder。
+- Sheet name 或 file name 与表内字段、正文、历史上下文冲突时，输出人工复核。
+- `IN9-17` 不是 group code。
+- `总名单` 是 shared evidence，不是单独目标。
+- `WpsReserved_CellImgList` 等系统 sheet 忽略。
+
+## Note
+
+Rooming List 也可能派生 Note。Note 字段可包含：
+
+- payer code
+- charge code
+- breakfast
+- note text
+
+具体可写字段由信息系统模板和人工确认决定。
+
+## 不适用
+
+- `TA` 只是 travel agent、source 或 reservation type。
+- parent Rooming List 是人工复核。
+- 文件不可读或无权限。
+- 没有名单/分房文件。
+- current/history boundary 不清。
+
+## 人工复核
+
+- target group code 不清。
+- attachment/file binding 不清。
+- workbook 包含多个 group，但 target split 未确认。
+- sheet/file name 与正文、表内字段或 Rooming List binding 冲突。
+- parent Rooming List 未确认。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/18-invoice.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/18-invoice.md
new file mode 100644
index 0000000..dae0e95
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/18-invoice.md	
@@ -0,0 +1,36 @@
+# Invoice 与 Payment Notice
+
+## 适用业务
+
+用于当前证据明确要求：
+
+- 生成 Proforma Invoice。
+- 提供 invoice 所需材料。
+- 收到已有 invoice 或 revised invoice。
+- 发送不属于 voucher/payment image evidence 的 payment notice。
+
+事件类型：
+
+- `Invoice Generation`
+- `Invoice Received`
+- `Payment Notice`
+
+`Payment Notice` 是清楚的付款通知，不是付款条件审批。需要酒店决定是否接受分期、延期、账期、余款到店支付或其他付款政策的询问，不输出 `Payment Notice`：同邮件存在其他支持事件时进入 `unhandled_current_intents`，整封邮件没有支持事件时由 Main Agent 输出 S10。
+
+当前邮件同时包含 bank slip/payment receipt 与付款安排询问时，文件按 `13-voucher-payment.md` 输出 `Payment Evidence`，询问按 `03-current-content-completeness.md` 单独保留；不得合并后遗漏询问。
+
+## 安全边界
+
+- 不生成 Invoice Excel/PDF。
+- 不确认 payment。
+- 不创建 receipt。
+- 不执行 storage 或 accounting 动作。
+- 只输出候选事件、证据、目标 key 和人工复核点。
+
+## 业务复核
+
+在详细 invoice 字段规则未完善前：
+
+- 当前证据已经能唯一确定 `Invoice Generation`、`Invoice Received` 或 `Payment Notice` 时，目标、材料或必需字段不安全不得改成 Fallback；保留该业务 `event_type`，保留所有已确认字段，并附非空、完整的 `manual_review`。
+- `manual_review.missing_fields[]` 必须使用指向当前 event 的 RFC 6901 JSON Pointer。
+- 只有无法在 `Invoice Generation`、`Invoice Received` 和 `Payment Notice` 之间确定事件类型或对应 subtype 时，才输出 `event_type=Need Manual Review` 的 Fallback 复核。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/30-qbd-liantai-workflow.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/30-qbd-liantai-workflow.md
new file mode 100644
index 0000000..965e977
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/30-qbd-liantai-workflow.md	
@@ -0,0 +1,101 @@
+# QBD / LianTai 表格工作流
+
+## 适用场景
+
+当当前邮件、附件、发件人、主题、表格、OCR 或抽取证据显示 QBD/LianTai 工作流时读取。
+
+常见信号：
+
+- QBD / LianTai 发件人或渠道。
+- Excel/table 附件。
+- `BOOKING UPDATE`、`NEW BOOKING`、`AMEND`、`AMD`、`AMD ALLOTMENT`、`CXL`、`CFM`。
+- 黄色/高亮行、红字、删除线、hotel status column、泰文 `โรงแรม` 或酒店回应/状态单元格。
+
+## 当前行规则
+
+- 只有当前有效行可以触发事件。
+- 当前邮件附件中业务列被 yellow/highlight 的行全部视为当前有效行，不要求 `action_date_raw` 匹配邮件标题日期。
+- 业务列包括 group code、人数、行程、酒店、备注、酒店状态等列；只有序号列、标题、说明区或装饰单元格上色，不单独触发事件。
+- 每个当前有效行必须独立处理，不得跨行合并。普通情况下每行、每目标生成一个主事件；Parent split 的 parent `Cancel Allotment` candidate、linked Trace 和其他契约明确的 linked/derived events 可以额外产生。
+- 不得用汇总字段或数组型 `case_keys.group_code` 合并多行。
+- 行的业务类型和 subtype 已知，但 highlight、sheet、status 或其他必需行证据不安全时，保留该业务事件并附非空 `manual_review`；只有类型或 subtype 无法确定时才输出 `Need Manual Review` Fallback。
+- 某一行不安全，不得阻塞其他安全行。
+
+## 行证据
+
+保留：
+
+- attachment/file name
+- workbook/sheet
+- row index / row label
+- highlight / yellow / red text / strikethrough
+- action/status cell raw text，包括 `action_date_raw`
+- hotel date raw text、tour date raw text、sheet month/year、raw nights
+- raw room type / room quantity
+- raw price / rate marker
+- hotel status text
+- before/after evidence
+- OCR/table confidence，如有
+
+## 日期识别
+
+酒店入住、离店和晚数必须按 `54-stay-date-parsing.md` 解析。
+
+- 酒店列开头住期范围优先，例如 `14-15`、`15-17`、`31-02`。
+- 行程日期列用于补全年/月和校验，不得直接覆盖酒店住期。
+- `action_date_raw` 只作为动作证据，不是入住日期，也不是标黄行过滤条件。
+
+## 新订行
+
+当前行明确 `NEW BOOKING`、`NEW`、新增、จองใหม่，且目标和最小字段清楚时，可路由 `New Booking`。新订创建前通常没有 confirmation number；缺 confirmation number 不是复核原因。
+
+## 修改行
+
+Amendment 行需要可靠 current amendment 和 before/after evidence，除非实质是 parent-to-child allocation creation。
+
+标准 OP 联系兜底文字不应当作业务 amendment，除非包含具体可执行请求。
+
+明确的部分 Allotment / Control Block 维护或保留 parent 余量继续使用当前不受支持，不得路由为 Update 或 `Allotment Maintenance`。整封邮件只有该意图时走 S10；混合邮件按 `03-current-content-completeness.md` 保留为 `unhandled_current_intents`。
+
+## 取消行
+
+`CXL`、cancel、release、cancel block 可路由 `Cancel Booking` / `Cancel Allotment`，前提是动作来自当前有效行且目标清楚。
+
+## Parent-To-Child Allocation
+
+当当前证据明确显示 Parent Group 完整拆成 Child Groups，parent 不保留余量，并列出 child group code 及日期、晚数、房型、房量：
+
+- 每个 child group 固定路由为 `New Booking`，`booking_object_type=Group Block`；不得归为 Allotment / Control Block creation。
+- 一个 child group code 一个主事件；同一来源行列出多个 children 时仍按 child 分开。
+- parent 放入 `parent_group_code` 或 `parent_allocation_context`。
+- 不得把 parent group 写成 child event 的 `case_keys.group_code`。
+- 不要求普通 amendment 的 before/after。
+- Allotment / Control Block 就是 Parent Group；其 Allotment code、Parent Group code、`case_keys.group_code` 与 `case_keys.block_code` 是同一 code。
+- parent group code 清楚时，必须额外生成一个独立 linked parent cancel candidate：`event_type=Cancel Allotment`、`cancel_scope=entire_allotment_control_block`、`relationship_type=linked_parent_release_after_child_split`、`requires_downstream_hard_validation=true`。
+- parent candidate 的 `related_source_event_indices[]` 必须指向该 split cluster 的全部 child New Booking events。
+- parent release/cancel candidate 是候选事件，不代表 PMS 已取消成功。
+- 同一 parent 的字面 `Cancel Allotment` 与 split 派生取消合并为一个事件；不同 parent 才分别输出。当前 producer 不得生成 linked Parent `Cancel Booking`。
+
+如果某 child line 只有 generic `SUITE` 且无法唯一映射必需 PMS 房型，保留 `room_type_raw=SUITE`、令 PMS 房型 code 为 `null`，保留该 child 的 `New Booking + Group Block` 判别字段，并附非空 `manual_review`；不得用 downstream hard validation 代替人工确认。该 child 的复核不阻塞其他安全行。
+
+明确只转移部分房量或保留 parent 余量继续使用时，不属于 Parent split；不得生成 parent Cancel candidate。完整 split 已确定但 parent key 或关系字段不安全时，保留 `Cancel Allotment` 同卡复核；无法判断是完整 split 还是部分维护时，类型/subtype 未确定，输出 `Need Manual Review` Fallback。
+
+## 行内 Trace 补充信息
+
+extra bed / 加床 / `เตียงเสริม` / `U-เตียงเสริม`：
+
+- 不计入 room quantity。
+- 不决定 FIT/Group。
+- 不映射 PMS room type。
+- 不决定 Rate Code。
+- 与主事件同现时，生成 linked `Trace`。
+
+当前有效行或同邮件中与该行目标明确关联的 Meeting、meal、arrival notice、room preference/setup、已确定的 payment information 或其他具体预订补充信息，也生成 linked `Trace`。信息即使只是告知也保留；同一目标的多条补充信息合并为一个 Trace，多个 group code 分别生成 Trace。主事件已完整承接的核心字段不得重复写入 Trace。
+
+## 价格 Marker
+
+`U-<number>` 是 price/rate marker，不是 confirmation、reservation 或 booking reference。可用于 Rate Code / settlement price 判断。
+
+## 名单边界
+
+Rooming List / Name List 文件不得与 QBD/LianTai booking update 表混淆。看文件内容，而不是只看 Excel 载体。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/31-allotment-control-block.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/31-allotment-control-block.md
new file mode 100644
index 0000000..f3a516d
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/31-allotment-control-block.md	
@@ -0,0 +1,133 @@
+# Allotment / Control Block 与 Parent Group
+
+## 权威业务定义
+
+本文件是 Allotment / Control Block 与 Parent Group 语义的权威来源：
+
+```text
+Allotment / Control Block = Parent Group
+Allotment code = Parent Group code
+Parent Group 的 block_code = group_code
+```
+
+`Parent` 是完整 split 关系中的角色，不是独立于 Allotment / Control Block 的第二种预订对象。`group_code` 是统一业务主键；`block_code` 是 Parent Group 场景的兼容别名。
+
+对象边界固定为四类：
+
+1. 独立新建 Parent Group：`New Booking`，`booking_object_type=Allotment / Control Block`。
+2. 独立整块取消 Parent Group：`Cancel Allotment`。
+3. Parent Group 完整拆成 Child Groups：每个 child 为 `New Booking + Group Block`，另有且只有一个 parent `Cancel Allotment`。
+4. 部分维护、部分释放或保留 parent 余量：当前不受支持，不得伪装为上述三类。
+
+## Parent Identity
+
+所有当前 producer 生成的 Parent Group 事件都必须使用：
+
+```json
+{
+  "case_keys": {
+    "group_code": "<parent_code>",
+    "confirmation_number": null,
+    "reservation_number": null,
+    "block_code": "<parent_code>"
+  }
+}
+```
+
+固定规则：
+
+- 只取得 `group_code` 或 `block_code` 任一值时，归一后同时写入两个键。
+- 两个值同时存在且归一后不同，不得选择其一或输出冲突 key；两键均置为 `null`，在 `context_used.parent_identity_candidates[]` 保留原始候选证据，并在已知业务卡上使用 `manual_review.reason_code=target_object_unclear`。
+- Child Group 和普通 Group Block 继续只使用 `group_code`，`block_code=null`。
+- Parent code 不得写入 child event 的 `case_keys.group_code`。
+
+## 新建 Parent Group
+
+当前证据要求新建 allotment、allocation、control block、控房、配额、取配或配合房时，路由到 `New Booking`：
+
+```json
+{
+  "booking_object_type": "Allotment / Control Block"
+}
+```
+
+它是 Parent Group creation；其 `case_keys.group_code` 与 `case_keys.block_code` 必须按 Parent Identity 规则归一为同一值。
+
+## 整块取消 Parent Group
+
+明确取消整个 Allotment / Control Block 时使用 `Cancel Allotment`。这是取消 Parent Group，不是普通 Group Block 的 `Cancel Booking`。
+
+独立整块取消不需要 split 关系字段，但仍必须满足 Parent 双 key 等值不变量。
+
+减少房量、改部分日期、释放部分 allocation 或保留余量，不得路由为 Update、Cancel 或 `Allotment Maintenance`：整封邮件只有该意图时走 S10；同邮件另有支持事件时按 `03-current-content-completeness.md` 进入 `unhandled_current_intents`。
+
+## 完整 Parent-To-Child Split
+
+当当前证据明确显示 Parent Group 完整拆成 Child Groups，且 parent 不保留余量：
+
+- 每个 child group 一个 `New Booking`，`booking_object_type=Group Block`。
+- parent 是被完整取消/释放的 Allotment / Control Block。
+- 保留 `allocation_split_from_parent=true`、parent original room summary 和 child group 列表。
+- 不得因为文本写 `AMEND` 就归为普通改单。
+- 不得因为出现 allocation/allotment/control block 字样就把 child 归为 `Allotment / Control Block`。
+- 无论正文是否字面出现 `cancel` / `CXL`，都必须额外输出且只输出一个 linked parent `Cancel Allotment` candidate。
+
+Parent split 事件固定为：
+
+```json
+{
+  "event_type": "Cancel Allotment",
+  "case_keys": {
+    "group_code": "<parent_code>",
+    "confirmation_number": null,
+    "reservation_number": null,
+    "block_code": "<parent_code>"
+  },
+  "extracted_fields": {
+    "cancel_scope": "entire_allotment_control_block",
+    "parent_release_or_cancel_candidate": true,
+    "release_reason": "parent_to_child_allocation_split",
+    "parent_group_code": "<parent_code>",
+    "child_group_codes": ["<child_code>"],
+    "allocation_split_from_parent": true,
+    "parent_original_room_summary": null
+  },
+  "related_source_event_indices": ["<child_event_index>"],
+  "related_event_type": "New Booking",
+  "relationship_type": "linked_parent_release_after_child_split",
+  "requires_downstream_hard_validation": true,
+  "manual_review": null
+}
+```
+
+该事件：
+
+- 不替代 child creation。
+- 只是候选事件，不代表 PMS 已取消成功，不创建真实 TaskCard，不写外部系统。
+- 不得由 history-only parent-child evidence 触发。
+- 复用 `Cancel Allotment / cancel_allotment_control_block` 卡；`relationship_type` 只负责 child 关联和 Preflight，不选择另一个任务卡 subtype。
+- 当前 Agent 不得再生成 `Cancel Booking + linked_parent_release_after_child_split`。
+
+## 显式取消去重
+
+- 当前正文的显式 `Cancel Allotment` 与完整 split 派生取消命中同一归一化 parent code 时，合并两类证据，只保留一个上述 linked `Cancel Allotment` 事件。
+- 显式取消命中不同 parent code 时，各 parent 独立输出，不得错误合并。
+- 一个 split cluster 只能有一个 parent event。
+- `child_group_codes[]` 不得重复，并与 `related_source_event_indices[]` 的数量和顺序一一对应。
+- 每个 related index 必须指向同一 `message_events[]` 中对应 child code 的 `New Booking + Group Block`。
+
+## 复核与 Fallback
+
+- 完整 split 和 Parent `Cancel Allotment` subtype 已确定，但 parent key 冲突、child list 或关系字段不安全时，保留 `Cancel Allotment` 并附完整 `manual_review`。
+- Parent 双 key 冲突使用 `target_object_unclear`；split 关系不完整使用 `parent_child_split_evidence_unclear`。
+- 只有无法确认是否为完整 split，或无法在完整 split 与部分维护/保留余量之间裁决时，才输出 `event_type=Need Manual Review` 的 Fallback 复核。
+
+## Legacy 只读兼容
+
+历史 payload 中的 `Cancel Booking + relationship_type=linked_parent_release_after_child_split` 不迁移、不改写。Reader/adapter 可以无损读取后展示为 `Cancel Allotment / cancel_allotment_control_block` 卡；该兼容规则不得被当前 producer 用来继续生成旧组合。
+
+## 默认 Rate / Room
+
+Allotment / Control Block 缺 explicit Rate Code 时，只能在 room mapping 唯一且上下文明显符合 control-block default rules 时使用 `51-rate-code.md` 默认。
+
+必需 room mapping 或 Rate Code 不唯一时保留 raw values、对应 PMS/code 字段为 `null`。当 `New Booking + Allotment / Control Block` 或 `New Booking + Group Block` subtype 已知时，保留原业务事件并附非空 `manual_review`；不得用 downstream hard validation 替代人工确认。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/50-room-type-mapping.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/50-room-type-mapping.md
new file mode 100644
index 0000000..67f5c34
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/50-room-type-mapping.md	
@@ -0,0 +1,41 @@
+# 房型映射
+
+## 安全立场
+
+房型映射必须由本 reference 支持且唯一。必需房型未覆盖或存在歧义时，保留 raw text、PMS room type code 为 `null`，并在原业务事件上附非空 `manual_review`；不得使用 downstream hard validation 代替人工确认。不要凭常识猜 PMS room type。
+
+## 已知规则
+
+| Raw / normalized signal | PMS room type code | 说明 |
+| --- | --- | --- |
+| 普通 `DBL`, `Double`, `1 DBL` | `RM2` | 普通 DBL。 |
+| 普通 `TWN`, `Twin`, `1 TWN` | `RM3` | 普通 TWN。 |
+| `U-DBL`, `Upgrade DBL` | `RM2` | Rate Code 走 upgrade 口径。 |
+| `U-TWN`, `Upgrade TWN` | `RM3` | Rate Code 走 upgrade 口径。 |
+| `U-TRP`, `TRP`, `Triple` | `RM4` | 需结合人数/家庭房语境确认。 |
+| `DBL SUITE`, `Double Suite`, `SUITE DBL` | `SU1` | 必须有明确 DBL suite 线索。 |
+| `TWN SUITE`, `Twin Suite`, `SUITE TWN` | `SU6` | 必须有明确 TWN suite 线索。 |
+| `FAMILY 3PAX`, `FAMILY 4PAX` | `SU3` | 家庭房规则。 |
+| `ST+K`, `2卧1厅`, `FAMILY 1` 且组合证据匹配 | `SU3` | Rate Code 继续按渠道/价格判断。 |
+| `HNM`, Honeymoon | 默认 DBL 路径 | 仅在没有更明确房型时使用。 |
+
+## 保留规则
+
+- 始终保留 `room_type_raw`。
+- normalized room text 与 PMS code 分开保存。
+- 不得让 PMS code 抹掉 `U-`、`Sup`、高级房、suite/family、price 等原始线索。
+- 不得仅凭 room code 反推 Rate Code。
+- Extra bed / 加床 / `เตียงเสริม` 不是房型。
+- `Q10` 类 suite 文本必须结合 twin/double/layout evidence；不得只凭 `Q10` 单独映射。
+
+## 业务复核
+
+以下房型不安全情况在业务 `event_type` 和 subtype 已知时，必须保留原业务事件并附非空、完整的 `manual_review`：
+
+- generic `SUITE` 没有精确床型，包括 Parent split child；不再存在 normal candidate / downstream-hard-validation 例外。
+- `FAMILY 1` 缺 ST+K / 2卧1厅 / 1200 组合证据。
+- `HNM` 与更明确房型冲突。
+- 存在多个映射候选。
+- raw room text 混合不兼容类别。
+
+始终保留 `room_type_raw`，令无法唯一确认的 `pms_room_type_code=null`，并在 `manual_review.missing_fields[]` 中写入对应 PMS code 字段的 RFC 6901 JSON Pointer。只有房型证据同时导致业务类型或 subtype 本身无法确定时，才使用 `event_type=Need Manual Review` 的 Fallback 复核。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/51-rate-code.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/51-rate-code.md
new file mode 100644
index 0000000..95e72b5
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/51-rate-code.md	
@@ -0,0 +1,76 @@
+# Rate Code 与结算价格
+
+## 安全立场
+
+Rate Code 必须由当前证据和本 reference 唯一支持。不要只凭 room code 猜。若 channel、market、room text、UP marker、price、breakfast、restaurant 或 supplier 上下文不足，输出人工复核。
+
+## 已知规则
+
+| 场景 | Typical Rate Code |
+| --- | --- |
+| QBD 普通 DBL/TWN 且无 `U` 或 Upgrade marker | `GRPA1-900` |
+| QBD `U-DBL` / `U-TWN` / `U-TRP` 或 Upgrade marker | `GRPA2-850UP` 或对应 UP rate code |
+| LianTai 普通 DBL/TWN 或 Sup DBL/Sup TWN | `GRP1-900` |
+| LianTai `U-DBL` / `U-TWN` | `WHO1-850UP` |
+| LianTai `ST+K` / `2卧1厅` / `FAMILY 1` 且价格 1200 | `WHO3-1200` |
+
+价格示例：
+
+- 850 -> `WHO1-850UP`
+- 900 -> `GRP1-900`
+- 1000 -> `WHO2-1000`
+- 1200 -> `WHO3-1200`
+
+渠道和上下文优先于单纯价格。
+
+## `U-<number>`
+
+例如 `U-1200`：
+
+- 数字部分视为 settlement price / price marker。
+- 保留 `rate_code_raw = "U-1200"`。
+- 数字命中已知规则时输出命中。
+- 数字不可读或未覆盖时人工复核。
+- 绝不写入 confirmation/reservation/booking reference 字段。
+
+## 控房/配额默认
+
+示例：
+
+- `U-DBL` -> room `RM2`，settlement price 850。
+- `U-TWN` -> room `RM3`，settlement price 850。
+- `U-TRP` / `FAM` -> room `RM4`，settlement price 1275。
+
+仅当事件明确是 new Allotment / Control Block、房型唯一映射，且当前没有不同明确规则时使用。
+
+## 手工价格
+
+当需要人工维护 settlement price：
+
+```json
+{
+  "rate_code": null,
+  "settlement_price": null,
+  "manual_settlement_price_required": true,
+  "manual_price_reason_code": "",
+  "price_evidence": []
+}
+```
+
+手工价格仍要求目标、日期/room items、price text 和系统上下文安全。
+
+## 复合价格
+
+对于 `2000THB+500`、`1800+500`、`2000THB*2 +500*2`：
+
+- 只用可分离的 base room price 判断 Rate Code / settlement price。
+- additional component 交给 `52-fix-charge.md`。
+- 不得把组件相加后当单一房价。
+
+## 人工复核
+
+- channel/market 未知或冲突。
+- raw room type 无法唯一映射。
+- UP marker 与普通 rate path 冲突。
+- price marker 不可读。
+- price 未命中任何规则。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/52-fix-charge.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/52-fix-charge.md
new file mode 100644
index 0000000..2f0158e
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/52-fix-charge.md	
@@ -0,0 +1,67 @@
+# Fix Charge
+
+## 适用业务
+
+Fix Charge 是 New Booking 或 Update Booking 的附加收费维护事项。它不是独立业务事件。
+
+## 触发
+
+只有当前证据包含可分离的复合单价或附加费组件时才识别，例如：
+
+- `2000THB+500`
+- `1800THB+500`
+- `2000THB*2` 后接 `+附加500*2`
+
+不得仅因普通房型或普通价格存在就触发。
+
+## 解析
+
+- `+` 前组件用于 Rate Code / settlement price。
+- `+` 后组件是 additional fee candidate。
+- 不得把 `2000+500` 合成 `2500` 判断 Rate Code。
+- 不得自行计算 quantity 或 total amount。
+
+## 输出字段
+
+```json
+{
+  "fix_charge_required": true,
+  "fix_charge_items": [
+    {
+      "charge_type": "fixed_charge",
+      "amount": null,
+      "currency": null,
+      "pricing_mode": "unit",
+      "unit_basis": null,
+      "quantity": null,
+      "total_amount": null,
+      "raw_text": "",
+      "evidence_source": "",
+      "requires_followup_tool": true,
+      "followup_tool_name": "create_or_update_fix_charge / TBD"
+    }
+  ],
+  "additional_operations": [
+    {
+      "operation_type": "create_or_update_fix_charge",
+      "status": "pending_target_id"
+    }
+  ]
+}
+```
+
+## New Booking
+
+New Booking 的 Fix Charge 操作必须等 reservation/group/block 目标存在后再执行。
+
+## Update Booking
+
+Update Booking 场景必须确认 current action 是 add、update 还是 cancel Fix Charge。目标或动作不清时人工复核。
+
+## 人工复核
+
+- 无法分离 base room price 与 additional fee。
+- additional fee amount 不可读。
+- 多个价格组件无法归属。
+- Update action 未说明 add/update/cancel。
+- 目标订单不清或系统上下文阻塞。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/53-manual-rate-code.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/53-manual-rate-code.md
new file mode 100644
index 0000000..841f6c3
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/53-manual-rate-code.md	
@@ -0,0 +1,16 @@
+# Manual RateCode
+
+## 适用业务
+
+只有当前证据明确请求或暗示 manual Rate Code / settlement price maintenance，且不应作为 New Booking 或 Update Booking 内嵌字段表达时，才使用 `Manual RateCode`。
+
+## 安全规则
+
+- 不得猜 Rate Code。
+- 不得仅凭 PMS room code 反推 Rate Code。
+- 保留 raw price、channel、market、room text、breakfast/meal/restaurant、supplier 和当前证据。
+- 目标对象不清时输出人工复核。
+
+## 与 New/Update 的关系
+
+如果 manual price 是 New Booking 或 Update 的一部分，应保留在该事件的 `extracted_fields.rate_code_result`，除非当前请求只有 manual rate maintenance。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/54-stay-date-parsing.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/54-stay-date-parsing.md
new file mode 100644
index 0000000..a8dccce
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/54-stay-date-parsing.md	
@@ -0,0 +1,53 @@
+# Stay Date Parsing
+
+## 用途
+
+统一解析 QBD/LianTai 表格里的酒店入住、离店和晚数。适用于当前邮件附件、表格、OCR 或抽取证据中出现的酒店日期、行程日期和动作日期。
+
+## 字段
+
+保留以下日期证据：
+
+- `hotel_date_raw`：酒店列开头的住期范围，例如 `14-15`、`15-17`、`31-02`。
+- `tour_date_raw`：行程日期列原文，例如 `2026/05/11\n2026/05/16`。
+- `action_date_raw`：备注或状态中的动作日期，例如 `11/05 AMD`、`12/05 NEW BOOKING`。
+- `sheet_month_year`：workbook sheet 名中的月份年份，例如 `BOOKING 05-2026`。
+- `arrival_date`
+- `departure_date`
+- `nights`
+- `date_inference_basis`
+
+## 识别优先级
+
+1. 优先使用酒店列开头的酒店住期范围作为 `arrival_date` / `departure_date`。
+2. 酒店列内有完整日期时，使用该完整日期范围。
+3. 行程日期列用于补全年/月和校验，不得直接覆盖酒店住期。
+4. sheet 名用于补全年/月；当行程日期可读时，优先用行程日期选择能落在行程范围内的酒店住期。
+5. 备注中的动作日期只作为 `action_date_raw`，不是入住日期，也不是标黄行过滤条件。
+
+## 年月补全
+
+- `15-17` 在 `BOOKING 05-2026` 且行程日期落在 2026 年 5 月时，解析为 `2026-05-15` 到 `2026-05-17`。
+- `31-02` 这类跨月范围必须按跨月处理；如果行程日期或 sheet 名无法唯一确定跨到哪个月，按本节“业务复核”处理。
+- 当酒店日期范围缺年/月时，用行程日期补全；行程日期缺失时，用 sheet 名补全。
+- 如果补全后酒店住期不在行程日期范围内，保留 raw evidence 并按本节“业务复核”处理。
+
+## 晚数
+
+- `15-17` 表示入住 15 日、离店 17 日，`nights=2`。
+- `14-15` 表示入住 14 日、离店 15 日，`nights=1`。
+- `nights = departure_date - arrival_date`。
+- 表格里的 `5N6D`、`5N7D` 是行程晚数线索，不得覆盖酒店住期晚数。
+
+## 业务复核
+
+以下日期问题 reason code 使用 `stay_date_inference_unclear`：
+
+- 酒店日期范围不可读。
+- 酒店日期、行程日期和 sheet 名无法唯一补全年/月。
+- 酒店住期与行程日期明显冲突且无法解释。
+- 跨月、跨年或格式异常导致 arrival / departure 无法安全确定。
+
+当所属业务 `event_type` 和 subtype 已知时，保留原业务事件、全部 raw date evidence 和已确认日期字段，并附非空、完整的 `manual_review`；无法确定的日期字段为 `null`，`manual_review.missing_fields[]` 使用对应字段的 RFC 6901 JSON Pointer。不得仅因日期不安全改成 Fallback。
+
+只有当前行或材料不可读到连业务类型或 subtype 也无法确定时，才输出 `event_type=Need Manual Review` 的 Fallback 复核。
diff --git a/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/90-manual-review.md b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/90-manual-review.md
new file mode 100644
index 0000000..e29f5c1
--- /dev/null
+++ b/docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/90-manual-review.md	
@@ -0,0 +1,160 @@
+# 人工复核
+
+## 入口结果边界
+
+Gateway 必须先校验 `source_message.source_message_id`。该值为 `null`、空字符串或纯空白时，形成并校验 `00-output-contract.md` 定义的 `infrastructure_input_error`；不得读取正文、附件、OCR、历史或系统上下文，也不得调用 `booking-desk-event` skill。冻结该 error 后必须执行一次 mandatory submit，再原样返回；如果 Gateway 在 Main Agent 前短路，Gateway 必须执行同一最终提交钩子。
+
+source message identity 合法后，Main Agent 才完成支持范围分类：
+
+- 当前输入可理解，但没有匹配 active event 时，输出 `S10`。
+- 当前输入不足，无法判断是否匹配 active event 时，输出 `S99`。
+- `S10` 和 `S99` 都展示源邮件并由用户自行决定是否回复或进行其他处理。
+- `S10` 和 `S99` 不由 `booking-desk-event` skill 输出。
+
+Thank you、裸 FYI、acknowledgement、Noted、Received 等没有具体预订业务信息的文字，以及一般咨询和当前不支持的 Booking Confirmation Request，都不匹配 Trace。FYI 或单纯告知中包含与明确预订对象相关的具体补充信息时，匹配 `Trace`。正文只有 `see attached` 且附件无法取得、无法识别业务方向时走 `S99`。
+
+需要酒店批准的价格、退款、减免、账期、付款政策或合同条件询问不是 Trace。此类具有当前业务意义但没有任务卡承接的内容必须保留在 `unknowns`：同邮件存在支持事件时输出到 `unhandled_current_intents`，整封邮件没有支持事件时走 S10。意图清楚但不受支持不等于业务判断不安全，不得仅因此输出业务人工复核。
+
+## 两种业务人工复核
+
+### 已知业务卡型的人工复核
+
+只要业务 `event_type` 和 subtype 已经能够确定，就必须保留该业务事件，继续输出能够安全抽取的字段，并令该 event 的 `manual_review` 为完整 `business_event_review` 对象。不得仅因为房型、Rate Code、目标对象或某项证据存在歧义，就把事件改成 `Need Manual Review`。
+
+常见情形包括：
+
+- target object 不明确或不唯一，但业务卡型已确定；
+- current/history 边界不明确，但业务卡型已确定；
+- 已确定业务卡型，但其附件、OCR、表格或必要证据不可读；
+- required room type、Rate Code、settlement price 或其他必需字段无法唯一确定；
+- QBD/LianTai row、highlight 或 current-row evidence 缺失或歧义；
+- system context 显示 duplicate、pending/open task、active workflow、lock 或 conflict。
+- Parent Group 的 `group_code` 与 `block_code` 原始候选冲突，但 `New Booking + Allotment / Control Block` 或 `Cancel Allotment` 卡型已确定；此时两 key 均置空，保留候选证据并使用 `target_object_unclear`。
+- 完整 Parent split 已确认，但 child list、关系 index 或 parent-child 对应不完整；保留 linked `Cancel Allotment` 并使用 `parent_child_split_evidence_unclear`。
+
+例如，正文明确 `please update the booking as attached`，因此业务卡型已经确定为 Update；附件不可读时仍输出对应 Update event，把安全取得的订单号、客人名等保留下来，并附非空 `manual_review`。Adapter 据此派生 `manual_review + 原业务 task_type + 原业务 subtype`，而不是 Fallback。
+
+### 业务类型或 subtype 未知的 Fallback
+
+只有业务 `event_type` 或 subtype 本身无法确定时，才输出 `event_type=Need Manual Review`。Adapter 将其派生为：
+
+```text
+manual_review + Fallback + business_event_review
+```
+
+例如，同一段 current action 同时可能表示 New Booking 或 Update，且没有足够证据裁决，业务类型无法确定，此时才走 Fallback。
+
+不得为了满足 Main Agent 的 skill-call gate 而制造 `Need Manual Review`。如果 Main 给出的所有粗候选都被 skill 否定，skill 返回内部 `no_supported_event` disposition，由 Main 转成 S10。
+
+## 必要结构和字段类型
+
+业务级 `manual_review` 必须完整包含九个字段：
+
+```json
+{
+  "reason_code": "room_type_mapping_multiple_candidates",
+  "visible_reason": "房型原文可识别，但无法唯一映射到当前有效 PMS 房型代码。",
+  "review_record_type": "business_event_review",
+  "missing_fields": [
+    "/extracted_fields/room_items/0/pms_room_type_code"
+  ],
+  "blocking_points": [
+    "pms_room_type_code is required before Preflight"
+  ],
+  "conflicting_points": [],
+  "suggested_human_actions": [
+    "select_room_type_from_active_pms_catalog"
+  ],
+  "evidence_to_check": [
+    "current_body",
+    "current_attachments"
+  ],
+  "known_fields": {
+    "room_type_raw": "SUITE"
+  }
+}
+```
+
+固定规则：
+
+- 九个字段必须全部存在。
+- `reason_code` 和 `visible_reason` 必须是非空字符串。
+- `review_record_type` 固定为 `business_event_review`。
+- `missing_fields`、`blocking_points`、`conflicting_points`、`suggested_human_actions`、`evidence_to_check` 固定为字符串数组；无内容时使用空数组。
+- `known_fields` 固定为对象；没有已知值时使用空对象。
+- `missing_fields[]` 每一项必须是指向当前 event 的 RFC 6901 JSON Pointer，例如 `/extracted_fields/room_items/0/pms_room_type_code`。不得填写人类说明、点号路径或根邮件路径。
+- 不新增 `required_user_inputs`；前端业务卡字段注册表负责将 pointer 映射到可编辑控件。
+- pointer 无法映射到该业务卡的已知可编辑字段时，属于 adapter contract error，不能展示一个无法完成的复核卡。
+
+## 房型和其他必需字段
+
+房型原文可以识别但映射不唯一时：
+
+- 保留 `room_type_raw`；
+- `pms_room_type_code=null`；
+- 在 `manual_review.missing_fields` 中登记对应的 JSON Pointer；
+- 用户只能从信息系统提供的当前有效 PMS 房型目录中选择，不得由 Agent 猜测，也不得允许用户自由填写 PMS code。
+
+Rate Code、价格或其他业务必需字段遵循相同原则：保留安全抽取值，待用户确认的目标字段置为 `null` 并用 pointer 标记。`requires_downstream_hard_validation` 不能替代这些字段的人工确认；也不得写成“人工复核或 downstream validation 二选一”。
+
+一个 event 进入人工复核时，不得清空同邮件中的 sibling events。每个 event 独立派生路由：确定且完整的 sibling 仍为 normal task，需要确认的 sibling 保留其业务 task type/subtype 并进入 manual-review mode。
+
+## 同卡解阻状态
+
+Agent 输出只描述初始业务判断，保持不可变。信息系统在同一张业务卡上维护复核状态，初始为：
+
+```json
+{
+  "review_status": "pending",
+  "review_resolution": null
+}
+```
+
+用户确认后保存：
+
+```json
+{
+  "review_status": "resolved",
+  "review_resolution": {
+    "field_overrides": [
+      {
+        "field_pointer": "/extracted_fields/room_items/0/pms_room_type_code",
+        "value": "SU1"
+      }
+    ],
+    "resolved_by": "<user_id>",
+    "resolved_at": "<ISO-8601>"
+  }
+}
+```
+
+固定规则：
+
+- 原 Agent payload 和初始 `result_type=manual_review` 不得改写；当前页面模式由 `review_status` 控制。
+- `field_overrides[].field_pointer` 必须与待解决字段 pointer 对应，覆盖值和审计信息由信息系统持有。
+- 只有所有缺失字段完成、目录值校验通过、依赖字段重新校验通过后，才允许进入现有 Preflight。
+- 在 Preflight 完成前不得写 PMS。
+- 不创建第二张 linked normal task；解决后仍是同一张业务卡。
+- 业务字段可以按权限编辑；邮件原文、raw evidence、source ID 和审计字段只读。
+
+## 常见 Reason Code
+
+- `current_history_boundary_unclear`
+- `target_object_unclear`
+- `multiple_target_candidates`
+- `attachment_or_ocr_unreadable`
+- `event_type_conflict_unclear`
+- `subtype_unresolved`
+- `room_type_mapping_unconfirmed`
+- `room_type_mapping_multiple_candidates`
+- `rate_code_unconfirmed`
+- `rate_code_rule_not_covered`
+- `settlement_price_required`
+- `manual_price_unconfirmed`
+- `composite_unit_price_unconfirmed`
+- `fix_charge_unconfirmed`
+- `qbd_liantai_row_evidence_unreadable`
+- `parent_child_split_evidence_unclear`
+- `stay_date_inference_unclear`
+- `existing_order_record_found`
+- `pending_or_active_workflow_found`
diff --git a/docs/import/20260712/OPEN_AGENT_API_CURL_EXAMPLES.md b/docs/import/20260712/OPEN_AGENT_API_CURL_EXAMPLES.md
new file mode 100644
index 0000000..375bdf6
--- /dev/null
+++ b/docs/import/20260712/OPEN_AGENT_API_CURL_EXAMPLES.md
@@ -0,0 +1,306 @@
+# Agent Profile Open API Curl 请求示例
+
+本文档用于外部系统调用已发布的 Agent Profile。示例环境域名：
+
+```bash
+export DEERFLOW_BASE_URL="https://superagent.nianxx.cn"
+export DEERFLOW_OPEN_API_KEY="df_open_xxx"
+```
+
+`DEERFLOW_OPEN_API_KEY` 使用的是 Ops 中 `Agent Profile Open API` 创建外部应用时生成的 `df_open_...` token，不是“新建应用”的普通业务 token。
+
+## Profile 调用规则
+
+公开 API 请求里不直接传 `profile_id`。系统通过当前 `df_open_...` token 对应的外部应用策略来决定调用哪个 Profile：
+
+- 外部应用策略配置了 `profile_id`：固定调用该 Profile 的已发布版本。
+- 外部应用策略未配置 `profile_id`：调用组织默认 Profile 的已发布版本。
+- 目标 Profile 必须已发布，并且该 Profile 的 API exposure 已启用。
+
+## 执行过程 Trace 策略
+
+如果对接方需要看到 Agent 执行任务的过程数据，需要在 Ops 的 `Agent Profile Open API` 外部应用策略中显式开启 `trace_policy`：
+
+```json
+{
+  "profile_id": "profile_xxx",
+  "trace_policy": {
+    "enabled": true,
+    "expose_tool_inputs": "summary",
+    "expose_tool_outputs": "summary",
+    "expose_step_updates": "summary",
+    "expose_task_events": "summary"
+  }
+}
+```
+
+说明：
+
+- `include_trace=true` 只在 `trace_policy.enabled=true` 时可用。
+- 系统不会开放模型原始 chain-of-thought。对外只返回公开推理摘要，例如“正在分析问题并规划下一步操作”。
+- 工具入参、工具输出默认建议使用 `summary`，避免把敏感业务数据或内部上下文完整暴露给第三方。
+- 如果确实需要完整工具入参或输出，可以把对应项设为 `full`；如果完全不希望透出，可以设为 `redacted`。
+
+## 认证方式
+
+推荐使用 Bearer token：
+
+```bash
+Authorization: Bearer df_open_xxx
+```
+
+也可以使用请求头：
+
+```bash
+X-DeerFlow-Open-API-Key: df_open_xxx
+```
+
+## 1. 创建会话
+
+一个外部用户、一个微信会话、一个 CRM 会话，建议对应一个 Open Agent Session。这样 Agent 可以保留同一会话里的上下文。
+
+```bash
+curl -X POST "$DEERFLOW_BASE_URL/api/open/agent-sessions" \
+  -H "Authorization: Bearer $DEERFLOW_OPEN_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "external_subject_id": "wechat-user-001",
+    "idempotency_key": "wechat-session-001",
+    "metadata": {
+      "conversation_id": "wechat-conv-001",
+      "source": "wechat"
+    }
+  }'
+```
+
+示例响应：
+
+```json
+{
+  "session_id": "open_sess_xxx",
+  "status": "active",
+  "external_subject_id": "wechat-user-001",
+  "metadata": {
+    "conversation_id": "wechat-conv-001",
+    "source": "wechat"
+  },
+  "created_at": "2026-06-22T10:00:00Z",
+  "updated_at": "2026-06-22T10:00:00Z"
+}
+```
+
+## 2. 流式发送消息
+
+推荐优先使用流式接口。它会通过 SSE 返回运行过程和最终输出。
+
+```bash
+curl -N -X POST "$DEERFLOW_BASE_URL/api/open/agent-sessions/{session_id}/messages/stream" \
+  -H "Authorization: Bearer $DEERFLOW_OPEN_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "message": "你好，帮我介绍一下养马岛有什么玩的？",
+    "idempotency_key": "msg-001",
+    "metadata": {
+      "conversation_id": "wechat-conv-001",
+      "customer_id": "wechat-user-001"
+    }
+  }'
+```
+
+其中 `{session_id}` 替换为创建会话接口返回的 `session_id`。
+
+## 2.1 流式发送消息并返回公开 Trace
+
+对接方需要看到执行过程、工具调用、步骤更新时，使用 `include_trace=true`：
+
+```bash
+curl -N -X POST "$DEERFLOW_BASE_URL/api/open/agent-sessions/{session_id}/messages/stream?include_trace=true" \
+  -H "Authorization: Bearer $DEERFLOW_OPEN_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "message": "帮我查询刘亦菲最近动态，并标注信息来源。",
+    "idempotency_key": "msg-trace-001",
+    "metadata": {
+      "conversation_id": "wechat-conv-001",
+      "customer_id": "wechat-user-001"
+    }
+  }'
+```
+
+SSE 返回统一使用 `event: trace`，具体事件类型在 `data.event` 中：
+
+```text
+event: trace
+data: {"event":"run.started","run_id":"run_xxx","thread_id":"thread_xxx","external_app_id":"external-app-xxx","org_id":"org-1","ts":"2026-07-11T10:00:00Z"}
+
+event: trace
+data: {"event":"reasoning.summary","run_id":"run_xxx","text":"正在分析问题并规划下一步操作。","external_app_id":"external-app-xxx","org_id":"org-1","ts":"2026-07-11T10:00:01Z"}
+
+event: trace
+data: {"event":"tool.call.started","run_id":"run_xxx","message_id":"ai-1","tool_calls":[{"tool_call_id":"tool-1","name":"web_search","input":{"summary":"{\"query\":\"刘亦菲最近动态\"}"}}],"external_app_id":"external-app-xxx","org_id":"org-1","ts":"2026-07-11T10:00:02Z"}
+
+event: trace
+data: {"event":"tool.call.completed","run_id":"run_xxx","tool_call_id":"tool-1","name":"web_search","output":{"summary":"..."},"external_app_id":"external-app-xxx","org_id":"org-1","ts":"2026-07-11T10:00:03Z"}
+
+event: trace
+data: {"event":"message.delta","run_id":"run_xxx","message_id":"ai-final","text":"根据可检索到的信息...","external_app_id":"external-app-xxx","org_id":"org-1","ts":"2026-07-11T10:00:04Z"}
+
+event: trace
+data: {"event":"run.completed","run_id":"run_xxx","status":"success","external_app_id":"external-app-xxx","org_id":"org-1","ts":"2026-07-11T10:00:05Z"}
+```
+
+当前公开 Trace 事件包括：
+
+- `run.started`
+- `reasoning.summary`
+- `tool.call.started`
+- `tool.call.completed`
+- `message.delta`
+- `step.updated`
+- `task.updated`
+- `progress`
+- `run.failed`
+- `run.completed`
+
+## 2.2 订阅已有 Run 的公开 Trace
+
+如果对接方使用非流式发送消息拿到了 `run_id`，或者流式连接中断后需要重新订阅过程事件，可以使用：
+
+```bash
+curl -N "$DEERFLOW_BASE_URL/api/open/agent-sessions/{session_id}/runs/{run_id}/events" \
+  -H "Authorization: Bearer $DEERFLOW_OPEN_API_KEY"
+```
+
+说明：
+
+- 该接口需要外部应用具备 `agent_sessions:read` scope。
+- 仍然要求外部应用策略里 `trace_policy.enabled=true`。
+- 支持通过 `Last-Event-ID` 请求头按底层 stream bridge 的保留窗口重放事件。
+- 如果底层事件已经被清理，只能订阅后续仍保留或新产生的事件。
+
+## 3. 非流式发送消息
+
+非流式接口会立即返回 `run_id`，不直接返回最终答案。外部系统需要继续查询 run 状态，或通过 webhook 接收后续事件。
+
+```bash
+curl -X POST "$DEERFLOW_BASE_URL/api/open/agent-sessions/{session_id}/messages" \
+  -H "Authorization: Bearer $DEERFLOW_OPEN_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "message": "你好，帮我介绍一下养马岛有什么玩的？",
+    "idempotency_key": "msg-002",
+    "metadata": {
+      "conversation_id": "wechat-conv-001"
+    }
+  }'
+```
+
+示例响应：
+
+```json
+{
+  "session_id": "open_sess_xxx",
+  "run_id": "run_xxx",
+  "status": "running"
+}
+```
+
+## 4. 查询运行状态
+
+```bash
+curl "$DEERFLOW_BASE_URL/api/open/agent-sessions/{session_id}/runs/{run_id}" \
+  -H "Authorization: Bearer $DEERFLOW_OPEN_API_KEY"
+```
+
+示例响应：
+
+```json
+{
+  "session_id": "open_sess_xxx",
+  "run_id": "run_xxx",
+  "status": "running",
+  "metadata": {
+    "source": "open_agent_api",
+    "external_app_id": "external-app-xxx",
+    "resolved_profile_id": "profile_xxx",
+    "resolved_profile_version_id": "version_xxx",
+    "invocation_source": "open_agent_api"
+  }
+}
+```
+
+## 5. 取消运行
+
+```bash
+curl -X POST "$DEERFLOW_BASE_URL/api/open/agent-sessions/{session_id}/runs/{run_id}/cancel" \
+  -H "Authorization: Bearer $DEERFLOW_OPEN_API_KEY"
+```
+
+示例响应：
+
+```json
+{
+  "session_id": "open_sess_xxx",
+  "run_id": "run_xxx",
+  "status": "cancelling",
+  "metadata": {}
+}
+```
+
+## 6. 常见错误
+
+### 401 Unauthorized
+
+检查 `df_open_...` token 是否正确，或外部应用是否已被停用、移除。
+
+### 403 Forbidden
+
+当前外部应用缺少对应 scope。例如：
+
+- 创建会话需要 `agent_sessions:create`
+- 发送消息需要 `agent_sessions:message`
+- 查询 run 需要 `agent_sessions:read`
+- 取消 run 需要 `agent_sessions:cancel`
+
+### 404 Default profile has no published version
+
+外部应用没有绑定 `profile_id`，系统回退到组织默认 Profile，但默认 Profile 没有已发布版本。处理方式：
+
+- 在 Agent 工作台设置并发布组织默认 Profile。
+- 或在 Ops 的 `Agent Profile Open API` 外部应用策略里绑定明确的 `profile_id`。
+
+### 409 Active run
+
+同一个 session 当前已有运行中的任务。需要等上一个 run 结束，或先取消上一个 run。
+
+## 7. 最小完整流程
+
+```bash
+export DEERFLOW_BASE_URL="https://superagent.nianxx.cn"
+export DEERFLOW_OPEN_API_KEY="df_open_xxx"
+
+SESSION_ID=$(
+  curl -s -X POST "$DEERFLOW_BASE_URL/api/open/agent-sessions" \
+    -H "Authorization: Bearer $DEERFLOW_OPEN_API_KEY" \
+    -H "Content-Type: application/json" \
+    -d '{
+      "external_subject_id": "wechat-user-001",
+      "idempotency_key": "wechat-session-001",
+      "metadata": {
+        "conversation_id": "wechat-conv-001",
+        "source": "wechat"
+      }
+    }' | jq -r '.session_id'
+)
+
+curl -N -X POST "$DEERFLOW_BASE_URL/api/open/agent-sessions/$SESSION_ID/messages/stream" \
+  -H "Authorization: Bearer $DEERFLOW_OPEN_API_KEY" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "message": "你好，帮我介绍一下养马岛有什么玩的？",
+    "idempotency_key": "msg-001",
+    "metadata": {
+      "conversation_id": "wechat-conv-001"
+    }
+  }'
+```
diff --git a/docs/import/20260712/开发交付_P0_to_P0.1_增量修订说明_给开发Codex_2026-07-11.md b/docs/import/20260712/开发交付_P0_to_P0.1_增量修订说明_给开发Codex_2026-07-11.md
new file mode 100644
index 0000000..dcef689
--- /dev/null
+++ b/docs/import/20260712/开发交付_P0_to_P0.1_增量修订说明_给开发Codex_2026-07-11.md
@@ -0,0 +1,337 @@
+# P0 → P0.1 增量修订说明（给已基于旧 P0 包开发的团队与 Codex）
+
+> 日期：2026-07-11（Asia/Shanghai）
+> 旧开发基线：`开发交付_P0冻结基线_2026-07-11.zip`
+> 旧 ZIP SHA-256：`f08337fab17a1b016d0d6c0b6e667b4d8d9ffa9741bc2067916bae73dbe472c7`
+> 最新完整增量基线：`开发交付_P0.1_ParentGroup语义修订_2026-07-11.zip`
+> 新 ZIP SHA-256：`d2bbdfbfb786ce06fcf948f3665a654007154beb942ad054bc34017ff38e0eee`
+
+## 1. 可以直接交给开发 Codex 的任务指令
+
+```text
+你现在维护的是已经按照“开发交付_P0冻结基线_2026-07-11”开发中的代码。
+
+请在现有实现上做 P0 → P0.1 增量修改，不要推倒重做全部 P0，也不要实施 P1/P2。
+
+本次只有一个领域语义调整：
+Allotment / Control Block = Parent Group。
+
+完整 Parent split 必须从：
+N 个 Child New Booking + 1 个 Parent Cancel Booking
+
+改为：
+N 个 Child New Booking + 1 个 Parent Cancel Allotment。
+
+Parent 使用既有 task subtype：cancel_allotment_control_block。
+relationship_type=linked_parent_release_after_child_split 只用于关联和 Preflight，不再选择独立任务卡 subtype。
+
+请同步修改：
+1. 当前事件 producer/AI 输出消费校验；
+2. Adapter 路由；
+3. Parent key 归一；
+4. 同 Parent 去重；
+5. Legacy 只读兼容；
+6. 前端卡型映射；
+7. 测试和路由计数。
+
+删除当前合法路由中的两条旧三元组：
+- normal_task + Cancel Booking + linked_parent_release_after_child_split
+- manual_review + Cancel Booking + linked_parent_release_after_child_split
+
+Parent split 改为复用：
+- normal_task + Cancel Allotment + cancel_allotment_control_block
+- manual_review + Cancel Allotment + cancel_allotment_control_block
+
+总路由由 42 条改为 40 条。
+
+历史已经保存的旧 linked Parent Cancel Booking payload 不迁移、不改写；只在 reader/adapter 展示层归一为现有 Cancel Allotment 卡。
+当前 producer 如果继续产生该旧组合，必须 adapter_contract_error/fail closed。
+
+完成后按本文第 10 节逐项验收，并报告修改文件、测试结果和仍未覆盖的风险。
+```
+
+## 2. 本次修改边界
+
+本次只取代旧 P0 的以下两项：
+
+1. Parent split 父事件从独立 linked `Cancel Booking` 改为复用 `Cancel Allotment / cancel_allotment_control_block`。
+2. 因删除独立 Parent Cancel Booking subtype，Adapter 从 19 个业务 subtype、42 条总路由收敛为18个业务 subtype、40条总路由。
+
+以下旧 P0 规则继续有效，不得借本次增量重写：
+
+- S10/S99 两个独立根契约。
+- Main 只做粗分类、Skill 做最终业务判型。
+- type-known 人工复核保留原业务卡型。
+- 房型不唯一时同卡复核。
+- 同卡 `review_status/review_resolution` 解阻。
+- 缺少 `source_message_id` 返回基础设施输入错误。
+- 行级隔离和明确 derived events。
+- 部分 Allotment 维护不受支持。
+- `Note`、`Allotment Maintenance` 当前禁止新生成。
+
+P1/P2 仍未实施。本次不得依据 P1/P2 报告自行新增 Schema、路由或卡型。
+
+## 3. 业务语义修改
+
+### 3.1 统一业务对象
+
+```text
+Allotment / Control Block = Parent Group
+Allotment code = Parent Group code
+group_code = 业务主键
+block_code = Parent Group 场景的兼容别名
+```
+
+`Parent` 是拆分关系里的角色，不是另一种独立业务对象。
+
+### 3.2 完整 Parent split
+
+1 个 Parent 拆成 N 个 Child 时，固定输出：
+
+- 每个 Child：`New Booking + booking_object_type=Group Block`。
+- Parent：恰好一个 `Cancel Allotment + cancel_scope=entire_allotment_control_block`。
+- Parent 保留 `relationship_type=linked_parent_release_after_child_split`。
+- Parent 必须 `requires_downstream_hard_validation=true`。
+
+禁止把 Parent split 建模为：
+
+- `Update Booking / Amendment`
+- `Allotment Maintenance`
+- 当前 `Cancel Booking`
+- 一个同时包含 Child New 和 Parent Cancel 的复合单事件
+
+## 4. Agent 事件 before / after
+
+### 4.1 旧 Parent 事件：当前生产禁止
+
+```json
+{
+  "event_type": "Cancel Booking",
+  "event_role": "travel_agent_request",
+  "current_or_history": "current",
+  "source_event_index": "E_PARENT_CANCEL",
+  "case_keys": {
+    "group_code": "PARENT-2608",
+    "confirmation_number": null,
+    "reservation_number": null,
+    "block_code": null
+  },
+  "extracted_fields": {
+    "cancel_object_type": "group_block",
+    "parent_release_or_cancel_candidate": true,
+    "release_reason": "parent_to_child_allocation_split",
+    "parent_group_code": "PARENT-2608",
+    "child_group_codes": [
+      "CHILD-2608-A",
+      "CHILD-2608-B"
+    ],
+    "allocation_split_from_parent": true
+  },
+  "related_source_event_indices": [
+    "E_CHILD_1",
+    "E_CHILD_2"
+  ],
+  "related_event_type": "New Booking",
+  "relationship_type": "linked_parent_release_after_child_split",
+  "requires_downstream_hard_validation": true,
+  "manual_review": null
+}
+```
+
+### 4.2 新 Parent 事件：当前生产唯一合法形式
+
+```json
+{
+  "event_type": "Cancel Allotment",
+  "event_role": "travel_agent_request",
+  "current_or_history": "current",
+  "source_event_index": "E_PARENT_CANCEL",
+  "case_keys": {
+    "group_code": "PARENT-2608",
+    "confirmation_number": null,
+    "reservation_number": null,
+    "block_code": "PARENT-2608"
+  },
+  "extracted_fields": {
+    "cancel_scope": "entire_allotment_control_block",
+    "parent_release_or_cancel_candidate": true,
+    "release_reason": "parent_to_child_allocation_split",
+    "parent_group_code": "PARENT-2608",
+    "child_group_codes": [
+      "CHILD-2608-A",
+      "CHILD-2608-B"
+    ],
+    "allocation_split_from_parent": true
+  },
+  "related_source_event_indices": [
+    "E_CHILD_1",
+    "E_CHILD_2"
+  ],
+  "related_event_type": "New Booking",
+  "relationship_type": "linked_parent_release_after_child_split",
+  "requires_downstream_hard_validation": true,
+  "manual_review": null
+}
+```
+
+Child 事件保持 `New Booking + new_group_block`；Child 和普通 Group Block 仍然只填 `group_code`，`block_code=null`。
+
+## 5. Adapter 路由修改
+
+### 5.1 删除两条当前路由
+
+以下三元组从当前合法路由表删除，合法数量均为 0：
+
+| 旧三元组 | 当前处理 |
+| --- | --- |
+| `normal_task + Cancel Booking + linked_parent_release_after_child_split` | 当前 producer 命中时 `adapter_contract_error`；仅 legacy reader 可识别 |
+| `manual_review + Cancel Booking + linked_parent_release_after_child_split` | 当前 producer 命中时 `adapter_contract_error`；仅 legacy reader 可识别 |
+
+### 5.2 复用已有 Cancel Allotment 卡
+
+| Agent event | Adapter 三元组 |
+| --- | --- |
+| `Cancel Allotment` 且 `manual_review=null` | `normal_task + Cancel Allotment + cancel_allotment_control_block` |
+| `Cancel Allotment` 且 `manual_review!=null` | `manual_review + Cancel Allotment + cancel_allotment_control_block` |
+
+`relationship_type=linked_parent_release_after_child_split` 只决定关联校验和 Preflight，不得再决定 `task_subtype`。
+
+### 5.3 最新统计
+
+```text
+18 个业务 subtype × normal/manual = 36 条
+type/subtype 未知 Fallback = 1 条
+S10、S99、unhandled display = 3 条
+总计 = 40 条
+```
+
+因此所有写死的 `42`、`19`、旧 linked subtype 枚举、路由快照和断言都要同步更新。
+
+## 6. Parent key 归一与人工复核
+
+当前 producer 对所有 Parent Group 事件都执行：
+
+| 输入情况 | 输出 |
+| --- | --- |
+| 同时取得相同 `group_code`、`block_code` | 两边保留相同值 |
+| 只取得 `group_code` | 将其复制到 `block_code` |
+| 只取得 `block_code` | 将其复制到 `group_code` |
+| 两边都存在但归一后不同 | 两边都置为 `null`，保留原始候选证据，进入已知业务卡人工复核 |
+
+双 key 冲突时：
+
+- 事件仍是 `Cancel Allotment`，不能改成 Fallback。
+- Adapter 仍派生 `manual_review + Cancel Allotment + cancel_allotment_control_block`。
+- `manual_review.reason_code=target_object_unclear`。
+- `context_used.parent_identity_candidates[]` 保留两边原始候选和证据来源。
+- `manual_review` 仍必须满足旧 P0 已冻结的完整对象契约，不能只写一个 reason code。
+
+## 7. 去重和关系校验
+
+### 7.1 同 Parent 合并
+
+如果同一封当前邮件同时包含：
+
+- 完整 split 派生的 Parent release；以及
+- 字面明确的同一 Parent `Cancel Allotment`
+
+则只输出一个 Parent `Cancel Allotment`，合并两份证据。不能生成两张 Parent 取消卡。
+
+如果显式取消的是另一个 Parent，则分别输出两个 Parent `Cancel Allotment`。
+
+### 7.2 关系不变量
+
+- 一个 split cluster 恰好一个 Parent 事件。
+- `child_group_codes[]` 与 `related_source_event_indices[]` 数量相等、顺序一一对应。
+- 每个 index 都必须指向同根 `message_events[]` 中对应的 Child `New Booking + Group Block`。
+- Parent 的 `related_event_type` 固定为 `New Booking`。
+- Parent 的 `requires_downstream_hard_validation` 必须为 `true`。
+- 关系不完整时拒绝 Parent event，不猜测关系，不因 Parent 失败而删除合法 sibling Child。
+
+## 8. Legacy 兼容和数据迁移
+
+历史已经存储的旧组合：
+
+```text
+Cancel Booking
++ cancel_object_type=group_block
++ relationship_type=linked_parent_release_after_child_split
+```
+
+处理要求：
+
+1. 不批量迁移历史 JSON。
+2. 不改写或回写原历史 payload。
+3. Reader/adapter 只在展示层归一为已有 `Cancel Allotment + cancel_allotment_control_block` 卡。
+4. 审计查看原始数据时仍应看到原 payload。
+5. 当前 producer 输出同一旧组合时必须 fail closed，不能借 legacy 分支放行。
+
+需要把“历史读取”和“当前生产”作为两个明确代码路径或模式参数，禁止仅按 payload 形状自动放行。
+
+## 9. 对开发代码的建议修改位置
+
+实际文件名以开发仓库为准，但至少检查以下模块：
+
+| 模块 | 必须修改 |
+| --- | --- |
+| Event schema / validator | Parent split 当前只接受 `Cancel Allotment`；校验 `cancel_scope`、双 key、关系字段 |
+| Adapter router | 删除旧 linked Cancel Booking subtype 两条路由；复用 Cancel Allotment 路由 |
+| Route enum / registry | 删除当前合法 `linked_parent_release_after_child_split` task subtype |
+| Parent normalizer | 单边 key 补齐；双边冲突置空并触发 type-known review |
+| Deduplicator | 同 Parent 显式取消与 split-derived release 合并证据 |
+| Legacy reader | 旧 linked Cancel Booking 只读映射到 Cancel Allotment 卡，不回写 |
+| Preflight | 校验 Parent 双 key、Child code/index 顺序和硬校验标记 |
+| Frontend card registry | Parent split 使用既有 Cancel Allotment 卡，不再注册单独 Parent Cancel Booking 卡 |
+| Metrics / snapshots | 路由总数 42→40，业务 subtype 19→18 |
+| Fixtures / tests | 使用第 10 节场景替换旧 Parent Cancel Booking 期望 |
+
+如果部署 AI runtime，必须同时使用 P0.1 的：
+
+- `main_agent_prompt.md`，SHA-256：`de87c0959b1143bc3bd2cdcd43d4c6c36ae6bdd46706e1949d0ff314f4b8b436`
+- `booking-desk-event.skill`，SHA-256：`da14f305fd8c4d44ecd57a0a9409c4df462b314af2afac71b4e11584ff799ca5`
+
+不能继续部署旧 Main Prompt/Skill，再只修改 Adapter。
+
+## 10. 最低验收清单
+
+| # | 场景 | 必须结果 |
+| ---: | --- | --- |
+| 1 | 1 Parent → 2 Children | 2 个 Child New Group + 1 个 Parent Cancel Allotment |
+| 2 | 1 Parent → 7 Children | 7 个 Child New Group + 1 个 Parent Cancel Allotment |
+| 3 | split 同时明确取消相同 Parent | 仍只有 1 个 Parent 事件，证据合并 |
+| 4 | split 同时明确取消另一个 Parent | 两个 Parent 分别输出，不错误合并 |
+| 5 | Parent 只提供一边 key | 自动补齐，最终 `group_code=block_code` |
+| 6 | Parent 两边 key 冲突 | 两 key 为 null；同一 Cancel Allotment 卡进入 `target_object_unclear` 复核 |
+| 7 | Child 与 index 数量或顺序不一致 | 拒绝 Parent event，不猜关系；合法 sibling Child 保留 |
+| 8 | 普通 FIT/Group Block 取消 | 仍走普通 `Cancel Booking`，不得误改成 Cancel Allotment |
+| 9 | 独立整块 Parent/Allotment 取消 | 正常走 `Cancel Allotment + cancel_allotment_control_block` |
+| 10 | 历史旧 linked Parent Cancel Booking | 只读展示归一；原 payload 字节/字段不改 |
+| 11 | 当前 producer 输出旧 linked Parent Cancel Booking | `adapter_contract_error`，该 event 0 卡，siblings 继续 |
+| 12 | 路由注册表 | 40 个唯一三元组；18 个业务 subtype；旧 linked subtype 0 条 |
+| 13 | `Allotment Maintenance` | 当前仍为 0 条合法路由，不得因本次修改重新开放 |
+| 14 | PMS 写入 | Parent 始终经过 downstream hard validation 和 Preflight 后才允许继续 |
+
+## 11. 完成定义
+
+开发 Codex 只有在以下条件全部满足后才能报告完成：
+
+- 已列出实际修改的代码文件。
+- 已证明当前 producer 路径不再生成或接受旧 linked Parent Cancel Booking。
+- 已证明 legacy reader 仍可展示旧数据且没有修改原 payload。
+- 已证明 Parent 双 key、去重和关系顺序校验存在。
+- 已证明普通 Cancel Booking 没被误改。
+- 已证明路由数量为 40，旧 linked subtype 当前合法路由数为 0。
+- 已运行相关单元测试/集成测试并提供结果。
+- 未顺带实施或发明 P1/P2 规则。
+
+## 12. 权威优先级
+
+本增量说明用于指导旧 P0 实现升级。发生差异时按以下顺序处理：
+
+1. `ADR-002-allotment-parent-group-unification.md`
+2. P0.1 同版 `main_agent_prompt.md` 与 `booking-desk-event.skill`
+3. P0.1 `任务卡前端字段变更与路由说明_3.0_to_current.md` 和 Excel
+4. 本增量说明
+5. 旧 P0 冻结包
+
+旧 P0 包继续作为历史基线留存，但其中 Parent Cancel Booking/42 路由部分已经失效。
diff --git a/docs/project/README.md b/docs/project/README.md
index 7620bf3..56ec6f7 100644
--- a/docs/project/README.md
+++ b/docs/project/README.md
@@ -31,7 +31,7 @@
 | `requirements/M001-source-message-inbox-prd.md` | 当前有效 | M001 邮件来源入口 PRD，记录 AgentBus 邮件 JSON 入库、历史查询、原文读取和媒体引用边界。 |
 | `requirements/M002-order-task-workflow-v1.md` | 历史参考 | M002 订单任务主流程 V1，已由 V2 承接，保留用于理解早期流程。 |
 | `requirements/M002-order-task-workflow-v2.md` | 阶段记录 | M002 订单任务主流程 V2，记录当前已阶段实现的 AI 过渡层、S000/S999 兼容、订单任务流转、任务确认和 OPERA 模拟骨架。 |
-| `requirements/M002-order-task-workflow-v3.md` | 当前有效 | M002 订单任务主流程 V3，基于 2026-07-11 P0 冻结基线，记录 S10/S99、42 路由、方案 C、type-known manual review 同卡解阻和 fail-closed 边界。 |
+| `requirements/M002-order-task-workflow-v3.md` | 当前有效 | M002 订单任务主流程 V3，基于 2026-07-11 P0 冻结基线和 2026-07-12 P0.1 Parent Group 修订，记录 S10/S99、40 路由、方案 C、type-known manual review 同卡解阻和 fail-closed 边界。 |
 | `requirements/M002-superagent-task-result-api-contract.md` | 阶段记录 | M002 SuperAgent 任务结果入站接口契约阶段记录；对外总契约以 `integrations/superagent-api-contract.md` 为准。 |
 | `requirements/M002-ai-query-minimal-fields.md` | 阶段记录 | M002 SuperAgent 查询上下文接口 1、2 最小字段落地记录；对外总契约以 `integrations/superagent-api-contract.md` 为准。 |
 | `requirements/M002-backend-data-model-design.md` | 阶段记录 | M002 后端数据模型设计，记录 AI 过渡层、订单、任务、任务卡、审计和 OPERA 模拟结果表。 |
diff --git a/docs/project/frontend-backend/README.md b/docs/project/frontend-backend/README.md
index 75bc537..0bd60b4 100644
--- a/docs/project/frontend-backend/README.md
+++ b/docs/project/frontend-backend/README.md
@@ -19,7 +19,7 @@
 
 | 来源 | 当前用途 |
 | --- | --- |
-| `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更与路由说明_3.0_to_current.md` | 0711 P0 前端 / Adapter 路由说明。前端后续按 42 路由、S10/S99、type-known manual review 和 fail-closed 口径调整页面。 |
+| `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更与路由说明_3.0_to_current.md` | 0711 P0 前端 / Adapter 路由说明。Parent split / 42 路由部分已被 0712 P0.1 覆盖；前端后续按 40 路由、S10/S99、type-known manual review 和 fail-closed 口径调整页面。 |
 | `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更说明_3.0_to_当前版_2026-07-10.xlsx` | 最新前端任务卡展示 / 编辑白名单和三元组路由表。文件名保留 7 月 10 日，内部基线为 7 月 11 日。 |
 | `docs/import/20260708/任务卡前端展示字段表 3.0.xlsx` | 历史前端字段白名单，已被 0711 P0 冻结基线承接。 |
 | `docs/import/20260706/任务卡展示编辑矩阵.xlsx` | 后端完整规则来源。用于后端校验、最终确认写入、OPERA 映射、展示条件和任务卡完整约束。 |
@@ -39,7 +39,7 @@
 | SuperAgent MCP tools | `docs/project/integrations/superagent-mcp/README.md` | MCP 对外交付资料包，tools 字段语义应跟随 SuperAgent HTTP 对外总契约。 |
 | SuperAgent 任务结果入站接口 | `docs/project/requirements/M002-superagent-task-result-api-contract.md` | 阶段记录，用于理解 M002 接收 AI 结果的落地细节；如与总契约冲突，以总契约为准。 |
 | SuperAgent 查询上下文接口 1、2 | `docs/project/requirements/M002-ai-query-minimal-fields.md` | 阶段记录，用于理解接口 1、2 的最小字段实现；如与总契约冲突，以总契约为准。 |
-| 订单任务主流程 V3 | `docs/project/requirements/M002-order-task-workflow-v3.md` | 当前开发基线，基于 0711 P0 冻结基线，覆盖 S10/S99、42 路由、方案 C、type-known manual review 同卡解阻和 fail-closed。 |
+| 订单任务主流程 V3 | `docs/project/requirements/M002-order-task-workflow-v3.md` | 当前开发基线，基于 0711 P0 冻结基线和 0712 P0.1 Parent Group 修订，覆盖 S10/S99、40 路由、方案 C、type-known manual review 同卡解阻和 fail-closed。 |
 | 订单任务主流程 V2 | `docs/project/requirements/M002-order-task-workflow-v2.md` | 已实现阶段记录，保留用于理解当前代码中的 S000/S999、订单任务流转和 OPERA 模拟骨架。 |
 | 后端 checkpoint | `docs/project/requirements/M002-backend-checkpoint-plan.md` | 阶段记录，用于理解后端拆分和验收。 |
 | 前端可用接口与待补接口 | `docs/project/frontend-backend/frontend-to-backend-api-requests.md` | 前后端协作清单，已区分可用、后置和历史候选路径，不替代后端权威契约。 |
diff --git a/docs/project/frontend-backend/backend-to-frontend-notes.md b/docs/project/frontend-backend/backend-to-frontend-notes.md
index 6f586d4..d7242c9 100644
--- a/docs/project/frontend-backend/backend-to-frontend-notes.md
+++ b/docs/project/frontend-backend/backend-to-frontend-notes.md
@@ -18,7 +18,8 @@
 
 ## 3. 字段来源注意事项
 
-- `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更与路由说明_3.0_to_current.md` 是当前前端 / Adapter 路由说明，覆盖 42 路由、S10/S99、type-known manual review 和 fail-closed 口径。
+- `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更与路由说明_3.0_to_current.md` 是 0711 P0 前端 / Adapter 路由说明，覆盖 S10/S99、type-known manual review 和 fail-closed 口径；其中 Parent split / 42 路由口径已被 0712 P0.1 覆盖。
+- `docs/project/requirements/M002-v3-p0.1-parent-group-routing-update.md` 是当前 Parent Group / Allotment 路由修订说明：前端应按 40 路由口径处理 Parent split。
 - `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更说明_3.0_to_当前版_2026-07-10.xlsx` 是当前前端展示 / 编辑白名单和三元组路由表。
 - `docs/import/20260708/任务卡前端展示字段表 3.0.xlsx` 是历史前端展示 / 编辑白名单，已被 0711 P0 冻结基线承接。
 - `docs/import/20260706/任务卡展示编辑矩阵.xlsx` 是后端校验、最终确认写入、OPERA 映射和展示条件的完整规则来源。
@@ -145,6 +146,8 @@ POST /api/auth/logout
 - 任务列表里旧 `task_type=SOURCE_MESSAGE_ONLY`、`task_subtype=S000/S999` 或新 `task_subtype=S10/S99` 的记录只展示邮件来源和 SuperAgent 入口结果，不展示处理按钮。
 - 任务详情里 `source_message_only_result` 仅对 `SOURCE_MESSAGE_ONLY` 返回，包含 `entry_result_code`、`entry_result_meaning`、`entry_result_description`、`entry_result_source_message_id`、`result_type`、`route_code`、`agent_assessment`、`notification`、`manual_review` 和 `raw_answer`；普通业务任务该字段为空。
 - 任务列表、订单任务时间线和任务详情顶层已透出 `result_type`、`ai_task_type`、`route_code`、`system_process_category`。前端展示任务卡标题和标签时优先用这些稳定 code，不要只靠旧 `task_type` 判断。
+- P0.1 后，Parent split 父事件不再是独立 Parent Cancel Booking 卡；前端应展示为 `Cancel Allotment / cancel_allotment_control_block`。`linked_parent_release_after_child_split` 只作为关系字段或详情信息，不作为任务 subtype 筛选项。
+- P0.1 的“40 条路由”表示当前合法 route definition 数量；`route_code` 保持历史稳定且不连续重编号，因此 `R41_FALLBACK_BUSINESS_EVENT_REVIEW` 和 `R42_UNHANDLED_CURRENT_INTENT` 仍是合法展示 code。
 - `adapter_contract_errors[]` 和 `unhandled_intents[]` 只在任务详情返回，表示同一 SuperAgent 入站批次中没有生成业务任务的诊断块；前端只读展示并提供来源邮件入口，不显示保存、确认、执行或重试按钮。
 
 ### 5.5.1 Type-known manual review 同卡复核解阻接入注意
@@ -308,7 +311,7 @@ run_label: 可选调试标签
 ## 7. 需要持续提醒的后置事项
 
 - 普通任务切换订单接口继续后置。
-- M002 V3 的结构化 `S10/S99` 入站、42 路由枚举 / 稳定配置、`UNHANDLED_CURRENT_INTENT`、`adapter_contract_error` transition 最小落库、任务列表 / 订单时间线 / 任务详情 V3 路由字段和只读诊断块透出、type-known manual review 同卡解阻第一版、typed infrastructure error 和 P0 fixtures 回归基线均已完成。
+- M002 V3 的结构化 `S10/S99` 入站、40 条 P0.1 路由枚举 / 稳定配置、`UNHANDLED_CURRENT_INTENT`、`adapter_contract_error` transition 最小落库、任务列表 / 订单时间线 / 任务详情 V3 路由字段和只读诊断块透出、type-known manual review 同卡解阻第一版、typed infrastructure error、P0 fixtures 回归基线和 Parent Group / Cancel Allotment 路由修订均已完成。
 - 系统管理后台 V1 已完成；后续若要做用户搜索更多筛选、批量操作、密码策略增强、MFA、登录设备管理，应单独开需求。
 - 现有 Reservation / SourceMessage 业务接口的强制登录、强制权限和业务审计 actor 全量迁移仍后置。
 - 真实 OPERA / OHIP 接入继续后置。
diff --git a/docs/project/frontend-backend/frontend-to-backend-api-requests.md b/docs/project/frontend-backend/frontend-to-backend-api-requests.md
index 6097909..5e6292c 100644
--- a/docs/project/frontend-backend/frontend-to-backend-api-requests.md
+++ b/docs/project/frontend-backend/frontend-to-backend-api-requests.md
@@ -114,12 +114,12 @@ GET /api/reservation/tasks
       "temporary_order_no": "TMP-20260708-001",
       "task_type": "UPDATE_BOOKING",
       "result_type": "normal_task",
-      "ai_task_type": "Update Booking",
-      "task_subtype": "RATE_CHANGE",
-      "route_code": "R07_UPDATE_RATE_CODE_NORMAL",
+      "ai_task_type": "Payment Evidence",
+      "task_subtype": "payment_evidence",
+      "route_code": "R10_PAYMENT_EVIDENCE_NORMAL",
       "system_process_category": "BUSINESS_TASK",
       "task_status": "PENDING_CONFIRM",
-      "card_name": "Rate Change",
+      "card_name": "Payment Evidence",
       "queue_sequence": 2,
       "queue_participation": true,
       "can_process": false,
@@ -325,7 +325,9 @@ POST /api/system/reservation/demo-data
 | --- | --- | --- | --- |
 | 结构化 `S10/S99` 入站 | 任务列表、任务详情、Debug EML 结果展示 | 已完成第一版 | 后端接收 `result_type=source_message_review_notification + route_code=S10/S99`，创建只读源邮件通知卡；任务列表可见，订单列表不可见；返回 `route_code`、入口说明、`agent_assessment`、`notification` 和 S99 的入口 `manual_review`。 |
 | 旧 `S000/S999` 兼容映射 | 任务列表、任务详情 | 已完成第一版 | 旧数据继续可见；前端可按 `S000→S10`、`S999→S99` 展示统一文案。 |
-| 42 路由元数据 | 任务列表筛选、订单任务时间线、任务详情标题、字段展示 | 已完成第一版 | 后端保存并返回 AI 原始 `result_type/ai_task_type/task_subtype`、`route_code` 和系统处理分类；前端不要只依赖系统主任务类型判断卡片。 |
+| 40 条 P0.1 路由元数据 | 任务列表筛选、订单任务时间线、任务详情标题、字段展示 | 已完成第一版 | 后端保存并返回 AI 原始 `result_type/ai_task_type/task_subtype`、`route_code` 和系统处理分类；前端不要只依赖系统主任务类型判断卡片。 |
+| P0.1 稳定 route_code | 任务列表筛选、订单任务时间线、任务详情标题 | 已完成第一版 | `route_code` 保持历史稳定，不因路由总数变 40 而连续重编号；前端仍可能看到 `R41_FALLBACK_BUSINESS_EVENT_REVIEW` 和 `R42_UNHANDLED_CURRENT_INTENT`。 |
+| Parent split 父事件卡型 | 任务列表、订单任务时间线、任务详情标题 | 已完成第一版 | 0712 P0.1 后，Parent split 父事件展示为 `Cancel Allotment / cancel_allotment_control_block`；`linked_parent_release_after_child_split` 仅作为关系字段，不作为任务 subtype 筛选项。 |
 | `unhandled_current_intents[]` 展示块 | 任务详情 | 已完成第一版 | 后端保存并在任务详情 `unhandled_intents[]` 返回未覆盖业务意图，只用于展示和源邮件查看，不自动建业务任务卡。 |
 | `adapter_contract_error` | 任务详情、错误提示 | 已完成第一版 | 命中 P1/P2 未闭合或路由冲突时，任务详情 `adapter_contract_errors[]` 返回稳定错误 code 和原始片段，不转成 Fallback。 |
 | type-known manual review 同卡解阻 | 任务详情复核 | 已完成第一版 | `manual_review` 不再全部等同 Fallback；已知业务卡型返回原业务卡信息、`review_status`、`review_resolution` 和可编辑 pointer 字段，解阻后进入 `READY`。 |
diff --git a/docs/project/go-live-notes.md b/docs/project/go-live-notes.md
index 14668a2..368238d 100644
--- a/docs/project/go-live-notes.md
+++ b/docs/project/go-live-notes.md
@@ -140,6 +140,7 @@
 - 任务结果通知接口 JSON body 里的 `source_message_id` 是外部来源消息 ID，对应 AgentBus `source.external_message_id`；SuperAgent 默认不传 `hotel_id`，后端用系统酒店 `hotel_id + provider + channel + external_message_id` 反查内部 SourceMessage Inbox。
 - 当前代码的任务结果通知接口也支持 `text/plain` 的 `S000,source_message_id` 和 `S999,source_message_id`。这类请求不在 body 里带 `hotel_id`，后端同样使用平台酒店表唯一 `ACTIVE` 酒店查询 SourceMessage Inbox。
 - M002 V3 已支持结构化 `S10/S99`、V3 业务根基础解析、`UNHANDLED_CURRENT_INTENT` 和 `adapter_contract_error` 最小落库：上线前必须单独验证新 JSON 入站、旧 S000/S999 兼容、隐藏技术订单、任务列表可见、订单列表不可见和只读限制。
+- 0712 P0.1 后，SuperAgent runtime 必须同步使用 P0.1 Main Agent prompt / booking-desk-event skill。完整 Parent split 的父事件必须提交为 `Cancel Allotment + cancel_allotment_control_block`；当前新入站 `Cancel Booking + linked_parent_release_after_child_split` 会被后端按 `adapter_contract_error` 处理，不创建业务任务。旧历史 payload 只读兼容，不做批量迁移。
 - `application/json` 和 `text/plain` 都必须使用原始请求体计算 SHA-256 并参与 HMAC 签名；SuperAgent 侧不能签名格式化后的 JSON 或二次拼接字符串。
 - 旧 S000/S999 会创建 `SOURCE_MESSAGE_ONLY` 只读特殊任务和隐藏技术订单，任务列表可见，订单列表不可见，不允许编辑、确认、转换订单或执行 OPERA。V3 S10/S99 应保持同等只读和不可执行边界。
 - SuperAgent 查询上下文接口中的 `source_message_id`、`source_event_index` 第一版仅兼容接收，不参与查询和校验；不要依赖它们限制查询范围。
diff --git a/docs/project/integrations/superagent-api-contract.md b/docs/project/integrations/superagent-api-contract.md
index 64cc51d..38fe2fb 100644
--- a/docs/project/integrations/superagent-api-contract.md
+++ b/docs/project/integrations/superagent-api-contract.md
@@ -107,23 +107,25 @@ SuperAgent 不应知道或依赖内部 SourceMessage Inbox ID。任务结果通
 
 ## 3.1 M002 V3 迁移提醒
 
-2026-07-11 起，项目需求基线已确认采用 `docs/project/requirements/M002-order-task-workflow-v3.md`：
+2026-07-11 起，项目需求基线已确认采用 `docs/project/requirements/M002-order-task-workflow-v3.md`；2026-07-12 起，Parent Group / Allotment 路由采用 `docs/project/requirements/M002-v3-p0.1-parent-group-routing-update.md`：
 
 - 新入口结果将从旧文本 `S000/S999` 迁移为结构化 `S10/S99`。
 - 新业务输出将从旧 `ai_task_results[]` 迁移为 `source_message + message_events[] + case_candidates[] + extraction_warnings[] + unhandled_current_intents[]`。
 - 后端会完整保存 AI 三元组、`route_code` 和系统处理分类；`S10/S99` 仍以只读源邮件通知卡展示，任务列表可见，订单列表不可见。
 - 旧 `S000/S999` 数据继续兼容展示，语义上分别映射到 `S10/S99`。
+- 完整 Parent split 的父事件必须使用 `Cancel Allotment + cancel_allotment_control_block`；`relationship_type=linked_parent_release_after_child_split` 只用于关联和 Preflight，不再作为独立任务 subtype。
+- 当前新入站不接受 `Cancel Booking + linked_parent_release_after_child_split` 作为合法业务任务；该组合仅允许历史数据只读兼容。
 
 当前后端已完成 M002 V3 CP1-CP6：
 
-- 已建立 42 条 P0 路由枚举 / 稳定配置。
+- 已建立 40 条 P0.1 路由枚举 / 稳定配置；`route_code` 保持历史稳定，不按总数连续重编号，`R41/R42` 仍可能出现在响应和历史 transition 中。
 - 已支持结构化 `S10/S99` 入站，创建只读 `SOURCE_MESSAGE_ONLY` 任务。
 - 已支持 V3 业务根 `source_message + message_events[]` 的基础解析；可派生到现有任务模型的 event 会创建业务任务，无法派生、显式契约错误或基础 manual_review / parent split 结构不完整的 event 只落 `adapter_contract_error` transition，不创建业务任务。
 - 已支持 `unhandled_current_intents[]` 最小落库：只写 `UNHANDLED_CURRENT_INTENT` transition，不创建业务任务，也不按 adapter 契约错误返回。
 - 已在 `workflow_reservation_ai_transition` 保存 `route_code`、`system_process_category`、`adapter_error_code` 和 `adapter_error_message`。
 - 已支持 type-known manual review 同卡解阻、当前订单归属确认、P0 fixtures 回归测试和 V3 typed `infrastructure_input_error` 响应。
 
-尚未完成：真实 OPERA / OHIP、普通任务切换订单、字段矩阵从当前扁平结构整体迁移到 0711 P0 新结构。
+尚未完成：真实 OPERA / OHIP、普通任务切换订单、字段矩阵从当前扁平结构整体迁移到 0711 P0 新结构、历史旧 Parent Cancel Booking payload 批量迁移。
 
 ## 4. 接口 1：查询订单上下文
 
@@ -559,9 +561,13 @@ V3 字段说明：
 
 当前已支持的 V3 行为：
 
-- 42 条 P0 路由进入后端枚举 / 稳定配置。
+- 40 条 P0.1 路由进入后端枚举 / 稳定配置。
+- `route_code` 是稳定代码，不因路由总数从 42 调整为 40 而重编号；联调方不要按数字连续性判断合法性。
 - 结构化 `S10/S99` 创建只读 `SOURCE_MESSAGE_ONLY` 任务，任务列表可见，订单列表不可见。
 - 业务 event 能派生到稳定路由时，复用现有订单 / 任务 / 任务卡创建链路。
+- 完整 Parent split 父事件必须提交为 `event_type=Cancel Allotment`、`extracted_fields.cancel_scope=entire_allotment_control_block`、`task_subtype=cancel_allotment_control_block`，并保留 `relationship_type=linked_parent_release_after_child_split` 作为关系字段。
+- 当前新入站若提交 `event_type=Cancel Booking` 且 `relationship_type=linked_parent_release_after_child_split`，写入 `adapter_contract_error` transition，不创建业务任务；旧 V2 兼容 `ai_task_results[]` 中的同等三元组按请求级 `ADAPTER_CONTRACT_ERROR` 拒绝。
+- 同一个 Parent split cluster 重复提交 Parent 候选时，后续重复 Parent 写入 `adapter_contract_error` transition，不创建第二张 Parent 业务任务。
 - event 判别字段不完整、显式携带 `contract_errors`、根 `missing_fields`、不完整 `manual_review` 或不完整 parent split 候选时，写入 `adapter_contract_error` transition，不创建订单和任务；同一邮件其他 sibling event 继续处理。
 - `unhandled_current_intents[]` 写入 `UNHANDLED_CURRENT_INTENT` transition，不返回 `adapter_error_code`。
 - V3 `message_events[].relevant_message_excerpt` 入站后会归一化到任务卡 AI payload 根路径，供旧字段矩阵读取证据字段；SuperAgent 仍只需要按 V3 event 契约提供该字段。
diff --git a/docs/project/requirements/M002-backend-checkpoint-plan.md b/docs/project/requirements/M002-backend-checkpoint-plan.md
index 01f1b86..b520c48 100644
--- a/docs/project/requirements/M002-backend-checkpoint-plan.md
+++ b/docs/project/requirements/M002-backend-checkpoint-plan.md
@@ -4,8 +4,8 @@
 
 | 项目 | 内容 |
 | --- | --- |
-| 文档版本 | 0.3 |
-| 日期 | 2026-07-11 |
+| 文档版本 | 0.4 |
+| 日期 | 2026-07-12 |
 | 状态 | V2 后端 checkpoint 阶段记录；V3 新开发和当前实现状态以 `M002-order-task-workflow-v3.md` 为准 |
 | 适用范围 | M002 后端实现拆分、交付物和验收标准 |
 | 主要读者 | 后端、测试、产品、后续协作 agent |
@@ -14,7 +14,7 @@
 
 本文把 `M002-order-task-workflow-v2.md`、`M002-superagent-task-result-api-contract.md` 和 `M002-backend-data-model-design.md` 拆成可执行后端 checkpoint，用于理解当前已阶段实现的 M002 V2 能力。
 
-2026-07-11 后，M002 后续新开发必须先读 `M002-order-task-workflow-v3.md`。V3 已确认采用 0711 P0 冻结基线，新增结构化 `S10/S99`、42 路由、方案 C、type-known manual review 同卡解阻、复核场景订单归属确认和 P1/P2 fail-closed 边界。本文下方 V2 checkpoint 不再覆盖这些新需求。
+2026-07-11 后，M002 后续新开发必须先读 `M002-order-task-workflow-v3.md`。V3 已确认采用 0711 P0 冻结基线，新增结构化 `S10/S99`、方案 C、type-known manual review 同卡解阻、复核场景订单归属确认和 P1/P2 fail-closed 边界。2026-07-12 后，Parent Group / Allotment 语义按 P0.1 修订，路由总数从 42 调整为 40，完整 Parent split 父事件从旧 `Cancel Booking + linked_parent_release_after_child_split` 改为 `Cancel Allotment + cancel_allotment_control_block`。本文下方 V2 checkpoint 不再覆盖这些新需求。
 
 每个 checkpoint 都应先读项目规范，再按本项目包结构和注释要求实现。不要一次性把完整后端做完，也不要在不确定字段或目录归属时先写再重构。
 
@@ -30,11 +30,13 @@
 - `docs/import/reusable/alibaba-java-coding-guidelines-summary.md`
 - `docs/project/requirements/M002-order-task-workflow-v2.md`
 - `docs/project/requirements/M002-order-task-workflow-v3.md`
+- `docs/project/requirements/M002-v3-p0.1-parent-group-routing-update.md`
 - `docs/project/requirements/M002-superagent-task-result-api-contract.md`
 - `docs/project/requirements/M002-backend-data-model-design.md`
 - `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/README_交付说明.md`
 - `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更与路由说明_3.0_to_current.md`
 - `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更说明_3.0_to_当前版_2026-07-10.xlsx`
+- `docs/import/20260712/开发交付_P0_to_P0.1_增量修订说明_给开发Codex_2026-07-11.md`
 - `docs/import/20260706/开发AI先读_工作顺序.md`
 - `docs/import/20260706/AI输出参数并集字典.xlsx`
 - `docs/import/20260706/任务卡展示编辑矩阵.xlsx`
diff --git a/docs/project/requirements/M002-backend-data-model-design.md b/docs/project/requirements/M002-backend-data-model-design.md
index e7df3f8..34f2f4c 100644
--- a/docs/project/requirements/M002-backend-data-model-design.md
+++ b/docs/project/requirements/M002-backend-data-model-design.md
@@ -16,7 +16,7 @@
 
 本文不是完整最终模型。当前后端已经按本模型落地第一阶段 Flyway migration、Entity、Mapper、Repository、Service 和测试；后续真实 OPERA、前端页面和 SuperAgent 查询上下文接口仍需继续补充。
 
-2026-07-11 后，M002 V3 已确认采用 0711 P0 冻结基线。后续数据模型扩展必须支持结构化 `S10/S99`、`message_events[]`、42 路由、方案 C 中的 AI 原始三元组 / 系统处理分类分离、type-known manual review 同卡解阻和 `adapter_contract_error`，不能只沿用本文的 `ai_task_results[]` 阶段模型。
+2026-07-11 后，M002 V3 已确认采用 0711 P0 冻结基线；2026-07-12 后，Parent Group / Allotment 语义按 P0.1 修订。后续数据模型扩展必须支持结构化 `S10/S99`、`message_events[]`、40 路由、方案 C 中的 AI 原始三元组 / 系统处理分类分离、type-known manual review 同卡解阻和 `adapter_contract_error`，不能只沿用本文的 `ai_task_results[]` 阶段模型。
 
 ## 2. 设计原则
 
diff --git a/docs/project/requirements/M002-order-task-workflow-v3.md b/docs/project/requirements/M002-order-task-workflow-v3.md
index dc5cbc7..2f9907a 100644
--- a/docs/project/requirements/M002-order-task-workflow-v3.md
+++ b/docs/project/requirements/M002-order-task-workflow-v3.md
@@ -4,9 +4,9 @@
 
 | 项目 | 内容 |
 | --- | --- |
-| 文档版本 | 0.1 |
-| 日期 | 2026-07-11 |
-| 状态 | 0711 P0 基线确认版；后端已完成 M002 V3 CP1-CP6 入站、路由持久化、列表 / 详情展示、同卡复核解阻和 P0 fixtures 回归第一版 |
+| 文档版本 | 0.2 |
+| 日期 | 2026-07-12 |
+| 状态 | 0712 P0.1 增量确认版；后端已完成 M002 V3 CP1-CP6 第一版，Parent Group / Cancel Allotment 路由按 P0.1 修订 |
 | 适用范围 | SourceMessage 之后的 SuperAgent 输出适配、任务路由、只读通知卡、人工复核同卡解阻、前后端协作边界 |
 | 主要读者 | 产品、后端、前端、测试、SuperAgent 对接方、后续协作 agent |
 
@@ -14,7 +14,7 @@
 
 本文是 `M002-order-task-workflow-v2.md` 的第三版修正。V2 记录了当前后端阶段实现：`ai_task_results[]`、`S000/S999` 文本结果、订单任务基础流转、任务草稿确认、OPERA 模拟骨架、SuperAgent 查询上下文接口和前端 P0 查询接口。
 
-V3 记录 2026-07-11 导入的 SuperAgent P0 冻结基线，以及本项目已经确认的产品决策。后续 M002 新开发应优先按本文执行；当前代码中已经存在的 V2 行为，需要按 checkpoint 逐步兼容迁移，不能在未实现前对外宣称已经完成。
+V3 记录 2026-07-11 导入的 SuperAgent P0 冻结基线、2026-07-12 导入的 P0.1 Parent Group 语义修订，以及本项目已经确认的产品决策。后续 M002 新开发应优先按本文和 `M002-v3-p0.1-parent-group-routing-update.md` 执行；当前代码中已经存在的 V2 行为，需要按 checkpoint 逐步兼容迁移，不能在未实现前对外宣称已经完成。
 
 本文不替代 `docs/project/integrations/superagent-api-contract.md` 的线上联调接口说明。若要给 SuperAgent 联调方使用，必须在对应接口实现完成后同步更新该对外契约。
 
@@ -25,23 +25,27 @@ V3 以以下资料和决策为输入：
 | 资料 | 用途 |
 | --- | --- |
 | `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/README_交付说明.md` | 0711 P0 交付边界、可先实现范围、P1/P2 暂缓范围 |
-| `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更与路由说明_3.0_to_current.md` | Adapter / Frontend 的 42 路由、人工复核、Parent split、fail-closed 规则 |
+| `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更与路由说明_3.0_to_current.md` | Adapter / Frontend 的 P0 路由、人工复核、fail-closed 规则；其中 Parent split / 42 路由部分已被 0712 P0.1 覆盖 |
 | `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更说明_3.0_to_当前版_2026-07-10.xlsx` | P0 字段、三元组路由、旧枚举迁移、非法组合和验收用例 |
 | `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/02_AI_Runtime/main_agent_prompt.md` | 当前 Main Agent 运行提示词 |
 | `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/02_AI_Runtime/booking-desk-event.skill` | 当前 Skill 包 |
 | `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/02_AI_Runtime/核心契约_展开阅读/*.md` | 输出契约、事件路由、内容完整性、Main 到 Skill 输入、人工复核规则 |
 | `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/03_P0_Acceptance/` | P0 fixtures 和轻量 validator |
 | `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/04_Known_Issues_非契约/` | P1/P2 未闭合范围，只用于识别暂缓和 fail-closed，不作为生产规则源 |
+| `docs/import/20260712/开发交付_P0_to_P0.1_增量修订说明_给开发Codex_2026-07-11.md` | Parent Group / Allotment 语义修订、40 路由、当前 producer 禁止旧 Parent Cancel Booking |
+| `docs/import/20260712/Agent 0711 1743/**` | P0.1 Main Agent prompt、booking-desk-event skill 和 references |
+| `docs/project/requirements/M002-v3-p0.1-parent-group-routing-update.md` | 本项目对 P0.1 增量的落地说明和验收清单 |
 
 本项目确认的产品决策：
 
-- M002 V3 正式采用 0711 P0 基线。
+- M002 V3 正式采用 0711 P0 基线，并从 2026-07-12 起采用 P0.1 Parent Group / Allotment 增量修订。
 - 旧数据 `S000/S999` 继续在任务列表可见；新数据迁移为 `S10/S99`。
 - `S10/S99` 继续复用隐藏技术订单 + 任务列表只读卡，不进入订单列表和订单执行队列。
 - 缺少 `source_message.source_message_id` 时，后端已按 `HTTP 400 + infrastructure_input_error + retryable=true` 的技术错误响应返回，不创建 SourceMessage、AI transition、订单、任务或通知卡。
 - 内部任务模型采用“方案 C”：完整保存 AI 三元组，系统处理分类和前端展示分类单独维护。
 - type-known manual review 使用同一张业务卡复核解阻，不生成第二张 normal task。
-- 第一版保存全部 42 条路由 / 枚举，先支持保存和列表展示。
+- 第一版保存全部 40 条 P0.1 路由 / 枚举，先支持保存和列表展示。
+- `Allotment / Control Block = Parent Group`；完整 Parent split 的父事件必须是 `Cancel Allotment + cancel_allotment_control_block`，不是普通 `Cancel Booking`。
 - P1/P2 未闭合范围命中时 fail closed，不由本系统发明字段或业务规则。
 - 普通任务切换订单继续后置；P0 仅支持“复核场景下确认订单归属”。
 
@@ -51,7 +55,7 @@ V3 以以下资料和决策为输入：
 | --- | --- | --- |
 | SuperAgent 业务输出 | 顶层 `source_message_id + ai_task_results[]` | 顶层 `source_message + message_events[] + case_candidates[] + extraction_warnings[] + unhandled_current_intents[]` |
 | 信息类 / 入口问题 | `text/plain`：`S000,source_message_id` / `S999,source_message_id` | 结构化 JSON：`S10` / `S99`，`result_type=source_message_review_notification` |
-| 任务路由 | 以 `result_type + task_type + task_subtype` 粗映射系统主任务 | 按每个 `message_events[i]` 派生 42 条 P0 三元组 |
+| 任务路由 | 以 `result_type + task_type + task_subtype` 粗映射系统主任务 | 按每个 `message_events[i]` 派生 40 条 P0.1 三元组 |
 | 人工复核 | Fallback / manual_review 可转换为业务任务 | type-known review 保留原业务卡；只有类型或 subtype 未知才走 Fallback |
 | 复核解阻 | 偏“转换”思路 | 同卡 `review_status + review_resolution.field_overrides[]` 解阻 |
 | Message Notification | 历史信息提醒任务 | 新入口统一使用 `S10/S99` 只读源邮件通知卡；历史数据兼容展示 |
@@ -159,21 +163,35 @@ V3 接收端按根结构分流：
 
 ## 7. Adapter 路由模型
 
-### 7.1 42 条 P0 路由
+### 7.1 40 条 P0.1 路由
 
 V3 第一版必须保存并支持以下路由类别：
 
-- 19 个业务 subtype，每个 subtype 都有 normal 和 type-known manual review 两条路由，共 38 条。
+- 18 个业务 subtype，每个 subtype 都有 normal 和 type-known manual review 两条路由，共 36 条。
 - `S10` 和 `S99` 两条源邮件通知路由。
 - 类型或 subtype 未知的 Fallback 路由：`manual_review + Fallback + business_event_review`。
 - `unhandled_current_intent + Unhandled Current Intent + requires_business_approval_or_unsupported_task_card` 展示路由。
 
 第一版后端要求：
 
-- 42 条路由全部进入枚举或稳定配置，不能只硬编码已实现的少数几条。
+- 40 条路由全部进入枚举或稳定配置，不能只硬编码已实现的少数几条。
+- `route_code` 是历史稳定码，不因 P0.1 总数从 42 调整为 40 而重编号；`R41_FALLBACK_BUSINESS_EVENT_REVIEW` 和 `R42_UNHANDLED_CURRENT_INTENT` 继续保留。
 - 每条入站 event 都按自己的 `message_events[i]` 独立派生，不能在邮件根只生成一个任务。
 - 同一封邮件多个任务按 SuperAgent 返回数组顺序和事件顺序生成执行顺序。
 - `Note`、`Allotment Maintenance`、`update_allotment_control_block` 仅历史兼容，不允许新数据生成。
+- 当前 producer 不允许再生成 `normal_task/manual_review + Cancel Booking + linked_parent_release_after_child_split`。
+- `relationship_type=linked_parent_release_after_child_split` 只用于 Parent / Child 关联和 Preflight，不再决定 `task_subtype`。
+- 旧 V2 兼容 `ai_task_results[]` 若继续提交 `Cancel Booking + linked_parent_release_after_child_split`，也按当前 producer 契约错误处理。
+
+P0.1 Parent Group 路由规则：
+
+| 场景 | 合法事件 / 三元组 | 系统处理 |
+| --- | --- | --- |
+| Child Group 创建 | `normal_task/manual_review + New Booking + new_group_block` | 创建 New Booking 业务任务 |
+| Parent Group 完整释放 / 取消 | `normal_task/manual_review + Cancel Allotment + cancel_allotment_control_block` | 创建 Cancel Allotment 业务任务卡 |
+| 旧 Parent split 新入站 | `Cancel Booking + linked_parent_release_after_child_split` | `adapter_contract_error`，不创建业务任务 |
+| 重复 Parent 候选 | 同一 Parent Group 再次输出合法 Parent 候选 | 第二个及后续 Parent 写入 `adapter_contract_error` |
+| 历史旧 payload 只读展示 | `Cancel Booking + linked_parent_release_after_child_split` | reader / adapter 展示层可归一为 Cancel Allotment，不改写原 payload |
 
 ### 7.2 方案 C：AI 三元组和系统处理分类分离
 
@@ -341,10 +359,11 @@ Content-Type: application/json
 
 命中以下情况时，第一版应 fail closed：
 
-- 42 路由与 runtime 输出不一致或无法唯一匹配。
+- 40 路由与 runtime 输出不一致或无法唯一匹配。
 - `manual_review` 九字段不完整。
 - `missing_fields[]` 不是 RFC 6901 pointer，或无法映射到可编辑字段。
 - Parent split 关系字段不完整或无法一一对应。
+- 当前 producer 输出 `Cancel Booking + linked_parent_release_after_child_split`。
 - `Note`、`Allotment Maintenance`、`update_allotment_control_block` 新数据出现。
 - Fix Charge、Preflight/lock、Fallback 非字段解阻、Voucher 文件对象缺失、Manual RateCode 边界等 P1/P2 未闭合场景。
 
@@ -366,6 +385,8 @@ Content-Type: application/json
 - 复核解阻页需要能提交 `field_overrides[]`，并在复核场景下确认订单归属。
 - `unhandled_current_intents[]` 只作为展示块，不提供执行按钮。
 - P1/P2 fail-closed 返回时，前端展示稳定错误和源邮件入口，不让用户误以为可以确认执行。
+- Parent split 父事件展示为 `Cancel Allotment / cancel_allotment_control_block`，不再展示独立 Parent Cancel Booking 卡。
+- 任务列表筛选不提供 `linked_parent_release_after_child_split`；新开发阶段只展示 `S10/S99` 筛选，不再展示旧 `S000/S999` 筛选项。
 
 ## 12. 后端实施 checkpoint 建议
 
@@ -373,16 +394,17 @@ V3 建议拆成以下 checkpoint，避免一次性重构过大：
 
 | Checkpoint | 目标 | 说明 |
 | --- | --- | --- |
-| M002-V3-CP1 | 文档和枚举基线 | 已完成：建立 42 路由枚举 / 稳定配置，作为入站路由唯一代码源 |
+| M002-V3-CP1 | 文档和枚举基线 | 已完成：建立 0711 P0 42 路由枚举 / 稳定配置；P0.1 后已调整为 40 路由 |
 | M002-V3-CP2 | 入站解析兼容 | 已完成：正式回调支持结构化 S10/S99 和 V3 业务根，保留旧 S000/S999 兼容 |
 | M002-V3-CP3 | 路由持久化 | 已完成第一版：已保存 AI 原始三元组、route_code、system_process_category、unhandled_current_intents 和 adapter_contract_error |
 | M002-V3-CP4 | 列表 / 详情展示 | 已完成第一版：任务列表、订单任务时间线和任务详情透出 V3 路由字段；任务详情支持 S10/S99 入口通知结构、unhandled intent 展示块和 adapter contract error 展示块 |
 | M002-V3-CP5 | 同卡复核解阻 | 已完成第一版：支持 review_status、review_resolution.field_overrides[]、复核场景订单归属确认、JSON Pointer 校验和 READY 流转 |
 | M002-V3-CP6 | P0 fixtures 回归 | 已完成第一版：引入 0711 P0 fixtures / validator 作为后端适配测试参考，覆盖 main_outcomes、candidate_gate、manual_review_resolution、source_identity_errors、parent_split_two_children、row_multiple_derived、allotment_scope；其中 candidate_gate 是 Main Agent 调 Skill 前契约，后端以 validator 和 fixture reference 固化，不作为任务结果回调直接建任务 |
+| M002-V3-CP7 | P0.1 Parent Group 路由修订 | 当前 checkpoint：将 Parent split 父事件从旧 Cancel Booking 迁移为 Cancel Allotment，路由总数 42 → 40，并保留旧 payload 只读兼容 |
 
 ## 13. 明确不做
 
-V3 P0 不做以下事项：
+V3 P0.1 不做以下事项：
 
 - 不做真实 OPERA / OHIP 写入。
 - 不做普通任务任意切换订单。
@@ -394,12 +416,12 @@ V3 P0 不做以下事项：
 
 ## 14. 当前代码现状提醒
 
-截至 M002 V3 CP6 落地后，当前后端已经实现：
+截至 M002 V3 CP7 落地后，当前后端已经实现：
 
 - `S000/S999` 文本结果兼容处理。
 - 结构化 `S10/S99` 入站处理，复用 `SOURCE_MESSAGE_ONLY` 只读特殊任务。
-- 42 条 P0 路由枚举 / 稳定配置。
-- V3 业务根 `source_message + message_events[]` 基础解析；能派生到稳定路由的 event 创建业务任务，无法派生的 event、显式 `contract_errors`、根 `missing_fields`、不完整 `manual_review` 和不完整 parent split 候选只落 `adapter_contract_error` transition。
+- 40 条 P0.1 路由枚举 / 稳定配置。
+- V3 业务根 `source_message + message_events[]` 基础解析；能派生到稳定路由的 event 创建业务任务，无法派生的 event、显式 `contract_errors`、根 `missing_fields`、不完整 `manual_review`、当前 producer 旧 Parent Cancel Booking 和不完整 parent split 候选只落 `adapter_contract_error` transition。
 - `unhandled_current_intents[]` 只落 `UNHANDLED_CURRENT_INTENT` transition，不创建订单和任务，也不伪装成 adapter 契约错误。
 - AI transition 最小保存 `route_code`、`system_process_category`、`adapter_error_code`、`adapter_error_message`。
 - 任务列表、订单任务时间线和任务详情顶层透出 `result_type`、`ai_task_type`、`task_subtype`、`route_code`、`system_process_category`。
@@ -409,11 +431,11 @@ V3 P0 不做以下事项：
 - `POST /api/reservation/tasks/{taskId}/manual-review-resolutions` 支持字段修正、当前订单归属确认、JSON Pointer 到可编辑字段校验、READY 流转、confirmed payload 写入、两条 OPERA 模拟操作创建和审计记录。
 - `POST /api/reservation/tasks/{taskId}/manual-review-resolutions` 的 `field_overrides[]` 已支持 `field_pointer` 和 `field_path` 两种定位方式；`field_path` 可为 P0 主路径或旧扁平路径，成功后响应归一化到 P0 主 `field_path`。
 - `source_message.source_message_id` 缺失时按 V3 typed `infrastructure_input_error` 结构响应。
-- 0711 P0 fixtures 已纳入后端回归测试参考，并补齐 S10/S99 严格契约、P0 type-known manual review 解阻、candidate_gate reference 和当前扁平字段矩阵兼容。
+- 0711 P0 fixtures 已纳入后端回归测试参考，并补齐 S10/S99 严格契约、P0 type-known manual review 解阻、candidate_gate reference 和当前扁平字段矩阵兼容；Parent split 相关用例按 0712 P0.1 增量改为 Cancel Allotment。
 - `field_contract_version` 历史迁移已收紧：V18 只把没有 `draft_payload_json` 且没有 `confirmed_payload_json` 的 `code-v1` 任务卡标记为 `20260711-p0`；已经存在用户草稿或确认 payload 的历史任务卡保留旧版本，等待重新保存、确认或后续专项 backfill。
 - 订单 / 任务列表、任务详情、草稿保存、最终确认、OPERA 模拟骨架和审计列表。
 - SuperAgent 查询上下文接口 1、2，以及邮件会话相关查询。
 
 仍需后续 checkpoint 实现：
 
-- 真实 OPERA / OHIP、普通任务任意切换订单、字段矩阵从当前扁平结构整体迁移到 0711 P0 新结构。
+- 真实 OPERA / OHIP、普通任务任意切换订单、字段矩阵从当前扁平结构整体迁移到 0711 P0 新结构、历史旧 Parent Cancel Booking payload 批量迁移。
diff --git a/docs/project/requirements/M002-superagent-task-result-api-contract.md b/docs/project/requirements/M002-superagent-task-result-api-contract.md
index 448c86c..9302e95 100644
--- a/docs/project/requirements/M002-superagent-task-result-api-contract.md
+++ b/docs/project/requirements/M002-superagent-task-result-api-contract.md
@@ -8,9 +8,9 @@
 
 | 项目 | 内容 |
 | --- | --- |
-| 文档版本 | 0.5 |
-| 日期 | 2026-07-11 |
-| 状态 | V2 兼容 + M002 V3 CP1-CP6 入站解析、同卡复核和 P0 fixtures 回归基线；后续业务流程以 `M002-order-task-workflow-v3.md` 为准 |
+| 文档版本 | 0.6 |
+| 日期 | 2026-07-12 |
+| 状态 | V2 兼容 + M002 V3 CP1-CP7 入站解析、同卡复核、P0 fixtures 回归和 P0.1 Parent Group 路由修订；后续业务流程以 `M002-order-task-workflow-v3.md` 为准 |
 | 适用范围 | SuperAgent / Main Agent 调用本系统提交 AI 任务结果 |
 | 主要读者 | 后端、SuperAgent 对接方、测试、后续协作 agent |
 
@@ -20,7 +20,7 @@
 
 本文承接 `M002-order-task-workflow-v2.md`，只定义本系统入站接口、鉴权、幂等、请求响应和技术校验边界，不定义 SuperAgent 内部 prompt、Skill 实现、OPERA 真实接口或前端展示细节。
 
-2026-07-11 后，M002 后续开发基线已迁移到 `M002-order-task-workflow-v3.md`。当前后端已完成 CP1-CP6：结构化 `S10/S99` 入站、V3 业务根基础解析、42 路由枚举 / 稳定配置、`UNHANDLED_CURRENT_INTENT` 和 route 相关字段最小落库、type-known manual review 同卡解阻第一版、typed `infrastructure_input_error` 响应和 P0 fixtures 回归基线。旧 `S000/S999` 和 `ai_task_results[]` 仍作为兼容路径保留。对外联调以 `docs/project/integrations/superagent-api-contract.md` 为准。
+2026-07-11 后，M002 后续开发基线已迁移到 `M002-order-task-workflow-v3.md`。2026-07-12 起，Parent Group / Allotment 路由采用 P0.1 增量修订：当前后端目标为结构化 `S10/S99` 入站、V3 业务根基础解析、40 路由枚举 / 稳定配置、`UNHANDLED_CURRENT_INTENT` 和 route 相关字段最小落库、type-known manual review 同卡解阻第一版、typed `infrastructure_input_error` 响应、P0 fixtures 回归基线和 Parent split `Cancel Allotment` 路由。旧 `S000/S999` 和 `ai_task_results[]` 仍作为兼容路径保留。对外联调以 `docs/project/integrations/superagent-api-contract.md` 为准。
 
 ## 2. 接口概览
 
@@ -41,6 +41,7 @@
 - 本接口只做技术校验和系统接收，不替代用户确认和 OPERA 模拟操作。
 - `application/json` 用于 V3 结构化 `S10/S99`、V3 业务根或 V2 `normal_task` / `manual_review` 兼容结构化任务。
 - `text/plain` 用于旧 `S000,source_message_id` / `S999,source_message_id` 特殊入口结果兼容。
+- P0.1 后，V3 业务根中的完整 Parent split 父事件必须使用 `event_type=Cancel Allotment` 和 `task_subtype=cancel_allotment_control_block`；当前新入站不接受 `Cancel Booking + linked_parent_release_after_child_split` 作为合法业务任务，旧 V2 `ai_task_results[]` 兼容入口也不能继续提交该三元组。
 
 ### 2.1 SourceMessage ID 口径
 
@@ -251,6 +252,8 @@ S999,mail-20260708-0001
 - `task_type` 属于当前系统可识别的稳定值或可进入 Fallback 处理。
 - 同一个请求内 `source_event_index` 和数组顺序可保存。
 - 关键字符串长度不超过数据库限制。
+- V3 P0.1 Parent split 当前合法结构必须是 `Cancel Allotment + cancel_allotment_control_block`；`Cancel Booking + linked_parent_release_after_child_split` 属于当前 producer 契约错误，只能作为历史 payload 只读兼容。
+- 同一个 Parent split cluster 只能有一个 Parent 候选；重复 Parent 候选不创建第二张业务任务卡。
 
 ### 5.2 不在本接口判断
 
@@ -260,6 +263,7 @@ S999,mail-20260708-0001
 - 不因为字段缺失自动改成 Fallback。
 - 不直接执行 OPERA 模拟。
 - 不直接把 AI 原始值写入 OPERA 参数。
+- 不把 Parent split 的 adapter 契约校验理解为业务成功；即使生成 `Cancel Allotment` 任务，也必须等待用户确认、Preflight 和后续 OPERA/OHIP 接入。
 
 ## 6. 幂等设计
 
diff --git a/docs/project/requirements/M002-v3-p0.1-parent-group-routing-update.md b/docs/project/requirements/M002-v3-p0.1-parent-group-routing-update.md
new file mode 100644
index 0000000..f7937fe
--- /dev/null
+++ b/docs/project/requirements/M002-v3-p0.1-parent-group-routing-update.md
@@ -0,0 +1,144 @@
+# M002 V3 P0.1 Parent Group Routing Update
+
+## 文档信息
+
+| 项目 | 内容 |
+| --- | --- |
+| 文档版本 | 0.1 |
+| 日期 | 2026-07-12 |
+| 状态 | P0.1 增量修订确认版，作为 M002 V3 后续 Parent Group / Allotment 路由开发依据 |
+| 适用范围 | SuperAgent V3 入站、Adapter 路由、Parent split、前端卡型映射、后端回归测试 |
+| 主要读者 | 后端、前端、测试、SuperAgent 对接方、后续协作 agent |
+
+## 1. 背景
+
+2026-07-12 导入的 P0.1 资料修正了 0711 P0 中 Parent split 的建模方式。旧 P0 曾把 Parent split 父事件建模为 `Cancel Booking + linked_parent_release_after_child_split`。P0.1 明确要求：
+
+```text
+Allotment / Control Block = Parent Group
+Allotment code = Parent Group code
+Parent Group 的 block_code = group_code
+```
+
+因此 Parent split 的父事件不再是普通 `Cancel Booking`，而是 Parent Group 整块取消：
+
+```text
+N 个 Child New Booking + 1 个 Parent Cancel Allotment
+```
+
+本文只记录 P0 到 P0.1 的增量差异，不重写完整 M002 V3 业务流程。完整流程仍以 `M002-order-task-workflow-v3.md` 为主文档。
+
+## 2. 权威输入
+
+本次增量以以下导入资料为准：
+
+| 资料 | 用途 |
+| --- | --- |
+| `docs/import/20260712/开发交付_P0_to_P0.1_增量修订说明_给开发Codex_2026-07-11.md` | P0.1 Parent Group 语义修订、路由数量、验收清单 |
+| `docs/import/20260712/Agent 0711 1743/prompts/main_agent_prompt.md` | P0.1 Main Agent prompt |
+| `docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/SKILL.md` | P0.1 booking-desk-event skill 入口 |
+| `docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/00-output-contract.md` | 输出契约、S10/S99、Parent candidate 结构 |
+| `docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/31-allotment-control-block.md` | Allotment / Control Block 与 Parent Group 权威定义 |
+
+`docs/import/20260711/**` 仍作为 P0 基线和 fixtures 参考，但其中 Parent Cancel Booking / 42 路由口径已被 P0.1 覆盖。
+
+## 3. 路由差异
+
+P0.1 删除两条当前合法路由：
+
+| 旧三元组 | P0.1 当前处理 |
+| --- | --- |
+| `normal_task + Cancel Booking + linked_parent_release_after_child_split` | 当前新入站必须 `adapter_contract_error`，仅 legacy reader 可只读识别 |
+| `manual_review + Cancel Booking + linked_parent_release_after_child_split` | 当前新入站必须 `adapter_contract_error`，仅 legacy reader 可只读识别 |
+
+P0.1 复用已有 Cancel Allotment 卡：
+
+| Agent event | Adapter 三元组 |
+| --- | --- |
+| `Cancel Allotment` 且 `manual_review=null` | `normal_task + Cancel Allotment + cancel_allotment_control_block` |
+| `Cancel Allotment` 且 `manual_review!=null` | `manual_review + Cancel Allotment + cancel_allotment_control_block` |
+
+`relationship_type=linked_parent_release_after_child_split` 只表示 Parent 与 Child 的关联关系和后续 Preflight 校验，不再选择独立 task subtype。
+
+最新路由统计：
+
+```text
+18 个业务 subtype × normal/manual = 36 条
+S10、S99、Fallback、unhandled display = 4 条
+总计 = 40 条
+```
+
+注意：`route_code` 是对外接口和历史 transition 都会看到的稳定代码，不按总数重编号。P0.1 的“40 条”表示当前合法 route definition 数量为 40；历史稳定码 `R41_FALLBACK_BUSINESS_EVENT_REVIEW` 和 `R42_UNHANDLED_CURRENT_INTENT` 继续保留。
+
+## 4. Parent Split 当前合法结构
+
+完整 Parent split 必须满足：
+
+- 每个 Child 输出一个 `New Booking`，且 `extracted_fields.booking_object_type=Group Block`。
+- Parent 输出且只输出一个 `Cancel Allotment`。
+- Parent 的 `extracted_fields.cancel_scope=entire_allotment_control_block`。
+- Parent 的 `extracted_fields.parent_release_or_cancel_candidate=true`、`release_reason=parent_to_child_allocation_split`、`allocation_split_from_parent=true`。
+- Parent 的 `relationship_type=linked_parent_release_after_child_split`。
+- Parent 的 `requires_downstream_hard_validation=true`。
+- Parent 的 `case_keys.group_code` 与 `case_keys.block_code` 必须同时存在且完全相等；只取得一边时复制到另一边。
+- Parent 的 `extracted_fields.parent_group_code` 必须与归一后的 Parent code 一致。
+- Parent 的 `related_source_event_indices[]` 必须与 `extracted_fields.child_group_codes[]` 数量一致、顺序一一对应，并指向同根 `message_events[]` 中的 Child New Booking。
+
+如果当前 producer 输出：
+
+```text
+Cancel Booking + linked_parent_release_after_child_split
+```
+
+后端不得按 legacy 兼容路径放行，应作为当前入站契约错误处理。
+
+## 5. Legacy 只读兼容
+
+历史已经保存的旧 payload：
+
+```text
+Cancel Booking
++ cancel_object_type=group_block
++ relationship_type=linked_parent_release_after_child_split
+```
+
+处理规则：
+
+- 不批量迁移历史 JSON。
+- 不改写或回写原历史 payload。
+- 审计或原始 AI payload 查看仍展示旧数据。
+- reader / adapter 展示层可以只读归一为 `Cancel Allotment + cancel_allotment_control_block`。
+- 当前新入站不能借 legacy reader 分支继续生成旧组合。
+
+## 6. 前端影响
+
+前端应按以下口径展示：
+
+- 不再注册或展示独立 Parent Cancel Booking 卡型。
+- Parent split 父事件展示为 `Cancel Allotment / cancel_allotment_control_block`。
+- `relationship_type=linked_parent_release_after_child_split` 可以作为关联标签或详情字段展示，但不能作为任务 subtype 筛选项。
+- 任务筛选项不应出现 `linked_parent_release_after_child_split`。
+- 新开发阶段任务列表筛选只保留 `S10/S99`，不再展示旧 `S000/S999` 筛选项；旧数据展示兼容仍由详情和只读卡逻辑兜底。
+
+## 7. 后端验收清单
+
+后端实现 P0.1 时至少覆盖：
+
+- 路由枚举为 40 条。
+- 旧 `linked_parent_release_after_child_split` 不再是当前合法 route definition。
+- 当前入站 `Cancel Booking + linked_parent_release_after_child_split` 记录为 `adapter_contract_error`，不创建业务任务；该规则同时适用于 V3 `message_events[]` 和旧 V2 兼容 `ai_task_results[]`。
+- 当前入站 `Cancel Allotment + cancel_allotment_control_block + linked_parent_release_after_child_split` 可以创建 `CANCEL_ALLOTMENT` 业务卡。
+- 同一个 Parent split cluster 重复提交 Parent 候选时，后续重复 Parent 记录为 `adapter_contract_error`，不再创建第二张 Parent 任务卡。
+- Parent 双 key 不一致时不猜测，进入 type-known manual review 或 adapter contract error，不能改成普通 Cancel Booking。
+- Parent `child_group_codes[]` 与 `related_source_event_indices[]` 数量、顺序和 Child New Booking 目标一致。
+- 普通 FIT / Group Block 的 `Cancel Booking` 不受影响。
+- 旧历史数据只读兼容，不迁移、不改写原 payload。
+- 项目文档、对外 SuperAgent 契约、前后端沟通文档和测试断言全部从 42 路由更新为 40 路由。
+
+## 8. 不做范围
+
+- 不实现真实 OPERA / OHIP。
+- 不做普通任务任意切换订单。
+- 不批量迁移历史旧 payload。
+- 不扩大 P1/P2 未闭合规则。
+- 不把部分 Allotment / Control Block 维护重新开放为 active 路由。
diff --git a/server/src/main/java/cn/nianxx/thhotel/workflows/reservation/common/enums/ReservationAiRouteDefinition.java b/server/src/main/java/cn/nianxx/thhotel/workflows/reservation/common/enums/ReservationAiRouteDefinition.java
index e71e3e7..c829eee 100644
--- a/server/src/main/java/cn/nianxx/thhotel/workflows/reservation/common/enums/ReservationAiRouteDefinition.java
+++ b/server/src/main/java/cn/nianxx/thhotel/workflows/reservation/common/enums/ReservationAiRouteDefinition.java
@@ -106,22 +106,6 @@ public enum ReservationAiRouteDefinition {
             ReservationAiSystemProcessCategory.BUSINESS_TASK,
             ReservationSystemTaskType.CANCEL_BOOKING,
             ReservationTaskCardType.CANCEL_BOOKING),
-    LINKED_PARENT_RELEASE_AFTER_CHILD_SPLIT_NORMAL(
-            "R07_LINKED_PARENT_RELEASE_AFTER_CHILD_SPLIT_NORMAL",
-            "normal_task",
-            "Cancel Booking",
-            "linked_parent_release_after_child_split",
-            ReservationAiSystemProcessCategory.BUSINESS_TASK,
-            ReservationSystemTaskType.CANCEL_BOOKING,
-            ReservationTaskCardType.CANCEL_BOOKING),
-    LINKED_PARENT_RELEASE_AFTER_CHILD_SPLIT_REVIEW(
-            "R07_LINKED_PARENT_RELEASE_AFTER_CHILD_SPLIT_REVIEW",
-            "manual_review",
-            "Cancel Booking",
-            "linked_parent_release_after_child_split",
-            ReservationAiSystemProcessCategory.BUSINESS_TASK,
-            ReservationSystemTaskType.CANCEL_BOOKING,
-            ReservationTaskCardType.CANCEL_BOOKING),
     CANCEL_ALLOTMENT_CONTROL_BLOCK_NORMAL(
             "R08_CANCEL_ALLOTMENT_CONTROL_BLOCK_NORMAL",
             "normal_task",
diff --git a/server/src/main/java/cn/nianxx/thhotel/workflows/reservation/service/impl/ReservationAiTaskIntakeServiceImpl.java b/server/src/main/java/cn/nianxx/thhotel/workflows/reservation/service/impl/ReservationAiTaskIntakeServiceImpl.java
index 2977796..502c670 100644
--- a/server/src/main/java/cn/nianxx/thhotel/workflows/reservation/service/impl/ReservationAiTaskIntakeServiceImpl.java
+++ b/server/src/main/java/cn/nianxx/thhotel/workflows/reservation/service/impl/ReservationAiTaskIntakeServiceImpl.java
@@ -213,6 +213,10 @@ public class ReservationAiTaskIntakeServiceImpl implements ReservationAiTaskInta
         if (!taskResults.isArray() || taskResults.isEmpty()) {
             throw error(HttpStatus.BAD_REQUEST, "TASK_RESULTS_EMPTY", "ai_task_results 不能为空。");
         }
+        V3EventContractIssue legacyIssue = inspectV2TaskResultsContractIssue(taskResults);
+        if (legacyIssue != null) {
+            throw error(HttpStatus.BAD_REQUEST, "ADAPTER_CONTRACT_ERROR", legacyIssue.message());
+        }
 
         String hotelId = sourceMessage.hotelId();
         String requestPayloadSha256 = sha256(rawBody == null ? "" : rawBody);
@@ -364,10 +368,14 @@ public class ReservationAiTaskIntakeServiceImpl implements ReservationAiTaskInta
         }
 
         List<SuperAgentTaskResultItemResponse> responseItems = new ArrayList<>(itemCount);
+        Set<String> acceptedParentSplitCodes = new LinkedHashSet<>();
         for (int index = 0; index < messageEvents.size(); index++) {
             JsonNode event = messageEvents.get(index);
             int arrayIndex = index + 1;
             V3EventContractIssue contractIssue = inspectV3EventContractIssue(event, messageEvents);
+            if (contractIssue == null) {
+                contractIssue = inspectV3ParentSplitDuplicateIssue(event, acceptedParentSplitCodes);
+            }
             if (contractIssue != null) {
                 responseItems.add(createAdapterContractErrorTransition(
                         hotelId,
@@ -426,6 +434,32 @@ public class ReservationAiTaskIntakeServiceImpl implements ReservationAiTaskInta
         );
     }
 
+    /**
+     * 校验 V2 兼容 ai_task_results[] 中不再允许当前 producer 继续提交的旧 Parent split 三元组。
+     */
+    private V3EventContractIssue inspectV2TaskResultsContractIssue(JsonNode taskResults) {
+        for (JsonNode item : taskResults) {
+            if (isLegacyParentSplitTriplet(
+                    textAt(item, "result_type"),
+                    textAt(item, "task_type"),
+                    textAt(item, "task_subtype"))) {
+                return new V3EventContractIssue(
+                        "LINKED_PARENT_RELEASE_LEGACY_CANCEL_BOOKING_UNSUPPORTED",
+                        "当前 producer 不再支持 Cancel Booking + linked_parent_release_after_child_split，Parent split 父事件必须使用 Cancel Allotment。");
+            }
+        }
+        return null;
+    }
+
+    /**
+     * 识别 P0.1 已删除的旧 Parent split 三元组。
+     */
+    private boolean isLegacyParentSplitTriplet(String resultType, String taskType, String taskSubtype) {
+        return ("normal_task".equals(resultType) || "manual_review".equals(resultType))
+                && "Cancel Booking".equals(taskType)
+                && "linked_parent_release_after_child_split".equals(taskSubtype);
+    }
+
     /**
      * 校验 V3 业务根的批次级 P0 结构；单个事件内容错误由 event 级 transition 承接。
      */
@@ -705,13 +739,9 @@ public class ReservationAiTaskIntakeServiceImpl implements ReservationAiTaskInta
     }
 
     /**
-     * Cancel Booking 需要先识别 parent split 关系，再识别普通取消对象。
+     * Cancel Booking 只识别普通取消对象；Parent split 在 P0.1 后统一走 Cancel Allotment。
      */
     private String cancelBookingSubtype(JsonNode event, JsonNode extractedFields) {
-        String relationshipType = firstText(extractedFields, event, "relationship_type");
-        if ("linked_parent_release_after_child_split".equals(relationshipType)) {
-            return "linked_parent_release_after_child_split";
-        }
         return switch (nullToEmpty(firstText(extractedFields, event, "cancel_object_type"))) {
             case "fit_reservation" -> "cancel_fit_reservation";
             case "group_block" -> "cancel_group_block";
@@ -740,6 +770,11 @@ public class ReservationAiTaskIntakeServiceImpl implements ReservationAiTaskInta
                 return manualReviewIssue;
             }
         }
+        if (isLegacyLinkedParentCancelBooking(event)) {
+            return new V3EventContractIssue(
+                    "LINKED_PARENT_RELEASE_LEGACY_CANCEL_BOOKING_UNSUPPORTED",
+                    "当前 producer 不再支持 Cancel Booking + linked_parent_release_after_child_split，Parent split 父事件必须使用 Cancel Allotment。");
+        }
         if (isLinkedParentReleaseCandidate(event) && !validLinkedParentReleaseCandidate(event, messageEvents)) {
             return new V3EventContractIssue(
                     "LINKED_PARENT_RELEASE_CONTRACT_INCOMPLETE",
@@ -770,14 +805,54 @@ public class ReservationAiTaskIntakeServiceImpl implements ReservationAiTaskInta
     }
 
     /**
-     * 校验 parent split 候选的最小可追溯关系字段，避免只凭 relationship_type 建业务任务。
+     * 判断当前 producer 是否仍在输出旧 Parent Cancel Booking 组合。
+     */
+    private boolean isLegacyLinkedParentCancelBooking(JsonNode event) {
+        JsonNode extractedFields = event == null ? null : event.path("extracted_fields");
+        return isLegacyParentSplitTriplet(
+                event == null || isNullOrMissing(event.get("manual_review"))
+                        ? AiResultType.NORMAL_TASK.code()
+                        : AiResultType.MANUAL_REVIEW.code(),
+                trimToNull(textAt(event, "event_type")),
+                firstText(extractedFields, event, "relationship_type"));
+    }
+
+    /**
+     * 校验同一 V3 业务根中同一个 Parent split cluster 只能有一个 Parent 候选。
+     */
+    private V3EventContractIssue inspectV3ParentSplitDuplicateIssue(JsonNode event, Set<String> acceptedParentSplitCodes) {
+        if (!isLinkedParentReleaseCandidate(event)) {
+            return null;
+        }
+        String parentGroupCode = trimToNull(textAt(event.path("case_keys"), "group_code"));
+        if (parentGroupCode != null && !acceptedParentSplitCodes.add(parentGroupCode)) {
+            return new V3EventContractIssue(
+                    "LINKED_PARENT_RELEASE_DUPLICATE_PARENT",
+                    "同一个 Parent split cluster 只能有一个 Parent Cancel Allotment 候选。");
+        }
+        return null;
+    }
+
+    /**
+     * 校验 P0.1 parent split 候选的最小可追溯关系字段，避免只凭 relationship_type 建业务任务。
      */
     private boolean validLinkedParentReleaseCandidate(JsonNode event, JsonNode messageEvents) {
         JsonNode extractedFields = event == null ? null : event.path("extracted_fields");
         JsonNode caseKeys = event == null ? null : event.path("case_keys");
-        if (!("Cancel Booking".equals(trimToNull(textAt(event, "event_type")))
-                && "group_block".equals(firstText(extractedFields, event, "cancel_object_type"))
-                && trimToNull(textAt(caseKeys, "group_code")) != null
+        String parentGroupCode = trimToNull(textAt(caseKeys, "group_code"));
+        String parentBlockCode = trimToNull(textAt(caseKeys, "block_code"));
+        if (!("Cancel Allotment".equals(trimToNull(textAt(event, "event_type")))
+                && "entire_allotment_control_block".equals(firstText(extractedFields, event, "cancel_scope"))
+                && isBooleanTrue(extractedFields.path("parent_release_or_cancel_candidate"))
+                && "parent_to_child_allocation_split".equals(firstText(extractedFields, event, "release_reason"))
+                && parentGroupCode != null
+                && parentGroupCode.equals(firstText(extractedFields, event, "parent_group_code"))
+                && isBooleanTrue(extractedFields.path("allocation_split_from_parent"))
+                && "New Booking".equals(trimToNull(textAt(event, "related_event_type")))
+                && event != null
+                && isBooleanTrue(event.path("requires_downstream_hard_validation"))
+                && parentGroupCode != null
+                && parentGroupCode.equals(parentBlockCode)
                 && nonEmptyArray(extractedFields, "child_group_codes")
                 && nonEmptyArray(event, "related_source_event_indices"))) {
             return false;
@@ -789,25 +864,28 @@ public class ReservationAiTaskIntakeServiceImpl implements ReservationAiTaskInta
                 || childGroupCodes.size() != relatedSourceEventIndices.size()) {
             return false;
         }
-        Set<String> expectedChildGroups = new LinkedHashSet<>(childGroupCodes);
+        Set<String> childGroupCodeSet = new LinkedHashSet<>(childGroupCodes);
         Set<String> relatedEventIds = new LinkedHashSet<>(relatedSourceEventIndices);
-        if (expectedChildGroups.size() != childGroupCodes.size()
+        if (childGroupCodeSet.size() != childGroupCodes.size()
                 || relatedEventIds.size() != relatedSourceEventIndices.size()) {
             return false;
         }
-        Set<String> actualChildGroups = new LinkedHashSet<>();
-        for (String sourceEventIndex : relatedSourceEventIndices) {
+        for (int index = 0; index < relatedSourceEventIndices.size(); index++) {
+            String sourceEventIndex = relatedSourceEventIndices.get(index);
             JsonNode childEvent = findV3MessageEventBySourceEventIndex(messageEvents, sourceEventIndex);
             if (childEvent == null || !"New Booking".equals(trimToNull(textAt(childEvent, "event_type")))) {
                 return false;
             }
-            String childGroupCode = trimToNull(textAt(childEvent.path("case_keys"), "group_code"));
-            if (childGroupCode == null || !expectedChildGroups.contains(childGroupCode)) {
+            JsonNode childExtractedFields = childEvent.path("extracted_fields");
+            if (!"Group Block".equals(firstText(childExtractedFields, childEvent, "booking_object_type"))) {
+                return false;
+            }
+            String childGroupCode = trimToNull(textAt(childEvent.path("case_keys"), "group_code"));
+            if (!childGroupCodes.get(index).equals(childGroupCode)) {
                 return false;
             }
-            actualChildGroups.add(childGroupCode);
         }
-        return actualChildGroups.equals(expectedChildGroups);
+        return true;
     }
 
     /**
diff --git a/server/src/test/java/cn/nianxx/thhotel/workflows/reservation/common/enums/ReservationAiRouteDefinitionTest.java b/server/src/test/java/cn/nianxx/thhotel/workflows/reservation/common/enums/ReservationAiRouteDefinitionTest.java
index 905cad1..e37c05e 100644
--- a/server/src/test/java/cn/nianxx/thhotel/workflows/reservation/common/enums/ReservationAiRouteDefinitionTest.java
+++ b/server/src/test/java/cn/nianxx/thhotel/workflows/reservation/common/enums/ReservationAiRouteDefinitionTest.java
@@ -7,8 +7,8 @@ import org.junit.jupiter.api.Test;
 class ReservationAiRouteDefinitionTest {
 
     @Test
-    void shouldKeepFortyTwoM002V3P0RouteDefinitions() {
-        assertThat(ReservationAiRouteDefinition.values()).hasSize(42);
+    void shouldKeepFortyM002V3P01RouteDefinitions() {
+        assertThat(ReservationAiRouteDefinition.values()).hasSize(40);
     }
 
     @Test
@@ -25,5 +25,15 @@ class ReservationAiRouteDefinitionTest {
                 "Payment Evidence",
                 "payment_evidence"))
                 .contains(ReservationAiRouteDefinition.PAYMENT_EVIDENCE_REVIEW);
+        assertThat(ReservationAiRouteDefinition.findByTriplet(
+                "normal_task",
+                "Cancel Allotment",
+                "cancel_allotment_control_block"))
+                .contains(ReservationAiRouteDefinition.CANCEL_ALLOTMENT_CONTROL_BLOCK_NORMAL);
+        assertThat(ReservationAiRouteDefinition.findByTriplet(
+                "normal_task",
+                "Cancel Booking",
+                "linked_parent_release_after_child_split"))
+                .isEmpty();
     }
 }
diff --git a/server/src/test/java/cn/nianxx/thhotel/workflows/reservation/control/SuperAgentTaskResultControllerTest.java b/server/src/test/java/cn/nianxx/thhotel/workflows/reservation/control/SuperAgentTaskResultControllerTest.java
index ebf4ac7..36b9892 100644
--- a/server/src/test/java/cn/nianxx/thhotel/workflows/reservation/control/SuperAgentTaskResultControllerTest.java
+++ b/server/src/test/java/cn/nianxx/thhotel/workflows/reservation/control/SuperAgentTaskResultControllerTest.java
@@ -149,6 +149,35 @@ class SuperAgentTaskResultControllerTest {
         org.assertj.core.api.Assertions.assertThat(taskCardCount).isGreaterThanOrEqualTo(1L);
     }
 
+    @Test
+    void shouldRejectLegacyAiTaskResultsParentSplitCancelBooking() throws Exception {
+        SourceMessageCaptureResult source = captureSourceMessage("mail-v2-parent-split-legacy-001");
+        String body = minimalBody(source.inboxId().toString(), "Cancel Booking", "normal_task",
+                "linked_parent_release_after_child_split", """
+                "case_keys": {"group_code": "PARENT-V2-001"},
+                "extracted_fields": {
+                  "cancel_object_type": "group_block",
+                  "parent_release_or_cancel_candidate": true,
+                  "release_reason": "parent_to_child_allocation_split",
+                  "parent_group_code": "PARENT-V2-001",
+                  "child_group_codes": ["CHILD-V2-001"],
+                  "allocation_split_from_parent": true
+                }
+                """);
+
+        mockMvc.perform(signedPost(body, "nonce-v2-parent-split-legacy-001"))
+                .andExpect(status().isBadRequest())
+                .andExpect(jsonPath("$.error_code").value("ADAPTER_CONTRACT_ERROR"))
+                .andExpect(content().string(containsString("Cancel Booking + linked_parent_release_after_child_split")));
+
+        Long taskCount = jdbcTemplate.queryForObject("""
+                SELECT COUNT(*)
+                FROM workflow_reservation_task
+                WHERE source_message_id = ?
+                """, Long.class, source.inboxId());
+        assertThat(taskCount).isZero();
+    }
+
     @Test
     void shouldResolveTaskResultSourceMessageByExternalMessageId() throws Exception {
         String externalMessageId = "mail-external-source-id-001";
diff --git a/server/src/test/java/cn/nianxx/thhotel/workflows/reservation/control/SuperAgentTaskResultP0FixtureRegressionTest.java b/server/src/test/java/cn/nianxx/thhotel/workflows/reservation/control/SuperAgentTaskResultP0FixtureRegressionTest.java
index 8a7d912..2ebc7b4 100644
--- a/server/src/test/java/cn/nianxx/thhotel/workflows/reservation/control/SuperAgentTaskResultP0FixtureRegressionTest.java
+++ b/server/src/test/java/cn/nianxx/thhotel/workflows/reservation/control/SuperAgentTaskResultP0FixtureRegressionTest.java
@@ -269,6 +269,7 @@ class SuperAgentTaskResultP0FixtureRegressionTest {
     void shouldCreateParentSplitTasksFromP0FixtureInEventOrder() throws Exception {
         ObjectNode root = fixture("parent_split_two_children.json").deepCopy();
         useParentSplitBusinessKeys(root, "PARENT-2608-OK", "CHILD-2608-OK-A", "CHILD-2608-OK-B");
+        convertParentSplitRootToP01(root);
         String externalId = "p0-parent-split-001";
         SourceMessageCaptureResult source = captureSourceMessage(externalId);
 
@@ -279,7 +280,7 @@ class SuperAgentTaskResultP0FixtureRegressionTest {
                 .andExpect(jsonPath("$.items[0].execution_order").value(1))
                 .andExpect(jsonPath("$.items[1].route_code").value("R02_NEW_GROUP_BLOCK_NORMAL"))
                 .andExpect(jsonPath("$.items[1].execution_order").value(1))
-                .andExpect(jsonPath("$.items[2].route_code").value("R07_LINKED_PARENT_RELEASE_AFTER_CHILD_SPLIT_NORMAL"))
+                .andExpect(jsonPath("$.items[2].route_code").value("R08_CANCEL_ALLOTMENT_CONTROL_BLOCK_NORMAL"))
                 .andReturn();
 
         String parentOrderId = com.jayway.jsonpath.JsonPath.read(
@@ -297,16 +298,41 @@ class SuperAgentTaskResultP0FixtureRegressionTest {
                 WHERE source_message_id = ?
                   AND route_code IN (
                     'R02_NEW_GROUP_BLOCK_NORMAL',
-                    'R07_LINKED_PARENT_RELEASE_AFTER_CHILD_SPLIT_NORMAL'
+                    'R08_CANCEL_ALLOTMENT_CONTROL_BLOCK_NORMAL'
                   )
                 """, Long.class, source.inboxId());
         assertThat(transitionCount).isEqualTo(3L);
     }
 
+    @Test
+    void shouldFailClosedWhenCurrentProducerUsesLegacyParentCancelBooking() throws Exception {
+        ObjectNode root = fixture("parent_split_two_children.json").deepCopy();
+        useParentSplitBusinessKeys(root, "PARENT-2608-LEG", "CHILD-2608-LEG-A", "CHILD-2608-LEG-B");
+        String externalId = "p0-parent-split-legacy-001";
+        SourceMessageCaptureResult source = captureSourceMessage(externalId);
+
+        mockMvc.perform(signedPost(withSourceMessageId(root, externalId), "nonce-p0-parent-split-legacy-001"))
+                .andExpect(status().isCreated())
+                .andExpect(jsonPath("$.accepted_count").value(3))
+                .andExpect(jsonPath("$.items[0].route_code").value("R02_NEW_GROUP_BLOCK_NORMAL"))
+                .andExpect(jsonPath("$.items[1].route_code").value("R02_NEW_GROUP_BLOCK_NORMAL"))
+                .andExpect(jsonPath("$.items[2].adapter_error_code")
+                        .value("LINKED_PARENT_RELEASE_LEGACY_CANCEL_BOOKING_UNSUPPORTED"))
+                .andExpect(jsonPath("$.items[2].task_id").doesNotExist());
+
+        Long taskCount = jdbcTemplate.queryForObject("""
+                SELECT COUNT(*)
+                FROM workflow_reservation_task
+                WHERE source_message_id = ?
+                """, Long.class, source.inboxId());
+        assertThat(taskCount).isEqualTo(2L);
+    }
+
     @Test
     void shouldFailClosedWhenParentSplitReferencesDoNotMatchChildEvents() throws Exception {
         ObjectNode root = fixture("parent_split_two_children.json").deepCopy();
         useParentSplitBusinessKeys(root, "PARENT-2608-MIS", "CHILD-2608-MIS-A", "CHILD-2608-MIS-B");
+        convertParentSplitRootToP01(root);
         ObjectNode parentEvent = (ObjectNode) root.path("message_events").get(2);
         ((ArrayNode) parentEvent.path("related_source_event_indices"))
                 .set(1, objectMapper.getNodeFactory().textNode("E_UNKNOWN_CHILD"));
@@ -330,9 +356,97 @@ class SuperAgentTaskResultP0FixtureRegressionTest {
         assertThat(taskCount).isEqualTo(2L);
     }
 
+    @Test
+    void shouldFailClosedWhenParentSplitReferenceOrderDoesNotMatchChildCodes() throws Exception {
+        ObjectNode root = fixture("parent_split_two_children.json").deepCopy();
+        useParentSplitBusinessKeys(root, "PARENT-2608-ORD", "CHILD-2608-ORD-A", "CHILD-2608-ORD-B");
+        convertParentSplitRootToP01(root);
+        ObjectNode parentEvent = (ObjectNode) root.path("message_events").get(2);
+        ArrayNode relatedIndices = (ArrayNode) parentEvent.path("related_source_event_indices");
+        relatedIndices.removeAll();
+        relatedIndices.add("E_CHILD_2");
+        relatedIndices.add("E_CHILD_1");
+        String externalId = "p0-parent-split-order-mismatch-001";
+        SourceMessageCaptureResult source = captureSourceMessage(externalId);
+
+        mockMvc.perform(signedPost(withSourceMessageId(root, externalId), "nonce-p0-parent-split-order-mismatch-001"))
+                .andExpect(status().isCreated())
+                .andExpect(jsonPath("$.accepted_count").value(3))
+                .andExpect(jsonPath("$.items[0].route_code").value("R02_NEW_GROUP_BLOCK_NORMAL"))
+                .andExpect(jsonPath("$.items[1].route_code").value("R02_NEW_GROUP_BLOCK_NORMAL"))
+                .andExpect(jsonPath("$.items[2].adapter_error_code")
+                        .value("LINKED_PARENT_RELEASE_CONTRACT_INCOMPLETE"))
+                .andExpect(jsonPath("$.items[2].task_id").doesNotExist());
+
+        Long taskCount = jdbcTemplate.queryForObject("""
+                SELECT COUNT(*)
+                FROM workflow_reservation_task
+                WHERE source_message_id = ?
+                """, Long.class, source.inboxId());
+        assertThat(taskCount).isEqualTo(2L);
+    }
+
+    @Test
+    void shouldFailClosedWhenParentSplitRequiredP01FieldsAreMissing() throws Exception {
+        ObjectNode root = fixture("parent_split_two_children.json").deepCopy();
+        useParentSplitBusinessKeys(root, "PARENT-2608-FIX", "CHILD-2608-FIX-A", "CHILD-2608-FIX-B");
+        convertParentSplitRootToP01(root);
+        ObjectNode parentExtractedFields = (ObjectNode) root.path("message_events").get(2).path("extracted_fields");
+        parentExtractedFields.remove("parent_release_or_cancel_candidate");
+        String externalId = "p0-parent-split-fixed-field-missing-001";
+        SourceMessageCaptureResult source = captureSourceMessage(externalId);
+
+        mockMvc.perform(signedPost(withSourceMessageId(root, externalId), "nonce-p0-parent-split-fixed-field-missing-001"))
+                .andExpect(status().isCreated())
+                .andExpect(jsonPath("$.accepted_count").value(3))
+                .andExpect(jsonPath("$.items[0].route_code").value("R02_NEW_GROUP_BLOCK_NORMAL"))
+                .andExpect(jsonPath("$.items[1].route_code").value("R02_NEW_GROUP_BLOCK_NORMAL"))
+                .andExpect(jsonPath("$.items[2].adapter_error_code")
+                        .value("LINKED_PARENT_RELEASE_CONTRACT_INCOMPLETE"))
+                .andExpect(jsonPath("$.items[2].task_id").doesNotExist());
+
+        Long taskCount = jdbcTemplate.queryForObject("""
+                SELECT COUNT(*)
+                FROM workflow_reservation_task
+                WHERE source_message_id = ?
+                """, Long.class, source.inboxId());
+        assertThat(taskCount).isEqualTo(2L);
+    }
+
+    @Test
+    void shouldFailClosedWhenParentSplitHasDuplicateParentCandidate() throws Exception {
+        ObjectNode root = fixture("parent_split_two_children.json").deepCopy();
+        useParentSplitBusinessKeys(root, "PARENT-2608-DUP", "CHILD-2608-DUP-A", "CHILD-2608-DUP-B");
+        convertParentSplitRootToP01(root);
+        ArrayNode events = (ArrayNode) root.path("message_events");
+        ObjectNode duplicateParent = events.get(2).deepCopy();
+        duplicateParent.put("source_event_index", "E_PARENT_CANCEL_DUP");
+        events.add(duplicateParent);
+        String externalId = "p0-parent-split-duplicate-parent-001";
+        SourceMessageCaptureResult source = captureSourceMessage(externalId);
+
+        mockMvc.perform(signedPost(withSourceMessageId(root, externalId), "nonce-p0-parent-split-duplicate-parent-001"))
+                .andExpect(status().isCreated())
+                .andExpect(jsonPath("$.accepted_count").value(4))
+                .andExpect(jsonPath("$.items[0].route_code").value("R02_NEW_GROUP_BLOCK_NORMAL"))
+                .andExpect(jsonPath("$.items[1].route_code").value("R02_NEW_GROUP_BLOCK_NORMAL"))
+                .andExpect(jsonPath("$.items[2].route_code").value("R08_CANCEL_ALLOTMENT_CONTROL_BLOCK_NORMAL"))
+                .andExpect(jsonPath("$.items[3].adapter_error_code")
+                        .value("LINKED_PARENT_RELEASE_DUPLICATE_PARENT"))
+                .andExpect(jsonPath("$.items[3].task_id").doesNotExist());
+
+        Long taskCount = jdbcTemplate.queryForObject("""
+                SELECT COUNT(*)
+                FROM workflow_reservation_task
+                WHERE source_message_id = ?
+                """, Long.class, source.inboxId());
+        assertThat(taskCount).isEqualTo(3L);
+    }
+
     @Test
     void shouldCreateRowDerivedMainParentAndTraceTasksFromP0Fixture() throws Exception {
         ObjectNode root = fixture("row_multiple_derived.json").deepCopy();
+        convertParentSplitRootToP01(root);
         String externalId = "p0-row-derived-001";
         SourceMessageCaptureResult source = captureSourceMessage(externalId);
 
@@ -340,7 +454,7 @@ class SuperAgentTaskResultP0FixtureRegressionTest {
                 .andExpect(status().isCreated())
                 .andExpect(jsonPath("$.accepted_count").value(3))
                 .andExpect(jsonPath("$.items[0].route_code").value("R02_NEW_GROUP_BLOCK_NORMAL"))
-                .andExpect(jsonPath("$.items[1].route_code").value("R07_LINKED_PARENT_RELEASE_AFTER_CHILD_SPLIT_NORMAL"))
+                .andExpect(jsonPath("$.items[1].route_code").value("R08_CANCEL_ALLOTMENT_CONTROL_BLOCK_NORMAL"))
                 .andExpect(jsonPath("$.items[2].route_code").value("R13_EXTRA_BED_NORMAL"));
 
         Long taskCount = jdbcTemplate.queryForObject("""
@@ -675,6 +789,27 @@ class SuperAgentTaskResultP0FixtureRegressionTest {
         childGroupCodes.add(childGroupCodeTwo);
     }
 
+    private void convertParentSplitRootToP01(ObjectNode root) {
+        ArrayNode events = (ArrayNode) root.path("message_events");
+        for (JsonNode item : events) {
+            ObjectNode event = (ObjectNode) item;
+            if (!"linked_parent_release_after_child_split".equals(event.path("relationship_type").asText(null))) {
+                continue;
+            }
+            ObjectNode caseKeys = (ObjectNode) event.path("case_keys");
+            String parentGroupCode = caseKeys.path("group_code").asText(null);
+            event.put("event_type", "Cancel Allotment");
+            caseKeys.put("block_code", parentGroupCode);
+
+            ObjectNode extractedFields = (ObjectNode) event.path("extracted_fields");
+            extractedFields.remove("cancel_object_type");
+            extractedFields.put("cancel_scope", "entire_allotment_control_block");
+            extractedFields.put("parent_release_or_cancel_candidate", true);
+            extractedFields.put("release_reason", "parent_to_child_allocation_split");
+            extractedFields.put("allocation_split_from_parent", true);
+        }
+    }
+
     private void useManualReviewGroupCode(ObjectNode event, String groupCode) {
         useEventGroupCode(event, groupCode);
         ((ObjectNode) event.path("manual_review").path("known_fields")).put("group_code", groupCode);