【审计修复·管理后台】房务模块4类同类逻辑问题系统排查修复(9 PR · 前端/下游影响)

类型:审计驱动批量修复(无单个工单,以 #4124/#4125 为样板的同类排查) 端:管理后台(hl-ui)+ 下游(mp 行程/合同) 服务:hl-order-service-v3 日期:2026-06-20 关联 PR:#4133 #4137 #4138 #4139 #4140 #4143 #4144 #4146 #4147

⚠️ 关键说明

以已实现的 #4124/#4125 为样板,派 4 个并行 agent 把房务模块的逻辑问题抽象成 4 类(A 上游数据被映射丢弃 / B 硬编码该走枚举字典 / C 冗余死代码 / D mock 占位非真实)全量排查,出 ~25 项,9 个 PR 全部修复。多数是后端重构(死代码清理 / 枚举收口),无 API 契约变更;下面只列前端/下游能感知到的变更。

变更	端	影响
1. 抢单池/详情/我的接单卡片新增 `dispatchRemark`	管理后台	加字段,展示「提交备注(给房务看)」
2. 我的接单 `exceptionCount`/`todoCount` 由恒 0 改真实计数	管理后台	行为变更,排序/筛选恢复有效
3. 房务待办列表 8 个展示字段由占位改真实	管理后台	行为变更,字段不再为 null/写死
4. 车控「我的接单」由假数据改真实查询	管理后台	行为变更,不再返 mock 假单
5. 候选推荐语去掉假的「历史命中 50%」	管理后台	文案变更
6. 配车需求 `specialTags` 标注字典绑定	管理后台	字典选项(`vehicle_special_demand`)
7. 配置聚合 bundle 已配酒店由空改真实	下游(mp/合同)	行为变更,行程/合同含酒店

1. 新增 dispatchRemark(提交备注)字段(PR #4138)

团期管理员提交需求时填的「提交备注(给房务/车队看)」原写入表却从未透传到任何列表/详情,工作台看不到。现已加字段透传:

接口	新增字段	说明
`GET /v3/admin/order/grab-pool/hotel-requirements`(抢单池)	`dispatchRemark`	String,提交房务备注
房务详情快照 `requirement.current`	`dispatchRemark`	同上
`GET /v3/internal/order/vehicle-requirements`(车务池,下游)	`dispatchRemark`	提交车务备注

非破坏性加字段,前端按需展示。

2. 我的接单异常/待办计数接真值(PR #4139)

GET /v3/admin/order/grab-pool/my-claims/hotel 列表项:

字段	旧	新
`exceptionCount`	恒 0	该订单 OPEN 异常待办真实数
`todoCount`	恒 0	该订单未关闭待办真实数

之前因恒 0,sortBy=exceptionCount,desc 排序与「仅看有异常的单」过滤全失效;现已恢复有效。

3. 房务待办列表展示字段接真值(PR #4139)

GET /v3/admin/order/todos 列表项:orderNo/guestName/personsDesc/ownerName/requirementSummary/requirementVersion/departDate 由恒 null/写死 1 改为联表订单/需求真实值(批量取数,跨域降级)。

4. 车控「我的接单」去 Mock 改真实查询(PR #4146)

GET /v3/admin/order/grab-pool/my-claims/vehicle 原返硬编码假数据(「长白山自由行5日」等),现改真实查询(按当前车控 claimer_id + status 分页查 order_vehicle_requirement,装配真实数据)。列表项补 consultantId(开与定制师会话用)。

说明:车务是 fleet 派单(非人工抢单),claimer_id 写入路径暂未建,故当前返空列表(真实),而非假数据。

5. 候选推荐语去掉假「历史命中」(PR #4133)

GET /v3/admin/hotel-candidates 候选 recommendation 文案:历史命中算法尚未接入(stub 恒 0.5),原代码却把它拼成「· 历史命中 50%」展示给定制师(假指标)。现 stub 模式下不再拼该片段(historyScoreStub=true 标志位保留)。

6. 配车需求 specialTags 字典化标注(PR #4146)

VehicleRequirementReqVO.specialTags 标注绑定字典 vehicle_special_demand(镜像房务侧 house_special_demand),前端可走字典多选 + 自定义。

7. 配置聚合 bundle 已配酒店接真(PR #4147,下游)

internal getAssignmentBundle(供 mp 行程聚合/合同签约)的 hotelAssignments 原恒空(已配酒店数据迁到 house 域后未接),现经中立契约 HouseAssignmentReadContract 读真实已配酒店填充。下游 mp 行程/合同模板现能拿到酒店明细。

纯后端重构(无 API 变更,前端无需改动,仅记录)

死代码清理(#4133/#4137):删 order.assignment 3 个死候选 VO、RequirementService hotel 抢单旧死方法链 + 死 VO、RequirementSnapshot.lastReturnInfo 死字段、GrabPoolJoinItem.tripDays 死投影、死请求字段、Ranker 镜像方法上提。
枚举收口(#4140/#4143/#4144):productType/staffRole/resourceType 复用现成枚举;徽章/recommendSource/returnTarget/branchTaken/dailyFeeSource/urgency 建枚举;HouseTodoType label 内聚。行为零变更(字面量→枚举,输出/比较结果完全一致)。

验证

各 PR 均 test-compile + 相关单测 + *ArchTest(32)全绿;部署测试服 order-v3 成功,9443 实测车控我的接单去 Mock 生效(返空非假数据)、各端点 200 在服。

5.0 KiB 原始文件 Blame 文件历史