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

16 Commits

Author SHA1 Message Date
JianFeeeee
20fc8a5800 跨端: 修三个真崩溃/失败 —— @BuilderParam 丢 this、发送后退错页、漏校验 body 
用户 2026-09-21：「点击发送邮件直接闪退，点击授权也直接闪退，所有功能全部不可用」。
三个都是**真 bug**，逐个拿到证据后修的（不是猜的）。

## ① 点「授权」必崩：`@BuilderParam` 把 `this` 换掉了

崩溃日志（`jscrash-…-20260921150832132.log`）给出的栈：

    Reason: TypeError
    Error message: Cannot read property length of undefined
    at anonymous entry (MainPage.ets:1458:23)       ← this.requests.length
    at … Surface.ets:717:7                          ← AppHeader 里 this.trailing()

`MainPage.ets:1458` 是 `if (this.requests.length > 0)`，
而它住在 `PendingTrailing()` 这个 `@Builder` 里 —— **传给 `AppHeader` 的
`@BuilderParam` 之后，它执行时的 `this` 变成了 `AppHeader`**，
而 `AppHeader` 上当然没有 `requests` ⇒ `undefined.length` ⇒ 崩。

★ 这是 ArkUI 的老坑：`@BuilderParam` 是**按值传递一个函数**，
  调用方的 `this` 不会跟着过去。全仓**4 处**都踩了（`MainPage` 的
  `SentCountTrailing`/`PendingTrailing`、`AdminUsersPage`/`SettingsPage`
  的 `HeaderTrailing`）—— 它们各自读 `this.loaded`/`this.load()`。

修法：改成**尾随闭包**（`AppHeader({...}) { this.XxxTrailing() }`），
闭包捕获的是**定义处**的 `this`（本组件的），而不是 AppHeader 的。

★ 为什么判据没抓到：那 4 处此前都只是"静态源码里有这个 builder"，
  而崩溃只发生在**运行时的 `this` 绑定**上 —— 形态判据看不见绑定。
  这一条只能靠设备实测（我这次是靠真机崩溃日志）。

## ② 发送成功后"闪退"：其实是退错了页

`ComposePage.doSend()` 成功分支里是**无条件** `router.back()`。

而内嵌时（宽屏右栏 / 窄屏 `Navigation` 覆盖）写信只是 `MainPage` 的一个
**右栏状态** —— `router.back()` 退掉的是**整个 MainPage**，用户看到的就是
"发送之后 App 没了"（报成闪退）。

★ 同一个文件里，顶栏「取消」键（上面几十行）**早就写对了**：

    if (this.embedded) { this.onBack(); return; }
    this.getUIContext().getRouter().back();

我加 `doSend` 时没照着抄。`MailDetailView.goBack()` 也是这个正确形状 ——
**只有 `doSend` 是那个异类**。已改成与取消键同一判据。

## ③ 发送真的失败：校验漏了 `body`，且没 trim

日志里 `→ POST …/mail/send` 发出去了，但服务端 400。
直接打服务端复现：

    curl -d '{"to":"pi@root.new","subject":"t","body":""}'
    → {"error":"Missing to, subject, or body"}

而 WebUI 的 `canSend`（`ComposePage.tsx:132-138`）是**四个条件**：
    to.trim() !== '' && subject.trim() !== '' && body.trim() !== '' && …
鸿蒙这边只校验了 `to` 与 `subject` —— **漏了 `body`**。

⇒ 用户在"正文本来就是可选的"观感下不填正文，请求照样发出去、被拒。

同时补 `trim()`：WebUI 发的是 `to.trim()` / `subject.trim()`，
而 `pi@root.new ` 与 `pi@root.new` 在服务端是**两条不同地址**。

## 设备验证（改前 → 改后）

· 点「授权」：崩（进程消失，新增 jscrash） → **进程存活，页面正常渲染，
                                待决策徽标 "4" 正确显示**（证明 `this.requests` 绑定对了）
· 发送邮件：POST 发出但服务端 400，且"闪退" → **回到收件箱，
                              发件箱里 `realtest` 已落库**（服务端实测 9 封）

## 另修：候选补全的菜单按 WebUI 补齐四件

用户：「收件人填充能力完全不可用，根本没有与 webui 对齐」。
实测后确认功能是通的（`pi` → `pi@` → 路径 → 会话 → 完整地址，
三段链逐段验过），但**行内渲染漏了 WebUI 的四个要素**（`AddressInput.tsx:186-231`）：

  ① 别名 `font-mono`（地址类文本全仓等宽）
  ② 标题在**第二行**（原来挤在右边同一行）
  ③ `source` 三态视觉：`platform` 蓝胶囊 / `new` 灰字 / `mail` 无标
  ④ `unread > 0` 红徽标（服务端 `SessionCandidate.Unread`，带 `omitempty`）

`AddressSuggestion` 顺带补 `unread` 字段并守住 `omitempty`
（缺键时裸 cast 是 `undefined`，不是类里的 `= 0` —— 与 `title` 同一个坑）。

★ 另外修掉一个我自己写错的参数：`suggestAddress` 原来把 `'?name=…'` 传给
  `ApiClient.get(path, query)`，而**问号是那个方法自己加的**
  ⇒ 会拼成 `??name=`。约定：`query` 只放 `k=v`，不含问号。
 2026-09-21 15:21:47 +08:00
JianFeeeee
125aec1191 跨端: 2in1 键盘可达（Ctrl+N 写信 / ↑↓ 换补全 / Enter 选中）+ 三处判据被实测改判 
用户 2026-09-21：「接下来做一下 2in1 上的快捷键，比如快捷键打开发信页面」
「上下键切换发信目标」「回车展开输入框等」

## ① 打开发信页：Ctrl+N，用官方 `keyboardShortcut`

先查了官方文档再动手，避开两条静默失败的坑：

  · `keyboardShortcut`（组件快捷键事件，API 10+）「**无论组件是否获焦** ——
    只要窗口获焦，快捷键就会响应」。而 `onKeyEvent` 要求**组件先获焦**，
    邮件列表里焦点落在哪是不确定的（点一下就换）⇒ 用它做全局快捷键会时灵时不灵。
  · 「多个不同组件设置相同组合键 ⇒ 只响应节点树**深度最浅**的那个」。
    ⇒ 再给别处的"写信"按钮补一个 Ctrl+N 不是"多一个入口"，而是**让后来那处永久失效**。
    判据因此钉"全仓只许绑一处"。

