JianFeeeee
13b557a742
## 一、真 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`。
58 lines
5.4 KiB
Plaintext
58 lines
5.4 KiB
Plaintext
# 变异体基线的**自证底本**：每个被变异过的文件在此记下"未变异"时的 sha256。
|
||
# 跑完变异后 `sha256sum -c baseline.sha` 必须全 OK（summary.py 把结果打进 RESULT 行）。
|
||
#
|
||
# 取基线是**有意的动作**，不是随手重算 —— 重算会把"某次变异没还原"永久掩盖掉。
|
||
# 每次重算都要在此记一行"为什么"：
|
||
# 2026-09-15 11:22 dsh：`AdminUsersPage.ets` 的哈希变了，**不是变异残留**。
|
||
# 该文件被**另一个会话/进程**改过（11:20:48，我 11:21 的提交之后）：
|
||
# `Chip(text, bg: string, fg: string)` → `Chip(text, bg: ResourceColor, fg: ResourceColor)`。
|
||
# 核实过是**正确的 ArkTS 修法**（`Theme.surfaceMuted`/`textSubtle` 是 `Resource`，
|
||
# `Theme.chipNeutralBg` 是 `string` ⇒ 旧签名编译不过）。我没有提交也没有回退它。
|
||
#
|
||
# 2026-09-15 11:50 dsh：三个文件漂移，全部核实为**有意改动、不是变异残留**：
|
||
# · `model/Appearance.ts` + `pages/MainPage.ets`：**我自己**按 pi 的裁定把方案 (b) 落地成 (a)
|
||
# （删 `navMaterialFor` 与 `NAV_MATERIAL_OF`、导航条改回 `Theme.navMaterial`、
|
||
# 重写那段"注释说 (a)、代码是 (b)"的自相矛盾注释）。
|
||
# · `api/ApiClient.ets`：**别的会话**的提交 `69c2059`（JianFeeeee，11:43:22，
|
||
# 推送客户端契约层）动过它；当前内容与 HEAD 逐字节相同（`git diff HEAD` 空）。
|
||
# 复核"是不是变异残留"的方法：`git diff HEAD -- <文件>` + 上面这些记录。
|
||
#
|
||
# 2026-09-18 dsh：三个文件漂移，**已逐个核实是提交态、不是变异残留**（重算前的前提）：
|
||
# · `AdminUsersPage.ets`、`SettingsPage.ets`：提交 `1be8318`（09-17 21:15，
|
||
# "底栏黑带 / 联系人点不开"那批）改过；`git diff --quiet HEAD` 为空 ⇒ 与 HEAD 逐字节相同。
|
||
# · `ApiClient.ets`：提交 `fce5b91`（09-15 15:15，"鸿蒙客户端连不上服务器"）改过；同上。
|
||
# ★ 为什么必须先证这一步：底本**过期**与**变异残留**在 `sha256sum -c` 眼里一模一样，
|
||
# 而重算会把真正的残留**永久掩盖** —— 所以"重算"必须是一次**有记录**的动作。
|
||
# ★ 顺带修了播报：原来一律打"有文件没还原"（指向最危险的结论），
|
||
# 而真因只是底本没跟上提交 ⇒ 现在两种分开报，并各自给出判别方法。
|
||
#
|
||
# 2026-09-19 13:0x dsh：四个文件漂移，**已逐个核实是提交态、不是变异残留**（重算前的前提）：
|
||
# · `pages/AdminUsersPage.ets`：提交 `6693e96`（09-18 11:47，"登录页那个 emoji 是 Unicode…"）
|
||
# · `common/BackgroundPicker.ets`、`pages/SettingsPage.ets`：提交 `7e1120a`
|
||
# （09-19 12:30，"顶栏不再自己铺白条 + 日历改左右两栏…"）
|
||
# · `api/ApiClient.ets`：提交 `7e10bfa`（09-18 12:55，"鸿蒙日历补 .ics 导入导出"）
|
||
# 四个都 `git diff --quiet HEAD -- <f>` ⇒ **与 HEAD 逐字节相同** ⇒ 底本过期，不是残留。
|
||
# ★ 为什么必须逐个证这一步：底本**过期**与**变异残留**在 `sha256sum -c` 眼里一模一样，
|
||
# 而重算会把真正的残留**永久掩盖** —— 所以"重算"必须是一次**有记录**的动作。
|
||
# ⚠️ 这次漂移正是 `baseline-stale`（rc=0、只提示）那一档的又一次实例：
|
||
# 它**不假红**（正常提交不会天天红），但也**不会被自动发现** ——
|
||
# 我是靠"核每个文件的登记/实际读数"这条主动核查撞上的，不是它自己报的。
|
||
#
|
||
# 2026-09-19 18:2x baseline 重算（**先核过不是残留，才重算的**）：
|
||
# ① `pages/AdminUsersPage.ets`、`pages/SettingsPage.ets` —— 我本次的**有意编辑**：
|
||
# 给所有"压在彩色底上的字/图标"换前景色（`Theme.surface` → `Theme.accentFg`），
|
||
# 并把品牌蓝前景接入 `Theme.accentFor()`（深色下提亮到 WebUI 的 `--c-blue-600`）。
|
||
# ② `api/AppearanceApi.ets` —— **与 HEAD 逐字节相同**（`git diff --quiet HEAD` 为空），
|
||
# 但底本哈希对不上 ⇒ 说明它在底本取完之后被**合法改过**（提交 `3b5cc63`，
|
||
# 09-19 那次"外观保存 400"的修：`payloadFromLocal` 改用 `AppearancePayload`）。
|
||
# ⇒ 这是 `stale`（底本过期），不是 `residue`（变异残留）。
|
||
# ★ 三个都逐个跑过 `git diff --quiet HEAD -- <f>` 取证，没有一个是"改动忘了还原"。
|
||
# ★ 这正是这份文件里那条纪律的第 3 次执行："重算必须是一次有记录的动作"。
|
||
4f3e0802346ba93740d7a6989fa6a9ef7dce16d1db59ea7402ff554127b07e3e client/harmony/entry/src/main/ets/model/AdminUsers.ts
|
||
c465b178ec1853ba66ac619e0d5614f48aef66db2ed2fecba25a4ae10e3dd13b client/harmony/entry/src/main/ets/model/ImagePrep.ts
|
||
efd598149cb52400f1120f1ba4c7fb41ad9706f82005770479f571614a539e73 client/harmony/entry/src/main/ets/pages/AdminUsersPage.ets
|
||
4681c5f2d57870d64b09a10433f5ea518d777a27f6cb7ece3bbcc29c5f11012a client/harmony/entry/src/main/ets/common/BackgroundPicker.ets
|
||
3baed1fac54fef5f924c17f658ad05105b8be3ac35b110e2277b1365a84bb15a client/harmony/entry/src/main/ets/pages/SettingsPage.ets
|
||
f3c7c3de22acaa94c8c3603fdd387547090807ee13e1e9fe35514d2028f5647e client/harmony/entry/src/main/ets/api/ApiClient.ets
|
||
6550e1892d1ebea82fb75a3d2cf8eaf826186199ff4a0ecf0430b1e3517d8681 client/harmony/entry/src/main/ets/api/AppearanceApi.ets
|