提交图
5 次代码提交
作者 SHA1 备注 提交日期
Mimingguang 830b8109e0 docs(changelog): #7443 A+B 订单侧已交付 verified(hl-admin v2.1 6c091ef24)
changelog-filename-gate / validate (push) Failing after 2s
调整弹窗双槽+显式 kind 写口+结算 step3 requirementKind 归属;C 车务侧属 18_7443 另起交付
2026-09-21 17:23:09 +08:00
API Changelog Bot和Claude Opus 5 4fbf5ec2c0 docs(changelog): 20_7443 删掉把前端推向「问上线时间」的两处措辞
changelog-filename-gate / validate (push) Failing after 1s
「生产环境未开」暗示生产上存在这个开关、只是关着——实际 order-v3 根本没上生产
(2026-09-21 探生产网关,/v3/** 与 /admin/fleet/** 全 404,一期 /admin/order/page
与 /admin/product/page 同时 200 做阳性对照)。前端据此来问「请后端把生产开关打开」,
是照本文档做的。

「上生产前请与后端确认这个开关的状态」是一条派给前端、他查不了、且只影响
「什么时候开始写」而非「怎么写代码」的动作项,整句删除。

一并去掉两处部署时间戳(2026-09-19 15:33)——交接件不写上线/部署时间。
改后只留环境无关的契约事实:默认 false、关闭时返 809009、测试服已开。

⚠️ E_WAIT_LANGUAGE 没能拦住这两句:它按词表匹配「等/待/另发」,而这两句一个都没用上,
靠的是把不确定性包装成「请你去确认」。词表拦不住换了语法的同一件事。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-21 16:16:08 +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 f5596bf88e docs(changelog): 20_7443 按 CHANGELOG_TEMPLATE 重构分章节,过接口类门禁(#7443)
changelog-filename-gate / validate (push) Failing after 1s
E_API_TEMPLATE 要求接口类正文必须有 二/三/四/六/七/八/十/关联 八个章节。
内容零丢失,只重组结构并补齐模板要求的缺失章节。

三处不能丢的都逐字保留:
- 覆盖边界(本文只验到「提交」为止;TRANSFER 同步车务 outbox 恒 605905)
  在「六、边界行为」子节原样保留,文首「关键变化」只做导读不做替代
- 阳性对照注脚(两字段 fleet 恰好相同不能证明按 kind 取数生效,真正证明
  它的是全 null 对照与 id 不同)在「八」原样保留
- 809002/809009 分开处置(去补大交通 / 找后端开开关)新建对照表,两码
  各自一行,不混提示

代理顺带查实并订正三处:
- 路径参数按源码 AdjustmentAdminController 实为 {id} 而非 {orderId}
- status 枚举以 RequirementStatus 为准共 6 个;RespVO 注释里的 CLAIMED
  在源码里根本不存在,已显式点出分歧而非悄悄抹平
- 文件实际行尾是 LF 不是 CRLF,按现状保持
2026-09-20 15:35:01 +08:00
API Changelog Bot b8a079fda0 docs(changelog): 调整订单「车辆安排」页同页提交行程用车+接送机用车两类需求(#7443)
后端已合入 dev-v3(PR #8024 -> 920f29d76)并部署测试服,四条真实网关调用取证:
读口双槽(带全 null 阳性对照) / 一次 submit 同交两份落两条 active 行 /
两条 label 原文不同的调整记录 / 无大交通时 809002。
service_dates 两个 kind 分别派生成行程三天与接机送机两天,前端一个日期都不传。

覆盖边界写在正文与 status_note 里: 本文只验到「提交」为止。同一次实测观测到
TRANSFER 需求同步车务的 outbox 恒失败 605905(fleet AssignmentService:11492
取当前需求不带 kind),前端可并行开工但端到端尚未打通。
2026-09-20 15:35:01 +08:00