jianf/MailUI4Agents
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
678 Commits 1 Branch 0 Tags
0c6c506d7af3f4c98887f0e0a2002b631f4d10e2
Commit Graph

10 Commits

Author SHA1 Message Date
JianFeeeee
65de1c3884 跨端对齐：授权栏 navigator_only + 组件按页拆分 + 服务器补 permission_options 
用户两项裁定落地（均为 ask_user 明确选择）：

① 授权栏口径 = navigator_only（照 WebUI 架构）
   · 新建 pages/PermissionPanel.ets —— 详情页的决策面板，
     对应 MailView.tsx:693 的 PermissionPanel（审批型 / 主动提问 / 已处理 三态）
   · 决策入口从授权栏移到 MailDetailPage；MailDetailPage 原来只显示一个
     「权限请求」小标签、根本没有决策入口（比 WebUI 少一整块，且反了：
     栏里能决策、点进详情反而不能）
   · PermissionTab 删掉内联「同意/拒绝」+ 备注框 + decide()：
     整卡可点 → onOpenMail（对齐 WebUI PermissionList.tsx:81 的 pick()）
   · PermissionRequest 补 source_account_id（客户端侧记来源，跳详情要定位网关）

② 服务器补 permission_options —— 修一条真实的、跨端共有的缺口
   · mails.permission_options 从 INSERT 起就写进去，但**从来没有任何读路径
     选过它** ⇒ 详情端点永远返回空。WebUI 的决策面板读 mail.permission_options，
     所以提问型的预设选项**两端全部落空**（审批型靠 ['同意','拒绝'] 兜底蒙混）
   · GetMailByID 补选该列 + JSON 反序列化（与 cc_list 同款）

③ 组件按页封装（用户要求「以便与 WebUI 一一对应」）
   MainPage.ets 4592 → 3192 行
   · pages/PermissionTab.ets    720 行  ↔ PermissionList.tsx
   · pages/ContactsTab.ets      796 行  ↔ ContactPanel.tsx
   · pages/NavDestinations.ets  181 行  ↔ Navigation 壳
   · pages/NavShared.ets         65 行  ↔ 跨栏共用件

④ 判据跟着组件搬家（否则静默失效，不是红）
   harmony-logic 的 pageCode / harmony-nav 的 navSrc 改为显式文件名单；
   harmony-appearance 的 PANE_SOURCES 补 ContactsTab；harmony-contacts 三个
   test 并入 ContactsTab；harmony-logic 的决策断言改指 PermissionPanel，
   并新增「授权栏不许再有内联决策」两条（navigator_only 的正形状）。

   animation-audit：共享元素转场判据从「同文件共址」改为「按 id 找驱动」。
   旧形状把 in/out 端必须在同一文件当成代理，而两端**天然在两处**；
   抽出写信页（NavDestinations 持有 in 端）后误报。新判据仍要求每个 id
   都有 Motion.morph 驱动 —— 变异实测：把驱动换成裸 animateTo 仍判红。

判据：files=34 checks=556 red=1（仅 build-stamp，产物待重构建）
 2026-09-24 10:10:32 +08:00
JianFeeeee
f4d5a75976 跨端: 补 MailSummary 的解析边界兜底（列表这条主流的 omitempty 一直是敞的） 
判决书来自 `harmony-arkts` 那条判据，它在我加了授权栏历史之后报出两处调用点：

    MainPage.ets: parts.push(e.reason.length > 0 ? …)                 ← 假阳性
    MainPage.ets: if (m.mail_type === 'permission_request' && m.permission_result.length > 0)   ← 真 bug

## 真 bug：`MailSummary` 没有解析边界兜底

本仓早就为这个形状付过代价，**而且修法只修了一半**：

· `MailDetail` 有 `normalize()`，并在 `MailApi.mailDetail()` 接了（当时那次是**整页白屏**）；
· 而列表用的 `MailSummary` **没有** —— 于是 `mail_type` / `permission_result` /
  `session_alias` 这些带 `omitempty` 的字段在缺失时是 `undefined`，
  而三处调用点直接读 `.length`。