绑定位置在 `MainPage` 的**根 Stack**（窗口组件树的根）—— 绑在 FAB 上不行，
它在 `if` 分支里、窄屏/宽屏位置也不同，会随分支挂卸。

键位 `Ctrl+N` 避开了官方列出的五个**禁止绑定**组合（Alt+F4/Alt+Tab/Ctrl+Shift+Esc…）。
判据直接解析调用参数校验这三点。

## ② 根够不着 `openCompose()` ⇒ 照 `PushService` 的"两半"形状

`openCompose()` 住在**条件挂载**的 `CommPage` 上（`if (currentIndex === 0)`），
根组件拿不到它。新建 `common/ComposeIntent.ets`：

  · **格子**（`pending`）—— 用户此刻在别的页、`CommPage` 还没实例化；
  · **回调**（`listener`）—— 用户此刻就在通信页、页面早挂载完了。

缺任何一半都是**按键静默失效**：只有格子 ⇒ `aboutToAppear` 不重跑；
只有回调 ⇒ 没有监听者。这形状与 `api/PushService.ets` 处理"点通知跳转"时
踩的是同一个坑，那边注释里已写过解法 —— 这次是照着抄，不是重新踩。

## ③ 收件人三段式补全（↑↓ 切换、Enter/Tab 选中、Esc 收起）

WebUI 的逻辑原先**散在组件闭包里**（`parseParts` 没 export、`apply`/`onKeyDown`
直接改 React state）⇒ 判据根本 import 不到。先把它抽成一对纯逻辑：
`client/electron/src/lib/addressSuggest.ts` ↔ `model/AddressSuggest.ts`，
**抽的时候行为一字不改**（抽出来顺手"改进"会让判据比新行为、线上跑旧行为，两边都错）。
`AddressInput.tsx` 改接这份 lib。

`cross-client-logic` 新增 `AddressSuggest` 一对，22 个用例两边逐例比。
其中 `nextActiveIndex(0,3,-1)` 是**负下标陷阱**：JS 的 `%` 对负数返回负数
（`-1 % 5 === -1`），而负下标在数组访问里**不报错**（返回 `undefined`），
只表现为"按上键后没有任何一项高亮"。直接写 `(i-1) % n` 就会这样静默坏掉。

候选走**内联渲染**而不是 `bindPopup`/`bindMenu`：那两者各有焦点体系，
会先吃掉按键 ⇒ "↑↓ 换候选"落不到 `onToKey` 上。

## ④ 另修一个真 bug：`AddressSuggestion` 字段名整套写错

模型声明 `value`/`kind`，而服务端（`contacts.go:206`）给的是 `alias`/`title`/`source`
—— **从来没返回过** `value`/`kind`。按本仓纪律「声明了服务端从不返回的字段 ⇒ 删掉声明」改正。

顺带守住 `title` 的 `omitempty`：缺键时裸 cast 给 `undefined`（**不是**类里那个 `= ''`），
直接读会 `Cannot read property of undefined` —— 本仓在 `MailDetail.normalize()` 上
踩过同一形状（整页白屏）。判据钉住那句 `typeof … === 'string'` 的守。

## ⑤ 三处判据被**实测**改判（不是我挑一边，是拿数字定的）

### a. 卡片不该有模糊 —— 反转原断言
原判据断言「玻璃卡要走参数化 `backgroundEffect`」。那是**记录旧实现的副作用**
（重言式）。逐字读 WebUI 的 CSS：全仓 `backdrop-filter` **只有两处**
（`.glass-control` 8px/1.1、`.narrow-nav` 18px/1.5），而 `.glass-card`（`index.css:1629`）
**完全没有** —— 它的玻璃感是 `rgb(255 255 255 / 0.92)` 这个 alpha。
留着旧断言更坏：下次谁把卡片改成正确的"白 + alpha"会被判红，然后去**把模糊加回来**。

### b. 我试了"把模糊移到导航条"，被实测否掉
推断「真归属是底栏」，于是把底栏改成 `backgroundEffect({radius:18, saturation:1.5})`。
实测（模拟器窄屏 1008×2232，底栏中心列 x=504）：

    y      backgroundEffect        backgroundBlurStyle
    1960   rgb(191,199,209)        rgb(234,235,239)      ← 差 -36 亮度
    2060   rgb(206,211,219)        rgb(234,235,239)      ← 差 -24

⇒ `backgroundEffect` **只给模糊、不给底色**，壁纸原样透上来，底栏暗了 24~36 级。
WebUI 的 `.narrow-nav` 是**两条声明**组合的（`background-color` + `backdrop-filter`），
我只搬了后者。系统材质**同时含色调 + 模糊 + 深浅两套** ⇒ 在这里它才是正解
（§7.12 把它判成"有意差异"是对的，我的"改进"是退步）。
判据改成**反向钉住** `backgroundEffect`，并把这段实测数字留在 Theme.ets 里。

### c. 页签条判据记录的是被否掉的"胶囊"
原判据钉 `TAB_BAR_RADIUS`/`TAB_BAR_SIDE`/`TAB_BAR_TOP` —— 那正是用户否掉的形状
（「你又在内部套了一个胶囊」）。CDP 读 WebUI 的实测几何：

    .comm-pane   x=80 w=320 radius=14px overflow=hidden   ← 窗格，裁圆的是它
    tabstrip     x=80 w=320 radius=0px                    ← 条自己无圆角

设备实测（`uitest dumpLayout`）：页签条 `[28,140][980,267]`、窗格 `[28,140][980,1957]`
⇒ 左右边缘逐像素相同。判据改为钉"与窗格齐平 + 只有左上角圆角"这两条**不变式**，
`TAB_BAR_RADIUS`/`TAB_BAR_SIDE` 一并**删除**（留着就是孤儿，会邀请人把胶囊拼回来）。

## ⑥ 顺带修两条判据自己的正则
`{6}` 看不见 8 位色 ⇒ 把 `glassCard`/`glassCardWall` 报成"清册过期"，
**病因报错了**。改成 `{6}(?:[0-9A-Fa-f]{2})?`（不能写 `{6,8}`，那会连 7 位也放进来）。
半透明禁令改为**枚举白名单**（不是放宽：遮罩那个真实约束原样保留，
`overlay` 写成 8 位单色照样红）。

新增判据 `harmony-2in1.test.mjs` 12 条；`files=34 checks=543 pass=540 fail=2`（收尾前）。
 2026-09-21 13:29:24 +08:00
