0 Fork 0

Files

T

verify / booking-verify (push) Has been cancelled

Details

补齐C1正文资料交付和C2配额分类规则，完善Proposal人工任务、固定图片过滤及邮件附件展示。
修正失败终态与恢复上限，增加关闭状态的通知组件，永久保留处理历史并完善筛选分页。
同步相关页面修复、迁移、测试和项目记录。

验证：后台复用同源码clean verify结果1155通过/10条件跳过；前端262项及生产构建通过；敏感资料和提交路径检查通过。

2026-09-10 17:01:39 +08:00

8.6 KiB

Raw Blame History

Proposal Allotment 对接说明

2026-09-10 会话页保留原表及引用

用户指出会话纯文本导致编号/房量错位后，从Proposal原任务入口进入的会话复用现有source-material读取确切body_html_raw，并使用与任务详情相同的净化规则。仅来源ID匹配的当前消息显示该原表/引用；其他消息、缺失上下文或无可用材料时保持原纯文。没有更改会话接口TEXT_ONLY提示、业务分类或多消息拼接，也不直接执行其html_body。刷新/返回、来源权限、版本和晚响应边界保持；235项检查及确切3表/全文比对通过，见证据。

2026-09-10 邮件会话返回任务详情

用户授权补齐原邮件入口的往返导航。Proposal详情打开会话时携带from_order_task_id/from_card_id及原category/search；会话顶部复用现有返回样式，回到准确任务卡。刷新后仍保留，不依赖浏览器历史或猜测邮件关联，来源参数缺失时不新增错误目标。全部待处理的all保留至返回列表，不误回人工处理。没有后端契约或办理状态改动；226项前端检查及5178实际往返验证通过，见证据。

系统与B的同一份已确认页面已统一加载到5178/8082；Agent配置启用及实际邮件全流程验证仍由相应任务继续。A交付阶段没有重启，B按用户确认完成加载。见发布证据。

2026-09-09 补充：任务对应版本的原HTML表格

同一 GET /api/reservation/order-tasks/{orderTaskId}/source-material 响应新增可空字符串 body_html_raw，只为已保存的Proposal任务提供；body_text、附件、来源编号及版本字段保持。
这是未经净化的原HTML，不是 html_body_sanitized。按任务回执确定的 ORIGINAL/DUPLICATE + 材料ID + SHA-256 读取同封邮件的确切载荷，原样保留全部单元格、空格和 rowspan/colspan；不读取Inbox当前HTML，也不选择最新重复投递替代任务原版本。
确切版本没有可用HTML时为 null，使用既有原文/附件查看；不从文本或其他版本重建表格。原始邮件会话入口继续保留，本次没有EML下载新功能。
B负责安全展示：先净化为被允许的文本与表格结构，再显示；不可直接将raw HTML交给 v-html/innerHTML。保留表格层级、td/th、有效跨行跨列与空单元格，移除脚本、事件、框架、表单、外部图片/样式/字体及其他活动内容，不允许邮件HTML主动请求外部资源。不要把原始HTML标记为sanitized。
沿用原文权限、酒店范围和原文读取审计，完成后原版本材料仍可访问。普通预订和来源通知的这个新增字段为空。
主项目与 proposal-allotment-integration-20260909 副本此前均无已验收HTML能力；本次成果同步到主项目，B从主项目复用，不从旧integration副本重复开发。

运行与候选包：B已统一加载。后台PID60001，前端PID45022保留；运行包位于server/var/local-replay/runtime/proposal-allotment-workbench-20260909/，SHA与下列候选一致。24+10张业务表指纹保持；A自身未启停。

候选JAR：th-hotel-server-0.0.1-SNAPSHOT.jar。
SHA-256：`4f461f67b1e10f344cefbd372bc4014361c028e9611409f9194bab6ca9a632ba`。
候选对照与变更源文件指纹；完整后台构建输入指纹。
定向62项通过；完整后台verify共1086项，1079通过、7条件跳过、0失败/错误。包含原始/重复投递精确版本、合并单元格/全文保持、无HTML、办理后保留、原文审计与权限/酒店回归。
以PID49370使用的`booking-rule-read-fix-20260909`运行包为基准：新增2个类文件、修改52个类文件，均归于已验收Proposal系统支持和本次HTML读取，共17份Java源文件；另仅构建时间信息变化。未删除文件，依赖、应用配置、数据库迁移等其他资源逐文件相同；Booking规则读取修复类及匿名类逐字相同。
没有额外未验收后台变动。候选包不含Agent平台配置启用或页面变更；B已结合页面检查结果完成统一加载。本轮未替代旧integration副本的源码，复用主项目及上列候选包即可。

