Files
MailUI4Agents/client/electron/test/build-stamp.test.mjs
JianFeeeee d5cfcbdc9c fix(权限): 409 的第二种含义是「本档不该问」——四桥都补上;状态写入点不再兜默认档
线上事故(jianf 经 pi 转达):补投路径漏传 permission_mode,插件拿 undefined 兜了
workspace 档,把 full 档会话写成 workspace-write + ask —— 不是"拦一次",是一整轮
工具能力降级,且状态留在会话里;随后该会话每次受守卫调用都撞 409。

四件事:

1. **状态写入点不接受默认值**(新增共享 `modeForStateWrite`):缺字段/脏值 → `null`
   = 不写状态。"默认值可以出现在**决策**里,不可以出现在**状态写入**里。"
   同时保留共享契约的 fail-closed:真读到 workspace 才写 workspace。

2. **409 的两种含义分开处理**。`allowed-once` 只绕过**审批**,改不了**沙箱** ——
   所以 dsh 桥在放行前先把服务端给的权威档位**写回会话**(这也就成了自愈路径:
   已经降级的会话,下一次带档位的 409 会把它修回来);只认服务端明说的 full,
   plan 与"链上没有人类"照旧 fail closed。

3. **同一处缺陷在 zcode / opencode 也在**(`hooks/permission.mjs` 与 `index.js`
   都把 409 当永久失败拒绝)。我先前在回信里写过"这两个桥不转发权限询问,不需要改"
   —— 那句话是错的,我当时的搜索面只有 `<plugin>/src/*.mjs`。按 pi 的要求把这条
   **否定性事实变成常驻判据**后,它第一次运行就红给我看。四桥现在都有
   「409 + full → 放行」,且**排在永久失败分支之前**(含顺序变异自检)。

4. **共用测试重新同源**:`test/catchup.test.mjs` 从 `153985e` 起就是分叉的
   (我那版把平台专属路径写进了共用文件),而 `deploy/install.sh` 第 24 行会跑
   `check-shared-libs.sh` —— 也就是说**部署一直是红的**,我没跑过那个脚本。
   共用文件只放契约(值/行为),跨平台配对judge 移到平台专属文件,四份逐字节相同。

另外把"判代码 vs 判理由"从记忆变成代码:`test/lib/read.mjs` 提供 `code()/prose()/bytes()`,
判据目录里不得再裸用 `readFileSync`(新判据 `criteria-hygiene` 管,含读取器自检)。

判据证据(每条都做过"能不能红"的变异):
- 写回去掉 → 红;纠正块挪到普通 409 之后 → 红;状态写入点退回兜默认 → 红;
- zcode/opencode 的放行分支拿掉 → 各自红;共用测试分叉 → check-shared-libs 红。

各套件:dsh 388、pi 443、zcode 387、opencode 333(均经 npm test,含 tsc);
electron `npm test` 15/15 判据绿 + vitest 266 + typecheck;`check-shared-libs.sh` 退出 0;
Go `go test ./...` 全 ok。
2026-09-14 16:21:27 +08:00

141 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 { prose } from './lib/read.mjs';
import { test } from 'node:test';
import assert from 'node:assert/strict';
import { execFileSync } from 'node:child_process';
import { existsSync, 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 => prose(join(HERE, p));
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(prose(join(dir, f))));
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(prose(infoPath));
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 要带构建时间与构建命令');
});