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

41 Commits

Author SHA1 Message Date
JianFeeeee
6cf431ee11 跨端: AGC 客户端配置不入库（gitignore + rm --cached + example）+ 一条判据代替"靠记得" 
pi 2026-09-15 的裁定：**gitignore + `git rm --cached` + example，不轮换**。
我照办了，并且把**决定性事实**更正过来 —— 我上一封说"已经进了公开历史"，**那句是错的**。

## 一、暴露窗口：我原先的假设**方向反了**

我上一封写的是"它**已经进过**公开仓历史，gitignore 撤不回，要认真考虑轮换"。
**实测不成立**（pi 查的，我逐条复核）：

```
$ git cat-file -e origin/main:…/rawfile/agconnect-services.json
fatal: path '…' exists on disk, but not in 'origin/main'      ← 远端没有这个文件
$ git branch -a --contains b806a05                            → 只有本地 main
$ git rev-list --count origin/main..HEAD                      → 119（本地领先，落后 0）
```

**整段鸿蒙工作一次都没推上去。** 所以窗口是**"直到下一次 push"**，不是"已经泄露"。
这把修法从**止血**变成**赶在 push 之前做完就行** —— 顺序因此是判据的一部分：
**先入库 ignore + `rm --cached`，再 push**。哪次先推了，就立刻变成"必须轮换"。

**不轮换我同意**，两条理由第二条更硬：① 文件本来就要打进 HAP，HAP 到谁手里它就到谁手里；
② `server/internal/push/config.go:51-55` 的 `AppSecret` 走 `AppSecretFile`（`resolveSecret`，
`hms.go:95` 读它，例 `/etc/agentmail/hms.secret`），**能替你发推送的凭证不在这个文件里**
⇒ AGC 客户端配置泄露**升级不成"能发推送"**。理由已写进提交信息，免得将来有人"按惯例轮换一次"
（那会白白换掉两个客户端版本的一致性判据）。

## 二、`git rm --cached`：本地那份**必须留着**

它**必须在本地存在才能构建**（`hvigorw` 打包时要读）。所以：

```
git rm --cached <文件>     ← 只动索引，磁盘上那份不动
```

撤完实测：`ls` 仍在（2656 B）、`git check-ignore -v` 命中 `client/harmony/.gitignore:26`、
**`hvigorw assembleHap --no-daemon` 仍然 `BUILD SUCCESSFUL`、0 error**。
（这条我特意重编了一次 —— "撤出索引"与"构建还能用"是两件事，不能靠推理。）

## 三、★ 判据才是机制（pi 说的这条比 gitignore 重要，我同意）

`gitignore` 单独挡不住：这个文件**必须在本地存在**，任何人一次 `git add -A` 就把它加回来了，
而**那次 add 不会有任何东西变红**。所以加了
`commit-hygiene.test.mjs` 的「★ 版本库里不许跟踪 AGC 配置真身」：

- 扫**所有 tracked 文件**（不只 rawfile），找"AGC 配置的形状" —— 同时出现
  `"client_secret": "[!` / `"code1": "<32+ 位十六进制>"` / `"api_key": "[!`；命中即红并点名；
- 按**内容**判，不按文件名豁免（`example` 是**故意**带这些键名的 —— 结构留、值全打掉，
  所以它靠"值都是 `<!…>`"自然通过，而不是靠一个文件名白名单）；
- 另一半：**`agconnect-services.example.json` 必须存在** —— 否则新人不知道这文件要长什么样，
  只能问人或猜，而**键名猜错会报一个和"配置缺失"毫无关系的构建错**。

**变异验证**（不是只跑绿）：`git add -f` 把真身加回来 ⇒ **判据红并点名**；
`git rm --cached` 还原 ⇒ **绿**。

example 我做了泄漏核对：真文件里所有 ≥12 字符的值逐个比对，**只剩 3 处 `package_name`**
（`com.jianf.agentmail`，它本来就写在 `AppConfig` 里、必须是这个值，打掉了反而误导）。
其余保留原值的是 **AGC 各区域网关域名**（`connect-drcn.dbankcloud.cn` 之类）——
那是华为的公共基础设施域名、不是本项目凭证，打掉只会让模板不能用。

## 四、`blurStyleFor`：删除后生产代码里 5 处注释在说一个**不存在的函数**

函数已按 pi 的裁定删除（`9a10ab2`，并发会话落的）。但删除后 `Wallpaper.ts`（4 处）与
`MainPage.ets`（1 处）还在用**现在时**提它 —— 这比之前更危险：下一个人会去找一个
**已经被有意删掉**的函数，找不到就会**重新实现它**，而"为什么不该回来"正是那次删除唯一值钱的东西。
全部改成过去时 + 已删除，并在 `Appearance.ts` 原处留碑文。
`:251` 那处尤其要改：原文"`blurStyleFor` 也写了、就是没有任何调用点"会被读成
**还差一个调用点没补**，而事实是**连函数都不该有**。

## 五、`debt-visibility` 那条红（pi 数出我漏的那条）

`harmony-deviceprobe.test.mjs`（2 处）**按次数登记、不整文件放行** ——
整文件放行的话，将来在这个文件里写一句真实的「这里没判」就**不会红**。
那 2 处也不是"这块没验"，而是对**词表本身**的断言。
另在 `docs/DEBTS.json` 补一笔 `deviceprobe-fixture-timing`（到期前提：两份 fixture
从"人工存文件"变成"当场采集"）。

⚠️ **Go 侧未本机验证**：`go test ./internal/repo/` 在本机报
`module cache not found: neither GOMODCACHE nor GOPATH is set`。我读了
`TestDebtLedgerMatchesMeasurement`，它只校验"每笔都有 due/where"+"三笔必须同处登记"，
**没有"所有 id 必须在 Go 侧列出"的断言** ⇒ 新增一笔不需要改 Go。
但这是**读代码得出的结论，不是跑出来的**，如实标未验。

## 六、我自己记错的两个数（pi 更正）

- **`STATIC_ONLY` 是 7 不是 8** —— 我上封写 8，`RESULT static=7` 与闸门打的 7 个文件
  都是 7。我记串了。
- `PROBE_DEVICE=none` 下**是 7 条红**，我只列了 6 条，漏了 `debt-visibility`（本笔已修）。

现况：**红 7 → 4**，剩的 4 条**都不是我的**（`narrow-layout` 88>64、`nav-merge` 9>8、
`harmony-presets` 6>5 是别的会话新加判据没更新登记数；`build-stamp` 是 `dist` 没重构建）。
 2026-09-15 12:25:25 +08:00
JianFeeeee
77aa42623a 跨端: debt-visibility 补登记（新判据文件不会自动跑守卫）+ blurStyleFor 删除后的注释真相 
## 一、`debt-visibility` 那条红：**新文件不会自动跑一遍守卫**

```
这些文件里有"边界声明"，但一次都没登记：
  harmony-deviceprobe.test.mjs（2 处）      ← e917b87/4880c31 新加的判据文件
```

**这是同一个洞在新文件上的复发**：上一轮我刚修完 `harmony-admin` / `harmony-imageprep`，
下一个**新建的**判据文件又踩了同一个坑。pi 之所以看见，只是因为他跑了整个套件 ——
**缺的不是"记得登记"，是"新建判据文件"这个动作没有守卫**。这条形状与"写了判据忘了接线"同族，
只是这次忘的是**登记边界**。

处理：**按次数登记（2），不整文件放行** —— 整文件放行的话，将来在这个文件里写一句
真实的「这里没判 / 已知缺口」就**不会红**。那 2 处本身也不是"这块没验"，
而是对**词表本身**的断言（`unverifiedReason(...)` 必须含「未验」）。

同时在 `docs/DEBTS.json` 补一笔 `deviceprobe-fixture-timing`（`where` 指向该文件）——
`debt-visibility` 的第二条要求"声明必须有对应的一笔"，两处各写各的会让审计只找到一处。
这笔的**到期前提是"两份 fixture 变成当场采集而不是人工存文件"**。

⚠️ **Go 侧未能本机验证**：`go test ./internal/repo/` 在本机报
`module cache not found: neither GOMODCACHE nor GOPATH is set`。我读了
`TestDebtLedgerMatchesMeasurement`：它只校验"每笔都有 due/where"+"三笔必须同处登记"，
**没有"所有 id 必须在 Go 侧也列出"的断言**，所以新增一笔不需要改 Go。
但这是**读代码得出的结论，不是跑出来的** —— 如实标成未验。

## 二、`blurStyleFor` 删除后：生产代码里 5 处注释在说一个**不存在的函数**

函数已按 pi 的裁定删除（别的会话的 `9a10ab2` 落的）。但删除后
`Wallpaper.ts`（4 处）与 `MainPage.ets`（1 处）还在用现在时提它：

```
Wallpaper.ts:242  "由 `model/Appearance.ts` 的 `blurStyleFor` 映射成系统材质档"
Wallpaper.ts:248  "页面拿它去问 `blurStyleFor`"
Wallpaper.ts:251  "`blurStyleFor` 也写了、就是没有任何调用点"
Wallpaper.ts:311  "`blurStyleFor` 里面也有一次 clamp，那是它自己的防线"
MainPage.ets:1711 "（`blurStyleFor` 那张表服务的是**材质档**…）"
```

**这正是本会话反复在消的"注释描述一份不存在的代码"**，而它现在比之前更危险：
下一个人读注释会去找一个**已经被有意删掉**的函数，找不到就会**重新实现它** ——
而"它为什么不该回来"恰恰是那次删除唯一值钱的东西。

已全部改成**过去时 + 它已删除**，并在 `Appearance.ts` 原处留了碑文（函数没了，理由不能没）。
`:251` 那处尤其要改：原文说"`blurStyleFor` 也写了、就是没有任何调用点"——
函数已不存在，这句会让读者以为**还差一个调用点没补**，而事实是**连函数都不该有**。

## 三、这条碑文判据我做了变异验证

`harmony-appearance.test.mjs` 里那条「碑文不许回来」的判据**确实在校验**（不是摆着好看）：
把 `Wallpaper.ts` 那段碑文抹掉 ⇒ **红**；还原 ⇒ **绿**。
顺带核了它的**指向**：碑文现在的主要落点是 `Appearance.ts`（函数原来所在处），
而判据的正则锚的是 `Wallpaper.ts` —— 两处都有内容才过，我保留了 `Wallpaper.ts` 里的引用
（它说明"这里的 px 不是材质档"），所以判据成立。

## 四、未做

- 到期闸门那 **7 条**（pi 更正过我：`STATIC_ONLY` 是 7 不是 8，我上封记串了）**仍然没动**。
- `PROBE_DEVICE=none` 下**剩 5 条红**，都是**别的会话**新加判据但没更新登记数
  （`narrow-layout` 88>64、`nav-merge` 9>8、`harmony-presets` 6>5、`commit-hygiene` 3>2）
  加 `build-stamp`（`dist` 没重构建，与本次改动无因果）。**我没有替他们改**。
 2026-09-15 12:22:23 +08:00
JianFeeeee
4880c31110 跨端: fix(设备闸): app state 交叉验证（矛盾⇒拿不准）+ 正例换成**真机实采**样本 
pi 邮件 `6f902e1e` 指出两件，都对：

1. **我那条正例是自相矛盾的**：我用脚本把 `state #FOREGROUND` 对调，却漏了同一块的 `app state #X`
   ⇒ 造出 `state FG` + `app state BG` 这种**真机上不会出现**的 dump。于是"闸能放行"这条正例
   建在**非法输入**上 —— 它绿，但它没证明任何真机会发生的事。
   现在：正例改用 12:08 **真机实采**的 `fixtures/aa-dump-l-ours-foreground.txt`（两个 mission 都在、
   `state`/`app state` 一致、FG 是我们）；
2. 顺手把"矛盾怎么办"钉成规则：同一块里 `state` 与 `app state` 打架 ⇒ **`unverified`**，
   **不许"挑一个信"**（那是把互相打脸的证据当成证据）。`app state` 缺失时不因此判未验
   （否则老格式 dump 会一律未验 —— 那是"更安静的失效"）。

判据 8 条全绿；登记同步为 8。
 2026-09-15 12:10:49 +08:00
JianFeeeee
b413fbb43e 跨端: fix(设备闸): 按真机形状改写解析（前台 = state #FOREGROUND 那个 mission 的 bundle），判据改喂真机样本 
第一版是**猜的**格式（`bundleName: com.x`），真机上根本没有这种写法；退一步"取第一个 bundle name"
又会取到别人的（真机多 mission，`#31 com.example.homeagent` 排在我们 `#32` 前）⇒ 假绿（pi 独立复现）。

真机形状（样本 `test/fixtures/aa-dump-l-real.txt`，实采）：每块 `Mission ID #N … ` +
`bundle name [com.x]` + `state #FOREGROUND/#BACKGROUND`；**前台只由 `state #FOREGROUND` 决定**。

- `parseMissions` / `foregroundBundle`：按块解析，取不到返回空（不猜、不兜底）；
- `foregroundVerdict` 三态不变：`ours` / `other` / `unverified`；
- 有 mission 但**全无 FOREGROUND** ⇒ `unverified`（不是"没我们所以算别人"）；
- 空 dump / 截断 ⇒ `unverified`，状态词写明"**缺证据 ≠ 没有那个现象**"。

判据 5 条（喂真样本 + 对调状态 + 空/截断/无前台 + 撞名撞文案反证）全绿。
真样本本身含"对方在前台"那一刻 —— 争用在一分钟内真实发生过，所以这不是构造出来的场景。
 2026-09-15 12:05:17 +08:00
JianFeeeee
c12744e8c3 跨端: 导航条材质选 (a) 固定档（推翻我的 (b)）—— 并修掉"注释说 (a)、代码是 (b)"的自相矛盾 
pi 2026-09-15 裁定：**推翻 (b)，选 (a)**。我原先给 (b) 的理由不成立，他逐条驳了：

