Files
MailUI4Agents/client/electron/test/build-stamp.test.mjs
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

140 lines
8.1 KiB
JavaScript
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

/**
* 界面必须带一个可核对的构建戳2026-09-14
*
* # 为什么
*
* 用户连续三轮说「webui 还没改」,而我每次都能证明部署是活的:入口页 `no-cache`、
* 资源哈希 immutable、线上 bundle 与本地构建逐字节一致……但**隔着屏幕谁也说不清
* 对方的浏览器跑的是哪一份**。这行字把这件事变成可核对的:它在界面设置里显示
* `git短哈希·月日-时分`,刷新后数字变了就是拿到了新构建。
*
* 判据落在三处接线vite 注入 → 组件渲染 → 产物里真的有。
*/
import { test } from 'node:test';
import assert from 'node:assert/strict';
import { execFileSync } from 'node:child_process';
import { existsSync, readFileSync, readdirSync } from 'node:fs';
import { srcState } from '../scripts/build-info.mjs';
import { dirname, join } from 'node:path';
import { fileURLToPath } from 'node:url';
const HERE = dirname(fileURLToPath(import.meta.url));
const ROOT = join(HERE, '..', '..', '..');
const read = p => readFileSync(join(HERE, p), 'utf8');
const STAMP = /[0-9a-f]{7,}·\d{4}-\d{4}/;
test('vite 注入 __BUILD_STAMP__', () => {
const cfg = read('../vite.config.ts');
assert.match(cfg, /__BUILD_STAMP__/);
assert.match(cfg, /git rev-parse --short HEAD/, '戳里要有 git 短哈希');
});
test('界面渲染这个戳', () => {
const cmp = read('../src/components/BackgroundPicker.tsx');
assert.match(cmp, /__BUILD_STAMP__/, '组件必须渲染它,而不是只定义');
assert.match(cmp, /界面构建/, '文案里要能认出来');
});
test('★ 构建产物里真的带着戳', () => {
const dir = join(HERE, '../dist/assets');
const js = readdirSync(dir).filter(f => f.startsWith('index-') && f.endsWith('.js'));
assert.ok(js.length > 0, '先跑 npm run build');
const found = js.some(f => STAMP.test(readFileSync(join(dir, f), 'utf8')));
assert.ok(found, '产物里没有构建戳 —— 界面上就永远看不出自己跑的是哪一份');
});
test('判据自检:这个正则不能匹配随便一段文本', () => {
assert.equal(STAMP.test('界面构建 index-abcdef.js'), false);
assert.equal(STAMP.test('d2904fc·0914-0910'), true);
});
/*
* 仓库里不得跟踪缓存/构建产物(`.tmp/` 那次事故的判据化pi 提议)。
*
* 2026-09-14一次 `git add -A` 把 `.tmp/node-compile-cache/**` 与 `.tmp/studtmp-*`
* 554 个文件、2.6MB)提交进了版本库。靠"记得先看 git status"防不住下一次 ——
* 而这件事**不报错、不报警**,代价却落在别人身上:复核者读 diff 判断"改了什么"
* 554 个缓存文件直接把改动面埋了(同一工作区里还有并发写入者,这尤其致命)。
* 所以按 pi 的建议,改成一条结构性判据。
*/
test('★ 版本库里不得跟踪缓存/构建产物(.tmp、node_modules、dist、release、embed 产物)', () => {
const tracked = execFileSync('git', ['ls-files'], { encoding: 'utf8', cwd: ROOT })
.split('\n')
.filter(Boolean);
assert.ok(tracked.length > 100, `git ls-files 只列出 ${tracked.length} 个文件,判据大概跑错目录了`);
/*
* `server/internal/static/static/` 是 go:embed 的落点:**它的存在**靠一个
* 有意跟踪的 `placeholder.html` 撑着(.gitignore 里也是 `*` + `!placeholder.html`)——
* 那是设计,不是产物。所以这条只放行那一个名字,其余一律算产物。
*/
const EMBED_PLACEHOLDER = 'server/internal/static/static/placeholder.html';
const poison = tracked.filter(f =>
/^(\.tmp\/|.*\/node_modules\/|client\/electron\/dist\/|client\/electron\/release\/|release\/|server\/internal\/static\/static\/)/.test(f)
&& f !== EMBED_PLACEHOLDER
);
assert.deepEqual(
poison.slice(0, 10),
[],
`版本库里跟踪了缓存/构建产物(共 ${poison.length} 个,前 10 个如下)—— 它们会让复核者看不清真实改动面:\n ${poison.slice(0, 10).join('\n ')}`
);
// 反向对照:判据要真能认出这类路径(否则正则写错也是一片绿)
const looksTracked = p => /^(\.tmp\/|.*\/node_modules\/|client\/electron\/dist\/|client\/electron\/release\/|release\/|server\/internal\/static\/static\/)/.test(p);
assert.ok(looksTracked('.tmp/node-compile-cache/v22/0014c7b4'), '自检:认不出 .tmp 下的缓存');
assert.ok(looksTracked('client/electron/release/agentmail-web_0.1.0_amd64.deb'), '自检:认不出安装包产物');
assert.ok(!looksTracked('client/electron/src/index.css'), '自检:把源码当成产物了');
// 那个占位文件必须还在:它是 go:embed 落点存在的唯一理由,删了 Go 侧就编不过
assert.ok(tracked.includes(EMBED_PLACEHOLDER), 'go:embed 的占位文件丢了 —— 没有它 static/ 目录不存在Go 侧编不过');
});
test('★ 产物必须自报来源BUILD_INFO 精确比对(不是比时间戳)', () => {
/*
* 这条是踩出来的2026-09-14 接手 pi 的 WebUI 开项时):
* 我把 `npm run build` 串在管道里(`npm run build 2>&1 | tail -4 && electron-builder …`
* **构建失败被管道吞了**pipeline 的退出码是 tail 的),于是 electron-builder
* 拿旧的 dist 打了一个新包 —— 而所有判据都是绿的:
* - vitest 绿:测试运行时对"缺的具名导出"很宽容(拿到 undefined只有打包器会报
* - packaging 绿:它比的是"dist vs 安装包",两边都是旧的,自然一致。
*
* 第一版判据比的是**时间戳**dist 不早于 src 最新文件),它能抓住那次事故,
* 但 pi 2026-09-14 指出它是**代理变量**,两层都靠不住:
* ① 看不见"构建是否成功"(实测:构建失败但碰过 dist 时它照样绿 —— 那个坑由
* scripts/release-linux.sh 喂退出码来堵,见 CRITERIA.md §6.7.1
* ② **dist 比 src 新也不等于 dist 是从这份 src 构建的**`git checkout`、`cp`、
* 时钟都能骗过 mtime —— 我确实用 checkout 造过一次假红)。
* 现在改成**内容自证**`dist/BUILD_INFO.json` 记下构建时的 srcHash 与 gitRev
* 判据重算一遍当前的指纹再**精确比对**。于是判据说的是"产物记的源状态 == 当前源状态"
* 而不是"谁的时间更晚" —— "代理"两个字没有了。
*/
const infoPath = join(ROOT, 'client/electron/dist/BUILD_INFO.json');
const distIndex = join(ROOT, 'client/electron/dist/index.html');
if (!existsSync(distIndex)) {
console.log('(没有 dist —— 先 npm run build 才验得到这条)');
return;
}
assert.ok(existsSync(infoPath),
'dist 里没有 BUILD_INFO.json —— 构建没走 `npm run build`(它最后一步会写这份自证)。\n' +
' 重构建cd client/electron && npm run build');
const info = JSON.parse(readFileSync(infoPath, 'utf8'));
const now = srcState();
// 精确比对:这一条比"谁更新"强的地方在于它**能读出**差在哪
assert.equal(info.srcHash, now.srcHash,
`产物与当前源码不是同一份(改了没重新构建):\n` +
` 产物记录的 srcHash${String(info.srcHash).slice(0, 12)}${info.srcFiles} 个文件)\n` +
` 当前源码的 srcHash${now.srcHash.slice(0, 12)}${now.files} 个文件)\n` +
` 重构建cd client/electron && npm run build注意别把它的退出码丢在管道里`);
if (now.gitRev && info.gitRev) {
assert.equal(info.gitRev, now.gitRev,
`产物是在另一个提交上构建的(产物记 ${info.gitRev},当前 HEAD ${now.gitRev})—— 重构建再复核`);
}
/*
* `gitDirty` 只**展示**不判定:共享工作区常年是脏的(并发写作者的未提交改动),
* 拿它当红/绿依据会让这条判据天天误报。它写在 BUILD_INFO 里是为了复核时先看这一行
* —— "这个包对应的源码状态干净吗"pi 提的"一条红自报来源"的构建侧同款)。
*/
assert.ok(typeof info.gitDirty === 'boolean', 'BUILD_INFO 要记录构建时工作树是否干净(供复核者判断)');
assert.ok(info.builtAt && info.buildCmd !== undefined, 'BUILD_INFO 要带构建时间与构建命令');
});