JianFeeeee
f83c23362a 跨端: 修卡片投影/页签条圆角/日视图/周视图 — 五处对 WebUI 的误读 
用户逐条指出后，用 CDP 读 WebUI 的 computed style 与祖先链，发现五处都是我读错/抄错。

## ① 列表底部那条"不知道什么玩意的阴影"（用户原话）

根因：我把 `instance.shadow(Theme.glassShadow)` 挂在 **每张卡片** 上。
WebUI 全仓 `box-shadow` 只有三处 —— `.app-shell > *`（窗格）、
`html[data-bg='on'] .app-shell > *`、`.narrow-nav`（底部导航条）。
**卡片 `.glass-card` 一次都没有**（整个规则块只有 radius/border/bg/transition）。

一屏十几张卡各投一次 ⇒ 叠加成灰雾。设备实测（x=600，卡片底边 y≈1847）：
    有投影 y=1846→231、y=1852→230（向下衰减的暗带）
    去掉后 y=1846→255、y=1852→251（消失）
⇒ 投影移到 `PaneModifier`（窗格层），与 WebUI 一致。

★ 判定实验还排除了一个嫌疑：`List` 默认 `edgeEffect(EdgeEffect.Spring)`
  （官方文档「支持弹簧效果和**阴影效果**」）。设 `EdgeEffect.None` 后暗带照样在
  ⇒ 不是它。**弹簧是滚到边缘的正常反馈，不该为遮一个 bug 把它关掉。**

## ② 页签条右上角"那个圆角"（用户原话）

两道弧叠在一起。WebUI 实测（CDP 读祖先链）：
    .comm-pane   x=80 w=320 radius=14px overflow=hidden   ← 窗格
      tabstrip   x=80 w=320 radius=0px                    ← 页签条
**两者横向完全齐平**，页签条自己直角、靠窗格裁圆 ⇒ 只有一道弧。
我们内缩 16vp + 自己带角 ⇒ 两道弧，中间一弯月牙。
⇒ 改成与窗格齐平、只留左上角圆角。

★ 期间我犯过两个错，都记在注释里：先把半径设成 `HEADER_HEIGHT/2`=22（条高也是
  44，那就是一个完整胶囊），后来自作主张把整条改成"通栏+下边框+无玻璃"——
  那是重做而不是用户要的小改，已还原。

## ③ 日视图与周视图一样（用户原话）

`DayTimeline()` 我写好了却**从未调用**。日视图一直走 `rows()`（周视图那套七列）。
⇒ 按 scale 分流：日视图 → 24 小时时间轴（对齐 WebUI `DayGrid` 的 `HOURS` 逐行、
  当前小时淡蓝底）；周/日格子改用 `WEEK_CELL_HEIGHT`(240) 并画日程标题条
  （对齐 `EventChip`：`HH:mm` + 标题，停用的加删除线 + 灰底）。

## ④ 邮件正文垂直居中（用户原话）

官方 FAQ `faqs-arkui-725` 原文：内容比 `Scroll` 矮时「**默认居中排布**」，
要 `.align(Alignment.Top)` 才是顶部排布。
实测内容块在 `Scroll` 里偏移 731px = (1944−481)/2 —— 正好居中。
⇒ 4 处 Scroll/List 补 `.align(Alignment.Top)`（详情页 y 从 1018 → 287）。

## ⑤ 窄屏圆角/留白全丢（用户：「你的邮件的圆角呢？日历的圆角呢？」）

`borderRadius(this.isWide ? glassRadius : 0)` —— 窄屏恒 0；
`left/right: isWide ? paneGap : 0` —— 把 WebUI「窄屏**底边**留白为 0」
错推广成「四边都为 0」。
WebUI 两条 shell 规则**都给圆角**，差的只是底边留白。
⇒ 圆角两端都开；左右留白两端都给；只有底边分宽窄。

## 连带修的两个真问题

· **底部导航避让**（用户：「为什么不避让底部导航栏」）：根是 `NavBar` 与内容
  是 `Stack` 里的**并列兄弟**（互相重叠），所以每个滚动容器都得手写
  `contentEndOffset` —— 我漏了 8 处。照 WebUI 改成 `Column{内容, NavBar}`
  （WebUI 实测 `scroller.bottom=861` / `nav.top=871`，内容停在导航上方）。
· **不透明的那一张卡**（用户：「有一个完全不透明的邮箱项」）：`MailRow` 手写
  `Theme.surface`（系统卡片色 α=1），而 `GroupHeader` 用的是 `GlassCardModifier`。
  ⇒ 改用同一件基础件 + 新增 `TintModifier` 合成状态色（`.attributeModifier`
  是单一插槽，色必须参与合成）。实测 `(255,255,255)` → `(195,218,204)`。

判据随之反转 3 条（`harmony-widescreen` 两处把"窄屏 0"改成"两端都要"、
`cross-client-theme` 抓到我新写的 `Theme.border` 当 `fontColor`）。
 2026-09-21 12:04:52 +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
1df8245a6d 跨端: 写邮件改在宽屏右栏打开（原来盖住全屏、把列表栏也带走） 
用户：「写邮件 webui 的宽屏样式不是在右侧打开吗」—— 是，这是**结构性不符**。

WebUI `App.tsx:179` 宽屏下写信只是把 `main` 那一格换掉：
    const main = composing ? <ComposePage /> : viewMode === 'account' ? ... : ...
侧栏与列表栏都还在。而鸿蒙无条件 `router.pushUrl('pages/ComposePage')` ——
一个 `@Entry` 全屏页，左侧列表整片消失。

修法照**既有先例** `MailDetailView` / `MailDetailPage`（同一个问题上次已经解过）：
· `ComposePage` 拆成 `ComposeView`（真内容）+ `@Entry ComposePage`（只负责窗口避让）
· 新增 `ComposeDestination`（`NavDestination` 壳），与 `MailDetailDestination`
  **完全同构** —— 宽屏由 `mode(Auto)` 自动并排在右栏，窄屏自动 push 覆盖全屏。
  **两条路径同一套代码，不自己判断宽窄**（这正是 `Navigation` 该干的事）。
· 走本页自己的 `Navigation` 栈（`COMPOSE_ROUTE`）而不是布尔 `@State showCompose`：
  路由让"返回"自动正确（系统返回键 / 手势 / 头部按钮弹同一个栈）；
  布尔状态要自己接三条返回路径 —— 那正是 2026-09-17 那批「返回直接回登录页」的来源。
