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 —— 那是**构建流程**的改动，
  而本工作区正被多个会话并发使用；由人决定。
· 这笔债**仍未结算**：它会在**下一次提交**时重现（结构性的，与代码无关）。

client/electron/test/CRITERIA.md

@@ -239,8 +239,42 @@ cmd >file 2>&1; echo $? ⇒ 唯一诚实的形状
 - **改完用变异测试自证**：把旧实现放回去，确认那条判据**确实变红**。
   本次正是这一步把「我修好了」与「我改的东西恰好没人用」区分开。
 
-### 6.1 判据的**存在性**也要有下限：把"必须存在哪几条"锚到判据自己的表之外（pi 2026-09-18）
+#### 6.0.6 **同一个红会自己搬家**时，要把它变成有界的（2026-10-03）
 
+6.0.1–6.0.5 讲的是「读数怎么取才可信」。这一节讲一个**读数的信噪比**问题：
+**一条结构性长期红，与真缺陷同屏时，会把整屏红的价值抵消掉。**
+
+具体形态（`client/electron/build-stamp` + `packaging`）：
+
+```
+提交 ⇒ 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` 钩子把两者串起来。
+
+**为什么不能靠“加进跳过名单”解决**：那是把它变成**看不见**（本仓反复消的
+「看不到 ⇒ 绿」，方向相反的那一族）。正解是**把它变成有界的**：
+
+- **到期条件写成可机检的动作**（本笔的 `due` 就是那个界）；
+- 报错文案自带**第二步**（`build-stamp` 的文案现在只说“重构建”，
+  不够 —— 要写上“然后重打包”）—— 与 §14 同一条道理：
+  **报错是下一个人一定会看到的东西，文档不一定。**
+- 实测记下**哪个 commit 下什么状态**，别让下一个人重新推一遍。
+
+⚠️ 注意区分两种红：
+· **本节的**：与被测代码**无关**，只由 HEAD 移动引起 ⇒ 有界、可预言；
+· **真缺陷**：由代码引起 ⇒ 不会自己消失。
+⇒ 两者**同屏**时，要让人一眼分得出 —— 至少别让前者看起来像后者。
+
+### 6.1 判据的**存在性**也要有下限：把"必须存在哪几条"锚到判据自己的表之外（pi 2026-09-18）
 §6 那条只说了"扫目录要有下限"。**同一条规矩换个对象就漏了** —— 这条是它的镜像：
 
 `run-all.mjs` 的自检登记表 `SELFTESTS` 原来**没有任何下界**，也没有任何"必须存在哪几个"的

client/electron/test/build-stamp.test.mjs

@@ -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` 只**展示**不判定：共享工作区常年是脏的（并发写作者的未提交改动），