docs(判据): ★★ 「重构建」是**两步** —— 只做第一步,红会从 build-stamp 搬到 packaging
**实测(2026-10-03,每步退出码取自不接管道的运行)**:
提交 ⇒ HEAD 前进 ⇒ build-stamp 红(产物记旧 rev)
① npm run build ⇒ build-stamp 绿、**packaging 红**
② npx electron-builder --linux … ⇒ 两条同时绿
★ 只做①的人会以为「修好了」(前一条确实绿了),而红只是**换了个位置**。
**为什么①会让 packaging 转红**:packaging 比的是「asar 里的 dist 文件名」
vs「当前 dist/index.html 引用的文件名」,而 Vite 输出带**内容哈希**
⇒ 重构建一换文件名,asar 立刻过期。两条判据是**同一条链的两环**,
而 package.json 里**没有** beforeBuild 钩子把两者串起来 ⇒ 必须人记得做两次。
**改了三个地方,因为「报错文案」比文档更容易被看到(§14 同一条道理)**:
· build-stamp 的报错文案**自带第二步**。原文只写「正确修法只有一个:重跑构建」——
实测证明那句话**只完成了一半**,而只看文案的人会照做然后以为好了。
已用变异测试确认:把产物 gitRev 改成 0000000 ⇒ 变红且两条步骤都出现,
改回 ⇒ 绿。
· CRITERIA.md 新增 §6.0.6「同一个红会自己搬家时,要把它变成有界的」。
它讲的是**读数的信噪比**:一条结构性长期红与真缺陷**同屏**,
会把整屏红的价值抵消("看到了 ⇒ 当没看见")。
明确**不能**靠加跳过名单解决(那是把它变成看不见),
正解是到期条件可机检 + 报错文案自带下一步。
· DEBTS.json 的 build-stamp-stale-artifact-blocks-verification:
把 due/where/note 补上「两步」的实测事实,并把**第二环 packaging**
补进 where —— 原笔只记了 build-stamp 那一环。
**边界 / 未做**
· 没有把两步串进 npm 脚本或 beforeBuild —— 那是**构建流程**的改动,
而本工作区正被多个会话并发使用;由人决定。
· 这笔债**仍未结算**:它会在**下一次提交**时重现(结构性的,与代码无关)。
This commit is contained in:
@ -131,7 +131,17 @@ test('★ 产物必须自报来源:BUILD_INFO 精确比对(不是比时间
|
||||
`产物是在另一个提交上构建的(产物记 ${info.gitRev},当前 HEAD ${now.gitRev})—— 重构建再复核。` +
|
||||
`\n**别去改 BUILD_INFO.json 里的 gitRev / srcHash 了事** —— 那是把这条判据废掉` +
|
||||
`(§14 说的「最常见的错误修法」):产物自证的意义就是「产物必须来自当前源码」,` +
|
||||
`改记录只会让两者不一致却看不出来。正确修法只有一个:重跑构建。`);
|
||||
`改记录只会让两者不一致却看不出来。正确修法只有一个:重跑构建。` +
|
||||
`\n\n★★★ 而重跑构建是**两步**,不是一步(2026-10-03 实测,` +
|
||||
`\n改完先看 packaging 那条,别以为修好了):` +
|
||||
`\n ① cd client/electron && npm run build` +
|
||||
`\n ② npx electron-builder --linux -c.electronDownload.isVerifyChecksum=false` +
|
||||
`\n**为什么必须两步**:\`packaging\` 比的是「asar 里的 dist 文件名」vs` +
|
||||
`\n「当前 dist/index.html 引用的文件名」,而 Vite 输出带**内容哈希** ——` +
|
||||
`\n重构建一换文件名,asar 就过期 ⇒ 本条转绿的同时 \`packaging\` 会转红。` +
|
||||
`\n只做第①步的人会以为「修好了」(前一条绿了),而红只是**换了个位置**。` +
|
||||
`\n形状与实测记在 \`CRITERIA.md\` §6.0.6;` +
|
||||
`\n那笔账在 docs/DEBTS.json 的 build-stamp-stale-artifact-blocks-verification。`);
|
||||
}
|
||||
/*
|
||||
* `gitDirty` 只**展示**不判定:共享工作区常年是脏的(并发写作者的未提交改动),
|
||||
|
||||
Reference in New Issue
Block a user