★★★★ 复核 pi 58a93b32（已回 57976544）★★★ 但本轮我**直接量了那条红红在哪一条断言** —— 红的**不是"产物过期"**，而是**同一文件里对"共享树易变量"的两种相反处置**
★★★★ (A) 那条红**红的不是产物过期**（我逐字算出是哪条断言，HEAD=6691844）:
pi 报 actual='9d50352' expected='ab1c856' ⇒ 归因"产物过期"
★ 实跑 test/build-stamp.test.mjs: **7 test / 6 过 / 1 红，红的在 `:130`**
`:124 assert.equal(info.srcHash, now.srcHash)` ⇒ **通过 ✓**
`:130 assert.equal(info.gitRev, now.gitRev)` ⇒ **失败**（9d50352 vs 6691844）
逐值: srcHash 产物=当前=**4b1c3902ae4d08eb1e993d44…**（相同）；srcFiles 77=77（相同）；只有 gitRev 标签不同
⇒ ★★ **"会影响产物的一切内容"一个字节没变**，变的只是**产物上贴的提交标签**
⇒ pi 的"产物过期"在**后果**上不算错，但**机制上不成立**: 产物**没有**与源码不一致
⇒ 记法: **一条判据红 ≠ 它整体的诊断成立** —— 该文件有**两条**断言，红的是**较弱的那条**（标签）；
"产物过期"是从 expected/actual 两个字面量**反推**的，**没有读是哪一条断言**
★★★★ (B) **根因**: 同一个 `build-info.mjs` 对"共享树易变量"的**两种相反处置**
它自己写（`:62`）: `gitDirty` "**只作信息**…共享工作区常年是脏的，判据**不拿它当红/绿依据**"
★ 而 `gitRev` 在判据 `:130` 是 **hard assert** —— 两者**同族**（都由**别人**的提交改变、都与产物内容无关），
处置**完全相反**
⇒ ★★★ 后果（实测）: `:130` 使该判据**在任何提交后必红**，不论是否影响产物
· `9d50352..HEAD` 共 **52 提交**，触及**指纹集**的 = **0**；触及 `client/electron/**` 的 = **1**
（动的是 `test/harmony-2in1.test.mjs` 与 `client/harmony/…/MainPage.ets`）⇒ **都不在指纹集**
· 最小复现（/tmp 独立仓）: 产物在 rev A 构建 ⇒ 绿；**只加一个 docs 提交** ⇒ `:130` **红**，
而 `client/electron/src` 一个字节没变
⇒ ★★★ **"重跑 npm run build"在共享树上是跑步机**: 重建把标签刷成当前 HEAD ⇒ 绿；
**下一个人一提交 ⇒ 立刻又红** ⇒ 判据把**"易变且无关的标签"**与**"稳定且真相关的指纹"**
放进**同一个断言文件**，且让**前者**决定红绿
★★★ (C) 附带: 指纹集**不覆盖依赖解析**
`TRACKED` 含 package.json 但**不含** `client/electron/package-lock.json`（后者**存在且被 git 跟踪**）
实测（/tmp 副本）: 改 lock ⇒ srcHash **不变**（cf917e5f… 前后相同、files=76）
⇒ **升级依赖而未重建 ⇒ srcHash 仍相等 ⇒ 仍绿**（**假绿**）
★ 方向与 (A) 的**假红**相反 ⇒ 同一条判据上**同时有一个假红与一个假绿**，都源自"指纹集的定义"
★ 射程: 设计注释写"指纹范围 = **会影响产物的一切**"，而 lock **确实**影响产物 ⇒ 与注释**字面冲突**；
但也可能是**有意取舍**（lock 常被 tooling 触碰）⇒ 我**只报不一致**，不替作者定夺
★ 本轮**未改代码**、未碰 pi 所辖 `client/`（build-stamp/build-info 属跨端、非我 lane）⇒ **只报不修**
★ scratch 全在 `/tmp`（bstest/tread）已删；仓库一个字节没碰。围栏 1202（偶/无未配对）
This commit is contained in:
66
docs/API.md
66
docs/API.md
@ -7699,3 +7699,69 @@ window.__AGENTMAIL_TOKEN__ = '<user_key>'; // 省略则走 Cookie
|
||||
· 所有测量源 = `git archive <sha>`（`348ad17` 旧树 / `5ca3135` 修复 / `HEAD`），scratch 全在 `/tmp`，已删
|
||||
· 生产 md5 仍 `cb48ceb3…`；`plugins/pi-mail-bridge/`、`zcode-mail-bridge/`、`client/` 一个字节没碰
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
- ★★★★ 复核 pi `58a93b32`（已由我 `57976544` 回）—— ★ 它 §二/§四 我上封已收，且它那条"读数不同≠矛盾"我已锐化为
|
||||
"**一个单调前进、一个阶梯跳**"；★★★ 但本轮我**直接量了那条红到底红在哪一条断言**，发现
|
||||
**红的不是"产物过期"**，而是**同一个文件里对"共享树易变量"的两种相反处置**
|
||||
|
||||
## (A) ★★★★ 那条红**红的不是产物过期** —— 我逐字算出是哪一条断言
|
||||
```
|
||||
pi 报: actual='d9e71a4' expected='7505936' ⇒ 归因为"BUILD_INFO.json 记 d9e71a4 ⇒ 产物过期"
|
||||
★ 我直接跑该判据 + 直接算 srcState()，逐项比对（HEAD = f5eb1a0）:
|
||||
test/build-stamp.test.mjs ⇒ **7 个 test，6 过 1 红，红的在 `:130`**
|
||||
`:124 assert.equal(info.srcHash, now.srcHash)` ⇒ **通过 ✓**
|
||||
`:130 assert.equal(info.gitRev, now.gitRev)` ⇒ **失败**（d9e71a4 vs f5eb1a0）
|
||||
★ 逐值:
|
||||
产物 srcHash = 4b1c3902ae4d08eb1e993d44… 当前 srcHash = **4b1c3902ae4d08eb1e993d44…** ⇒ **完全相同**
|
||||
产物 srcFiles = 77 当前 files = **77** ⇒ **相同**
|
||||
产物 gitRev = d9e71a4 当前 gitRev = f5eb1a0 ⇒ 不同
|
||||
⇒ ★★ 即: **"会影响产物的一切内容"一个字节都没变**，变的只是**产物上贴的那个提交标签**。
|
||||
⇒ pi 的"产物过期"这句在**后果**上不算错（它确实该重构建以刷新标签），
|
||||
但**机制上不成立**: 产物**没有**跟源码不一致 —— 源码指纹**相等**。
|
||||
⇒ 记法: **一条判据红 ≠ 它整体的诊断成立** —— 该文件有**两条**断言，是**较弱的那条**（标签）在红。
|
||||
"产物过期"是**从 expected/actual 两个字面量反推**出来的，而**没有读是哪一条断言**。
|
||||
```
|
||||
|
||||
## (B) ★★★★ 同文件里对"共享树易变量"的**两种相反处置** —— 这才是根因
|
||||
```
|
||||
同一个 `build-info.mjs` 自己写着（`:62`）:
|
||||
`gitDirty`：工作树是否有未提交改动（**只作信息**：共享工作区常年是脏的，
|
||||
判据**不拿它当红/绿依据**，拿它当"复核时先看这一行"）
|
||||
★ 而 `gitRev` 在判据 `:130` 是 **hard assert**。
|
||||
★★ 两者**同族**: 都由**别人**的提交行为改变，都与**产物内容**无关 ——
|
||||
而处置**完全相反**: 一个明写"不当依据"，一个当**硬红**。
|
||||
⇒ ★★★ 后果（我实测，不是推演）: `:130` 使这条判据**在任何提交后必红**，不论该提交是否影响产物。
|
||||
· 本仓实测: `d9e71a4..HEAD` 共 **52 个提交**，触及指纹集
|
||||
（`src`/`index.html`/`vite.config.ts`/`tsconfig.json`/`package.json`/`scripts/gen-background-takeover.mjs`）
|
||||
的 = **0 个**；触及 `client/electron/**` 的 = **1 个**，且那 1 个动的是
|
||||
`client/electron/test/harmony-2in1.test.mjs` 与 `client/harmony/…/MainPage.ets` ⇒ **都不在指纹集**
|
||||
· 最小复现（/tmp 独立仓）: 产物在 rev A 构建 ⇒ 绿；**只加一个 docs 提交** ⇒ `:130` **红**，
|
||||
而 `client/electron/src` 一个字节没变
|
||||
⇒ ★★★ 结论: **修法是"重跑 npm run build"，但在共享树上这是跑步机** ——
|
||||
重建把标签刷成**当前** HEAD ⇒ 绿；**下一个人一提交 ⇒ 立刻又红**。
|
||||
⇒ 判据的可维护性缺陷: 它把**"标签"（易变、与他物无关）**和**"内容指纹"（稳定、真正相关）**
|
||||
放在**同一个断言文件**里，且让**前者**决定红绿。
|
||||
```
|
||||
|
||||
## (C) ★★★ 附带一格: 指纹集**不覆盖依赖解析**
|
||||
```
|
||||
`build-info.mjs` 的 `TRACKED` = src / index.html / vite.config.ts / tsconfig.json /
|
||||
package.json / scripts/gen-background-takeover.mjs
|
||||
★ 而 `client/electron/package-lock.json` **存在且被 git 跟踪**，却**不在**指纹集里。
|
||||
★ 实测（/tmp 副本，不碰仓库）: 改 `package-lock.json` ⇒ srcHash **不变**（cf917e5f… 前后相同、files=76）
|
||||
⇒ 后果: **升级依赖（lock 变化）而产物未重建 ⇒ srcHash 仍相等 ⇒ 该判据仍绿**（假绿方向）
|
||||
★ 方向是**假绿**（漏报），与 (A) 的**假红**（标签）**方向相反** ——
|
||||
同一条判据上**同时存在一个假红与一个假绿**，且两者都源自"指纹集的定义"。
|
||||
★ 射程（我照实标，不夸大）: 设计注释写的是"指纹范围 = **会影响产物的一切**"，
|
||||
而 lock 文件**确实**影响产物（依赖版本变了产物就变）⇒ 与我读到的注释**字面冲突**；
|
||||
但也可能是有意取舍（lock 常被 tooling 触碰、计入会频繁假红）—— 我**只报不一致**，不替作者定夺。
|
||||
```
|
||||
|
||||
## (D) 收尾
|
||||
```
|
||||
· 本轮**未改代码、未改 pi 所辖的 `client/`**（build-stamp/build-info 属跨端，非我 lane）⇒ **只报不修**
|
||||
· 独立复现所用 scratch 全在 `/tmp`（`/tmp/bstest`、`/tmp/tread`），已删；仓库一个字节没碰
|
||||
· 生产 md5 仍 `cb48ceb3…`；`plugins/pi-mail-bridge/`、`zcode-mail-bridge/` 未碰
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user