· `InboxTab` 里那个自己的 `openCompose` 也一起改（它抄了同一个 `pushUrl`）——
  收件箱内按筛选账号写信、收件箱外用活跃账号写信，两条入口现在共用
  `CommPage.openComposeWith(accountId)`。

★ 两个必须守住的细节（都是上一次踩过的坑，这里重复了一遍）：
· 避让留给 **`@Entry` 包装层**，`ComposeView` 里 `embedded` 时取 0 ——
  同一个 View 被内嵌复用，而 `MainPage` 已经加过避让，加在里面就是**让两次**。
· 「取消」内嵌时必须弹**自己的**栈（`onBack`），不能 `router.back()` ——
  那会退掉整个 `MainPage`（写信只是它的一个右栏状态，不是一个页面）。
  `MailDetailView.goBack()` 里是同一条判断。
· 内嵌时参数走 `@Prop` 初值，**不读** `getRouter().getParams()` ——
  内嵌没走 router，那里拿到的是**上一次 push 的残留**，
  会把上一封信的收件人带进来（比空更坏）。

设备验证（模拟器 3184×2232 宽屏）：点悬浮加号 → 写信在**右栏**打开，
侧栏与列表栏都在；点「取消」→ 弹回右栏空态，列表与选中态不受影响。
 2026-09-20 12:57:55 +08:00
JianFeeeee
1da4e15a7b 跨端: 补齐「我的」页深色可读性（4 页 219 段全 ≥3:1）+ 判据自己漏报的那一类 
上一条把通信/日历/联系扫干净了，但**「我的」页没扫到**
（扫描脚本按文案点不到它 —— 那是侧栏**底部的头像按钮**，不是导航项）。
补上后立刻又抓出问题，并把判据自身的**漏报形状**一并修了。

## 一、「我的」页两处真 bug

1. **主题分段按钮 `SettingsPage.ets:834`**：
   `.fontColor(... ? Theme.surface : Theme.textPrimary)` —— `surface` 是
   **会翻转的面色**，压在 `Theme.accent` 蓝底上，深色下变成近黑。
   设备读数：`深色 2.93:1  ink rgb(32,34,36) bg rgb(34,96,228)`。
2. **权限档徽标 `MailDetailPage.ets:391`**：同一个错法（第 13 处）。
3. **账号名 `SettingsPage.ets:1179`**：三元里的裸 `Theme.accent`
   压在 `accentSoftFor()` 底上 ⇒ `jianf 2.83:1`。
   `AdminUsersPage.ets:386` 同形状（角色徽标）。

## 二、判据自己的漏报形状（比 bug 本身更值得记）

静态防线（`C｜会翻转的 Resource 不得当前景色`）**在 bug 存在时是绿的**。
原因是它的提取正则：

    /\.fontColor\(Theme\.([A-Za-z0-9_]+)\)/      ← 要求令牌是**唯一实参**

于是**三元里的令牌全被漏掉**：

    .fontColor(this.appearanceTheme === t ? Theme.surface : Theme.textPrimary)

改成"在 `fontColor(` 之后的整段实参里找所有 `Theme.X`"之后，
它**立刻报出上面第 1、2 两处**（此前一直绿）。

★ **判据漏报的常见形状是它自己的正则太窄，而不是被测代码太隐蔽。**
  这条写成注释留在判据里了。

## 三、我自己犯的批量替换错误（已加判据钉住）

把裸 `Theme.accent` 换成 `accentFor()` 时，**误把 6 处 `backgroundColor` 也换了**。
`accentFor()` 深色给浅蓝 `#80AFF9`，而搭档前景是白色 `accentFg`
⇒ 白字压浅蓝 ≈ **1.4:1**，主按钮文字会彻底看不见。

- 6 处已逐处还原（复核：`grep -c "backgroundColor(Theme.accentFor())"` = 0）。
- 新增判据 **`C2`**：`accentFor / dangerFor / approveFor / warnFgFor / textSubtleFor`
  **只能用于前景**，`backgroundColor(Theme.XFor(...))` 直接判红。
  （`accentSoftFor` 是例外 —— 它本来就是"面"。）
  ★ 修法不是"下次小心点"：批量替换一定会再犯，**一行判据把它变成不可能**。

## 四、设备复扫（修后）

```
[通信]      扫 42 段，低对比 0
[日历]      扫 85 段，低对比 0
[联系人]    扫 51 段，低对比 0
[我的]      扫 41 段，低对比 0      ← 新增
```
**219 段文字全部 ≥3:1**（本轮全部针对深色）。

## 五、底本

`baseline.sha` 第 5 次重算。重算前**专门复核**了"那 6 处误改有没有残留"
（不只看 `git diff` 非空就放行）：`backgroundColor(accentFor)` 计数为 0、
`git diff HEAD~1` 里 backgroundColor 只有 calendar 那一处（有意改动）。

`run-all.mjs` → `checks=515 pass=515 fail=0 skip=0 red=0 broken=0 unreported=0`。

**未验**：浅色主题下的对比度没扫（本轮全部针对深色）。
 2026-09-19 20:43:59 +08:00
JianFeeeee
4ecddfc2b6 跨端: 语义色/三级文字在深色下没提亮（设备扫出 12 处）+ 判据取样法修到第三版 
## 一、判据基建先修对，否则是在听噪声

深色可读性扫描的**取样法迭代了三版**，每版都因为**假红**才改的
（记在这里，因为"判据自己错"比"界面错"更费时间）：

1. **取中心一个像素** ⇒ 落在笔画之间、读到的是底色 ⇒ 一片 ratio=1.00 假红。
2. **取全局最暗/最亮** ⇒ 会采到**两个不同的东西**：细字的抗锯齿中间色。
   实例：segmented「日」报 ink `rgb(32,34,35)` / bg `rgb(98,100,101)` 2.69:1 ——
   而截图里它要么蓝底白字、要么深底浅字，两种都远高于 3:1。
   **反复核对才确认是判据的错，不是界面的错。**
3. **步长采样 + 众数** ⇒ 仍然假红：周表头「一」报 2.03:1，
   而逐像素的真实墨是 `rgb(166,167,167)`（**6.6:1**）——
   稀疏网格**整个跳过了笔画**。这不是调参能修好的（字越小越糟）。
4. **逐像素 + 众数=底 + 离底最远者=墨**（最终版）。
   理由：一个文字框里**面积最大的一定是底**，而"离底色最远"就是笔画最实那部分。
   ⚠️ 逐像素是**负担得起的**（整屏已解码在内存，一个框最多 9 万像素）——
   **不要再为了省开销退回抽样**，前两版都因此假红。

