docs(changelog): #7442 订正两份交接件的部署顺序结论——按单算的"顺序无所谓"在并集里是错的

两份文档各有一句部署顺序结论： - reconfigure 补登：「万一要分批，order-v3 先滚风险更低」 - 就绪回写补登：「本单不强制要求特定先后顺序」两句按各自那次改动算都是对的，分析段也都标了范围（reconfigure 那份甚至明写「本单与 #7957 的『fleet 必须先滚』不同」）。错的是结论句把限定丢了，读起来像是对这次部署的建议。而 PR-C2（#7957）后来在同一个 GroupBatchDispatchBaselineDTO 上加了 reconfigureWindow，它强制 fleet 先于 order-v3：order-v3 先滚时旧 fleet 收到 dispatchable=true 直接放行重配，不读 reconfigureWindow、不校验令牌与范围，「受控重开」当场退化成「不受控重开」——而两端日志都正常、没有任何报错。今天要部署的人面对的是这些改动的并集，不是某一单。 ⇒ 两份都补了订正框，并把实操答案写死：同批滚；必须分批时 fleet 先、 order-v3 后。同时立了一条规矩：写部署顺序结论一律带上「截至某日期/commit，这个 DTO / 这批部署单位上还有哪些已合入的改动」这个限定——按单写的部署结论会在下一次改动落到同一个对象上时变成陷阱，而它不报错，也没有人会回来改它。原分析段逐字保留，只给结论句补范围。 Refs #7442 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-19 14:30:07 +08:00
@@ -300,8 +300,23 @@ POST /admin/fleet/group-dispatch/batches/1934567890123456800/reconfigure
  乘车分组清单」），**这是本单与 PR-C2 最大的不同**：PR-C2 的 `dispatchable` 放宽会被旧 fleet 静默忽略、
  放行了本不该放行的请求；本单缺 `groups[]` 则是**整个新端点在这段时间内全部请求都报 602009**——响应是
  **明确的错误码，不是静默放行**，运营/车务会立刻发现"这功能用不了"而不是"这功能用了但结果不对"。