服务端 `omitempty` 的语义是**整个 key 不出现**（不是给空串），
ArkTS 裸 cast（`JSON.parse(raw) as T`）缺键给 `undefined`、**不会**应用类里那个 `= ''`。

⇒ 这是同一形状的**第四次**（前三次：`MailDetail` 白屏、`participantAddress` 的 trim、
`AddressSuggestion.title`）。前三次都是"读的人临时守一下"，
**而列表这条主流一直敞着**。

修法（与 `MailDetail` 同一处、同一纪律）：给 `MailSummary` 加 `normalize()`，
在 `MailApi.inbox()` / `sent()` / `sessionMails()` **三处**解析边界接上。

★ 为什么不在调用点加 `??`：`MailSummary` 上还有 `mail_type`/`session_alias`
  同样带 omitempty —— 逐个调用点加就是"每加一处就得记得做一次"，
  本仓反复在消的形状。归一化做一次、覆盖全部字段。

## 假阳性：同名词撞车

`e.reason` 的 `e` 是 **`AccountError`** —— 鸿蒙**本地类**（`MailStore.ets:73`），
只经 `AccountError.of(account, reason)` 构造 ⇒ `reason` 恒为 string。
而判据收集的那个 `json:"reason,omitempty"` 属于 `RenameProposal`
（`rename_proposal.go:39`，**完全不同的**接口）。已按既有
「已逐个核实过的豁免」格式加 ⑤，附取证。

## 期间修了判据自己的一个洞（变异实测）

我给 ⑥ 加豁免时第一版写的是**无条件**正则 —— 变异实测
（把 `MailSummary.normalize` 里那行 `m.permission_result = str(...)` 删掉）
**判据照样全绿**：豁免把那一行永久致盲了。

这正是本仓反复消的形状：**豁免口自己没人管**。

⇒ 改成"**有前提**的豁免"：先断言 `MailSummary.normalize` 里确实有那两行，
命中才豁免。变异复验：

    删掉 normalize 里 permission_result → 判据红 ✓
    删掉 normalize 里 mail_type        → 判据红 ✓
    两者都在                          → 全绿 ✓

⇒ 豁免表达的是"**因为上游归一了**，所以这里可以不写 ?? "，
  而不是"这一行不用管"。
 2026-09-21 17:06:19 +08:00
JianFeeeee
5e4a1b616c 跨端: 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 秒**跑完整套。
 2026-09-20 22:35:35 +08:00
JianFeeeee
25e7d8f3bf 跨端: 补附件区（两端一直都有这个功能，我上次误判成"死代码"）+ 修两个真 bug 
══ ① 更正我 2026-09-19 的一个**错误结论**（已写进 docs/DEBTS.json 留档）

那天我审计后写下：`GET /me/mail/inbox` 的回包**既没有 `attachments` 也没有
`has_attachments`** ⇒ `MailList.tsx:261` 的 `mail.attachments?.length ?? 0`
恒为 0、WebUI 那个 📎 是**死代码**。并据此在鸿蒙侧**有意不抄**这个标记。

**这个结论是错的**，错在取证方法：我**只看了一封没有附件的邮件**，
看到 key 不在，就断言服务端从不返回它。事实：
· 服务端 `GetInbox`（`mail.go:586`）**明确调了 `fillAttachments`**，注释还写着
  理由：「Agent 靠收件箱列表得知有哪些附件可下载，否则它不知道该调 attachment_id」
· `Mail.Attachments` 的 tag 带 **`omitempty`** ⇒ **没有附件的邮件根本不输出这个 key**

实测 `limit=200`（96 封）：带 `attachments` 的 **2 封**，正是真有附件那两封。

★ 教训：**`omitempty` 字段的"缺失"不等于"服务端不返回"**。
  判「某字段有没有」必须拿**确实有值的那条**去验，而不是拿一条恰好为空的数据。
  这与同一天那个白屏崩溃（`session_workspace` 缺失 → `undefined` → 抛）
  是**同一个坑的两面** —— 那天是"缺失 → 客户端崩"，今天是"缺失 → 我误判成不返回"。

