6.4 KiB
新建预订附件接续 CP16
状态：2026-09-16本地实现及验证完成。承接CP12实际创建编号、CP14共享客档、CP15有据字段和CP9来源记录。默认执行器仍Pending，整个GROUP/FIT四流程尚未接通。
本次行为
员工原确认保持不变。只有同次新建清单中的全部Block/Reservation都已保存实际编号，才准备附件计划。邮件中的单份Excel原件会传到每个实际父对象，Name和Description均为Tour Code。NEW上传固定overwriteExistingFileYN=N，不覆盖、替换或删除任何旧文件；UPDATE仍走CP11替换流程。
系统先查询全部父对象和附件列表，排除同名冲突、缺对象或错误Note，再发第一笔上传。每笔上传使用固定调用键和原请求摘要；保存实际附件编号后，重新查询其父对象、附件清单及原文件内容，核对名称、说明、酒店、非全局属性和字节摘要。成功上传后查询失败，仍保留已保存的上传事实，不显示为“什么都没做”。
恢复时只查询已保存的实际附件编号。没有可靠回执的未知上传，不通过同名、相同内容或改调用键重新认领/上传；明确NOT_SENT才允许后续受控attempt用同键重试。多笔FIT部分成功时保留已知部分，剩余部分不掩盖成功事实。并发执行者使用同一执行行锁和调用键，一份原件在同一父对象只发送一次。
内部实现与数据边界
| 模块 | 职责 |
|---|---|
| HotelNewBookingAttachments | 不可变附件计划、目标及内部结果；当前查询观测和已存写回执分开 |
| HotelNewBookingAttachmentRepository / JdbcHotelNewBookingAttachmentRepository | 在原执行锁内检查完整创建清单、共享Guest、原确认/租约、历史调用与来源，冻结V47计划并提供严格发送守卫 |
| JdbcHotelBookingCreationRepository.completedInTransaction | 在调用者事务中复用完整创建校验，只接受全部父对象已持久绑定且创建回执可查询的状态 |
| OhipNewBookingAttachmentAdapter | 事务外查询/上传；固定请求、全部目标预查、按实际ID和字节核对、查询恢复 |
| V47__create_hotel_new_booking_attachment.sql | 按execution_id保存唯一计划，外键指向V45创建记录；UTF8二进制比较、InnoDB、UTC时间 |
V47保存原Excel内部引用/文件名/声明大小、实际父编号、初始附件元数据摘要、内容/请求/先前调用摘要；不保存文件字节、原Note、附件URL或凭据。实际计划比较包含原确认/完整创建清单/共享Guest绑定/全部父绑定，不能另传目标编号。先前Note来源必须匹配原邮件、酒店、环境与服务地址；已保存上传来源也检查executionId及sourceMessageId。HTTP在数据库事务外，reserve及发送许可校验在同一短事务内。
适配器仅显式构造，不注册Spring运行Bean。NEW附件必须使用仓储提供的guardedCalls，通用CP5技术journal不是本流程的授权入口。每次读取固定计划和发送前都重验执行上下文；最终结果收集若发现上下文失效，必须降为UNRESOLVED，不得吞掉错误返回VERIFIED。Result.businessComplete恒false，VERIFIED仅说明本次计划的附件内容核对完成，不代表全部预订业务完成，也未直接接员工页面。
FIT Note与限制
FIT附件阶段沿用创建Reservation时保存的BUSINESS_NOTE来源和实际Note子编号，查询该子编号原文摘要是否仍相同；不重写Note，不按文本猜一个编号。若创建回执缺实际Note编号，即使后来能查到同文Note，也停在NEW_ATTACHMENT_NOTE_EVIDENCE_MISSING；本次未增加Note编号补绑机制。
当前技术入口只接单Excel，允许一个GROUP父对象或多个FIT父对象。多Excel会在计划首次保存/任何附件上传前停止；这不取消“上传邮件全部Excel”的用户要求。多份同名Excel的原生命名、内容及替换契约尚待核对。固定linkType须来自已验证目标环境配置；代码不猜配置值。先前调用最多300条、各父附件初始清单最多4000条，超过界限拒绝不截断。
本次不保证先前已成功的所有预订字段直到最后均未变化；附件阶段只进行父对象身份、FIT原Note及附件检查。整个流程仍需独立最终查询全部业务值。精确Note编号缺失的恢复、多Excel、FIT TA recorder准确REST写入/读回、Meal/餐厅、GROUP完整写入、UPDATE完整范围与最终员工回显、目标环境权限配置及原生UAT仍未完成。CP15的ATTACHMENTS缺口不能仅据CP16局部验证就全部移除。
验证与运行边界
- 新增48项真实H2仓储＋localhost HTTP测试；V41/V42/V43/V45/V46/V47只在临时测试库应用。覆盖GROUP、共享Guest的两笔FIT、精确父/子ID、原件/来源/计划/租约变化、创建/上传编号缺失、未知及NOT_SENT、多目标部分成功和已保存回执后的中断恢复。
- 两个执行者在真实reserve之前用并发屏障同时竞争，断言各父对象只有一次POST；首次prepare前篡改Note服务地址，断言明确错误、V47未保存且零上传。多Excel从原确认即存在，单独验证输入数量门槛。
- 已保存成功回执后来源加载器抛异常、最终上下文失效或查询失败，仍保留已知写入事实；不伪造当前查询结果。列表/内容/父对象错位及Note编号变化阻止继续。
- 相关247项通过；完整Maven verify 2131项，2115通过、16既有条件跳过，223份报告，零失败/错误。实际JVM26.0.2，编译release17；未声称Java17运行时或实际MySQL/Oracle验收。
- 1名已获许可的只读子智能体复核，发现的最终结果降级、来源地址/邮件校验及部分成功保留问题已修复并覆盖；最终复核未发现新实质问题。它未改文件、运行测试或操作酒店。
- 无酒店、邮件、凭据或公开目录调用；无真实数据库迁移、运行加载/重启、平台修改、提交推送或部署。CP13/14平台候选仍未发布；CP15最后观察的公开目录0.6.0，本次未重新查询。
下一步按独立checkpoint接完整办理与最终实际值回显，并补齐上述契约和多Excel缺口；继续前恢复本记录。增加子智能体需先向用户说明任务并获得本次许可。