1. **WebUI 的导航条根本不读 `--bg-blur`**：`index.css:1114` 的 `.narrow-nav` 是硬编码
   `backdrop-filter: blur(18px) saturate(1.5)`。我引这条支持"两个量不同"，
   而同一条也说明**它不由用户偏好驱动**。
2. **WebUI 那个滑杆的语义是"背景"**：`BackgroundPicker.tsx:183` —— `label="模糊"`、
   `hint="虚化细节，避免背景与正文抢注意力"`、`min=0 max=24`，只作用在
   `.app-backdrop{filter:blur(var(--bg-blur))}` 上。
3. WebUI 自己留了**分开的**令牌 `--bg-blur-panel`（`index.css:267`，注释写明
   "与壁纸自身的 `--bg-blur` 分开"）—— 它的词汇表本身就拒绝把两者等同。
4. **★ 我给 (b) 的理由不成立**：我写"(a) 会让那个滑杆在导航条上变成死控件"，
   可那个滑杆**已经**被壁纸消费了（`MainPage.ets` 壁纸层的 `.blur(bgPlan.blurPx)`）——
   它从来**不是**导航条的控件。(a) 之下它照样是活的。
5. §7.12 的「材质（玻璃）」行原本写的就是固定档 ⇒ (a) 是**回到**已登记契约。

产品向还有一条：**导航条是 chrome，材质应当稳定**，不该因为用户换张壁纸而变厚变薄。

## 最该记的是：我的注释和代码**互相矛盾**

`MainPage.ets` 里那段注释论证的是 (a)、并明确写着"跟随是错的，pi 抓出来了"，
而它下面那一行代码是 (b)。**下一个读者会照注释把代码改回去，并引我那句话当权威。**
这是这一路反复在消的形状（说的与做的不一致、而判据看不见），这次落在**注释**上 ——
而注释正是"理由要写清"那条纪律的证据源。已整段重写为真实的 (a) 版本，并把
"(a) 会让滑杆变死控件"这个**错的理由**连同它为什么错一起留在注释里。

## 做掉的东西

- `MainPage.ets`：导航条回到 `.backgroundBlurStyle(Theme.navMaterial)`；
  删掉 `NAV_MATERIAL_OF` 表与 `navMaterialFor` 的 import（(a) 之下都是孤儿）。
- `model/Appearance.ts`：删 `navMaterialFor`（它存在的唯一理由就是方案 (b)）。
  `blurStyleFor` 现在**没有任何调用点** —— 如实登记在它的文档注释里
  （"有测试"不等于"有人用"，上一轮我刚因同形状被抓过），不假装它活着。
- **五处"整条字面表达式"断言改成语义断言**（pi §四）：`cross-client-theme`、`harmony-appearance`、
  `harmony-nav`（3 处）此前都在钉
  `/\.backgroundBlurStyle\(NAV_MATERIAL_OF\[navMaterialFor\(…\)\] \?\? Theme\.navMaterial\)/`
  —— 字面换字面，正是 `CRITERIA.md` 不许的"对源码形状的匹配"。
  现在判：① 那一处的材质**来自 `Theme.navMaterial` 这个系统令牌**；
  ② **不许跟随** `bg_blur`（NavBar 真代码里不许出现 `blurPx`/`blurStyleFor`）；
  ③ 令牌是 `BlurStyle` 枚举值、不是 `NONE`、且**成员名真实存在于 SDK 枚举**。
- "可达性"那条判据**随契约作废**（它守的是方案 (b)）：换成判 (a) 的契约。
  **判据随契约走，不随实现走。**
- `harmony-appearance`：原先判"页面里那张表的键必须是 SDK 成员"。表删了，
  改成**枚举 `blurStyleFor` 的整个值域**（0..40 + 界外 + NaN），逐个核 SDK 成员 ——
  比原来只核表里那三行**更严**。

## 判据自己先错了一次，记下来

新判据第一版**没剥注释**就断言"NavBar 里不许出现 `blurPx`"，当场红了 ——
而红的原因不是代码错，是 `NavBar` 的**文档注释**里正好写着
"我一度把档位接过用户偏好（`navMaterialFor(this.bgPlan.blurPx)`）"这句历史说明。
**注释说明禁令 ≠ 违反禁令**；不剥注释，这条判据就会变成"逼人删掉解释"，
恰好与本仓库"理由要写清"的纪律相反。改成 `stripComments(bar)` 后再判，并加了一条
"注释里确实留着那处说明"的自检前提。

## 变异体：45 个全部被抓（含 3 个新判据的专属变异）

方案 (b) 落地时配的 13 个变异体**整体作废**（它们锚的代码被删了），标注 `retired`
并写清理由 —— 不是"没跑成"。另有 5 个锚点漂移（我在注释里逐字引用了被锚的那句代码，
污染了通用正则）的**重锚**到真代码；注释里那句逐字引用也一并去掉了
（**注释里逐字抄代码**正是让"按字面锚定"的变异体反复失效的根因）。
新增 3 个针对 (a) 契约的变异体（绕过令牌 / 又跟随 `bg_blur` / 令牌变 `NONE`），全部被抓。

## 未验

- **真机观感仍未验**：三档材质在真机上能不能看出差别、滑杆手感、管理页布局，
  只有真机能答。本机模拟器已起（`hdc list targets` 有目标），但
  `run-all.mjs` 的**设备闸已经到期**（8 个静态判据的前提成立）⇒ 套件现在会挡在
  那道闸上、不打 `RESULT`。**这不是本笔引入的**（前提是环境变了），已单独报给 pi。
- Go 侧 `debt_registry_test.go` 仍未在本机跑（无 Go 模块缓存）；pi 已在别处跑过，绿。
 2026-09-15 11:58:19 +08:00
JianFeeeee
e917b8782a 跨端: feat(设备闸): DeviceProbe.ts —— "读到别人的界面"是假绿来源，读之前先判"是谁的"，拿不到就记未验 
pi 邮件 `971c58fa` §4 / `bf583b0f` §2。别的 agent 在同模拟器上 `aa start` 会抢前台，
之后读到的控件树是**它的窗口** ⇒ 断言可能通过也可能红，**两者都不是在讲我们的界面**（前者=假绿）。

- `foregroundVerdict` 判决只有三种：`ours` / `other` / `unverified`；**只按 bundle 判，不许看标题/文案/控件名**
  （别人的合法 dump 里完全可能有同名控件与同文案，"邮件"这种通用词尤其容易撞）；
- `parseForeground` 取不到就 **undefined**（空 dump / 截断 / 格式变了都不猜）；
- `mayAssertOn === false` ⇒ 调用侧必须记 **`未验`**（欠账继续开着），**不许**记通过、**不许**静默跳过
  —— 跳过会在下一轮被读成"验过了"；
- `unverifiedReason` 统一状态词，并写明"**缺证据 ≠ 没有那个现象**"。

判据喂 4 类样本（pi 指定的最易漏输入）：① 我们的 dump ② **别人的合法 dump（含同名控件 + 同文案）**
③ 截断/畸形 ④ **空 dump**（窗口没起来时最常见，最容易被当成"坏现象不存在"）。
另加一条只按 bundle 判的反证（把标题改成"像我们"也不许变 ours）。

**顺手抓到自己一个坑**：`firstMatch` 第一版的否定类既接受非 ASCII 也接受**换行**
⇒ 对 `windowTitle: 邮件\n abilityName: …` 会吞掉中文标题并**捕获下一行的键名**，
"标题"读到 `abilityName`（看起来有值、其实指错地方）。判据当场抓到 ⇒ 改成按行取、值允许中文、空值不回退。
 2026-09-15 11:54:25 +08:00
JianFeeeee
ab31690348 跨端: fix(推送客户端): 登记标记绑定账号（token 换账号是"转移"不是并存 ⇒ 别把登记状态缓存成长期结论） 
pi 邮件 `2518e1a3` 的服务端事实：注销只认注册者本人、token 字符串不是凭证，
**同一个 token 换账号登录是"转移"而不是并存** ⇒ "我登记过没有"的答案**随账号而变**。

原来的 `shouldReportToken(lastReported, current)` 只按 token 存标记 ⇒ 换账号后
（同一 token）会**错误地跳过上报**，而那个账号其实还没登记过这个 token。
改成 `reportMarker(accountKey, token) = accountKey|token` + `shouldReportToken(lastMarker, accountKey, token)`：
**账号变了标记必然不同** —— 于是"换账号必然重新上报"是**性质**，不靠人记得 reset。

判据 13 条全绿（新增"换账号后必然重新上报 / 切回来也要重新上报"，并断言两次 marker 不相等）。
 2026-09-15 11:51:39 +08:00
JianFeeeee
30886271ea 跨端: docs(引用锚): 把日期锚换成邮件 ID（pi 邮件 b1e23663：日期也是锚，写错一天下一个人找不到那封信） 
pi 指出的锚错：`PushContract.ts` 里那段线上形状是 pi **09-15** 发的（邮件 `004983bb`），我写成了 09-14。
照他的推理（"引用别人的工作状态时，哈希和'谁在读'一样会漂"）往下再走一步：
**日期本身就是会漂的锚 —— 邮件 ID 不会。** 所以不是把 09-14 改成 09-15 就完事，
而是把这一族引用改成**可检索的标识**：

- `PushContract.ts`：契约来源 → `1f9ff3b4`；线上形状 → `004983bb`；
- `harmony-push.test.mjs`：同上两处；
- `Calendar.ts`：表头共用分叉、"今天"的调用侧 → `f60521de`；
- `ALIGN-REFS.json`：参照物版本登记 → `6e14b410`；圆角策略追认 → `90372ca1`；AGC 包名实测 → `1f9ff3b4`。

共 10 处。判据不依赖这些注释文本，改完 `harmony-push` 12/12、`harmony-calendar` 10/10、`align-refs` 3/3 仍绿；
`ALIGN-REFS.json` 仍是合法 JSON。

**没改的 4 处**（`NavItems.ts` 1 处、`Wallpaper.ts` 3 处）：它们写于 09-14 那批往来，日期本身没被指出错，
而那几封的邮件 ID 我这边没有（跨过一次上下文压缩）——**宁可留着有争议的日期，也不编一个 ID**。
 2026-09-15 11:51:39 +08:00
JianFeeeee
ed0ad2508e 跨端: feat(推送客户端): 按线上形状补契约层（DELETE 也带 body / 未知字段 400 / provider 无白名单 / 错误是 {"error"}） 
pi 2026-09-14 给的线上形状（从 handler/push.go 读的，不是猜的）逐条落成可判的：

- **请求体只放已知键**：`PUSH_BODY_KEYS` 登记四个键，**未知字段服务端直接 400**（不是静默忽略）
  ⇒ 拼错会立刻可见；可选字段为空就不放（空串虽合法，但不放更不容易踩校验）。
- **provider 只做形状校验、没有白名单**（`^[a-z0-9_-]{1,32}$`）：判据断言 `apns`/`fcm` 也合法 ——
  客户端**不许**硬编码"只有 hms 合法"去先拦一道（服务端没实现的通道不该变成客户端的 400）。
  这正是"校验的范围必须等于它真正知道的事"的又一落点。
- **token**：空非法、512 上限；形状不合法 ⇒ `buildTokenBody` 返回 undefined，调用侧**静默跳过**，
  不去打一次注定 400 的请求。
- **错误体是 `{"error"}` 不是 `{"message"}`**：判据专门断言 `{"message":"x"}` 解析出 undefined
  （用错键会把"没有消息"当有消息）。
- **注销：`deleted:false`（本来没登记）不是失败** ⇒ 它**不改变分类**，所以**不再是入参**
  （一个不影响结果的入参只会让人误以为它影响结果），判据断 `classifyUnregister.length === 2` 钉住这点。
- **`ApiClient.del` 补可选 JSON body**：DELETE 端点是 JSON body 形状（不是 query、不是 path 参数），
  原来只有 `path` ⇒ 注销会无效。不传 body 时行为与旧版完全一致（向后兼容）。
EOF
 2026-09-15 11:43:22 +08:00
JianFeeeee
8fed8401de 跨端: feat(推送客户端): 契约层 model/PushContract.ts + 6 条设备无关判据（静默失败/enabled:false 正常态/按 provider+tail 比/按 mail_id 去重） 
pi 2026-09-14 推送契约的客户端半边。四条不变量里**三条是纯逻辑**，所以先落这三条，
平台调用（Push Kit 取 token、通知权限）留在下一步的 `PushService.ets` 里。

- `shouldReportToken`：取不到 token 不上报；与上次相同不重复上报（否则每次启动打一次接口）；
- `tokenTail` / `isRegistered`：GET **只回尾 6 位** ⇒ "登记过没有"必须按 `provider + tail` 比。
  比全文是**看起来更严、其实永远为假**的写法（全文永不等于尾 6 位 ⇒ 每次启动重复上报），
  所以有判据钉它，并在注释里写明"同尾 6 位即视为同一条 —— 这是服务端给的信息量的上界，不是我们的选择"；
- `classifyRegister`：`ok-enabled` / `ok-disabled` / `silent-skip` —— **三种里没有一种是"提示失败"**
  （`enabled:false` 是自部署常态 ⇒ 不重试、不提示）；
- `parseNotificationData`：不满足约定形状就返回 undefined（坏 JSON 不抛、缺 mail_id/动作不符都忽略）——
  推送是可选通道，收到不认识的东西不许有任何副作用；
- `NotificationLedger`：服务端**无幂等键**（至多一次、无重试/去重表）⇒ 重复保护落客户端；台账**有界**。

另有一条判据禁止契约层引入 `@ohos`/`@kit`（否则这些判据会退化成必须上设备）。
它第一次跑**咬到了解释这条规则的那行注释** ⇒ 改扫 `code()`（去注释），与前面扫描口径那次同族。