页面办理约定

一封纯Proposal邮件显示一项“Proposal Allotment”，固定放入“人工处理”。无需普通预订、实际团号或唯一LTQ；编号及数量按原文查看，不新增填写表单。
沿用 GET /api/reservation/task-cards 的人工队列（card_status=REVIEW_REQUIRED）及 GET /api/reservation/order-tasks/{orderTaskId} 详情。
card_type、event_type 均为 PROPOSAL_ALLOTMENT；display_payload.processing_method=MANUAL。待办卡状态为 REVIEW_REQUIRED，正常来源检查结果为 validation_status=VALID、无缺字段错误，review_status=null。
binding.resolution_status=NOT_REQUIRED；订单及确认预订ID为空，basic_information=null、卡片 fields=[]。不要因此显示补充普通预订资料或绑定订单的要求。
内容使用既有 source_message_summary、display_information 和 GET /api/reservation/order-tasks/{orderTaskId}/source-material。原文、已保留表格、附件及邮件会话继续沿用现有查看入口；附件使用原有下载标识，不自行拼接外链。
待办卡 availability.confirmable=true、editable=false、reviewable=false。按钮含义为“确认已办理”；调用下述确认动作，不要调用补充资料/人工复核接口。

员工手动办理后调用：

POST /api/reservation/order-tasks/{orderTaskId}/cards/{cardId}/confirm

{
  "operation_id": "e4d52c9e-cd6c-4728-a0a4-69406af27f05",
  "version": 0
}

operation_id 每次办理生成UUID，重试沿用；version 取当前卡片版本。其他确认字段省略，不提交修改后的配额、Basic或团号。沿用现有确认权限、酒店访问检查和版本冲突提示。

成功返回刷新后的详情：卡片 CONFIRMED，记录 confirmed_by/confirmed_at；任务 COMPLETED 并移出默认待办。界面显示“已办理”，原文关联保留。重复提交不重复办理；此动作不会增减配额或写普通预订。

Booking Agent 结果约定

分类仍由Booking Agent选择，系统不根据标题、LTQ文字或缺失字段分类。沿用当前compact返回形式和名称，Proposal在 decisions 内返回：

{
  "contract_name": "booking-business-agent-compact-decision-v2",
  "ignored_direction": false,
  "decisions": [{
    "decision_ref": "P1",
    "business_type": "PROPOSAL_ALLOTMENT",
    "target_ref": null,
    "booking_type": null,
    "trace_items": [],
    "department_code": null,
    "rooming_ref": null,
    "linked_relationship_refs": [],
    "source_refs": ["X2"]
  }],
  "derived_actions": [],
  "risk_items": [],
  "unclassified_texts": []
}

source_refs 必须来自本次输入，至少关联当前邮件材料；示例X2表示本次正文，附件场景使用本次提供的材料引用。无需逐个返回31个/5个LTQ字段；同次返回多个Proposal选择也会集中成一项。个别数量没提取清楚时保留原文，不猜补、不以普通预订缺项生成风险。

系统的结果格式已增加该类型，内部任务格式已配套。配置任务已交付对应主提示词及Skill，用户已配置测试平台；实际C1/C2曾正确形成一项Proposal。随后发现现有候选表类型约束遗漏，V19及Layer6错误分类修复已加载5178/8082；同EML复验的一张Proposal人工任务已成功保存，完整12项原表和办理入口可见。本次Parsing另返错误格式，回放总状态仍失败，单独接续；业务规则和B页面设计保持。最新状态见实际回放与修复证据。

验收范围和验证结果见需求记录。

8.6 KiB Raw Blame History Unescape Escape