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

12 Commits

Author SHA1 Message Date
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
4ff6b10260 跨端: 联系人页补齐「写信 / 归档」—— 顺带撞出三个只在跑起来才现形的 bug 
用户：「你自己看看这些页面和webui有哪怕一丁点的相似之处吗？」
把两个客户端**同一个宽度**并排看之后，缺的很具体：WebUI 联系人卡片有
「写信 / 归档」，鸿蒙一个都没有。补的过程撞出三个缺陷，都不是"代码不合法"——
编译器与既有判据全绿：

## ① 归档打的是**服务端不存在**的路由（死函数）

`MailApi.archiveContact` 打的是 `DELETE /me/contacts/{name}/{path}`：

- `grep 'me/contacts' server/cmd/server/main.go` **零命中** ⇒ 按钮接上去就是 404；
- 全仓**没有任何调用方** ⇒ 它是个从没跑过的死函数，所以"没有归档按钮"这件事
  一直没暴露这个错。

服务端真实形状是 `POST /api/v1/contacts/archive`（`handler.ArchiveContact`），
body 二选一 `{session_id}` / `{address}`。**跟 WebUI 同口径用 session_id**：
address 会随别名变化，只有 session_id 是会话的身份。

## ② 用已存 token 恢复登录**永远进不去主界面**（最恶劣的一个）

`LoginPage.tryRestore` 验完 token 就结束了 —— 设了 `loggedIn = true`
（界面出现「登录成功：jianf」）却**从无跳转**。本文件另外两条成功路径
（`aboutToAppear` 快速路径、`doLogin` 末尾）都有跳转，唯独这条没有，
而它**恰恰是老用户最常走的那条**（重启时 token 还在，`doLogin` 根本不会被调用）。

症状最坏的地方是它**看起来是成功的**。实测（模拟器 + jianf 的永久 key）：
日志只有 `→ GET /auth/me` 然后什么都没有。补齐 ① 跳转 ② 账号登记
③ SSE 连接（后两条是 `doLogin` 有而这里缺的，少了它们进主界面是个瘸的状态，
而且因为 `aboutToAppear` 的快速路径靠账号命中，下次启动还会重走这里 ⇒ 永远进不去）。

修后实测：启动即进主界面（可见文本变成「发件箱/授权/收件箱 · 2 组 · 50 封」）。

## ③ 时间戳原样印出来

卡片直接印 `last_activity` ⇒ 屏上是 `2026-09-18T02:50:35.49065Z`。
WebUI 是 `09/18 10:50`（`toLocaleString('zh-CN', {month,day,hour,minute})`，**本地**时区）。
加 `MailGrouping.shortTimeOf`（走 `Date` 取本地字段；**不许 `.slice()`** ——
那是拿 UTC 的月/日当本地时刻，UTC+8 的 09-15 00:30 会显示成 09-14 16:30）。
实测：`112 封 · 09/18 10:50`，与 WebUI 逐字一致。

## 补的界面（三折叠模拟器 3184px 展开态实测）

- 两种视图**各一处**「写信 / 归档」（WebUI 两视图同语义），WebUI 用 `.reveal`
  悬停显形，**鸿蒙不能照抄**：`index.css` 那段注释已经踩过这个坑
  （触摸设备没 hover ⇒ 按钮透明却仍可点，一个看不见却按得动的破坏性按钮更糟），
  WebUI 的修法是只在真支持悬停的设备上隐藏 ⇒ 鸿蒙这两个按钮**常显**。
- 归档先确认，**两视图共用同一个确认框**（WebUI 原话：换个视图就换套确认 UI
  只会让人对「自己点了什么」更没底）；文案逐字一致。
- 列表视图的 meta 行原来放 `last_preview`，于是同一联系人在两视图里的关键信息
  不一致 ⇒ 改成与卡片视图同源（`N 封 · 时间`）。
- ★ 一处只有跑起来才会发现的坑：列表视图的 ListItem 钉死 `.height(85)` +
  `clip(true)`，而确认框比 85 高 ⇒ **按钮被裁掉、点不了也退不出**。
  确认态下高度交给内容自己定。

