4 次代码提交

包含重命名

作者	SHA1	备注	提交日期
Mimingguang	559c8da1c1	docs(changelog): #7324 status_note 补后端需求文档交叉引用(4aa3037)	2026-09-11 10:06:50 +08:00
Mimingguang	b0c68caa15	chore(changelog): #7324 frontmatter 回写 verified(6710ad4a)	2026-09-11 09:23:16 +08:00
API Changelog Bot	d9f30eb9bf	docs(changelog): #7324 订正 H1 住期筛选的区间口径（右开 → 两端闭） ... 原文把 stayDateFrom/To 的匹配范围写成团期 `[出发日,结束日)`，右端开区间是错的。 实际谓词是 `depart_date <= stayDateTo AND end_date >= stayDateFrom` （GroupBatchMapper.selectHouseClaimedPage:779-791），两端都闭。 实测：团期 end_date=2026-07-05 配 stayDateFrom=2026-07-05 命中。 前端照右开写日期选择器会漏掉最后一天。 同一份文档里 H4/H5 校验入住日合法性用的 `[出发日,结束日)` 是**对的**、不动 （assertStayDateInRange:568-575，`!stayDate.isBefore(endDate)`， 结束日是离店日不产生间夜）。两处口径本就不同，已在表格里写明区别，避免混用。 Refs #7324	2026-09-10 19:12:28 +08:00
API Changelog Bot	fc6f223419	docs(changelog): #7324 房务团期看板与整团按日订房计划 CRUD（H1-H6 + release-all） ... 七个新端点的前端交接件，重点写清四处「后端行为对、前端按直觉写会踩坑」的地方： 1. H1 列表 total 可能是 -1，语义是「未统计」——传 planStatus 且扫描页(500)被填满时 走内存过滤降级路径。全仓其它分页都保证 total >= 0，直接拿它算总页数会出负页码。 2. H5 只传 version 的空提交：PENDING 行返 200 且只把 version +1（updateById 默认 NOT_NULL 策略，null 不进 SET 子句，不清空任何业务字段），CONFIRMED 行抛 808692。 3. release-all 会返回「200 但什么都没释放」——整团都是过去的已确认行时， releasedPlanIds 为空、retainedPastPlanIds 非空、warnings=[PAST_STAY_RETAINED]， 与「团里根本没订房」的 808619 幂等出口是两条不同分支。 4. H4 响应恒带两个空数组 warnings / removedManualAllocIds（与 H5 共用 RespVO）。 另记两条与工单口径不一致、以源码为准的事实： - 错误码实际新增 17 个（工单写 12 个），已按 HouseGroupBatchErrorCode 逐个列出。 - 部署顺序：hl-resource-service 必须先于 hl-order-service-v3，反序会让 order-v3 拿到 roomCategory=null，fail-closed 房型守卫把每次 H4/H5 提交拒成 808691。 Refs #7324	2026-09-10 18:50:32 +08:00