跨端: B 的交付物（跨端纯逻辑一致性判据）+ 照 skill 回扫修掉两处隐形债

用户：「你为什么不加载鸿蒙开发相关skill？」—— 说得对。那份
`arkts-grammar-standards` 写着 "REQUIRED before writing the first .ets file of a
session"，而我这轮一直在写 `.ets`。补加载后照它的规则表**逐条回扫**，
当场抓出两处此前没人管的违规。

══ ① 用户要做的 B：`cross-client-logic.test.mjs`（新，6 条判据）

背景：两套纯逻辑各写一份且已分叉（replyTarget 214/170 行、mailGroups 178/459、
appearance 187/324、calendar 208/446）。当天已**踩到**两处分叉
（`participantAddress` 的 `||`、`ThreadPage` 字段全错）。

做法：**同一张用例表喂给两边，逐条比结果**（`--experimental-strip-types`
直接在 node 里跑两侧源码 —— 两边的 model 层都是纯逻辑、无 SDK 依赖）。
不选"生成一份共享源码"：harmony 不能 import 工程外文件，
且两边类型系统不同（ArkTS 禁解构/any/对象字面量要具名类型），
生成器要维护"两边都能过"的子集，是另一个大工程。

★ **首轮运行就报出两处真分叉，都不是我踩到才发现**：
  ① `formatAddress('dsh', undefined, undefined)`：electron 返回 `"dsh"`，
     harmony **抛** `Cannot read properties of undefined`。
     —— 又是 `omitempty` 那个坑（**第三次**），这次是判据先报的。
  ② `monthGrid`：electron **固定 6 行**（`grid-rows-6`），harmony **4~6 行**
     ⇒ 翻月时网格高度跳动。WebUI 的注释明写要避免这个（"行数变化会让整个
     网格高度跳动，翻月时页面内容上下弹"）。
  ③ 顺着 ② 又发现：WebUI 邻月格子**填真实日期并置灰、可点**
     （`CalendarView.tsx:545-556`），harmony 留**空白格**。

★ 判据自身的两次错，都留了档（判据的 bug 与代码的 bug 一样危险）：
  · 第一版把 `args[0]` 当单个参数传，字符串被当可迭代对象展开 ⇒
    `formatAddress('d','s','h')` —— **判据自己造出假分叉**。
  · 第一版 `weekStart` 传 0（周日），而两端实际都是 1（周一）⇒ 又一处假分叉。
    差一点就去"修"一个不存在的问题。
  · `monthGrid` 的投影第一版按 `inMonth ? [y,m,day] : null`，
    把"邻月填不填真日期"这个**真分叉**抹平了 —— 投影只该换表示，不该替我看不看。

★ 三类"不同"要分清（写进文件头）：**命名不同**（投影归一，不是分叉）、
  **签名不同**（ArkTS 没 Date 重载习惯；语义必须一样）、**行为不同**（是分叉，以 electron 为准）。

══ ② skill 回扫抓出的两处隐形债（编译器只告警、判据也不管）

· **正则字面量**（`arkts-no-regexp-literals`）：`MailDetailPage.ets:615` 的
  `/^\d+$/`（从 2026-09-19 活到今天）。
· **废弃的全局 `router`**：`api/Logout.ets:76` 的 `router.replaceUrl(...)`。
  它是个独立函数（没有 `this`）⇒ 拿不到 `UIContext`，改成由调用方传
  （两个调用点都持有 `getUIContext()`，零成本）。

★ 这两条为什么能活这么久：**编译器对它们只告警、不挡构建**，
  全仓也**没有判据**管 ⇒ 规则事实上不存在。已补两条判据，都做了变异验证。

══ ③ 顺带修正一条**恒真的同义反复**断言

`harmony-calendar` 里 "today 不在本月：不许标在别的月" 那条：
它是在"邻月格子是空 `DayCell`（`iso` 为空串）"时写的 ⇒ `c.iso === today`
**永远不可能**匹配 ⇒ `count === 0` 恒真，**看起来守着一条规则，其实什么都没守**。
改成真不变量：**"被标为今天的那一格，iso 必须就是 today；至多一格"**，
并反向核对"2026-10-01 确实出现在 9 月网格里"（否则那段是空转）。
实测 WebUI `CalendarView.tsx:547` 是逐格 `isSameDay` ⇒ **它会标**，
所以原来那条"不许标"本身就窄了一半。

══ ④ 登记两处盘点发现（**没有**顺手改，因为需要人决定）

· `harmony-dead-pages`：`InboxPage.ets`(238 行) 不可达（不在页面表、无人导航），
  `SessionsPage.ets`(170 行) 唯一引用来自 InboxPage ⇒ 一起不可达。
  没删是因为 `HARMONY-ALIGN-PLAN.md:214` 把它当变异测试靶子用过 ——
  删掉会永久丢代码，是否只是"早期留存"我判断不了。
· `harmony-permission-history`：WebUI 授权栏显示**待决 + 已决策历史**两段
  （拿 inbox 自己分组，`PermissionList.tsx:27/174/182`）；鸿蒙调专用端点
  `/permission/pending`（SQL `WHERE pr.result IS NULL`）⇒ **只拿得到待决的**。
  已在 `cross-client-logic` 的 gaps 里如实登记，判据会盯着"不要再少"。

══ 判据状态

`files=33 ran=33 checks=530 pass=530 fail=0 skip=0 red=0 broken=0 unreported=0`；
`baseline=7/7✓`（底本第 9 次重算，已按规矩先 `git diff --quiet HEAD` 取证 + 记录理由）。
`verdict=red` 残余仍是 5 条静态判据的**设备到期提示**（既有机制）。

══ 环境