## 二、真 bug 三批（都是"深色下没提亮"）

### ① 语义色前景（12 处 → 修完设备复扫 0）
WebUI 的语义色也是**双通道**，`.dark` 段把 `red/green/amber-700` 换成浅色
（`248/118/249 → 164/219/195` 那组）。鸿蒙只有一个深色值：
- 「归档」按钮 `Theme.danger` #B91C1C 压深面 ⇒ **2.47:1**（联系人页 7 处）
- 「今天」/「日」等 ⇒ **2.38–2.77:1**

加 `dangerDark/approveDark/warnFgDark`（逐字对齐 WebUI `.dark`）
+ `dangerFor()/approveFor()/warnFgFor()` 入口，22 处接入。

### ② 日历工具条整块配色抄错（不是"深色档选错"）
对照 WebUI `CalendarView.tsx:313-331`：

| 元素 | WebUI | 鸿蒙（改前） |
|---|---|---|
| 「今天」 | `border-gray-300` + `text-gray-700`（**中性**） | `accentSoft` 底 + `accentStrong` 字 |
| 月/周/日 未选中 | `bg-white` + `text-gray-700` | `accentSoft` 底 |

鸿蒙把**次要的中性按钮**画成了**品牌色按钮** —— 视觉重量跟主操作一样，
三个档看起来"都像选中"。已按 WebUI 改成中性。

### ③ 三级文字在深色下 2.82:1（**71 处**，全局最大的一个）
WebUI 的 `.dark` 段注释逐字写着这个坑：

> 「`gray-400/500`（次要文字）→ **提亮**。深底上的浅色 gray-400
>  只有约 2:1 对比度，远低于 WCAG AA 的 4.5:1 —— **看得见但读不动**。」

鸿蒙用的系统三级色 `ohos_id_color_text_tertiary` 深色下是 `rgb(102,103,105)`
压深面 **2.82–3.05:1**，而它被用在 10–11px 的**小字**上
（时间戳、农历、空态、辅助说明）。

**不换掉系统令牌**（"系统拥有的维度"纪律照旧），加 `textSubtleFor()`：
深色下改用二级色（实测 `rgb(166,167,167)` ≈ 7.15:1，
且与 WebUI 的 `gray-500` 同档位）。71 处接入。

**设备复扫（修后）**：通信/日历/联系三页 **176 段文字全部 ≥3:1**。

## 三、欠账与底本

- `baseline.sha` 第 4 次重算。仍**先逐个取证**：
  `git diff --quiet HEAD -- <f> && echo STALE || echo INTENTIONAL`
  ⇒ 三个全是 `INTENTIONAL`（我改的），不是变异残留。
  把这条取证命令也写进文件，下次照抄。
- `dangerDark/approveDark/warnFgDark` 已登记进 `SELF_OWNED_COLORS`
  + `Theme.ets` 登记表（各带理由与 WebUI 出处）。

`run-all.mjs` → `checks=514 pass=514 fail=0 skip=0 red=0 broken=0 unreported=0`。

**未验**：①「我的」页（底部头像按钮，扫描脚本没找到入口）没扫；
② 浅色下的对比度没扫（本轮全部针对深色）。
 2026-09-19 20:27:09 +08:00
JianFeeeee
13b557a742 跨端: 品牌蓝深色下没提亮（24 处字/图标看不见）+ 补深色可读性设备判据 
## 一、真 bug：WebUI 深色下把品牌蓝**提亮**了，这边没有

WebUI 的强调色是**双通道**（`tailwind.config.js` 的 `backgroundColor`
/`textColor` 覆盖 + `index.css` 两段定义）：

| 通道 | 用途 | 浅色 | 深色 |
|---|---|---|---|
| `--s-blue-600` | **实心按钮底** | `37 99 235` | `37 99 235`（**同值**）|
| `--c-blue-600` | 内容/交互的**蓝字与图标** | `37 99 235` | **`128 175 249`** |

`index.css:353` 写了理由：主按钮底跟着变「会让主按钮在深色页面上
失去『这是主操作』的视觉重量」；而蓝字必须提亮，否则深底上读不动。

鸿蒙只有一个 `Theme.accent = '#2563EB'` ⇒ 24 处字/图标在深色下
对比度 **2.61:1**（设备实测：管理页返回箭头 `‹`），低于 WCAG 图形下限 3:1。

**取证方式**：在跑着的 WebUI 上用 CDP 读**计算样式**（不是读 CSS 源）——
浅色 `37 99 235` / 深色 `128 175 249`，实测确认。

## 二、修法：加前景专用的深色档 + 唯一入口

- `Theme.accentDark = '#80AFF9'`（= WebUI `.dark --c-blue-600`）
- `Theme.accentFor(dark?)` 作为**前景**唯一入口
- **当背景的 20 处保持 `Theme.accent` 不动**（跟 WebUI 的 `--s-*` 一致）

24 处 `.fontColor/.iconColor(Theme.accent)` → `Theme.accentFor()`。

## 三、顺手修掉「转述一层就会漏」这个结构问题

`accentSoftFor(isDark)` 原本的约定是"页面算好深浅色传进来"。
给 `accentFor` 做准备时一数：**8 处**直接用了 `Theme.accentSoft`（没走入口）
—— 约定**已经漏了**，而漏掉的症状正是上一轮那个"深色下白底卡片刺眼"。

于是把两个 `For()` 的参数都改成**可选**：`AppStorage` 是 ArkTS 全局键值存储，
静态类可以直接读（原来"拿不到 Context"的理由不成立）。
⇒ `Theme.isDarkNow()` 成为唯一判断点，调用方不必再各自转述。

## 四、设备判据：深色可读性**扫一屏**

原来只有悬浮球那一条（单个点）。这个 bug 类一天撞到**两批**（12 处 + 24 处），
逐处写判据追不上 ⇒ 改成把当前页所有小段文字都量一遍对比度。

三个实现要点（第一版全踩了，都写进注释）：
- **不能只取中心一个像素**：中心多半落在笔画之间 ⇒ 读到的是底色，
  报出一片 ratio=1.00 的假红。改成**框内网格扫描取极值**（最亮=底/最暗=墨）。
- **整屏解码一次**：每点 spawn 一次 ffmpeg 太慢 ⇒ 新增
  `readPixels()`（157ms 解整屏，比逐点快三个数量级）。
- **只判"有真实墨迹"的框**（`hi.L - lo.L >= 0.02`），否则跳过而不是判红。

