鲨鱼辣椒
694c4317a3
Complete the selective V2 checkpoint with its minimal AgentBus, object-storage, replay persistence, and validated-workbench shared dependency closure.
60 lines
7.5 KiB
Markdown
60 lines
7.5 KiB
Markdown
# BR00 业务类型 contracts-v1 验收矩阵（已由 Booking Business Agent v1.0 取代）
|
||
|
||
| 项目 | 内容 |
|
||
| --- | --- |
|
||
| 文档状态 | 历史候选材料；不得作为新 Layer 5 权威规则或业务验收结论 |
|
||
| 业务基线 | `BR00-BASELINE-1` |
|
||
| 契约版本 | `booking-contracts-v1` |
|
||
| 目的 | 把业务理解、契约、实现切片与验收证据对齐；不是旧 V4 卡片清单的替代品 |
|
||
|
||
> 新 Layer 5 的唯一业务规则见 [Booking Business Agent v1.0](booking-business-agent-rules-v1.md)。本矩阵保留用于
|
||
> 追溯旧 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 路径读取。
|