Files
MailUI4Agents/client/electron/test/mutants/baseline.sha
JianFeeeee 6ca0113fd2 跨端: 统一顶栏组件 + 按压反馈(真跑通)+ 滑动判定从"时长门"改"速度门"
用户四条意见,逐条都是真问题,且**两条是我写完没生效**:
  ① 「所有的顶栏都应该应用玻璃圆框效果」② 「抽象一个统一的顶栏组件出来吧」
  ③ 「你不觉得发件箱太大了吗」④ 「各个组件带响应点击、滑动等的动画了吗」
  ⑤ 「还有转场动画呢?」⑥ 「还有其他行为都要一一对齐,例如邮件展示页面」

★ ① ② 统一顶栏 `AppHeader`
  改造前**六处各写各的**:`AdminUsersPage`(40×40 返回键+16 号标题)、
  `SettingsPage`(20 号标题+40×40「+」+**实心 Theme.surface**)、
  `MailDetailPage`(36×36 + 14 号标题,行高只有 14px 被裁过)、
  `MainPage.SentTab`/`PermissionTab`(通栏、无圆角)、`CommTabBar`。
  尺寸(36/40、14/16/20)、底色(实心白/透明/无)、返回键(有/无)三类都不一致;
  且四处用 `Text('‹')` 当返回键 —— **用字符当图标**(本仓明令禁止,字形随字体变、
  基线对不齐),而 `ICON_PATHS` 里**早就有** `chevronLeft`。
  ⇒ 抽成 `AppHeader`(返回键 + 标题 + `@BuilderParam` 右侧动作区),
    几何复用底部条常量,材质走 `Theme.navMaterial`。已接入 5 处。
  ★ `topInsetPx` 由调用方传:状态栏避让是**窗口级**事实(属页面),
    组件自己读会变成"每层各加一次"(平板侧栏 83+83 双计就是这么来的)。

★ ③ 发件箱"太大"—— 我的理由错了
  我第一版让 `HEADER_HEIGHT = NAV_BAR_HEIGHT`(56),理由是"顶栏与底栏同在一根
  竖轴上,高度不同会一眼看出来"。**那个理由不成立**:
  底栏是**两行**(图标+文字标签)⇒ 需要 56;顶栏只有**一行标题** ⇒ 56 里一半是空白。
  实测 `Row [277,315,1105,476]` = 161px = 56vp,标题那行只占 54px。
  "两根轴上的条要一样高"是把**对齐**理解成了**等高**。真正要对齐的是**左右留白与圆角**。
  ⇒ `HEADER_HEIGHT = 44`(= 可点区下限,返回键装得下)。

★ ④ 按压反馈 —— 两次失败才跑通,两个坑都记进注释
  · **坑一**:`.attributeModifier()` **一个组件只能挂一个**,链两个是**后者覆盖前者**。
    会话组头卡同时挂了玻璃与按压反馈 ⇒ 只生效一个,**编译器不报错、运行不提示**。
    WebUI 是 CSS,类名天然叠加;ArkUI 是单一插槽,"叠加"必须显式做
    ⇒ 新增 `CompositeModifier`。
  · **坑二**:`applyPressedAttribute` **只对自带按压状态机的组件**(`Button`)回调。
    实测:挂 `Button` 上 → hilog 有输出;挂只有 `.onClick` 的 `Row`/`Column` 上
    → **一次都不回调**(按下与常态逐像素相同 `239,244,255`)。而全仓 117 处
    `onClick` 的主体正是纯 `Row`/`Column` ⇒ 那条路对本仓没用。
    改用 `onTouch` + `animateTo`。
  · 底色用**系统点击效果色** `ohos_id_color_click_effect`(不是我自己挑的):
    第一版用 `Theme.surfaceMuted`,实测只差 `3/3/3`,肉眼看不出 ——
    因为"一块面的颜色"与"按下时叠的提示色"在系统色板里是**两个不同语义**。
  设备验证:`onTouch type=0`(Down) → `type=1`(Up) 成对到达,像素确有位移。