## 判据（新增 harmony-contacts，5 条；4 个变异方向都跑过）

判的都是"按下去会发生什么"，不是"按钮在不在"：
① 归档打的是服务端真有的路由（同时钉住**没有**再用那条不存在的 DELETE —— 只钉前者的话，
   加个平行实现也能全绿）；② 两视图各一处动作且去向正确；③ 确认框只有 1 个定义、
   两视图都调它、文案逐字一致、确认态下点卡片不开会话；④ 时间戳走了格式化且
   函数本身不走 slice；⑤ **切出 `tryRestore` 的函数体**判它自己含跳转
   （只判全文件出现次数的话，另外两条路径里那两句就够让它变绿）。
 2026-09-18 12:17:41 +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
423ff9fbb2 跨端: feat(推送客户端) 收尾两处接线（pi 邮件 66bbd929 分工）+ 换账号补报 
`PushService.ets` 与 `pendingRoute` 都早就写好了，但**没人调用/没人读** ——
而"写好了"与"接上了"是两件事：ArkTS 只编译可达模块，往一个无人 import 的
文件里放必然报错的类型错误，`assembleHap` 照样 BUILD SUCCESSFUL
（pi 与我各复现过一个方向）。这次补的是**边**，不是点。

① 登录成功补报（LoginPage）：`EntryAbility.onCreate` 那次在**登录之前**跑，
   那时 `ApiClient` 还没有 token ⇒ 服务端 401，而 `reportToken` 的失败是静默的
   ⇒ "启动时报过"不等于"这个账号登记过"。补三条登录路径，一条都不能漏：
   快速路径（已有账号直接进主界面，老用户走这条）/ tryRestore / doLogin。

② 换账号补报（SettingsPage.switchTo，**我加的第三处**）：服务端语义是同一
   token 换账号**转移**而非并存 ⇒ 新账号其实没登记过。幂等标记按
   `accountKey|token` 存，所以这里调一次必然重发，不会被"我报过"挡掉。
   不补的症状：切完账号，通知仍推给上一个账号。

③ pendingRoute 消费端（MainPage.CommPage）：`EntryAbility` 已把通知 data
   解析成 `pendingRoute`（冷启 onCreate / 热启 onNewWant 都写了），
   **但没有任何东西读它** ⇒ 点通知只拉起 App、停在列表页。
   在 CommPage 消费（详情页是这个 Navigation 的 navPathStack 上的路由，
   栈只有它持有），消费后**立刻清空**（它是"待处理"不是"当前页"，
   不清则返回列表再进来会被反复跳走）。

判据：`harmony-push.test.mjs` 15 → 18 条，三条新判据钉的就是上面这三条边，
**三条都做了变异验证**（各自删掉对应接线即红、恢复即绿）。
`LoginPage` 那条数**恰好 3 处**调用：少了快速路径＝老用户永远不补报，
多了要问清是哪条路径。

编译验证（不是"命令成功"，是"它真读了这个文件"）：三处改动各植入一次必然
类型错误 ⇒ BUILD FAILED 且 `At File:` 指到**新代码那一行**（MainPage:1173 /
LoginPage:108 / SettingsPage:456），恢复后 BUILD SUCCESSFUL。
产物侧证：`modules.abc` 里能查到 `consumePendingRoute`(2) / `reportPushToken`(2)。
 2026-09-17 19:03:14 +08:00
JianFeeeee
a5f680a147 harmony(ui): 登录页 1:1 对齐 WebUI 卡片规格 + 通信页改用系统 Navigation Auto 
登录页（LoginPage.ets）：对照 WebUI LoginPage.tsx 同规格重写 build()
- maxWidth 380vp 居中卡片（与 WebUI 380px 同档）
- 14vp 圆角（Theme.glassRadius）
- 48vp 品牌图标（Envelope 浅蓝底 accentSoft）
- 显式字段标签（服务器/用户名/密码/用户密钥）
- 40vp 输入框与登录按钮（WebUI 控件同高）
- 分段式登录方式切换（账号密码 / 用户密钥）
- 窄屏安全边距 16vp + Scroll 可滚