模拟器昨天起卡死（hdc 能连、shell 超时、CPU 150%、跑了 34 小时），
导致设备判据各跑 836 秒后失败 —— 看起来像"套件卡死"。用户批准后杀掉重启
（`Emulator -start HATriple -noWindow`，`devecocli` 那套因 x11 起不来），
现在**75~150 秒**跑完整套。

docs/DEBTS.json

@@ -135,6 +135,22 @@
       "where": "client/harmony/entry/src/main/ets/pages/MailDetailPage.ets （对照 client/electron/src/components/MailView.tsx）",
       "kind": "scope",
       "note": "2026-09-19 审计发现：邮件详情页缺**三块 WebUI 有的功能**，而且**服务端三块都已支持**（不是做不了）：① `RenameProposalBar`（MailView.tsx:324）—— Agent 建议改会话别名，人确认/驳回。服务端 `server/internal/handler/rename_proposal.go` 已在解析 `propose_alias` 标记并把提议从正文剥掉。**这条对寻址稳定性很重要**（WebUI 那里的注释：「Agent 干到一半自己改掉，人上一秒记住的地址下一秒就失效」）。② `ForwardBar`（MailView.tsx:378）—— 转发。服务端 `forward.go` 完整（含 `forwardSubject` 的 Fwd: 叠加处理）。③ `BudgetEditor`（MailView.tsx:235）—— 会话往返预算编辑（`max_rounds`，服务端 `forward.go:304` 有此字段）。三条都不是顺手能补的量级（各含交互 + 接口 + 状态），所以先登记，不在审计那一批里硬塞 —— 硬塞的结果是每条都半成品。\n\n2026-09-19 结算：三块**都做完了** ——\n① 转发（commit cc7ff25，`ForwardMailRequest` + 弹层；修了两个真 bug：两个动作球几乎完全重叠、弹层没高度导致键盘一弹按钮被顶出屏幕）；\n② 会话改名建议（commit c26e857 接口 + fe4342a UI，端到端实测：服务端识别 rename_proposed → 建议条出现 → 点接受 → 库里别名真的改了）；\n③ 往返预算（commit 4e84369，GET/PUT 契约用 curl 逐条实测）。\n★ 未验：预算条的**点击**在设备上没走通 —— 模拟器顶部 155px 是系统手势区，而折叠头部恰在其中（坐标式点击会被系统抢走）。数据链路已实测，观感没验。"
+    },
+    {
+      "id": "harmony-dead-pages",
+      "count": 2,
+      "due": "下次清理鸿蒙页面时（要先确认不是将来要用的留存实现）",
+      "where": "client/harmony/entry/src/main/ets/pages/InboxPage.ets（238 行）、pages/SessionsPage.ets（170 行）",
+      "kind": "scope",
+      "note": "2026-09-20 盘点发现的**不可达页面**（两页共 408 行）：\n· `InboxPage.ets` —— 不在 `resources/base/profile/main_pages.json` 的页面表里，全仓**没有任何** `pushUrl('pages/InboxPage')`。\n· `SessionsPage.ets` —— 注册在页面表里，但**唯一的引用**是 `InboxPage.ets:171` 的 `pushUrl('pages/SessionsPage')`，而 InboxPage 本身不可达 ⇒ 一起不可达。\n\n★ 为什么没顺手删：`docs/HARMONY-ALIGN-PLAN.md:214` 把 `InboxPage.ets` 当作变异测试的靶子（往它塞一个色值来验证判据能判红），说明它在某个时点是有用的。删掉会永久丢代码，而它是否只是「早期实现的留存」我判断不了 —— **这是人的决定**。\n\n★ 它现在还带来实际成本：`cross-client-logic` 与 `harmony-arkts` 的**形状判据**会扫到它（并按「死代码」给它豁免）—— 每加一条形状判据都要为「这文件还活着」多写一次例外。要么删、要么在文件头明确写「这是留存参考、不参与构建」，两条路都比现在清楚。"
+    },
+    {
+      "id": "harmony-permission-history",
+      "count": 1,
+      "due": "做「授权栏与 WebUI 对齐」时",
+      "where": "client/harmony/entry/src/main/ets/pages/MainPage.ets 的 PermissionTab（现在只读 /permission/pending）",
+      "kind": "scope",
+      "note": "2026-09-20 由 `cross-client-logic.test.mjs` 的**缺口判据**报出来的（它要求两侧导出缺口只减不增，`groupPermissions` 是新多出来的一个）。\n\n**两端拿授权栏数据的方式根本不同：**\n· WebUI：`PermissionList.tsx:27` 拿 inbox 自己分组 —— `const groups = groupPermissions(inbox)`，每组同时渲染两段：\n    · `g.pending`（显示 `{n} 待决策`）\n    · `g.settled`（显示 `历史 {n}`，见 `:182`）\n  即**待决 + 已决策历史**都在，且按会话分组。\n· 鸿蒙：`MainPage.ets` 的 `PermissionTab` 调专用端点 `GET /permission/pending`（服务端 `ListPendingPermissionsFor`，SQL 里带 `WHERE pr.result IS NULL`）—— **只拿得到待决的**，而且是**平铺一列**，不分组。\n\n⇒ 用户可见差异：**已决策的授权记录在鸿蒙上完全看不到**（WebUI 能看到每个会话的历史条数）。\n\n★ 为什么没当场改：这不是照抄一个函数能解决的 —— 要么改成读 inbox 并实现分组渲染（结构改动），要么另调一个含已决策的端点（服务端可能没有）。两条路都要想清楚哪边是权威（本仓方向：**electron 是唯一真实源泉**⇒ 倾向于改成读 inbox + 分组）。先登记，别假装对齐了。"
     }
   ]
 }