跨端: 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`。

docs/ALIGN-REFS.json

@@ -24,7 +24,8 @@
       "judgement": "**按语义对齐，不按数值对齐**：两端都表示「卡片圆角」，但取值来源不同（WebUI 自定 rem，鸿蒙用**系统**资源）。数值是否一致属于形态差异，等设备上并排看再定 —— 见 docs/DEBTS.json 的 radius-card-numeric-divergence。**鸿蒙侧不许把 0.875rem/14 抄成裸数字**（那正是当初 14 处 Material 调色板被清零的同一形态，量纲从颜色换成长度）。",
       "webuiValue": "0.875rem = 14px",
       "harmonyValue": "**本工作区读不到数值**：`toolchains/id_defined.json` 里该条目只有 name/type（没有 value），SDK 的 `ets-loader/sysResource.js` 只有**资源 ID 125829709**（btn 是 125829702）—— 实体值在**系统资源包**里（编译进 resources.index / 随设备）",
-      "policy": "**策略现在就定（提案，待人追认）**：语义配对成立 ⇒ 数值按两端各自成立（WebUI 的 rem 基准 vs 鸿蒙的 vp/系统档），**默认以 WebUI 为准**；只有鸿蒙平台规范明确要求用系统档时才反向。设备**只做验证（并排看是否感知不一致）**，**不做决策** —— 这个工作区起不了模拟器，把决策挂在设备上就是一笔永远不还的账。"
+      "policy": "**语义以 WebUI 为准；数值按平台各自成立**（两端数值来源不同：WebUI 自定 rem，鸿蒙用系统档）。**不相等是对的** —— 不是\"数值待补齐\"。**追认**：pi 以 WebUI 侧负责人身份追认（2026-09-14），骨架按此执行，不必再等追认。保留的是**验证**：真机并排若看出感知不一致 ⇒ 反向并**登记成决定**（那是等设备的 env 项，与策略无关，别混成一笔）。",
+      "unitNote": "**px 与 vp 之间没有\"差值\"**：`px` 是桌面 CSS 像素，`vp` 是设备密度无关单位，两者只能通过屏幕密度 + 观看距离换算 —— 所以这里不是\"差值暂时未知\"，而是**\"差值\"在这个比较里没有定义**。**停止追这个数**：把它当待补的数，会诱使下一个人去追一个改变不了结论的数字，最后以\"抄一个 vp 进去\"收场，而那正是这笔账要防的事。"
     },
     {
       "semantic": "控件圆角",
@@ -33,7 +34,14 @@
       "judgement": "同「卡片圆角」：语义对齐、数值来源不同。",
       "webuiValue": "0.5rem = 8px",
       "harmonyValue": "同卡片圆角：本工作区只能读到资源 ID 125829702，读不到 vp 值",
-      "policy": "**策略现在就定（提案，待人追认）**：语义配对成立 ⇒ 数值按两端各自成立（WebUI 的 rem 基准 vs 鸿蒙的 vp/系统档），**默认以 WebUI 为准**；只有鸿蒙平台规范明确要求用系统档时才反向。设备**只做验证（并排看是否感知不一致）**，**不做决策** —— 这个工作区起不了模拟器，把决策挂在设备上就是一笔永远不还的账。"
+      "policy": "**语义以 WebUI 为准；数值按平台各自成立**（两端数值来源不同：WebUI 自定 rem，鸿蒙用系统档）。**不相等是对的** —— 不是\"数值待补齐\"。**追认**：pi 以 WebUI 侧负责人身份追认（2026-09-14），骨架按此执行，不必再等追认。保留的是**验证**：真机并排若看出感知不一致 ⇒ 反向并**登记成决定**（那是等设备的 env 项，与策略无关，别混成一笔）。",
+      "unitNote": "**px 与 vp 之间没有\"差值\"**：`px` 是桌面 CSS 像素，`vp` 是设备密度无关单位，两者只能通过屏幕密度 + 观看距离换算 —— 所以这里不是\"差值暂时未知\"，而是**\"差值\"在这个比较里没有定义**。**停止追这个数**：把它当待补的数，会诱使下一个人去追一个改变不了结论的数字，最后以\"抄一个 vp 进去\"收场，而那正是这笔账要防的事。"
     }
-  ]
+  ],
+  "agc": {
+    "file": "client/harmony/entry/src/main/resources/rawfile/agconnect-services.json",
+    "packageName": "com.jianf.agentmail",
+    "appId": "6917616450599975320",
+    "note": "AGC 下发的配置（加密信封格式，非明文密钥）。**包名必须与 AppScope/app.json5 的 bundleName 完全一致** —— 不一致时 Push Kit 推不到设备，这不是风格问题而是功能性约束（pi 2026-09-14 实测：AGC 拒绝 `com.agentmail.harmony`，因为 `harmony` 是包名保留字；用户定 `com.jianf.agentmail`）。"
+  }
 }

docs/DEBTS.json

@@ -10,9 +10,9 @@
   "debts": [
     {
       "id": "static-criteria",
-      "count": 5,
+      "count": 7,
       "due": "本工作区能装、能点设备（探针三值转 true 时自动变红）",
-      "where": "client/electron/test/run-all.mjs 的 STATIC_ONLY（test/harmony-nav.test.mjs、test/harmony-appearance.test.mjs、test/harmony-logic.test.mjs、test/cross-client-theme.test.mjs、test/appearance-defaults.test.mjs）",
+      "where": "client/electron/test/run-all.mjs 的 STATIC_ONLY（test/harmony-nav.test.mjs、test/harmony-appearance.test.mjs、test/harmony-logic.test.mjs、test/cross-client-theme.test.mjs、test/appearance-defaults.test.mjs、test/harmony-admin.test.mjs、test/harmony-imageprep.test.mjs）",
       "kind": "scope"
     },
     {
@@ -71,13 +71,6 @@
       "where": "client/electron/test/debt-visibility.test.mjs（词表键控的盲区：**已知未覆盖**——词表是采样、不是完备）",
       "kind": "env"
     },
-    {
-      "id": "radius-card-numeric-divergence",
-      "count": 1,
-      "kind": "scope",
-      "due": "**策略已定、只剩\"有人拍一下\"**（提案见 docs/ALIGN-REFS.json 的 radius.policy）：语义配对成立 ⇒ 数值按两端各自成立，默认**以 WebUI 为准**（除非鸿蒙平台规范要求系统档）。**设备只做验证（并排看是否感知不一致），不做决策** —— 本工作区起不了模拟器，把决策挂在设备上这笔账就永远不还。**实现者不能自己拍**（同 `unknown-preset-approval`）：追认或驳回即闭合；若真机并排看出感知不一致，则改为反向并登记成决定",
-      "where": "docs/ALIGN-REFS.json 的 radius 段（含两侧数值：WebUI 14px/8px；鸿蒙侧本工作区只能读到资源 ID 125829709 / 125829702，读不到 vp 值 —— 实体值在系统资源包里）"
-    },
     {
       "id": "redeploy-script-unguarded-steps",
       "count": 1,
@@ -105,6 +98,13 @@
       "kind": "只在 redeploy-gateway.sh 做了，另两个部署脚本没做",
       "due": "下一次动 redeploy-plugin.sh / install.sh 时",
       "where": "只有 redeploy-gateway.sh 有 INT/TERM/HUP trap；install.sh 与 redeploy-plugin.sh 在写系统目录期间被打断同样会留半成品（它们没有\"服务停着\"那种后果，所以优先级低）"
+    },
+    {
+      "id": "harmony-p4c-boundary-decls",
+      "count": 5,
+      "due": "本工作区能装、能点设备 —— 那时这几条静态判据里被替代掉的那些断言换成真机断言，声明随之减少",
+      "where": "client/electron/test/harmony-admin.test.mjs、client/electron/test/harmony-imageprep.test.mjs",
+      "kind": "scope"
     }
   ]
 }

docs/GUI-PLAN-HARMONY.md

@@ -162,7 +162,7 @@ entry/src/main/ets/
 ## 4. 里程碑与验收
 
 ### M0 脚手架（0.5 天）
-- `devecocli create` 建 Stage 工程（包名 `com.agentmail.harmony`，API 23）；
+- `devecocli create` 建 Stage 工程（包名原为 `com.agentmail.harmony`，**2026-09-14 已改为 `com.jianf.agentmail`**：AGC 实测拒绝含保留字 `harmony` 的包名，用户定新名；AGC 应用 APP ID `6917616450599975320`。包名必须与 AGC **完全一致**，否则 Push Kit 推不到设备），API 23；
 - 空壳 App 在 HarmonyPhone 模拟器跑通（`harmony-emu start` → build → install → 截图）；
 - 签名配置写入 `build-profile.json5`（复用 `~/.ohos/config` 材料）。
 

docs/HARMONY-ALIGN-PLAN.md

@@ -586,9 +586,9 @@ deb 也不必从 targets 里摘。已写进 `client/electron/BUILD.md`（含排
 | 维度 | WebUI | 鸿蒙 | 为什么允许不同 |
 |---|---|---|---|
 | 圆角 | 自声明 `--radius-card: 0.875rem` | 系统 `sys.float.ohos_id_corner_radius_card/button` | 系统圆角会随设备/主题/无障碍设置变；跟着系统才是"系统方案" |
-| 材质（玻璃） | 自声明 `--nav-bg: 255 255 255 / 0.72` + `backdrop-filter` | 系统 `backgroundBlurStyle(BlurStyle.COMPONENT_THICK)` | 系统材质自带深浅两套颜色与模糊半径，手写 alpha 跟不了深色 |
+| 材质（玻璃） | 自声明 `--nav-bg: 255 255 255 / 0.72` + `backdrop-filter: blur(18px)` | 系统 `backgroundBlurStyle(Theme.navMaterial)`（`COMPONENT_THICK`）；**档位经 `navMaterialFor(bg_blur)`、有下限（永不 NONE）** | 系统材质自带深浅两套颜色与模糊半径，手写 alpha 跟不了深色。**导航条档位跟随用户模糊偏好**（0 px ⇒ 最薄档，不是 NONE）—— 这是**有意差异**：WebUI 的 `.narrow-nav` 是硬编码 18px、不读 `--bg-blur`；这里跟随是为了让用户那个滑杆**真的有用**（否则它在导航条上就是死控件）。下限由 `navMaterialFor` 保证，判据钉「可达输入上不许 NONE，且三档都要出现」。 |
 | **未知预设 id（版本偏移）** | WebUI/服务端先加第 7 档、鸿蒙还是旧构建 ⇒ 旧端认不出新 id | 按缺省语义**静默替换为 aurora**（`normalizePreset`） | **这不是 bug，是批准的缺省语义的可见后果**：用户以为选的是新档，实际看到的是 aurora。方向是"宽（静默）"——不会看到错误，但会看到**别人的档**。行为判据用"不存在的 id 当哨兵"正好钉住这条（`harmony-presets.test.mjs`） |
-| **壁纸模糊度** | 用户的 `bg_blur`（**像素半径**，初值 4px）作用在壁纸图层上（`filter: blur(var(--bg-blur))`） | **已消费**（P4c，2026-09-15）：壁纸层 `.blur(bgPlan.blurPx)` = **图片内容模糊**（与 WebUI 同一个量与同一个数）；导航条 `backgroundBlurStyle(BLUR_STYLE_OF[blurStyleFor(blurPx)])` = **面板材质**（映射表 `model/Appearance.ts` 的 `blurStyleFor`，分档 0/8/20 有行为判据；档位名 → `BlurStyle` 的四行表在 `MainPage.ets`） | **两种模糊不是同一件事**（核实自 `client/electron/src/index.css`：`.app-backdrop` 的 `filter` 是图片本身糊，它**之上**的面的 `backdrop-filter` 才是背后糊）—— 所以「壁纸糊一次 + 导航条材质一次」**不是**「同一张底糊两遍」。原来那条判据把两者混为一谈，已于同一天修正为「壁纸层只许图片内容模糊、面板材质只许出现在背后是可变内容的层」。**本条已按原承诺更新**（原文写着：若将来鸿蒙开始消费它，那时必须补一条映射判据并更新本行）。消费侧登记表已从 0 改准（`harmony-appearance.test.mjs`，逐文件 + 计数 + 理由）。 |
+| **壁纸模糊度** | 用户的 `bg_blur`（**像素半径**，初值 4px）作用在壁纸图层上（`filter: blur(var(--bg-blur))`） | **图片内容模糊已消费**（P4c）：壁纸层 `.blur(bgPlan.blurPx)` —— 与 WebUI **同一个物理量、同一个数**，所以这一处**不需要也不该有**映射表。另有一个**面板材质**的档位映射：`navMaterialFor(bg_blur)`（有下限）喂 `backgroundBlurStyle`，见上一行。 | **两种模糊不是同一件事**（核实自 `client/electron/src/index.css:677` 的 `.app-backdrop{filter:blur(var(--bg-blur))}` 与 `:772`/`:1114` 的 `backdrop-filter`：一个是**图片本身糊**、一个是**背后内容糊**；`index.css:266-267` 的 `--bg-blur-panel` 注释把「这是两个量」写进了令牌名）。所以「壁纸糊一次 + 导航条材质一次」**不是**「同一张底糊两遍」—— 原判据（壁纸层不许有**任何**模糊）把两者混为一谈，已修正为按两种模糊分别钉。`model/Appearance.ts` 的 `blurStyleFor`（**材质档**映射）此前是「有映射表、无调用点」，现在**有调用点**了：`navMaterialFor` 内部复用它，并把它返回的 `NONE` 抬成最薄档（所以「导航条可以是 NONE」这个洞被堵在**入口**上，而不是靠调用方记得判断）。 |
 | 动效 | 自定义 transition/时长 | `animateTo` + 系统 `curves` | 动效曲线应跟随系统设置（含"减弱动效"） |
 | 遮罩 | 自声明 `--bg-scrim` + `--bg-dim` 两段式 | 系统 `sys.color.ohos_id_color_mask_regular` | 遮罩要随主题换向（浅色洗白/深色压黑），这件事系统已经做了 |
 | **品牌色** | `--c-blue-600: 37 99 235` | `Theme.accent = '#2563EB'` | **不允许差异** —— 两个客户端是同一个产品 |