通信页（MainPage.ets CommPage）：改用鸿蒙系统 Navigation 组件
- Navigation(navPathStack) 包住列表，navDestination 注册邮件详情目标页
- mode(NavigationMode.Auto)：phone 自动 Stack、tablet/2in1 自动 Split
- navBarWidth(320) 对齐 WebUI MailList 320px；navBarWidthRange([280,360])
- minContentWidth(360) 参与 Auto 断点计算
- Inbox/Sent 选中邮件改走 navPathStack.pushPath，不再 router.pushUrl
- 切收件箱/发件箱/授权时清空详情栈避免跨栏残留

详情页（MailDetailPage.ets）：抽出可复用 MailDetailView
- 既有详情实现导出为 @Component struct MailDetailView
- 新增 initialMailId/initialAccountId/embedded/onBack 输入
- 无 initialMailId 时才读路由参数（兼容旧 router 入口）
- embedded=true 时返回走 onBack 回调（NavPathStack.pop）
- 薄壳 @Entry MailDetailPage 用 Column 包裹（@Entry 根节点须容器）

module.json5：deviceTypes 扩展为 phone/tablet/2in1 三形态

判据：harmony-widescreen.test.mjs 新增 ⑥ 钉住 Navigation Auto 不许退回手搓分栏

验证：ArkTS 编译通过；harmony-arkts/widescreen/nav/cross-client-theme 35/35 通过
 2026-09-17 10:58:31 +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
9c6e9c66ad 跨端: 修复: 鸿蒙客户端"连不上服务器"—— 地址补 /api/v1 + 失败分类成人话（含网络白名单固化） 
症状
  鸿蒙客户端（client/harmony）连不上服务端，界面只显示"无法连接"，用户无法自助；
  而服务端 HTTPS 完全正常：https://mail.jianfgit.xyz/health → 200、
  /api/v1/auth/me → 401、/api/v1/events/stream → 401（Let's Encrypt *.jianfgit.xyz，
  TLS 校验通过；代理与直连 http://127.0.0.1:8180 行为一致）。

根因（两条，逐条核实过，其中一条**推翻了原判断**）
  ① apiBase 是"API 前缀本身"（ApiClient 里拼的是 '/auth/login' 这类相对路径），
     而 Ui 只做 trim+去尾斜杠：用户若只填 `https://mail.jianfgit.xyz/`，请求就打到
     `https://mail.jianfgit.xyz/auth/login` ⇒ 404，客户端再把它压成"无法连接"。
     **这是本次故障最可能的直接原因。**
  ② 默认值 `http://192.168.2.60:8180/api/v1` 是明文 + 写死内网 IP：手机不在同网段
     就永远不通（mail.jianfgit.xyz 解析到的就是这台内网机）。
     ★ 但"鸿蒙默认禁止明文 HTTP"这条**不成立**，已按本机离线官方文档核实：
     `devecocli docs read .../使用HTTP访问网络/http-request` 的《明文HTTP访问权限配置说明》
     写明 cleartextTrafficPermitted "默认为 true"，Network Kit 默认允许明文；
     另有 FAQ《Stage模型如何配置支持http明文传输》："无需配置，支持HTTP明文传输数据"。
     ⇒ network_config.json 按"显式固化意图"处理（照文档形状写对，但**不冒充**它是修复）。
     本机 SDK @ohos.net.http.d.ts 里确实有 2300997 Cleartext traffic not permitted（since 18），
     所以那条错误码在客户端被建成一条可读提示，而不是被忽略。

