OHIP客档创建与FIT多房 CP13

状态：2026-09-16本地实现及验证完成，未发布、未启用酒店执行。承接CP12。

本次结果

能力	当前状态
按确认Name/CN建立一个Guest	平台新增postProfile及消费固定协议已实现，原生UAT待执行
读回实际客档编号、姓名和国家	平台及消费端均核对实际响应；不一致不会报告已核对
创建中断与重复调用	平台固定幂等键，未知不重建，已知ID只重查
同住期同房型多间FIT	已按Oracle官方规则支持numberOfUnits=确认房数，仍每请求一条普通Reservation
工作台共享该客档继续创建所有FIT	客档ID在消费端的持久归属与编排尚待下一checkpoint
整单执行和最终回显	仍未接入默认执行器，businessComplete保持false

平台与消费边界

候选源码位置：工作区.planning/ohip-interface-review-20260915/platform-booking-release，基础提交56bbe8649c643a64022b989ee3137301e04d13fe，本次修改尚未提交/推送。候选目录0.9.0为119操作、14能力组；当日本次公开目录查询仍0.6.0且无postProfile。

平台新增POST /api/v1/profiles，独立profiles.write仅含建Guest，不含修改/合并/删除或任意读取。0008迁移仅扩已知能力约束，不增加应用授权或人员/代理上限。请求沿用原员工确认及稳定幂等键，固定Guest、单Primary姓名、单primary国家地址和配置酒店registeredProperty；拒绝未知字段、旧ID、批量及不匹配酒店。姓名原样置surname，最多40 Unicode码点，不猜姓/名、不截断。

原生201必须提供一个合法且同源或相对的/crm/v1/profiles/{id} Location。拿到ID后通过固定GET并带Profile、Address读取；查询核对唯一实际Profile ID、Guest、registeredProperty、Primary姓名/国家和完整单结果。未知创建不重POST，不按同名搜索猜认领；已接受/已验证的同键请求只查真实ID，正文变化冲突。

消费端新增CREATE_PROFILE固定路由和专用OhipGuestProfileConverter。HTTP读回有verified外壳仍须核对内层身份及字段，错误只返回固定码。该枚举没有加入OhipDurableWriteAdapter的业务stage许可，当前默认OhipPendingBookingExecutionAdapter不变。不能绕过后续持久客档归属步骤把协议层当成完整NEW入口。

FIT多房规则纠正

CP12的count=1是证据不足时的临时限制，不是用户规则。Oracle官方明确支持先保留一条多房Reservation，分房/入住前才拆分。因此CP13允许一个已确认房型/住期行的正整数房数与原生numberOfUnits完全相等，仍为一请求、一记录、单roomRates行、一个实际父ID，多请求须使用同一已备Profile。根批量关联指令、share/link相关字段即使为null也拒绝。

两种房型各3间的localhost测试实际收到两次POST、各numberOfUnits=3，保存两个实际父ID，未拆成六个预订。此结论不表示Oracle所有postReservation调用只返回一个ID：原生允许多记录集合，现平台创建取Location并读一个ID，批量仍未开放。

尚未拆分的同一Reservation，3→2应验证同ID的putReservation数量更新，无需引入自动取消。零房数、酒店已拆分记录、不同日分配及跨父重组不能套用本次正数单记录模式；这些情况不能猜取消或静默漏处理。numberOfUnits没有官方schema最小/最大值，酒店控制与权限决定上限；4000是记录集合上限，不是单预订房数上限。

验证与下一步

消费相关162项通过：Guest协议46、NEW持久恢复55、HTTP41、durable20。完整verify1,948项，1,932通过、16既有条件跳过、0失败/错误，220报告。编译release17，实际测试JVM26.0.2，未执行Java17运行时验证。
平台完整12包通过，405通过测试事件（含父测试与子用例）、9数据库条件跳过；race/vet及最终OpenAPI检查通过。0008真实PostgreSQL迁移未运行。
一位本轮获准子智能体只读核对Oracle多房定义，已结束；未进行代码评审代理、酒店操作或测试委派。
无真实酒店/邮件/凭据调用，无真实库迁移、重启、授权扩展、提交推送或部署。混合工作区其余改动保留，隔离patch在本地证据目录。

下一checkpoint：持久保存并固定Guest ID归属到原确认，恢复先查询，随后交给CP12共享同一Profile创建各FIT。继而接全流程写入/附件/Note/查询回显。原生UAT至少验证Guest回读、3间创建单ID、同ID3→2、日期房型变更、adults=2的实际多房含义；部署与权限/酒店配置、TA recorder精确映射、MySQL/PostgreSQL及Oracle验证仍需完成。

官方依据

Oracle 26.3多房与关联预订
Oracle 26.3修改住期及Rooms
Oracle 26.3预订控制
固定CRM 26.3契约与RSV契约。CRM GET按官方example的profiles.profileInfo解释，目标租户仍须原生验证。

5.6 KiB Raw Permalink Blame History Unescape Escape