1da4e15a7b03bab392637d81e01eeaaa8b744424
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 1da4e15a7b |
跨端: 补齐「我的」页深色可读性（4 页 219 段全 ≥3:1）+ 判据自己漏报的那一类
上一条把通信/日历/联系扫干净了，但**「我的」页没扫到**
（扫描脚本按文案点不到它 —— 那是侧栏**底部的头像按钮**，不是导航项）。
补上后立刻又抓出问题，并把判据自身的**漏报形状**一并修了。
## 一、「我的」页两处真 bug
1. **主题分段按钮 `SettingsPage.ets:834`**：
`.fontColor(... ? Theme.surface : Theme.textPrimary)` —— `surface` 是
**会翻转的面色**，压在 `Theme.accent` 蓝底上，深色下变成近黑。
设备读数：`深色 2.93:1 ink rgb(32,34,36) bg rgb(34,96,228)`。
2. **权限档徽标 `MailDetailPage.ets:391`**：同一个错法（第 13 处）。
3. **账号名 `SettingsPage.ets:1179`**：三元里的裸 `Theme.accent`
压在 `accentSoftFor()` 底上 ⇒ `jianf 2.83:1`。
`AdminUsersPage.ets:386` 同形状（角色徽标）。
## 二、判据自己的漏报形状（比 bug 本身更值得记）
静态防线（`C｜会翻转的 Resource 不得当前景色`）**在 bug 存在时是绿的**。
原因是它的提取正则：
/\.fontColor\(Theme\.([A-Za-z0-9_]+)\)/ ← 要求令牌是**唯一实参**
于是**三元里的令牌全被漏掉**：
.fontColor(this.appearanceTheme === t ? Theme.surface : Theme.textPrimary)
改成"在 `fontColor(` 之后的整段实参里找所有 `Theme.X`"之后，
它**立刻报出上面第 1、2 两处**（此前一直绿）。
★ **判据漏报的常见形状是它自己的正则太窄，而不是被测代码太隐蔽。**
这条写成注释留在判据里了。
## 三、我自己犯的批量替换错误（已加判据钉住）
把裸 `Theme.accent` 换成 `accentFor()` 时，**误把 6 处 `backgroundColor` 也换了**。
`accentFor()` 深色给浅蓝 `#80AFF9`，而搭档前景是白色 `accentFg`
⇒ 白字压浅蓝 ≈ **1.4:1**，主按钮文字会彻底看不见。
- 6 处已逐处还原（复核：`grep -c "backgroundColor(Theme.accentFor())"` = 0）。
- 新增判据 **`C2`**：`accentFor / dangerFor / approveFor / warnFgFor / textSubtleFor`
**只能用于前景**，`backgroundColor(Theme.XFor(...))` 直接判红。
（`accentSoftFor` 是例外 —— 它本来就是"面"。）
★ 修法不是"下次小心点"：批量替换一定会再犯，**一行判据把它变成不可能**。
## 四、设备复扫（修后）
```
[通信] 扫 42 段，低对比 0
[日历] 扫 85 段，低对比 0
[联系人] 扫 51 段，低对比 0
[我的] 扫 41 段，低对比 0 ← 新增
```
**219 段文字全部 ≥3:1**（本轮全部针对深色）。
## 五、底本
`baseline.sha` 第 5 次重算。重算前**专门复核**了"那 6 处误改有没有残留"
（不只看 `git diff` 非空就放行）：`backgroundColor(accentFor)` 计数为 0、
`git diff HEAD~1` 里 backgroundColor 只有 calendar 那一处（有意改动）。
`run-all.mjs` → `checks=515 pass=515 fail=0 skip=0 red=0 broken=0 unreported=0`。
**未验**：浅色主题下的对比度没扫（本轮全部针对深色）。
|
|||
| 4ecddfc2b6 |
跨端: 语义色/三级文字在深色下没提亮（设备扫出 12 处）+ 判据取样法修到第三版
## 一、判据基建先修对，否则是在听噪声
深色可读性扫描的**取样法迭代了三版**，每版都因为**假红**才改的
（记在这里，因为"判据自己错"比"界面错"更费时间）：
1. **取中心一个像素** ⇒ 落在笔画之间、读到的是底色 ⇒ 一片 ratio=1.00 假红。
2. **取全局最暗/最亮** ⇒ 会采到**两个不同的东西**：细字的抗锯齿中间色。
实例：segmented「日」报 ink `rgb(32,34,35)` / bg `rgb(98,100,101)` 2.69:1 ——
而截图里它要么蓝底白字、要么深底浅字，两种都远高于 3:1。
**反复核对才确认是判据的错，不是界面的错。**
3. **步长采样 + 众数** ⇒ 仍然假红：周表头「一」报 2.03:1，
而逐像素的真实墨是 `rgb(166,167,167)`（**6.6:1**）——
稀疏网格**整个跳过了笔画**。这不是调参能修好的（字越小越糟）。
4. **逐像素 + 众数=底 + 离底最远者=墨**（最终版）。
理由：一个文字框里**面积最大的一定是底**，而"离底色最远"就是笔画最实那部分。
⚠️ 逐像素是**负担得起的**（整屏已解码在内存，一个框最多 9 万像素）——
**不要再为了省开销退回抽样**，前两版都因此假红。
## 二、真 bug 三批（都是"深色下没提亮"）
### ① 语义色前景（12 处 → 修完设备复扫 0）
WebUI 的语义色也是**双通道**，`.dark` 段把 `red/green/amber-700` 换成浅色
（`248/118/249 → 164/219/195` 那组）。鸿蒙只有一个深色值：
- 「归档」按钮 `Theme.danger` #B91C1C 压深面 ⇒ **2.47:1**（联系人页 7 处）
- 「今天」/「日」等 ⇒ **2.38–2.77:1**
加 `dangerDark/approveDark/warnFgDark`（逐字对齐 WebUI `.dark`）
+ `dangerFor()/approveFor()/warnFgFor()` 入口，22 处接入。
### ② 日历工具条整块配色抄错（不是"深色档选错"）
对照 WebUI `CalendarView.tsx:313-331`：
| 元素 | WebUI | 鸿蒙（改前） |
|---|---|---|
| 「今天」 | `border-gray-300` + `text-gray-700`（**中性**） | `accentSoft` 底 + `accentStrong` 字 |
| 月/周/日 未选中 | `bg-white` + `text-gray-700` | `accentSoft` 底 |
鸿蒙把**次要的中性按钮**画成了**品牌色按钮** —— 视觉重量跟主操作一样，
三个档看起来"都像选中"。已按 WebUI 改成中性。
### ③ 三级文字在深色下 2.82:1（**71 处**，全局最大的一个）
WebUI 的 `.dark` 段注释逐字写着这个坑：
> 「`gray-400/500`（次要文字）→ **提亮**。深底上的浅色 gray-400
> 只有约 2:1 对比度，远低于 WCAG AA 的 4.5:1 —— **看得见但读不动**。」
鸿蒙用的系统三级色 `ohos_id_color_text_tertiary` 深色下是 `rgb(102,103,105)`
压深面 **2.82–3.05:1**，而它被用在 10–11px 的**小字**上
（时间戳、农历、空态、辅助说明）。
**不换掉系统令牌**（"系统拥有的维度"纪律照旧），加 `textSubtleFor()`：
深色下改用二级色（实测 `rgb(166,167,167)` ≈ 7.15:1，
且与 WebUI 的 `gray-500` 同档位）。71 处接入。
**设备复扫（修后）**：通信/日历/联系三页 **176 段文字全部 ≥3:1**。
## 三、欠账与底本
- `baseline.sha` 第 4 次重算。仍**先逐个取证**：
`git diff --quiet HEAD -- <f> && echo STALE || echo INTENTIONAL`
⇒ 三个全是 `INTENTIONAL`（我改的），不是变异残留。
把这条取证命令也写进文件，下次照抄。
- `dangerDark/approveDark/warnFgDark` 已登记进 `SELF_OWNED_COLORS`
+ `Theme.ets` 登记表（各带理由与 WebUI 出处）。
`run-all.mjs` → `checks=514 pass=514 fail=0 skip=0 red=0 broken=0 unreported=0`。
**未验**：①「我的」页（底部头像按钮，扫描脚本没找到入口）没扫；
② 浅色下的对比度没扫（本轮全部针对深色）。
|
|||
| 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`。 |
|||
| e8b260dd70 |
维护: 底本重算（4 个文件漂移 = **底本过期**，不是变异残留）—— 逐个核实后按本文件的协议记一行"为什么"
pi `df62ad3d` 那封的 §四 我复核后**已经在 `d07494e` 修好了**（父提交正是 pi 报信时的 HEAD `93dabb4`）：`if (r.red) reds.push(r.red)` + `DIAG[*].blocksGreen` 让 `summary.py` 的 status 真的进了 `verdict`。同刻 A/B（只切 baseline 一个变量）实测： 残留态红清单 diff **恰好 +1 行**（`（summary.py）baseline-residue ——…`），`red` 10→11； stale 态 diff **0 行**。⇒ "stale ⇒ 提示(0) / residue ⇒ 红(进 verdict)" 这条口径成立。 这轮顺手核"每个文件的登记/实际读数"时，撞上底本自己的状态： `baseline=3/7（底本过期…）`。逐文件核过 —— 4 个漂移**全部**是 `git diff --quiet HEAD -- <f>` 为空的**提交态**（各自有明确的提交）： · AdminUsersPage.ets ← |
|||
| 590a72a715 |
修复: job 集合从 glob 改成**清单**（+ 清单外即报，与 SUITE 同形状）+ RESULT 行带集合指纹；baseline 播报区分"底本过期"与"变异残留"；权限政策补上**目录可进入性**（原来只管文件）
pi 2026-09-18 报的三件，逐条实测后处置。
## 一、job 集合是 glob ⇒ "权威"是**树的函数**（同一段代码两个数）
pi 独立复算对上了（48/48/0、A=36/B=41 与我一致），但发现 48 与 52 **都不是错的** ——
它们读的是**不同的集合**，而**没有任何东西说明读的是哪个**：
| 快照 | job 文件 | 输出 |
|---|---|---|
| 提交态 | 9 个（全跟踪） | `mutants=48 …` |
| 工作树 | 11 个（2 个未跟踪） | `mutants=52 …` |
真因：`glob(JOBS_DIR + '/jobs*.json')` ⇒ **未跟踪的 job 文件静默进入统计**。
这与"写了判据忘了接线"同族，区别是 `run-all.mjs` 有**自检 2** 挡着（清单外的 `*.test.mjs` 直接红），
这边没有对等物。**本仓用"清单 + 清单外即红"解决过同一个问题两次，这是第三次。**
**处置（pi 建议的前者）**：新增 `jobs.manifest.json` 显式列 job 集合，`summary.py` 只读清单；
清单与磁盘不一致时**明说**（两个方向都报：未列入清单 / 清单里有但磁盘没有），
并声明"上面的数字**不代表磁盘上现在有多少个变异体**"。
**另加集合指纹**（pi 建议的后者，两条都做了）：`sha=…` —— 让"48 还是 52"变成可判的：
集合没变而数变了 ⇒ 真算错；集合变了 ⇒ 一眼看出是换了快照，不必再互相复算一遍。
**变异验证**（两个方向都试）：
```
加一个未列入清单的 job 文件 ⇒ 报「未列入清单：jobs-UNLISTED-probe.json」
且 mutants=**48**（未被静默计入）✓
清单里加个不存在的文件 ⇒ 报「清单里有、磁盘上没有：jobs-GHOST.json」✓
```
（`_` 开头的条目是说明，读时滤掉 —— 否则会被当成文件名，`ghosts` 假报一堆。）
## 二、`baseline=4/7✗**有文件没还原**` 是**假警报指向最危险的结论**
实测三个不匹配的文件 **全部与 HEAD 逐字节相同**（`git diff --quiet HEAD` 为空）：
`AdminUsersPage.ets`/`SettingsPage.ets` 是提交 `6861934`（09-17 21:15）改的、
`ApiClient.ets` 是 `9c6e9c6` 改的 ⇒ **底本过期，不是变异残留**。
★ 而原来一律打"✗**有文件没还原**" —— 那会让人去翻变异，而真因只是底本没跟上提交。
**两种成因在 `sha256sum -c` 眼里一模一样**，所以播报必须分开，并各给判别方法：
```
baseline=4/7⚠**底本过期**（3 个文件与 HEAD 逐字节相同 ⇒ 是正常提交改过、不是变异残留）
```
**底本已重算**，并按要求在文件里记一行"为什么"（含"重算前必须先证是提交态"这个前提）。
**重算后仍在校验**（变异验证）：给 `AppearanceApi.ets` 追加一行 ⇒ 立刻 `FAILED`；还原 ⇒ `7/7 OK`。
## 三、`summary.py` 对非 root 是坏的：`jobs/` 缺 `x` 位
```
drw-r--r-- client/electron/test/mutants/jobs ← 缺 x
$ runuser -u nobody -- python3 …/summary.py
PermissionError: [Errno 13] Permission denied: '…/jobs/jobs-all.json'
```
⇒ 那份"口径的唯一权威"**只有 root 跑得起来**。已 `chmod 755`，非 root 复跑输出一致。
★ pi 的深层判断成立且我核实了：**这条落在任何判据的射程之外** ——
`deploy/check-file-modes.sh` 的政策是"**源文件**不得比 0644 更严"，
而它遍历的是 `git ls-files`，**只看文件**；"目录缺 x"比"文件 0644 更严"更严重
（连 `stat` 都进不去）。
⇒ **给该政策补上"目录可进入性"**（只判 `u+x`、只判"仓库内容所在的目录"，
不去管 node_modules/dist —— 那会把这判据淹掉；也不判 group/other —— 那取决于本机 umask）。
**★ 我第一版这里又写错了，而且错得正好是被测的那个病**：
用 `[ -x "$d" ]` 判可进入 ⇒ **恒为真**，因为 **root 无视权限位**（`test -x` 对 uid=0 永远返回 0），
于是变异验证"撤掉 x"**根本不触发**，而**输出看起来完全正常**。
⇒ 改成**直接读权限位**（与同文件里文件那段的位运算同一做法）。
改后变异验证：撤 x ⇒ `[FAIL] 目录不可进入：…（drw-r--r--，缺属主 x 位）`、退出码 1；还原 ⇒ 0。
## 四、顺带修好三处既有权限违规（`check-file-modes.sh` 原来一直红着）
```
.githooks/pre-push 711 ⇒ 755（保留执行位，**不是**去掉）
test/harmony-arkts.test.mjs 600 ⇒ 644
model/DeviceProbe.ts 600 ⇒ 644
```
三者都是**提交态**就这样（不是并发会话弄的）。按脚本自己的"药方按类型分岔"修的。
现在该政策 **退出码 0**。★ git **不存** 600/644 的区别（只记 exec 位）⇒ 这三处是**本地状态**修复，
不随提交走，新克隆不受影响 —— 与 pi 对目录权限的说明同一条。
## 五、pi 报的另两件：**在 HEAD 上已经不存在了**（是过时读数）
- **ArkTS 两处阻断**：`MainPage.ets` 的 import 现在在 71-74 行、最后一个 `const` 在 88 行
⇒ **位置正确**；`AdminUsersPage.ets` 的 `Chip` 签名已是 `ResourceColor`（`:410`）
⇒ 两处**都已在 HEAD 修好并提交**（工作树 `client/harmony/` 干净）。`harmony-arkts` 判据 3/3 绿。
- **套件现状**：现在 **29** 个判据文件（不是 23），`unreported=0 broken=0`。
## 六、测量
| 相位 | RESULT |
|---|---|
| build | `files=29 ran=29 checks=456 pass=453 fail=3 red=9 broken=0 unreported=0` |
| install | `files=29 ran=27 checks=444 pass=442 fail=2 red=8 broken=0 unreported=0` |
三种 cwd 仍逐字节一致（上一轮的修复保持）。
|
|||
| 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 已在别处跑过，绿。
|
|||
| bcd4f97e37 |
跨端: 变异体计数收进仓库 —— 前面报过 40/48/58 四个数，根因是"job 集合"从没定义
pi 用 `/tmp/mut/` 复算后指出：48 也不对。他是对的，而且**不是记性问题、是口径问题**——
我把 9 个 `jobs*.json` 的条目**直接相加**，没做归一：同一个变异体在跨批重锚时被键了多次
（13 组重复、15 条冗余），最典型的是「计划不搬运模糊值」同时挂在 `jobs-b3`/`jobs-blur`/`jobs-blur2`
三个文件、三个不同 `test` 键上 —— 于是"按判据文件分组求和"必然把它算三次，
而"跑在新增判据上的是多少"在交叉归类下**没有唯一答案**（41 或 35）。
更根本的是 pi 指出的第二层：**那个统计脚本根本不在 `/tmp/mut/` 里**（他为了复算是现写的），
而且 `/tmp` 会被清、不在仓库里 ⇒ 变异体数字**只活在信里**。
这一路已经立过同形状的规则（余额打在 `RESULT` 行、权威源在文件里），这条当时漏了。
## 做了什么
- `client/electron/test/mutants/`：把 `mut.py`、`run.sh`、`jobs*.json`、`baseline.sha`
从 `/tmp` 挪进仓库（`/tmp` 会清、复核方够不着）。
- `mutants/summary.py`：**口径的唯一权威**，定义写死在代码里：
· 不同变异体 = 按 (file, pat, repl) 去重（`retired` 不计）；
· 跑起来 = 锚点在该文件里**恰好命中 1 次**（与 mut.py 同一条件）；
· `on_new_criteria` = 该变异体的**每一个** test 键都指向本批新增的两个判据文件
（口径 A —— 不因交叉归类虚高；另报口径 B 作参考，它只增不减，不拿来报数）。
- `run-all.mjs` 的 `RESULT` 行播报它，并**顺带自证基线**：跑不起 `summary.py` 时
**不静默**（打印 status 与 stderr 末行）——我第一版路径写错，只看到"计数未知"，
真因（`can't open file …/test/test/mutants/summary.py`）被吞掉了。
- `mutants/test-keys.json`：`test` 键 → 判据文件的**唯一来源**（`mut.py` 与 `summary.py`
共用）。此前两处各写一份，分叉过一次：键名从旧名换成 API 名后 `summary.py` 那份没跟上，
于是所有锚点被判 `hits=-1`、报出"51 个变异体全部 skipped"。
- 无歧义口径下的**当前真值**：`mutants=48 ran=48 skipped=0 on_new_criteria=36 baseline=7/7✓`
（口径 B = 41；原始条目 66，其中 `retired` 5）。
- 清掉 pi 指出的三类脏数据：
· **过期条目**（锚点是修复前的旧写法，`hits=0`）标 `retired` 5 条 ——
它们**不是"没跑成的变异体"**，重锚后都跑过、都红了；留着只会把 skipped 一直抬高；
· **重复计数**（multipart 那条在两个文件里各一次）去重；
· **真 skip** 的 multipart 锚点切片成 `name: 'file',\n contentType: mimeType` ⇒ 真的跑起来了
（此前命中 2 次，因为 `ApiClient.ets` 有两个 multipart 构造器）。
- 修两处并发/竞争：`mut.py` 的 `tempfile.mktemp()`（Py3 起 deprecated，**TOCTOU**）→ `mkstemp`；
`run.sh` 的固定 `/tmp/mut/bak` → 按 `$$-$RANDOM` 唯一（并行跑会互相覆盖备份）。
## 未做（如实说）
- **`AdminUsersPage.ets` 有一处不是我做的改动留在工作树里**（11:20:48，我 11:21 的提交之后）：
`Chip(text, bg, fg: string)` → `ResourceColor`。核实过是**正确的 ArkTS 修法**
（`Theme.surfaceMuted`/`textSubtle` 是 `Resource`、`chipNeutralBg` 是 `string`，
第 368 行的三目因此是 `Resource | string` ⇒ 旧签名**编译不过**）。
我**没有提交也没有回退**它 —— 工作树是共享的，不该替别人提交别人的活。
基线因此重算了（`baseline.sha` 顶部记了原因与哈希来源，重算本身是**有意动作**：
随手重算会把"某次变异没还原"永久掩盖掉）。
- Go 侧 `debt_registry_test.go` 仍未跑（沙箱无 Go 模块缓存），只做了 `gofmt`。
|