══ ② 补附件区（鸿蒙原来完全没有）

· `model/Attachment.ts`（新）—— `formatSize` / `attachmentLabel`，纯逻辑无 SDK 依赖，
  逐字对齐 WebUI `api/client.ts:390`（三档 + 保留一位小数）。
· `MailApi.downloadAttachment` —— 走 `getBytes`（不是 `get<T>`：后者假定 JSON，
  取二进制会炸；壁纸当初踩过）。
· `IcsFile.saveBinaryFile` —— 与既有 `saveIcsText` 同一套流程，只是写 `ArrayBuffer`。
· `MailDetailPage` 正文之后渲染附件清单（回形针 + 文件名 + 大小 + 下载），
  位置/形态对齐 WebUI `Attachments.tsx`（无附件时**整块不渲染**）。
· 列表行的 📎 + 数字（`attach_count`，与 `cc_count` 同形状派生）。

══ ③ 顺带撞出并修掉两个**真 bug**

**bug A（差一点就是 94/96 必崩）**：我第一版写 `mail.attachments.length` ——
而 `Attachments` 带 `omitempty`，96 封里只有 2 封有这个 key ⇒ 其余 94 封是
`undefined` ⇒ `.length` 抛。**与当天早些时候那个白屏崩溃是同一个坑，
我刚修过、还在 `Models.ets` 里写了一大段注释，然后加新字段时照踩。**
⇒ 说明"记住别这么写"不管用，要在每个真正读的地方把 `?? []` 写出来。

**bug B（潜在白屏）**：`PermissionTab` 读 `req.session_alias` ——
而服务端 `PermissionRequest` struct **根本没有这个字段**（`models.go:239-255`），
`ListPendingPermissionsFor` 的 SELECT 也没查它，WebUI 的类型里同样没有。
它是我照"授权卡总得显示会话名"的直觉加出来的。⇒ 恒 `undefined`，
一旦有待办就抛。**一直没暴露只因为当前待办数一直是 0**（实测 `{"requests":[]}`）。
⇒ 改成服务端确实有的 `agent_name`，并**删掉那个字段声明**：
让误用变成**编译错**，而不是运行时白屏。

同样是 `body_preview`（`omitempty`，值是 `Body` 的截断）——
空正文 ⇒ 空串 ⇒ 服务端省略 key ⇒ `undefined.length` 抛。那批 96 封恰好都有正文，
所以"看起来没问题"——那正是这个坑的形态。已加 `?? ''`。

══ ④ 新判据：`omitempty` 字段的读法（形状，不是实例）

从 `server/internal/models` **算出**"只以 omitempty 形式出现过"的字段名
（不在判据里手抄名单），再扫鸿蒙侧对它们的裸成员调用。
★ 关键：**不能按字段名一刀切** —— 我第一版就是这么写的，报了 6 处、4 处误报：
  `session_alias` 在服务端有**两个**声明（`Mail` 上带 omitempty、`repo.Contact` 上不带），
  鸿蒙那 4 处读的全是 `Contact` ⇒ 恒有值、不是 bug。
  ⇒ 只扫"从未不带 omitempty 出现过"的名字，那 4 处自动排除。
已逐个核实 4 处豁免（每条都写了取证理由，不是"看着像就放过"）。
变异验证：把 `?? []` 去掉 → 判据转红，且**正是**报 `MailStore.ets: mail.attach_count = mail.attachments.length`。

══ ⑤ 数据路径已实测（模拟器）

临时把 `INBOX_PAGE_SIZE` 提到 200（因为有附件那两封在下标 51/52，
默认 limit=50 **根本取不到** —— 这也解释了为什么之前一直没发现），
加临时 hilog 后拿到：
    AttProbe: mail=531a1629-… attach=1
    AttProbe: mail=b68cbbe8-… attach=1