实测：修前 1 处低对比（2.61:1），修后 **40 段文字全部 ≥3:1**。

## 五、判据自身的三个修正

- `accentSoftFor(dark:)` 的签名断言跟着放宽成 `dark?`，并**补上 `accentFor` 的**。
- **孤儿令牌判据从"一跳"改成"走整条链"**：`KEY_IS_DARK` ← `isDarkNow()`
  ← `accentFor()` ← 24 处页面。只查一跳时它假红 ——
  ★ **"有没有人用"是可达性问题，不是邻接问题**；加中间层（抽 `For()` 入口）
  恰恰是我们鼓励的写法，而旧判据会因此假红。
- 手写色登记表补 `accentDark` 一行理由。

## 六、`baseline.sha` 重算（先核过不是残留）

三个文件哈希对不上。逐个 `git diff --quiet HEAD -- <f>` 取证：
- `AdminUsersPage.ets` / `SettingsPage.ets` —— 本次**有意编辑**；
- `api/AppearanceApi.ets` —— **与 HEAD 逐字节相同** ⇒ 底本取完后被**合法改过**
  （提交 `f811c98`），属 `stale` 不是 `residue`。

按该文件自己那条纪律（「重算必须是一次有记录的动作」）在文件里记了理由。

`run-all.mjs` → `checks=514 pass=514 fail=0 skip=0 red=0 broken=0 unreported=0`。
 2026-09-19 20:05:33 +08:00
JianFeeeee
fc295893cb 跨端: 深色模式下的品牌浅底不跟随 —— 12 处「选中/未读」底色在深色页上刺眼 
## 真 bug（设备实测）

深色主题下，「我的」页**选中**的那张账号卡片仍是接近纯白的浅蓝
（实测像素 `(255,255,255)` 级别的浅底压在 `(32,34,36)` 的深色页上）。

根因：`Theme.accentSoft = '#EFF6FF'` 是**写死的浅色**，而它被当作
「选中态背景」用在 12 处（未读邮件行、选中账号、分段选中、登录页模式切换…）。

**为什么只有 WebUI 没这个问题**：它有 CSS 变量的**反转发**机制 ——
`index.css:113` 的 `--c-blue-50: 239 246 255` 在 `.dark` 段（`:475`）被换成
`28 37 54`（深蓝黑）。ArkTS 的 `static readonly` **一个常量一个值**，
没有那层机制 ⇒ 静态常量必须自己提供两个取值。

## 修法

1. `Theme.accentSoftDark = '#1C2536'`（对齐 WebUI `.dark --c-blue-50` 的 `28 37 54`）
2. `Theme.accentSoftFor(dark)` 作为**唯一入口** —— 不在页面里各自
   `isDark ? a : b`：那样每处都会各写一遍，迟早漏一处
   （WebUI 那条"由 test/theme.test.mjs 逐档断言"就是为防这个）
3. **深浅色从哪来**：只有 `MainPage` 算得出（它读 `resourceManager` 的
   `colorMode`）。所以走 `AppStorage` 单向发布（与徽标、windowInsets 同一套）：
   MainPage 算 → 写 `agentmail.appearance.isDark` → 各窗格 `@StorageProp` 读。
   6 个文件、12 处，全部改用 `accentSoftFor(this.isDarkNow)`。

**设备实测**：深色下「我的」页账号卡片与收件箱未读行都变成深蓝底，
像素 `(32,34,36)` 与页面底一致（不再刺眼）。

## 判据（这条是新加的，形状值得记）

`cross-client-theme` 新增：**品牌浅底必须有深色变体**。断三件事：
1. 深色变体存在，且**取值从 WebUI 的 `.dark` 段反推**（不是随手挑一个深色）；
2. 有按主题选值的**入口**（防"页面各自写三元"）；
3. **用到它的地方真的走那个入口** —— 扫描所有 `backgroundColor(… accentSoft …)`
   并排除 `accentSoftFor`，把漏改的位置**逐行报出来**。

第 3 条在我改到一半时**当场列出了剩下 9 处**（`CalendarPage:1172`、
`ComposePage:255`、`LoginPage:327`…）—— 这就是它该有的样子：
不是"断言存在某个常量"，而是"断言没有一处漏改"。

★ 写这条判据时踩了自己一次：JS 模板串里嵌了反引号包围的标识符
（`` `accentSoft` ``），直接 SyntaxError。改用字符串拼接。

## 判据

`run-all.mjs` → `checks=506 pass=506 fail=0 skip=0 red=0 broken=0 unreported=0`。
`hvigorw assembleHap` 成功；前端重建。

**未验**：日历/登录页在深色下的观感（只逐处改了底色，没逐页截图）。
 2026-09-19 16:02:26 +08:00
JianFeeeee
af2d2b5cad 跨端: 鸿蒙动画补齐 —— 并且发现原来的「逐字一致」是假的（令牌存在 ≠ 动画用了它） 
用户：「A，同时把鸿蒙app的动画补齐」。

## 先纠一条错的前提（这是本轮最有价值的发现）

`Theme.ets` 的注释与 `harmony-nav` 的判据**都**写着：「三个数与 WebUI **逐字一致**：
`--ease-out-soft: cubic-bezier(0.22,1,0.36,1)`、`--dur-fast: 120ms`、`--dur-base: 180ms`」，
`paneRiseIn()` 就按 `durBase(180)` + `easeOutSoft` 做。

三个令牌**确实存在**（`index.css:310-312`）—— 但这句话把「令牌存在」当成了「动画用了它」：

| WebUI 里 | 真实用途 |
|---|---|
| `--dur-base: 180ms` | **只**用在壁纸淡入（`:747`） |
| `--ease-out-soft (0.22,1,0.36,1)` | **只**用在 transition（壁纸、控件变色） |
| **所有 @keyframes 动画** | 硬编码 **150ms / 200ms** + `cubic-bezier(0.22, 0.61, 0.36, 1)` |

全仓 `(0.22,0.61,0.36,1)` 出现 **5 次**（rise-in×3 / cal-in×2），`(0.22,1,0.36,1)` 只出现
**1 次**（令牌定义处）。**是两根不同的曲线** —— 旧代码的面板入场比 WebUI 慢 30ms 且曲线偏软。

所以令牌拆成两组，各对齐各的：控件类 `durFast + easeOutSoft`；动画类
`durRise(150)/durMenu(140)/durCal(200) + easeRise(0.22,0.61,0.36,1)`。

## 补的动画（对齐 WebUI 三个 @keyframes）

