wx/hl-api-changelog
1
0
派生 0
代码 工单 合并请求 工作流 软件包 项目 发布 百科 活动
2,973 提交 29 分支 0 Git 标签
59938ccf63ccb2580edf7835e77bf96f968b77df
提交图
2973 次代码提交
此分支
此分支
所有分支
作者 SHA1 备注 提交日期
jw和Claude Opus 5 59938ccf63 docs(changelog): 更正 #7105「出具门恒失败」说明——门已由 #7248 打通
changelog-filename-gate / validate (push) Failing after 2s
详情 
2026-09-07 那条 #7105 的首段写着：酒店 ready 线上无写入方（#4132），
故 issuable 恒 false、手动开/作废重开恒返 589548、团期合同保险不会自动出具。
两个前提现已都不成立：

- #7248 / PR #7249（9f47f620f）把出具门从「判团期状态」改成
  「资源准备中 + 四项 ready 全 true 即放行」，解开与 #7023 的死锁
- hotel_ready 已有三处写入方（GroupBatchRoomDayConfirmManager:457/:767、
  HouseGroupBatchAssignmentService:201）

2026-09-21 TEST 经真实网关实测：RESOURCE_PREPARING 团期 issuable=true；
issue 端点返 200 逐户结果而非整单 589548；四项配齐团期下 40 户已确认行程的
子订单合同全 SIGNED、保险全 INSURED。

接口契约零变更，前端需调整两处：按 issuable 置灰、失败改读逐户 outcome/message。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-21 16:00:42 +08:00
Mimingguang 83652bb0a2 docs(changelog): #7211 前端已交付 verified(hl-admin v2.1 4d092b09)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-21 15:47:38 +08:00
API Changelog Bot和Claude Opus 5 a45a079e9f docs(changelog): 20_7443 同步车务链路改写为实测肯定式结论 + 新增 21_7211 团期联系入口交接件
changelog-filename-gate / validate (push) Failing after 2s
详情 
20_7443（#7443 接送机用车双槽提交）：
- 删掉「该缺陷已在修…修好后另发交接件」「只验到提交为止」等让前端停工的措辞——
  这正是 2026-09-21 wx 第二次点名的问题（mmg 因此整段时间没动工），新增的
  E_WAIT_LANGUAGE 门禁对旧版报 7 处、对本版 0 处。
- 换成带读数的肯定式结论：hl-fleet-service 已部署 dev-v3 @ c238f38c3
  （含 #7990 修复提交 53c2ff2d1 / bf4fba5a2，merge-base --is-ancestor 均 true），
  order_fleet_command_outbox 两行 RECONCILE（TRAVEL 2101937490971742210 /
  TRANSFER 2101937491068211201）均 SUCCEEDED、last_error_message 为 NULL，605905 未再出现。
- 保留契约自带的限定：单槽写口 kind 默认 TRAVEL、hasPickupTime=false 时 809002、
  生产开关 transfer-kind-submit-enabled 需独立运维动作、#8056 仍 open。
- verified_at 2026-09-20 → 2026-09-21。

21_7211（团期子订单联系入口改为联系团期管理员，前端缺陷，后端零改动）：
- 判据字段 ItineraryVO.groupBatchId（非 OrderMainVO.groupBatchId），
  入口 POST /admin/message/chat/open-group 请求体只收 orderId。
- 补本轮测试服实测：团期单 2101935981273976833 → code=200/isNew=true；
  非团期单 9199000000000000002 → code=281015（反例，证明端点按团期与否分流）。

两份均通过 validate-changelog-frontmatter.mjs（含 E_WAIT_LANGUAGE）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-21 15:41:59 +08:00
API Changelog Bot和Claude Opus 5 455d9da1af fix(gate): E_WAIT_LANGUAGE 撤掉「暂不可用」族——实测几乎全是错误码表文案
changelog-filename-gate / validate (push) Failing after 2s
详情 
对全仓 1968 份 changelog 跑新规则做存量抽样,命中里「暂时不可用 / 暂不可用」这一族
几乎全部落在错误码表与响应示例的**文案**上,例如:

  | `584105` | 结算字典暂时不可用，请稍后重试 | 字典服务失败、空响应或无启用项 |
  | `584100` | 车辆费用暂时不可用 | 车辆费用来源调用失败…… |

这正是本规则必须放行的契约内容——它影响前端「怎么写代码」(要认这个错误码),
不影响他「什么时候开始写」。判据没有分辨力时,门禁只会教人绕开它,或者逼作者
为了过门禁把该写的错误码说明一起删掉。已在代码里写明不要加回来及其依据。