正好是那两封。验完已撤掉探针、`INBOX_PAGE_SIZE` 恢复 50。

══ ⚠️ 本轮**未能**完成设备端视觉验收

模拟器已卡死（`hdc` 能连上但 `shell` 超时；进程 152% CPU、已跑 32 小时），
导致套件里的设备判据各跑 836 秒后失败（"要能拉起应用"）。
主机可用内存只剩 ~3.7GB。附件区的**渲染**（清单外观、下载落盘）
尚未在设备上看过 —— 待模拟器恢复后补。
 2026-09-20 21:14:20 +08:00
JianFeeeee
f1db99ef41 跨端: 发件箱接上 MailStore（A 的剩余）+ 修 3 处把原始 ISO 印到界面上的时间 
══ ① A 的剩余：发件箱走了 store（顺带撞出 store 里的一个真 bug）

`SentTab.load()` 原来把收件箱那 107 行**抄了一遍**（注释里还写着"同收件箱"
—— 抄的时候就知道是重复）。现在改成 3 行调用 `MailStore.loadSent`。

★ 接上之后**立刻炸出一个真 bug**：`MailStore.loadSent` 里写的是
      snap.groups = [];
  而发件箱的列表**就是按会话分组渲染的**（`ForEach(this.groups, …)`）
  ⇒ 接上 store 之后发件箱会**一片空白**，而"接口有返回、loaded > 0"
  会让症状看起来像"数据没到"。

  为什么会写成空数组：它是照收件箱那半抄的，而收件箱的 `groups` 来自
  `splitByPermission` **筛完之后**的 `inboxMails`（授权邮件要挑出去单独成栏）。
  抄的时候只看到"要赋值"，没注意发件箱没有那一步筛选 ⇒ 把 `[]` 抄了过来。
  发件箱也**不能**照搬那个筛选：那是为"授权待办栏"服务的，发件箱不显示那栏。

★ 这段经历本身值得记：**死代码不会自己暴露错误**。
  `loadSent` 写完到今天我接上它之前，那行 `groups = []` 一直没人执行过。
  "写完就搁着"和"接上一个调用点"是两件事 —— 后者才算验过。

══ ② 3 处把原始 ISO 直接印到界面上（看到屏幕才发现的）

发件箱那张卡的时间格显示的是
      2026-09-19T02:55:33.10099Z
（23 个字符，把「致 homeagent」那行挤到换行）。

WebUI **三种卡片全部格式化**、一个没漏：`MailList.tsx:151/262`、
`PermissionList.tsx:143/251`，全是 `toLocaleString('zh-CN', {month,day,hour,minute})`
⇒ `MM/DD HH:mm`。鸿蒙的 `compactMailTime` 就是那个实现，收件箱一直在用 ——
所以这不是"要不要格式化"的分歧，是**三处漏调**（收件箱 / 发件箱 / 授权栏）。

══ ③ 补判据（形状而不是实例）

新判据：`Text(<x>.created_at)` 这个**形状**不许出现（`Text` 只负责画，
不做格式化）。为什么枚举形状而不是列举调用点：漏的三处分布在**三个不同 struct**，
按名字枚举一定会再漏第四个。
自检 + 变异验证都做了（把 SentRow 那处改回裸字段 → 判据转红；还原 → 绿）。

设备验证：发件箱正常渲染（会话组 + 条目，非空白），
时间显示 `09/19 10:55` 而非 ISO。
 2026-09-20 18:43:35 +08:00
JianFeeeee
6085159694 跨端: 5 处 Unicode 符号当图标换成 AmIcon（并把判据扩到"排版符号"这一类） 
起因：做邮件详情时顺手把 `Text('‹')` 换成 `AmIcon('chevronLeft')`，
想着"本仓不是有这条判据吗，怎么没抓到" —— 去看了判据，发现它**只扫 emoji 那一段**。