`npm test`（install 相位）全绿；余额 `debts=13`。
 2026-09-15 11:40:54 +08:00
JianFeeeee
351be9dc5e build(harmony): 写入签名配置（devecocli signature generate 生成，指纹已登进 AGC） 
用户把签名这块交给我（「你不是有devecocli嘛」）。做法：
- 共享浏览器里用已有登录态完成 DevEco CLI 授权（无需短信）→ devecocli auth status 通过
- client/harmony 下 `devecocli signature generate --product default`：
  生成 p12/csr/cer/p7b 到 ~/.ohos/config/，并把 signingConfigs 写进本文件
- 叶子证书 = CN=靳睿(1681189977251159745),Development，SHA256
  FD:89:AC:53:9C:C6:F9:37:C0:B4:E1:BC:82:91:B1:BA:11:15:46:33:66:88:F9:74:E0:A5:52:DA:46:FC:9D:09
  已登进 AGC 该应用的「SHA256证书/公钥指纹」（推送送达的前提）
- profile 绑 com.jianf.agentmail，debug 型，登记设备 3 台（1 模拟器 + 2 真机）

验签用官方工具（不用猜结构）：hap-sign-tool verify-app → Verify success，
证书链里正是上面那张叶子证书。

注：signingConfigs 里的路径是绝对路径（DevEco 默认行为），换机器要重新生成。
 2026-09-15 11:38:34 +08:00
JianFeeeee
7b16fec61c fix(harmony): AdminUsersPage 的 Chip 参数放宽到 ResourceColor —— 三个编译期错误（不是警告） 
`Chip(text: string, bg: string, fg: string)` 收不下 `Theme.surfaceMuted` /
`Theme.textSubtle`（它们是 `$r('sys.color.*')` ⇒ `Resource`）。于是
`user.role === 'admin' ? Theme.chipNeutralBg : Theme.surfaceMuted` 这类三目
在三处报：

  Argument of type 'string | Resource' is not assignable to parameter of type 'string'
  Argument of type 'Resource' is not assignable to parameter of type 'string'
  （AdminUsersPage.ets:353 / 357 / 368）

`fontColor` / `backgroundColor` 本来就收 `ResourceColor`，所以放宽参数类型即可 ——
不必把系统语义色抄成字符串（那正是 Theme.ets 文件头要避免的事）。

归属与复核（2026-09-15）：
- 这三条在 `474cada` / `b806a05` / `7f4fa26` 上**一直红着**，是**提交树里**的错误，
  不是任何人的在飞改动。复核方式：`git show 7f4fa26:…/AdminUsersPage.ets | grep -n 'Chip(text'`
  ⇒ `bg: string`；该文件自 `474cada` 起未被改过（`git log -- <file>`）。
- 同一批的另两条（MainPage.ets 的 `arkts-no-misplaced-imports`）由**别人**在写，
  我没有 stage / 没有改那份文件。
- 实测：修前 `hvigorw assembleHap` = BUILD FAILED（6 个 arkts 错误，
  含 MainPage 两条 misplaced-imports）；MainPage 那份修好后本笔使整个构建
  BUILD SUCCESSFUL（本轮实测）。
 2026-09-15 11:33:27 +08:00
JianFeeeee
b806a05bfa 跨端: harmony 管理页（用户管理）+ P4c 壁纸上传入口 —— 「功能做全再交付」的两块 
pi 的交付清单里缺的两块（`docs/GUI-PLAN-HARMONY.md` 原先把管理后台划在首版之外，
用户明确要求「功能做全再给我」之后收进来）。

标 `跨端:` 是因为判据落在 `client/electron/test/`（鸿蒙的判据目录一向量在那里），
代码本体全在 `client/harmony/`。

## 管理页（用户管理）

- `pages/AdminUsersPage.ets`：新建 / 编辑（显示名·角色·白名单）/ 启停 / 重置密码。
  排布照 `AdminUsersPage.tsx`，包括「受限」徽标口径（普通用户且白名单非空才显示）、
  最后登录缺席与空串都显示「从未登录」、管理员对白名单两项忽略。
- 入口在设置页底部，**仅管理员可见**（`role === 'admin'` 严格相等，与 `App.tsx` 同口径）。
  读不到身份时**不**显示也不报错（乐观放行会让每个普通用户看到点进去 403 的入口）。
- `api/AdminApi.ets` + `model/AdminUsers.ts`（纯逻辑，零 import ⇒ 判据能真跑）。
- 启停**只发 status 一个字段** —— 服务端是部分更新，多发字段会把显示名与白名单一起改掉。
- `model/Models.ets` 补管理端 DTO；`main_pages.json` 注册路由。

## P4c 壁纸上传

- `model/ImagePrep.ts`：阈值与两档策略（2560/0.85 → 1280/0.78，入口 20MB，压后上限 3.5MiB）。
  **一处有意不对齐 WebUI** 并写明理由：WebUI 卡 data-URL 长度（含 base64 膨胀），
  鸿蒙内存直传 ArrayBuffer，卡的是字节数。
- `common/BackgroundPicker.ets`：不设 / 预设 / 自定义图片 + 浓度与模糊滑杆。
  上传链：picker → 判可不可以 → 逐档按 desiredSize 解码压缩 → 上传 → **请页面以服务端为准重新同步**。
  失败**必带原因**（服务端 415/413 文案原样透出）。用户取消选图**不算失败**。
- `ApiClient.uploadBytes`：MultiFormData.data 收 ArrayBuffer（核了 SDK，since 11；本工程 23）
  ⇒ 内存直传，不需要 base64 也不需要临时文件。

## 两处真 bug（变异测试逼出来的，不是"新写坏的"）

1. **压缩循环的第二档此前是死代码**：循环里的 break 与循环外那句 shouldRetryWithActual
   互相抵消 —— 把循环里那处改成 `if (true)`（永远只压一档）整套判据照样全绿。
   收成一处判定（overLimit），循环外只读结论，并加结构性判据（该函数在这条链上只许调用一次）。
2. **壁纸的模糊档一直是「只写不读」**（计划文档 §7.12 登记过）：滑杆能拖、值能存、
   blurStyleFor 也写了，就是**没有调用点**，壁纸一点没糊。
   本次补上的调用点分两层：壁纸层 `.blur(px)` = **图片内容模糊**
   （与 WebUI 的 `filter: blur(var(--bg-blur))` 同一个量、同一个数，所以不需要映射表）；
   而那张**材质档**映射表 `blurStyleFor` 也终于有了调用点（`navMaterialFor` 内部复用它）。
   `docs/HARMONY-ALIGN-PLAN.md` 的 §7.12 两行（材质 / 壁纸模糊度）已一并改准、不再互相矛盾。

## pi 复核后**改回来的**（这一笔里我自己犯的两处，都由 pi 抓出）

1. **导航条材质一度绑定到 `bg_blur`，`bg_blur=0` 时整个消失。**
   我把 `NavBar` 从固定档改成 `blurStyleFor(bgPlan.blurPx)`，而滑杆 `min: 0` 可达、
   `blurStyleFor(0) === 'NONE'` ⇒ 用户把壁纸调清晰时**导航条一点材质都没有**。
   而且它与本笔自己的论证**相反**：刚论证完"图片内容模糊"与"面板材质"是两个物理量，
   转头把面板材质接到壁纸模糊这个输入上。
   现在**分层**：`blurStyleFor` 是通用映射（**允许** NONE —— "0 px 不模糊"是它的正确语义）；
   `navMaterialFor` 是**导航条专用、有下限**的入口（0 px ⇒ 最薄档）。
   判据钉**可达性**（滑杆 0..40 每个整数 + 界外值都不许 NONE，且三档都要出现 ——
   否则"恒定最薄档"会让滑杆成为死控件）。
2. **`Theme.navMaterial` 被我弄成了死令牌**，而看着它的判据**照样绿**
   （那条只断言"声明存在且不是 NONE" —— 守的是声明，坏的是活的调用路径）。
   现在导航条真的用它；并把同文件里**只覆盖 `Theme.overlay` 一个令牌**的死令牌规则
   **铺到 Theme 的全部 35 个令牌**（量**外部引用数**：只被 Theme 内部方法读、
   而那个方法自己有外部调用点 ⇒ 不算死 —— `chipSpentBg` 是这种；`navMaterial` 当时
   唯一的消费者是一张可整体删掉的局部表，所以必须被抓）。

## pi 复核后**补上的**（这一笔漏掉的接线，都是我造成的）

- **`test/run-all.mjs` 的 SUITE 没接两个新判据文件** ⇒ HEAD 上 `npm test`
  **一条判据都不跑、直接 exit 1**（套件自检 2 就是为这件事写的）。已接入，
  并把两条登记进 `STATIC_ONLY`（`.ets` 要设备 ⇒ 静态欠账）。
- **`debt-visibility` 是我自伤**：那两个新文件里有 5 处"边界声明"但一次都没登记。
  我当时报"2 条失败是改动前就红" —— **只对一半**：这条在父提交上是**绿的**。
  我那次 `git stash push -u -- client/harmony` 的对照是**无效对照**
  （`-- client/harmony` 把 `client/electron/test/` 整个排除在外，新判据文件根本没被 stash），
  所以两次跑都红、看着像"既有"。已按 pi 的建议改用 `git worktree` 到父提交做对照。
  现在两处都登记进 `docs/DEBTS.json`（含 `static-criteria` 5→7，Go 侧同一份登记同步改）。

## 一并修正的旧判据（都是"太宽/太窄/钉错东西"，不是放宽标准）

- 「模糊归属」：原文「壁纸层不许有**任何**模糊调用」把**图片内容模糊**与**面板材质**
  混为一谈（WebUI 侧核实：`.app-backdrop` 的 filter 与它之上那层的 backdrop-filter
  是两个不同的量）⇒ 改成按两种模糊分别钉。
- 「bgBlur 只写不读，消费侧必须为 0」：值不再成立，**形状保留**（逐文件登记 + 计数 + 理由），
  标题与断言里的假话一并改掉。
- isDarkMode 那条 `/dark\s*\)/` 断的是**参数顺序**（加一个入参就误红）⇒ 改成"dark 在实参里"。
- 三条钉 `backgroundBlurStyle` **整条字面表达式**的断言 ⇒ 改成钉语义
  （"用系统材质 + 材质有下限"），不再匹配那一行的字符。

## 判据

新增 `harmony-admin.test.mjs`（22 条）、`harmony-imageprep.test.mjs`（29 条）；
`harmony-presets.test.mjs` 加 1 条（模糊档搬运与归一，含 `-0` 那个洞：
`Math.round(-0.4)` 是 `-0` 而 `-0 < 0` 为 false ⇒ 改成判 `!(r > 0)`）。

**`node test/run-all.mjs`：22 个判据文件全部跑起来**，红的只有 1 个：
`build-stamp`（`dist` 是 `a5fc86b` 上构建的，`gitRev` 对不上当前 HEAD）。
这条**不是我的代码造成的**（可证：`a5fc86b..HEAD` 之间，`srcHash` 覆盖的那批文件
——`client/electron/src` 等——**一个都没动过**，所以 `srcHash` 没变，差的是 `gitRev`），
但也**不是"改动前就红"**：任何推进 HEAD 的提交都会让它变红，正确修法是重构建。

## 未验（如实标注）

- **本机无设备/无模拟器 ⇒ 全部观感未验**：管理页排版与卡片观感、滑杆手感、
  模糊在真机上的实际档位观感、系统材质在自绘悬浮条上的实际效果。代码齐 ≠ 真机验过。
- 预设档**没有**上模糊（壁纸在预设档下是一叠自绘矩形，系统材质对它不生效）——
  这是我**主动收的范围**，不是漏，真机看一眼再决定要不要补。
- **Go 侧的 `debt_registry_test.go` 我没能跑**（沙箱里没有 Go 模块缓存，`go test` 起不来），
  只做了 `gofmt` 校验；那处改动是一行 `Count: 5 → 7`。
 2026-09-15 11:17:23 +08:00
JianFeeeee
474cadaf54 跨端: harmony 管理页（用户管理）+ P4c 壁纸上传入口 —— 「功能做全再交付」的两块 
pi 的交付清单里缺的两块（`docs/GUI-PLAN-HARMONY.md` 原先把管理后台划在首版之外，
用户明确要求「功能做全再给我」之后收进来）。

标 `跨端:` 是因为本次的判据落在 `client/electron/test/`（鸿蒙的判据目录一向量在那里），
代码本体全在 `client/harmony/`。

## 管理页（用户管理）

- `pages/AdminUsersPage.ets`：新建 / 编辑（显示名·角色·白名单）/ 启停 / 重置密码。
  排布照 `AdminUsersPage.tsx`，包括「受限」徽标的口径（普通用户且白名单非空才显示）、
  最后登录缺席与空串都显示「从未登录」、管理员对白名单两项忽略。
- 入口在设置页底部，**仅管理员可见**（`role === 'admin'` 严格相等，与 `App.tsx` 同口径）。
  读不到身份时**不**显示也不报错（乐观放行会让每个普通用户看到一个点进去 403 的入口）。
- `api/AdminApi.ets` + `model/AdminUsers.ts`（纯逻辑，零 import ⇒ 判据能真跑）。
- 启停**只发 status 一个字段** —— 服务端是部分更新，多发字段会把显示名与白名单一起改掉。
- `model/Models.ets` 补管理端 DTO；`main_pages.json` 注册路由。

## P4c 壁纸上传

- `model/ImagePrep.ts`：阈值与两档策略（2560/0.85 → 1280/0.78，入口 20MB，压后上限 3.5MiB）。
  **一处有意不对齐 WebUI** 并写明理由：WebUI 卡 data-URL 长度（含 base64 膨胀），
  鸿蒙内存直传 ArrayBuffer，卡的是字节数。