- `menuIn()` —— 弹层：下移 4vp + 缩到 0.985 + 淡入（`@keyframes menu-in`）。
  ★ 适用范围照搬 WebUI 注释那条窄口径（「只给真正是弹层的东西」）：那条规则曾挂着
  `glass-control`，于是每次切视图**所有按钮与输入框一起淡入位移**，09-15 被摘掉。
  挂到写邮件页的账号候选列表上。
- `calendarSlide(forward)` —— 日历翻月：从 ±12% 横向滑入（`cal-in-next/prev`）。
  方向由新增 `@State slideForward` 带进 `animateTo` 闭包；网格键加 `monthKey()` 前缀
  保证月份一变所有键全变（否则"跨年同名月"那类边角会静默不播）。
- 写信页整页 `rise-in`、回复框 `rise-in`（WebUI 挂在回复框本身，不是外层遮罩 ——
  挂遮罩上会让整个屏幕一起位移，看起来是"页面在动"而不是"框弹出来"）。

**实测确认真的会播**（不是"编译过了"）：按本仓记录的手法把 `durCal` 临时改成 8000
做慢动作，连拍三帧 —— 截图硬证**两张月历同时在屏**（九月淡出、十月从右侧 12% 滑入），
验完还原成 200ms。

## 判据：从「令牌存在」改成「动画真的用了那个令牌」

`harmony-nav` 那条判据原文锚在令牌上，所以它对上面那个 bug **一辈子全绿**。
重写为：
- 从 WebUI `index.css` **读出** `rise-in` 的真实时长与曲线（`150ms` + 那条 bezier），
  再断言鸿蒙的 `durRise` 与曲线字面量与之逐字一致 —— 而不是"仓库里有没有 180 这个数"；
- ★ 把 `paneRiseIn()` 的**函数体抠出来**单独断言它引的是 `durRise/easeRise`，
  且**不得出现** `durBase/easeOutSoft`。

**这一步不能省 —— 我第一版就漏了它**：断言了令牌存在、也断言了曲线字面量存在，
但没断言函数用了它们；于是把函数体换回旧的错值后判据**仍然全绿**。
变异自检抓住了这一点，补上函数体断言后同一个变异 ⇒ 判红 ✓。
与今天修的另一处同源：**判据要锚在"这个东西被用在哪"，不是"它存在"**。
 2026-09-18 10:56:57 +08:00
JianFeeeee
a87a88ea2a 跨端: 全屏是**窗口级**的 —— 光给 MainPage 让位，等于把黑边换成顶栏压字 
上一提交（cac026e）把黑边消掉了，但**只给 `MainPage` 加了避让**。
实测截图硬证：写邮件页的「取消」与时钟「09:49」重叠、「发送」与 wifi/电量图标重叠。

## 根因：`setWindowLayoutFullScreen(true)` 不只作用于当前页

它是**窗口级**的：一旦设上，这个窗口里**所有**用 `router.pushUrl` 推上来的页
（写邮件/会话/收件箱/邮件详情/用户管理）都从 y=0 开始画。

所以上次那个错与更早那次（6861934 只删全屏不留避让）**同源**：
都是"同一件事只做了一半"。上次少的是**步骤**，这次少的是**页面**。

## 改法：把"消费避让"变成每个 @Entry 页都得做的事

- `model/WindowInsets.ts` 加 `topInset(insets)`：取 0 时（未全屏/取不到）
  表达式的值与旧代码**逐字相同** ⇒ 没全屏的环境行为不变，不会把谁顶下去。
- 五个页各按自己的形状让位：
  - 固定 56vp 顶栏（写邮件/会话/收件箱/用户管理）：
    `height(56 + topInset(...))` **与** `padding(… top: topInset(...))` 一起加 ——
    只加 padding 会把固定的 56 切掉 39（按钮压扁），只加 height 则内容仍贴 y=0。
  - 满高容器（邮件详情）：`padding({ top })` 加在 `@Entry` 包装层。
    ★ **不能加在 `MailDetailView` 里面**：它同时被 `MainPage` 的 Navigation 内嵌复用，
      而那层已经让过位了 —— 加在里面就变成让两次（39vp 变 78vp）。
      这类"同一组件两种入口"的坑与"悬浮加号要放在 Navigation 内部"同源：
      **让位的量取决于它被挂在哪一层**。

## 判据（harmony-window 8 → 9 条）

接线⑤ 枚举**所有** `@Entry` 页并要求它们消费避让 —— 口径是
"有人在窗口上开了全屏 ⇒ 每个 @Entry 页都得让"，而不是"检查 MainPage 做了没有"。
后者在新增一个推上来的页时会静默逃掉，而"新增一个页"正是最常发生的事。

豁免要带**可机器复核**的理由（不再是"这个页先不管"）：
- `Index.ets`：DevEco 模板欢迎页，不在 `main_pages.json` 流程里；
- `LoginPage.ets`：根容器 `.align(Alignment.Center)` ⇒ 结构上碰不到 y=0。
  但"居中"是可能被改掉的性质 ⇒ 判据**断言那个居中写法仍然存在**，
  谁把它改成贴顶，这条先红，逼他回来重新想这个页要不要避让。

**变异自检两个方向都跑过**：
- 把 ComposePage 避让整个拿掉（重演"只给 MainPage 加"）⇒ 红 ✓
- 只加 padding 不加 height（会压扁按钮）⇒ 红 ✓

★ 期间还修掉两处"判据锚在当时的字符串上"（不是放宽，是它把"加一个正当的避让"
  与"真犯那个错"判得一模一样）：
  - `harmony-nav` ④ 的留白断言、`harmony-widescreen` ④ 的 navReserve 断言，
    都改成剥注释后验**形状与不变量**，而不是写死字面表达式。改完变异仍咬得住。
 2026-09-18 10:34:00 +08:00
JianFeeeee
cfe7808af4 ke: 鸿蒙 UI 整改：emoji→AmIcon 图标、宽屏侧栏、Md 第三方库、通知可配置项 
- common/Icons.ets（生成器产出）：43 枚与 WebUI icons.tsx 同几何的 Path 图标
- NavItems.ts：icon(emoji) → iconKey，与 WebUI 导航同图标
- 全页面 emoji 清除（空态改单行灰字，按钮/头像/刷新等换 AmIcon）
- MailDetailPage 接入 @luvi/lv-markdown-in（第三方，替代手写解析器）
- WideSidebar + MainPage isWide(≥768vp)：宽屏侧栏 60vp 图标轨、藏底部条、onAreaChange 断点
- 通知=可配置项（默认关）：PushService.isEnabled/setEnabled + reportToken 最前 gate （关=不取token/不弹权限/不打网关）+ SettingsPage Toggle + 服务端通道状态提示
- EntryAbility.onCreate 解析 want：冷启点通知也能路由（原来只有 onNewWant）
- 判据：harmony-widescreen(4) + harmony-push-optin(4) 新增；harmony-nav 同步 iconKey/条件 padding
 2026-09-16 07:46:52 +08:00
