# 【审计修复·管理后台】房务模块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 在服。