判据（`harmony-arkts.test.mjs:168`）扫的是 U+2600–27BF / U+2B00–2BFF / U+FE0F，
而漏网的 5 处全在这三段**之外**：
    MainPage.ets      Text('‹')   返回键（会话视图）
    MainPage.ets      Text('›')   会话别名前的小箭头
    SettingsPage.ets  Text('›')   「管理」的进入下一级指示
    ComposePage.ets   Text(' ▾')  账号下拉指示
    MailDetailPage.ets Text('‹')  返回键

★ 它们与 emoji 那类**问题不同、但同样是"看着像图标其实不是"**：
  · 字形宽窄由**字体**决定，与旁边 20vp 的 `AmIcon` 对不齐；
  · 而且**WebUI 用的根本不是字符** —— `icons.tsx:135` 是
    `ChevronRightIcon`（SVG）、`AccountSwitcher.tsx:84` 是它**转 90°**。
    所以这同时是"两端不一致"，不只是"字形不好看"。

修法：5 处一律换 `AmIcon`，并按 WebUI 的**同一形状**给：
· 两个返回键 → `chevronLeft` 20vp、可点区 `HEADER_BACK_HIT`（与 `AppHeader` 同值）
· 会话别名 / 「管理」→ `chevronRight`
· 账号下拉 → `chevronRight` + `rotate(open ? 90 : 0)`（照 `AccountSwitcher` 那句）

★ 判据扩了一类（`GLYPH_ISH`：U+2039/203A/00AB/00BB/25A0–25CF/25B2/25BC/25C0/25B6），
  并保持原有那条边界不被破坏：**U+2190–21FF 基本箭头仍不扫** ——
  `→`/`←` 在正文里是标点，扫进来会误伤大量正常文案（原注释里已经踩过这个坑）。
  这次的符号是"单个字符整体"，所以 `Text('a → b')` 这类多字符本来也不匹配。

★ 扩完之后判据**当场又抓到一处我自己没注意的**（`SettingsPage.ets` 的 `›`）——
  这正是"把判据从'枚举实例'扩到'枚举类'立刻多抓一个"的现场证据，
  也说明原来那三条区间是照"已经出现过的实例"框的，不是照"这类东西的共同形状"框的。
 2026-09-20 13:33:13 +08:00
JianFeeeee
ff172ed2c1 判据: 修 AmIcon 尺寸检查的假红 —— 它跨过 } 吃到了下一个组件的修饰符 
这条判据抓的是真形状（`AmIcon({…}).width(48)` 会让图标贴左上角），
但正则写宽了：`[\s\S]{0,200}?` 允许**跨过 `}`**，于是这种**正确**写法被判红：

    Row({ space: 4 }) {
      AmIcon({ … })
      Text('新建')
    }
    .height(26)      ← 这是 Row 的，不是 AmIcon 的

实测（日历工具栏新加的「＋ 新建」按钮）：报 `CalendarPage.ets:1223 → .height(`，
而那一行链在 `Row` 上。**是判据误报，不是代码错。**

修法：扫描区间**不允许出现 `{`/`}`**。`AmIcon({…}).width(48)` 里参数花括号已被
`)` 收尾，而跨到下一个组件的路径会被排除。

★ 修完**立刻做了变异验证**（这类放宽最容易顺手把判据改废）：
   把真实的 `AmIcon({…})` 改成 `AmIcon({…}).width(48)` ⇒ **判红**；
   还原 ⇒ 绿。既要"不误报"，也要"仍能抓真错"，两半都得验。
 2026-09-19 15:22:34 +08:00
JianFeeeee
0e5eec61bd 跨端: 登录页那个"emoji"是 Unicode 符号 —— 顺手修好图标贴左上角（共 4 处） 
用户两条反馈，都是**看着界面**报出来的，而编译器与所有既有判据全绿：
①「为什么登陆页不是app图标，而是一个emojy？」
②「你自己看看那个图标的位置正常吗？」

## ① `Text('✉')` 被系统渲染成彩色 emoji

