Files
MailUI4Agents/client/electron/test/mutants
JianFeeeee e8b260dd70 维护: 底本重算(4 个文件漂移 = **底本过期**,不是变异残留)—— 逐个核实后按本文件的协议记一行"为什么"
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、只提示)那一档 ——
它**不假红**(正常提交不会天天红),但也**不会被自动发现**:
我是靠主动逐文件核查撞上的,不是它自己报的。
"不假红"与"会被发现"在这个闸上仍有取舍,这条记为已知残留。
2026-09-19 13:01:39 +08:00
..