|
|
1094154f26
|
feat(ele): 自绘窗口标题栏 —— 对齐 HarmonyOS 的 PC/2in1 窗口外观
## 问题
用户：「现在窗口外观还是 ele 默认外观，很原始」。
查证了两端在 PC 上的实际做法，差距是**结构性的**：
| | HarmonyOS (PC/2in1) | Electron（改之前）|
|---|---|---|
| 窗口装饰 | `setWindowDecorVisible(false)` 隐掉系统标题栏 | 系统默认标题栏 |
| 顶栏 | 自绘 `AppHeader`（圆角/材质/标题/可选返回键） | 无 |
| 避让 | `Insets` 三量：`statusBar`/`navIndicator`/`windowDecor` | 无这个概念 |
| 拖动 | 系统 | 系统 |
⇒ `grep app-region|titleBarStyle` 在整个 `client/electron/` 命中 **0**。
鸿蒙那边早就走完「内容铺满 + 自绘顶栏」，Electron 还停在最原始的系统窗口。
## 修法
* `frame: false` + `titleBarStyle: 'hidden'` —— 两个**一起**。
只给 `titleBarStyle` 在 Win/Linux 上仍留着系统边框（可拖动、可双击），
观感还是「系统窗口 + 一条自己画的头」；既然自绘窗口按钮 = 框架整个接管，
那圈系统边框就是多余的一层。
★ 不用 `titleBarOverlay`（官方「留系统按钮」那条）：它留的是**系统**按钮，
观感仍由系统决定，与「自绘」目标相反，且 Linux 支持不齐。
本项目只有 win/linux target（无 mac）⇒ 统一一条路，不做两套形态。
* 新增 `src/components/TitleBar.tsx`：固定顶栏 + 左标题 + 右三键。
★ 挂点选在 `main.tsx`、与 `.app-backdrop` 同层，**不在 App 里面** ——
App 的根节点有四个 return 分支（宽屏/窄屏/独页/…），
塞进去就得改四处，漏一处就是「某个页面没有标题栏」。
它自己是 `position: fixed`，与 App 布局零耦合。
## 三条实现纪律（都写进注释了）
① **拖动靠 CSS `-webkit-app-region: drag`，不靠 JS 鼠标事件。**
`drag` 区域由浏览器/系统处理，不受页面重排影响（sandbox 下那种
mousemove 算窗口位置的写法既慢又脆）。
★ 代价：**drag 区域里的交互元素收不到点击** ⇒ 按钮与标题文字都显式
`no-drag`。实测 `elementFromPoint` 命中 `BUTTON.titlebar-btn`（不是拖拽层）。
② **最大化状态是「订阅」来的，不是「查」来的。**
最大化有三条**不经过按钮**的路径：双击拖拽区（系统处理，JS 收不到事件）、
`Win+↑↓`、拖到屏幕边缘的 Snap Layouts ⇒ 只在点按钮时查一次，
图标必然与真实状态脱节。所以主进程用 `pushMaxState` 主动推
（`maximize`/`unmaximize`/进退全屏四个事件），渲染层只订阅。
另：`toggleMaximize` 刻意**不**拆成 maximize/unmaximize ——
双击时序上会多一次异步往返，IPC 往返期间用户可能又双击了一次。
⇒ 读状态与决定动作在主进程侧原子完成。
③ **浏览器里整条不渲染。**
没有 bridge 时 `TitleBar` 返回 `null`；高度占位（`html.titlebar-on`）
由 `main.tsx` 用**同一个** `__AGENTMAIL_SHELL__` 判据挂上 ——
CSS 不会看 bridge，不挂则网页端白丢 36px。
## 尺寸为什么是 36px
鸿蒙 PC/2in1 实测 `windowDecor=37`（见 `MainPage.ets` 的 insets 日志
statusBar=38.6 navIndicator=27.8 windowDecor=37）⇒ 两端窗口控件高度对齐同一量级，
免得并排摆两个应用时一个头厚一个头薄。这里取 36：桌面端按物理像素算，
1x 下更接近常见做法，且 12px 字号不出血。**要改就两端一起改。**
## 顺带记一条踩过的坑（它就在这批代码里）
`preload.cjs` 是 `.cjs`，**不能写 TS 类型标注**。第一版写了
`(cb: (maximized: boolean) => void)` ⇒ 整个 preload **静默**加载失败 ⇒
`window.agentmail === undefined` ⇒ 账号读不到（回退到网页版登录页，
显示用户名+密码，桌面壳里注定失败）+ 标题栏不渲染。
★ 而 `npm run typecheck`（`tsc --noEmit`）**不检查 .cjs**，照常全绿。
已在 preload 注释里写明，并在 `main-process-security.test.mjs` 加了加载闸门
（下一个提交）。
## 实测
`DISPLAY` 起真窗口 + CDP 取证：
shell=desktop hasBridge=true hasWin=true titlebar=true h=36 appRegion=drag
btns=[最小化, 还原, 关闭] btnHitTarget=BUTTON.titlebar-btn
errs=[]（渲染层零异常）
标题栏实测截图含深浅两态，面板圆角与阴影不变。
## 未验（本机无 GUI 交互，只能取证不能点）
最大化/还原按钮点击、双击标题栏、**关闭进托盘**（这个最需要小心，
点错会把应用整个退出）。上一条留待有人手上有真桌面时验。
|
2026-10-04 11:07:56 +08:00 |
|
|
|
5621cf97fa
|
fix(webui): 深色模式「只有通信页正常」—— 根因不是 alpha，是底没暗下来
用户原话：「webui 只有通信页面的深色模式正常了，剩下的三个页面深色模式
可读性都极差」。99a2d7a 只修了 `.glass-card` 那块（通信页走的就是它），
其余三页的面板走 `html[data-bg='on'] .bg-white` → `--bg-glass`，没跟进。
我第一版把这三档 alpha 从 0.9/0.84/0.55 降到 0.08/0.05/0.04，**仍然不够**。
## 正确判据：逐个叶子文本节点，采样它**真实渲染的底色**
之前的探测全在数 DOM 祖先链上的 backgroundColor，而 `.app-backdrop` 是
`position:fixed` 的**兄弟节点**（不是祖先）⇒ 永远采不到壁纸与遮罩，
只能退回"壁纸均值 213"→ 得出"底是亮的"但与屏幕不符。
改成截图后用 pngread.mjs 逐像素采样：对每个叶子文本节点取其 bbox 内
出现最多的颜色当作它的实际底色，再算 WCAG 对比度。得到决定性的数字：
通信 最差 1.87:1 ／ 日历 最差 **1.19:1** ／ 联系 1.64:1 ／ 我的 1.42:1
（日历页「廿五」fg=rgb(138,146,161) bg=rgb(134,132,132) —— 字和底几乎同色）
## 根因：`--bg-dim` 是**比例**，比例压不住一张**浅**壁纸
用户 jianf 的壁纸均值 RGB 213（浅照片）、dim=56 ⇒ 213×0.44 ≈ 94，仍是中灰。
近白正文对 94 只有约 3.6:1；次要文字 gray-400 对 94~134 只有 1.2–1.4:1。
**没有任何文字颜色能救** —— 这与 background.test 的契约「玻璃是白色材料」
是同一件事的两面：深色下敢用近白基材，前提就是「背后是深底」，
而这个前提此前没人保证。
## 改动
1. 新增 `--bg-dim-min`（`:root` 0% / `.dark` 92%），遮罩取
`max(var(--bg-dim), var(--bg-dim-min))` —— **取 max 而非覆盖**，
用户调得比下限高时仍以用户的为准，不下调他的选择。
2. 玻璃 alpha 收到 0.04/0.03/0.02（第三层从 `transparent` 改为
`--bg-glass-nested3` 的小值：深色下"透明"= 浅壁纸直接透上来）。
3. `.dark` 的 `--glass-card-wall-a` 0.1 → 0.04 与其它档对齐。
4. 浅色分支完全不变（dimMin=0% ⇒ max() 等价于原值，实测 glass 仍是 0.88、
遮罩仍是 `rgba(255,255,255,0.56)`）。
## 验收（1280×800 真渲染采样，逐个叶子文本节点）
修复前：通信 1.87 / 日历 1.19 / 联系 1.64 / 我的 1.42（<4.5 的节点 17/88/22/26）
修复后：通信 6.14 / 日历 4.90 / 联系 4.96 / 我的 5.38（<4.5 的节点 **0/0/0/0**）
代价（明写在案）：深色下浅壁纸被压得很淡（92%）。这是可读性优先的取舍，
壁纸仍在（8% + 玻璃质感 + 模糊），只是不再是主体。
## 判据（theme.test 30 → 38，已同步 run-all 的棘轮）
新增 4 条，针对"归因错"这件事本身：
· 深色下有压暗下限且 ≥90%（浅色下不干预）
· 下限真的作用在遮罩上（**不是只定义变量**）
· 用最坏输入（纯白 255 壁纸）实算 gray-400 对合成底 ≥ 4.5:1
· 判据自检：拿掉下限必须判红
变异自检跑过：下限改回 56% ⇒ 2 条红；下限定义了但没用上 ⇒ 1 条红。
`--revert-mutation` 之外的基本面：theme 38/0、background 44/0、
cross-client-theme 15/0、appearance-defaults 4/0。套件 broken 由 4 降到 3
（build stamp 因重构建而转绿），red 23 不变，无新增失败。
|
2026-09-18 01:08:04 +08:00 |
|
|
|
99a2d7ad7e
|
fix(webui): 深色模式真的落地了 —— 之前 .dark 是「有意留空」的
用户报「深色模式可读性差」。实测（1280×800，读页面计算值）拿到两个数字：
· .glass-card 合成成 rgb(237,237,237) 白卡，而其上 --c-gray-900 文字是
rgb(243,245,248) ⇒ **1.07:1 的白底白字**
· .nav-rail 合成成 rgb(188,189,190) 浅灰条，未选中文字只有 4.03:1
根因写在 index.css 自己的注释里：`.dark { /* 有意留空 */ }`。当年留空的理由
是「组件没有 dark: 变体，只换令牌会半深不浅」——**方向反了**：组件写的是语义
色阶（bg-white / text-gray-900），灰阶反转后本来就会自适应；真正没适配的是
**手写 CSS 里那几处硬编码白色**（.glass-card 的 0.92、--nav-bg 令牌），
它们不在 --c-* 色板里，所以「色板变量已全覆盖」的判据一直是绿的。
改动：
1. .glass-card / .nav-* 全部改走令牌，主题之间只差 alpha；
深色给 --glass-card-a: 0.06 + --nav-bg: 30 35 44/0.72。
遵守既有契约（background.test「玻璃是白色材料」）：**基材恒为白**，
只降 alpha，绝不换成深色层。
2. CalendarView 的非本月农历小字 text-gray-300 → gray-400/500。
gray-300 在这套调色板里是**分隔线档**（全仓 68 处 border-gray-300、
当文字只有 5 处），深色下它是 61,68,81，落在深卡上 1.49:1；
而 gray-400 在深色 4.66:1、浅色白卡 2.54:1，两端都更好。
3. 判据：theme.test 补 3 条（手写 CSS 不许有绕过主题的硬编码白色表面 /
深色卡片 alpha 必须降低 / **按实际 alpha 合成后**正文须 ≥4.5:1，
即把 1.07:1 那个事故写成可计算的断言）。background.test 那条
「.dark 里不许出现 --nav-*」**方向反转**为「必须有且底暗字亮」——
它原来守的是「还没有深色主题」这个前提，其注释本就写明
「真做深色主题时这条要一起改」。
验证（不是"改了就算"）：
· 自建探针遍历 **9 个页面**（三个通信子页签 / 邮件详情 / 日历 / 联系人 /
我的 / 写信 / 地址补全弹层）：修复前通信 14 处、日历 74 处、
联系人 13 处低于 WCAG AA；修复后 **9/9 页面 0 处**。
· 三条新判据逐条**变异自检**（还原修复即变红，且失败信息自带药方）；
浅色三个取色值与改动前**逐字节一致**（导航 0.72 白玻璃、卡片 0.92 白）⇒ 零回归。
· theme.test 34 通过 / background.test 44 通过 / tsc 干净。
· 已按 deploy/redeploy-gateway.sh 部署到 systemd 实例，后置清单自动项全绿，
并在生产实例上复量 9 个页面（同为 0 处）+ 端到端发信（状态 read，非仅入库）。
#深色模式 #可读性 #WCAG
|
2026-09-17 22:32:25 +08:00 |
|
|
|
d81ab319e4
|
fix(webui): 动画全量盘点 —— 两处死动画 + 一处过宽；并把盘点变成常驻判据
用户：「全面检查整体的动画」。查出来的不是"好不好看"，而是**接线断了**（三种形态都很难靠肉眼发现）：
① @keyframes pane-in **定义了两处**、挂在 `html.view-switch .pane-enter` 上，而 `.pane-enter`
**没有任何组件在穿** ⇒ 规则看着像"页面有入场动画"，一次都不会播（9aa702b 删整面板入场时的遗留）。
已连规则与 keyframes 一起删干净（注释里我把"连它一起删"写了却没做，被新判据当场抓到）。
② `.animate-menu-in`（菜单入场）keyframes 与规则都写好了，**同样没人穿** ⇒ 所有下拉/候选菜单
其实是"啪"地出现。已接到 AddressInput 的候选菜单上；线上实测捕捉到 menu-in @140ms。
③ `html.view-switch .glass-control` 把"菜单入场"错当成"控件档入场" ⇒ 每次切视图，页面上
**所有**按钮与输入框一起淡入位移（几十个元素同时动，闪与卡顿的现成来源）。已收窄为
只给 `.animate-menu-in`；线上实测切视图只剩 pane-rise + 导航项的颜色过渡。
判据化：新增 test/animation-audit.test.mjs —— 每个 @keyframes 都必须有人穿（死动画闸门）、
弹层必须带菜单入场类、不得再出现"整档控件一起动"的切视图规则、reduced-motion 必须显式
覆盖挂载即播那档。写判据的过程本身抓到两处我自己的不一致：删了规则却留下孤儿 keyframes；
以及正则把 reduced-motion 名单里的 `html.view-switch .glass-control` 误判成"还在让它动"
（已改为只扫顶层规则，媒体查询块里的"关掉名单"不算）。
|
2026-09-15 08:51:18 +08:00 |
|
|
|
f5d05755b7
|
fix(webui): 窄屏两处 —— 收起补反向 morph、编辑态不再隐藏底部导航
用户：「收起没有动画，且输入框弹出后，底部导航栏会消失，再次点击界面导航才会出现」
① 收起没动画：打开有 morph、收起是瞬间卸载（不对称）。补反向 morph：
打开时把球的矩形存进 originRef（球在框打开时不在 DOM 上，收起草稿时取不到），
收起时从当前形状缩回球的位置/大小（160ms），**播完再卸载**（先卸载就没得播）。
finished 被取消时也会 reject，两种情况都落到"收起"。
② 底部导航消失：测量结果是 nav 的 rect = 0,0,0,0，即 **display:none**，不是被挤出去——
根因是 `.form-editing .narrow-nav { display: none }` 撞上"回复框展开即自动聚焦 textarea"
（form-editing 由 main.tsx 在任何输入框获焦时挂上）⇒ 一弹框导航就消失，点到别处才回来。
而这条隐藏已经没必要：viewport 声明了 `interactive-widget=resizes-content`，键盘弹出时
浏览器会重排布局，导航自然落在键盘上方。已删掉该隐藏。
顺带：详情/列表两个窄屏根节点补 min-h-0（flex 子项默认不可压缩，回复框一撑会把导航顶出可视区）。
判据 +4（编辑态不隐藏导航、viewport 声明 resizes-content、两个根节点带 min-h-0、收起有反向
morph 且先播完再卸载）。变异：抽掉 min-h-0 → 红；收起改回瞬间卸载 → 红；把 display:none
放回去 → 红。
★ 一处判据自身的坑：判断"还有没有那条隐藏规则"必须用**剥注释版**——我第一版用原文判，
被我刚写的那段解释性注释（里面原样引用了那条规则）判红，与 read.mjs 里记的同一形态。
窄屏（420x820，真实邮件）实测：初始/开信/回复框弹出并聚焦(form-editing)/收起后 ——
底部导航高度都是 51px 且在视口内；收起时框上有 160ms 动画。
|
2026-09-15 08:45:54 +08:00 |
|
|
|
110d457535
|
fix(webui): 回复球改成容器变形 + 摘掉邮件列表的入场动画 + 全局控件过渡不再补间阴影
用户连着报了三件（2026-09-15）：
① 「邮件页面那个蓝色的圆形是聊天图标点击没有任何动画」
上一版我只给了回复框一个 150ms 的 opacity 淡入 —— 观感上等于没有。用户要的形态与
写信页一致：**球自己长成回复框**。现在蓝球带 data-morph-trigger、onClick 里就地记下
自己的矩形（currentTarget 最准），回复框挂载时用 useLayoutEffect 在**首帧之前**把
CSS 淡入关掉并接上 morph（220ms，只动 transform/opacity/border-radius）。
② 「邮件列表会闪」——**我上一版引入的回归**。
我把 pane-rise 挂到了邮件列表上，而 view-switch 窗口在**选中一封邮件**时也会触发
（narrowPane 是依赖之一）⇒ 每点一封信整个列表重放一次入场。已摘掉：列表这类
"选中即变"的面不许挂入场动画，只有日历（真的换视图）保留 pane-rise。
判据改成反向的"列表必须不动"，把这个回归钉死。
③ 「主页点击按钮有明显的卡顿」。
全局 `button,a,input,textarea,select,[role=button]` 的 transition 里带了一条
`box-shadow var(--dur-base)` —— 阴影是**绘制**属性，每次 hover/active 都要把元素
连同阴影覆盖区重绘，且它挂在所有交互元素上。已去掉该补间（阴影瞬切），
判据钉"全局控件过渡不得含 box-shadow"，个别表面仍可自己写。
另补一个真缺口：prefers-reduced-motion 原先只覆盖"窗口触发"那档，**没覆盖"挂载即播"
那档（裸 .rise-in）**，两处 morph 也没走这个开关。现已全部纳入；判据加严到"必须行首
就是 .rise-in"（第一版被 `html.view-switch .rise-in,` 满足掉，变异测试才发现假绿）。
判据合计 84 通过 0 失败（变异都验过：删裸 .rise-in → 红；把 box-shadow 加回 → 红；
列表挂回 pane-rise → 红；useLayoutEffect 换回 useEffect → 红）。
|
2026-09-15 08:15:22 +08:00 |
|
|
|
436de6ee4d
|
feat(webui): 回复/转发动画真的会播了 + 写邮件改成「按钮长成整页」
用户两问：
① 「回复邮件那个按钮还是没有动画」——**我上一版的锅**：我只给回复框/转发面板挂了
`rise-in`，但那条规则写作 `html.view-switch .rise-in`，而 view-switch 窗口只由
视图/页签/窄屏/写信 四个状态触发。**回复/转发根本不触发它** ⇒ 类挂着、动画永远不播。
我当时的"验证"只覆盖了写信页（恰好命中四个触发之一），另外两处只验了类在不在。
② 「写邮件的按钮点击不应该是一个按钮扩大变成页面的动画吗？」——是，这才是对的形态。
改法：
- 拆两档作用域：`.rise-in` **挂载即播**（给"点了才出现"的面：写信页/回复框/转发面板），
`.pane-rise` 由 `html.view-switch` 窗口触发（给常驻面板：列表栏/日历）。
首屏不会有一堆东西同时淡入，因为前者只在用户动作时挂载。
- 新增 lib/composeOrigin.ts：在**捕获阶段**记录被点元素的矩形（React 的 onClick 在冒泡
阶段，晚一步就取不到），带 2s 时效（防止"点了别的按钮 → 稍后被程序化打开写信页"时
从旧按钮长出来）；优先认 `data-compose-trigger`，退一步认最近的 button，
这样 4 个入口不必逐个改（漏一个的后果是静默无动画，与 ① 同一种失败）。
- ComposePage：有起点就 el.animate 从那个矩形长成整页（220ms，只动
transform/opacity/border-radius —— 合成器可做，不动宽高），没起点退回 rise-in。
两条动画都动 transform/opacity，所以渲染期就决定挂哪一条，不同时挂。
判据（narrow-layout +6）：rise-in 必须不带 view-switch 前缀、常驻面板必须用 pane-rise
且 window 规则在、reduced-motion 覆盖两档、morph 只动合成器属性、有起点 morph /
无起点 rise-in。生产实测：点悬浮球后 document.getAnimations() 里 ComposePage 根节点上
有 running 的 220ms 动画，首帧 translate(-564px,396px) scale(0.0549)、opacity 0.3
（悬浮球 56px ⇒ scale≈0.055）。回复框/转发面板因该账号收件箱为空未点穿，但触发条件
已从我写错的"窗口触发"改成"挂载即播"。
|
2026-09-15 08:09:36 +08:00 |
|
|
|
e3b7f8f421
|
perf(webui): 动画卡顿三处治理 + 覆盖列表/日历
用户：「动画卡顿严重，且绝大部分场景还是没有流畅的动画」。
① 提层：`html.view-switch .rise-in` 里加 will-change: transform, opacity。
这一档只动 opacity+transform，但没提层时浏览器不保证合成器接管。
写在 view-switch 窗口里（只在切换的 ~400ms 内有效），不是写在元素上 ——
常驻 will-change 会把每个面板都变成常驻图层，白吃内存。
② 去掉触发动画时那次强制同步重排：App.tsx 原来用 `void root.offsetWidth`
让 remove/add 分属两帧，代价是每次切视图都逼浏览器把整个文档布局算一遍，
而这笔账正好落在动画第一帧上。改成两次 rAF，同样分两帧，不付重排的钱。
③ 覆盖：列表栏与日历根节点也穿 rise-in ⇒ 切 通信/日历/工作列表 都有入场，
仍只动"新出现的那一块"，骨架不动（避免 09-14 那次"整屏闪"的老问题）。
判据（narrow-layout +3）：will-change 必须在 view-switch 规则里；
App.tsx 不得再有 `void root.offsetWidth`（且必须用 requestAnimationFrame）；
MailList/CalendarView 必须穿 rise-in。变异：抽掉 will-change → 红；
把强制重排放回去 → 红；复原 → 77 通过 0 失败。
★ 顺带纠错：上一轮我报"整页 146 个元素带 backdrop-filter / 动画子树 76 个全带模糊"
是我探针自己的 bug（`webkitBackdropFilter` 取到 undefined，`undefined !== 'none'` 恒真，
连 <path>/<META> 都被算进去）。修正后实测：真模糊 0 个、同时动画 1 个、
帧间隔中位/最长 17ms（60fps）。所以"卡顿"不是我能在本机复现的形态 ——
需要知道你看的是哪一端/什么状态（见回信）。
|
2026-09-15 07:57:04 +08:00 |
|
|
|
6ee58fa28a
|
fix(webui): 局部入场动画补回（写信页/回复框/转发面板）—— 你猜对了，是被整条删掉的
用户（2026-09-15）：「从发信按钮到发信页面，从聊天按钮到聊天输入，以及转发拉起输入框
都没有对应的动画，所有的动画都消失了，是不是我批评一下用力过猛你就全给删了」
是。9aa702b（09-14，回应「部分动画十分不合理，会导致页面大范围的闪动」）把
整条删掉、换成 ，
而 **.pane-enter 没有任何组件在穿**（grep 确认）⇒ 这一档从「全部一起动」变成
「一条都不动」，连这三处局部、有明确语义的入场也一起没了。
批评针对的是**整面板/整屏**一起淡入（骨架跟着暗 = 闪），不是局部入场。所以补回
只动「刚出现的那一块」：@keyframes rise-in（4px + 不缩放，150ms，与 pane-in/menu-in
同一套尺子），仍挂在 view-switch 触发窗口上，骨架一动不动。
判据（narrow-layout 新增 3 条）：keyframes+规则存在、三处目标面都穿（MailView 里
回复框与转发面板各一处）、且 reduced-motion 块里也有它。变异：去掉转发面板那处 → 红；
从 reduced-motion 里删掉 → 红；复原 → 74 通过 0 失败。（第一版取错了 reduced-motion
块——文件里有多个，取到全局那个，判据自己假红，已改成逐块检查。）
生产实测（8180，点「新建邮件」后 90ms 读计算样式）：animationName=rise-in、0.15s、
cubic-bezier(.22,.61,.36,1)，此时 html 正带 view-switch。
|
2026-09-15 07:49:25 +08:00 |
|
|
|
e6048e9914
|
fix(webui): 候选菜单改用不透明弹层表面 —— 半透明+背景模糊把背后的表单糊进了列表
用户（2026-09-15，看着抄送/转发两处的候选）：「你在选择框的模糊逻辑上用力过猛，
导致只能显示一条信息」。
实测（生产构建 4c2bf26，浏览器里读计算样式，壁纸开）：
菜单 background: rgba(255,255,255,0.5) + backdrop-filter: blur(8px) saturate(1.1)
而它浮在**表单自己**之上（主题输入框 y=294 正落在菜单 284-510 下面）
⇒ 背后的输入框/标签被糊一遍再从半透明列表底下透上来，只有顶行还读得清。
根因与 2026-09-14 那次「模糊叠模糊」同族：把**控件档**（0.5 透 + 8px 模糊）用在
**弹层**上。控件背后是面板自身，透一点好看；弹层背后是别的内容，透就是叠两份内容。
- 新增 .popup-surface（rgb(var(--c-white))，不取 backdrop-filter；壁纸开时单独压回不透明，
否则会撞上 html[data-bg='on'] .bg-white 那条接管规则）
- .popup-surface 并入「滚动区不淡」豁免（原来只认 .glass-control，换类会漏掉 → 弹层又被洗白）
- AddressInput 菜单 glass-control → popup-surface；旧断言 nav-merge.test.mjs:109 钉的正是
那个错的意图（『地址建议菜单』必须用控件档），已改钉新意图
判据：narrow-layout 新增 4 条（表面不透明/不取模糊/壁纸开时也压回/菜单穿的类）+
nav-merge 反向对照。两侧都验：变异①换回 glass-control → 红；变异②改回 0.5 → 红；
复原 → 71 通过 0 失败。生产实测：rgba(...,0.5)+blur → rgb(255,255,255)+无模糊。
|
2026-09-15 07:46:54 +08:00 |
|
|
|
5544edabaf
|
fix(webui): 窄屏「我的」页补上圆角（与日历那次同一个根因，另一条分支）
用户（2026-09-14）：「webui的『我的』页面，还是没有圆角」。
根因不在 AccountPage —— 在 App.tsx 的**分支**：没有列表栏的页面（我的/管理/写信）
走 `<div className="flex-1 min-h-0 flex">{main}</div>`，而 `.narrow-shell > *` 那条
圆角正落在这一层上。它是透明的、且 overflow: visible —— 有底色的是它里面的页面
根节点（`… bg-white`），内层直角从透明外壳里原样戳出来。
这与日历那次（`.narrow-stack` / `.cal-panes`）是同一条教训的**第三处**：
圆角必须给到**有底色的那一层**。
实测（390x844，真浏览器读渲染像素）：
改前 面板 radius=0px，四角像素 255,255,255（纯白＝方角）
改后 面板 radius=14px，四角像素 = 页面底色 249,250,251（被切掉）
宽屏 1280 一直是好的（对照：与收件箱详情栏的四角剖面逐像素一致）
改法：那一层挂 `narrow-solo`，圆角写在 `.narrow-solo > *`（有底色的那层），
**不写 overflow:hidden**（这层下面的子元素自己就是滚动容器，与 app-shell 那段同一个坑）。
横屏紧凑的两栏（`narrow-duo`）照 `cal-panes` 只给**外沿**：首元素左两角、末元素右两角。
判据 narrow-layout 新增 3 条（规则与 JSX 按类名接得上 / 不写 overflow:hidden /
两栏只给外沿）；变异自检：把 `narrow-solo` 类名去掉，判据立刻红。
已部署（d3f6f3b·0914-1904）；.deb 与 dist 同批重打。
|
2026-09-14 19:07:28 +08:00 |
|
|
|
59b2575838
|
fix(webui): 底部导航选中态只换颜色（去掉背景块与顶部指示条）
用户：「同时底部导航栏选中对应的文字和图标变色即可」。
- NarrowNav：删掉 bg-blue-400 顶部指示条
- index.css：.narrow-nav .nav-item[data-active='true'] 背景置 transparent——
只作用在底部导航；宽屏侧栏是 48px 竖条、没有文字标签，那块底色是它唯一的选中线索
- 图标本就是 stroke=currentColor，所以跟着文字色走（判据钉住这一点）
- 判据 nav-merge ④ + 变异自检：把 bg-blue-400 加回去，④ 立刻红
|
2026-09-14 17:50:34 +08:00 |
|
|
|
6702cc2f5e
|
fix(webui): 窄屏日历/详情的圆角——圆角要给到「能裁剪的那一层」
用户（2026-09-14）：「我这边看还是方角」。上一轮我只修了宽屏那条分支，
窄屏（手机/平板，<1024px）当时仍然是方角 —— 这次按像素量到了。
## 实测（真浏览器读渲染像素，不是读声明）
390x844 日历页左上角：
改前 (255,255,255) 纯白 → 方角；面板 computed radius = 0px
改后 (249,250,251) 页面底色 → 圆角；上边缘内缩 8px
## 根因：圆角落在**裁不住东西**的那层上
窄屏走 NarrowStack（`list`+`main` 的覆盖式容器，日历与收件箱详情都用它）：
.narrow-shell > * ← 14px 加在这里（App.tsx 的 flex-1 min-h-0 flex）
NarrowStack 根 ← overflow:hidden，但 radius 0px
absolute inset-0 flex ← 透明
gridPane (bg-white) ← 0px，直角原样露出来
`overflow: visible` 的透明 flex 容器拿到圆角 = 什么也没发生。
NarrowStack 的根节点是**唯一**同时具备「自己 overflow:hidden」与「包住有底色那一层」
的层，圆角必须加在它上面 —— 加给它，底层页与滑入的覆盖层就一起被裁到圆角里。
顺带修好一处同类问题：**收件箱详情在窄屏也是方角**（同一个容器），
以前没人报过，这次一起圆了（实测同上）。
## 判据
narrow-layout 新增 2 条，分开钉两件事（分开一条都不算修好）：
① 那层自己带上面板圆角（类名与 CSS 规则接得上）；
② 那一层同时具备裁剪能力（overflow:hidden）。
三组变异全部红在对的那条上（去掉类名 / 去掉 border-radius / 去掉 overflow-hidden）。
narrow-verify（手动探针）新增**读像素**的能力与两条判据 —— 这件事只有像素能回答：
computed radius 是 14px、角上 2px 处"谁在画"也指着面板本身，**但渲染出来仍是方的**
（圆角加在没底色的层上，被内层直角原地盖掉）。所以这里截 1x1 再解 PNG，
只用 zlib，不引图像库。方角=255,255,255 / 圆角=249,250,251，两个数字就能分辨。
|
2026-09-14 16:51:31 +08:00 |
|
|
|
d78f19fe9a
|
fix(webui): 日历页面补上圆角（圆角要给到「有底色的那一层」）
用户（2026-09-14）：「日历页面还没有添加圆角」。
根因不是「忘了写 border-radius」—— 外壳那条 `.app-shell > *` 是生效的，
它给日历**根节点**加了 14px 圆角。问题是根节点写着
`flex-1 min-w-0 flex min-h-0`、**自己完全没有底色**：
真正白底的是里面那两块面板（网格栏、右栏），它们的直角从透明外壳里戳出来。
所以 `getComputedStyle(根).borderRadius` 一直是 14px，看上去却全是方角。
两处不能照搬收件箱做法的地方：
① 网格栏与右栏**不是两张卡**（中间只有 1px 分隔线，没有外壳间距）
⇒ 只能给**外沿**：左边那块给左两角、右边那块给右两角。
内侧也给会露出底色缺口。
② 右栏外面还套了一层容器（管 `lg:w-[400px]` 与 `border-l`，自己不上色），
真正上色的是它里面的 DayAgendaPane / CalendarEventEditor
⇒ 圆角要**再往下给一层**，只加在容器上会被内层直角原地盖掉。
（左栏本身就是白底面板，不能再往下给：它的第一个子元素是工具条。）
实测（1280×800，真浏览器读渲染像素）：
改前 左栏 radius=0px、右栏 radius=0px，四个外角都是白像素（方角）
改后 左栏 `14px 0px 0px 14px`、右栏内层 `0px 14px 14px 0px`，
四个外角像素都等于页面底色（被切掉）；上边缘内缩 8px，
与收件箱详情栏（对照）完全一致；内侧分隔线两侧保持直角。
判据：narrow-layout 新增 4 条 —— 钉的是「规则与 JSX 接没接上」「给的是哪几条边」
「右栏有没有再往下给一层」「左栏有没有多给一层」，不是那条 14px。
wide-regression 新增一条**渲染层**判据：从 `elementFromPoint` 沿祖先链找第一个
自带底色的元素，四个外角都必须正是那个圆角面板（光看 computed style 区分不了，
因为被盖掉的形态 computed 也照样是 14px）。
顺手修掉 wide-regression 里一条**假失败**：`#root > div` 现在指向壁纸幕布
（`app-backdrop` 后来挂成了 `#root` 的第一个子节点），于是「仍是三栏并排」
一直报「栏数=0」，而三栏好好的。假失败比没有判据更贵 —— 看的人会去查一个
本来没坏的东西。
|
2026-09-14 16:05:15 +08:00 |
|
|
|
00c4df4e98
|
fix(webui): 滚动边缘淡出按容器高度封顶，弹层不再淡（「渐变过猛」）
用户（2026-09-14）：「你有的地方渐变用的过猛了，比如收件人候选那里」。
上一轮加的「边缘淡出」写的是上下各固定 12px —— 那是拿**长列表**的内边距
（10px）当尺子量的，可它作用在**所有** `overflow-y-auto` 上。
实测收件人候选菜单整块只有 58px 高（提示行 22px + 一条候选 34px），
上下各淡 12px 共 24px ⇒ 小半个菜单是渐变的，那条唯一的候选底部被洗白。
根因不是「12px 太大」，而是**固定像素用在了高度不固定的东西上**。所以：
1. `.overflow-y-auto` 的淡出宽度改成按可见高度封顶 `min(12px, 10%)`；
2. 弹层（`.overflow-y-auto.glass-control`）**不淡**：它是圆角＋边框的独立
表面，内容被边框截住已经「有交代」，而它高度小到淡出只剩负作用。
实测（Chromium 渲染后读像素，不是读声明的字面）：
60px 容器：新规则淡出 6px（10.0%），旧规则 12px（20.0%）
700px 容器：新规则淡出 12px（1.7%）—— 高列表观感不变
真实候选菜单：`getComputedStyle(...).maskImage` 从 12px 渐变变为 `none`
判据：narrow-layout 新增 4 条，钉的是**结构**而不是那个数字 ——
淡出宽度必须带上限、两个上限都必须 > 0、弹层必须豁免、两套前缀都要在。
（第一版只取了 `min(` 里的 px 就断言 > 0，把 10% 改成 0% 时照样绿，
被变异测试抓到后重写。）
|
2026-09-14 15:44:08 +08:00 |
|
|
|
1717863c87
|
fix(webui): 手势与横向滚动分家 + 纵向滚动边缘淡出
用户给了两条具体信息（这比我自己猜五轮都管用）：
「横向滚动条会与切换视图的手势冲突，我觉得周视图需要卡严条件，
同时我说的其他硬截断是对应内容项上下滑动会直接被切断」。
## ① 手势卡严（周视图）
冲突是真的：周视图窄屏下必须横向滚（`overflow-auto` + `min-w-[36rem]`），
而我又给整页加了左右滑动翻页 ⇒ 同一次横滑既想滚又想翻，两边都不好用。
规则定死：**手势从可横向滚动的区域里起手，就归滚动条，完全不参与翻页判断**
（触点沿祖先链查找 `overflow-x: auto/scroll` 且真的能滚的容器）。
想翻页就从别处滑（例如上方标题栏）。
## ② 纵向滚动边缘淡出
滚动条本身是"一刀切"：卡片滚到边缘被硬生生截断 —— 这就是用户说的"直接被切断"。
给纵向滚动容器（`.overflow-y-auto`）加 12px 上下渐隐遮罩，切得有交代。
只作用在**纵向**容器：横向滚动有自己的滚动条，加纵向遮罩会跟它打架。
## 过程记录（值得记）
这两条改动**第一次没有生效**，因为部署失败了：`/tmp` 是 tmpfs 且已 100% 满，
而部署脚本把构建产物写到硬编码的 `/tmp/agentmail-gateway-build-*` ⇒
`no space left on device`。我差点把"旧构建上的测量结果"当成"改动无效"。
清理后（清掉我自己的探针脚本/截图/旧构建，约 950MB）部署成功。
⚠️ `/tmp` 现在仍占 91%（`gocache` 4.5G 等不全是我的），**下次部署可能还会撞上**；
脚本改成尊重 `TMPDIR` 才是根治（未做）。
|
2026-09-14 14:35:43 +08:00 |
|
|
|
2e42aacc07
|
fix(webui): 修「列表与正文之间那条大空隙」—— 包装层撑满而列表面板固定 320
用户发截图指出：「外框列表和右边正文那么大一个空隙」。
## 根因（在代码里很难看出来）
我为了让「通信」有内部页签与悬浮加号，给中栏加了一层包装 div，它写着 `flex-1`；
而里面的列表面板是 `lg:w-[320px]` **固定宽度** ⇒ 包装层把剩余宽度全占了，
**空隙在包装层里、不在任何面板里** —— 于是既看不出是哪一层的错，也不像"布局 bug"，
看起来就像设计上多留了一条白。
## 改法
`.app-shell .comm-pane { flex: 0 0 auto; width: 320px }` —— 宽屏下中栏贴住列表面板的宽度。
窄屏不动：那边外壳是**列**方向，`flex-1` 管的是高度，宽度由 `w-full` 决定。
## 实测（自有浏览器）
宽屏 1600: 包装层 320 / 列表 320 / 详情 1180 → 包装层内空隙 0px，到详情 10px（设计间距）
窄屏 390: 包装层 370 / 列表 370 → 包装层内空隙 0px
顺带说一句：这条与前面「日历没有圆角」「列表项变成一张大框」是**同一个包装层**引出的
三个症状（撑满宽度 / 内层直角戳出圆角 / 每项没有独立卡）。包装层是我为合并导航加的，
当时的验证只看了结构（页签在不在、点得到点不到），**没有量过宽度**，
所以它一连串地出问题。现在宽度已有判据（上面的数字就是判据）。
|
2026-09-14 14:29:27 +08:00 |
|
|
|
83cb7528fb
|
fix(webui): 玻璃是白色材料 —— 深色模式只降 alpha，不换基材
用户纠正我：「什么叫深色模式也是玻璃？深色模式不应该是浅色玻璃吗？」
**他是对的，而且这是个概念错误，不是一个数值错误。**
我原先把深色模式下的玻璃写成 `rgb(15 23 42 / .72)`（一整层深色）—— 那不是玻璃，
是把面板压黑。磨砂玻璃是**白色材料**；深色模式下要做的是**降低这层白的透明度**
让深背景透出来，而不是换基材颜色。
## 更深一层的真因（这才是"半深不浅"的源头）
`.dark` 里写着 `--c-white: 24 27 33`（近黑），而**所有**玻璃面都写成
`rgb(var(--c-white) / α)` ⇒ 深色模式下**整个玻璃层系**（正文面、嵌套卡、控件、
卡片）一起变深，而 Tailwind 的浅色工具类照旧 ⇒ 界面半深不浅。
用户先看到的是"导航栏为什么还是黑色"，根子在这里。
## 改法：让这个错误写不出来
- 新增 `--glass-base: 255 255 255`（**两个主题都一样**），玻璃面的基材只有这一个来源；
- 8 处玻璃面从 `rgb(var(--c-white) / α)` 改为 `rgb(var(--glass-base) / α)`；
- `.dark` 里的玻璃相关覆盖全部清空并写明：**深色主题必须与组件侧的 `dark:` 变体
一起做**（现在一个都没有），单独生效只会"面变深、字还是深色"，读不了；
- 删掉提前写下的 `.dark .glass-card`（它按"深色主题已存在"写，实际只会让卡片
在浅色页面上几乎消失）。
## 判据（background.test.mjs，34 条全绿）
三条新的，都是行为级而非数值级：
- 玻璃基材只有一处定义且必须是白色；
- 没有玻璃面再用 `--c-white`（它与深色主题冲突）；
- 深色主题里不许出现非白色的 `--glass-base`；并带扰动自检。
## 实测（自己的无头 Chromium，壁纸开，1600×1000）
系统浅色: 卡片 rgba(255,255,255,0.78) 导航 rgba(255,255,255,0.72)
系统深色: 卡片 rgba(255,255,255,0.78) 导航 rgba(255,255,255,0.72) ← 不再变深
即"白色玻璃、只有透明度随主题变"确实生效；深色模式也不再出现半深不浅的观感。
|
2026-09-14 13:36:54 +08:00 |
|
|
|
8dd3b0eb17
|
fix(webui): 列表项改为"每项一张玻璃卡"，面板退成透明
用户：「你为什么是给所有列表项一起套了一个玻璃外框，而不是每个列表项单独套外框？」
**他是对的，而且我上一轮没给理由**：之前的做法是"面板 = 一张玻璃，行躺在里面"，
把列表当成一个整体容器 —— 而界面上其它地方（正文卡、弹层）都是"每一项自己是一块面"，
列表成了唯一的例外，观感上少一层层次。
改法：
- 新增 `.glass-card`（圆角 14px + 半透明 + 细边框 + 悬停加深，带 dark 档）；
- **列表面板退成透明**（壁纸模式下 `html[data-bg='on'] .comm-pane > .bg-white`
置为 transparent）—— 这样壁纸从卡片之间露出来，卡片才是真正的一块块面；
- 会话分组行与邮件行都换成 `.glass-card`。
实测（自己的无头 Chromium，1600×1000）：
壁纸关: 面板 rgb(255,255,255) / 卡片 rgba(255,255,255,0.92) / 圆角 14px
壁纸开: 面板 rgba(0,0,0,0) / 卡片 rgba(255,255,255,0.78) / 圆角 14px
即"面板透明、每项一张卡"确实生效。
未做（如实说明）：**联系人列表与会话列表**仍是"一张面板 + 行走廊"的旧结构，
只有 MailList 换成了每项一卡。要全部统一说一声，同一套 `.glass-card` 直接套即可。
|
2026-09-14 13:09:38 +08:00 |
|
|
|
faacd3c911
|
fix(webui): 修「宽屏导航栏还是黑色」的真因 —— 应用没有深色主题，导航却单独变深
用户：「宽屏 ui 你是一点没修复啊」。
## 真因（我前两轮都判断错了方向）
不是令牌抄错、也不是特异性覆盖。是**整个应用根本没有深色主题**：
- `tailwind.config.js` 里 `darkMode: 'class'` 是配好的，
- 但我数了一遍：**没有任何组件写过 `dark:` 变体**（`grep -c 'dark:' src/components/*.tsx` 全 0）；
⇒ 挂上 `.dark` 只会切换我手写的 CSS 变量，Tailwind 工具类一律照旧。
于是系统是深色时（`prefers-color-scheme: dark` → themeStore 的 `system` 解析为 dark）：
**导航**（有深色令牌）变深、**正文**（没有深色样式）仍是浅色 —— 界面半深不浅，
用户看到的就是"导航栏为什么还是黑色"。
## 改法
在真正的深色主题做出来之前，导航**跟随内容的实际形态**（浅色）：
`.dark` 里的导航令牌块清空并留下说明。要做深色主题的正确做法是给组件补齐
`dark:` 变体（独立一件事），而不是先把导航单独压深。
顺带：
- 删掉一条更早的 `.app-shell > .bg-chrome-900 { background-color: rgb(var(--c-chrome-900)/0.82) }`
—— 侧栏改成 `.nav-rail` 之后它是死代码，但特异性更高，一旦有人再挂上那个类就会重新变黑。
- 「我的」页宽屏用满：`max-w-lg`（512px，右半边全空）→ `max-w-3xl mx-auto`。
## 实测（自己的无头 Chromium，因为共享 9222 的 CDP 已被僵尸上下文拖死）
系统浅色: htmlDark=false, 侧栏 rgba(255,255,255,0.72)
系统深色: htmlDark=true, 侧栏 rgba(255,255,255,0.72) ← 不再单独变黑（这就是修复点）
## 顺带清理
共享 Chromium（9222）里我历次被中断的运行留下了 12 个僵尸标签，
已按 URL 精确关闭（保留 5174/8080/18091 等别人的标签）。
|
2026-09-14 13:08:19 +08:00 |
|
|
|
fc4671e55c
|
fix(webui): 去掉卡片/面板各自的模糊 —— 模糊叠模糊
用户：「你又犯了模糊叠模糊的毛病，整体的模糊是由壁纸那一层模糊确定的，
而你在每一个卡片又打了固定的模糊底」。
## 改动
浮在壁纸上的大面（列表栏、详情栏、卡片、侧栏）**不再各自 backdrop-filter**：
- 它们背后只有**已经模糊过的壁纸** ⇒ 再模糊一次不会更"玻璃"，只会更脏更糊，
而且每层都要重新采样背景（滚动时明显掉帧）。
- `.bg-white` 接管、面板基线、侧栏基线、壁纸模式下的侧栏 —— 全部去掉 backdrop-filter。
- **模糊只留给真正悬浮在内容之上的层**：底部导航条（浮在滚动列表上）、
地址建议菜单（浮在表单上）。它们背后是会滚动的内容，模糊在那里才有遮蔽意义。
模糊声明从 9 处降到 4 处。实测（真浏览器，通信页）：**没有任何元素带 backdrop-filter**
（`blurredCount = 0`）。
## 同一轮还有
`test/manual/nav-contrast-verify.mjs` 4/4：
浅色 白玻璃+深字 **7.48:1**、深色 深玻璃+亮字 **6.96:1**（自动反色真的生效）、
两主题底色确实不同、以及反向对照"过渡中途读会拿到起点色"——
这条正是我上一轮把深色模式误判成对比度不足（2.36）的原因。
|
2026-09-14 12:02:57 +08:00 |
|
|
|
9aa702b8cc
|
fix(webui): 导航改"按主题的玻璃"（浅色白玻璃+深字）+ 去掉整屏闪的入场动画
用户两句话：
「那你为什么不把白字换成黑字或者自动反色或者描边呢？」
「部分动画十分不合理，会导致页面大范围的闪动，且不能让人自然的把注意力集中在
将要出现的页面上」
## ① 导航：他说得对，我之前是用错误的方式解决对比度
这个应用是**浅色底 + 深字**，导航却是全页唯一一块黑的 —— 那才是"割裂"。我上一轮
为了"白字对比度"把它做成深玻璃，等于**把一块地方永久压黑**来回避问题。
现在导航底色/文字全部走令牌，按主题切换：
浅色：白玻璃 rgb(255 255 255 / .72) + 深字 #475569 → 对比度 7.48:1
深色：深玻璃 rgb(15 23 42 / .72) + 亮字 #94a3b8 → 自动反色
组件侧改成 `.nav-rail` / `.nav-item[data-active]` 令牌类（Sidebar 与 NarrowNav 同一套）。
同时删掉壁纸模式里写死的深玻璃规则 —— 那条正是"为什么还是黑色"。
## ② 动画：整面板入场删掉
先是从"所有面板一起动"改成"只动主内容区"，试下来仍然不对：页面级淡入会把
**已经在那儿的框架**也一起暗一下，观感还是闪。所以这一档整体删掉，只保留局部、
有明确语义的动效（日历翻页、菜单展开）。实测切视图时 `animatedOnSwitch = 0`。
骨架不动，注意力自然落在变化的那块内容上。
## ③ 一条我自己的误判（值得记下）
深色主题下我量到导航文字对比度只有 2.36，一度以为是变量/级联的问题，还写死了一份
深色字面值。**那是误判**：`.nav-item` 有 `transition: color .15s`，我在切主题后
**立刻**读 computed color，拿到的是过渡的**起点**（浅色值）。决定性证据是连内联
`style.color` 都"改不动"它 —— 级联不可能这样，只可能是还在过渡中。等 400ms 再量就正常。
写死的那份已撤掉，并在 CSS 里留下说明；新判据 `test/manual/nav-contrast-verify.mjs`
用 WCAG 比值量对比度（不是"颜色是不是黑的"），每次读之前等 400ms。
背景套件 32 条全绿（含"导航走令牌 + 两套令牌都在"）。
|
2026-09-14 11:57:41 +08:00 |
|
|
|
a456d2127e
|
feat(webui): 横屏导航改为侧边（不再压底部），列表栏固定 320
用户：「导航栏在窄屏横屏情况下不也应当是在侧边吗？」。
横屏缺的是**竖向**空间：底部导航吃掉本就不多的高度（844×390 里它占了 61px），
而横向反而有余（824px）。所以在紧凑双栏下复用桌面那条 60px 图标栏，去掉底部导航。
## 顺带修掉"横屏没自适应"的另一半原因
列表栏宽度写的是 `lg:w-[320px]`，而 lg 断点是 **1024px** —— 844 宽的横屏不满足
⇒ 它退回 `w-full` ⇒ **列表吃掉整宽、详情被挤成一条缝**。之前我只改了排布方式，
没管这件事，所以横屏仍然不好用。现在按"紧凑双栏"这个**语义条件**给宽度
（`.compact-2pane .comm-pane { flex: 0 0 320px }`），而不是再猜一个像素断点。
**实测**（844×390）：侧栏 60×380 在左侧；导航项 = 通信/日历/联系/我；底部导航**不存在**；
列表栏 x=80 宽 **320**；详情 434；无横向溢出。
|
2026-09-14 11:30:51 +08:00 |
|
|
|
d11e6df9a8
|
feat(webui): 日历翻页过渡动画（方向跟随手势/按钮）
用户：「日历滑动页面为什么没有切换动画？」。
## 做法
`shift()` 里记下方向（手势与"上一页/下一页"按钮**都走这一个函数** ⇒ 方向只有一个来源），
容器用 **key + 声明的动画类**：
<div key={`${anchor.getTime()}-${scale}`} className={`flex-1 min-h-0 flex ${slideClass}`}>
## 为什么不是"命令式加类"
第一版用 `el.classList.add()`（与视图切换动画同一套写法），**类根本没进 DOM**。
原因：切月时 `loading` 会把网格整块换成加载态、再换回来，命令式加上的类会被
React 的重渲染与那次重挂载抹掉。key 变化 ⇒ 新元素自带动画类出现 ⇒ 必然重放。
## 顺带修掉一个守卫 bug
`firstRender` 守卫原先只在 `el` 存在时才消费。挂载时 `loading=true` ⇒ 容器还没渲染
⇒ 守卫一直留着 ⇒ **用户第一次真正翻页的动画被吞掉**（实测：点第一下不动、第二下才动）。
现在无条件消费。
## 判据
`test/manual/calendar-swipe-verify.mjs` 增加三条（与滑动手势同一条线索）：
反向对照"刚进页面不跑动画"（animationName=none）、翻页时 `cal-slide-next` +
`cal-in-next` 且时长 >0、反向翻页是 `cal-slide-prev`（方向正确性）。
**实测**：静止 none → 点下一页 `cal-slide-next`/`cal-in-next` 0.2s → 上一页 `cal-slide-prev`/`cal-in-prev`。
|
2026-09-14 11:27:37 +08:00 |
|
|
|
ef68c4950c
|
fix(webui): 统一玻璃语言 —— 导航改深色玻璃 + 内层面板自带圆角
用户：「你不觉得页面设计很割裂吗？尤其是通信页，大面积的非圆角元素。
同时还有大面积的非玻璃样式。导航栏不也应该改为玻璃样式吗，为什么还是黑色」。
## ① 导航还是黑的：因为我自己留了一条"必须不透明"的规则
`html[data-bg='on'] .bg-chrome-900 { background-color: rgb(var(--c-chrome-900));
backdrop-filter: none }` —— 这是**更早一轮**用户的要求（当时面板太透，壁纸从导航里
透出来显得脏）。现在整套语言统一到玻璃之后，导航继续做一块实心黑就成了全页唯一的
例外，也就是"割裂"的来源。
改成**深色玻璃**（α=0.72 + blur(18px) + saturate）——用深色而不是白色玻璃：
白字压在深色上才有对比度。没开壁纸时用 0.82（后面是页面底色而不是照片，太透显脏）。
## ② 通信页"大面积非圆角"：是我修滚动时带出来的
圆角原本只加在外壳上，靠 `overflow: hidden` 裁掉内层的直角 —— 但那个 overflow
会杀掉滚动（上一封），必须去掉。**于是内层白底面板的直角就从圆角外壳里戳了出来。**
现在把圆角直接给内层面板（`.comm-pane > *`），两边对齐，且不依赖裁剪 ⇒ 与滚动不冲突。
MailView 的两条工具条也不再自带宽底（只留上边框，底色继承面板），否则同样会戳角。
## 判据
`background.test.mjs` 里两条**旧判据**（断言"导航必须不透明、不参与模糊"）按现行契约
重写为"深色玻璃（α∈[0.6,0.9]）+ 参与模糊"，并新增"内层面板自带圆角"。
要求反转后旧判据必须一起改 —— 留着只会让下次改动"要么违规、要么把缺陷写回去"。
**实测**（真浏览器，1280×900，壁纸态）：导航 α=0.72 / blur(18px) / radius 14px；
内层 MailList 面板 radius **14px**（不再是直角）。背景套件 31 条全绿。
|
2026-09-14 11:17:12 +08:00 |
|
|
|
50ee10a522
|
fix(webui): 修「通信页面完全无法上下滑动」+ 日历左右滑动手势
## 滑动（用户：「通信页面的各个子页面还是无法滑动啊，我真服了」）
根因不是我第一次以为的 `overflow: hidden`，而是**我把列表包进了一个 flex 列**：
- `MailList` 的根是 `w-full lg:w-[320px] shrink-0 ... flex flex-col` —— 这个 `shrink-0`
是给**行**方向布局写的（控制宽度），放进列方向后它作用在**高度**上：列表连高度
都不肯让 ⇒ 内部的 `flex-1 overflow-y-auto` 永远拿不到可用高度 ⇒ 滚不动。
- 表现极具误导性：容器**自己也没有溢出**，所以连滚动条都不出现，看起来像"页面被裁掉了"。
- 为什么以前没坏：列表原先直接挂在窄屏覆盖层（`absolute inset-0 flex`，**行**方向）下，
行方向的高度来自 `align-items: stretch`，不需要 `min-height:0`。
修法：`.comm-pane > *:not([data-testid='comm-tabs']) { flex: 1 1 0%; min-height: 0 }`
—— 让子面板既能压缩、也填满这一列。对收件/发件/授权/联系人一视同仁，避免只修好一个。
**实测**（390×844，11 行邮件）：修复前 `scrollerCount: 0`（一个可滚动容器都没有）；
修复后滚动容器 = `flex-1 overflow-y-auto p-2.5`、`overflow-y: auto`、可滚范围 236px、
`scrollTop` 实际移动 200px。导航仍完整可见（bottom=834 ≤ 844）。
## 我自己的两个方法错误（都写在这里，避免下次再犯）
1. **判据没断言前置条件**：前三次探针都报"没有滚动容器"，其实是 gui-lab 收件箱太短
（12 封全落进同一个会话 ⇒ 只显示 1 组）⇒ 内容根本没溢出 ⇒ 我量的对象不存在。
最后用 10 个**独立会话**把列表撑高才复现出来。用户报的缺陷是真的，是我的探针没到位。
2. 第一条修复（去掉 `overflow:hidden`）方向不对，但我当时**差点把它当成修好了** ——
因为探针依旧是 0 滚动容器，只是我没深究。结论必须是三态，不能把"量不到"当"没问题"。
## 日历左右滑动（用户：「日历页面还不支持左右滑动手势」）
在日历主体上挂 touchstart/touchend，**复用 `shift()`**（与"上一月/下一月"按钮同一套翻页
逻辑）；阈值：水平位移 ≥40px、且 ≥1.5×垂直位移、且 <600ms —— 否则会把纵向滚动误判成翻页。
**这条我还没验成功**：探针取日历标题的方式不对（返回 null ⇒ 判不了），
不能说它好了。修好探针再补验。
|
2026-09-14 11:01:10 +08:00 |
|
|
|
76ce201c3a
|
feat(webui): 导航合并 + 悬浮玻璃 + 页面动画 + 控件档透明度 + 圆角无条件生效
用户四封信（同一线索）提的六件事，都在这里：
## ① 导航合并（「导航栏的内容有点多了」）
收件箱/发件箱/授权 → 一项「通信」，进去由**内部页签**区分（CommTabs）；
新建 → 「通信」页内**悬浮圆形加号**（ComposeFab）；导航只剩 通信/日历/联系人；
管理 → 合进「我的」，管理员在页面**最下面**看得到（非管理员不渲染，不是禁用）。
`viewMode` 仍是原来那三个值（几十处调用点不用改），新增 `commTab` 记住上次用的子页签；
通信项的徽标 = 未读 + 待决策（授权信息不能因为合并而消失）。
## ② 窄屏底部导航：悬浮玻璃（「还是固定底部延伸，没有玻璃效果，也没有悬浮」）
原来是 `border-t bg-chrome-900` 通栏贴底。改成：左右/离底各留 10px、圆角、
深色半透明 + `blur(18px)`、投影，安全区并入下外边距。
## ③ 页面动画（「页面极度缺少动画，所有页面都是直接出现」）
在 `<html>` 上挂一个短命类触发外壳直接子面板的入场动画。**没有用 key 重挂载**：
面板是 flex 链上的一环，套 wrapper 会改掉 flex 传递（窄屏覆盖层最先坏）。
并且尊重 `prefers-reduced-motion`（关了就一点都不动）。
## ④ 控件档透明度（「复选框和地址猜测项…他们才是真正需要拉低透明度的地方」）
新增第三档 `--bg-glass-control`（0.5/0.55）：授权多选胶囊、地址建议菜单。
三档递减：正文面 0.88 > 嵌套 0.82 > 控件 0.5。
## ⑤ 打底 vs 透明（上一封「该打底的地方透了、该透的空白处糊了」）
正文面回到 0.88（读得清优先）、空白/页面底透明**且不模糊**、面板模糊降到 10px。
## ⑥ 圆角与玻璃**无条件**生效（「大面积缺失圆角与玻璃效果…都是硬截断」）
根因：`.app-shell` 的留缝/圆角/投影原先全写在 `html[data-bg='on']` 里
⇒ **没开壁纸的账号**看到的是硬边不透明面板。现在几何下沉为无条件基线，
壁纸相关的加强仍叠加在上面。窄屏内容面板同样浮起来。
## 判据
- `test/nav-merge.test.mjs` 8 条（含自检：重构前的写法必须判红）——
改完跑老套件 254 条**全绿却一条都没测导航结构**，结构改动必须自带判据。
- `test/manual/nav-restructure-verify.mjs`：真浏览器 9 条（导航项数、页签切换真的换内容、
加号 56×56 且 `elementFromPoint` 命中自己、我的页底部管理入口在退出登录之后、
控件档 α=0.5 对正文面 α=0.88 的反向对照）。
- `test/manual/narrow-glass-verify.mjs` 6 条：悬浮几何（三边留缝 10px、圆角 14px、
缝隙处命中的是页面底 ⇒ 真的浮着）、玻璃（α=0.82 + blur18）、触摸高度最小 49px、
动画真的在跑（静止时 `animationName=none`，切换后 =pane-in）且 reduced-motion 下不动。
- `test/background.test.mjs`：把三条**过时判据**（早前那版"越透越好"）按现行契约重写 ——
旧判据留着只会把我拽回错误方向。30 条全绿。
## 顺带
窄屏探针原先只调视口、**没模拟触屏**，于是 `(hover: hover)` 仍为真，
把「悬停才显形的次要动作」误报成透明 —— 差点去"修"一个本来就对的规则。
已改成 hasTouch + isMobile + DPR 的触屏上下文，且收尾只关自己的 context
（CDP 连的是共享 Chromium，`browser.close()` 会把别人的标签页一起关掉）。
|
2026-09-14 10:35:05 +08:00 |
|
|
|
d2904fc45d
|
style(webui): 导航栏改为完全不透明 + 内容面板更通透 + 整屏浮动圆角玻璃
用户 2026-09-14 原话：「导航栏应当完全不透明……没有正文的位置过于不通透，
同时导航栏应当现代化一下，整个界面应当圆角化玻璃化」。
这三句是**两个方向**的要求，我上一轮正好把导航栏做反了（越改越透）：
## ① 导航栏：完全不透明（含窄屏底部导航）
`chrome-800/900` 在背景模式下不再吃 alpha、也不参与模糊。它是**框架**，
不该跟着壁纸一起虚化。它与"内容要通透"是两个方向的要求，所以写成独立规则、
并在注释里点名 —— 合并成一条必然互相打架。
## ② 内容面板：更通透
`--bg-glass` 0.62 → **0.45**（深色 0.66 → 0.5），嵌套层 0.3 → 0.22。
实测（纯红壁纸读绿通道）：邮件列表有效不透明度 115/255 ≈ **0.45**，正文区全透。
## ③ 整屏浮动圆角玻璃
给宽屏外壳加了稳定钩子 `app-shell`，背景开启时：外壳 **padding/gap 10px**
（面板之间露壁纸 —— 没有缝隙的"玻璃"看上去仍是一整块板）、顶层面板
**圆角 var(--radius-card)** + 投影。实测三栏：导航 60px/圆角14px/不透明、
列表 320px/圆角14px/0.45、正文 1020px/圆角14px/全透。
## 判据
`test/background.test.mjs` 新增 5 条形态判据（导航不透明、导航不参与模糊、
`--bg-glass ≤ 0.55`、外壳留缝、顶层面板圆角），共 **28 条**。
前端 254 条 + 打包一致性全绿。
## 过程中的三处自纠
1. **我的 App.tsx 编辑第一次根本没落盘**：那份 python 脚本第 18 行语法错误就整体
没执行，而我把"✓ 已加钩子"当成了成功 —— 后来 `.app-shell 存在: false` 才暴露。
教训：脚本报成功不等于目标文件变了，**改完要回读**。
2. **JSX 里把 `{/* … */}` 放在 `return (` 与根元素之间**是非法的 ⇒ 构建失败。
改为 JS 注释放在 `return` 之前。
3. ★ 这两次失败都是**新加的部署闸门先拦住的**（"前端 dist 比源码旧"），
也就是上一轮刚补的那道门当天就发挥了作用 —— 换成以前，会再次静默部署旧界面。
## 顺带清理
验收截图用的 2 封样例邮件已删、随之产生的空会话已归档；测试账号外观已重置。
|
2026-09-14 09:07:49 +08:00 |
|
|
|
ababe4ae56
|
fix(webui): 壁纸被不透明层盖住 —— 玻璃不再层层相乘 + 浅色表面类全部接管
用户报的：「webui 目前在壁纸底上叠了太多不透明层，导致壁纸效果很差，几乎看不出来」，
追问后补充：「不只是玻璃，而是很多界面是不透明的」。两句都成立，是两个叠加的原因。
## ① 玻璃层层相乘
每层面板都吃同一个不透明度 a，两层就是 1-(1-a)²。a=0.82 时两层 0.97、三层 0.995
—— 壁纸在数学上被吃掉，而且每层各做一次 16px 模糊，图案被糊成灰块。
改法：玻璃只出现一次（外层 0.62 + 18px 模糊；嵌套层只留 0.3 色调且不再模糊；
第三层透明）。同时把遮罩 24%→12%、照片自身模糊 8→4px（那张被洗白的锅之一）。
## ② 14 个浅色表面类根本没被接管（"很多界面是不透明的"就是这条）
旧规则只接管 white / gray-50 / slate-100，而源码里在用的是
gray-100(24 处)、blue-50(17)、red-50(13)、blue-100(8)、gray-200(8)、green-50(8)…
—— 全是实心的，正好盖住壁纸。
清单改为**从源码用法生成**（`scripts/gen-background-takeover.mjs` → 生成的 CSS，
构建前自动跑），因为手写清单必然烂；判据保证"源码里出现的浅色表面类必须都被接管"，
并明确排除页面底（gray-50/slate-100 必须保持**全透明**，不能被改成半透明）。
按钮/徽标（*-600/700、chrome-600/700）**故意保持不透明**：小控件可读性优先
（index.css 里原有注释记着实测 4.46:1 的教训）。
## 判据
- `test/background.test.mjs` 23 条（新增 8 条）：玻璃算式（两层 ≤0.85）、外层 ≤0.70、
嵌套规则存在、**判据自检**（旧值 0.82 必须算得出 >0.95）、表面类覆盖、页面底不得进清单、
清单非空跑。犯过一次错：第一版把判据追加在 `process.exit()` **之后** ⇒ 根本没执行，
从"测试数没变"才发现。
- `test/manual/wallpaper-layers-verify.mjs`（真实渲染，自带无头 Chromium）：
用**纯红壁纸读绿通道**测有效不透明度（纯色下 backdrop-filter 不影响读数）。
面板 p95：**修复前 82% → 修复后 62%**；反向对照（改回旧值）能分辨 ≥10 个百分点；
深色照片面上面板仍是浅底；关掉壁纸的同坐标对照更实。5/5。
过程中作废了两个指标：只看绿通道会把深色元素误判成"盖死"；"面积占比"类阈值
（Δ≥8/≥40）在 0.97 时仍会蹭过门槛，饱和而无分辨力 —— 同坐标比值才可信。
## 交付
已部署（网关内嵌 WebUI 重建）：线上 CSS 已含 `--bg-glass-inner`、嵌套规则与 14 个接管类。
|
2026-09-14 08:09:22 +08:00 |
|
|
|
c19eea5e3c
|
feat(webui): 真正动可见层的现代化 —— 字号、层次、间距、分隔线
# 起因：上一轮的「现代化」基本不算现代化
用户指出「我说的是 webui 现代化」。回看上一轮，我交付的其实是**底层改进**：
圆角加大一档、自定义滚动条、焦点环、过渡、reduce-motion、令牌与可访问性。
这些都对，但**可见变化几乎只有圆角** —— 界面看起来还是老样子。
实测数据确认了「老」在哪：
text-xs(12px) 172 处 ← 被当正文用
text-[10px] 84 处
text-[11px] 68 处
text-[9px] 19 处 ← 现代显示器上基本读不了
text-sm(14px) 69 处
text-base(16px) 4 处
57 处 border-b + 21 处 border-r，其中 67 条是 border-gray-200 的硬灰线
阴影：全站共 10 处，且全是 Tailwind 系统默认档；
index.css 里 --shadow-1/2/3 三个语义令牌**定义了但零处使用**
所以真正的病因是三条：**字太小、层次为零、硬线切分**。
# 改动
## 1. 字号体系抬一档（tailwind.config.js）
不用 Tailwind 默认档，重定为：
3xs 11px（角标下限，取代 9/10px 魔法数字）
2xs 12px（元信息，取代 11px）
xs 13px（次要正文，原 12px —— 拿它当正文的地方自动变舒适）
sm 14px（正文）
base 15px
并把 171 处裸 px 类名（text-[9px]/[10px]/[11px]）统一换成令牌 ——
顺带消除魔法数字。行高一起给：小档位 1.35/1.45，正文 1.55，
只放大字号不放行高会把密排列表顶得很难看。
## 2. 把层次接出来（原本是死代码）
tailwind.config.js 新增 boxShadow 映射 `--shadow-1/2/3` + 新增
`--shadow-panel`（横向偏移 + 大扩散，竖向几乎不偏移，否则全高面板像浮在半空）。
用于：列表面板（lg:shadow-panel，**同时去掉 border-r 硬线**）、
登录/初始化卡片（shadow-sm → shadow-2 + 去硬边框）、
地址自动补全下拉（shadow-lg → shadow-2）、窄屏滑入详情面板
（shadow-2xl → shadow-3 + 去 border-l）、主题分段控件的选中滑块。
深色下层次比浅色更难感知，所以 --shadow-panel 在深色里更实一些；
深色里靠边框分组几乎看不见，层次是**唯一**有效的分组手段。
## 3. 分隔线软化（改令牌而不是改 67 处类名）
`--c-gray-200` 浅色 229 231 235 → 234 236 241，深色 44 49 59 → 39 43 52。
改在令牌上，67 条边框 + 8 处底色一次性生效且不会漏。
**刻意没有一起调 gray-300**：它同时是滚动条滑块色，调淡会让滑块更难看见。
## 4. 配比放宽（列表行的呼吸感）
MailList：行内距 px-3 py-2.5 → px-3.5 py-3，列表 gap space-y-0.5 → space-y-1，
表头 py-3 → py-3.5。未读主题字重 medium → semibold，已读 gray-500 → gray-600。
## 5. 量出来的两个真实对比度缺陷（不是估算）
新增 `test/manual/modernization-verify.mjs`，用真实渲染做四条判据。
它量出浅色下两个 WCAG AA 不达标（阈值 4.5:1）：
- 会话别名 `text-blue-500` 白底 3.68:1（别名在 mail list / thread / mailview
共 4 处，都是 11px 小字）→ 改 blue-600/700，达 5.17:1
- 时间戳 `text-gray-400` 压在选中行淡蓝底 `bg-blue-50` 上 4.44:1
第二个的**根因是调色板缺一档**：浅色下 `--c-gray-400` 与 `--c-gray-500`
完全相同（都是 107 114 128），于是「比次要文字再深一档的中间色」根本不存在，
时间戳无处可退。拉开 gray-500 → 90 98 112（5.65:1），并把 5 个列表组件的
行内元信息（19 处）从 gray-400 提到 gray-500。
# 验证
- typecheck 干净
- 前端全量 `npm test` EXIT=0（markdown-xss / narrow-layout / theme 30 /
background 15 / vitest 216）
- **真实渲染** `modernization-verify.mjs`：浅色 8/8、深色 8/8，判据含
最小字号 ≥ 11px（改造前 9px）、邮件正文 ≥ 14px、列表面板真有 box-shadow、
gray-200 是软化值、40 处正文对比度全部达标
# 我自己的三处错（都被这次的度量拦下）
1. **判据量错对象**：第一版拿「收件箱列表」要求 40% 元素 ≥13px，量出 39.7%
判失败 —— 而收件箱本质是元信息密集区，发件人/时间/别名本来就该小。
改成量真正该达标的**邮件正文**（≥14px）。
2. **探针忽略 alpha**：`parseRgb` 把 `rgba(239,246,255,0.4)` 的 alpha 丢掉当实色，
于是把淡蓝底当纯蓝算出 4.44:1 的假缺陷。改为按画家算法合成整条背景链。
3. **config 注释换算写错**：3xs 注释写 10px，0.6875rem 其实是 11px。
|
2026-09-12 09:54:31 +08:00 |
|
|
|
84c1d749cd
|
feat(webui): 自定义背景 + 外观现代化；修正实心按钮白字在深色下的对比度
# 自定义背景（新功能）
三选一：不设 / 预设渐变 / 自定义图片，另加压暗与模糊两条滑杆。
**预设的色值全部复用现有调色板变量**，因此自动随主题变化 —— 那一组
（50–300）在深色下本来就是暗的（见 .dark 与 theme.test.mjs 第 19 条），
于是浅色得到柔和 pastel、深色得到低沉暗调，不需要维护两套渐变，也不会
出现「深色模式下原样落下浅色渐变」这类绕过主题变量的错误。
图片路径的关键取舍：
- **先压缩再存**。手机直出照片 4–8MB，而 localStorage 配额约 5MB，直接写会抛
异常，用户看到的是「选了图片没反应」。等比缩到最长边 2560px、转 JPEG；
仍超限则再缩一档；再不行就**明确拒绝并说明原因**（不是静默失败）。
- 失败一律返回 `{ok:false, reason}` 并渲染成 `role="alert"`。
# 背景层为什么不放进主题 store
主题（light/dark/system）是必须全局一致的语义；背景是纯装饰偏好，取值空间
与主题毫无关系。混在一起会让「跟随系统」的实现被背景字段淹没。
# 背景层实现在 CSS，不改 27 个组件
按 Tailwind 生成的实际类名统一接管：背景开启时让出不透明的页面底
（body / bg-gray-50 / bg-slate-100 → 透明），并把卡片（bg-white）与框架
（bg-chrome-800/900）变成半透明 + 背景模糊。
逐个组件加 class 必然漏 —— 漏掉的那块就是一张不透明卡片浮在背景上。
这段 CSS **刻意放在所有 @layer 之外**：它要覆盖的正是 utilities 生成的
`.bg-white`，写进 @layer components 会被 utilities 压过去（静默失效），
而分层 CSS 恒输给未分层 CSS，这是唯一稳定可靠的位置。
**chrome-600/700 刻意保持不透明**：它们不是大面板，而是导航项与 15px 的
计数徽标。真实渲染量得半透明会把徽标上的数字压到 4.46:1，低于 AA 4.5 ——
小控件的可读性优先于装饰效果（已用脚本量出，见下）。
# 「跟随系统」的可见性
三态本来就已实现（system 为默认值 + matchMedia 监听）。这次做的是让它可被
发现与信任：选择器改成分段控件（role=radiogroup + aria-checked），说明文案
写清「跟随系统会随系统的深色开关自动切换」，并保留单选按钮入口的
「当前跟随系统：深色/浅色」提示。
# 外观现代化
- **圆角整体调大一档**（默认 0.25→0.5rem）。原值是几年前的紧凑风格，
在宽屏桌面应用上偏硬。只改比例尺，200 处圆角一次性刷新，不产生
「新组件大圆角、旧组件小圆角」的断层。
- 语义化圆角令牌：`rounded-card` / `rounded-control`（数值档位答的是「多大」，
这两个名字答的是「用在哪」）。
- 自定义滚动条（桌面应用里常驻可见，系统默认样式偏旧）。
- 键盘焦点环（`:focus-visible`，仅键盘导航时出现；可访问性硬要求）。
- 交互元素统一过渡；并尊重 `prefers-reduced-motion`。
# 顺带修正两处真实问题（都由真实渲染量出，不是估算）
1. **实心按钮白字在深色下 4.46:1，低于 AA**。
深色 `--c-on-accent` 是「近白」244 246 250（为了不刺眼），而结构检查第 23
条只拿**浅色**的纯白 255 去算 → 4.83 通过。**测试存在盲区**：
同一个实心底，白字换暗一点点就越过 AA 线。导航未读徽标「12」正是这个组合。
两处都修：把第 23 条改成**两种模式的 on-accent 都算**（闭合盲区），
并把深色 on-accent 抬到 250 250 252（4.65:1，仍非纯白，保留原初衷）。
2. **theme.test.mjs 切颜色块的方式很脆**：它用 `indexOf('.dark')` 切片，于是在
:root 的注释里写一句带点的选择器写法就会把浅色块提前截断（我加注释时
真的踩到了，第 8 条假失败）。更危险的是反向情形：块被截短后变量集合变小，
「覆盖齐全」这类断言可能**真空通过**。改为所有块切分都基于**剥注释后**的文本。
# 测试
- 新增 `test/background.test.mjs`（15 条结构检查）：遮罩两主题各一份、
背景层必须负 z-index（0 会盖住界面）、背景开启时必须让出页面底、
玻璃化只在 data-bg=on 下、悬停态一并接管、预设复用调色板变量、
图片上限与失败原因存在、尊重 reduced-motion 等。
- 新增 `test/stores/background.test.ts`（16 条）：脏数据归一化（未知预设、
kind=image 却无图、越界数值）、CSS 变量写入与清理成对（残留 --bg-image 会
让「关掉背景」后仍显示旧图）、localStorage 抛异常不打断操作。
- 新增 `test/manual/background-verify.mjs`：连真实 Chromium 验收**渲染结果**
（背景层是否真的可见、玻璃化的计算样式、正文在背景之上是否仍达 WCAG AA、
自动模式在**不刷新**页面时跟随系统切换、显式选择不被系统覆盖）。
它拦住了上面两个真问题，也拦住了我自己两次写错的判据。
# 验证
- typecheck 干净
- 主题 30/30、背景 15/15、vitest 216/216（新增 16）
- 真实渲染验收 23/23（AGENTMAIL_DIST 注入本地构建 + 活 Gateway，未部署即验收）
- 截图对照：浅色/深色 + 极光背景，面板玻璃化与层次均符合预期
|
2026-09-12 08:02:30 +08:00 |
|
|
|
f9d757b5e5
|
chore: directory migration - gateway→server, web→client/electron
|
2026-09-08 19:16:35 +08:00 |
|