★ ④ 滑动判定:从「时长门」改成「速度门」(**设计错误,不是调参**)
  旧门 `SWIPE_MAX_DURATION_MS = 700`("整个手势超 700ms 就拒")。
  而**时长 = 距离 ÷ 速度** —— 它把两个量混成一个 ⇒ 同样的手速下
  **滑得越远越容易被拒**,屏幕越大越严重(平板同一手势像素更多)。
  设备实测(3184×2232,位移恒 542.6vp):
      600px/s→5909ms | 1200→3161ms | 1800→2006ms | 2500→1429ms | 5000→616ms | 15000→123ms
  ⇒ 旧门意味着**只有 ≥5000px/s 才过**,而那一档重复测试也只有 2/4 成功
    —— 用户报的"滑不动/时灵时不灵"就是这个。
  改 `SWIPE_MIN_SPEED = 0.25`(vp/ms,取自上表两档中间)后实测:
      1200px/s → 0/3(正确拒绝:那是拖动)    2500px/s → **0/4 → 3/3**
      5000px/s → **2/4 → 3/3**
  两条判据跟着改形态(**语义不变**:都是"够快才翻页"):
  · `cross-client-gesture` 断言"算的是 dx/ms"——只断言"有个门"会漏掉这次的错
    (旧的时长门**存在**、常量**有名字**、数值**是正数**,三条全过,而真机拒掉正常滑动);
  · `harmony-logic` 的行为判据加了两条**回归钉**:
    `542.6vp/1429ms`(实测的正常甩动)必须过;
    `1200vp/3000ms`(同速度、更远)也必须过 —— 旧门正是在这里误拒。

★ ⑤ 转场动画:查清了,"不做页面级"是**决定**而不是漏做
  WebUI `index.css:1230` 写明:页面级淡入会让**已在那儿的框架**也一起暗一下
  ("观感还是闪"),且用户 2026-09-14 **亲口否掉过**"整屏一起淡",
  所以那一档整体删掉,只保留**局部**动效。鸿蒙侧当前是:
  · `pushUrl` 推页 → **系统自带的滑动转场**(连拍 8 帧验证:第 3 帧能看到
    写信页正在覆盖发件箱,是真实的横向滑入,不是硬切);
  · 局部入场 → `paneRiseIn` / `menuIn` / `calendarSlide`(已接 12 处)。
  所以"加 pageTransition"反而会与用户当时的否决冲突 —— 这一条**不做**,
  理由记在这里,免得下次又当成遗漏。

判据:files=32 ran=32 checks=519 pass=519 fail=0 red=0;baseline 7/7✓。
2026-09-20 10:51:28 +08:00