- `common/BackgroundPicker.ets`：不设 / 预设 / 自定义图片 + 浓度与模糊滑杆。
  上传链：picker → 判可不可以 → 逐档按 desiredSize 解码压缩 → 上传 → **请页面以服务端为准重新同步**。
  失败**必带原因**（服务端 415/413 文案原样透出）。
- `ApiClient.uploadBytes`：MultiFormData.data 收 ArrayBuffer（核了 SDK，since 11；本工程 23）
  ⇒ 内存直传，不需要 base64、也不需要临时文件。
- 用户取消选图**不算失败**，什么都不说。

## 顺带修掉的两处真问题（都是变异测试逼出来的）

1. **压缩循环的第二档此前是死代码**：循环里的 break 与循环外那句 shouldRetryWithActual
   互相抵消 —— 把循环里那处改成 `if (true)`（永远只压一档）整套判据照样全绿。
   收成一处判定（overLimit），循环外只读结论。
2. **壁纸的模糊档一直是「只写不读」**（计划文档 §7.12 登记过）：滑杆能拖、值能存、
   blurStyleFor 也写了，就是**没有调用点**，壁纸一点没糊。本次补上调用点
   （壁纸层 .blur(px) = 图片内容模糊；导航条材质由 blurStyleFor 映射）。
   同时按 §7.12 的原承诺更新了那一行。

## 一并修正的旧判据（都是"太宽/太窄"，不是放宽标准）

- 「模糊归属」：原文「壁纸层不许有**任何**模糊调用」把**图片内容模糊**与**面板材质**
  混为一谈（WebUI 侧核实：.app-backdrop 的 filter 与它之上那层的 backdrop-filter
  是两个不同的量）⇒ 改成按两种模糊分别钉。
- 「bgBlur 只写不读，消费侧必须为 0」：值不再成立，**形状保留**（逐文件登记 + 计数 + 理由），
  标题与断言里的假话一并改掉。
- isDarkMode 那条 `/dark\s*\)/` 断的是**参数顺序**（加一个入参就误红）⇒ 改成"dark 在实参里"。
- 导航材质三处断言原本钉 `Theme.navMaterial` 字面量 ⇒ 改成钉新的映射写法。

## 判据

新增 `harmony-admin.test.mjs`（22 条）、`harmony-imageprep.test.mjs`（29 条）；
`harmony-presets.test.mjs` 加 1 条（模糊档搬运与归一，含 -0 那个洞）。
全量 203 条：**201 通过**，2 条失败为**改动前就红**的既有项
（BUILD_INFO 比对、词表↔余额）—— 用 stash 对照验证过。

两个新判据文件上跑了 **48 个变异体，全部被抓**（含"接线"类：删掉「受限」徽标、
组件自己宣布成功、release 不 await、按原图尺寸解码…），
其中 2 个变异体**红不了**，因此又补了 5 条判据（纯逻辑接线、退档判定只有一处、
两档都超限必拒、解码尺寸用的是目标尺寸而非原图尺寸、模糊档搬运）。
（数字口径：按 runner 的真实条件"锚点恰好命中 1 次才算跑过"统计；
另有 4 条锚点不命中、根本没跑，不算在这 48 里。我第一次写的是"40"——
凭记忆累加的，错了，已更正。）

**未验**：本机无设备/无模拟器 ⇒ 全部观感未验（管理页排版、滑杆手感、模糊在真机上的
实际档位观感）。代码齐 ≠ 真机验过。
 2026-09-15 11:03:22 +08:00
pi
d3f6f3baf6 跨端: 鸿蒙日历写侧（新建/编辑/删除/暂停恢复）+ 表单不再是一面滚轮墙 
用户：「是的去吧」（批准上一封列出的下一步）。

- CalendarApi：createEvent / updateEvent / deleteEvent（POST /calendar/events、
  PUT/DELETE /calendar/events/{id}）；新建与编辑发**同一份** CalendarEventInput
  —— 服务端两个端点同形（CreateCalendarEvent 里那个 Status 字段的注释就写着这句），
  拆两份会在严格解码下 400
- CalendarPage：写侧表单（新建与编辑共用一份）、二次确认删除、暂停/恢复走 update
  （调度器只触发 active；没有暂停就只能删掉重加，而那会丢 event_id 与历史）
- 服务端 400 文案原样显示（收件地址无法解析：…）—— 建事件时就校验地址，
  吞成保存失败等于让人猜，而猜的代价是以为设好了、实际永远发不出去
- 空标题/空收件人在本地就挡住，不发注定 400 的请求
- 提交的是**时间戳**（isoTimestampOfLocal），不是日期键；编辑回填走 localDateOf
- ★ 表单形状：日期/时间选择器合起来 ~1400px，展开着放会把标题与收件人挤出屏幕 ——
  改成一行摘要 + 点开展开（默认收起）。这不是美观问题：展开态下保存在屏幕外，
  要跨过一整面滚轮才够得着
- 判据 +7（端点/载荷/前置校验/文案/二次确认/时间戳往返/变异自检），23 条全绿
- 真机实测（hvigorw + hdc + uitest 逐字段输入 + 逐键点击，每一步都回库核对）：
  建 → 库里 event_time 是 2026-09-28T01:00Z（= 本地 09:00 整，默认值正确）、
  暂停 → status=paused、删除第一下只变确认删除（库里还在）、第二下才真删（库里 0 条）
 2026-09-14 18:57:53 +08:00
pi
94ba4b9c58 跨端: 鸿蒙端功能同步第一步——日历（只读月视图）上架，入口进底部导航 
用户：「要给鸿蒙端做功能同步」。按 API 面盘点（WebUI 62 个 API 函数 vs 鸿蒙 38 个），
最大的用户面缺口是**日历**：纯逻辑（model/Calendar.ts）与判据早就在，一直没页面。

新增：
- api/CalendarApi.ets：GET /calendar/events?from=&to=（与 WebUI 同参；区间按**网格**取，
  不是月首月末 —— 首尾格子会显示邻月，只查当月会让那些格子永远空着）
- pages/CalendarPage.ets：月网格（翻月/回今天）、点某天看当天日程、事件点、今天/选中两态、
  加载失败说出来。**没做**：写侧（增删改）、农历重复、.ics、滑动翻页 —— 逐条写在文件头
- model/Calendar.ts：补 localIsoOf / hhmmAtOffset / deviceOffsetMinutes（偏移是入参 ⇒ 三时区可真跑）
- model/Models.ets：CalendarEvent / CalendarListResponse（字段对齐服务端 JSON）
- NavItems：加「日历」，底部成为 通信/日历/联系人 三项（与 WebUI 同序）
- MainPage：日历是**常驻 pane**（visibility 控制），首次可见才拉数据；today 走
  @Prop @Watch(visible) 在 pane 变可见时重算 ⇒ 结算欠账 calendar-today-recompute
  （DEBTS 15 笔 → 14 笔，余额里不再计这一笔）

判据：harmony-calendar 新增 6 条（网格/表头同源、事件归日走 localIsoOf、三时区钟点、
today 重算路径、翻月走 addMonths、变异自检）；harmony-nav ② 分派与 ④ 让位跟着改成结构性判据
（④ 原来那个 400 字符窗口一加 pane 就红 —— 窗口式判据的又一次现身）；harmony-logic 两处
「只剩两个平级页签」跟着改成三项。

真机实测（harmony-emu + hvigorw assembleHap + hdc install + uitest click + dumpLayout）：
9 月网格星期对齐（周一起始，2026-09-01 落在「二」列）、事件点恰好在有日程的那 6 天
（11/17/18/24/25/30）、点 09-17 列出当天两条日程且钟点是本地时间（DB 里 02:20Z/08:30Z
→ 界面 10:20/16:30）。
 2026-09-14 18:38:51 +08:00
pi
79e591aa8b 跨端: 底部导航选中态——图标也变色（鸿蒙侧补齐），选中态只换颜色 
用户：「ui更新同步到鸿蒙端」+「选中对应的文字和图标变色即可」。

WebUI（上一提交）：删掉背景块与顶部指示条，只留颜色。
鸿蒙侧：本来就没有背景/指示条（选中态从没用形状表达过），缺的是**图标那一半** ——
MainPage.NavItem 里只有 label 上了 fontColor，图标一直保持默认色，看着像选中了一半。

- MainPage.NavItem：图标补 fontColor，与 label 过同一个三元式
- 判据 harmony-nav ⑤ + 真变异自检（删掉图标那行 fontColor，⑤ 立刻红）
- 自检本身也修了一处窗口式判据：原来用 [\s\S]{0,80} 找 fontColor，
  把下一行 label 的也圈了进来，自检自己假绿
- 模拟器实测（harmony-emu + hvigorw + hdc + uitest）：同一字形在两项之间颜色随选中**对调**
  （核心色 81,121,187 选中 vs 135,168,217 未选中）
- 提交归属：本提交同时动 harmony 与 electron，按仓库判据自报家门（跨端:）
 2026-09-14 18:38:33 +08:00
JianFeeeee
13e8671d03 跨端: feat(P6): 表头与网格共用同一个 startOfWeek；"今天"的调用侧入可跑判据；禁用 toISOString 取日期键 
pi 2026-09-14 两条，都赶在页面骨架之前定下来。

1. **唯一分叉点必须同时喂两处**：整月网格有两个地方依赖"周从哪天开始" ——
   空格数（`leadingBlanks`）**与表头第一格**。表头若在页面里硬编码，就是**第二个分叉**：
   格子全对、**表头整体错一列**，而原有 6 条判据一条都不会红（它们只看网格）。
   新增 `weekdayLabels(startOfWeek)`（顺序只从这一个参数出）+ **交叉核对判据**：
   把"1 号落在第几列"与"那一列的表头字"对上（6 个月份 × 2 种起始）。

2. **"今天"的调用侧**：`today` 入参化让纯逻辑侧干净了，代价是**唯一还能错的地方搬到了调用侧**
   —— 而它正好是纯逻辑判据够不着的。`toISOString()` 是 UTC 口径：UTC+8 的清晨会给**昨天**，
   "今天"就标到上一格，且在本机跑 UTC 的环境里**永远测不出来**。
   新增 `isoOfLocal(now)`（本地年月日手工补零）+ `isoAtOffset(now, 分钟)`（与前者同源但不依赖进程时区，
   好让三种偏移**可以真跑**）。判据钉住：UTC+8 / UTC-7 / UTC 三种偏移的日期、
   **两种取法在 UTC+8 清晨必须不同**（把陷阱本身钉死）、以及本机两条取法自洽。

3. 附带一条**未来时**的判据：鸿蒙树里不许出现 `toISOString().slice(0,10)` 取日期键
   （登记值 0 ⇒ 页面骨架写错时立刻红，报错写"正确修法 = isoOfLocal"与"最常见的错误修法 = 改期望值"）。
   它第一次跑就抓到了 `model/Calendar.ts` 里**解释这个陷阱的注释** —— 所以改扫 `code()`
   （去注释后的代码）：规则管代码，注释是文档。
 2026-09-14 17:43:09 +08:00
JianFeeeee
e94e4dcd39 跨端: feat(P6): 日历纯逻辑 model/Calendar.ts + 6 条可跑判据（第 1 步的逻辑那一半，不需要设备） 2026-09-14 17:41:43 +08:00
JianFeeeee
f5c4f56682 跨端: feat(预设): 静默兜底留一条可观测痕迹；"只写不读"在鸿蒙侧也补上判据（照 LEGACY_BACKUP_KEY 照搬）；§10 出处落地 
pi 2026-09-14 的三小条。

1. **§3 静默兜底要留可观测痕迹**：`normalizePreset` 把认不出的 id 换成 aurora 这件事，
   原先在真实环境里**不留任何痕迹** —— §10 的登记只防"被误报成 bug"，防不住
   "没人知道它正在发生"。现在 `BackgroundPlan.presetSubstitutedFrom` 带出**原来那个 id**
   （换过非空、没换过空串），页面据此打一行日志 ⇒ 后果从"可能发生"变成"**可数**"。
   **痕迹记在返回值里而不是在这一层直接打日志**，理由写进代码：这一层是**纯逻辑**
   （无 `@ohos` 依赖 ⇒ 判据能用 node strip-types 直接跑它）；为打一行日志引入 `@ohos.hilog`，
   等于把"能真跑的行为判据"换成"只能读源码的形态判据"——不划算的交易。
   **判据两条方向都钉**：替换必须留痕（且带出原 id）；**没替换时必须为空**
   （痕迹退化成噪声就等于没有）。变异与正反例都在（5 条全绿）。

2. **§2 §10 的"谁批准"落成出处**：那一格原写"产品决定" —— 按 pi 的话这是**事后追认**。
   现在写的是 **「无人类批准：这是实现时的默认行为（随 `model/Wallpaper.ts` 引入，
   `git log --diff-filter=A` 可查出处，2e42aac），本行是补登记」**，并把**意图**与**批准**分开写
   （不拿意图冒充批准）。另两行也补了出处（`Appearance.ts:39,52,88,104,133` /
   `AppearanceStore.ets:142-195` / `backgroundStore.ts:200`）。

3. **§1 "可扫的字段清册"不必先造 —— 同形状已有一边是判据**：他说得对。
   WebUI 的 `LEGACY_BACKUP_KEY` 早就钉着"只写不读"，鸿蒙的 `bgBlur` 只有文档
   ⇒ 差的是**同一个形状只有一边有判据**。已照搬：`harmony-appearance.test.mjs` 新增
   **"消费侧出现次数必须为 0"**；豁免**按文件登记 + 写理由**（域模型 / 状态同步 / 线上 DTO
   三处是搬运与传输，不是消费）——与 `mail_status_readers_test.go` 的豁免同一形状，
   登记表本身就是清册，不必另造一张。
   变异验证：让 MainPage 读一次 `bgBlur` → 判据红，红的信息写着"**停下：那时必须先补
   px ↔ 材质档位的映射判据**，而不是把登记值从 0 改成 1"。