改法
  · 新增 model/ApiBase.ts（纯逻辑，无 @ohos，判据能用 node 直接跑）：
    normalizeApiBase（去尾斜杠**但不咬协议 //**、末尾没有 /api/v1 就补、已有的一字不动）、
    validateApiBase（自带修法的中文提示 + "公网明文才告警、内网明文不误报"）、
    describeFailure（404 自己写文案并点名 /api/v1；其它状态码让服务端文案说话；
    网络层按 2300006/2300007/2300028/2300997/2300998/2300058-60-77 分类成人话）。
  · Config.ets：DEFAULT_API_BASE → https://mail.jianfgit.xyz/api/v1。
  · ApiClient.ets：setBase/init **都**过 normalizeApiBase（唯一闸口 ⇒ 老装机里已经存下的
    坏地址在读回时就治好，光改默认值救不了它）；ApiError 带 nativeCode；错误路径改走
    describeFailure；404 的提示指向"地址少了 /api/v1"。
  · LoginPage.ets：地址先校验后持久化（不合法**不落库**、给可执行提示），明文警告常驻渲染；
    SettingsPage.ets：添加账号同样校验（多账号库直接喂 SseService，坏地址会让该账号的实时
    通道永久连不上）；AccountManager/SseService 落库与建连时各自再归一化一次。
  · 新增 resources/base/profile/network_config.json：按官方文档形状把内网明文
    （192.168.2.60 / 10.0.2.2 / localhost）显式列进 domain-config 白名单。
    文档给的就是这个**固定路径与文件名**，不需要在 module.json5 里写引用
    （仓库里既有的 HomeAgent 工程同样是这么放的）。
  · 新增判据 test/harmony-apibase.test.mjs（13 条）并接进 run-all.mjs 的 SUITE：
    值判据**直接跑** model/ApiBase.ts；.ets 那几条是**静态**接线判据（本机无设备）。

验证（都真跑过）
  · cd client/harmony && devecocli build clean && devecocli build
    → BUILD SUCCESSFUL in 7 s 186 ms；entry/build/default/outputs/default/entry-default-signed.hap
    存在（1214592 B，15:14）。
  · 解包 HAP：resources/base/profile/network_config.json 在包里、JSON 可解析、
    cleartextTrafficPermitted=true 且白名单含 192.168.2.60/10.0.2.2/localhost；
    bundleName 仍是 com.jianf.agentmail，module.json 没有多余的 metadata/securityConfiguration。
  · devecocli check lint → 0 error；我改过的文件**零发现**（总工性从 8 降到 7，
    顺带修掉 LoginPage 一条既有的 await-thenable）。
  · node --experimental-strip-types --no-warnings --test test/harmony-apibase.test.mjs
    → ℹ tests 13 / pass 13 / fail 0。
  · 变异验证 11/11 全红且**红在对应那条**（在 /tmp 的独立 worktree 里做的，不碰共享树）：
    归一化不补后缀、去斜杠咬掉协议、404 用通用文案、401 拿通用文案顶掉服务端原因、
    网络码不再分类、默认地址退回明文内网、setBase 直接赋值、登录页去掉守卫、
    内网白名单关掉明文、出现第二处自己拼 /api/v1、守卫变成空壳。
    （M8 第一次是**假绿**——只判了方法声明、没判调用点；改成切出 doLogin 方法体后再判才红。）

未验到（别把"编译过了"读成"连通了"）
  · **没有**在真机/模拟器上点过一次登录：本机当前无设备在线，所以"真的连上了服务端"
    这件事本轮**未被验证**；已验证的只是"地址会被补成带 /api/v1 的形态""构建产物正确"。
  · network_config.json 的**实际效果**未验：按官方文档明文默认就允许，这份文件是显式固化，
    没有做"关掉它再对比"的实验（也无法在无设备时做）。
  · DNS/超时/证书这几条分类的文案是按 SDK 错误码写的，**没有构造真人故障去实测**
    （即没有真的把 DNS 打坏、把证书换成自签来看提示）。
  · 登录页那条"未 /api/v1 会 404"的因果链是从服务端路由 + 客户端拼接方式推出的，
    没有用 curl 对 `https://mail.jianfgit.xyz/auth/login` 实打一次取证。
  · test/run-all.mjs 在本机（node v24.14.1）**本来就是红的**：它只认 `# pass N`，
    而 node 24 打的是 `ℹ pass N` ⇒ 25 个文件里 21 个被记成"没自报条数"。
    这是既有环境漂移（已在 HEAD 的 worktree 里复现同样的红），**本次没有动它**，
    所以新判据虽然已登记进 SUITE，要等 runner 的 marker 解析修好才会被套件真正计数。
 2026-09-15 15:15:17 +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