撤掉后存量命中从 54 份(2.7%)降到 29 份(1.5%),剩下的按措辞分布:
未部署 20、等待…后端 7、待部署 5、另行通知 3、后续订正 3、等待…上线 2、
后端部署后 1、等待…部署 1、以后续 1、暂不要对接 1 —— 都是真的在让前端等。
存量不回填(门禁只跑 push diff),谁编辑旧文件谁负责当场改掉。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-21 15:29:27 +08:00
API Changelog Bot和Claude Opus 5 047a4be4fd feat(gate): 新增 E_WAIT_LANGUAGE——交接件正文禁「让前端等我们」的措辞
changelog-filename-gate / validate (push) Failing after 2s
详情 
2026-09-21 wx 第二次点名：「不要在changelog里写让前端等待部署 这不是你第一回犯错了
工作流是你部署完测试环境推送changelog」。

§2.1 的 backend_status 门禁挡得住预告式推送，挡不住这一类：20_7443 的 frontmatter
已经是 deployed、CI 全绿，但正文 status_note 结尾写着「该缺陷已在修……修好后另发
交接件」。mmg 因此一直没动工，隔天才来问「这个是有啥问题吗 还是没做到呢」——门禁
只看 frontmatter，看不见自由文本里的这句话，所以「deployed + 校验绿」并不代表这份
交接件可执行。消费方也没有能力消解这种不确定性：他查不了我们的部署状态、看不到
dev-v3、不知道「另发」是哪天，读到「等」就只能等，而且是静默地等。

- scripts/validate-changelog-frontmatter.mjs：新增 validateNoWaitLanguage，对所有
  v2 文档逐行扫描（与 change_type 无关，前端条目同样适用）。三类措辞：部署状态对冲、
  未来交付承诺、直接叫停对接；「等待」做共现判定而非裸词匹配，避免把「前端需轮询
  等待支付回调」这类业务语义一起拦掉。前向引用（「以后续订正为准」「见后续订正」）
  一并封住——它和「修好后另发」是同一件事换个说法，实测被绕过一次。
- tests：4 个用例，含 1 个阴性对照（灰度开关状态、已知缺口工单号、业务流程里的等待
  必须放行），防止作者为了过门禁把该写的契约边界一起删掉。
- BACKEND_CHANGELOG_DELIVERY_GUIDE.md §2.1：写明规则、背景与那条分界线——这条影响
  他「怎么写代码」，还是只影响他「什么时候开始写」？后者一律删。

阳性对照：对已推送的 HEAD 版 20_7443 跑新规则，命中 2 处（第 308、451 行「修好后另发」），
即它能抓住真实发生过的那次。既有 changelog-path-aliases 测试对 11_7510 的 2 条
E_ALIAS_STATE 红是本次改动之前就存在的，与本提交无关，pre-push 钩子也不跑该用例。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-21 15:27:37 +08:00
Mimingguang b4fbfe6f20 docs(changelog): #8045 前端已交付 verified(hl-admin v2.1 e680cf10)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-21 15:13:53 +08:00
jw和Claude Opus 4.8 e8d53378c7 docs(changelog): order-v3 团期详情返回整团待收 unpaidAmount（#8045）
changelog-filename-gate / validate (push) Failing after 2s
详情 
团期详情端点（A2）新增响应字段 unpaidAmount，值 = max(0, receivableAmount − receivedAmount)，
恒非 null 恒非负、字符串型金额；列表页 A1 早已有同名字段，本次把详情页补齐。

给前端（mmg）的三条要点：
1. 不要再自己拿应收减已收，直接读 unpaidAmount；
2. 不要与本页子订单项的 balanceAmount 混用（那是 per-order「应收 − 已退 − 已付」，
   扣退款且取消单归 0，同名不同义）；
3. 有退款的团本字段按毛已付算会偏大，权威待收是财务 tab 的 items/totals ——
   ⚠️ 注意是「逐户明细与合计」，不是财务 tab 的顶层 unpaidAmount
   （顶层与本字段同源同公式，数值一致；实测差异见正文第八节）。

既有四个金额字段（receivableAmount / receivedAmount / totalReceivable / totalReceived）
的值、名称、JSON 形态逐字未变，纯增量。

Issue: #8045   PR: #8101

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-09-21 14:59:57 +08:00
Mimingguang b29a9f72cb docs(changelogs-v2): #7994 前端已交付回写 verified(602013 长文案常驻展示)(mmg)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-21 11:30:56 +08:00
API Changelog Bot和Claude Opus 5 043a779820 docs(changelog): #7994 受控重开窗口内无分组历史派车行可被收编
changelog-filename-gate / validate (push) Failing after 2s
详情 
团期配车重新配车接口：分组列上线前的历史派车行，此前无论被改还是被删
都判越界（602013），叠加「物资准备期不开窗口不许配车」后形成单向死路。
改后按动作分两路——被同键收编则放行，被删除仍判越界。