124 lines
11 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 变异体基线的**自证底本**:每个被变异过的文件在此记下"未变异"时的 sha256。
# 跑完变异后 `sha256sum -c baseline.sha` 必须全 OK(summary.py 把结果打进 RESULT 行)。
#
# 取基线是**有意的动作**,不是随手重算 —— 重算会把"某次变异没还原"永久掩盖掉。
# 每次重算都要在此记一行"为什么":
# 2026-09-20 10:xx baseline 重算(第 8 次)—— 用户:「所有顶栏统一玻璃圆框」「抽象统一顶栏组件」
# 「发件箱太大了」「各组件带响应点击动画了吗」「转场动画呢」「还有其他行为要一一对齐」。
# ① 有意编辑:`MainPage.ets`(SentTab/PermissionTab 顶栏改 AppHeader、挂按压反馈)、
# `SettingsPage.ets`(标题行改 AppHeader)、`AdminUsersPage.ets`(Header 改 AppHeader)。
# ② 两个都跑过 `git diff --quiet HEAD -- <f>` 取证。
# ★ 本轮最大的收获是**两个「看起来做了、其实没生效」的坑**:
# · `.attributeModifier()` **一个组件只能挂一个**,链两个是后者覆盖前者 ——
# 会话组头卡同时挂了玻璃与按压反馈,结果只生效一个,编译器不报错。
# 修法:`CompositeModifier` 显式合成(CSS 的类名天然叠加,ArkUI 是单一插槽)。
# · `applyPressedAttribute` **只对自带按压状态机的组件**(Button)回调;
# 纯 `Row`/`Column`(全仓 117 处 onClick 的主体)一次都不触发 ——
# 实测:挂上去后按下与常态逐像素相同。改用 `onTouch` + 系统点击效果色。
# 2026-09-19 22:xx baseline 重算(第 7 次)—— 用户:「玻璃要更透明/磨砂更有质感」+「判据去芜存菁」。
# ① `pages/SettingsPage.ets` / `pages/MainPage.ets`:有意编辑 ——
# 页面里的玻璃三连(`backgroundColor` + `backgroundBlurStyle`)收敛成
# `.attributeModifier(GlassCardModifier.of(this.bgActive))` / `PaneModifier.of(...)`
# (用户:「定义一个基础玻璃容器给各个组件引用」)。
# ★ 途中一度把 `@Styles glassCard()` 里也替换成了 `attributeModifier`,
# 造成该页 ProfileSection/AppearanceSection/PushSection **整块不渲染**
# (设备实测:Scroll 直接跳到「客户端连接密钥」)。已删掉那个死 `@Styles`。
# ② 两个都跑过 `git diff --quiet HEAD -- <f>` ⇒ 非空(是"我改的",不是变异残留)。
# ★ 本轮到目前为止判据侧修了 4 个**判据自身的缺陷**(都不是放水,是补上它声称却漏判的类):
# · 材质来源只扫 `backgroundBlurStyle` —— 玻璃改成 `backgroundEffect` 后整类漏判
# (实测:塞一行裸 `backgroundEffect({radius:99,saturation:9.9})` 照样全绿);
# · 参数抽取用 `[^)]*`,对 `this.materialOf()` / `{...}` 对象字面量都截断 ⇒ 误伤合法写法;
# · 嵌套判定**没比文件**,拿 A 文件的偏移比 B 文件 ⇒ 判出物理上不可能的红;
# · `harmony-appearance` 数的是**内联字面量**("三元出现 ≥5 次"),
# 收敛成组件后写法变了、行为没变却变红 ⇒ 改成判不变式。
# 2026-09-19 21:0x dsh:baseline 重算(第 6 次)—— 用户要求「基础玻璃容器 + 补出现/消失动画」。
# ① `pages/AdminUsersPage.ets`:有意编辑 —— 「新建用户」表单补 `paneRiseIn()` 过渡
# (原来挂着 `if (this.showCreate)` 却硬弹;用户:「元素的出现消失动画呢?」)。
# 过渡挂在**调用点的 Column** 上,不是 `CreateForm()` 内部:`@Builder` 调用返回 void,
# 链不上修饰符(第一版就写错在内部,是新判据抓出来的)。
# ② `pages/SettingsPage.ets`:有意编辑 —— 所有卡片面 `Theme.surface` →
# `bgActive ? Transparent : surface` + `Theme.cardMaterial`(玻璃卡);
# 并**去掉**两处内层容器的材质(账号列表 / 密钥列表)——
# 那两处是"卡里面的一段列表",两层都铺材质 = 嵌套玻璃(判据 C 条会红)。
# ③ 两个都逐个跑过 `git diff --quiet HEAD -- <f>` ⇒ 非空(是"我改的");
# 另 grep 确认无裸 `BlurStyle.XXX` 残留、无变异留下的空 transition。
# ★ 本次判据侧也改了:C 条从"逐处登记白名单"改成"材质必须来自设计令牌"
# (玻璃从少数例外变成**默认**,白名单挡不住新写的裸枚举)。
# 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、只提示)那一档的又一次实例:
# 它**不假红**(正常提交不会天天红),但也**不会被自动发现** ——
# 我是靠"核每个文件的登记/实际读数"这条主动核查撞上的,不是它自己报的。
#
# 2026-09-19 18:2x baseline 重算(**先核过不是残留,才重算的**):
# ① `pages/AdminUsersPage.ets`、`pages/SettingsPage.ets` —— 我本次的**有意编辑**:
# 给所有"压在彩色底上的字/图标"换前景色(`Theme.surface` → `Theme.accentFg`),
# 并把品牌蓝前景接入 `Theme.accentFor()`(深色下提亮到 WebUI 的 `--c-blue-600`)。
# ② `api/AppearanceApi.ets` —— **与 HEAD 逐字节相同**(`git diff --quiet HEAD` 为空),
# 但底本哈希对不上 ⇒ 说明它在底本取完之后被**合法改过**(提交 `3b5cc63`,
# 09-19 那次"外观保存 400"的修:`payloadFromLocal` 改用 `AppearancePayload`)。
# ⇒ 这是 `stale`(底本过期),不是 `residue`(变异残留)。
# ★ 三个都逐个跑过 `git diff --quiet HEAD -- <f>` 取证,没有一个是"改动忘了还原"。
# ★ 这正是这份文件里那条纪律的第 3 次执行:"重算必须是一次有记录的动作"。
#
# 2026-09-19 20:2x baseline 重算(第 4 次,**仍先核过不是残留**):
# ① `pages/AdminUsersPage.ets` / `pages/SettingsPage.ets` / `common/BackgroundPicker.ets`
# —— 本次的**有意编辑**:语义色前景接入 `dangerFor()/approveFor()/warnFgFor()`
# (深色下红/绿/琥珀要提亮,对齐 WebUI `.dark --c-red/green/amber-700`),
# 以及三级文字接入 `textSubtleFor()`(深色下换二级,见 Theme.ets 里那段理由)。
# ② 三个都逐个跑过 `git diff --quiet HEAD -- <f>` ⇒ 全部**非空**(工作树有改动)
# ⇒ 是"我改的",不是"变异忘了还原"。
# ★ 取证命令留在这里,下次照着做:
# git diff --quiet HEAD -- <file> && echo STALE || echo INTENTIONAL
#
# 2026-09-19 20:4x baseline 重算(第 5 次):
# ① AdminUsersPage.ets / SettingsPage.ets -- 有意编辑:修三元里的裸 Theme.accent
# (前景位置漏改的那 2 处)+ 那一批 textSubtleFor()。
# ② 本次格外重要的一步:我批量替换 Theme.accent -> accentFor() 时,
# 误把 6 处 backgroundColor 也换了(accentFor() 深色给浅蓝 #80AFF9,
# 白字压上去约 1.4:1,主按钮文字会看不见)。发现后已逐处还原。
# 重算前专门复核过三件事(不能只看 git diff 非空就放行):
# - grep -c "backgroundColor(Theme.accentFor())" 得到 0
# - 三个涉及文件里都无 accentFor 背景
# - git diff HEAD~1 里 backgroundColor 只有 calendar 那一处
# (原本是 accentSoftFor,属本次有意改动)
# => 确认无「改错了没还原」的残留在。
# ③ 新增判据 C2(*For() 入口只能用于前景、不得当背景)把这整类钉住,
# 下次再手滑批量替换会直接判红,不必再靠事后复核。
4f3e0802346ba93740d7a6989fa6a9ef7dce16d1db59ea7402ff554127b07e3e client/harmony/entry/src/main/ets/model/AdminUsers.ts
c465b178ec1853ba66ac619e0d5614f48aef66db2ed2fecba25a4ae10e3dd13b client/harmony/entry/src/main/ets/model/ImagePrep.ts
5778eb9cc2af326b9f51ef9d53a66efa058fd0b5cfbef2881b603f9d367ac2a5 client/harmony/entry/src/main/ets/pages/AdminUsersPage.ets
73c66c7045f579c3eb8b8e0aa07803e7c9363b7ae8375972b251633d3ce969be client/harmony/entry/src/main/ets/common/BackgroundPicker.ets
1c8f848ee2d6817beeefd05325cb3b0cdc1d425717769533688019c1e59f2299 client/harmony/entry/src/main/ets/pages/SettingsPage.ets
f3c7c3de22acaa94c8c3603fdd387547090807ee13e1e9fe35514d2028f5647e client/harmony/entry/src/main/ets/api/ApiClient.ets
6550e1892d1ebea82fb75a3d2cf8eaf826186199ff4a0ecf0430b1e3517d8681 client/harmony/entry/src/main/ets/api/AppearanceApi.ets