登录页的品牌标识原先写的是 `Text('✉')`（Unicode U+2709）。HarmonyOS 字体链里有
**彩色 emoji 字体**，U+2709 自带 emoji 字形 ⇒ 渲染成一枚黄白色风信封 emoji：

- `.fontColor(Theme.accent)` 对彩色 emoji **无效**（界面显示的是 emoji 自带颜色）；
- 与底栏/侧栏那些 `AmIcon` 线描图标不是同一套视觉语言；
- 实测截图硬证：大屏下那枚 emoji 比旁边的文字还显眼。

而本仓**早就有** `ICON_PATHS.brandMark`（就是 App 图标上那个信封，专为品牌标识画的）。
换成 `AmIcon({ iconName: 'brandMark' })` 即可 —— 走 `Path.stroke()`，跟主题色走。

## ② 图标贴在卡片左上角（量出来的）

`AmIcon` 内部那个 `Stack` 是 `iconSize` 那么大、**默认靠左上**排版。调用方写
`AmIcon({…}).width(48).height(48)` 想要个大点的可上色盒子时，**外层盒子变大、图标不动**。

实测（三折叠 3.5 密度，`dumpLayout` 读的**实际 bounds**）：

    卡片 [1523,521][1661,659]  138×138px
    图标 [1526,524][1589,587]   63×63px   ← 左边距/上边距都只有 3px
    ⇒ 图标中心偏 10vp

**不是一处**：全仓扫出 4 个同样写法。修法是套一层
`Stack({ alignContent: Alignment.Center })`（仓里回复球与悬浮加号本来就是这么写的，
所以它们一直是对的）：

| 位置 | 图标 | 盒子 | 原状态 |
|---|---|---|---|
| 登录页品牌卡 | brandMark 24 | 48×48 | 贴左上 ✗ |
| 用户管理刷新键 | repeat 20 | 40×40 | 贴左上 ✗ |
| 联系人视图切换 | cardView 18 | 40×40 | 贴左上 ✗ |
| 收件箱组头箭头 | chevronRight 12 | 20 槽位 | 贴左 ✗ |
| 回复球 / 悬浮加号 | chatBubble / compose | 56×56 | 本来就对（尺寸在外层 Button 上） |

修后实测：偏移 **−34.5px → 0.5px**（0.14vp，亚像素级）。

## 判据（harmony-arkts 3 → 5 条）

- **图标不许用 Unicode 符号充当**：扫 `Text('…')` 里单个符号的情况。
  ★ 只框 U+2600–U+27BF / U+2B00–U+2BFF / U+FE0F，**刻意不含基本箭头段**（U+2190–U+21FF）——
  `→` 在正文里是标点不是图标，框进来会误伤大量正常文案。
  （我第一版把箭头段也框了，结果自检自己先红 —— 断言写错就是写错，不靠放宽它来「修」。）
- **尺寸不许直接链在 `AmIcon` 上**：把"图标贴左上角"这个坑的**形状**钉住，
  并自检"套了 `Stack` 的正确写法不许被误判"。

**两个变异方向都跑过**：放回 `Text('✉')` ⇒ 红 ✓；给 `AmIcon` 直接加 `.width(48)` ⇒ 红 ✓。
 2026-09-18 11:47:51 +08:00
JianFeeeee
4af083e8b8 test(判据): 4 个判据读的是**另一棵树** —— 修掉硬编码的仓库根，并让 stripComments 保持行号 
pi 2026-09-15 实测出来的，**这次长在判据自己身上** —— 正是我们前几轮一直在消的那个形状。

## 一、`const ROOT = '/home/program/agentmail'`：规则进来了，对象没进来

`harmony-arkts.test.mjs` 把仓库根写成了绝对路径。后果我按 pi 的步骤亲手复现了：

```
$ git worktree add --detach /tmp/wt-verify 7f4fa26      # 那个检出里 import 顺序**确实**违规
  （核对：最后 import 在第 80 行，而第 63 行已是 `const NAV_MATERIAL_OF…`）
$ cd /tmp/wt-verify/client/electron && node --test test/harmony-arkts.test.mjs
ok 1 / ok 2 / ok 3   # pass 3  # fail 0      ← **在一个明显违规的检出上 3/3 全绿**
```

