Files
th-hotel-simple/docs/project/requirements/booking-email-br00-contract-acceptance-matrix-v1.md
T
鲨鱼辣椒 694c4317a3 checkpoint: complete recoverable V2 pre-separation baseline
Complete the selective V2 checkpoint with its minimal AgentBus, object-storage, replay persistence, and validated-workbench shared dependency closure.
2026-08-20 17:09:00 +08:00

7.5 KiB
Raw Blame History

BR00 业务类型 contracts-v1 验收矩阵(已由 Booking Business Agent v1.0 取代)

项目 内容
文档状态 历史候选材料;不得作为新 Layer 5 权威规则或业务验收结论
业务基线 BR00-BASELINE-1
契约版本 booking-contracts-v1
目的 把业务理解、契约、实现切片与验收证据对齐;不是旧 V4 卡片清单的替代品

新 Layer 5 的唯一业务规则见 Booking Business Agent v1.0。本矩阵保留用于 追溯旧 BR00 样例;其中 Payment、同 Tour Code 合并、生命周期位于 Layer 5、Rooming List 宽泛识别、 Allotment 库存/聚合等描述均已过时。

1. 共同判定规则

  • 只由 current 邮件正文、当前附件和明确当前指令触发业务。quoted history 只用于理解、继承身份和重复提示。
  • Name of Group、Group Name、Tour Code、Group Code 都是同一订单业务标识的来源别名,统一标准化为唯一业务字段 group_code;不得把同一值拆成多个身份字段。group_name、tour_code 仅保留历史兼容读取或来源镜像,不能作为第二个目标。
  • group_code 与 name_values 对所有渠道、FIT/GROUP 都是独立字段:name_values 只保存真实入住人/客人姓名;缺少姓名时保持空,禁止用任何团号来源别名补值。多个来源别名同时出现且值不一致时必须复核,不猜优先级。
  • FIT 与 GROUP 的 Room Information 都展示 canonical Group Code 和至少 Name 1、Name 2 两个姓名位置;只有一个姓名时第二位为空,多于两个姓名时不得截断。两类订单在这组字段上的主要视觉差异仅为 Booking Type 标签。
  • 已知业务但字段缺失:保留原业务类型进入复核;不降格为 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 路径读取。