按 pi 复核改五处：判据的"值/行为"原则、真正的构建门、typecheck 进门、Go 判据零匹配、迁移归属

pi 用反例与变异逐条点了五处，全部**先跑变异再改**（结论都写在原地）。 ## 1 判据③：形状正则已删（它永远差一个反例）实测 pi 的反例 —— `const k = PREFIX + accountId; return PREFIX;`（拼了但没返回）—— 对第三版判据**仍然全绿**：第三版锚的是"**函数体里存在**这样的表达式"，不是"**返回的**表达式"。三版的骗法各一个（签名里的参数 / 提了一下没用 / 拼了没返回），都在判"源码里有没有那个形状"，而缺陷是"算出来的值对不对" ⇒ **权威交给行为判据**（`test/stores/background.test.ts` 直接断言 `storageKey('a') !== storageKey('b')`、`=== 'agentmail.background.acct-a'`、不退回全局键），正则那条删掉并把反例写在原地（否则下一个人会好心加回来）。保留"键必须来自 storageKey()"那条：那是**来源**约束，不是值对不对，正则在这里合适。鸿蒙侧只能静态判（`.ets` 本机没有运行时），已把这条限制写进判据说明。推广进规范：CRITERIA.md §6.7 + run-all 自检关键词（10 → 11）。 ## 2 真正的门：`scripts/release-linux.sh` - 实测 pi 提的变异：**`touch dist/index.html` 时 stamp 判据是绿的** —— 它抓不到"构建失败但碰过 dist"。 stamp 是**探测器**（抓"src 改了产物没跟上"），门是**喂退出码**，两者不互替（§6.7.1）。 - `build:linux` 里**没有管道**（`&&` 链，退出码本来就传），但那次的哑巴失败是我在命令行手打 `npm run build 2>&1 | tail -4 && …` 造成的；同时发现它跑的是**裸 `vite build`，跳过 `gen:bg`**。 - 于是把配方收成 `scripts/release-linux.sh`：`set -euo pipefail` + 走 `npm run build` + 再打包。 - 判据是**行为**的：注入失败的构建（`AGENTMAIL_BUILD_CMD='exit 7'`）→ 断言退出码非 0 **且打包那步没跑**（标记文件不存在）。变异：脚本改成 `|| true` → 红 ✓。 ## 3 typecheck 进 `npm test` 链 `npm run typecheck` 原本就有，但没人跑。先修掉它唯一的报错（我自己留下的未使用 import），现在干净； `test` = run-all + vitest + typecheck。它恰好检查**没被任何测试 import 的文件**（vitest 只解析被测到的图）—— 也就是那次 `is not exported by` 的形状。 ## 4 Go 源码判据：零匹配 / 读不懂都要红改成三分：切不出函数体 → 红；字段在但值不是字面量 → 报「**判据读不懂**」（变异：`BgDim: defaultDim` → 红 ✓）；字段不在 → 红。静默放行是这类判据最危险的失败方式。 **措辞更正**：这条核对的是"与**这份服务端源码**的契约"，不是"在跑的服务端二进制是 12/4" （与"dist 是产物"同构）；文档同步改。 ## 5 迁移归属：定向做不到，就把"不可恢复"降级成"可恢复" 查实：`accountStore` 的 `activeId` 是**派生视图状态、不落盘**（`persist(accounts)` 只存数组），所以**本机没有"上次活跃账号"标记可定向** —— 旧值的作者事后无法还原，定向迁移在原理上做不到。升级前用 B、升级后先登录 A ⇒ A 接管 B 的外观，**一次性错档**，触发条件就这一条。两件能做的都做了：**写了回读校验**（写不进去就不删旧键，避免净损失；变异：改成先删后写 → 2 条红 ✓）、 **删前另存** `agentmail.background.legacy.bak`（只写不读 ⇒ 不引入新的继承源，判据钉"只写不读"）。 §7.12 把本地这半与显形方式写进同一行。 ## 验证 `npm test` 退出码 0：14 个判据文件全绿 + vitest **265** 通过（+2 迁移行为测试）+ typecheck 干净； `hvigorw assembleHap` BUILD SUCCESSFUL；安装包经新脚本重打（dist 与包同批）。
2026-09-14 15:41:52 +08:00
parent 483f4ed960
commit 71a3c35610
10 changed files with 287 additions and 34 deletions
--- a/client/electron/test/appearance-defaults.test.mjs
+++ b/client/electron/test/appearance-defaults.test.mjs
@ -4,7 +4,10 @@
 // 为什么值得单独一个判据文件：
 //   1. 服务端 `DefaultAppearance()` 的注释宣称"与客户端 backgroundStore / themeStore 的
 //      默认值一致" —— 在 WebUI 用 24/8 时那句话**是假的**（pi 2026-09-14 更正了自己
