MailUI4Agents

Files

JianFeeeee f604badf86 判据: 三条判据锚在"实现位置"上，A 步搬家后假红 —— 改成锚不变量

用户裁定做 A（harmony 补 store 层）之后，`harmony-logic.test.mjs` 红了 4 条。
**一条都不是 bug**：它们读 `pageCode`（`MainPage.ets`）找那些调用，
而调用已经搬进 `common/MailStore.ets`。

这正是本仓反复出现的形状：**判据锚在实现位置上，而不是它声称的东西上**。
一处实现搬家（哪怕搬得更对）就假红 —— 而假红比漏报更坏，
它会让人去改本来对的代码。

★ 修法：引入 `compositionCode`（页面 + store 合起来看），按**归属**拆断言
  · **取数/组装**（谁调 `sumUnreadTotals` / `partialLoadNotice` /
    `groupMailsBySession`）→ 读 `compositionCode`
  · **渲染**（用户看到什么：单封平铺、多封按展开态、组头可点、卡片视图）→ 仍钉 `pageCode`
    （那是页面该管的事，不该被搬走）
  不变量是"这条纯逻辑真的被用上了"——**用它的人搬去哪一层不该让判据红**。

★ 顺带修掉一条**自己骗自己**的断言（变异测试抓出来的）
  「先分家再折叠」原本写成 `splitAt < groupAt` 两个 `indexOf` 比大小，
  并断言两个都 `>= 0`。我把顺序反过来做变异 —— **它没红**：
  因为反过来之后第二个字面量变了、`indexOf` 返回 -1，红的是"两个都 >=0"
  那条，而不是顺序那条。也就是说：**顺序这条判据从来没在判顺序**。
  改成直接断言**数据流形状** `groupMailsBySession(split.normal)` ——
  它同时表达"折叠的是筛过的那批"与"必须先分家"。再变异（换成 `mergedMails`）
  ⇒ fail=2，这次真的咬住了。

★ 判据 14 也从一条拆成两条（取数侧 / 渲染侧），名字改成
  「折叠逻辑真正接上了（不是"逻辑写好了没人用"）—— 取数侧 + 渲染侧都要在」。

harmony-logic 32/32 绿。注册数不变（拆一条加一条，净持平 32）。

2026-09-20 11:34:44 +08:00