- **结论**：两个方向都不会产生数据错乱，区别只是"功能完全不可用一段时间"（fleet 先滚）还是"零影响"
-  （order-v3 先滚）。**仍然建议同批滚**（消除过渡期报错），但万一要分批，**order-v3 先滚风险更低**。
+- **结论（⚠️ 只对本单这一次改动成立，不要拿它指导今天的部署）**：**单看本单**，两个方向都不会产生
+  数据错乱，区别只是"功能完全不可用一段时间"（fleet 先滚）还是"零影响"（order-v3 先滚）。
+
+> 🔴 **2026-09-19 订正：上面那句"order-v3 先滚风险更低"是按本单单独算的，拿它指导实际部署会出事。**
+> PR-C2（#7957，2026-09-18 合入）**后来在同一个 `GroupBatchDispatchBaselineDTO` 上又加了
+> `reconfigureWindow`**，而今天要部署的人面对的是**两次改动的并集**，不是本单。
+> 对并集而言正确答案是 **fleet 必须先于 order-v3**：order-v3 先滚 ⇒ 旧 fleet 收到 `dispatchable=true`
+> 直接放行重配，它不读 `reconfigureWindow`、不校验令牌与范围 ⇒ **「受控重开」当场退化成「不受控重开」，
+> 而两端日志都正常、没有任何报错**（详见 `19_7442_团期配车受控重开窗口计划刷新状态收口…md`「部署清单」
+> 与 PR [#7957](https://git.1814.love:8443/wx/HL/pulls/7957) 正文「⚠️ 部署：fleet 必须先于 order-v3」）。
+>
+> ⚠️ 上面那段按单分析**本身没错、也标了范围**（见本节标题与开头那句「本单与 #7957 的『fleet 必须先滚』
+> 不同」）——错的是**结论句把限定丢了**，读起来像是对这次部署的建议。
+> **按单写的部署结论会在下一次改动落到同一个 DTO 上时变成陷阱**，而它不会报错、也没有人会回来改它。
+> ⇒ 今后写部署顺序结论，一律带上「**截至 &lt;日期/commit&gt;，本 DTO 上还有哪些已合入的改动**」这个限定。
+
+**⇒ 今天的实操答案：同批滚；必须分批时 `fleet` 先、`order-v3` 后。**

 ### 消费方清单不能按 `pom.xml` 直接依赖关系查

@@ -309,8 +324,9 @@ POST /admin/fleet/group-dispatch/batches/1934567890123456800/reconfigure
 `grep -rl 'hl-common-core' */pom.xml` 只命中 `hl-gateway`/`hl-finance`，order-v3 与 fleet 都经
 `hl-common-web` 传递引入，不在直接依赖清单里，但正是本单真正改了代码的两个服务。

-⇒ **实际部署单位共 7 个**：gateway / user / resource / product-v2 / order-v3 / mp / fleet；
-本单不强制要求特定先后顺序，但**同批滚**仍是最稳妥的做法。
+⇒ **实际部署单位共 7 个**：gateway / user / resource / product-v2 / order-v3 / mp / fleet。
+**同批滚**；必须分批时 **`fleet` 先、`order-v3` 后**（理由见上方 2026-09-19 订正框——
+本单自身不强制顺序，但同一个 DTO 上的 PR-C2 强制了，今天部署的是两者的并集）。

 ---

@@ -396,8 +396,17 @@ POST /v3/internal/group-batch/1934567890123456800/vehicle-ready-reset
  不会报错也不会解析失败，等价于"这个请求体被忽略了"，order-v3 仍按改动前的无身份逻辑处理。**净效果**：
  两级判定这项保护在这段过渡期内**还没有生效**（旧漏洞——乱序/旧版回调污染就绪状态——仍然存在），
  但不会比改动前更糟，也不会报错或崩溃。
- **结论**：两个方向都不会比"改动前"更差，区别只是"保护何时开始生效"。**仍建议同批滚**，让两级判定
-  尽快对新回调生效，避免过渡期内继续吃"旧漏洞"的亏。
+- **结论（⚠️ 只对本单这一次改动成立，不要拿它指导今天的部署）**：**单看本单**，两个方向都不会比
+  "改动前"更差，区别只是"保护何时开始生效"。
+
+> 🔴 **2026-09-19 订正：不要据此认为"顺序无所谓"。**本单自身确实不挑顺序，但**同期还有别的改动**
+> 落在同一批部署单位上——PR-C2（#7957）在 `GroupBatchDispatchBaselineDTO` 上加了 `reconfigureWindow`，
+> 它**强制 `fleet` 先于 `order-v3`**（order-v3 先滚 ⇒ 旧 fleet 不校验窗口令牌，「受控重开」静默退化成
+> 「不受控重开」，两端日志都正常）。今天部署的是这些改动的**并集**。
+> ⚠️ **按单写的"顺序无所谓"，在并集里就是错的**，而且它不会报错、没有人会回来改它。
+> ⇒ 写部署顺序结论一律带限定：「**截至 &lt;日期/commit&gt;，这批部署单位上还有哪些已合入的改动**」。
+
+**⇒ 今天的实操答案：同批滚；必须分批时 `fleet` 先、`order-v3` 后。**

 ### 消费方清单不能按 `pom.xml` 直接依赖关系查

@@ -405,8 +414,9 @@ POST /v3/internal/group-batch/1934567890123456800/vehicle-ready-reset
 `grep -rl 'hl-common-core' */pom.xml` 只命中 `hl-gateway`/`hl-finance`，order-v3 与 fleet 都经
 `hl-common-web` 传递引入，不在直接依赖清单里，但正是本单真正改了代码的两个服务。

-⇒ **实际部署单位共 7 个**：gateway / user / resource / product-v2 / order-v3 / mp / fleet；本单不强制
-要求特定先后顺序，但**同批滚**仍是最稳妥的做法。
+⇒ **实际部署单位共 7 个**：gateway / user / resource / product-v2 / order-v3 / mp / fleet。
+**同批滚**；必须分批时 **`fleet` 先、`order-v3` 后**（本单自身不挑顺序，但同期 PR-C2 挑，
+今天部署的是并集——见上方 2026-09-19 订正框）。

 ### 🔧 2026-09-19 补充取证：PR 正文与本节结论的矛盾判定依据