Mimingguang
87ed9d0a3f
处置明细(mmg 2026-09-18): - 68 条机械核验通过批量翻 verified:frontend_ref 均可达且为 v2.1 祖先、 交付文件 HEAD 均在、关联 spec 批量 58 文件 891 例全绿。 - 11 条带演进史的例外逐条核后翻 verified:3 条交付自删文件(06_5610/ 07_5655/11_5810,删除即交付内容且终态保持);8 条被后续 changelog 预期 演进(10_5784→#5810、07_5664/08_5592→#5827、07_5665→去槽位化 U1、 01_5380/05_5356/06_5567/06_5581→settlement 族A扁平化与 mock 清理), status_note 均如实记录演进链。 - 05_5552 改判 not_required:frontend_ref 自述前端无需改动,grep 实证 vehicleFeeAmount.js 直接读后端 calendarPrice/calendarPriceMissing。 - 11_5827 frontend_ref 原空,经核交付即 753503c8(向导 4 步改 3 步提交 即派定),补登全哈希 753503c87cc635e5646b4368a8ed506746c79cf1。 另:保险域 2 条相邻条目(05_5530/06_5593)同标准复核翻 verified。 2026-07 历史月 45 条按规则不回扫,保持原状。
5.2 KiB
schema, ticket, title, consumer, change_type, author, backend_status, gateway_status, frontend_status, frontend_owner, frontend_ref, target_release, verified_at, status_note, updated_at, base
| schema | ticket | title | consumer | change_type | author | backend_status | gateway_status | frontend_status | frontend_owner | frontend_ref | target_release | verified_at | status_note | updated_at | base |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| hl-changelog/v2 | 5830 | 房务订单详情新增「订单详情」Tab：景点行程 tripItinerary + 出行人 travelers + 大交通 transport | admin | 修改接口 | wx(GIT) | deployed | not_required | verified | mmg | dbec5600 | 2026-09-18 | 前端已实现(dbec5600):OrderDetailModal 新增第 4 个「订单详情」Tab(徽标 tabCounts.tripItineraryCount 回退 tripItinerary.length),新建 OrderDetailPanel 渲染出行人表(脱敏 nameMasked 优先)/大交通表/每日安排(tripItinerary NSteps 节点),复用车务 fleet transport/display 纯函数同口径对齐 Step1;orderDetailReady=false 整块提示「订单信息加载失败,请稍后刷新」不误显「没有出行人」,ready=true 空数据显示「暂无」;orderDetailAdapter 透传 tripItinerary/travelers/transport/orderDetailReady + tripItineraryCount,既有 itinerary(配房住宿视角)一字未动。测试:OrderDetailPanel.spec 4 + orderDetailAdapter.spec 4(透传/降级/count 优先/transport 数组归 null),housekeeper 组件 84 全绿,checkpoint 5 文件含生产构建全过。[mmg 2026-09-18 批量复核翻 verified] ref dbec5600 可达且为 v2.1 祖先;交付文件 HEAD 均在;关联 spec 批量 891 例全绿。 | 2026-09-18 | dev-v3 |
房务订单详情新增「订单详情」Tab（#5830）
服务: hl-order-service-v3 PR: #5832（已合并 dev-v3 并部署测试服） 日期: 2026-08-11 背景: 房务订单详情此前只有 3 个 Tab（配房行程 / 定制师需求 / 操作日志），房务看不到出行人与大交通，行程也只有住宿视角。wx 要求对齐车务派单弹窗 Step1「订单详情」的三块内容。
变更接口
GET /admin/house/orders/{orderId} —— 根级新增 4 个字段：
| 字段 | 类型 | 可空 | 说明 |
|---|---|---|---|
tripItinerary |
List<ItineraryDayForFleetDTO> |
否（降级时空数组） | 景点/餐食每日安排（与车务 Step1 同源） |
travelers |
List<OrderTravelerForFleetDTO> |
否（降级时空数组） | 出行人，脱敏版（nameMasked 掩码、无证件/生日明文） |
transport |
OrderTransportForFleetDTO |
是 | 大交通（往返方向 / 交通方式 / 时间 / 路线 / 班次 / 关联出行人） |
orderDetailReady |
Boolean |
否 | 三块是否取数成功，见下方说明 |
🔴 不要和 itinerary 搞混
itinerary 字段依旧是「配房行程」Tab 的住宿视角数据（ItineraryDay：stayDate / cityCode / arrange 配房状态…），本次一字未动。新的景点行程叫 tripItinerary，两者结构完全不同，不要互换或复用。
tabCounts 新增 key
{
"itineraryCount": 2, // 配房行程 Tab（不变）
"messageCount": 1, // 留言（不变）
"unreadMessageCount": 0, // 留言未读红点（不变）
"operationLogCount": 4, // 操作日志（不变）
"tripItineraryCount": 3 // 【新增】订单详情 Tab 徽标 = 景点行程天数
}
orderDetailReady 怎么用
三块数据是软依赖：订单核心侧取数异常时各自降级为空集合/null，房务详情接口不会 500（房务主职责是配房，不该被订单核心故障拖垮）。
但降级后的空数据与「客人确实没录出行人/没填大交通」长得一模一样。orderDetailReady 用来区分：
true= 取数成功。此时字段为空就是真的没有，正常显示「暂无出行人 / 暂无大交通」false= 取数失败。前端应提示「订单信息加载失败，请稍后刷新」，不要显示成「该订单没有出行人」
实测印证：某订单 transport 各字段全 null（客人确实没录大交通），但 orderDetailReady=true，属于第一种情况。
前端要做
新增第 4 个 Tab「订单详情」，渲染三块，样式对齐车务派单弹窗 Step1：
- 出行人信息表：姓名（已脱敏）/ 所属地 / 人员类型 / 性别 / 年龄 / 国籍民族 / 关联班次
- 大交通表：方向（抵达接团 / 返程送站）/ 交通方式 / 时间 / 路线 / 班次 / 出行人
- 每日安排（
tripItinerary）：按天展示景点、餐食等行程明细
Tab 徽标用 tabCounts.tripItineraryCount。只读入口下同样只展示、无操作。
验证证据
2026-08-11 测试服（网关 9443）实测真实房务订单：
tripItinerary = 3 天
travelers = 1 人（nameMasked = "娜***"，脱敏正确）
transport = 返回对象（该单客人未录大交通，各字段 null）
orderDetailReady = true
itinerary（配房行程）= 2 天 ← 无回归
tabCounts = {"itineraryCount":2, "messageCount":1, "unreadMessageCount":0,
"operationLogCount":4, "tripItineraryCount":3}
单测：hl-order-service-v3 全量 6374 / Failures 0（3 个 Errors 为 surefire 单 JVM 后期 OOM 的环境性问题，单独重跑绿）；HouseDetailAggregatorTest 80/80；专守循环依赖的 OrderServiceCircularDependencyContextIT 绿；ArchTest 绿。