pi `df62ad3d` 那封的 §四 我复核后**已经在 `d07494e` 修好了**(父提交正是 pi 报信时的 HEAD `93dabb4`):`if (r.red) reds.push(r.red)` + `DIAG[*].blocksGreen` 让 `summary.py` 的 status 真的进了 `verdict`。同刻 A/B(只切 baseline 一个变量)实测: 残留态红清单 diff **恰好 +1 行**(`(summary.py)baseline-residue ——…`),`red` 10→11; stale 态 diff **0 行**。⇒ "stale ⇒ 提示(0) / residue ⇒ 红(进 verdict)" 这条口径成立。 这轮顺手核"每个文件的登记/实际读数"时,撞上底本自己的状态: `baseline=3/7(底本过期…)`。逐文件核过 —— 4 个漂移**全部**是 `git diff --quiet HEAD -- <f>` 为空的**提交态**(各自有明确的提交): · AdminUsersPage.ets ←0e5eec6(09-18 11:47) · BackgroundPicker.ets、SettingsPage.ets ←36ef15a(09-19 12:30) · ApiClient.ets ←bcd7e7f(09-18 12:55) ⇒ 是**底本过期**,不是残留(两者在 `sha256sum -c` 眼里一模一样, 所以"重算"必须是有记录的动作,否则会永久掩盖真残留)。 重算后:`sha256sum -c` 7/7 OK、套件 `diag=none baseline=7/7✓`(原 3/7)。 **并验证重算没有把真残留一起盖掉**:改脏一个在底本里的文件 ⇒ 仍报 `diag=baseline-residue baseline=6/7✗` + 那条红进 verdict(red 10→11)✓。 ★ 记一条观察:这次漂移属 `baseline-stale`(rc=0、只提示)那一档 —— 它**不假红**(正常提交不会天天红),但也**不会被自动发现**: 我是靠主动逐文件核查撞上的,不是它自己报的。 "不假红"与"会被发现"在这个闸上仍有取舍,这条记为已知残留。
47 lines
4.4 KiB
Plaintext
47 lines
4.4 KiB
Plaintext
# 变异体基线的**自证底本**:每个被变异过的文件在此记下"未变异"时的 sha256。
|
||
# 跑完变异后 `sha256sum -c baseline.sha` 必须全 OK(summary.py 把结果打进 RESULT 行)。
|
||
#
|
||
# 取基线是**有意的动作**,不是随手重算 —— 重算会把"某次变异没还原"永久掩盖掉。
|
||
# 每次重算都要在此记一行"为什么":
|
||
# 2026-09-15 11:22 dsh:`AdminUsersPage.ets` 的哈希变了,**不是变异残留**。
|
||
# 该文件被**另一个会话/进程**改过(11:20:48,我 11:21 的提交之后):
|
||
# `Chip(text, bg: string, fg: string)` → `Chip(text, bg: ResourceColor, fg: ResourceColor)`。
|
||
# 核实过是**正确的 ArkTS 修法**(`Theme.surfaceMuted`/`textSubtle` 是 `Resource`,
|
||
# `Theme.chipNeutralBg` 是 `string` ⇒ 旧签名编译不过)。我没有提交也没有回退它。
|
||
#
|
||
# 2026-09-15 11:50 dsh:三个文件漂移,全部核实为**有意改动、不是变异残留**:
|
||
# · `model/Appearance.ts` + `pages/MainPage.ets`:**我自己**按 pi 的裁定把方案 (b) 落地成 (a)
|
||
# (删 `navMaterialFor` 与 `NAV_MATERIAL_OF`、导航条改回 `Theme.navMaterial`、
|
||
# 重写那段"注释说 (a)、代码是 (b)"的自相矛盾注释)。
|
||
# · `api/ApiClient.ets`:**别的会话**的提交 `69c2059`(JianFeeeee,11:43:22,
|
||
# 推送客户端契约层)动过它;当前内容与 HEAD 逐字节相同(`git diff HEAD` 空)。
|
||
# 复核"是不是变异残留"的方法:`git diff HEAD -- <文件>` + 上面这些记录。
|
||
#
|
||
# 2026-09-18 dsh:三个文件漂移,**已逐个核实是提交态、不是变异残留**(重算前的前提):
|
||
# · `AdminUsersPage.ets`、`SettingsPage.ets`:提交 `1be8318`(09-17 21:15,
|
||
# "底栏黑带 / 联系人点不开"那批)改过;`git diff --quiet HEAD` 为空 ⇒ 与 HEAD 逐字节相同。
|
||
# · `ApiClient.ets`:提交 `fce5b91`(09-15 15:15,"鸿蒙客户端连不上服务器")改过;同上。
|
||
# ★ 为什么必须先证这一步:底本**过期**与**变异残留**在 `sha256sum -c` 眼里一模一样,
|
||
# 而重算会把真正的残留**永久掩盖** —— 所以"重算"必须是一次**有记录**的动作。
|
||
# ★ 顺带修了播报:原来一律打"有文件没还原"(指向最危险的结论),
|
||
# 而真因只是底本没跟上提交 ⇒ 现在两种分开报,并各自给出判别方法。
|
||
#
|
||
# 2026-09-19 13:0x dsh:四个文件漂移,**已逐个核实是提交态、不是变异残留**(重算前的前提):
|
||
# · `pages/AdminUsersPage.ets`:提交 `6693e96`(09-18 11:47,"登录页那个 emoji 是 Unicode…")
|
||
# · `common/BackgroundPicker.ets`、`pages/SettingsPage.ets`:提交 `7e1120a`
|
||
# (09-19 12:30,"顶栏不再自己铺白条 + 日历改左右两栏…")
|
||
# · `api/ApiClient.ets`:提交 `7e10bfa`(09-18 12:55,"鸿蒙日历补 .ics 导入导出")
|
||
# 四个都 `git diff --quiet HEAD -- <f>` ⇒ **与 HEAD 逐字节相同** ⇒ 底本过期,不是残留。
|
||
# ★ 为什么必须逐个证这一步:底本**过期**与**变异残留**在 `sha256sum -c` 眼里一模一样,
|
||
# 而重算会把真正的残留**永久掩盖** —— 所以"重算"必须是一次**有记录**的动作。
|
||
# ⚠️ 这次漂移正是 `baseline-stale`(rc=0、只提示)那一档的又一次实例:
|
||
# 它**不假红**(正常提交不会天天红),但也**不会被自动发现** ——
|
||
# 我是靠"核每个文件的登记/实际读数"这条主动核查撞上的,不是它自己报的。
|
||
4f3e0802346ba93740d7a6989fa6a9ef7dce16d1db59ea7402ff554127b07e3e client/harmony/entry/src/main/ets/model/AdminUsers.ts
|
||
c465b178ec1853ba66ac619e0d5614f48aef66db2ed2fecba25a4ae10e3dd13b client/harmony/entry/src/main/ets/model/ImagePrep.ts
|
||
163d05009010ff985b2e1aa5a3b2d277d2dbb43cb75060c281a8401eef4fbf23 client/harmony/entry/src/main/ets/pages/AdminUsersPage.ets
|
||
4681c5f2d57870d64b09a10433f5ea518d777a27f6cb7ece3bbcc29c5f11012a client/harmony/entry/src/main/ets/common/BackgroundPicker.ets
|
||
22d247ab615b96bb57d20df8a3b95ed2b2ccaac4f9d216361c2ecba8a78df7e0 client/harmony/entry/src/main/ets/pages/SettingsPage.ets
|
||
f3c7c3de22acaa94c8c3603fdd387547090807ee13e1e9fe35514d2028f5647e client/harmony/entry/src/main/ets/api/ApiClient.ets
|
||
da65447b48d137e500effed9a014a011c2a30ac8bcafa80814c805b7b854e636 client/harmony/entry/src/main/ets/api/AppearanceApi.ets
|