From e8b260dd70d302efc97fa8723fe0f0e0709ba829 Mon Sep 17 00:00:00 2001 From: JianFeeeee Date: Sat, 19 Sep 2026 13:01:39 +0800 Subject: [PATCH] =?UTF-8?q?=E7=BB=B4=E6=8A=A4:=20=E5=BA=95=E6=9C=AC?= =?UTF-8?q?=E9=87=8D=E7=AE=97=EF=BC=884=20=E4=B8=AA=E6=96=87=E4=BB=B6?= =?UTF-8?q?=E6=BC=82=E7=A7=BB=20=3D=20**=E5=BA=95=E6=9C=AC=E8=BF=87?= =?UTF-8?q?=E6=9C=9F**=EF=BC=8C=E4=B8=8D=E6=98=AF=E5=8F=98=E5=BC=82?= =?UTF-8?q?=E6=AE=8B=E7=95=99=EF=BC=89=E2=80=94=E2=80=94=20=E9=80=90?= =?UTF-8?q?=E4=B8=AA=E6=A0=B8=E5=AE=9E=E5=90=8E=E6=8C=89=E6=9C=AC=E6=96=87?= =?UTF-8?q?=E4=BB=B6=E7=9A=84=E5=8D=8F=E8=AE=AE=E8=AE=B0=E4=B8=80=E8=A1=8C?= =?UTF-8?q?"=E4=B8=BA=E4=BB=80=E4=B9=88"?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 -- ` 为空的**提交态**（各自有明确的提交）： · 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、只提示）那一档 —— 它**不假红**（正常提交不会天天红），但也**不会被自动发现**： 我是靠主动逐文件核查撞上的，不是它自己报的。 "不假红"与"会被发现"在这个闸上仍有取舍，这条记为已知残留。 --- client/electron/test/mutants/baseline.sha | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/client/electron/test/mutants/baseline.sha b/client/electron/test/mutants/baseline.sha index ba90163..58f3706 100644 --- a/client/electron/test/mutants/baseline.sha +++ b/client/electron/test/mutants/baseline.sha @@ -25,10 +25,22 @@ # 而重算会把真正的残留**永久掩盖** —— 所以"重算"必须是一次**有记录**的动作。 # ★ 顺带修了播报：原来一律打"有文件没还原"（指向最危险的结论）， # 而真因只是底本没跟上提交 ⇒ 现在两种分开报，并各自给出判别方法。 +# +# 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 -- ` ⇒ **与 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 -4c56e7e762374a8d2a9de0779c3d5c716808ed15f961e962b15299394ef436dd client/harmony/entry/src/main/ets/pages/AdminUsersPage.ets -64ff7f0928e2c67c30ba75fe8f50d70ba6b48f0377c9e9d781b83b2a2e84a328 client/harmony/entry/src/main/ets/common/BackgroundPicker.ets -b22023f2d05b431ef93b824f6d6f1ddec3eab08adde334fb32ea1680c8bbe813 client/harmony/entry/src/main/ets/pages/SettingsPage.ets -ae7bea2c3ade31661a1fcfcc660c015d7b10e5b097c1064d568628ec36fe93be client/harmony/entry/src/main/ets/api/ApiClient.ets +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