请求体/响应体零变化；602013 在含无分组历史行时追加自救提示，
前端需确认该文案能完整展示不截断。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-21 11:20:39 +08:00
Mimingguang a972180f69 docs(changelogs-v2): #8087 补记二次修复(下拉搜索默认不进全局遮罩)(mmg)
changelog-filename-gate / validate (push) Failing after 1s
详情
2026-09-21 11:17:57 +08:00
Mimingguang b950ceeb95 docs(changelogs-v2): #8087 补记交付后修复(餐厅变更清餐食+加载圈限定当前行)(mmg)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-21 11:10:18 +08:00
Mimingguang 57d50004af docs(changelogs-v2): #7973 前端实证 not_required(share-groups 无调用方;清空后端预填的 owner/verified_at)(mmg)
changelog-filename-gate / validate (push) Failing after 1s
详情
2026-09-21 10:49:46 +08:00
Mimingguang 054bde14ce docs(changelogs-v2): #8086 餐食 restaurantName null 口径前端已交付回写 verified(mmg)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-21 10:47:14 +08:00
Mimingguang 4e66eb234d docs(changelogs-v2): #8087 餐食下拉餐厅联动前端已交付回写 verified(mmg)
changelog-filename-gate / validate (push) Failing after 1s
详情
2026-09-21 10:41:51 +08:00
lc a968875f7f Merge branch 'main' of https://git.1814.love:8443/wx/hl-api-changelog
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-21 10:37:02 +08:00
lc和Claude Opus 5 d1f183115e docs(changelog): #8086 餐食不关联餐厅时餐厅名返回 null，分页按餐厅建档先后排序（修改接口·管理后台） 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-21 10:36:19 +08:00
Mimingguang aa310a1d61 docs(changelogs-v2): #7442 PR-A reconfigure 前端增量2已交付回写 verified(mmg)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-21 10:34:40 +08:00
lc和Claude Opus 5 8e1e77e6ca docs(changelog): #8087 餐食下拉按餐厅联动，未选餐厅只给「全部」餐食（修改接口·管理后台）
changelog-filename-gate / validate (push) Failing after 1s
详情 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-21 10:26:27 +08:00
API Changelog Bot和Claude Opus 5 459715bae9 docs(changelogs-v2): #7973 共用关系确认 confirmCrossResident 入参补记 + 网关取证转 verified
changelog-filename-gate / validate (push) Failing after 1s
详情 
2026-09-21 10:09:15 / 10:09:17 经网关取证：两次请求体逐字相同、唯一差异是
confirmCrossResident——不传得 605036，传 true 得 200 并建出 ACTIVE 共用关系，
取证完毕按 survivorPolicy=RELEASE 清场。据此 gateway_status 由 pending 转 verified。
状态位是取证换来的，不是为过门禁改的。

同批修正正文 7 处：
- 4 处源码行号漂移（AssignmentService / AssignmentErrorCode）
- 605036 示例改用网关原文，替换此前取自单测字面量的构造示例
- 补全 messageOf 的第 3 个分支：此前只记了 2 个，且两个都漏掉后缀
  「，继续操作将形成跨常驻车派单」
- 修正张冠李戴：driverBoundToAnotherVehicle 用例被配上了车辆侧文案
- 溯源订正为 #4936 引入、#5160 扩展（git log --follow 核实）
- 关联文档路径 19_7444 更正为 21_7444
- 第七节补明 GroupDispatchShareController 的 14 行改动全在 confirm 端点的
  接口文档注释里，GET/DELETE 契约逐字未动

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-21 10:25:34 +08:00
Mimingguang 7c6b6d769c docs(changelogs-v2): #8002/#8064 前端实证 not_required 回写(mmg)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-21 10:12:57 +08:00
Mimingguang 2d8b287ca6 docs(changelogs-v2): #7988 与 #7442 PR-C2 前端增量1已交付回写 verified;PR-A reconfigure 注增量2待建(mmg)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-21 10:10:43 +08:00
API Changelog Bot和Claude Opus 5 9798fb31f4 docs(changelog): #8002 605075 新错误码 + #8064 共用关系成员失去占用后自动收缩
changelog-filename-gate / validate (push) Failing after 1s
详情 
#8002：605008 语义收窄为「等待窗口内没抢到」专用，持锁期内复核/续租发现锁已
丢的 4 处改抛 605075（带 {0} 锁身份标签）。前端不能再把两者都按「系统繁忙，
稍后重试」处理——605075 重试无效且意味着可能已有并发写入。

#8064：接口契约零变化，变的是同一请求的副作用。共用关系的成员因真实释放路径
失去占用时会被自动移出，剩余不足 2 人时关系自动解除。这两件事在修复前于当前
部署形态（占用账本 LEGACY）下一次都没发生过——全库 release_reason=
AUTO_SINGLE_MEMBER 计数由 0 变 1 是它的硬判据。