-//      上一封"数值是审美"的说法：它是契约问题）。这条判据把那句注释变成**可核对**的。
+//      上一封"数值是审美"的说法：它是契约问题）。
+//      **措辞要准**（pi 同封指出）：这条判据核对的是"**与这份服务端源码的契约一致**"，
+//      **不是**"在跑的那个服务端二进制是 12/4" —— 与"dist 是产物、源码修好≠用户手上的包修好"
+//      同构。若服务端由别的流水线构建部署，这条判据对运行时**没有**发言权。
 //   2. 默认值决定"新账号的初始外观"：服务端"没有记录"时客户端以本地为准推上去，
 //      于是**谁先同步谁决定**。24/8 与 12/4 的差别不是审美，是同一个账号在不同客户端
 //      登录会得到不同的压暗强度。
@ -34,12 +37,27 @@ function serverDefaults() {
    else if (src[i] === '}') { depth--; if (depth === 0) { end = i; break; } }
  }
  const body = src.slice(at, end + 1);
-  const dim = /BgDim:\s*(\d+)/.exec(body);
-  const blur = /BgBlur:\s*(\d+)/.exec(body);
-  const theme = /Theme:\s*"([^"]+)"/.exec(body);
-  const kind = /BgKind:\s*"([^"]+)"/.exec(body);
-  const preset = /BgPresetID:\s*"([^"]+)"/.exec(body);
-  assert.ok(dim && blur && theme && kind && preset, `DefaultAppearance 里这几个字段都要有（实际：${body}）`);
+  /*
+   * pi 2026-09-14：这类"去源码里读值"的判据必须能区分三种情况，且都不许静默放行：
+   *   ① 切不出函数体（改名/挪位置）→ 红（上面的 `at > 0` 已经挡了，这里再加一道空体检查）；
+   *   ② 字段**在**但值不是字面量（例如 `BgDim: defaultDim`）→ 报"**读不懂**"，红；
+   *   ③ 字段**根本不在**（重排/删掉）→ 红。
+   * ②③ 分开报，因为修法不一样：②是要人去看服务端怎么算的，③是判据要跟着字段走。
+   * 静默绿是这类判据最危险的失败方式 —— 与"自报条数 < 登记条数"同族。
+   */
+  assert.ok(body.replace(/[\s{}]/g, '').length > 0,
+    'DefaultAppearance 的函数体切出来是空的（函数被改名/挪走了？判据要跟着改，别静默放行）');
+  const field = (name, re, what) => {
+    assert.ok(new RegExp(`\\b${name}\\s*:`).test(body), `DefaultAppearance 里没有 ${name} 字段了（判据要跟着服务端改）`);
+    const m = re.exec(body);
+    assert.ok(m, `${name} 在，但值不是${what} —— **判据读不懂**，请人工核对接线，别让它悄悄跳过。函数体：${body.replace(/\s+/g, ' ')}`);
+    return m;
+  };
+  const dim = field('BgDim', /BgDim:\s*(\d+)/, '数字字面量');
+  const blur = field('BgBlur', /BgBlur:\s*(\d+)/, '数字字面量');
+  const theme = field('Theme', /Theme:\s*"([^"]+)"/, '字符串字面量');
+  const kind = field('BgKind', /BgKind:\s*"([^"]+)"/, '字符串字面量');
+  const preset = field('BgPresetID', /BgPresetID:\s*"([^"]+)"/, '字符串字面量');
  return {
    dim: Number(dim[1]),
    blur: Number(blur[1]),
@ -80,7 +98,8 @@ test('★ 默认外观 = 服务端契约（去 Go 源码里读，不在判据里
  const wp = readFileSync(join(ETS, 'model/Wallpaper.ts'), 'utf8');
  assert.match(wp, new RegExp(`'${s.preset}'`), `服务端默认预设 ${s.preset} 要在鸿蒙的预设清单里`);

-  // 服务端那句注释现在是**事实**（它宣称"与客户端默认值一致"）—— 这条就是它的核对器
+  // 这句注释在**这份源码**里现在是事实（它宣称"与客户端默认值一致"）—— 这条就是它的核对器。
+  // （运行时是否一致不由此判据保证：见文件头第 1 条的措辞说明。）
  const models = readFileSync(SERVER_MODELS, 'utf8');
  const comment = /\/\/ DefaultAppearance[\s\S]{0,200}?func DefaultAppearance/.exec(models);
  assert.ok(comment, 'DefaultAppearance 上面要有说明注释');
@ -109,18 +128,21 @@ test('★ 缓存键按账号分：两端的键都带账号，且都不许退回
  }
  const body = store.slice(bodyStart + 1, end);
  /*
-   * 仍然不能用"两个词离得近"来判：第二次变异（`return accountId ? STORAGE_KEY_PREFIX : STORAGE_KEY_PREFIX;`
-   * ——提了一下 accountId 但根本没用它）又把松正则骗过去了。
-   * 要求**同一个表达式里**既出现常量又插值/拼接账号：模板字面量 `` `a${b}` `` 或 `a + b`。
-   * 这样"提到"与"用上"就分开了。
+   * ⚠️ **这里原来有一条正则断言，已删除**（pi 2026-09-14 用反例钉死）：
+   *   `const k = STORAGE_KEY_PREFIX + accountId; return STORAGE_KEY_PREFIX;`
+   * ——"常量 + 账号拼接"确实**在函数体里**，但 `return` 的是全局键。
+   * 实测：第三版判据对这种写法**仍然全绿**（我跑过），退化和第一版一样完整。
+   * 教训：**判据的作用对象是"值/行为"时，不要退化成对源码形状的匹配** ——
+   * 这一族"源码里有没有那个形状"的判据永远差一个反例。
+   * 权威已经交给行为判据：`test/stores/background.test.ts` 直接断言
+   *   storageKey('acct-a') !== storageKey('acct-b')
+   *   storageKey('acct-a') === 'agentmail.background.acct-a'
+   *   storageKey('') !== 'agentmail.background'（不退回全局键）
+   * 那三条对"拼了没用上""拼了又丢掉""换个名字的退化"都会红，且不误伤合法写法。
+   *
+   * 下面保留的是**别的东西**：不许写死键名（键必须来自 storageKey()）。
+   * 那是"来源"约束，不是"值对不对"，正则在这里是合适工具。
   */
-  const exprs = [
-    ...[...body.matchAll(/`[^`]*`/g)].map(m => m[0]),
-    ...[...body.matchAll(/[^;\n{}]*\+[^;\n{}]*/g)].map(m => m[0])
-  ];
-  const joins = exprs.filter(e => e.includes('STORAGE_KEY_PREFIX') && e.includes('accountId'));
-  assert.ok(joins.length > 0,
-    `取键的函数体里必须**真的**把账号拼进键（模板插值或 + 拼接）。现在函数体是：${body.replace(/\s+/g, ' ').trim()}`);
  /*
   * 行为面由 vitest 兜底（`test/stores/background.test.ts` 直接断言
   * storageKey('acct-a') === 'agentmail.background.acct-a' 且两个账号不相等）——
@ -134,9 +156,20 @@ test('★ 缓存键按账号分：两端的键都带账号，且都不许退回
   */
  const badWrites = [...store.matchAll(/setItem\(([^,)]+)/g)]
    .map(m => m[1].trim())
-    .filter(k => !/^storageKey\(/.test(k) && k !== 'key');
+    /*
+     * `key` = 按账号算出来的键；`LEGACY_BACKUP_KEY` = 迁移前留的手工恢复备份
+     * （第三次被这类"合法写入"误伤：判据钉的是**键的来源**，不是调用的字面形状）。
+     */
+    .filter(k => !/^storageKey\(/.test(k) && k !== 'key' && k !== 'LEGACY_BACKUP_KEY');
  assert.deepEqual(badWrites, [], `写入的键必须来自 storageKey()（现在这些不是：${badWrites.join('、')}）`);
  assert.match(store, /removeItem\(LEGACY_STORAGE_KEY\)/, '旧全局键要被删除（否则下一个账号继续从它继承）');
+  /*
+   * 备份键（`LEGACY_BACKUP_KEY`）**只许写、不许读** —— 那是它无害的全部理由：
+   * 一旦有人读它，它就变成了第二个"继承源"，刚修掉的串味会从这条路回来。
+   */
+  const backupReads = [...store.matchAll(/getItem\(([^,)]+)\)/g)].map(m => m[1].trim())
+    .filter(k => k === 'LEGACY_BACKUP_KEY');
+  assert.deepEqual(backupReads, [], '备份键只能写不能读（否则它就成了新的"继承源"）');
  // 读/写都要走按账号的键（`key` 由 storageKey() 算出，见函数开头）
  assert.match(store, /const key = storageKey\(accountId\)/, '键要先按账号算出来');
  assert.match(store, /let raw = localStorage\.getItem\(key\)/, '读缓存要按账号的键');
@ -152,7 +185,13 @@ test('★ 缓存键按账号分：两端的键都带账号，且都不许退回
    if (ets[i] === '{') d2++;
    else if (ets[i] === '}') { d2--; if (d2 === 0) { e2 = i; break; } }
  }
-  assert.match(ets.slice(eAt, e2 + 1), /KEY_PREFIX\s*\+\s*accountId/, '鸿蒙的键也要拼账号');
+  /*
+   * 鸿蒙这半**只能**静态判：`.ets` 在本机跑不起来（编译要 hvigorw，运行要设备，
+   * 而设备/模拟器在这条链上不可用，见计划文档 §7.21 的实测阻塞）。
+   * 所以上面那条"值/行为优先"的规则在这里让位于正则 —— 但要把限制写明：
+   * 这条只证明"函数体里有把账号拼进键的形状"，**不证明**拼出来的值对。
+   */
+  assert.match(ets.slice(eAt, e2 + 1), /KEY_PREFIX\s*\+\s*accountId/, '鸿蒙的键也要拼账号（静态判据，值未经运行验证）');
 });

 test('★ 切账号的顺序：**先按新账号重读本地**，再拉服务端', () => {