SUITE 计数同步：harmony-presets 4→5、harmony-appearance 24→25。
 2026-09-14 17:17:37 +08:00
JianFeeeee
456ae5a66d 跨端: pi 五条评审落地 —— 产物自证替代时间戳代理、静态判据可到期、判据能读一层标识符、值/来源配对规则、归因不许动别人的树 
pi 2026-09-14 的评审（`9839f8a9`）五条，逐条落地；其中 §6 的两条是**核对后已成立**，不重复劳动。

## 1 产物自证：`dist/BUILD_INFO.json`（pi §1）

原来那条判据是"`dist` 比 `src` 新"——**代理变量**，pi 指出两层都靠不住：看不见"构建是否
成功"（实测过），而"`dist` 比 `src` 新"也不等于"dist 是从这份 src 构建的"（`checkout`/`cp`/时钟
都骗得过 mtime；我确实用 checkout 造过一次假红）。现在改成**内容自证**：
`scripts/build-info.mjs` 在构建最后一步写 `{gitRev, gitDirty, srcHash, srcFiles, buildCmd, builtAt}`，
判据重算当前指纹再**精确比对**（`test/build-stamp.test.mjs`）——"代理"两个字没有了，
报错能直接读出两边指纹。`release-linux.sh` 打完包把同一份信息打进日志（一个包自带
"它对应哪个源码状态"）。`gitDirty` **只展示不判定**：共享工作区常年是脏的，拿它当红/绿依据
会天天误报。

实测三变异：改 src 内容不重建 → 红（两个指纹都打出来）；BUILD_INFO 记成别的提交 → 红；
**`touch`（只动 mtime）→ 绿** —— 旧判据在这里是**假红**，新判据不误伤，这是它严格更好的地方。

## 2 静态判据的**欠账**与到期（pi §5）

"暂时"不是状态、是待办，规范里写下的"暂时"没有任何机制回来读它。改成可机检的形状：
`run-all.mjs` 登记 `STATIC_ONLY`（5 条：`.ets` 只能验形态）+ **必填到期前提**（探针，真跑
`hdc list targets`）；汇总打 `RESULT static=N`（**欠账余额**）；**前提一旦为真，这些判据当场
变红**并要求"改成行为判据或换更准的前提"。实测：探针恒真 → 5 条同时报"到期"；把前提写成
`'vibes'`（未知探针/陈述）→ 套件红。这是"自报条数 < 登记条数"的**时间版本**。

## 3 判据能解析一层标识符（pi §3）

Go 默认值判据原来"值不是字面量 → 判据读不懂 → 红"，长期结局是有人做一次无害重构
（`BgDim: defaultDim`）就把判据逼宽、再下一步少核一个字段。现在：字面量直接用；
标识符在**同一文件**查 `NAME = <字面量>`；查不到（跨包/计算/iota）才报"读不懂"。
实测：`BgDim: defaultDim` + `const defaultDim = 12` → **绿**（无害重构不再误伤）；
`const defaultDim = baseDim + 0` → 红且报文说"读不懂"。**只解析一层**：再深就是"执行 Go"了。

## 4 §6.7 的可机检分流规则（pi §2）

新增 §6.7.0：**值 → 行为判据，来源 → 静态判据**，理由写成覆盖问题（行为判据只覆盖它跑到的
路径 ⇒ 原理上判不了"有没有别的路绕过去"；来源约束要的是全程序可达性 ⇒ 只有读代码能答）。
两条推论：静态判据判值永远差一个反例、行为判据判来源永远差一条路径；**不是强弱，是分工**，
缺任一条那一对就是假判据。附本仓已有的完整样例（P5 命中区：值判据"≥44"+ 来源判据
"应用点必须引用常量"），新增 §6.8 记欠账机制、§8 记共享树归因纪律。

## 5 值/来源配对补齐 + 让位派生（pi §6 的两条）

- 命中区原来只有值那一半：补**来源**判据（`.ets` 里出现 `minHeight: 44` 这类裸数字 → 红，
  报文点出"值判据管数字够不够大、来源判据管用的是不是同一个数字"）。变异：写死 44 → 红。
- "`76` 应从条高派生"：**核对后已成立**（`NAV_CONTENT_RESERVE = NAV_BAR_HEIGHT +
  NAV_BAR_BOTTOM + 8`，判据也按常量算）。顺手把裸的 `8` 起名 `NAV_CONTENT_GAP`
  （这一族里唯一还需要人判断的数），并加判据钉住**派生关系**：写回字面量 `76` → 红。

## 6 `legacy.bak` 的生命周期（pi §4）：**有意永久残留**，并说清代价

pi 质疑成立：判据钉死"没有任何代码读它"⇒ 也没有任何代码能删它。**否决了"点重置外观时删"**：
最可能点重置的人正是外观被接管的那个人，而这份备份是他唯一的旧值，那时删等于把恢复数据
毁在最需要的时刻。所以定为"有意永久残留"（没有代码路径能判定何时安全删除——那取决于人），
并把代价量出来写进 §7.12：值受 `MAX_DATA_URL_BYTES`（2.4MB）约束，**最坏是一张用户原图的
整份副本**，共享机器上即一份别人的外观；要清就手工 `removeItem`。判据钉住这行**同时**给出
"为什么不删"与"怎么删"（变异：删掉删除方法 → 红）。

## 7 归因方法（pi §6 第三条）：认错并写成纪律

我当天归因 `narrow-layout` 的 3 条红时用了 `git stash push -- MailView.tsx`，动的是**并发写
作者的未提交改动**。结论对、方法不行：它写共享工作区（别人崩溃/`git add -A` 就丢他的活），
而且只影响 tracked 文件（untracked 的 WIP 还在 ⇒ "干净了"是假干净，结论也可能假）。
纪律写进 CRITERIA.md §8：只读手段（`git show HEAD:path > /tmp/...`、`git worktree add`）或直接问作者。

## 验证

`npm test` 全绿（14 个判据文件 + vitest 266 + typecheck），`RESULT static=5`；
`hvigorw assembleHap` BUILD SUCCESSFUL；`scripts/release-linux.sh` 重打 deb（日志带产物指纹）。
提交前两道**真红**按预期挡了我：改了 src 未重建 → build-stamp 红；重建了 dist 未重打包 →
packaging 红。**未验**（照旧不写成已完成）：鸿蒙侧视觉/交互观感、运行期换肤重算（静态判据，
到期前提见 `RESULT static=5`）。

注：本次 `dist`/deb 是在**共享工作区**上构建的，树里含并发写作者未提交的
`CalendarView.tsx`/`index.css` —— 产物里的 `gitDirty: true` + `gitRev` 正是为此留的，
复核时先看那一行。
 2026-09-14 16:00:34 +08:00
JianFeeeee
25ac19b343 跨端: P5 悬浮玻璃导航取代系统 TabBar —— 自绘浮动条 + 命中区 ≥44vp + 内容让位 
（subject 原为「跨端(P5): …」—— 被自己的 commit-hygiene 判据判红：约定是 subject 里带
 `跨端:`，而 `跨端(P5):` 让字面 grep 找不到。判据是对的，改提交不改成判据。）
 2026-09-14 15:34:32 +08:00
JianFeeeee
e94313f66a 跨端: 接手 pi 的两个 WebUI 开项——默认值统一到服务端契约 12/4；缓存键按账号（含一次性迁移） 
pi 问"这两个开项谁执行"，我接了（他那边无 shell，我这边改过 WebUI）。两件都是他读源码读出来的实缺陷。

## 1 默认值：不是审美，是**服务端契约**（pi 更正了自己上一封）

`server/internal/models/models.go` 的 `DefaultAppearance()` 明写 `BgDim: 12, BgBlur: 4`，
且注释宣称"与客户端 backgroundStore / themeStore 的默认值一致"——而 WebUI 的
`backgroundStore.ts` 是 `dim: 24, blur: 8`，**那句注释是假的**；`lib/appearance.ts`
的 `clamp(..., 12, 4)` 又是另一套。**同一份代码里两个"默认值"**，走哪条路就落哪个数。

后果不是"两处代码不一样"这么轻：服务端"没有记录"时客户端以本地为准推上去，
于是**新账号的初始外观由第一个同步它的客户端决定**（先 WebUI 登录存 24/8，
先鸿蒙登录存 12/4）——同一个账号，压暗强度取决于谁先到。

改法：新增 `src/lib/appearanceDefaults.ts` 作为**唯一来源**（DEFAULT_DIM/DEFAULT_BLUR/
上限），`backgroundStore` 与 `lib/appearance` 都引用它，字面量全部消失。

## 2 缓存键按账号（含旧全局键的一次性迁移）

`STORAGE_KEY = 'agentmail.background'` → `storageKey(accountId)` = 前缀 + 账号；
写盘只走 `storageKey()`；旧全局键**只作为迁移源**：当前账号首次读到它时接管并存进自己的键，
然后**立刻删除**（否则下一个账号继续从它"继承"，等于把刚修的缺陷留在原地）；
未登录时不迁移（旧值不能送给一个还不知道是谁的账号）。

配套顺序：`appearanceSync` 在账号切换时**先 `reloadForAccount()` 再 `pull()`** ——
服务端"没有记录"时 `pull()` 会"以本地为准推上去"，那时"本地"必须已经是本账号的值。

## 3 判据（新增第 13 个判据文件 appearance-defaults）

`test/appearance-defaults.test.mjs`：**去 Go 源码里读** `DefaultAppearance()` 的四个字段，
再比对三处（WebUI 常量、store 的 DEFAULT_BACKGROUND 不许有字面量、鸿蒙 Appearance 的字段默认值）；
另两条钉"键按账号、不许退回全局键、旧键必须被删除"与"重读在 pull 之前"。
这样服务端那句注释是**可核对**的，不是承诺。

顺带更正：`Wallpaper.ts` 里"WebUI 默认 24"的注释已过时 → 改 12 并写明缘由；
`harmony-appearance` 里"WebUI 是全局键"的前提失效 → 改为断言两端都按账号分键。

## 验证

`npm test` 退出码 0（13 个判据文件全绿 + vitest 263 passed，原 258 + 新增 5 条行为测试：
键隔离、迁移一次并删除、未登录不迁移、默认值=12/4）。
 2026-09-14 15:17:01 +08:00
JianFeeeee
d1e0ba32f9 跨端: 壁纸遮盖色改用页面底色系（mask 两套主题都深，浅色下方向与 WebUI 相反）；模态遮罩保持 mask 
pi 提了一个**方向性**疑问，让我先把值读出来再定 —— 读完确认**他是对的**，而且这是"机制上确定不同"。

## 实测（两张 SDK 表交叉验证，不靠记忆）

`ets/build-tools/ets-loader/sysResource.js` 给名字→id，`previewer/.../resources.txt` 给 id→值：

| 令牌 | 浅色主题 | 深色主题 |
|---|---|---|
| `ohos_id_color_mask_regular`（原 `Theme.overlay`） | `#99182431` **深蓝灰** | `#b2000000` 黑 |
| `ohos_id_color_background` | `#ffffffff` **白** | `#ff18181a` 近黑 |

⇒ mask 的 light/regular/thick 是**浓度档**（同一深色的三个 alpha），不是深浅两套值：
它在**两套主题下都是深色**（模态遮罩语义）。而 WebUI 的 `--bg-scrim` 浅色是**白**
（原话「浅色下用白把花哨的图案洗淡」）—— 壁纸遮盖用 mask 就是**反方向**：
浅色主题下把预设压暗，而 WebUI 是把它洗淡。

## 改法

- 新增 `Theme.wallpaperScrim = $r('sys.color.ohos_id_color_background')`（页面底色系：
  浅色白、深色近黑，**自动换向**，与"朝底色淡化"同一意图）；预设档与图片档的遮盖层都用它。
- `Theme.overlay`（mask）**只留给模态弹层**（那里语义确实是压暗背后）。
- 不复用 `pageBg` 的原因写进注释：页面底在背景开启时会被换成**透明**
  （`bgActive ? Color.Transparent : Theme.pageBg`），而遮盖层**永远要一个真实颜色** ——
  两个用途生命周期不同，共用一个名字迟早坏一头（这个仓库撞过四次的模式）。

## 判据（从 SDK 读真值再判，不写死结论）

断言「mask 两套主题都深」「页面底色系浅白深黑」「WebUI 的 `--bg-scrim` 浅色是白」，
再落到代码：两处遮盖层必须用 `wallpaperScrim`、弹层仍用 `overlay`、两个令牌不许混用。
**这样"令牌选错方向"以后不能靠记性避免。**

变异：遮盖退回 mask → 红 1 条；只改一层 → 红 2 条。

## 文档

§7.17b-2 记这次读数（表格 + 两张表怎么读 + 为什么不复用 pageBg + 变异结果）；
§7.12 有意差异表加一行（遮盖色令牌：两个语义两个令牌，"不允许混用"）。

## 验证

`hvigorw assembleHap` BUILD SUCCESSFUL；`npm test` 退出码 0
（12 个判据文件全绿 + vitest 258/258；harmony-appearance 23 → 24 条）。
 2026-09-14 15:10:15 +08:00
JianFeeeee
71585dc42b 跨端: 预设档补遮罩（WebUI 的 --bg-dim 不分档位）+ 主题变化时重算"我们自己算的值"；缓存键差异记入表 
pi 读 WebUI 源码后发现两处两边不一致，都处理了。这一提交同时改 harmony 与 electron，故自报家门。

## 1 预设档遮罩：**补上**（选"与 WebUI 一致"，因为那服务的是可读性）

