2695 次代码提交

此分支

此分支

所有分支

作者	SHA1	备注	提交日期
lc和Claude Opus 5	3aa5242ab9	docs(7510): Changelog 路径迁移为 12_ 并登记 11_ 兼容别名 Refs #7510 ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UqNs52DGnGU29PN8Ey37Ms	2026-09-12 10:35:51 +08:00
lc和Claude Opus 5	fb7a6af37b	docs(7510): 服务按景区口径接入供应商关系 Changelog（supplierFullName / 原因可省略 / 395063）Refs #7510 ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UqNs52DGnGU29PN8Ey37Ms	2026-09-12 10:29:11 +08:00
jw和Claude Opus 5	4656428473	docs(order-v3): #7527 团期发起核单端点（TRIP_FINISHED → REVIEWING） ... 新增 POST /v3/admin/order/group-batch/{groupBatchId}/review/start。 补的是「团期卡死」的入口缺失：这一跳此前唯一入口是录共享成本的副作用， 不用大巴、没请导摄的团没有成本可录就没有触发点，永久停在「出行完毕」， 八桶看板的「核团中」桶对这类团恒为空。 面向 hl-ui 写清三件事：① 重复点击返 200 而非报错，必须看 data.alreadyStarted 区分「真的推进了」与「幂等命中」，否则会连弹两次成功；② 三个新错误码 589564/589565/589566 各对应不同的下一步动作（等团回来 / 去做验团反确认 / 这团已流团），给了逐条的前端提示建议，其中 589565 要带反确认跳转； ③ 录成本自动推进的老行为一行未改，两条入口并存，前端现有调用不需调整。 权限码复用录成本那一个（group-batch:finance:advance），按钮可见性判据可直接复用。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-12 10:26:15 +08:00
jw和Claude Opus 5	79186364b8	docs(order-v3): #7537 管理端展示订单号的响应体统一补团号（teamNo） ... 11 个 /v3/admin/** 端点响应体纯增 teamNo：退款详情/列表、支付分页/详情/按订单、 工单分页/详情三块新增字段，订单待办 4 个写端点补上此前恒 null 的填充。 面向 hl-ui 写清四件事：teamNo 是订单团号 order_main.team_no（26-0001），不是运营 团期号 batchNo（GB-26-0001）；为空一律 null 不返空串不回退订单号；生成条件是订金 支付成功、与是不是团期单无关（已付订金散客单有、未付订金团期单没有）；同团每张 子订单团号各不相同，别按团号归并。 另记 4 个 /v3/internal/ 端点连带多出该字段（服务间调用，前端不对接）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-12 09:15:46 +08:00
Mimingguang	a0d72720a6	chore(changelog): 7526 前端交付回写 verified ... 团期物料门复判与兜底重扫:hl-admin 36c9064a 在团期详情页 onContractActionSuccess 补 fetchDetailSafe 重拉主详情,出具/签署触发物料门 自动推进时状态立即刷新。frontmatter 翻 verified + owner + ref + status_note。	2026-09-12 07:46:16 +08:00
jw	37904dc20f	docs(changelog): 团期物料门复判与兜底重扫（#7526 / PR #7559） ... 新增 2 个端点： - POST /v3/admin/order/group-batch/{groupBatchId}/recheck-material-gate（运维手工复判，未推进时回执指明挡门原因） - POST /v3/internal/jobs/group-batch-material-gate/run（服务间，Quartz sys_job 1044 经 Feign 触发，公网网关不放行） backend deployed + gateway verified，TEST 2026-09-12 实测： 事件路径 03:37:09 管理端动作 → 03:37:10 团期推进；Job 路径 cron 03:27:00 自行触发，sys_job_log 1044 SUCCESS。	2026-09-12 07:29:45 +08:00
Mimingguang	6827c24324	chore(changelog): 7445/7446 前端核验 not_required 回写 ... 7445 团期用车结算闸(584131+VEHICLE 软预警)与 7446 住宿结算闸判团口径 (584130 判据修正),经 grep 实证 hl-admin 前端均零改动: - 前端无按码分支,request.js 通用 bizError 兜底透传后端 message 原文, 584131/584130 文案已含订单号+需求状态+操作指引,透传即达标。 - detail.vue warnings 渲染只取 item.message 且兼容过渡期字符串,从不读 settlementId/dayNumber 定位明细行,category=VEHICLE 项(恒 null)正常展示。 - 7446 契约一字未变仅触发人群变化,前端对 584130 无专属处理不受影响。 frontmatter 翻 frontend_status=not_required + owner=mmg + status_note 追加, 无业务 commit,ref 留空。	2026-09-11 19:20:10 +08:00
API Changelog Bot	251748d813	docs(7445,7446): 两份交接件补网关实测结果，gateway_status 转 verified Refs #7445 Refs #7446 ... 两单的 §八「测试环境已验证」原先都写着「本节当前为空，网关实测尚未进行」， frontmatter 的 gateway_status 卡在 pending、pre-push 校验器报 E_GATEWAY_PENDING。 2026-09-11 网关实测已完成，本次把结果写进两份交接件： - #7445 四组（17:38 三组 + 18:36 补一组）：团期单 + 用车 PENDING → 584131； 推 DONE → 200；散客单两类需求都 PENDING → 200（两闸均不误触发）； 车费派生行全部软删 + 需求 PROCESSING → 仍 584131 - #7446 四组：方向甲 + 住宿 PENDING → 584130；推 DONE → 200； 待回填老单（product 非空 + group 为空 + 团期存活）→ 仍 584130；散客单 → 200 两份都如实写明了两条取证边界，不许读的人误推： 1. 全部前置都是 SQL 直更造出来的（直接改需求 status），不是走真实配车/配房链路产生的 2. 取证路上绕过了三道与本单无关的通用前置闸（584310 八分类未确认、584082 待收尾款、 车费草稿冻结确认），手段是 SQL 标 CONFIRMED / 清零应收；这三道闸自身的正确性未被验证 gateway_status pending→verified、verified_at 填 2026-09-11、status_note 改为如实描述。 frontend_status 保持 pending 未动。	2026-09-11 18:58:29 +08:00
Mimingguang	98665c3a20	chore(changelog): #7509 前端交付回写 verified(mmg,hl-admin 64573356)	2026-09-11 18:14:35 +08:00
lc和Claude Opus 5	a28a67887f	docs(7509): 酒店按景区口径接入供应商关系 Changelog（supplierFullName / 原因可省略 / 395062）Refs #7509 ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UqNs52DGnGU29PN8Ey37Ms	2026-09-11 18:00:02 +08:00
API Changelog Bot	5a5ca03e0f	docs(7440): 交接件补 4 个改造接口 + 双侧未读取法 + 会话键不混同 Refs #7440 ... AC-19 要求的三块内容原先在文件里 grep 零命中，校验器也只解析出 4 个端点： - 新增「改造接口」4 节（messages 拉取/投递、read 双侧水位、biz-unread-batch 新增 TEAM_FLEET 取值），每节含方法/路径/路径参数/请求参数/响应/错误码 - 写死「双侧未读要分别取」：车务侧传 unreadScope=TEAM_FLEET、团期管理员侧传 TEAM， 传错不报错、会拿到对方的未读数 - 写明 GROUP_FLEET:{groupBatchId} 与「接送机沟通仍走 FLEET:{orderId}」，两个入口不混同 - 两条 internal 接口的清单编号由 *内部* 改为裸 5/6——校验器对非裸编号的端点标题 是静默跳过的，改前它们根本没进校验 - 补错误码汇总表（281018/281019/600012-600014/809400/809401，文案逐字抄源码） - 六.6「修改前后对比」由 N/A 换成 4 个改造端点的行为级对比 端点数 4 → 10（6 新增 + 4 改造），与工单口径一致。 另留痕一处信源冲突：biz-unread-batch 的 adminId，工单正文写「PERSONAL 时必填」， 而 ChatBizUnreadBatchReqVO.java:23-25 是 @NotNull（恒必填，与 unreadScope 无关）。 交接件按源码写，并在字段说明里标注与旧文档描述不一致、以源码为准。	2026-09-11 17:31:04 +08:00
API Changelog Bot	274f0b16c0	docs(changelog): #7440 订正六.8 节角色授予范围——ADMIN 已被 #7514 收回 ... 原文写「菜单可见性授予 SUPER_ADMIN / ADMIN / VEHICLE_MANAGER 三个角色」「权限码 授权 VEHICLE_MANAGER / ADMIN / SUPER_ADMIN」，这两句在 PR #7514 之后已经过时： V20260911_007__fix_group_dispatch_admin_grants.sql 于 2026-09-11 14:04:26 在测试库 收回了 ADMIN 的菜单行（2 行）与权限码授权（1 行），部署后实测两项命中数均为 0。 收回的原因本文件八节末尾那条红字早就写着：/admin/fleet/** 的访问控制是 #5626 的 路径级粗粒度角色门禁，只放行 VEHICLE_MANAGER 与 SUPER_ADMIN，不看权限码。给 ADMIN 菜单等于造一个看得见、点进去必 403 的死入口。也就是说本文件自身前后矛盾——六.8 节 说 ADMIN 有菜单，八节说 ADMIN 调接口必 403。现已统一到后者。 接口契约、错误码与行为均未变，仅授权数据层的描述订正。frontmatter 补 status_note。 前端影响：不要按「ADMIN 能看到团期配车」设计任何菜单可见性或路由逻辑。	2026-09-11 15:07:07 +08:00
Mimingguang	8accfb3a61	chore(changelog): #7500 前端交付回写 verified(mmg,hl-admin 7d7cf020)	2026-09-11 14:46:14 +08:00
lc和Claude Opus 5	0c30d2c966	docs(changelog): #7500 游玩项目按景区口径接入供应商关系 ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CKcJu3x9Ct9LutqH7AMjJb	2026-09-11 14:28:56 +08:00
API Changelog Bot和Claude Opus 5	78ddcae40e	docs(changelog): #7440 团期车务派单只读入口——看板三端点 + GROUP_FLEET 双团会话（已部署实测 861ebff0c） ... 6 个新接口：fleet 派单看板三个 admin 读口 + order-v3 两个 internal 读口 + user-service open-group-fleet。本单只读，不含配车写入与派单进度回写。 错误码 7 个：809400/809401（order-v3 内部口自用，经 fleet 侧 fail-closed 统一转 600012， **前端看不到原始码**）、600012/600013/600014（fleet 对外）、281018/281019（会话侧）。 809401 把「分页越界 / 出发日区间倒挂 / keyword 超 50 字符 / dispatchProgress 枚举非法」 合并为一个出口，前端按单码统一提示重填筛选条件。 ⚠️ 访问控制口径：三个 fleet 读口由 #5626 的粗粒度角色门禁把关（必须切到 VEHICLE_MANAGER 或 SUPER_ADMIN），**不看权限码**。实测 ADMIN 角色（已被本单 Flyway 授予 fleet:group-dispatch:view）同样拿到 403，前端不能按「有该权限码就能调」设计。 测试环境已验证：三服务已部署（fleet/order-v3 @ 861ebff0c、user @ 30761683e，差异原因与 契约一致性核验见正文），6 端点逐个网关实测、每条两轮。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-11 13:24:48 +08:00
Mimingguang	6a6c167b69	chore(changelog): #7325 status_note 补 hotelReady 组合态提示前端交付(740e7941)	2026-09-11 11:47:00 +08:00
API Changelog Bot和Claude Fable 5.1	67cb933c76	docs(changelog): #7325 补 808611/808612/808613 与 hotel_ready 组合态提示口径 ... #7325 的 AC-21 字面要求 changelog 覆盖这三个码的文案与 「hotel_ready=false ∧ 有 CONFIRMED 行」的提示口径，首发时漏了： 808611/808613 全文零命中、808612 只出现在测试记录表格里。 三个码属 #7324 的段位但三个新端点都会返回（归属门在编排层前置）， 前端只按本单新增的 8 个码做分支会漏掉最常见的三种拒绝。 顺带填 target_release=hl-ui@d487d2be：50c0e53 把 frontend_status 置为 verified 但 target_release 仍为空，校验器规则「verified 必须填写 target_release」会让该文件此后任何编辑都推不上去。取值来自同一份 frontmatter 的 frontend_ref，不是猜的版本号；mmg 若有正式版本号请覆盖。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-11 11:28:53 +08:00
Mimingguang	50c0e53c52	chore(changelog): 回写 #7324 接线闭环 + #7325 前端 verified(d487d2be)	2026-09-11 11:17:31 +08:00
API Changelog Bot和Claude Fable 5.1	c5b40bb83e	docs: 答复前端 #7324 后端需求（后端零改动）+ 补 #7322 我的团不过滤 batch_status ... 前端据 H1 看板过滤 CANCELLED 的行为，推断「整团释放」按钮无可达路径。 该推断的关键环节不成立：我的团（GET /v3/admin/order/grab-pool/my-claims/ group-batches）刻意不按 batch_status 过滤，H2 详情也没有阶段闸门， CANCELLED 团期经「我的团 → H2 详情」完全可达。 根因在我方：#7322 的 changelog 从未写过这条行为，前端看不到 javadoc。 本次一并补记，并在需求单上答复 status=answered-no-backend-change。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-11 10:39:30 +08:00
API Changelog Bot和Claude Fable 5.1	65d786ea87	docs(changelog): #7325 团期房务按日订房确认 H7/H8/confirm-check（已部署实测 dfd5a8f6f） ... 3 个新端点、8 个新错误码、808616 删除、808602 日期上限改为 endDate-1。 已部署测试服并经网关实测，Flyway V20260910_302 success=1。 起草时「GET /confirm-check 任何后台角色都能调」写错，已更正： 读端点虽不标 @HouseWriteGuarded，但在编排层入口直接调 HouseReadGuard.assertHouseReadPermission()，非房务角色同样 808090。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-11 10:37:49 +08:00
Mimingguang	559c8da1c1	docs(changelog): #7324 status_note 补后端需求文档交叉引用(4aa3037)	2026-09-11 10:06:50 +08:00
Mimingguang	4aa3037c3c	docs(backend-request): #7324 放开 H1 看板 batchStatus 对 CANCELLED 的过滤 ... 前端 #7324 已交付整团释放写口(commit 6710ad4a),但 H1 列表忽略 CANCELLED 过滤导致已流团团期进不了看板、释放按钮无可达路径。写明需求/现状/期望/ 安全性供后端评估排期:放开 H1 对 CANCELLED 过滤(推荐方案 A),前端零改动等待。	2026-09-11 10:06:06 +08:00
Mimingguang	1e52ba5d26	chore(changelog): #7328 frontmatter 回写 verified(0f2f5b1a)	2026-09-11 10:01:17 +08:00
Mimingguang	b0c68caa15	chore(changelog): #7324 frontmatter 回写 verified(6710ad4a)	2026-09-11 09:23:16 +08:00
Mimingguang	cad8452b92	chore(changelog): #7387 前端交付 verified(ref 620754fc)	2026-09-10 22:35:45 +08:00
lc	95d1789793	docs: 交接餐厅供应商关系契约（#7387）	2026-09-10 22:18:14 +08:00
API Changelog Bot	70dbb833e0	docs(changelog): #7328 团期房务整团会话 GROUP_HOUSE（三端点） ... 会话键是 GROUP_HOUSE:{groupBatchId}，按团期聚合主键建键而不是子订单 id—— 这是与既有 GROUP:{orderId} 的关键差异，前端拿错主键空间会静默查空 （不报错、只是永远没数据）。 三处前端按直觉写会踩的地方，都写进「关键变化」： 1. 团未被认领时的不对称：管理员侧能开会话（消息落团队池，认领后自动改判 给认领人），房务侧开不了（281002）。 2. peerAdminId 在两个接口上语义不同——这条是部署实测才发现的。 open-group-house 的响应直接回显 DB 占位值 0（ChatManager.buildFullResp 无归一化）；把「无认领人 → null」做归一化的是会话列表那条路 （fillOrderSummaries + fillGroupBatchSummaries），而且只对有消息的会话 生效——selectMyConversations 用 isNotNull(last_message_at) 把无消息的 占位会话过滤掉了。前端照单接口响应判 null 会渲染出「管理员 #0」。 3. currentClaimerId 刻意没有 @NotNull：RELEASE 事件本来就没有新认领人， 加了会让释放事件在参数校验阶段被拒、会话永远停在旧认领人身上。 顺带订正一条长期口口相传的错误说法：网关对 /internal/** 并非「一律 403」。 gateway 只给 /v3/internal/** 与 /internal/fleet/** 配了 Path predicate， /internal/message/** 与 /internal/house/** 根本没有路由，请求在到达 JwtAuthFilter 之前就被路由层拒掉，返回的是 HTTP 200 + 业务体 {"code":404,"message":"接口不存在"}。净效果一致（网关不可达），呈现不同。 backend_status=deployed：两服务已滚到 dev-v3 tip 0f62fb072（PR #7490）， 实例 LISTEN + Nacos healthy，三端点各打通，281002 负向用例四个角色全命中， 落库 conversation_key 已用 SQL 证实，测试数据已清理。 Refs #7328	2026-09-10 21:59:00 +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
Mimingguang	1f48714187	chore(changelog): #7456 前端 no-op 回写 not_required	2026-09-10 18:21:26 +08:00
jw	6c62b1aa2b	docs(changelog): #7456 团期生命周期后半段——核团开工自动推进 + 验团归档 + 反确认	2026-09-10 18:10:23 +08:00
Mimingguang	6fee8114b8	chore(changelog): #7455 前端 no-op 回写 not_required	2026-09-10 18:01:41 +08:00
jw	953d953bdc	docs(changelog): #7455 团期十五个 admin 端点补判权（写口 manage / 详情名单 view / 列表看板 list）	2026-09-10 17:56:28 +08:00
Mimingguang	7ecd4da276	chore(changelog): #7322 前端交付 verified(ref 745cd9b8)	2026-09-10 17:19:23 +08:00
API Changelog Bot和Claude Fable 5.1	4a284f6323	docs(changelog): #7322 菜单种子已落地（PR #7467），补部署两条注意事项 ... sys_menu 两行抢单池入口已由 V20260910_001 补上。 部署须知：#7322 部署清单本次起必须带 hl-user-service； 菜单树按 roleId 缓存 Redis（TTL 3600s），部署后需 DEL cache:menu:tree:role:*。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-10 16:06:07 +08:00
API Changelog Bot和Claude Fable 5.1	7b1601a7c2	docs(changelog): 补全 #7316 的订正——第四节仍有三处「无权限码限制」与已订正段落自相矛盾 ... 688c403 只订正了 :182 / :259 / :383 三处，同一文件里另有三处原样保留： - :215 请求示例的 Authorization 头写「任意已登录管理端 token，无需 group-batch:view」 - :284 契约表行「✅ 任意已登录管理端角色调用」 - :288 「本端点无权限码限制」 其中 :284/:288 落在「四、契约约束与正确调用方式」——正是 mmg 据以实现判权与 589507 兜底的那一节，照它实现会完全不处理 589507，危害最大。 三处均已改为现行口径并标注订正日期，另补一条前端提醒： FINANCE 角色持 finance:view 但不持 finance:advance，写端点按钮需单独控显隐。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-10 15:47:31 +08:00
API Changelog Bot和Claude Fable 5.1	d807fad55f	docs(changelog): #7322 团期整团抢单与抢单池分流（前端契约交接件） ... 五个新端点（抢单池列表/认领/释放/接管/我的团）+ 五个既有端点改造。 团单户不再进逐户抢单池，改以整团为单位认领；order_group_batch 新增 house_claimer_id / house_claimer_name / house_claimed_at 三列（Flyway V20260910_301 已执行）。 已部署测试服 HEAD 6d41d6148，32 条验收项中 28 条已取证， 含用 5 个真实登录账号过网关实测的归属与接管链路。 ⚠️ 正文已注明一项尚缺的交付：sys_menu 的两行抢单池菜单入口尚未随迁移落库， 在补上之前新端点只能直接调用、后台菜单里点不到。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-10 15:43:36 +08:00
Mimingguang	5cdf062dd2	docs(changelog): #7232 frontmatter 回写 EXPENSE 付款字段勘误前端修复证据	2026-09-10 15:42:42 +08:00
Mimingguang	41160bbfad	docs(changelog): #7411 frontmatter 回写 not_required	2026-09-10 15:32:32 +08:00
API Changelog Bot和Claude Fable 5.1	6cfa38b56d	docs(changelog): #7411 团期核单共享成本三端点补判权（前端契约交接件） ... 三端点权限码： - GET /v3/admin/order/group-batch/{groupBatchId}/settlement/summary → group-batch:finance:view - GET /v3/admin/order/group-batch/{groupBatchId}/settlement/cost → group-batch:finance:view - POST /v3/admin/order/group-batch/{groupBatchId}/settlement/cost → group-batch:finance:advance 不持码返 589507，HTTP 恒 200，前端判 Result.code。 请求与响应结构一字未改，网关零改动（/v3/admin/** 已通配）。 已部署测试服 HEAD 6d41d6148，四档权限矩阵经真实登录态过网关实测， 无权限 POST 已用 SQL 前后对比证明零副作用。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-10 15:26:39 +08:00
yaosutu	be7415b771	docs(finance): 更正 7232 changelog §10 出纳付款登记入参字段名勘误 ... 前端联调反馈 cashier/pay bizType=EXPENSE 报 400 出账账户不能为空/付款金额不能为空。 经测试服实调实证：后端 cashier/pay 为全 bizType 统一扁平入参，付款账户/金额字段名 固定为 payAccountId/amount（@NotNull 文案与前端 400 逐字一致），changelog §10 误把 输出字段名 fundAccountId/actualAmount 写进了请求入参表，前端据此调用触发校验失败。 更正内容（§10）： - 入参表 fundAccountId→payAccountId、actualAmount→amount，并补全量必填字段 payDate 等 - 变更点说明补「回写列名非入参字段」澄清 - 新增请求/成功响应示例（可直接照抄） - 598602 错误文案对齐实测「业务单状态非已批准，不可付款」 - frontmatter status_note 追加勘误说明 + updated_at 升 2026-09-10 验证（测试服，FY-202609100001）： 错误字段→复现 400；正确字段 payAccountId/amount→付款成功 LS202609100002、 余额 114894→114594、报销单回写 PAID+fundAccountId+paidAt、重复付款 598602 防重拦下。 Refs #7232	2026-09-10 15:19:23 +08:00
Mimingguang	4281aa8aca	docs(changelog): #7390/#7347 frontmatter 回写 not_required	2026-09-10 15:09:21 +08:00
API Changelog Bot和Claude Fable 5.1	688c403695	docs(changelog): #7347 finalize 团期住宿户级闸门 + #7390 孤儿持有行自动收敛；订正 #7316 的「无权限码是既有设计」 ... #7347：整单核单 finalize 新增团期住宿户级硬闸门，新增错误码 584130。 存量统计 SQL 结果为 0，全量生效不做灰度。 #7390：双写扣减孤儿持有行自动收敛，解开重新提交配房恒抛 808902 的死锁。 显著标注「本单不修根因」——submitPersist 仍在 try 块外，孤儿行仍会继续产生。 #7316 订正三处：原文写「本端点无权限码要求……这是既有设计」， 那不是设计而是 #7411 要修的缺陷，已改写为发布时点的事实陈述并指向 #7411。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-10 14:56:19 +08:00
Mimingguang	3370e7a278	docs(changelog): #7389 frontmatter 回写 not_required	2026-09-10 12:06:07 +08:00
API Changelog Bot和Claude Fable 5.1	9b67d6f4f0	docs(changelog): #7389 多夜配房释放改逐夜回补 + resource 库存账本告警码拆分 ... PR #7423(合并提交 f5545b148)已合入 dev-v3,测试服 order-v3/resource-service 均已滚动部署。 本单无接口/字段/表结构变化,仅记录:1) 多夜配房释放由只补首夜改为逐夜回补;2) resource 房务库存账本内部一致性告警从共用 310404 拆分为 310417-310420 四个语义码。 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>	2026-09-10 11:58:02 +08:00
Mimingguang	b165e41337	docs(changelog): #7164/#7165/#7217/#7232 frontmatter 回写 verified	2026-09-10 10:38:39 +08:00
Mimingguang	38a6cf5434	docs(changelog): #7323 frontmatter 回写 not_required	2026-09-10 10:05:26 +08:00
API Changelog Bot	5eff130bf2	docs(changelog): #7323 团期房务地基——配房提交新增可选 replaceReason ... PR #7413（合并提交 1a3d3c43f）。本单为地基单，不新增/下线端点、网关零改动。 对前端唯一直接可见的变化是核心配房提交端点新增可选字段 items[].replaceReason， 语义为「仅记首次、不覆写」——重复提交同一配房不会更新已落库的原因文案。 另附一条实测发现的既有文档缺口：items[].arrange 实际会返回 inquiring， 而 Swagger 只列了 pending/waiting/confirmed/problem，提醒前端做兜底分支。 已部署测试服并经网关四步实测，DDL 已 SHOW CREATE TABLE 逐列比对零差异。	2026-09-10 09:40:34 +08:00
Mimingguang	92eb0956a8	docs(changelogs-v2): #7199 前端 not_required	2026-09-10 09:27:08 +08:00
Mimingguang	bdeaa623ed	docs(changelogs-v2): #7378 前端 verified (hl-admin ref 4d016870)	2026-09-10 09:24:14 +08:00