因为它读的不是 `/tmp/wt-verify`，是 `/home/program/agentmail`（那份早已修好）。
两层后果，第二层最糟：
① 它**永远无法验证任何别的 checkout / CI / 镜像** —— 换目录不是"红"，是 `readdirSync` 直接抛；
② 在本机做 worktree 复核时，它**静默读另一棵树并报绿**。
**判据的逻辑是对的、对象是错的** —— 这比"判据写错了"更难发现，因为它在原地永远是绿的。

同一个毛病在 4 个文件里，**恰好全是最近这几笔新写的**（另 10 个鸿蒙判据写法是对的）：

```
harmony-admin / harmony-imageprep / harmony-presets / harmony-arkts  →  const ROOT = '/home/program/agentmail';
其余 10 个                                                          →  const ROOT = join(HERE, '..', '..', '..');
```

已全部照邻居改掉。**修好之后在同一个违规检出上：`# fail 1`** —— 它终于会红了。

## 二、修这条时又牵出一个：`stripComments` **改变了行号**

修好路径后，判据报出"最后一个 import 在第 64 行、第 47 行已是语句"，
而**真实文件里是第 80 / 63 行**。成因：`stripComments` 把块注释整块抹成 `''`，
而块注释**自带换行** ⇒ 它之后所有行号整体前移。

这不是小节：全仓判据都用 `文件:行号` 定位（`grep -n`、编辑器跳转、`git show` 核对），
**报出来的行号必须能直接用**，否则读者第一步得先猜"这是剥过的还是没剥的"。
改成"块注释里的每个换行换成等量空行"。修完报的就是 **80 / 63**，与文件逐字对上。

## 三、新增两条判据，让这两个形状不能再回来

1. **`★ 判据不许把仓库根硬编码成绝对路径`** —— 扫判据目录里**真代码**
   （`code()` 剥注释，否则本文件自己的说明文字就会误报），找
   `const X = '/绝对路径'` 且**看着像仓库内**的声明。
   **例外按名字放行**（含 `TOOLCHAIN`/`SDK`/`HDC` 的常量）—— 工具链本来就不在仓库里、推不出来；
   按**值**做白名单会逼着下一个人为了过判据去改那个路径的写法。
2. **`★ stripComments 必须保持行号`** —— 造含多行块注释的样本，断言剥完
   **行数不变**、且第 N 行仍是原来的第 N 行；**同时**断言注释内容确实被去掉了
   （别为了保行号把注释留下）。

两条都做了**变异验证**：
- 把 `harmony-admin` 的 ROOT 改回硬编码 ⇒ 新判据**红**，并点名那个文件；还原后绿。
- 在 `MainPage.ets` **import 之前**插一条语句 ⇒ `harmony-arkts` **红**
  （第 79 行 vs 第 1 行）；还原后绿。**这条同时证明了"读的是自己那棵树"** ——
  同样这个变异，在修路径**之前**是绿的。

## 四、未做 / 未验

- 到期闸门那 7 条**没动**（要真装真点，是另一件活）。
- **"把 build 做成一条判据"我探了，两个硬障碍**（详见给 pi 的回信）：
  ① `client/harmony/oh_modules` 被 `.gitignore` 排除且未入库 ⇒ **全新检出没有它**，
     构建会先死在装依赖上；② 本沙箱**拒写 `/root/.hvigor`**（`mkdir` Permission denied），
     `hvigorw` 在 worktree 里直接 `EACCES: mkdir '/root/.hvigor/project_caches/…'`。
  所以它在本仓能编过、在干净检出编不过 —— 作为判据它现在会**假红**。
 2026-09-15 12:06:15 +08:00