pi 的证据：WebUI 的 `applyBackground()` **无条件**写 `--bg-dim`（默认 24），
`.app-backdrop::after` 是 `rgb(var(--bg-scrim) / var(--bg-dim))` —— **遮罩不区分档位**；
它的注释写着目的「背景越花，正文越需要一层遮罩才读得动」。
而鸿蒙当时只在 image 档压（`resolveBackground` 里那行注释还写着"preset 档不用"），
且我们已经让出了页面底 → 正文直接压在原色渐变上，**比 WebUI 更艳更亮、更不好读**。

现在两档用**同一个浓度**（同一个服务端字段），页面在预设分支的渐变之上加一层
系统遮罩色 × 浓度（浅色由系统洗白、深色压黑，不自己写 alpha）。

判据：旧断言"preset 档不压暗"**反过来**（留着理由），另加一条钉"两档同一浓度"+
"两处遮盖层都在"+"WebUI 确实无条件写 --bg-dim"（这条差异有据可查）。
变异：预设档不压 → 红 2 条；页面预设分支的遮盖层被删 → 红。

## 2 多账号缓存键：**鸿蒙是对的，不许退回**（pi 点名）

WebUI 的键是全局常量 `agentmail.background`，后果是切到服务端没有记录的账号时
`saved=false` 分支会把**上一个账号的外观** push 上去（新账号"继承"了外观，还写进了服务端）。
这条差异进 §7.12「有意差异」表，**明确写"鸿蒙是对的"**，
判据防的就是"将来有人为了两边一致把它改回去"：取键函数的**正文**里必须拼账号 id
（按块取，不是看调用点出现过 `accountId` 就当数 —— "判结构要配对/解析"那条对我自己也适用），
且不许出现 WebUI 那个全局键。变异：`prefKey` 去掉账号 → 红 2 条。

## 3 "未做" → 按 pi 的三档口径改成**已知不一致**，并把系统侧的接法做掉

pi 指出这不是"没做"：色板确实按主题算了，只是没接环境变化事件 ——
现象是运行期切系统深浅色时"系统语义色/材质立刻跟随、我们自己算的色板不重算"的**撕裂**。
他给的规则我记成了通用规则（会咬到 P5/P6）：**系统自动跟随的东西不会顺带把
"我们自己计算/缓存的值"一起更新** —— 凡随主题变化的自算值都要挂在**同一个主题变化事件**上。

照做：`applicationContext.on('environment')` → `onConfigurationUpdated` 里
**只在 `colorMode` 真换向时**重算（`applyAppearance()`），页面销毁 `off` 退订。
状态 = **未验**（只有真机/模拟器能验：切一次系统深浅色看预设是否跟着换）。

SDK 锚点与两个编译错都记进 §7.17b：`EnvironmentCallback.onConfigurationUpdated(config: Configuration)`
（`Configuration` 从 `@kit.AbilityKit` 取，**不在** `common` 命名空间下）、
`Configuration.colorMode` 是**枚举 | undefined**（字段写成 `number` 直接编译失败）、
`on('environment')` 返回 **number 型 callbackId**。变异：不订阅 → 红。

## 4 文档

- §7.12 加两行：缓存键（含 WebUI 侧开项）、遮罩浓度默认值那两套（`24/8` vs `12/4`，
  按 `clamp` 的 12/4 对齐，因为服务端缺字段时落地的是它）。
- §四 验收纪律改成**四档口径**：没做 / 未验 / 已知不一致（要写触发条件与现象）/
  机制上确定不同（必须判），并把 pi 那条"自算值必须挂主题事件"的可复用规则写进去。

## 验证

`hvigorw assembleHap` BUILD SUCCESSFUL；`npm test` 退出码 0
（12 个判据文件全绿 + vitest 258/258；harmony-appearance 20 → 23 条）。
 2026-09-14 15:04:07 +08:00
JianFeeeee
22c9be7181 跨端: 预设色板两套（pi：这不是"观感未验"而是机制上确定不同）+ 手写色清册跨文件 + TMPDIR 按会话分家 + 提交归属可判 
pi 读完 `model/Wallpaper.ts` 后指出四处，全部处理。这一提交同时改了
`client/harmony/` 与 `client/electron/`（跨端改动），所以 subject 按新约定自报家门。

## 1 预设色板不随主题 —— **类别判错了：不是"未验"，是机制上确定不同**

我上一版把"深色档预设"记成"观感未验"。pi 指出：WebUI 的 `.bg-preset-*` 写的是
`rgb(var(--c-blue-100))`，而 `--c-*` 在 `.dark` 里整体换了一套（blue-100 → `30 43 67`），
所以 **WebUI 的预设自动随主题变**；这边只有浅色那套 = 深色主题下"浅色渐变垫在深色系统表面之下"，
正是这一整轮在治的病。**它不需要真机就能判**（机制写在代码里）—— 我把可判的东西
记成了"未验"，这跟上一轮把"没做"写成"没验"是同一类错。

选 pi 倾向的那条（跟随主题，与 WebUI 一致）：

- 色板两套：`LIGHT_*` 取 CSS `:root`、`DARK_*` 取 CSS `.dark`；`paletteFor(dark)` 选一套，
  `layersFor(id, dark)` 按主题出层；
- `isDarkMode(theme, systemColorMode)` 放在纯逻辑里：选了 dark/light 就照办，
  `system` 看系统当时的 `colorMode`（锚到 SDK：`COLOR_MODE_DARK = 0` / `COLOR_MODE_LIGHT = 1`；
  读不到按浅色，与 WebUI 的 `:root` 默认一致）；
- 系统深浅从 `resourceManager.getConfigurationSync().colorMode` 读
  （`Context` 基类没有 `config`；`UIAbilityContext.config` 要转型；两个枚举取值一致，都核过 SDK）；
- 判据：两套值与 `:root`/`.dark` **逐个相等**；每个预设的深浅两套**必须真的不同**
  （否则"两套"是抄了两遍）；网格线色也要换；`isDarkMode` 五种输入。
- **未做**：运行期间改系统深浅色不会自动重算（要重进页面）——系统侧正确做法是订阅
  `applicationContext.on('environment', …)`，记在 §7.17b。

变异：`DARK_BLUE_100` 偏一位 → 红；`paletteFor` 永远返回浅色（= 我原来那个状态）→ 红；
`isDarkMode` 把系统深浅记反 → 红；页面把深浅写死成 false → 红。

## 2 手写色清册**跨文件按类扫**（原 A2 只保护 `Theme.ets`）

`Wallpaper.ts` 也有手写色。若对照是"按名字枚举"的，第 15 个色就会逃掉 ——
与 A2 要防的是同一件事，只是换了文件。现在一份清册按类扫：全 `ets/` 树里每个
`X: string = '#RRGGBB'` 都必须登记（Theme 的品牌/业务语义色，或预设色板 ——
后者常量名必须带 `LIGHT_`/`DARK_` 前缀，值由 CSS 两段比对负责）。反向也判清册过期。

变异：`Theme.ets` 加未登记色 → 红；`Wallpaper.ts` 加未登记色 → 红；
加一个"看着合规"的 `DARK_EXTRA` → 红。

## 3 `TMPDIR` 互踩（pi 提出）

这个 worktree 可能同时有多个 agent 跑构建，而 fpm 会把 291MB 的 `linux-unpacked`
**整份复制**进 `TMPDIR` —— 撞车就是随机的产物损坏。`whoami` 区分不开（大家都是 root），
所以按**会话**分家：`TMPDIR=$PWD/.tmp/${DSH_SESSION_ID:-$(id -un)-$$}`
（进了 `npm run build:linux` 与 BUILD.md 的手敲命令；普通终端退化成"用户+PID"）。

## 4 提交归属变成**跑判据就看得出来**（pi 给的形状）

新的 `test/commit-hygiene.test.mjs`：扫最近 40 条提交，**同时改两侧目录**的提交
必须在 subject 里自报家门（`跨端:`）。两条防腐：基线 = 该判据文件自己的引入提交
（**历史不改**，规则管从今往后）；分类逻辑拿合成输入自检
（未标注的混合提交必须判红、标注过的不许红）——否则"解析没跑起来"时它会全绿。
变异：`COMMIT_HYGIENE_BASELINE` 指到老提交 → 历史里那两个被卷进去的提交立刻判红。

## 验证

`hvigorw assembleHap` BUILD SUCCESSFUL；`npm test` 退出码 0
（12 个判据文件全绿 + vitest 258/258；`commit-hygiene` 在本提交落地后基线生效）。
 2026-09-14 14:57:18 +08:00
JianFeeeee
1717863c87 fix(webui): 手势与横向滚动分家 + 纵向滚动边缘淡出 
用户给了两条具体信息（这比我自己猜五轮都管用）：
「横向滚动条会与切换视图的手势冲突，我觉得周视图需要卡严条件，
  同时我说的其他硬截断是对应内容项上下滑动会直接被切断」。

## ① 手势卡严（周视图）

冲突是真的：周视图窄屏下必须横向滚（`overflow-auto` + `min-w-[36rem]`），
而我又给整页加了左右滑动翻页 ⇒ 同一次横滑既想滚又想翻，两边都不好用。

规则定死：**手势从可横向滚动的区域里起手，就归滚动条，完全不参与翻页判断**
（触点沿祖先链查找 `overflow-x: auto/scroll` 且真的能滚的容器）。
想翻页就从别处滑（例如上方标题栏）。

## ② 纵向滚动边缘淡出

滚动条本身是"一刀切"：卡片滚到边缘被硬生生截断 —— 这就是用户说的"直接被切断"。
给纵向滚动容器（`.overflow-y-auto`）加 12px 上下渐隐遮罩，切得有交代。

只作用在**纵向**容器：横向滚动有自己的滚动条，加纵向遮罩会跟它打架。

## 过程记录（值得记）

这两条改动**第一次没有生效**，因为部署失败了：`/tmp` 是 tmpfs 且已 100% 满，
而部署脚本把构建产物写到硬编码的 `/tmp/agentmail-gateway-build-*` ⇒
`no space left on device`。我差点把"旧构建上的测量结果"当成"改动无效"。
清理后（清掉我自己的探针脚本/截图/旧构建，约 950MB）部署成功。
⚠️ `/tmp` 现在仍占 91%（`gocache` 4.5G 等不全是我的），**下次部署可能还会撞上**；
脚本改成尊重 `TMPDIR` 才是根治（未做）。
 2026-09-14 14:35:43 +08:00
JianFeeeee
c9717daa13 fix(webui): 联系人项改为"每项一张玻璃卡"（补齐上一轮承诺） 
上一轮我说过"联系人/会话列表还是老结构，只有 MailList 改了"，这条把它补上：

- 联系人项：`rounded-lg border` → `.glass-card`（圆角 14px + 白色玻璃 + 细边框），
  与邮件行、顶部气泡、日历格子同一套语言；
- 会话分组行与邮件行上一轮已经是 `.glass-card`，所以三类列表现在一致了。

实测（自有浏览器，壁纸开，1400×900）：联系人页的卡片 `border-radius: 14px`、
底色 `rgba(255,255,255,0.78)`。

另外这一轮我又试了两个"滑动硬截断"的假设，**都不成立**：
- 窄屏日历（月/周/日三种刻度）：月与日刻度不溢出；周刻度溢出 208–278px 但
  **有横向滚动条**（`overflow-auto`），不是硬截断；
- 页面级横向溢出：390/320 下都是 0。

所以这条仍然需要用户指路。**而且教训很明确**：上一条"列表与正文之间的大空隙"，
我三轮猜都没猜中，用户一张截图我当场就定位了。截图比任何自测量法都快。
 2026-09-14 14:31:16 +08:00
JianFeeeee
2e42aacc07 fix(webui): 修「列表与正文之间那条大空隙」—— 包装层撑满而列表面板固定 320 
用户发截图指出：「外框列表和右边正文那么大一个空隙」。

## 根因（在代码里很难看出来）

我为了让「通信」有内部页签与悬浮加号，给中栏加了一层包装 div，它写着 `flex-1`；
而里面的列表面板是 `lg:w-[320px]` **固定宽度** ⇒ 包装层把剩余宽度全占了，
**空隙在包装层里、不在任何面板里** —— 于是既看不出是哪一层的错，也不像"布局 bug"，
看起来就像设计上多留了一条白。

## 改法

`​.app-shell .comm-pane { flex: 0 0 auto; width: 320px }` —— 宽屏下中栏贴住列表面板的宽度。
窄屏不动：那边外壳是**列**方向，`flex-1` 管的是高度，宽度由 `w-full` 决定。

## 实测（自有浏览器）

    宽屏 1600: 包装层 320 / 列表 320 / 详情 1180  →  包装层内空隙 0px，到详情 10px（设计间距）
    窄屏 390:  包装层 370 / 列表 370              →  包装层内空隙 0px

顺带说一句：这条与前面「日历没有圆角」「列表项变成一张大框」是**同一个包装层**引出的
三个症状（撑满宽度 / 内层直角戳出圆角 / 每项没有独立卡）。包装层是我为合并导航加的，
当时的验证只看了结构（页签在不在、点得到点不到），**没有量过宽度**，
所以它一连串地出问题。现在宽度已有判据（上面的数字就是判据）。
 2026-09-14 14:29:27 +08:00
JianFeeeee
a6b5e52f45 test(harmony): 判据按 pi 复核意见补强 —— 手写色登记表、玻璃叠用形状、按标题取小节、遮罩必须被用、废弃 API 清单从 SDK 生成 
pi 逐行读了 `cross-client-theme.test.mjs` 与 `Theme.ets` 后指出五处（第一处是真缺口），
外加一条建议。全部处理，并且**每一处都用变异验证过**。

## 一（真缺口）：枚举 11 个"必须是系统资源"的名字，挡不住第 12 个新写死的手写色

