th-hotel-simple/docs/project/requirements/booking-email-br00-contract-acceptance-matrix-v1.md

BR00 业务类型 contracts-v1 验收矩阵

项目	内容
文档状态	当前有效
业务基线	BR00-BASELINE-1
契约版本	booking-contracts-v1
目的	把业务理解、契约、实现切片与验收证据对齐；不是旧 V4 卡片清单的替代品

1. 共同判定规则

• 只由 current 邮件正文、当前附件和明确当前指令触发业务。quoted history 只用于理解、继承身份和重复提示。
• Name of Group、Group Name、Tour Code、Group Code 都是团号的来源别名，统一标准化为唯一业务字段 group_code；不得把同一团号拆成四个独立身份字段。若有真正独立的展示名称，才可额外填 group_name；tour_code 仅保留兼容镜像，不能作为第二个目标。
• 已知业务但字段缺失：保留原业务类型进入复核；不降格为 General/Risk。
• 整封没有任何支持任务才产生一条 General。存在不可安全解释片段时每封最多一条 Risk；同封清晰任务继续生成。
• 用户确认是本期终点。任何卡片、确认、Allotment source 关系、图片或付款说明都不得触发 PMS/Opera、付款核销或部门流转。

2. 类型矩阵

业务类型	识别与拆分	Context 必要信息	Validator / 确认阻断	当前实现状态与后续切片
NEW_BOOKING	每个清晰预订目标一张候选；同一 group_code 下的多个房型/日期段可属于同一目标，不按团号别名误拆	是否已有同 Group Code/订单、sender 映射、Rate Code 候选	Booking Type、可定位身份（group_code 或明确姓名）、入住/离店、房型+数量、Rate Code；Group 必须有 group_code，不要求凭空填写 group_name；房量未知不得推 FIT	固定渠道纵向切片已存在；迁移到 contracts-v1/PostgreSQL 主线
UPDATE_BOOKING	AMEND、AMD、AMEND TO 等归一；每封实际 Update、每个目标生成新的 Update 候选	目标当前确认态、有效未完成任务、old→new Group Code 链、revision	目标必须唯一或由用户选择；前置 New/Update 关系、Cancel 后冲突、变更字段与证据	固定渠道纵向切片已存在；连续生命周期在 Phase 4 收口
CANCEL_BOOKING	当前邮件明确取消指令；不能把 quoted history 的旧 Cancel 再触发	目标当前态、未完成 Update/Cancel、关联证据	目标/前置链/重复判断；确认只是冻结取消参数，不结束订单	固定渠道纵向切片已存在；Cancel 后冲突在 Phase 4 收口
TRACE_RESERVATION_NOTES	Extra Bed 是 Trace，不是房型；同一 Group Code、同一 current 邮件的多个 Trace 合并	同 Group/订单、相邻 lifecycle 任务、既有 Trace	Department 仅在邮件证据唯一明确时预填；否则确认前必须选 FO、HSK 或两者	基础卡已存在；文字/图片证据和跨封顺序在 Phase 4 收口
ROOMING_LIST	当前附件/正文表明房表事项；一 Group Code 一项	目标识别或未知目标线索	只展示/下载 Excel，不解析旅客、不改 DEF；Group Code 不明仍应生成目标未识别通知	原生通知卡已存在；材料展示和下载在 Phase 4 收口
PAYMENT	当前附件/图片/正文表明付款凭证或替换说明	目标识别、附件/图片与当前邮件的关联	只展示图片/替换说明；不核对到账、不改订单状态；目标不明保留通知	基础附件摘要已存在；图片路径在 Phase 4 收口
ALLOTMENT	每个 actual 团独立识别为 New；source 团与 actual 团的关系必须显式表达	source 团当前库存/状态、每个 actual 的准入结果	先验证每个 actual；只汇总通过准入的房量给 source；source 不存在/不足不回滚安全 actual，只提示人工	未作为已完成切片；Phase 4 独立主线最后收口
图片 / Voucher 媒体	图片不是单独业务类型；结合 current 正文判断其支持 Trace、Payment/替换说明或不在范围	当前正文、附件关系、目标线索	证据不足不猜业务类型；可形成 Risk 或 General/ignored，不能自行创建“Voucher 订单”	Phase 4 与 Payment/图片一并完成
GENERAL_NOTIFICATION	整封 current 邮件经材料、Parser 和业务词典确认没有支持任务	仅消息级最小上下文	不得因已知业务缺字段而生成 General	基础通知已有；迁移后由 contracts-v1 统一输出
RISK_NOTIFICATION	业务类型、目标、材料或 Parser 结论有不可消解歧义	受影响目标/材料/历史摘要	每封最多一张；只隔离歧义片段；Agent invalid 也必须经 Validator 进入 Risk	基础通知已有；目标级隔离在 Phase 3 收口
IGNORED_DIRECTION	可确定为酒店外发、内部邮件或不属于处理范围	邮件方向、sender/recipient、受控规则	不创建待办或业务卡，保留安全处理记录	新 contracts-v1 主线能力，随 Orchestrator 实现

3. 核心样例到契约的断言

场景	必须形成的事实	禁止推断
【U-TWN8.5】 12	房型线索 U-TWN、价格证据 850、数量 12；与备注共同形成当前动作线索	不从价格直接猜 Rate Code
【U-TWN】 6)(850...)	房型线索 U-TWN、数量 6、价格证据 850	不因格式差异丢失 New Booking 语义
NEW BOOKING ยกเลิก 与 NEW BOOKING CXL	Parser 可保留动作候选及原始证据；业务/生命周期最终解释由 Catalog+Context+Validator	不穷举所有自然语言组合后把未覆盖文本静默当普通 New
Excel 非白底整行	严格候选行和行/列/Sheet 证据	不能靠任意一个底色单元格、字体颜色或多行互补建立确定事实
无附件 current 邮件	MaterialPackage(NO_ATTACHMENT)，仍进入 Context 和业务识别	不能绕过 SourceMessage 或直接生成 General
同一信息再次出现	重复/陈旧提示与消息幂等证据	不能静默丢弃真实新邮件或把两封邮件强行合并

4. 验收最低集

每个业务类型在实现完成前都必须至少有：

1. 一个去隐私的 contracts-v1 正例与一个错误/歧义例。
2. Parser、Agent（如适用）和 Validator 对同一输入的版本、evidence reference 与目标范围断言。
3. PostgreSQL th_hotel_booking 的 processing run、候选、校验和确认投影持久化断言。
4. 前端的展示/阻断/确认行为断言；确认后不产生 PMS/Opera、付款或部门副作用。
5. 对应真实或脱敏 E2E 样例；真实邮件只通过 opt-in 路径读取。