JianFeeeee
c6aaf8c468 refactor(harmony): 23 处废弃 API 换成 UIContext 写法（全局 promptAction.showToast 自 API 18 废弃） 
SDK 里写得很清楚：`@ohos.promptAction.d.ts` 的全局 `showToast` 标着 `@deprecated since 18`，
替代品是 `UIContext.getPromptAction()`。仓库里有 23 处这种调用（6 个页面，历史遗留）——
这一轮既然在按"用系统方案"整理鸿蒙侧，就一次扫干净，并加判据挡住回潮。

- `promptAction.showToast(...)` → `this.getUIContext().getPromptAction().showToast(...)`（23 处）
- 清掉不再需要的 `promptAction` import（多个 → 只留 `router` 等）
- 新增判据：不得再用全局写法。防的不是这次，而是**新增页面照抄旧代码**这条回退路径 ——
  它编译照样通过、只在真机上行为不同。自检同时验"认得出旧写法"与"不误伤新写法"。
- 顺带把权限徽标那条"点它弹说明"的判据改成钉**非废弃**写法（原来是 `promptAction.showToast(`）。

变异验证：把 `SettingsPage` 的一处改回全局写法 → 判红并点出文件。

验证：`hvigorw assembleHap` BUILD SUCCESSFUL；`npm test` 退出码 0（harmony-logic 20 条）。
 2026-09-14 14:05:35 +08:00
JianFeeeee
b041ea51e4 fix(harmony): 令牌收尾 —— 裸色值清零、遮罩拆两段式、权限档位配色对齐 WebUI 
接手核对时发现：「不许写死颜色」那条判据**只挡得住枚举的 8 个旧值** —— 判据全绿的
同期，pages/ 里还留着 14 处另一套写死的色（Google/Material：#E8F0FE、#E8F5E9、
#FFF3E0、#D93025、#777777×2、#555555、#444444、#cccccc、#aaaaaa、
遮罩 #80000000×2、透明 #00000000×2）。枚举挡不住漂移，只有"类"能挡。

## 改法

- 14 处全部换成令牌。新增 accentStrong / warnBg / warnFg（取值对齐 WebUI `:root`
  的 blue-700 / amber-50 / amber-700）与 `Theme.permBg/permFg` —— 权限档位徽标与
  WebUI 的 `PermissionChip.tsx` **同一映射**（plan=蓝 / workspace=绿 / full=琥珀）；
  原先写成 `full ? 绿 : 橙`（Material 色），与 WebUI **反着来**。
- 遮罩拆成 `overlayColor` + `overlayAlpha`（照 WebUI 的 `--bg-scrim` + `--bg-dim`
  两段式）：遮罩色要能随主题换向，色与透明度焊死成一个 `#AARRGGBB` 等于把枚举写回
  代码。ArkUI 只认单值，故由 `Theme.overlay()` 组装。
- 判据从"枚举旧值"改成"按类挡"：pages/ 下**一个裸色值都不许有**（含 8 位
  `#AARRGGBB`），页面清单从硬编码 7 个文件名改成**扫目录** —— 旧写法下，
  接下来要加的发件箱/授权/日历会自动逃出判据。另加一条判据：权限档位配色与
  WebUI `:root` 变量逐一比对，防"看起来差不多"。

## 验证

- 变异测试：往 `InboxPage.ets` 塞一个 `#E8F0FE` → 判据红；撤回 → 绿。
- cross-client 判据 6 → 8 条全绿；`hvigorw assembleHap` BUILD SUCCESSFUL。
- **视觉未验**（模拟器在本机文件沙箱下起不来，见 `docs/HARMONY-ALIGN-PLAN.md` 5.4），
  未写成"已完成"。
 2026-09-14 13:29:50 +08:00
JianFeeeee
5434bc9e4e feat(harmony): 对齐第一阶段 + 对齐计划文档（差距/分期/验收纪律） 
用户：「安排对齐」。

## 先量差距（不靠感觉）

鸿蒙侧的调色板与 WebUI **根本不同**：`#1A73E8`（Google 蓝）vs 品牌 `#2563EB`、
`#333333` vs slate-900 `#0F172A`、`#F5F7FA` vs `#F8FAFC`、`#FF4444` vs red-600…
共 217 处硬编码色值散在 7 个页面里。

功能面：鸿蒙是 收件箱/会话/联系人 三个 tab，**缺 发件箱 / 授权 / 日历 / 管理**，
也没有玻璃悬浮底栏、主题壁纸同步、Composer 共用组件。

## 第一阶段（已完成并可验收）

- `common/Theme.ets` 补齐文字/浅底/语义令牌，页面里的旧调色板**全量替换为令牌**
  （共 203 处），`hvigorw assembleHap` **BUILD SUCCESSFUL**。
- 判据：`cross-client-theme.test.mjs` 新增"鸿蒙页面里不得再出现旧调色板色值"
  （6 条全绿，含扰动自检）。这条防的是**新页面又随手写个"差不多"的颜色** ——
  漂移就是这么开始的，而此前没有任何判据会红。

## 计划文档：docs/HARMONY-ALIGN-PLAN.md

写清两件事，免得每轮重新猜"还差什么"：

- **差距表**（逐项，标出"缺页面/交互不同/观感不同"的性质）；
- **分期**：P2 发件箱（与收件箱同构，风险最低）→ P3 授权页（备注必须随决策送达模型
  —— WebUI 侧踩过这个坑）→ P4 主题/壁纸同步（服务端"无记录"时以本地为准）
  → P5 玻璃悬浮导航 → P6 日历（最大，单独排）。

## 如实说明

鸿蒙**视觉未验证**：本机 `hdc list targets` 为空、HAP 未签名 ⇒ 只能保证编译通过 +
令牌一致，观感需要设备或签名后由人眼确认。文档里也把这条写进"验收纪律"。
 2026-09-14 12:49:40 +08:00
JianFeeeee
f9d757b5e5 chore: directory migration - gateway→server, web→client/electron 2026-09-08 19:16:35 +08:00