docs(changelog): #8061 清理 status_note 里重复的 gateway_status 说明

连续修订留下一段标着 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>

changelogs-v2/2026-09/20_8061_解除共用关系只清成员占用同槽非成员不动-修改接口-管理后台.md

@@ -12,7 +12,7 @@ frontend_owner: ""
 frontend_ref: ""
 target_release: ""
 verified_at: ""
-status_note: "backend_status=deployed：PR #8067 squash 为 00930f5d6，2026-09-20 22:42 已部署到测试服 192.168.100.236，deploy-status.sh 复核落点 = 00930f5d6，Nacos 两实例（8087/8187）healthy=true。gateway_status=verified：2026-09-21 在测试服网关上以全新三户夹具（团期 2101690789438570497、服务日 2026-10-30）取得阳性与阴性两条对照——阳性：releasedSourceIds 恰为两个成员且库内真变 unassigned；阴性：非成员 C 的 assignment_status/vehicle_id/driver_id 解除前后逐一相等。两条缺一不可：只有阳性的话，「C 没变」与「解除没跑起来」观测相同，且阳性在修复前同样成立。详见正文「八、测试环境已验证」。frontend_status=pending：本字段记的是「网关验证有没有做过」，不是「网关路由要不要改」——按 BACKEND_CHANGELOG_DELIVERY_GUIDE 的标准搭配 deployed/verified，以及 2026-08 #5405/#5407 的先例（『测试环境部署和网关验证尚未执行，因此 backend_status、gateway_status 保持 pending』）。本次确实不新增端点、不改路由形状，但网关上一次真实调用尚未打过，故 pending，不是 not_required。frontend_status=pending：请求/响应字段确实零增删，但派车操作日志时间线新增了 operation_type 取值 share_release_cleared——前端若按 operation_type 白名单过滤，这条会被静默丢掉，用户就看不到『车和司机是被哪次共用关系解除清掉的』，而那正是本次补留痕要解决的问题。⇒ 前端至少需要确认自己有没有这层过滤、必要时加上，这是动作不是知会，故 pending。另按指南，not_required 会禁止 mmg 回写 frontend_owner 等认领字段，填错反而挡住认领。mmg 前端实证 2026-09-20:fleet 操作日志读口 getOrderOperationLog(api/fleet/board.js:58)在全仓零调用方,src/views/fleet 无 operationType 命中——后端担心的「时间线按 operation_type 白名单过滤会静默丢 share_release_cleared」过滤层在前端不存在(该时间线 UI 尚未建),故前端零改动,翻 not_required。后续接入操作日志时间线时 operation_type 渲染必须包含 share_release_cleared(detail_json 全字段字符串 ID 透传)。share-groups 解除入口前端未接入,属 #7444 挂起域,同 #8051 口径。"
+status_note: "backend_status=deployed：PR #8067 squash 为 00930f5d6，2026-09-20 22:42 已部署到测试服 192.168.100.236，deploy-status.sh 复核落点 = 00930f5d6，Nacos 两实例（8087/8187）healthy=true。gateway_status=verified：2026-09-21 在测试服网关上以全新三户夹具（团期 2101690789438570497、服务日 2026-10-30）取得阳性与阴性两条对照——阳性：releasedSourceIds 恰为两个成员且库内真变 unassigned；阴性：非成员 C 的 assignment_status/vehicle_id/driver_id 解除前后逐一相等。两条缺一不可：只有阳性的话，「C 没变」与「解除没跑起来」观测相同，且阳性在修复前同样成立。详见正文「八、测试环境已验证」。（📌 gateway_status 这个字段记的是「网关验证有没有做过」，不是「网关路由要不要改」——先例见 2026-08 #5405/#5407：『测试环境部署和网关验证尚未执行，因此 backend_status、gateway_status 保持 pending』。本次不新增端点、不改路由形状，但那不构成填 not_required 的理由，填 verified 的理由是上面那次真实调用。）frontend_status：后端起初填 pending，理由是——请求/响应字段确实零增删，但派车操作日志时间线新增了 operation_type 取值 share_release_cleared——前端若按 operation_type 白名单过滤，这条会被静默丢掉，用户就看不到『车和司机是被哪次共用关系解除清掉的』，而那正是本次补留痕要解决的问题。⇒ 前端至少需要确认自己有没有这层过滤、必要时加上，这是动作不是知会，故 pending。另按指南，not_required 会禁止 mmg 回写 frontend_owner 等认领字段，填错反而挡住认领。mmg 前端实证 2026-09-20:fleet 操作日志读口 getOrderOperationLog(api/fleet/board.js:58)在全仓零调用方,src/views/fleet 无 operationType 命中——后端担心的「时间线按 operation_type 白名单过滤会静默丢 share_release_cleared」过滤层在前端不存在(该时间线 UI 尚未建),故前端零改动,翻 not_required。后续接入操作日志时间线时 operation_type 渲染必须包含 share_release_cleared(detail_json 全字段字符串 ID 透传)。share-groups 解除入口前端未接入,属 #7444 挂起域,同 #8051 口径。"
 updated_at: "2026-09-20"
 base: "dev-v3"
 ---