两份都按 origin/dev-v3=c1a6e96c8 逐条复核过行号与文案；#8002 那份订正了自动
生成稿里的 5 处事实错误，订正记录连同旧值一起留在文件里。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-21 10:00:25 +08:00
Mimingguang acdff03133 docs(changelogs-v2): #8046 用房订房记录前端已交付回写 verified(mmg)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-21 09:49:45 +08:00
Mimingguang 1d1aec6d02 docs(changelogs-v2): #5935 改期残留清理前端已交付回写 verified(mmg)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-21 09:41:37 +08:00
API Changelog Bot和Claude Opus 5 ba87a9b611 docs(changelog): #7987 订正被 mmg 实证推翻的「前端必须新增渲染分支」，并清空 not_required 上的认领字段
changelog-filename-gate / validate (push) Failing after 1s
详情 
正文第 38 行说「前端必须新增这两个 event_type 的渲染分支」，而 mmg 在
frontmatter 里已用实证翻成 not_required（StatusLogsPanel 渲染
eventTypeName || eventType || '事件'，后端直供中文名+原码兜底，前端无自建
映射表，零改动）。订正了状态位却没回头改正文，那句话会让下一个读的人以为
前端还有活。原句划掉保留接 grep，并注明这条结论依赖「后端继续直供
eventTypeName」——该字段哪天返 null，渲染缺口会重新成立。

frontend_owner/frontend_ref 清空：交付指南写死 not_required 条目任何人
（含前端）不得回写这 4 个认领字段，填了会被 E_FRONTEND 残留校验拦下
（2026-08-19 #6077 先例）。本文件能推上去是因为门禁只扫新增路径，
不是因为合规。mmg 的实证本身原样保留。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-21 09:02:10 +08:00
API Changelog Bot和Claude Opus 5 9d4b4387f0 docs(changelog): #8061 清理 status_note 里重复的 gateway_status 说明
changelog-filename-gate / validate (push) Failing after 1s
详情 
连续修订留下一段标着 frontend_status 却在讲 gateway_status 语义的残渣，
标签与内容不符会误导下一个填这个字段的人。内容并入括注，标签改回对的。