`static readonly brandSecondary: string = '#123456'` 这种新增**三条判据都碰不到**：
A（不在名单里）、B（六位、不是半透明）、裸色值那条（只管 `pages/`）。
原理与当初 14 处 Google 色逃出去是同一条 —— **枚举挡实例，类才挡漂移**，
只是这次枚举的单位是**名字**。补 `A2` 条：

- 枚举 `Theme.ets` 里所有 `static readonly X: string = '#……'`，未登记的 → 红；
- 名单里已不存在的名字 → 红（名单不能烂成化石）；
- `Theme.ets` 里的「手写色登记表」段必须逐个列出这些名字（理由不能只存在于记忆里）；
- 自检：把一个**新的**手写色塞进源码字符串，确认这条抓得到。
  `Theme.ets` 因此新增登记表（17 项，每项一行理由，按品牌 / 业务语义 / 档位胶囊分组）。

变异：Theme.ets 加 `brandSecondary` → 红。

## 二：C 的"玻璃只有一处"**说错了自己断言的东西**

`assert.equal(glassCalls.length, 1)` 断言的是"全仓共一处"，**不是**"没有嵌套"：
同页两个**并列**玻璃面（没问题）会让它红，真嵌套它没在判。P5 正是悬浮玻璃导航，
到时若把 1 改成 2 就等于不判。改成形状判据：

- 收集每个调用点所作用的**组件块**（按括号配对回溯；注意 ArkUI 修饰符是链式的，
  `X.blur(A).blur(B)` 前面是 `)` 不是 `}` —— 第一版只看一个字符，对这种写法**静默失效**，
  是判据自检抓出来的）；
- 判两种叠法：同一组件上叠多次（同一块）、以及套在另一层玻璃的子树里；
- 每一处玻璃都要在 `GLASS_REGISTRY` 里登记（附一句为什么），名单里的位置若已不存在 → 红。

变异：链式叠两层 → 红；通信页多开一处未登记玻璃 → 红；导航条块内嵌玻璃 → 红。

## 三：文档小节用 `indexOf('有意差异')` 会**拿错段落**

别的段落正文里出现这四个字，切片就从那里开始，后面所有断言都在**别的段落**上判。
改成**按标题**定位（正则匹配 `^#{2,4}…有意差异…$`），并加了表头列名断言
（WebUI / 鸿蒙 / 为什么）—— 拿错段落时表头不会是这个形状，于是它自己会红。

顺带修掉一个**我自己的**同类毛病：品牌色那行原来用"关键词 + 80 字符窗口"判，
窗口宽度在赌表格单元格字符数（该行两格之和 > 80）。改成**按行取**那一行再断言。
另外把偏移算术的切片换成**按行**切片（偏移差一个字符就会把最后一行拦腰截断，
现象是"品牌色那行只剩 57 字符"这种看着像文案、其实像切片的怪事）。

变异：文件前面插入含「有意差异」的段落 → 仍绿（按标题定位生效）；
再改坏真表里的品牌色行 → 红（确实读的是那一张表）。

## 四：`Theme.overlay` 只判了"存在"，没判"被用"

没使用点的令牌是自证。补断言：它必须在 `Theme.ets` **之外**有真实使用点
（实测 `SettingsPage.ets` / `MailDetailPage.ets` 两处自绘弹层在用），
并把 `overlayColor`/`overlayAlpha` 消失的理由写进 §7.12 —— 否则下一个人会当成漏改补回来。

## 五：材质档次是这次替换里唯一"判据绿但可能观感错"的地方

`COMPONENT_THICK` 的依据（对 THIN / BACKGROUND_* / ULTRA_THICK 的取舍）写进 §7.12，
并把"材质档次在导航条上的实际观感"列为**模拟器起来后第一个要看的项**（间距是数字，材质是判断）。

## 六（建议）：废弃 API 判据**类化** —— 清单从 SDK 生成

原来是手写"不得再用全局 `promptAction.showToast`"（只挡已踩过的那个）。
现在从 SDK 生成：顶层（花括号深度 0）被标 `@deprecated` 的 `declare function`
—— 实测 68 个名字（含 `animateTo` / `getContext` / `px2vp`），配一份**空**的 allow-list。
深度判定是必要的：`declare namespace fileIo { declare function open() }` 里的 `open`
是命名空间成员，算进来会造一堆假红。只算全局调用（排除 `x.name(`）。

变异：调 `px2vp(10)` → 红；`this.px2vp(10)`（成员调用）→ 绿（假阳性自检）。

## 验证

`hvigorw assembleHap` BUILD SUCCESSFUL；`npm test` 退出码 0
（11 个判据文件全绿 + vitest 258/258）。cross-client-theme 13 → 14 条，harmony-system-api 4 → 5 条。
 2026-09-14 14:26:45 +08:00
JianFeeeee
2a6ad93ec0 feat(harmony): P4 —— 外观（主题 + 壁纸）跟着账号走 
服务端 2026-09-13 起就是外观的权威（账号级 `/api/v1/me/appearance`），WebUI 接好了，
**鸿蒙这边此前完全没接**。这一期补上，并把"谁覆盖谁"的规则做成可判据的纯逻辑。

## 改了什么

- `api/AppearanceApi.ets`：`GET/PUT /me/appearance`、`POST /me/appearance/image`、
  `GET /me/appearance/image`（图片带认证取回本体：不用 `?token=`，也不让 Image 直连 http）。
- `api/ApiClient.ets`：新增 `getBytes()`（按 ARRAY_BUFFER 收）—— 复用 `request<T>` 会当场炸，
  因为它假定响应是 JSON（`JSON.parse`）。
- `model/Appearance.ts`（纯逻辑，判据直接执行）：归一化 / PUT 报文 / **合并决策** /
  模糊值→系统材质档次 / 主题→系统色彩模式 / 遮罩浓度 / 状态文案。
- `common/AppearanceStore.ets`：落地副作用 —— 主题交给**系统**（`setColorMode`，不自己维护
  深色色值）、壁纸取回 `PixelMap`、缓存**按账号**分键（`appearance.<accountId>`）。
- 入口两处：`MainPage`（进主界面就应用 —— 只在设置页生效的话"一进主界面就变回去"，
  WebUI 侧踩过）与 `SettingsPage` 新增「外观」段（三档主题 + 同步状态「已同步 / 仅本机」）。

## 为什么这么写（两条最贵的规则）

1. **服务端"没有记录"时以本地为准**（`saved === false`）：服务端这时回的是一份*默认值*，
   拿它覆盖本地 = 把用户已有的主题/壁纸抹掉（WebUI 原话：每个老用户升级后第一次登录
   都会发现被重置）。正确动作是把本地那份推上去。
2. **降级必须可见**（`local-only` → 显示「仅本机」）：否则用户以为换设备也能带走。

## 判据（新增 11 条，已接进 run-all；套件 10 → 11 个判据文件）

归一化（脏值/越界/小数/NaN 退回默认）；`image` 档无图 → 退回 `none`；PUT 报文蛇形字段名；
★服务端无记录 → 以本地为准且**一个字段都不能被默认值顶掉**；服务端有记录 → 以服务端为准但
**不擦掉**本地那张服务端还没有的图；离线状态可见且三种状态文案互不相同；
★模糊值→系统材质档次（与 SDK 的 `BlurStyle` 成员**逐一比对**）；
主题→色彩模式（数值与 SDK 的 `ConfigurationConstant.ColorMode` **逐一比对**）；
★路径必须**相对基地址**（WebUI 那条"整套同步从来没生效过而单测全绿"的坑）；
缓存键**带账号**；两处入口都真的应用。

变异验证（6 种，均判红）：默认值覆盖本地 / 不管"image 档但服务端无图" / 材质档次自造名字 /
路径多写 `/api/v1` / 缓存键不带账号 / 深浅色彩模式数值写反。

## 判据抓到的两个真 bug

- `snapshotFromResponse` 在字段缺失时给 `bgDim = 0`，而 WebUI 语义是退回 12 ——
  ArkTS 反序列化把缺失字段留成**类里写的默认值**，"字段不在"与"字段是 0"分不开。
  已把默认值对齐 WebUI 的 `clamp(..., dflt)` 语义（并让 `saved` 默认 false = 安全的那一侧）。
- 主题落地按"0=浅色、1=深色"写的 `setColorMode` —— **正好反了**
  （SDK：`COLOR_MODE_DARK = 0`、`COLOR_MODE_LIGHT = 1`），选深色会切成浅色。
  靠判据去 SDK 枚举文件读数比对发现；映射已搬进纯逻辑 `colorModeValue`，
  从"某处有个 setColorMode 调用"变成"可判据的行为"。

## 验证 / 未验

`hvigorw assembleHap` BUILD SUCCESSFUL；`npm test` 退出码 0（11 个判据文件全绿 + vitest 258/258）。
套件自检又抓到一次"判据写好没接进套件"（新文件第一版漏了 run-all），已修。

**未做**：壁纸**上传**入口（选图 → `POST /me/appearance/image`）—— 需要 picker，API 与命名已就位。
**未验**：壁纸在真机上的渲染 —— 需真机或模拟器。
 2026-09-14 14:19:26 +08:00
JianFeeeee
73f886aea5 feat(harmony): P2b+P3 —— 「收件箱」改成「通信」（内部三栏 + 徽标 + 悬浮加号），发件箱与授权栏落地 
用户：「收件发件授权改为一个导航项，通过内部导航区分，然后新建作为他们内部的一个悬浮的圆形加号」。
所以这一期不是"再加两个页面"，而是对齐信息架构。

## 鸿蒙侧

- 底部第一项 **收件箱 → 通信**（`CommPage`），内部三栏 收件箱 / 发件箱 / 授权；
  页签下划线式（不是浮动白胶囊 —— WebUI 侧用户原话「通信页面的二级页面与其他位置极其割裂」）。
- **徽标**：收件箱红（未读）、授权橙（**待决策**）、发件箱无；0 不显示，>99 写 `99+`。
  合并成一个导航项后，底部看不到"授权有 3 个在等我"，这个信息不能丢 —— 它比未读更急。
- **悬浮圆形加号**挂到通信页这一层（三个栏都要能新建）；`⚙` 也搬上来（否则切栏就够不到设置）。
- **收件箱不再混权限邮件**（`splitByPermission`），未读按筛后算 ——
  WebUI 实测过"一个会话 17 封权限邮件挤掉另外两个会话"。
- **发件箱**：`GET /me/mail/sent`，与收件箱同构（同一套折叠/行），行上主角是**收件人**；
  空态有说明（主句与 WebUI 逐字一致「暂无邮件」+ 一句"这里放什么"）。
- **授权栏**（P3 主体）：`GET /permission/pending`（不从收件箱筛）+ `POST /permission/decide`。
  拒绝**可填备注且备注真的送出**；请求**过期**时当场说清「审批不会让那次调用继续」。
- 顺手删掉死代码：收件箱里「写邮件」的 `bindSheet`（`composeVisible` 从未置 true，谁也打不开）。

## 判据（harmony-logic 19 → 28 条）

页签键/顺序从 WebUI 源码抽取比对（`uiStore.ts` 的 `CommTab` + `CommTabs.tsx` 的 `TABS`）；
页签状态机（键↔下标往返、脏键/越界/非整数 → 回收件箱）；徽标规则（数字来源、0 不显示、
99+ 上限、红/橙与 WebUI 类名对应）；分家语义（决策过的不再算待决策、空串与 null 同义）；
三栏空态互不相同且主句与 WebUI 一致；接线（三个 pane 真的渲染、加号是圆形且在通信页、
"先分家再折叠"、接口路径与决策体三字段、拒绝传备注、过期分支）。

判据抓到一个**真 bug**：`commTabFromIndex` 只判范围，`1.5` → `COMM_TABS[1.5]` = `undefined`
（表现"点哪都不亮"）。已加 `Number.isInteger`。

变异验证（六种）：授权徽标看未读 / 权限邮件不分出去 / 类型名拼错 / 决策过仍算待决策 /
收件箱不分家 / 发件箱空态去掉说明 —— 全部判红。

## 排序说明

**日历暂时没有入口**：P6 的内容（网格 + 事件读写 + 滑动翻页）还没做，
先放一个点进去空着的入口比暂时没有更糟 —— 有意排序，记在 §7.15 以免被当成漏做。

## 验证 / 未验

`hvigorw assembleHap` BUILD SUCCESSFUL；`npm test` 退出码 0（10 个判据文件全绿 + vitest 258/258）。
**未验**：页签/徽标/悬浮加号在真机上的观感与点击 —— 需设备或模拟器（模拟器要人在命令行启动）。
 2026-09-14 14:13:45 +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
36f3183bba feat(harmony): 系统方案第一批 —— 表面/文字/圆角交给系统、删手写玻璃、每项一张卡；跨端判据改"意图相同" 
jianf：「鸿蒙也同步，但是鸿蒙要求用系统方案」。按 pi 对齐的形状（A/B/C + 品牌色防线）落地。

## 鸿蒙侧改了什么

- `Theme.ets` 的表面/文字/分隔/遮罩/圆角**来源换成系统**：
  `pageBg→sys.color.ohos_id_color_background`、`surface→…_list_card_bg`、
  `surfaceMuted→…_sub_background`、`border→…_list_separator`、三级文字 `→…_text_primary/secondary/tertiary`、
  `overlay→…_mask_regular`、`radiusCard/Control→sys.float.ohos_id_corner_radius_card/button`。
  于是这些维度自动跟随深色模式与无障碍设置 —— 这正是"手抄 WebUI 色值"做不到的事。
- **删掉手写玻璃** `#B8FFFFFF`/`#B80F172A`：那两个值等于"我们替系统猜了深色该怎么做"。
  换成一个**档次**声明 `navMaterial: BlurStyle = BlurStyle.COMPONENT_THICK` + 导航条上的
  `.backgroundBlurStyle(...)`；深浅两套颜色与模糊半径由系统按主题给。
  遮罩的两段式（色 + 透明度）同样删掉：拆两段本就是为了"随主题换向"，而这件事系统已经做了。
