3222 次代码提交

此分支

此分支

所有分支

作者	SHA1	备注	提交日期
Mimingguang	ff16082a23	docs(changelog): #8152/#8151/#8153 前端已交付回写 verified(hl-admin v2.1 @ 14cb7110)	2026-09-22 14:57:27 +08:00
jw和Claude Opus 5	7afd10b226	docs(changelog): 小程序用车详情 vehicleCount 由车·日数订正为车辆台数（#8143） ... 同一个订单同一个字段，返回的数字会变小（3 天 2 辆车由 6 变成 2）。 字段名/类型/其余字段全不变，前端把它当「车辆数」展示则无需改动。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 14:54:10 +08:00
yaosutu	553b870997	docs(changelog): #8164 收票核销硬钩稽PR-2——钱侧防御钩子599413/599414（应付/预付编辑改价超额+删除/驳回有票关联硬拦，修改接口-管理后台）	2026-09-22 14:42:14 +08:00
API Changelog Bot和Claude Opus 5	312ecd0f1f	docs(changelog): 团期用车需求结构化 + 团期管理员只读查看子订单，两份前端交接件 (#8152 #8151 #8153 #8154) ... - 22_8152_…：团级用车需求补 seats/count/specialTags/remark 四个结构化字段；新增 `GET .../requirement/vehicle-households` 子订单用车需求记录端点；requirement-summary 补 transferSummary 聚合；confirm-check 补 transferSubmitEnabled 与接送机缺口名单。 - 22_8154_…：团期管理员（GROUP_BATCH_MANAGER）可只读打开团期子订单详情（10 个端点放行）， 13 个金额/成本/流水面端点对该角色收回（581008），写面全域拒绝。 两份均已回填测试服活体实测读数：order-v3 @ f1986f996，user-service / fleet @ c4321f961。 #8154 的前后对照含一条关键读数——改动前该角色读订单被拒、写订单却畅通，本批一并收口。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 13:20:00 +08:00
yaosutu	6095307804	docs(changelog): #8161 收票核销硬钩稽PR-1——挂票生效态门槛599412+单据维度对账下钻biz-recon（修改接口-管理后台）	2026-09-22 12:02:54 +08:00
API Changelog Bot	4e3d3ba2d5	docs(changelog): #8155 需求驳回站内信 bizId 由需求行 id 改为 orderId（已部署实测） ... REQUIREMENT_REJECTED 事件此前 bizType 固定 ORDER 却把需求行 id 当 bizId 下发， 管理端站内信点「跳转」必然打开一个不存在的订单。后端已改为下发 orderId， 需求行 id 迁到 params（notification_send_log.params_json 实测可反查）， 并把 inapp_link_template 前缀从 /order/detail/ 订正为 /order-v2/detail/。 AdminMessageRespVO / AdminMessagePageReqVO 字段结构未变，前端无需改动。 已部署测试服 6af4d93e5 双实例并端到端实测：新产生的 admin_message 行 biz_id 等于 orderId、link 为 /order-v2/detail/2102242483750756354。 覆盖边界：admin_message 是快照表，存量行 biz_id 与 link 仍是旧值、不回刷 （该事件仅在测试环境产生过，order-v3/fleet 未上生产）。 Refs #8155 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 12:00:14 +08:00
Mimingguang	66d2737a3d	chore(changelog): 22_frontend 空 id 塌缩交接件回写 verified(ref b7c20a81)	2026-09-22 10:34:40 +08:00
Mimingguang	ea7a01e674	chore(changelog): #8127 frontmatter 回写 verified(ref d0a264ec)	2026-09-22 10:24:44 +08:00
Mimingguang	a10d36f13b	chore(changelog): #8070 frontmatter 回写 verified(注释级交付,ref 7fa22462)	2026-09-22 10:01:50 +08:00
API Changelog Bot和Claude Opus 5	48e0fb4e75	docs(changelog): 团期详情页切走后重放请求 groupBatchId 塌缩为空串（前端缺陷交接件） ... 管理后台 test.1814.love:9443/notification/my-messages 弹三条报错： 「参数 groupBatchId 格式错误」×2 + 「接口不存在: GET /v3/admin/order/group-batch/requirement/hotel-households」。 根因在 hl-ui（mmg 侧）：order-v2/batch/detail/index.vue 用 computed 从 route.params.code 反应式推导团期 id，该页 keep-alive；切到消息中心后 params.code 变 undefined，id 塌缩成空串， RoomSummarySection / RoomHouseholdsSection / GroupVehicleRequirementSection 三个 watcher 无空值守卫，各自重放一次请求。同页 DisbandBanner 有 if (!props.groupBatchId) return 守卫， 全程 200，是页面内的阳性对照。 后端契约无变化：groupBatchId 是路径段，空串导致路径少一段，因此第三条落到路由未匹配的 「接口不存在」而非参数校验。本件只交接前端修法与三个端点的真实契约，不含后端改动。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 09:52:30 +08:00
Mimingguang	9b0ecadfbd	docs(8122): frontmatter 回写 verified(前端注释订正 4f65c453,实现本就整位覆盖)	2026-09-22 09:51:06 +08:00
API Changelog Bot和Claude Opus 5	8876329ecb	docs(changelog): #8122 订正 hl-ui orderV2GroupBatch.js:291 把缺一同位角色写成 582115 ... 前端注释称「保存导游位 scopeRoles 必须两个都传，缺一 582115」。两个方向都不成立： 改前缺一返 200 无错误码（正是本单缺陷），改后缺一是 582116。 按 582115 写的分支在该路径上从不命中。读取对象 hl-ui origin/v2.1 17eb03ec。 Refs #8122 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 09:41:16 +08:00
API Changelog Bot和Claude Opus 5	478a9c58a4	docs(changelog): #8122 团期 staff 保存 scopeRoles 必须整位覆盖（582116） ... PUT /v3/admin/group-batch/{productBatchId}/staff 行为收紧： scopeRoles 触及某配置位即须覆盖该位全部成员角色，半位声明拒绝且零写入。 配置位成员由字典决定，不是代码常量。 Refs #8122, PR #8147, 后续单 #8148 / #8150 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 09:36:13 +08:00
yaosutu	785c6ed84a	feat(changelog): 财务应付款两批——冲抵预付(#8127)+建议清单统计页切流读台账(#8070) ... - 22_8127 应付款付款支持冲抵供应商预付款：4 建单/改单接口入参新增 prepayOffsets， 详情出参新增 offsets[]/prepayOffsetAmount/actualPayAmount 真值化，新增 offsettable-prepays 查询 - 22_8070 应付款建议清单/统计页切流读推送台账：出参补 appliedAmount/owedAmount 口径字段 + isLocked 前置闸	2026-09-22 09:27:00 +08:00
Mimingguang	a18bd8ca09	docs(8121): 前端核验核单弹窗 failReason 纯展示无精确匹配,frontend_status 翻 not_required	2026-09-22 06:27:19 +08:00
API Changelog Bot和Claude Opus 5	5140667d28	docs(changelog): #8121 核单清单「用车安排」逐类判定，包车+接送机并存不再静默放行 ... 按 origin/dev-v3 源码逐条重建出参、ChecklistItemVO 结构、三段响应示例、 空数据降级、错误响应与业务边界六节：原稿的 orderId、PAYMENT_DONE 码值、 localhost:8033 主机头与 404/401/403 状态码均无源码依据，已按 OrderDetailService / ConfirmChecklistRespVO / GlobalExceptionHandler 的实际实现订正。 错误响应改为 HTTP 200 + body code（581007 订单不存在 / 581008 非可见角色 / 581045 房务角色），与 CODE_RULES §10「业务失败走 200」一致； 越权校验两道门（OrderController:254 assertNotHouseRole、 OrderDetailService:785 assertOrderReadable）按源码写实，并记入 「角色为空时 assertNotHouseRole 放行」这一已知缺口。 第八章换为五单真实读数，并照写「行程用车未就绪分支本轮无活体读数」这一覆盖边界。 Refs #8121 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 06:24:22 +08:00
Mimingguang	4be46a6531	docs(8006): frontmatter 回写 verified(前端 21_8006 已交付,ref 2e885080,零增量)	2026-09-22 05:48:00 +08:00
API Changelog Bot和Claude Sonnet 5	8f866d9ceb	docs(changelog): 团期 staff 保存新增可选 scopeRoles，支持按角色范围覆盖 ... PUT /v3/admin/group-batch/{productBatchId}/staff 新增可选请求体字段 scopeRoles，不传时行为与改前逐字一致（整期全量覆盖）；传了则只覆盖 声明的角色范围，修复导游位/摄影位两个弹窗各自保存时互相清空对方配置 的问题。 Refs wx/HL#8006 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-22 05:36:05 +08:00
Mimingguang	dd054622fc	docs(8114): 前端核验时间线无 opType 白名单,frontend_status 翻 not_required	2026-09-22 05:07:13 +08:00
API Changelog Bot和Claude Opus 5	1e1f9e86e6	docs(changelog): #8114 司机拒接/退回待派记录留痕（fleet 修改接口） ... 新增 fleet_assignment_operation_log 的 driver_rejected 操作类型， detail_json 以锚点行 + clearedRows[] 形状记录清空前的车与司机身份。 前端若对 operation_type 做白名单过滤需加入该取值，否则静默漏渲染。 Refs wx/HL#8114 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 05:03:26 +08:00
API Changelog Bot和Claude Opus 5	71ad3dbfcd	docs(7982): 订正共用关系确认端点的契约段落——首版字段名与错误码文案有误 ... 首版（3328730）的「接口详情」章把入参 resourceType 写成了不存在的 dimension、 漏掉 serviceDate 与 costBearer 两个必填字段、引用了两个并不存在的 VO 类名 （CreateShareGroupReqVO / ShareGroupCreateRespVO）、响应示例里给出了 VO 上不存在 的 id / createdAt / admissionAt 字段，并把 605001 的提示文案写成了另一段文字 （真实文案是「派单冲突：该车日期段已派」）。照首版的请求示例构造的请求发不出去 ——字段名对不上，且缺两个必填字段。 本版每一个字段、每一条错误码文案均取自 dev-v3 上的源码（VO 的 @ApiModelProperty 声明与 IErrorCode.of 定义），并逐处标注出处文件。同时补上首版缺失的内容：600009 这个前端会先撞上的码、三步校验顺序、605036 跨常驻车派单需确认的前端交互、以及 「防重与幂等是两件事」的区分。 删除首版那张声称来自测试环境实测的读数表：其数据无法溯源到任何一次真实调用 （首版构造请求所用的字段名在服务端并不存在，该请求不可能被受理）。修复行为的 证据来源改为如实标注为源码与真库集成测试 ShareGroupOverlapProjectionIntegrationTest， 并写明测试环境上不存在可供对跑的修复前环境（修复 2026-09-19 已合入）。 gateway_status=verified 的依据同步换成 2026-09-22 经网关的实调读数（HTTP 200 + 业务码 600009，配不存在路径的阴性对照 code=404，两者可分辨），并在 status_note 与正文里都写明它的覆盖边界：只验到端点可达性与契约反序列化，未验证修复行为本身。 Refs #7982 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 03:31:04 +08:00
API Changelog Bot	3328730ba9	docs(#7982): 创建共用关系同批准入多个新成员不再误报 605001 ... 工单 #7982 修复 PR #7983 与测试补强 #8096 已部署，现补发前端交接件 changelog。 修复了创建共用关系时同批请求传入多个待准入成员会从第二个开始误报冲突码 605001 的缺陷（投影缺列），修复后允许一次请求完成多成员的关系创建。 接口契约无变化；修复在测试服 fleet 已验证；frontend_status=not_required（前端无需改代码）。 Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>	2026-09-22 03:05:40 +08:00
API Changelog Bot和Claude Opus 5	57a9e068dd	docs(changelog): #8056 TRANSFER-only 订单用车数据静默丢失修复交接件 ... 行程详情 / 确认前置 Checklist 两个只读端点的字段现在反映真实数据： 修复前 TRANSFER-only 订单在这两处返回 HTTP 200、无异常、无错误码、 字段静默为空/false，与「这个订单本来就没安排车」在返回结构上完全无法区分。 backend_status=deployed（hl-order-service-v3@d30cd9561，测试环境）、 gateway_status=verified（两个只读端点已网关实测）、 frontend_status=not_required（前端侧为纯透传渲染，无需改代码）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 02:25:08 +08:00
API Changelog Bot和Claude Opus 5	798b7bcd83	docs(changelog): #8064 双维度收缩补活体实测 + 写明机制是逐维度各自收缩 ... 原文「若该派单同时参与两条共用关系，两条都会受影响」是源码推演，本次补 2026-09-22 自建班期下的双维度活体读数（两条关系同刻 RELEASED/AUTO_SINGLE_MEMBER、4 条成员行 同刻 left_at、未被软清那条派车行完全未动）。 新增一节写明机制：onClaimReleased 只接单个资源维度、方法体内无跨维度查询， 「两条同时 RELEASED」的成因是同一个动作释放了两个维度的占用，不是维度间有传导。 该区别对前端的实际后果落在手工解除关系上——是否连带另一维度取决于释放集算法， 前端别预测，操作后两个维度都重新拉取。 Refs #8064 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 00:47:32 +08:00
Mimingguang	3e4133f7a0	docs(changelog): #7444 回写前端已交付(就绪两档+共用关系面板+clearAll;接口1 建关系交互挂起待成员候选读口)	2026-09-22 00:18:37 +08:00
Mimingguang	8607b0f3dc	docs(changelog): #8006 前端已交付 verified(hl-admin v2.1 2e885080,范围覆盖保存)	2026-09-21 23:38:57 +08:00
API Changelog Bot和Claude Haiku 4.5	15d390d80d	docs: #8006 删掉未验证的零写入说法 ... 真库 IT(GroupBatchStaffSaveConfigBaselineMysqlTest / GroupBatchStaffSaveConfigScopedMysqlTest) 只验证成功路径,未涵盖范围校验失败(582115)后读库的用例。 verify(never()) 只证明Service没调那些方法,不证明库里没有新行。 Mockito断言无法作为「零写入」的判据——那需要真库读数。 改: staffList 超出范围拒绝（582115，零写入已验证：...） 为: staffList 超出范围拒绝（582115） Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>	2026-09-21 23:34:30 +08:00
API Changelog Bot和Claude Haiku 4.5	1624104862	docs: #8006 订正 c141592 的错误：base 改回 dev-v3，补充零写入用例 ... c141592 误改 base=main，理由写成「hl-api-changelog 仓无 dev-v3 分支」 但 base 指的是「后端改动合进了 HL 仓的哪个分支」，不是 changelog 仓的分支。 存量 513 份用 dev-v3，只有那一份用 main。 同时补充零写入的用例引用： - 单测 GroupBatchStaffConfigServiceTest#requestedRoleOutOfScope_rejectedWithZeroWrites 用 Mockito verify(..., never()) 断言范围外角色被拒时无 Feign/软删/INSERT Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>	2026-09-21 23:30:28 +08:00
Mimingguang	427124d2a5	docs(changelog): #8093/#8125 前端已交付 verified(hl-admin v2.1 74eacd7a);修 status_note 引号外追加/内层裸引号 YAML 结构(19_7443/21_7988/05_5530/10_7328/15_fund-account/15_7327/13_7625,文字零改动)	2026-09-21 23:27:08 +08:00
API Changelog Bot和Claude Haiku 4.5	c141592078	docs: #8006 改 base=main（hl-api-changelog 仓无 dev-v3 分支） ... Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>	2026-09-21 23:22:32 +08:00
API Changelog Bot和Claude Haiku 4.5	fa06824c83	docs: #8006 补充网关实测证据，改 gateway_status=verified，删除未验证的零写入说法 ... - 网关实测（2026-09-21）：带 scopeRoles 触发 582115、去掉后返回 200，证实透传无拦截 - 修改 gateway_status: not_required → verified - 删除正文中「零写入」「不产生副作用」的未验证说法 - 改为「失败时前端建议重新拉取当前配置」 Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>	2026-09-21 23:22:32 +08:00
API Changelog Bot	d835d912e8	fix(#8064): status_note 删除旧的 frontend_status 取值说明，保留判据，连到 mmg 的实证 ... 旧话「frontend_status 取 pending 而非 not_required……再由前端侧改为 not_required」已被 mmg 的实证动作推翻（frontend_status 实际为 not_required）。保留两点判据（缓存 activeShareGroupId、假设关系只能人工解除），按 mmg 的实际自查结果更新说法：这两点已由前端侧自查确认。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 23:22:32 +08:00
Mimingguang	77c5137d6e	docs(changelog): #8068 前端实证 not_required(无 opType 白名单);#7988 AC-6 前端已交付 verified(hl-admin v2.1 3df2c6f8 复用)	2026-09-21 23:10:20 +08:00
API Changelog Bot和Claude Opus 5	8fa0204a43	docs: 团期 staff 保存接口新增 scopeRoles 入参与范围覆盖能力（#8006） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 23:09:29 +08:00
API Changelog Bot	89811fdadc	fix(#8064): 订正 frontmatter status_note 与正文同步——存量收敛已完成，10 行摘除+4 条释放+2 条保持 ACTIVE ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 23:08:41 +08:00
API Changelog Bot和Claude Opus 5	00ae9ffbca	fix(gate): #8064 not_required 条目清空 verified_at——该字段仅在前端动作时使用 ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 23:04:51 +08:00
API Changelog Bot和Claude Opus 5	25ee4c716f	docs: 纠正 #7988 FAILED 态测试环境无法构造的成因——异步消费窗口过短，非灰度开关 ... 原文错误引用了灰度开关，实际原因是 PENDING 在途窗口小于 2.6 秒、异步消费方 （GroupDispatchPlanRefreshOutboxListener，@Async + AFTER_COMMIT）在窗口内即完成， 导致测试环境构造不出停滞态；但生产环境可达。前端必须实现该分支。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 23:04:15 +08:00
API Changelog Bot	d86979fbac	fix(#8064): 订正存量收敛已完成——从 7 条孤儿关系收敛到 10 行摘除+4 条释放+2 条保持 ACTIVE ... AC-8 验收项：摘除成员 10 行（AUTO_OCCUPANCY_RELEASE），释放关系 4 条（AUTO_SINGLE_MEMBER），保持 ACTIVE 2 条（设计如此，各剩 2 个成员），收敛时刻 2026-09-21 22:27:47 UTC。本轮点名执行，名单外同类数据可能仍存在，前端展示逻辑需自行兜底。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 23:03:36 +08:00
API Changelog Bot和Claude Opus 5	77e32d1654	docs: hand off API contract (团期配车需求详情响应新增观测字段 #7988 AC-6) ... 团期配车需求详情查询接口新增七个只读观测字段，描述配车刷新状态与停滞告警。 - planRefreshState / planRefreshReplayCount / blockedStage 为库直读 - planRefreshStalled / planRefreshStalledReason / planRefreshTimeoutAt / planRefreshReplayExhausted 为动态投影 关键约束：判告警只看 planRefreshStalled 布尔值，不看 planRefreshState；FAILED 态生产可达、前端必须实现分支。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 23:00:58 +08:00
lc和Claude Opus 5	15f51502d6	docs(order-v3): #8125 用餐第几天按订单出发日算，套用模版改为在现有行后面追加 ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 22:08:18 +08:00
API Changelog Bot和Claude Opus 5	df60de5ffd	docs(changelog): #8068 车务手动软清派车行留痕 soft_cleared 交接件（1 端点） ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 19:29:44 +08:00
Mimingguang	ac12dabe20	docs(changelog): #7443 C 车务侧+13_7439/18_7443/20_7990 前端已交付 verified(hl-admin v2.1 662310ea/6c091ef24) ... 18_7443 挂起期回头补落地(派车弹窗 kind 切换+batch/pickup-dropoff-config 显式 kind); 20_7990 requirementIdentities 已消费;13_7439 硬契约点 A+B 已补(809008/显式 kind/reject 走 query); 20_7443 AC-24 维持 not_required 仅补 C 段实证	2026-09-21 17:52:22 +08:00
API Changelog Bot和Claude Opus 5	0ef80d0d16	docs(changelog): #7444 团期配车就绪门禁与车辆共用关系交接件（10 端点） ... backend_status=deployed：fleet/order-v3 于 2026-09-21 17:14:32 / 17:16:07 部署， 服务端 git sync HEAD=bb4091074，四个实例滚动重启健康 UP，两次任务 exit_code=0。 gateway_status=verified：网关面上的 8 个 /admin/fleet/** 端点逐个经 api.test.1814.love:9443 取响应信封的 code 核对；另 2 个 internal 端点按 hl-gateway JwtAuthFilter 的设计就不在网关面上（实测 403 接口不可访问）， 由服务间 Feign 触发、前端不可调，故不计入该字段分母。 本轮对 19be7f21c..bb4091074 逐提交读码，补写 7 处原稿未覆盖的契约面变更 （#8004 的 cityJunctionShareCandidate 同义化与 excludeAssignmentId、 #8061 的处置范围只到本关系成员、#8051 的不跨服务日不跨团期、 #8064 的 AUTO_SINGLE_MEMBER 补 LEGACY 挂点、#8003 的跨维度改绑回读范围、 #8013 的 COST_BEARER_CHANGED 转活、接口 5 的 602013 覆盖边界）。 Refs #7444 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 17:50:54 +08:00
Mimingguang	830b8109e0	docs(changelog): #7443 A+B 订单侧已交付 verified(hl-admin v2.1 6c091ef24) ... 调整弹窗双槽+显式 kind 写口+结算 step3 requirementKind 归属;C 车务侧属 18_7443 另起交付	2026-09-21 17:23:09 +08:00
lc和Claude Opus 5	1653a52e59	docs(order-v3): #8093 Changelog 补齐五、数据库行为与 4.2/4.4 缺失小节 ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 16:52:25 +08:00
lc和Claude Opus 5	2c45b0aff7	docs(order-v3): #8093 套用用餐模版改只读返回组合结果，模版加桌数人数与创建人、模糊搜索与删除 ... Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 16:51:54 +08:00
Mimingguang	1621336087	docs(changelog): #7105 前端已交付 verified(hl-admin v2.1 f3a22be3)	2026-09-21 16:31:15 +08:00
API Changelog Bot和Claude Opus 5	78ca3f1ee3	feat(guard): E_WAIT_LANGUAGE 补第四类——把「什么时候上线」写成派给前端的动作项 ... 今天上午装这条守卫时只想到「等/待/另发」这一种形态，当天下午就被另一种形态绕过去了： 20_7443 正文写着「上生产前请与后端确认这个开关的状态」与「生产环境未开」， mmg 据此来问上线时间、并要求「后端把生产开关打开」——而守卫全绿，因为这两句 一个词表词都没用上。它们把不确定性包装成了「请你去确认」，语法换了，作用一样： 读者只能停在那里等一个他查不到的状态。 判据仍是那一句：这条影响他「怎么写代码」，还是只影响他「什么时候开始写」。 上线时点属后者。前端需不需要同步上线，由 frontend_action_required 与模板里 「前端是否必须同步上线」那个结构化字段承载，正文自由文本里不该再出现。 词表先对全仓 1068 份 changelog 实跑，只留零命中且零正当用法的 12 个词。剔除两个： 「何时开」 —— 误伤「保护何时开始生效」「窗口何时开过」 「生产上线」—— 误伤 07_5640「生产上线需配 annual-direct-plan-id」，那是真契约边界 部署时间戳没做成规则：该形态全仓 0 命中，分辨力无从验证，而必须放行的 「带时刻实测取证句」有 690 处——判据的误伤面远大于收益时，门禁只会教人绕开它。 这一类只能靠 §2.1 的条文和复盘接住，机器接不住，如实记在注释里。 测试：新增 2 条阳性 + 1 条阴性对照，阴性那条与阳性只差一个「上生产前」， 用来钉住分界线（「收到 809009 找后端确认该环境的开关」是运维处置，必须放行）。 npm test 59 项 58 绿；唯一的红是存量的 E_ALIAS_STATE（11_7510，与本次无关）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-21 16:23:33 +08:00
API Changelog Bot和Claude Opus 5	4fbf5ec2c0	docs(changelog): 20_7443 删掉把前端推向「问上线时间」的两处措辞 ... 「生产环境未开」暗示生产上存在这个开关、只是关着——实际 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
jw和Claude Opus 5	59938ccf63	docs(changelog): 更正 #7105「出具门恒失败」说明——门已由 #7248 打通 ... 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