3034 次代码提交

此分支

此分支

所有分支

作者	SHA1	备注	提交日期
API Changelog Bot和Claude Opus 5	a4b92733f5	docs(8182): 订正种子脚本行号引用 171/203 -> 171(ESCALATED)/202(TIMEOUT) ... 原写 203 是行号记错一位（逐字核对为 202）。同时把「改前取值以种子脚本为准」的依据 从「读了一份文件」升级为穷举：整个 db/migration 里出现 inapp_link_template 的文件共 8 份，涉及这两个询房事件码的只有种子 V20260520_002 与本单 V20260922_210，中间没有 第三份改过它们——否则种子值就不等于改前值。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 17:49:52 +08:00
API Changelog Bot和Claude Opus 5	c356e8b564	docs(changelog): 订正 #8182 交接件里两条询房事件的「改前」取值（?id= 而非 ?inquiryId=） ... 原文表格把 HOUSE_INQUIRY_TIMEOUT / _ESCALATED 的改前模板写成 /pages/house/inquiry?inquiryId=${inquiryId}，实际种子值是 ?id=${inquiryId} (V20260520_002__house_notification_event_config.sql:171/203，逐字核对)。 迁移脚本按 event_code 定位、SET 绝对值，行为不受影响；迁移测试的夹具种的也是 正确的 ?id= 原值，只有交接件正文这一处写错。顺带补一句说明 query key 由 id 改名为 inquiryId，以及这两个事件码当前没有发布方、改名无实际调用差异。 Refs #8182 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 17:40:37 +08:00
API Changelog Bot和Claude Opus 5	2c9b21f796	docs(changelog): #8182 HOUSE 内部员工站内信 link 由小程序路径订正为管理后台路由，并明确 bizId 不是路由键（修复-管理后台） ... 三个内部员工事件码(HOUSE_INVENTORY_CHECKED / HOUSE_INQUIRY_TIMEOUT / HOUSE_INQUIRY_ESCALATED)的 inapp_link_template 由 /pages/house/* 改为 /housekeeper/*；字段结构不变，变的是值。 本条 frontend_status=pending 而非 not_required：22_8155 写过「前端 jumpToBiz 从不读 row.link，无需前端改动」，那句话仅在 REQUIREMENT_REJECTED 上成立—— 核房/团期事件的 bizId 根本不是订单，按 bizId 反推跳转必然打开不存在的订单。 正文已点名 22_8155 并写清适用范围。 Refs #8182 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 17:38:41 +08:00
Mimingguang	a2120cf1ec	chore(8181): 回写前端核验 not_required(渠道渲染数据驱动自动生效,历史映射保留)	2026-09-22 17:38:15 +08:00
Mimingguang	5a33baba38	chore(frontend): 回写两份 22_frontend 交接件已交付 verified(取值订正 cf37e7f6 / 补列 369ed5b4)	2026-09-22 17:33:58 +08:00
yaosutu	a0413a53be	docs(changelog): #8181 线下收款废除报账人代收DRIVER_CASH渠道——options出参channels移除DRIVER_CASH+register新增520417（尾款收款模型重构PR-1，修改接口-管理后台）	2026-09-22 17:07:15 +08:00
jw和Claude Opus 5	165cbcb69a	docs(changelog): 团期三张子订单表的前端渲染缺陷两份交接件（GB-ADM-003 后端零改动） ... 整团名单速览、子订单、查看需求三张表吃同一个接口 GB-ADM-003 GET /v3/admin/order/group-batch/{groupBatchId}/orders，同源所以同病： - 22_frontend_整团名单速览与子订单表…：联系人列显示占位符「—」应取 customerName； 房型列显示英文枚举码（KING）应取 roomTypeName（豪华大床）。 - 22_frontend_查看需求Tab子订单表…：同样两处取值问题，外加只有 5 列、 要补齐到子订单表的列集（团号/房型·间数/状态/需求审核/联系电话/应收/游客/资料）。 后端零改动，两份均已回填测试服活体实测读数：团期 2101506167098511362 全量 12 户， customerName 12/12 有值、roomType→roomTypeName 12/12 翻译正常（KING→豪华大床）； 图示那一行的 12 列逐列与实测值逐字吻合。附排查提示：travelers 12/12 为空数组且 travelerInfoComplete 恒 false，联系人若从出行人明细推导即会恒显「—」。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 16:57:39 +08:00
Mimingguang	1e59aac339	chore(8152/8164): 回写前端闭环(8152 订正残留已清 0b65814a;8164 核验 not_required 透 message 自动覆盖)	2026-09-22 16:35:50 +08:00
Mimingguang	9dbec55501	chore(8161): 回写前端已交付 verified(biz-recon 单据对账下钻,ref 5072da0b)	2026-09-22 16:25:47 +08:00
Mimingguang	4a8e301d39	docs(changelog): #8154 前端已交付回写 verified(hl-admin 9c5dd0cb)	2026-09-22 16:00:09 +08:00
API Changelog Bot和Claude Opus 5	000e93c6be	docs(changelog): 8152 交接件补记前端侧同源残留两处（statusName 编造取值的下游落点） ... e011960 订正了本交接件里 statusName 的四个编造取值，但那四个字符串已被 hl-admin 抄进两处：VehicleHouseholdsSection.vue:191 的注释与该组件 spec 的夹具。两处都不影响运行（组件 :78 是纯透传、用例断言的是透传行为）， 但下一个人 grep「待处理」会同时撞上它们，需要能分清哪些是错的。 同时把责任归属写明：四个取值是后端先写错在交接件里、前端照抄的。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 15:36:32 +08:00
API Changelog Bot和Claude Opus 5	e011960e45	fix(changelog): 订正 8152 交接件 vehicle-households 端点 statusName 编造取值 ... `three` 处示例/字段说明里的 statusName 中文值（"已完成"/"待处理"）系凭空编造，既不是修复前的房务口径值（"配房完成"/"待房务配"），也不是修复后的车务口径值。核对 GroupBatchConverter.resolveRequirementStatusName(code, true) 源码后改为实测口径：PENDING→待车队配、PROCESSING→配车中、DONE→配车完成。 同时订正 六.5 枚举表里同样错误的三个取值，并补一段说明——该端点 statusName 原实现直接取 RequirementStatus 枚举的房务侧 label，已由 45adfd7ed（PR #8173）改调 resolveRequirementStatusName(code, true) 修正，附完整取值表。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 15:16:10 +08:00
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