- **每项一张卡/气泡**：收件箱行、会话组头、联系人列表行改成卡片（圆角 + 卡片底色 + 行间距），
  联系人列表那条贯通分隔线删除。
- 仍然自己写的只有两类：**品牌色**（`accent = #2563EB`，跨客户端身份）与**业务语义色**
  （权限三档、预算三档 —— 系统只有 warning/alert 两个情绪色，凑不出三档，硬套会丢语义）。

## 判据：从"取值相同"改"意图相同"（两侧一起改）

- 品牌蓝**唯一保留取值钉**，并新增防线：不得退化成 `$r('sys.color.*')`
  （系统强调色随主题/厂商皮肤变，"两个客户端是同一个产品"就靠不住了）。
- 圆角/材质/遮罩：改成"WebUI 自声明令牌 + 鸿蒙来自系统 + 差异被记录"（§7.12 有意差异表）。
- 新增 A（系统拥有的维度唯一来源是 `$r('sys.*')`，且不得退回 string/number）、
  B（旧机制不得回来：`navBg*`、8 位半透明色、`rgb(`/`rgba(`、写死的 14/8）、
  C（玻璃位置必须调 `backgroundBlurStyle` 且**只许一层**）。
- pi 指出的洞已补：裸色值判据原来只扫 `#RRGGBB(AA)`，抓不到 `rgba(`/`0xRRGGBBAA` ——
  而这几种恰是"改用系统材质"时最容易混进来的形态。现在四种一起扫，且**先剥注释**
  （注释里正当地引用旧写法不该被judged红）。
- pi 的 §5 建议也已落地：新增"版本库不得跟踪缓存/构建产物"判据（`.tmp/` 那次 554 个文件的事故判据化），
  并放行 `server/internal/static/static/placeholder.html`（go:embed 落点的有意占位，删了 Go 侧编不过）。

## 变异验证（能红，且红在对的地方）

| 变异 | 结果 |
|---|---|
| 品牌蓝 → 系统强调色 | 红 3 条 |
| 手写玻璃 `navBgLight` 回来 | 红 2 条 |
| 导航改用写死半透明色、不调 `backgroundBlurStyle` | 红 2 条 |
| 卡片上再开一层模糊 | 红 1 条（"玻璃应只出现在一处，实际 2 处"） |

## 验证 / 未验

`hvigorw assembleHap` BUILD SUCCESSFUL；`npm test` 退出码 0
（10 个判据文件全绿：跨端 13 条、系统资源名 4 条、harmony-logic 19 条… + vitest 258/258）。
**未验**：观感（卡片间距、系统材质在导航条上的实际效果、深色模式）—— 需真机/模拟器；
模拟器要人在命令行跑一次 `harmony-emu start`。`sys.*` 名字全部对着 SDK 名表核过，且判据持续盯着。
 2026-09-14 14:04:04 +08:00
JianFeeeee
bb855b1518 fix(webui): 日历补上圆角 —— 外层面板圆了、里面的格子还是直角 
用户：「日历页面怎么没有圆角」。

原因与列表那次同源：**外层面板一直是圆的**（`.app-shell > *` 给了 14px），
但里面的日格/列写的是 `border-b border-r`（直角 + 细边框），而我早前为了修滚动
去掉了面板的 `overflow: hidden` ⇒ 里面的直角就戳在圆角外面，看起来"整页没有圆角"。

改法：日格、周视图列、以及日历的两个大面板都改用 `.glass-card`
（圆角 14px + 白色玻璃 + 细边框），与列表项、顶部气泡同一套语言。
顺手去掉日格上的 `overflow-hidden`（它会把事件条裁掉，而"裁掉"正是这几轮的老毛病）。

实测（自有浏览器，壁纸开）：日历里 **42 个 `.glass-card`**（月视图 42 格 + 面板），
格子 `border-radius: 14px`、底色 `rgba(255,255,255,0.78)`。

（这条同样是"外层圆角 + 内层直角"这一类问题 —— 我已经在列表、顶部、日历上
各修了一次。要找根因的话：**面板圆角不能靠 `overflow: hidden` 裁**（它会杀滚动），
所以每一层自己都要圆角。这是这套"浮动面板"设计的固有代价，写在这里备查。）
 2026-09-14 13:47:58 +08:00
JianFeeeee
3729afd96f feat(harmony): P2a —— 收件箱按会话折叠 + 联系人页卡片视图（判据直接跑同一份逻辑） 
按 pi 的结论落地 P2a 的前一半：**先补视图与折叠，再删平级「会话」tab**（tab 本轮保留）。

## 判据怎么"点用户真正会点的那一层"

鸿蒙侧没有设备（`hdc list targets` 为空、模拟器在本机沙箱下起不来），"点一下"暂时
无法自动验。应对不是编个能过的新判据，而是把会点的那一层的内核抽成纯逻辑：
`entry/src/main/ets/model/MailGrouping.ts`（无 UI 依赖），判据用 node 的
`--experimental-strip-types` **执行同一份代码**（`test/harmony-logic.test.mjs`，14 条），
断言的是行为而不是"源码里出现过某个字符串"：

- 折叠后组头是不是**最新一封**、组内是否时间倒序、组间排序、同一时刻用 `mail_id` 倒序兜底；
- 时间解析失败**不能让顺序依赖入参**（WebUI 侧踩过的 NaN 比较坑）；
- 多账号合并下同名 `session_id` 不能被错并成一组；`session_id` 缺失时各自成组；
- 预算档位与 WebUI `BudgetChip` 完全一致（剩 0 用尽 / ≤1 将尽 / 上限 0 不显示）；
- 视图切换与卡片上"最新一封是人还是 Agent"的判据。

页面那一层另用源码判据钉"确实调了这些函数"，两层合起来覆盖「逻辑对」+「页面接上了」。
**变异验证 4 处全部判红**：去掉组内排序（2 条红）、预算阈值 `<=1` 改 `<1`、
分组键去掉账号前缀、页面不再区分单封组。

## 收件箱折叠

- 组头取组内最新一封的别名与主题，带未读数徽标与「N 封」，点它展开/收起；
- **单封不成组、平铺**（与 WebUI `isFlatGroup` 同结论：给孤立一封信套组头只是多一次点击）；
- 多账号是鸿蒙特有：分组键带账号前缀；`session_id` 缺失按 `mail:<id>` 各自成组。

## 顺带修掉一个"看起来是总数、其实是未读数"的显示

`/me/mail/inbox` 的 `total` 是 **`CountUnread`（未读总数）**，不是总封数
（`server/internal/handler/me.go`）。鸿蒙底部原写「共 N 封」⇒ 同一屏出现
「共 7 封」和「未读 7」两行自相矛盾的字。改成：未读数用服务端 `total`（权威，
原来数这一页会少报）；「共 N 封」→「已加载 N 封」；**这一页取满时如实提示
「已加载 50 封（本页上限 50，可能还有更多）」** —— 客户端没有可信总封数，
就不能把 50 封说成全部（pi 提醒的"别让只取 50 封伪装成只有这么多会话"）。
WebUI 侧不读这个字段，故只影响鸿蒙。

## 联系人页补卡片视图（撤 tab 的前置）

- 右上角切列表/卡片，标题「联系人」/「工作列表」（与 WebUI 同词），切换规则在
  `nextContactView()`；
- 卡片对应 WebUI 的 `WorkCard`：Agent 名 + 工作目录 + 未读徽标、会话别名、
  **主题当主角**、最新摘要 + 人/Agent 标记、`N 封 · 时间`、权限档位徽标、
  **往返预算条**（同一档位判据）。
- 平级「会话」tab 暂留：撤 tab 按 pi 的顺序排在后面单独一步（撤早了预算/status/from_agent 没处看）。

## 验证

- `hvigorw assembleHap` **BUILD SUCCESSFUL**（`.ts` 纯逻辑模块被 `.ets` 引用，实测可行）。
- `npm test` **退出码 0**：窄屏布局全通过、主题 30、背景 34、cross-client 8、
  harmony-logic 14、packaging 3、vitest 258/258；新判据已接进 `npm test`。
- **视觉与点击仍未验**（无设备）：展开手感、卡片间距、组头命中区没有任何自动判据
  能代替人眼 —— 交付按"结构/逻辑已验证、观感未验"写，未写成已完成。
 2026-09-14 13:36:05 +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
cefd96a6a3 feat(clients): UI 设计同步到客户端 —— Electron 包重建 + 鸿蒙设计令牌 
用户：「下一步就是同步 ui 设计到客户端了」。

## ① Electron 客户端（之前严重滞后）

打包产物停在 **09:11**，而前端 dist 是 **12:23** ⇒ 今天所有 UI 工作（导航合并、悬浮玻璃、
圆桌语言、Composer、动画、模糊分层…）**一个都不在包里**。已重建 AppImage + deb。

**验证**（关键：AppImage/deb 是压缩容器，`grep` 直接扫是扫不到的 ——
我第一次就差点因此得出"包里没有"的结论）：把 deb 解到 /tmp 再查 `app.asar`：

    comm-tabs=2  compose-fab=1  nav-rail=2  glass-control=2  cal-slide-next=2
    构建戳 "5ce25f6·0914-1240"（与当前提交一致）

## ② 鸿蒙客户端

它是**原生 ArkTS 应用**（22 个 .ets、自带 API 层），不是 WebView 壳 ⇒ 设计要移植。

第一步做的是**共用词表**：新增 `common/Theme.ets`（品牌蓝、页面底、面、分隔线、
导航玻璃不透明度、圆角 14/8、语义色、字号），全部注明与 WebUI 令牌的对应关系
（含一个易错点：CSS 是 `rgb(r g b / a)`，鸿蒙是 `#AARRGGBB`，0.72×255≈184=0xB8）。

顺带修掉一个真 bug：TabBar 的选中色写成 `this.currentIndex === 0` ⇒
**只有第一个 tab 会高亮**。现在按每个 tab 自己的下标判断。

**编译验证**：`hvigorw assembleHap` → **BUILD SUCCESSFUL**（HAP 已打包）。
（无法在设备上跑：本机 `hdc list targets` 为空、HAP 未签名 ⇒ 视觉未验证，如实说明。）

## ③ 判据：跨客户端令牌一致性

新增 `test/cross-client-theme.test.mjs` 5 条：品牌蓝、卡片圆角（0.875rem=14px）、
导航玻璃 0.72 —— 断言的是"两边对同一件事取值一致"，不约束实现方式
（CSS 变量 vs ArkTS 常量本来就该不同），并带一条扰动自检。
这种漂移**没有任何判据会红**，所以必须显式钉住。

## 还没做的（如实说明）

鸿蒙端只同步了**设计语言**，功能面不对等：鸿蒙是 收件箱/会话/联系人 三个 tab，
没有 日历/授权/管理；也没有玻璃悬浮底栏与 Compose 共用组件。要做功能对齐是另一件事，
需要单独排期（我可以按你的优先级来）。
 2026-09-14 12:43:08 +08:00
JianFeeeee
a404cbad54 feat(branding): 确定项目图标，并接入 Web / Electron / HarmonyOS 
# 唯一源

`client/electron/src/icons/agentmail.svg` 是图标唯一源（24×24 视图框，`currentColor`
跟随文字色）。此前各端用的都是占位物：Electron 的窗口/托盘指向一个**不存在**的
`src/icons/tray-icon.png`（`nativeImage` 拿到空图，托盘不可见），
HarmonyOS 的 `startIcon/foreground/background` 是 1×1 PNG，
Web 端根本没有 favicon。

# 为什么带生成脚本

PNG/ICO 是二进制的，换一次配色要重出十几个尺寸，手工做必然出现
「Web 是旧的、Harmony 是新的」这种不一致，而且没人能复核。
`generate.py` 只认上面那一份源，所有变体都由它推导（本机无 rsvg/ImageMagick，
用 cairosvg + Pillow）。改图标只需改源文件再跑一次脚本。

# 各端产物

- **Web**：`public/assets/{agentmail.svg,favicon.ico,apple-touch-icon.png}` + `index.html` 引用。
  放 `assets/` 下而非根目录，是因为 Gateway 只把 `/assets/*` 与 `/` 交给静态处理器
  （`server/cmd/server/main.go`），放根下会 404。已实测本机与 LAN 均 200。
- **Electron**：应用图标 `icon.png`(512) / `icon.ico`(16–256) / 各尺寸 PNG /
  托盘 `tray-icon.png`(32)，`package.json` 里 `win.icon` 与 `linux.icon` 指过去。
  托盘用品牌色字形而非白色 —— 浅色面板下白色会消失。
- **HarmonyOS**：`startIcon.png`(512) 用完整应用图标（启动页底色浅 `#FFF` /
  深 `#000`，白底蓝图标两套都立得住）；分层图标的 `background` 是品牌色整块、
  `foreground` 是白色字形并留 12% 安全区，避免被系统圆角裁掉。
- **应用内**：新增 `BrandMarkIcon`（fill 型，与现有描边图标集不同族），
  替换登录页与初始化页品牌位的占位 `MailboxIcon`；后者已无引用，一并删除。

图标色 `#2563eb` 与门户 Dashy 主题主色一致。

# 验证

- 前端 typecheck 与 196 项测试全绿；`npm run build` 产物含三个图标文件
- Gateway 重新部署后 `/assets/{agentmail.svg,favicon.ico,apple-touch-icon.png}`
  在本机与 `192.168.2.60:8180` 都返回 200，Content-Type 正确
- 所有 PNG/ICO 用 Pillow 复核尺寸与 alpha 边界（合成失败会表现为全透明，
  已用 getbbox 排除）
 2026-09-11 15:49:41 +08:00
JianFeeeee
f9d757b5e5 chore: directory migration - gateway→server, web→client/electron 2026-09-08 19:16:35 +08:00