mmg 的 frontend_status=not_required 原样保留：他们在自己代码库里查实
getOrderOperationLog(api/fleet/board.js:58) 全仓零调用方、src/views/fleet
无 operationType 命中，后端担心的白名单过滤层尚不存在。那是前端负责人
带证据的判定，比后端的推断硬。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-21 00:15:45 +08:00
Mimingguang 5770e3faa4 chore(changelog): #7980 AC-6 司机险台账同名锁回写 mmg 前端复核 note
changelog-filename-gate / validate (push) Failing after 1s
详情
2026-09-21 00:08:16 +08:00
API Changelog Bot和Claude Opus 5 bc07d07f20 docs(changelog): #7980 AC-6 司机险年保台账两写口补同名锁——新增 100503（内部接口，无 C 端）
changelog-filename-gate / validate (push) Failing after 1s
详情 
PR #8072（合并提交 8bf9c520c）。三个端点都在 /v3/internal/insurance/**，只有 fleet 经
Feign 调，fleet 侧 Controller 全挂 /admin/fleet/drivers/**，无小程序 C 端路径。

🔴 本次只有两个端点新增 100503，不是三个：
- driver-annual/upsert 与 driver-annual/{driverId}/invalidate 共用 name=driver-ins:ledger，
  这两者之间新增互斥，因此新增 100503。
- driver-purchase 补的是自成一域的 name=driver-ins:purchase，锁语义与改前完全等价
  （只是 Redis 键字符串从「类全名+方法名」变成显式 name），未新增任何错误码。

唯一可能传导到 hl-ui 的路径已逐行核实：DriverInsuranceService:352-353 投保后同步作废
旧 MANUAL 台账，失败在 :226 被 catch(AnnualBindingRollbackQueuedException) 捕获并统一
包装成既有错误码 600206，前端看到的仍是既有码，无需为 100503 新增处理。

backend_status=deployed：2026-09-20 23:43 order-v3 滚到 8bf9c520c（运行版本与合并提交
精确相等），两实例 12/13 秒起监听。「八、测试环境已验证」明写了没有做任何功能调用取证、
100503 在测试服上一次都没触发过——是「没测」不是「测过不会触发」，理由是端点不经网关且
手动触发会污染真实司机台账、触发真实保游扣费。

文件名日前缀用 21 是因为提交日已跨过零点；updated_at 同步为 2026-09-21。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-21 00:00:11 +08:00
Mimingguang 8a59255f93 chore(changelog): #8061/#7980 三批同名锁回写 mmg 前端实证,翻 not_required
changelog-filename-gate / validate (push) Failing after 1s
详情
2026-09-20 23:35:03 +08:00
API Changelog Bot和Claude Opus 5 6ce29f1872 docs(changelog): #7980 补三份 @Lock4j 同名锁 changelog（房务7口/出行人+发票8口/产品库存2口）
changelog-filename-gate / validate (push) Failing after 1s
详情 
三份同属一个机制：@Lock4j 未写 name 时 lock4j 把方法名拼进锁键，keys 逐字相同的
多个方法各持一把锁、互不阻塞。本批给各组补同一个显式 name，互斥才真正生效。
对前端唯一可见的变化是这些端点新增一个可能返回的 100503（HTTP 200 + body code）。
路径、方法、请求/响应字段全部零变化。

- 配房工作台 7 个写口（PR #8069）：全 admin，无 mp/C 端。
- 出行人删改 + 发票申请 8 个写口（PR #8049）：三组全部触达小程序 C 端，
  逐端点沿 hl-mp-service 的 Feign 与公网 Controller 查证了调用链。
- 产品库存扣减/恢复 2 个 internal 口（PR #8047）：当前零调用方，修复是预防性的。

三份 backend_status 均为 deployed 且附真实部署读数：product-v2 滚到 ba8aab3ab
（部署前 4cbccc26b，落后 93 个提交）、order-v3 滚到 ba8aab3ab（部署前 c35251b07），
merge-base --is-ancestor 逐个验过。其中 AC-5 的 b9738a20f 在部署前确实不在运行版本内，
是真正的「从不生效到生效」。

🔴 三份的「八、测试环境已验证」都明写了没有做功能调用取证及其原因（写口调用会真实
改动配房行/出行人行/库存，测试服数据多会话共用且撤不回来），并写明 100503 一次都
没触发过——是「没测」不是「测过不会触发」。互斥由落库级并发 IT 与按效果枚举的契约
用例覆盖，这是 name 契约类改动的恰当取证层级。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-20 23:26:24 +08:00
API Changelog Bot和Claude Opus 5 6ade6e1332 docs(changelog): #8061 解除共用关系只清成员占用，同槽非成员不动
changelog-filename-gate / validate (push) Failing after 1s
详情 
fleet 已部署测试服 00930f5d6，网关实测取得阳性与阴性两条对照：
阳性 releasedSourceIds 恰为两个成员且库内真变 unassigned；
阴性 非成员 C 的 assignment_status/vehicle_id/driver_id 解除前后逐一相等。

两条缺一不可——只有阳性的话，「C 没变」与「解除没跑起来」观测相同，
且阳性在修复前同样成立（旧实现一样释放成员，只是顺手把 C 也清了）。

frontend_status=pending：请求/响应字段零增删，但派车操作日志新增
operation_type 取值 share_release_cleared，前端若按白名单过滤会静默
丢掉这条记录，而那正是本次补留痕要解决的问题。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-20 23:21:18 +08:00
Mimingguang 1883b39f8f chore(frontmatter): #7990 AC-8 前端实证翻 not_required(字面渲染无特判)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-20 20:08:06 +08:00
API Changelog Bot和Claude Opus 5 e813ea774d docs(changelog): #7990 候选资源槽位需求锚点按 requirementId 反查（AC-8 修复）
changelog-filename-gate / validate (push) Failing after 1s
详情 
本单名下已有一份 changelog（看板身份三元组，PR #8048），但按内容 grep 那份已推送
文件，requirementMatched / seatsEnough / requirementMismatchReasonCode / 候选 / 座位
六个关键词全部 0 命中——AC-8 的候选面行为变化一个字都没有。

这正是 #7443 被重开的形态：按单号数文件全绿，按内容查全空。所以另写一份，
而不是让那份顶数。

行为变化（POST /admin/fleet/assignments/candidates）：
TRANSFER-only 订单上，seatsEnough / requirementMatched / requirementMismatchReasonCode
由「恒空/退化」变为按 TRANSFER 需求真实判定。

修复前 AssignmentCandidateService.resolveSlotRequirement 的车型/座位锚点恒取 TRAVEL
需求：两类并存时接送机槽锚到 TRAVEL 需求的第 fleetItemIndex 项；TRANSFER-only 单上
取到 null、锚点整块退空、座位判据回退到整单 headcount，于是 5 座 SUV 反而「够」，
只剩车型一条提示（少报一半）。

两种失败出口都是 SlotRequirement.empty() 这条「仅提示不限制」的正常路径——不抛错、
不打日志。车务只看到提示不对，没有任何信号能顺藤摸瓜。这条静默属性已写进正文。

网关实测（2026-09-20 22:0x，同一次请求两辆车判定截然相反）：
7 座 SUV 蒙A-U1557 → seatsEnough=true / requirementMatched=true / reasonCode=null；
5 座 SUV 蒙P321A → seatsEnough=false / requirementMatched=false / reasonCode=SEATS。
修复前两车都会是 requirementMatched=null。这组阴性对照排除了「返回一堆候选但根本
没过滤」这个竞争解释。

取证前先补了部署缺口：开测时 fleet 停在 c35251b07，而 bf4fba5a2(#8062) 触及 fleet
却未部署，重新部署到 0/N 才开测，否则会测到旧字节。

请求契约完全不变：修法是按 requirementId 匹配式反查 kind，不是给请求补 kind 位。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-20 20:00:03 +08:00
Mimingguang 8ce545aa7e chore(frontmatter): #8051 前端实证维持 not_required(全仓零命中,知会点已收)
changelog-filename-gate / validate (push) Failing after 1s
详情
2026-09-20 19:48:07 +08:00
API Changelog Bot和Claude Opus 5 ff834a4858 docs(changelog): #8051 订正 PR 字段——写的是「待建」，实际已合入 ac9efb735
changelog-filename-gate / validate (push) Failing after 1s
详情 
交接件里的「待建」会活得比它的语境久：下一个人看到它会以为代码还没合。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-20 19:40:10 +08:00
API Changelog Bot和Claude Opus 5 52b3f81fd0 docs(changelog): #8051 解除共用关系不再跨服务日跨团误清派车行
changelog-filename-gate / validate (push) Failing after 1s
详情 
代码 PR #8058（squash ac9efb735）已合入 dev-v3，fleet 测试服部署在 c35251b07
（2026-09-20 18:58，STATE=ok），merge-base --is-ancestor ac9efb735 c35251b07 = 真，
并用 jar 字节正负两向自证：新类 AssignmentOccupancyDayScope 部署前不在 jar 里、
部署后在（只查后一次没有分辨力）。

网关两轮独立实测 DELETE .../share-groups/{id}?survivorPolicy=RELEASE，两半边都取了：
- 阳性对照：本服务日那张确实被处理（assigned/有车 -> unassigned/NULL，且在
  releasedSourceIds 里）；
- 负对照：跨日的独立派单三字段逐一不变，跨日+跨团的原受害者所在三个团七个服务日
  共 7 行 fleet_group_dispatch 释放前后逐字段完全一致。
缺任一半，「另一日没变」与「解除根本没跑起来」观测上完全一样。

frontend_status=not_required：本次不改请求/响应形状、不增删字段、不新增错误码。
但仍是给 mmg 的知会件——「解除共用关系」这个动作的影响范围变了，看板上此前莫名
变成「待派车」的那些户，原因在此。

一并订正两处事实：
- 误伤是 6 行不是 7 行（第 7 行同日同槽，RELEASE 策略下本就在处置范围，补了日期
  过滤照样会被释放）；
- 修复只动了 ASSIGNMENT 侧，GROUP_DISPATCH 侧本就按 trip_date 精确过滤、从无此 bug。

仍未解决且不在本篇范围：同一资源同一服务日上的非成员在途行仍会被 RELEASE 一并
软清（releaseClaims 不引用 members），已另立工单 #8061 待产品口径。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-20 19:39:07 +08:00
Mimingguang 27ec0f1eb1 chore(frontmatter): #7987/#8013 前端实证翻 not_required,#7988/#8046 维持 pending 记挂起口径,#8030 补 589596 订正复核
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-20 19:16:14 +08:00
API Changelog Bot和Claude Opus 5 91cca38c2e docs(changelog): #7987 #7988 #8013 网关实测通过，gateway_status 置 verified，并订正 #7987 一处契约偏差
changelog-filename-gate / validate (push) Failing after 2s
详情 
2026-09-20 18:22-18:46 经网关 api.test.1814.love:9443 实测（账号 cw_test_7444）：

- #7988 GET .../vehicle-requirement：七个只读观测字段全部出现，字段名/类型与正文
  一字对应，逐字段对照无出入。
- #7987 GET .../status-logs：开窗（BATCH_VEHICLE_REQUIREMENT_REOPENED）与重配
  （BATCH_VEHICLE_DISPATCH_RECONFIGURED）两类事件均取到，extra 各项齐全。
- #8013 POST/GET .../share-groups：只改 costBearer 不改成员，写出的历史行是
  COST_BEARER_CHANGED 而非 MEMBER_ADDED，且按正文声明的口径用事后 GET 查证，
  没有拿 POST 响应体推断。

订正 #7987 一处契约偏差（5 个位置）：重配事件的 operatorId 正文写字符串 "SYSTEM"，
实测为 null，与库里其它 SYSTEM 类事件（如 BATCH_VEHICLE_REQUIREMENT_DONE）惯例一致，
判为文档写错而非实现错。前端若按原文档判空会得到相反预期，故订正与发布同一批。

backend_status 的判据是 merge-base --is-ancestor 对各自 squash 提交与测试服部署点
（fleet 311dc92ee / order-v3 e179e09bd）逐条为真，不是「已在主线」这种弱判据。

verified_at 留空：该字段归 frontend_status 用，与 gateway 的验证时刻是两码事。

同批还有 #7444 与 #7973 两份草稿未推送，gateway_status 如实保持 pending——
#7444 缺 reconfigure / restore-cancel happy path / DELETE 三处证据，
#7973 的 confirmCrossResident 入参未被真正走到（目标资源已占用，未触发 605036 分支）。
「同一个端点被调通了」不等于「本篇登记的那个入参被验过了」。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-20 19:00:10 +08:00
jw和Claude Opus 5 304477d880 docs(changelog): order-v3 团期用房新增子订单订房记录接口（#8046）；回填 #8030 实测并订正错误码
changelog-filename-gate / validate (push) Failing after 2s
详情 
#8046 新增接口条目（含 TEST 真实响应、AC-1~AC-11 实测读数、地域字段该用
district 而非 city 的实测依据）。

同时补两处 #8030 的遗留：
- 「八、测试环境已验证」当时留着「待部署后回填」的占位没填，现按当轮实测回填；
- 正文里的降级错误码 589574 订正为 589596（589574 是 #7932 的保留位）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-20 19:00:06 +08:00
Mimingguang 72bb0ff4ad docs(changelog): #7990/#7964 前端实证 not_required(#7990 TRAVEL 流程逐字正确,TRANSFER 取参口径入 memory;#7964 internal 不可达)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-20 18:02:12 +08:00
Mimingguang bb2814981d docs(changelog): #7443 AC-24 前端实证维持 not_required(契约零变化;canonicalSnapshot null 自验静默 return;挂起条件已收紧)
changelog-filename-gate / validate (push) Failing after 1s
详情
2026-09-20 17:59:52 +08:00
API Changelog Bot和Claude Opus 5 73e0def125 docs(changelog): #7990 车务看板订单详情按需求各返一组身份三元组，接送机确认参数有来源了
changelog-filename-gate / validate (push) Failing after 2s
详情 
GET /admin/fleet/board/orders/{orderId} 新增 requirementIdentities：
每条用车需求各一项，含 kind / requirementId / requirementVersion /
requirementSha256 / dispatchPlanGeneration。
顶层原有的那一组三字段语义不变，仍指行程用车（TRAVEL），前端不改也不炸。

为什么前端必须接：POST /admin/fleet/assignments/requirements/{id}/confirm
的三个 expected 入参（version / sha256 / planGeneration，均 @NotNull 或 @NotBlank）
唯一公开来源就是本端点，而此前它只给 TRAVEL 那一组
⇒ 接送机需求在管理后台确认不动。

同时修掉一个必 500 的场景：同一订单同时有两条已确认需求时，
本端点每一次都抛 IllegalStateException。现改为正常返回；
真出现无法判定的代际时抛新业务码 605311（HTTP 200）。

行为变化（是修复不是回归）：接送机需求未定稿时，它的待派车行
现在会出现在逐日计划里——那些行归它自己的需求，先前隐藏它们才是缺陷。

gateway_status=verified 的依据是真实调用不是推断：经测试网关拿到
requirementIdentities 两项后，原样用于需求级确认返 code=200、
confirmed=true、finalPlanPublished=true ⇒ 该字段不只是返回了，
而是真的能驱动接送机确认走通。

Refs #7990

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-20 17:59:50 +08:00
jw 867e5ad790 docs(changelog): order-v3 订单取消同事务失活用车需求，已取消户不再进 fleet 待配车池（#7964）
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-20 17:57:22 +08:00
API Changelog Bot和Claude Sonnet 5 24dde670d1 docs(changelog): #7443 AC-26 TRANSFER 派车行四端点网关实测收尾，gateway_status 回填 verified
changelog-filename-gate / validate (push) Failing after 2s
详情 
四个既有端点（candidates/change/confirm(assignmentId)/confirm(requirementId)）经网关
逐一实测通过；此前缺失的 confirm(requirementId) 借新上线的
GET /admin/fleet/board/orders/{orderId} requirementIdentities 字段取得
expectedRequirementVersion/Sha256/expectedPlanGeneration 真值补齐验证。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
 2026-09-20 17:52:04 +08:00
Mimingguang d3028eb02a docs(changelog): #7980 AC-4 发票三写口锁 前端实证翻 not_required(admin 两写口拦截器透 message,mp 侧归 mp loop)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-20 17:49:25 +08:00
API Changelog Bot和Claude Opus 5 9ee36c0b94 docs(changelog): #7980 AC-4 发票签发组三写口补同一把锁，新增可重试冲突码 100503（会触达小程序 C 端）
changelog-filename-gate / validate (push) Failing after 2s
详情 
order-v3 的 InvoiceAdminService.issueInvoice / reuploadInvoice 与 InvoiceMpService.reissueInvoice
三处 @Lock4j 写了逐字相同的 keys 却都没写 name；lock4j 的 Redis 键在 name 缺省时退化成
「类全限定名+方法名」，于是三处各持一把锁。后果是 reupload ∥ reissue 会留下一单两张有效票。
本次三处补同一个 name = "order-invoice:issue"。PR #8043 → 09b8f2323 已合 dev-v3。

接口路径、方法、请求/响应字段、既有错误码全部零增删。唯一契约变化是新增一个可能返回的错误码 100503
（RESOURCE_LOCKED「资源被占用,请稍后重试」），且它以 HTTP 200 + body code 返回——
前端只看 HTTP 状态码会把它当成功。

该码会触达小程序 C 端：reissue 经 hl-mp-service 两个入口透传
（MpV3InvoiceController:54 直接透传；MpInvoiceController:108 经 getCheckedData()，
Result:143-148 用上游 code 原样重抛）。用户点「申请重开发票」时若财务端正在同一张票上操作，
等最多 3 秒后收到该提示；反向同理。此前这几条互不阻塞。

测试服证据（backend_status 因此才从 pending 转 deployed；此前门禁 E_BACKEND_PENDING 正确拦下过一次，
没有为换绿灯改状态，而是去把部署真的做了）：运行版本 5d14bc524，
merge-base --is-ancestor 09b8f2323 5d14bc524 → YES。
⚠️ 如实记：部署前 COMMIT 已是 5d14bc524（另一会话此前推上去的），本次重跑不等于「使它从不生效变生效」。

🔴 证据强度按实际收窄，没有拔高：redis-cli MONITOR 抓到键
lock4j:order-invoice:issue#order-invoice:issue:<invoiceId>、无方法名混入，
但 MONITOR 只跑了三个写口里的一个（issueInvoice）；另两处由代码同源 + 反射守卫用例
InvoiceIssueLockNameGuardTest（断言三处 name 非空且相等）覆盖，未在测试服上单独抓包。
正文里 §2/§3 原本写「同第 1 节，链路一致」会被读成「也实测过」，已改成明确写「未单独抓包」。

100503 未复现：并发两个 issueInvoice，一个 code=200、另一个 code=581502（INVOICE_CANNOT_ISSUE
业务状态守卫），不是锁超时码。原因是临界区极短（与 fleet 那轮 34 并发未触发同因）。
第二个请求被业务守卫拦下说明没产生并发脏写，但这是旁证不是互斥证据。
两面都写：路径源码级真实存在（已读码确认 + IT 里实测过等 3024ms），但测试服未能触发，
不代表更长事务／生产数据量下不会触发。

取证干净：三张票全是测试夹具（客户名「核团甲/乙/丙」，apply_reason 为 #7932 造数），
改前均 REQUESTED/NULL/NULL，已按改前快照逐列 UPDATE 还原并复读一致，
Redis --scan lock4j:*order-invoice* 复扫为空。过程中发生过一次 code=401（token 被别的会话顶掉），
该次调用前无任何读数，已重登并把那段整个重做。

顺带修掉一个会挂门禁的文件名 bug：原名后缀写的是「小程序管理后台」，而 changelogs-v2/ 根目录
要求端类型字面量必须是「管理后台」，改名前文件名校验确实报 E_CLIENT。

Refs #7980

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-20 17:47:14 +08:00
Mimingguang 0cd51c06b4 docs(changelog): #7972 前端实证维持 not_required(809114/584131 零命中走拦截器,TRANSFER 不可达)
changelog-filename-gate / validate (push) Failing after 1s
详情
2026-09-20 17:43:23 +08:00
API Changelog Bot和Claude Opus 5 8ff7f0761e docs(changelog): #5935 改期残留清理——前端要的能力已具备，用现有读写口即可
changelog-filename-gate / validate (push) Failing after 2s
详情 
前端 2026-09-20 待办清单第 4 项要求读侧补 residueServiceDates 日期数组，
并称写口 POST .../slots/{slotId}/clear-residue-dates 已就绪。两条都不成立：

- 那个写口在 origin/dev-v3 上零命中——「槽位(slot)」概念已随 #7067 退役，
  基于 slotId 的写口不会再有；
- 读侧能力早就有，只是不叫 residueServiceDates：candidates 响应的 cells[]
  逐日带 rescheduleResidue + serviceDate + assignmentId，
  另有 editableServiceDates 已并入残留日期。

故本件是用法说明，后端零代码改动：逐日清理走 DELETE /assignments/{id}，
整批清理走 POST /batch 不提交残留项（diff 会精确取消）。
已写明真正的写侧边界——POST /batch 有「已过去日期不可改」硬门禁，
而改期后延场景的残留日多半已过去。

DELETE 路径对已过去日期是否放行未取证，如实标【需确认】；
若实测也挡住，那才需要另开工单放开残留行的过去日期取消。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-20 17:41:05 +08:00
Mimingguang 875a682ea9 docs(changelog): #7925/#7937/#8023/#8030 前端接入「用房·汇总」建页交付,翻 verified(mmg@9a14ad86)
changelog-filename-gate / validate (push) Failing after 2s
详情
2026-09-20 17:39:04 +08:00
API Changelog Bot和Claude Opus 5 41c0f752f9 docs(changelog): #7972 接送机的免车闸与结算闸改为非对称判据，809114 放宽 / 584131 新增拒绝
changelog-filename-gate / validate (push) Failing after 2s
详情 
PR #7976（572dc4037）改了两个既有错误码的抛出条件，零新增错误码：

- 809114（整团免车被派车阻塞）改为只看 TRAVEL——「只订接送机、没有团车」
  是合法的在团户，不该被上游拒绝免车，属于放宽。
- 584131（团期用车未就绪）对 TRANSFER 补独立的非对称判据：不存在放行 /
  DONE 放行 / 其余拒。原 TRAVEL 的抛出与放行结论逐字不变。
  整团免车现在只短路 TRAVEL 一支，两类互不豁免。

🔴 运维注意已写进正文：存量里停在 PENDING 的 TRANSFER 需求行，其所在户的
finalize 会从 200 变 584131——那是本次改动的预期行为，不是回归。

backend_status=deployed 依据 572dc4037 是测试服 order-v3 所在提交的祖先；
gateway_status=not_required 依据本次不涉及网关路由变更（仅后端判定条件）。
校验器 PASS，校验对象 4 个端点。

Refs #7972

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-20 17:35:19 +08:00