JianFeeeee
7f4fa2629e 跨端: ArkTS 编译期硬规则进判据 —— 我插的常量表把 import 挤到了后面，assembleHap 报 arkts-no-misplaced-imports 
`hvigorw assembleHap` 在 `f31bc02`/`b806a05` 上都红了一条：

    ERROR: ArkTS:ERROR …/MainPage.ets
    "import" statements after other statements are not allowed  (arkts-no-misplaced-imports)

**是我造成的**：P4c 那笔我在 `MainPage.ets` 里插了 `NAV_MATERIAL_OF` 那张（带注释的）
常量表，位置在**既有 import 之前**。ArkTS 要求所有 import 在任何语句之前，
常量表算语句 —— 编译器直接报错。

## 为什么我那一笔的判据一条都没抓到它

因为**这个仓库里没有任何判据会跑 ArkTS 的编译规则**。我的判据判的是"表达式对不对、
接没接上、颜色写没写死…"，它们全绿 —— **文本层面确实没问题**，问题只有编译器知道。
pi 是构建时撞上的。

⇒ 教训不是"下次小心"，是**把编译器能抓、而判据不抓的那一类固化下来**。
这一类里有一批**纯文本就能判、不需要设备**，所以它们不该待在"等设备才能验"的欠账里。

## 做了什么

- 新增 `test/harmony-arkts.test.mjs`（3 条，不需要设备 ⇒ **不进** STATIC_ONLY）：
  · **所有 26 个 `.ets` 的 import 必须在任何其它语句之前**（就是这次报的那条）；
  · 全仓 `.ets` 的词汇层硬坑（对象解构 / `any` / `unknown` / 函数表达式）
    —— 这几条此前**只在"我自己新写的那个页面"里判**，而我恰恰是在**改既有文件**时犯的下一个错，
    编译期硬规则不该按"谁写的"分覆盖；
  · **一条自检**：造已知坏样本（常量插在两组 import 之间）确认检查会红、合法样本不误报
    —— 否则"全绿"可能只是扫描逻辑失效（我第一版就把多行 import 的成员行误判成了语句）。
- 接进 `SUITE`（判据文件数 22 → 23）。
- 文件头明确写了它**不能**替代 `hvigorw`：覆盖的只是"能静态判出来的那几类"，
  类型推断/重载解析/Sendable 那些仍然只有 build 能验 ——
  不许把这个文件的存在读成"编译已经验过了"。
- 变异测试 5 条**全部被抓**，含**精确复现我那个错的形状**（把 import 搬到常量表之后）。
  基线 `7/7✓`（逐字节还原）。
- 现口径：`mutants=52 ran=52 skipped=0 on_new_criteria=36 baseline=7/7✓`。

## 工作树里**不是我做的**两处改动（已核实为正确，我没有提交也没有回退）

工作树是共享的：`AdminUsersPage.ets` 与 `MainPage.ets` 在我提交**之后**被别的进程改过，
两处都是**修构建错误**，都核实过是对的：

1. `MainPage.ets`：把两组 import（`CalendarPage`、`NavItems`）从 `NAV_MATERIAL_OF` 表**之后**
   挪到文件最前 —— 就是上面那条 `arkts-no-misplaced-imports`；
2. `AdminUsersPage.ets`：`Chip(text, bg, fg: string)` → `ResourceColor`
   （`Theme.surfaceMuted`/`textSubtle` 是 `Resource`、`chipNeutralBg` 是 `string`，
   第 368 行那个三目因此是 `Resource | string` ⇒ 旧签名编译不过）。

我不提交别人的活、更不回退它；但它们**让基线必须重算**，而**重算基线是有意动作**
（随手重算会把"某次变异没还原"永久掩盖掉），所以 `baseline.sha` 顶部记了原因与哈希来源。

## 未验

- 这三条判据**只覆盖静态可判的那几类**。`assembleHap` 仍然只有真正构建才能验 ——
  这次就是构建先于我所有判据发现的问题，下次还可能是。
- Go 侧 `debt_registry_test.go` 仍未跑（沙箱无 Go 模块缓存），只有 `gofmt`。
 2026-09-15 11:27:35 +08:00