JianFeeeee
eb4e413c67
用户两条：「玻璃不透明/不够磨砂炫酷，要更基础组件化」＋「判据去掉无意义的、保留有用的」。
★ 玻璃的透明度与质感（逐层调出来的，不是拍的）
· 透明度：`BlurStyle` 是固定档、没有 saturate 旋钮 ⇒ 观感偏灰。
改用参数化 `backgroundEffect({ radius, saturation })`，字段与 CSS `backdrop-filter`
一一对应，于是可以**照抄 WebUI 的数**：`blur(18px) saturate(1.5)`
（WebUI `.narrow-nav`，那里最"玻璃"的一档）。**saturate 才是玻璃感的主要来源**。
· 质感：只模糊+饱和仍然"像一块平的白方块" —— 玻璃板之所以像板靠的是**边缘**。
WebUI 的完整配方是 `box-shadow: 0 8px 28px rgb(0 0 0 / 0.16)` + 发丝描边。
只有模糊没有投影 ⇒ 一片雾；加上投影 ⇒ 一块板。**这是"不够炫酷"的主因**
（我先前两个方向都调了模糊与饱和，方向就偏了）。
· 投影用**系统预置档** `ShadowStyle.OUTER_FLOATING_SM`（"浮起的小面板"），
不是手写 `{radius, color, offsetY}` —— 手写色要么是 `#AARRGGBB`、
要么是 `rgba()`，两者都被判据明令禁止，而那条禁令**是对的**：
手写阴影色在深色下看不见（深底叠深影 = 无变化），WebUI 在 `.dark` 里
要把同一处从 0.16 加重到 0.55 —— 那正是"替系统猜深浅"。
★ 基础组件（用户：「定义一个基础玻璃容器给各个组件引用」）
· `GlassCardModifier` / `PaneModifier`（`AttributeModifier<CommonAttribute>`）：
**一处定义、处处引用**。页面里的玻璃从 15 处内联三连收敛成
`.attributeModifier(...of(this.bgActive))`。
★ 为什么不是 `@Styles`：全局 `@Styles` 读不到 `this`（而玻璃要知道 `bgActive`）；
成员级 `@Styles` 能读 `this` 但**每个 struct 各一份**，MainPage 有 7 个 struct
⇒ 只是把"每处抄 3 行"换成"每 struct 抄 1 份"，没解决问题。
· `Motion.dur()`：接系统「减弱动态效果」（`isAnimationReduceEnabledSync()`，API 23）。
WebUI 有 `prefers-reduced-motion` 硬约束，鸿蒙这边**改造前一次都没调过**。
★ 途中撞出并修掉的**真 bug**（都是我自己的）
· 把 `@Styles glassCard()` 里也替换成 `attributeModifier` ⇒
「我的」页 ProfileSection/AppearanceSection/PushSection **整块不渲染**
（设备实测：Scroll 直接跳到「客户端连接密钥」）。删掉那个死 `@Styles` 即恢复。
· `Theme.shadowColor/hairline` 用了 `rgba()` + `#AARRGGBB` ⇒ 违反本仓两条既有禁令
（"鸿蒙侧不写 CSS 颜色函数"、"半透明属于系统材质/职责"）。改用系统阴影档。
★ 判据去芜存菁：修了 4 个**判据自身的缺陷**（都是它声称在管、实际漏判/误判）
· 材质来源只扫 `backgroundBlurStyle` —— 玻璃改成 `backgroundEffect` 后**整类漏判**。
实测：往 Modifier 里塞 `backgroundEffect({radius:99,saturation:9.9})` 照样全绿。
⇒ 补上这一类，并加"参数必须引 Theme 令牌"（否则只是换个旋钮写死）。
· 参数抽取用 `[^)]*` —— 对 `this.materialOf()` 与 `{...}` 对象字面量都提前截断，
**误伤合法写法**（本次被它误红两次）。改成配对括号 + 去外层花括号。
· 嵌套判定**没比文件**：拿 A 文件的字符偏移去比 B 文件 ⇒ 判出
"MainPage 内含 SettingsPage 的玻璃"这种物理上不可能的红。
假红比漏报更坏 —— 会让人去改本来对的代码（本次差一点）。
· `harmony-appearance` 数的是**内联字面量**（"三元出现 ≥5 次"），
收敛成组件后写法变了、行为没变却变红 ⇒ 改成判不变式
（让位只有一条路径 + 每个窗格都收到开关）。
· 顺带：设备判据找「背景」时只在首屏可见节点里找（而 dumpLayout 只给可见节点），
且我的第一版只朝一个方向滑（越滑越远）⇒ 改成"先回顶、再逐屏向下扫"。
判据：files=32 ran=32 checks=518 pass=518 fail=0 red=0；baseline 7/7✓（第 7 次，逐个取证）。
112 lines
10 KiB
Plaintext
112 lines
10 KiB
Plaintext
# 变异体基线的**自证底本**：每个被变异过的文件在此记下"未变异"时的 sha256。
|
||
# 跑完变异后 `sha256sum -c baseline.sha` 必须全 OK（summary.py 把结果打进 RESULT 行）。
|
||
#
|
||
# 取基线是**有意的动作**，不是随手重算 —— 重算会把"某次变异没还原"永久掩盖掉。
|
||
# 每次重算都要在此记一行"为什么"：
|
||
# 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
|
||
dce63e1b847fb0656afcac0ed034f3d084859ce8246f3051cbc24a1101baa545 client/harmony/entry/src/main/ets/pages/AdminUsersPage.ets
|
||
73c66c7045f579c3eb8b8e0aa07803e7c9363b7ae8375972b251633d3ce969be client/harmony/entry/src/main/ets/common/BackgroundPicker.ets
|
||
beb55081a550d833c4a35b75cc69498d028a0ae0591eb8861c799c1700616d40 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
|