Complete the selective V2 checkpoint with its minimal AgentBus, object-storage, replay persistence, and validated-workbench shared dependency closure.
7.5 KiB
7.5 KiB
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. 验收最低集
每个业务类型在实现完成前都必须至少有:
- 一个去隐私的 contracts-v1 正例与一个错误/歧义例。
- Parser、Agent(如适用)和 Validator 对同一输入的版本、evidence reference 与目标范围断言。
- PostgreSQL
th_hotel_booking的 processing run、候选、校验和确认投影持久化断言。 - 前端的展示/阻断/确认行为断言;确认后不产生 PMS/Opera、付款或部门副作用。
- 对应真实或脱敏 E2E 样例;真实邮件只通过 opt-in 路径读取。