MailUI4Agents

Files

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

2026-10-03 11:17:18 +08:00

reviews

docs(归档): 把三轮结论与待人决策项落进仓库 —— 邮件会被压缩，这些不能只存在于往来里

2026-09-28 11:14:17 +08:00

ALIGN-REFS.json

docs(对齐): 重新核对 calendar-view 对齐底本（第四轮）

2026-09-28 08:46:02 +08:00

API.md

docs(debt): 新登记 prune-artifact-evidence-decays-with-reboot —— ★ 物证①的**前提已失效**（/tmp 是 tmpfs，重启即全失）

2026-09-27 04:11:38 +08:00

DEBTS-REVIEW.md

fix(inbox): 收件箱按**工作区**收窄（三维地址的 path 位此前从未被使用）