3054 次代码提交

此分支

此分支

所有分支

作者	SHA1	备注	提交日期
API Changelog Bot和Claude Opus 5	9a3d6a04a6	docs(changelog): 新增 #8202 车队字典校验与团期详情页3项前端待办的 changelog ... #8202/PR #8224 已合并 dev-v3(b439565be)并部署 TEST：用车需求提交/调整两条写路径 共用的车型大类校验新增车队活字典比对(582032/582033)，存量码582022不变； mmg v2.1(7df292624)已提前接入车型字典下拉。 另补团期详情页用车/用房面板3项纯前端待办(乘车户全选汇总/确认按钮布局/对话入口)， 经核实②④两项已在 dev-v3+v2.1 端到端实现，故仅收窄为①③⑤三项。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-23 11:08:43 +08:00
API Changelog Bot和Claude Opus 5	5397036b98	docs(changelog): 用房·汇总首屏必失败根因——同页两组件共用 requirement-summary 被去重取消（前端缺陷） ... wx 反馈团期详情「查看需求」Tab 的「用房·汇总」恒显示「汇总加载失败」， 同页其余区块正常、点刷新即好。 根因在 hl-ui：RoomSummarySection 与 VehicleSummarySection 在同一 tick 各调一次 getGroupRequirementSummary（同 method+url+params+data），而 src/api/orderV2GroupBatch.js:563-568 这个封装未传 cancelDuplicate:false， src/utils/request.js:260-275 用后发的 AbortController abort 掉先发的那条； 渲染顺序 Room 在前，被取消的恒是 Room，裸 catch{} 把 cancel 当失败吞掉。 后端与数据经测试服 nginx 访问日志（16 次全 200）、order-v3 应用日志 （全团需求汇总完成，零 ERROR）与只读 SELECT 核查，均正常，无后端改动。 建议主修 = RequirementTab 只请求一次经 props 下发；护栏 = 两个 Summary 组件的 catch 区分 ERR_CANCELED 与真实失败（路由切换 abort 同样会落进来）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-23 10:38:58 +08:00
API Changelog Bot和Claude Opus 5	3e1e5599cd	docs(changelog): 查看需求 Tab 操作重排 + 子订单行需求详情弹窗规格（前端优化，后端零改动） ... wx 2026-09-23 对团期详情「查看需求」Tab 提三点：新增正式行程用车需求按钮 应在顶部操作条、该按钮独立成卡片操作不方便、要一个按钮点开看用房/用车 需求详情；并总结「这个 Tab 操作整体不方便，整理优化下」。 本条给 mmg 四项重排规格：整团级操作收进 .requirement-tab__ops、预检提示条 每条可点直达解除入口、子订单表操作列加「需求详情」弹窗（按户聚合房+车）、 刷新收敛成一个且明细卡片默认折叠。 字段清单逐项对 origin/dev-v3 源码核过（GroupHotelHouseholdsRespVO / GroupVehicleHouseholdsRespVO / GroupBatchRoomPlanDetailRespVO），无新增端点、 无出入参变化、无网关路由变化、无 DDL。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-23 10:28:18 +08:00
Mimingguang	7eba84761f	docs(changelog): #8215 判 not_required(BatchHero 回落链接住 subOrderCount,hl-ui@61a549bd 补测试锁)	2026-09-23 09:59:25 +08:00
jw	09d3728e92	docs(changelog): 团期详情 A2 新增出参 subOrderCount（#8215） ... 活跃子订单户数，与 A3 total / 看板 orderCount 同源同值。 TEST 09:50 三接口同轮实测均为 12（dev-v3 @ fc0508981）。 纯增出参，路径/入参/权限码/其余字段零变化，网关无改动。 前端是否取的就是这个字段名待确认，frontend_status 记 pending。	2026-09-23 09:52:17 +08:00
Mimingguang	425b4c7e76	docs(changelog): #8142 not_required 补 mmg 复核证据(row-key/虚拟待派/未读 Map 三处实证)	2026-09-23 09:30:54 +08:00
Mimingguang	e5af5425e8	docs(changelog): #8195 回写 verified(hl-ui@7df29262),#8193 not_required 补 mmg 复核证据	2026-09-23 09:28:29 +08:00
API Changelog Bot和Claude Opus 5	35f60460b9	docs(changelog): 车务派单看板两类需求并存时接送机整行消失的修复交接件 (#8142) ... 同一订单现按需求维度出多条记录，字段结构零变化。 frontend_status=not_required：hl-ui 看板已用 requirementId 作 row-key (src/views/fleet/board/utils/boardSummary.js:9-14)，实测不受影响。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-23 09:09:23 +08:00
API Changelog Bot和Claude Opus 5	85855fbe8a	docs(changelog): 团期查看需求页五处缺口的前端交接件 (#8195) ... 四个接口：新增「批量确认接送机需求」端点；vehicle-households 补 endDate/teamNo/ 户级 status/statusName 且未提交户进列表；hotel-households 补 endDate/teamNo； 保存正式用车需求新增车型字典校验（809119）。 三条会让前端静默出错的契约变化已写在正文开头： - orderNo 从来不是团号，团号改读新字段 teamNo（orderNo 保留不删，v-for :key 在用） - vehicleRowCount 不再恒 >= householdCount，旧不变量作废 - 批量确认部分失败仍返 code:200/success:true，要看 data.failedCount 覆盖边界照写未回避：vehicle-households 上「从未提交户」与「被打回户」完全同形 （均 requirements:[] + status:null），本接口给不出判据，出处 GroupVehicleHouseholdsRespVO.java:169-171。 同时逐行列出 hl-ui(origin/v2.1) src/api/orderV2GroupBatch.js 两处已过期的 JSDoc： getGroupVehicleHouseholds :600/:601-602/:607-620，getGroupHotelHouseholds :576-586。 后端已部署测试服并实测（order-v3 dev-v3/62449e550/2026-09-22 22:22:58/ok）， 九条验收全部取到活体读数，原始报文落盘；正文无任何「等部署/另行通知」类前向引用。 Refs #8195 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 22:53:51 +08:00
API Changelog Bot和Claude Opus 5	4a38a8d492	docs(user): 团期房务三事件补站内信配置行，管理后台新增三类消息 (#8193) ... 三个 GROUP_BATCH_* 事件一直在发但 notification_event_config 无配置行， 分发器因此零产出。补齐后房管角色(ROOM_MANAGER)收件箱新增三类消息， link 落 /housekeeper/grab-pool-group，hl-ui 已有通用 link 分支可直接跳， mmg 零改动 => frontend_status=not_required。 同时记录三处前端看不见的配置变更(删两条无发布方的询房行、换店两条 inapp 关闭、TRAVELER_INCOMPLETE_DAILY 企微关闭)，以免被误读为回归。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 22:26:19 +08:00
Mimingguang	82f6ada707	chore(changelog): #8159 成员共用候选读口前端交付 verified(ref bc4024952)	2026-09-22 22:06:19 +08:00
Mimingguang	338f6af9ed	chore(changelog): #8150 前端核验 not_required 补证(hl-ui@6bf97829e)	2026-09-22 21:51:31 +08:00
Mimingguang	6edd653d3e	chore(changelog): 22_frontend 查看需求页五项缺陷前端交付 verified(ref 91d476c93)	2026-09-22 21:34:19 +08:00
API Changelog Bot和Claude Opus 5	1a4a16030c	docs(fleet): 订正 #8159 候选清单 CROSS_BATCH 的触发条件，group_batch_id 为空的行不在清单里 ... 原正文两处（浏览态判据列表、unselectableReason 取值表）都把 group_batch_id 为空 写成会以 CROSS_BATCH 出现在清单里，与同一份第六节「4. 覆盖范围」自相矛盾。 取数条件是 eq(group_batch_id, ?)，那类行结构上查不出来。 Refs #8159 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 19:38:06 +08:00
API Changelog Bot和Claude Opus 5	61bfe0f9a3	docs(order-v3): #8150 changelog 按接口类模板骨架补齐入参/响应示例/业务边界 ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 19:30:44 +08:00
API Changelog Bot和Claude Opus 5	e2828a3e67	docs: 团期 staff 保存 scopeRoles 元素级非空校验交接件（#8150） ... 覆盖 bfc10966e（PR #8177）对 BatchStaffConfigReqVO.scopeRoles 加的元素级 @NotBlank，两条对外可见变化： 1. [null] 由「HTTP 200 静默空操作」改为 code:400。旧行为是静默失败—— @Pattern 对 null 恒为 true 让它穿过校验层，整位守卫 touched 恒 false 不抛，删除窗口 {null} 命中 0 行、插入集合为空，于是库里一行没动却返 200。 2. [""] / [" "] 的 message 由一条变两条以 "; " 拼接。两条约束并列触发、 不是后者替换前者；拼接顺序不保证，已在正文写明前端不得按顺序或按精确 相等解析 message。 证据：网关活体实测四组（含一组阴性对照，证明 400 不是端点无差别返回）， 部署三条独立判据（merge-base 祖先关系 + jar mtime + 活体行为）。 覆盖边界：本份只覆盖 scopeRoles 字段的入参校验契约。 顺带记一处已知缺口：Swagger 请求侧 staffList[].staffRole 的取值域文案只列 了 5 个角色，实际 @Pattern 放行 8 个（后 3 个由 #7079 引入），正文第六.5 节 以 STAFF_ROLE_PATTERN 常量为准写全。 Refs #8150 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 19:13:34 +08:00
API Changelog Bot和Claude Opus 5	34390d85ad	docs: 订正 #8159 候选查询 changelog 的编造与漏项 ... 上一版由轻档代理生成，存在多处与源码不符的内容，逐处订正： 编造（源码无此事实） - 服务端口 8060；五个表名 order_requirement / group_dispatch_line / group_batch / vehicle / driver 全部不存在 - 下游不可用返 code: 999 或 5xx - 鉴权口径「订单顾问、财务相关角色可访」——真相是 FleetAdminRoleGuardInterceptor 只放行 VEHICLE_MANAGER / SUPER_ADMIN， 且权限点 fleet:group-dispatch:* 在 Java 侧零引用（本单 #8159 专门订正过） - 出参 VO 写成 ShareMemberCandidateVO，真名 ShareMemberCandidateRespVO 写错（会让前端写错代码） - 参数非法标成 HTTP 400：本服务业务失败恒 HTTP 200，须按 body.code 判 - 业务边界称浏览态 selectable 恒为 null：实际 ALREADY_IN_ANOTHER_GROUP 与 CROSS_BATCH 两条判据不依赖 resourceId，浏览态照样返 false - 四个 unselectableReason 的触发条件均不准确 漏项（数据损坏级） - 漏掉 shareGroupId 必须由调用方比对这条契约义务。本读口会把正在编辑的 关系的既有成员也置灰成 ALREADY_IN_ANOTHER_GROUP，前端须自行恢复； 且 members 是全集不是增量，漏掉的既有成员会被写口静默移出关系 - 漏掉 602106 的渲染要求（提示刷新重选，不得自动重试） - 漏掉 sourceType + sourceId 可直接透传给写口 members[] 依据：GroupDispatchShareController.java 类注释与 listMemberCandidates 的 @ApiOperation notes（origin/dev-v3）。 Refs #8159 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 18:36:37 +08:00
API Changelog Bot	d609d3ec77	docs: 团级配车成员共用候选查询（#8159）	2026-09-22 18:29:33 +08:00
API Changelog Bot和Claude Opus 5	12c9c6d3d6	docs(changelog): 查看需求页 5 项前端缺陷交接件（订单号改团号/接送机逐行确认/弹窗默认值与文案） ... 2026-09-22 wx 在「团期详情 → 查看需求」页逐屏提了 8 个问题，对 origin/dev-v3(cf9dc85a4) 与 hl-ui origin/v2.1(590c1155) 逐项查证后拆两边：本件只收后端零改动、可立即动手的 5 项 （5 处团号渲染点、接送机逐户确认按钮、新建弹窗默认分组、两个日期默认值、按钮文案）。 后端有硬缺口的 3 项（另 5 处渲染点缺 teamNo、车侧未提交户不返回、无批量确认端点） 建了 wx/HL#8195，本件不含也不做前向引用。 所有「不存在/0 命中」结论均配同形状阳性对照，逐条写在对应小节。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 18:26:03 +08:00
Mimingguang	a7df8cdc5a	chore(8182): 回写前端已交付 verified(jumpToBiz 改读 link,ref 191fdc3c)	2026-09-22 17:52:55 +08:00
API Changelog Bot和Claude Opus 5	a4b92733f5	docs(8182): 订正种子脚本行号引用 171/203 -> 171(ESCALATED)/202(TIMEOUT) ... 原写 203 是行号记错一位（逐字核对为 202）。同时把「改前取值以种子脚本为准」的依据 从「读了一份文件」升级为穷举：整个 db/migration 里出现 inapp_link_template 的文件共 8 份，涉及这两个询房事件码的只有种子 V20260520_002 与本单 V20260922_210，中间没有 第三份改过它们——否则种子值就不等于改前值。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 17:49:52 +08:00
API Changelog Bot和Claude Opus 5	c356e8b564	docs(changelog): 订正 #8182 交接件里两条询房事件的「改前」取值（?id= 而非 ?inquiryId=） ... 原文表格把 HOUSE_INQUIRY_TIMEOUT / _ESCALATED 的改前模板写成 /pages/house/inquiry?inquiryId=${inquiryId}，实际种子值是 ?id=${inquiryId} (V20260520_002__house_notification_event_config.sql:171/203，逐字核对)。 迁移脚本按 event_code 定位、SET 绝对值，行为不受影响；迁移测试的夹具种的也是 正确的 ?id= 原值，只有交接件正文这一处写错。顺带补一句说明 query key 由 id 改名为 inquiryId，以及这两个事件码当前没有发布方、改名无实际调用差异。 Refs #8182 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 17:40:37 +08:00
API Changelog Bot和Claude Opus 5	2c9b21f796	docs(changelog): #8182 HOUSE 内部员工站内信 link 由小程序路径订正为管理后台路由，并明确 bizId 不是路由键（修复-管理后台） ... 三个内部员工事件码(HOUSE_INVENTORY_CHECKED / HOUSE_INQUIRY_TIMEOUT / HOUSE_INQUIRY_ESCALATED)的 inapp_link_template 由 /pages/house/* 改为 /housekeeper/*；字段结构不变，变的是值。 本条 frontend_status=pending 而非 not_required：22_8155 写过「前端 jumpToBiz 从不读 row.link，无需前端改动」，那句话仅在 REQUIREMENT_REJECTED 上成立—— 核房/团期事件的 bizId 根本不是订单，按 bizId 反推跳转必然打开不存在的订单。 正文已点名 22_8155 并写清适用范围。 Refs #8182 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 17:38:41 +08:00
Mimingguang	a2120cf1ec	chore(8181): 回写前端核验 not_required(渠道渲染数据驱动自动生效,历史映射保留)	2026-09-22 17:38:15 +08:00
Mimingguang	5a33baba38	chore(frontend): 回写两份 22_frontend 交接件已交付 verified(取值订正 cf37e7f6 / 补列 369ed5b4)	2026-09-22 17:33:58 +08:00
yaosutu	a0413a53be	docs(changelog): #8181 线下收款废除报账人代收DRIVER_CASH渠道——options出参channels移除DRIVER_CASH+register新增520417（尾款收款模型重构PR-1，修改接口-管理后台）	2026-09-22 17:07:15 +08:00
jw和Claude Opus 5	165cbcb69a	docs(changelog): 团期三张子订单表的前端渲染缺陷两份交接件（GB-ADM-003 后端零改动） ... 整团名单速览、子订单、查看需求三张表吃同一个接口 GB-ADM-003 GET /v3/admin/order/group-batch/{groupBatchId}/orders，同源所以同病： - 22_frontend_整团名单速览与子订单表…：联系人列显示占位符「—」应取 customerName； 房型列显示英文枚举码（KING）应取 roomTypeName（豪华大床）。 - 22_frontend_查看需求Tab子订单表…：同样两处取值问题，外加只有 5 列、 要补齐到子订单表的列集（团号/房型·间数/状态/需求审核/联系电话/应收/游客/资料）。 后端零改动，两份均已回填测试服活体实测读数：团期 2101506167098511362 全量 12 户， customerName 12/12 有值、roomType→roomTypeName 12/12 翻译正常（KING→豪华大床）； 图示那一行的 12 列逐列与实测值逐字吻合。附排查提示：travelers 12/12 为空数组且 travelerInfoComplete 恒 false，联系人若从出行人明细推导即会恒显「—」。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 16:57:39 +08:00
Mimingguang	1e59aac339	chore(8152/8164): 回写前端闭环(8152 订正残留已清 0b65814a;8164 核验 not_required 透 message 自动覆盖)	2026-09-22 16:35:50 +08:00
Mimingguang	9dbec55501	chore(8161): 回写前端已交付 verified(biz-recon 单据对账下钻,ref 5072da0b)	2026-09-22 16:25:47 +08:00
Mimingguang	4a8e301d39	docs(changelog): #8154 前端已交付回写 verified(hl-admin 9c5dd0cb)	2026-09-22 16:00:09 +08:00
API Changelog Bot和Claude Opus 5	000e93c6be	docs(changelog): 8152 交接件补记前端侧同源残留两处（statusName 编造取值的下游落点） ... e011960 订正了本交接件里 statusName 的四个编造取值，但那四个字符串已被 hl-admin 抄进两处：VehicleHouseholdsSection.vue:191 的注释与该组件 spec 的夹具。两处都不影响运行（组件 :78 是纯透传、用例断言的是透传行为）， 但下一个人 grep「待处理」会同时撞上它们，需要能分清哪些是错的。 同时把责任归属写明：四个取值是后端先写错在交接件里、前端照抄的。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 15:36:32 +08:00
API Changelog Bot和Claude Opus 5	e011960e45	fix(changelog): 订正 8152 交接件 vehicle-households 端点 statusName 编造取值 ... `three` 处示例/字段说明里的 statusName 中文值（"已完成"/"待处理"）系凭空编造，既不是修复前的房务口径值（"配房完成"/"待房务配"），也不是修复后的车务口径值。核对 GroupBatchConverter.resolveRequirementStatusName(code, true) 源码后改为实测口径：PENDING→待车队配、PROCESSING→配车中、DONE→配车完成。 同时订正 六.5 枚举表里同样错误的三个取值，并补一段说明——该端点 statusName 原实现直接取 RequirementStatus 枚举的房务侧 label，已由 45adfd7ed（PR #8173）改调 resolveRequirementStatusName(code, true) 修正，附完整取值表。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 15:16:10 +08:00
Mimingguang	ff16082a23	docs(changelog): #8152/#8151/#8153 前端已交付回写 verified(hl-admin v2.1 @ 14cb7110)	2026-09-22 14:57:27 +08:00
jw和Claude Opus 5	7afd10b226	docs(changelog): 小程序用车详情 vehicleCount 由车·日数订正为车辆台数（#8143） ... 同一个订单同一个字段，返回的数字会变小（3 天 2 辆车由 6 变成 2）。 字段名/类型/其余字段全不变，前端把它当「车辆数」展示则无需改动。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 14:54:10 +08:00
yaosutu	553b870997	docs(changelog): #8164 收票核销硬钩稽PR-2——钱侧防御钩子599413/599414（应付/预付编辑改价超额+删除/驳回有票关联硬拦，修改接口-管理后台）	2026-09-22 14:42:14 +08:00
API Changelog Bot和Claude Opus 5	312ecd0f1f	docs(changelog): 团期用车需求结构化 + 团期管理员只读查看子订单，两份前端交接件 (#8152 #8151 #8153 #8154) ... - 22_8152_…：团级用车需求补 seats/count/specialTags/remark 四个结构化字段；新增 `GET .../requirement/vehicle-households` 子订单用车需求记录端点；requirement-summary 补 transferSummary 聚合；confirm-check 补 transferSubmitEnabled 与接送机缺口名单。 - 22_8154_…：团期管理员（GROUP_BATCH_MANAGER）可只读打开团期子订单详情（10 个端点放行）， 13 个金额/成本/流水面端点对该角色收回（581008），写面全域拒绝。 两份均已回填测试服活体实测读数：order-v3 @ f1986f996，user-service / fleet @ c4321f961。 #8154 的前后对照含一条关键读数——改动前该角色读订单被拒、写订单却畅通，本批一并收口。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 13:20:00 +08:00
yaosutu	6095307804	docs(changelog): #8161 收票核销硬钩稽PR-1——挂票生效态门槛599412+单据维度对账下钻biz-recon（修改接口-管理后台）	2026-09-22 12:02:54 +08:00
API Changelog Bot	4e3d3ba2d5	docs(changelog): #8155 需求驳回站内信 bizId 由需求行 id 改为 orderId（已部署实测） ... REQUIREMENT_REJECTED 事件此前 bizType 固定 ORDER 却把需求行 id 当 bizId 下发， 管理端站内信点「跳转」必然打开一个不存在的订单。后端已改为下发 orderId， 需求行 id 迁到 params（notification_send_log.params_json 实测可反查）， 并把 inapp_link_template 前缀从 /order/detail/ 订正为 /order-v2/detail/。 AdminMessageRespVO / AdminMessagePageReqVO 字段结构未变，前端无需改动。 已部署测试服 6af4d93e5 双实例并端到端实测：新产生的 admin_message 行 biz_id 等于 orderId、link 为 /order-v2/detail/2102242483750756354。 覆盖边界：admin_message 是快照表，存量行 biz_id 与 link 仍是旧值、不回刷 （该事件仅在测试环境产生过，order-v3/fleet 未上生产）。 Refs #8155 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 12:00:14 +08:00
Mimingguang	66d2737a3d	chore(changelog): 22_frontend 空 id 塌缩交接件回写 verified(ref b7c20a81)	2026-09-22 10:34:40 +08:00
Mimingguang	ea7a01e674	chore(changelog): #8127 frontmatter 回写 verified(ref d0a264ec)	2026-09-22 10:24:44 +08:00
Mimingguang	a10d36f13b	chore(changelog): #8070 frontmatter 回写 verified(注释级交付,ref 7fa22462)	2026-09-22 10:01:50 +08:00
API Changelog Bot和Claude Opus 5	48e0fb4e75	docs(changelog): 团期详情页切走后重放请求 groupBatchId 塌缩为空串（前端缺陷交接件） ... 管理后台 test.1814.love:9443/notification/my-messages 弹三条报错： 「参数 groupBatchId 格式错误」×2 + 「接口不存在: GET /v3/admin/order/group-batch/requirement/hotel-households」。 根因在 hl-ui（mmg 侧）：order-v2/batch/detail/index.vue 用 computed 从 route.params.code 反应式推导团期 id，该页 keep-alive；切到消息中心后 params.code 变 undefined，id 塌缩成空串， RoomSummarySection / RoomHouseholdsSection / GroupVehicleRequirementSection 三个 watcher 无空值守卫，各自重放一次请求。同页 DisbandBanner 有 if (!props.groupBatchId) return 守卫， 全程 200，是页面内的阳性对照。 后端契约无变化：groupBatchId 是路径段，空串导致路径少一段，因此第三条落到路由未匹配的 「接口不存在」而非参数校验。本件只交接前端修法与三个端点的真实契约，不含后端改动。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 09:52:30 +08:00
Mimingguang	9b0ecadfbd	docs(8122): frontmatter 回写 verified(前端注释订正 4f65c453,实现本就整位覆盖)	2026-09-22 09:51:06 +08:00
API Changelog Bot和Claude Opus 5	8876329ecb	docs(changelog): #8122 订正 hl-ui orderV2GroupBatch.js:291 把缺一同位角色写成 582115 ... 前端注释称「保存导游位 scopeRoles 必须两个都传，缺一 582115」。两个方向都不成立： 改前缺一返 200 无错误码（正是本单缺陷），改后缺一是 582116。 按 582115 写的分支在该路径上从不命中。读取对象 hl-ui origin/v2.1 17eb03ec。 Refs #8122 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 09:41:16 +08:00
API Changelog Bot和Claude Opus 5	478a9c58a4	docs(changelog): #8122 团期 staff 保存 scopeRoles 必须整位覆盖（582116） ... PUT /v3/admin/group-batch/{productBatchId}/staff 行为收紧： scopeRoles 触及某配置位即须覆盖该位全部成员角色，半位声明拒绝且零写入。 配置位成员由字典决定，不是代码常量。 Refs #8122, PR #8147, 后续单 #8148 / #8150 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 09:36:13 +08:00
yaosutu	785c6ed84a	feat(changelog): 财务应付款两批——冲抵预付(#8127)+建议清单统计页切流读台账(#8070) ... - 22_8127 应付款付款支持冲抵供应商预付款：4 建单/改单接口入参新增 prepayOffsets， 详情出参新增 offsets[]/prepayOffsetAmount/actualPayAmount 真值化，新增 offsettable-prepays 查询 - 22_8070 应付款建议清单/统计页切流读推送台账：出参补 appliedAmount/owedAmount 口径字段 + isLocked 前置闸	2026-09-22 09:27:00 +08:00
Mimingguang	a18bd8ca09	docs(8121): 前端核验核单弹窗 failReason 纯展示无精确匹配,frontend_status 翻 not_required	2026-09-22 06:27:19 +08:00
API Changelog Bot和Claude Opus 5	5140667d28	docs(changelog): #8121 核单清单「用车安排」逐类判定，包车+接送机并存不再静默放行 ... 按 origin/dev-v3 源码逐条重建出参、ChecklistItemVO 结构、三段响应示例、 空数据降级、错误响应与业务边界六节：原稿的 orderId、PAYMENT_DONE 码值、 localhost:8033 主机头与 404/401/403 状态码均无源码依据，已按 OrderDetailService / ConfirmChecklistRespVO / GlobalExceptionHandler 的实际实现订正。 错误响应改为 HTTP 200 + body code（581007 订单不存在 / 581008 非可见角色 / 581045 房务角色），与 CODE_RULES §10「业务失败走 200」一致； 越权校验两道门（OrderController:254 assertNotHouseRole、 OrderDetailService:785 assertOrderReadable）按源码写实，并记入 「角色为空时 assertNotHouseRole 放行」这一已知缺口。 第八章换为五单真实读数，并照写「行程用车未就绪分支本轮无活体读数」这一覆盖边界。 Refs #8121 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 06:24:22 +08:00
Mimingguang	4be46a6531	docs(8006): frontmatter 回写 verified(前端 21_8006 已交付,ref 2e885080,零增量)	2026-09-22 05:48:00 +08:00
API Changelog Bot和Claude Sonnet 5	8f866d9ceb	docs(changelog): 团期 staff 保存新增可选 scopeRoles，支持按角色范围覆盖 ... PUT /v3/admin/group-batch/{productBatchId}/staff 新增可选请求体字段 scopeRoles，不传时行为与改前逐字一致（整期全量覆盖）；传了则只覆盖 声明的角色范围，修复导游位/摄影位两个弹窗各自保存时互相清空对方配置 的问题。 Refs wx/HL#8006 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-22 05:36:05 +08:00