|
|
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 |
|
|
|
e21151e98d
|
fix(webui): 手势卡严只作用于周/日刻度（我第一版卡太宽，把月视图翻页也一起杀了）
用户原话：「**周视图**需要卡严条件」。我第一版对**所有刻度**都卡，判据写成
"这页里有没有可横向滚动的容器" —— 而月视图的外层容器本身就带 `auto`，
于是连月视图的翻页手势也一起没了（实测：栅格与标题栏起手都不翻页）。
判据必须贴在**真正有横向滚动需求的那个刻度**上，而不是"这页里有没有横滚容器"。
## 实测（390×844，自有浏览器）
月视图（标题栏起手横滑）：2026 年 9 月 → 2026 年 10 月 ✅ 可翻页
周视图（栅格里起手横滑）：不翻页 ✅ 让给横向滚动
滚动容器遮罩：linear-gradient(rgba(0,0,0,0) 0px, rgb(0,…) ✅ 已生效
⚠ 如实说明：最后一次探针里周视图的**标题取成了 null**（我的取样函数对
"2026 年 9 月 14–20 日"这种短横线格式没匹配上），null→null 不构成证据。
不过同一代码路径在上一轮探针里取到了真实标题（"9 月 14–20 日"）且未变化，
所以这条结论成立，但**证据强度弱于另外两条** —— 写在这里免得下次被当成硬结论。
## 附：部署差点又失败
`/tmp` 是 tmpfs，当时已 100% 满（9.8G），而部署脚本把构建产物写到硬编码的
`/tmp/agentmail-gateway-build-*` ⇒ `no space left on device`。
我差点把"旧构建上的测量结果"当成"改动无效"。清理我自己的产物后恢复。
**根治**：脚本应尊重 `TMPDIR`（未做，`/tmp` 现仍占 91%）。
|
2026-09-14 14:36:49 +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 |
|
|
|
bb855b1518
|
fix(webui): 日历补上圆角 —— 外层面板圆了、里面的格子还是直角
用户：「日历页面怎么没有圆角」。
原因与列表那次同源：**外层面板一直是圆的**（`.app-shell > *` 给了 14px），
但里面的日格/列写的是 `border-b border-r`（直角 + 细边框），而我早前为了修滚动
去掉了面板的 `overflow: hidden` ⇒ 里面的直角就戳在圆角外面，看起来"整页没有圆角"。
改法：日格、周视图列、以及日历的两个大面板都改用 `.glass-card`
（圆角 14px + 白色玻璃 + 细边框），与列表项、顶部气泡同一套语言。
顺手去掉日格上的 `overflow-hidden`（它会把事件条裁掉，而"裁掉"正是这几轮的老毛病）。
实测（自有浏览器，壁纸开）：日历里 **42 个 `.glass-card`**（月视图 42 格 + 面板），
格子 `border-radius: 14px`、底色 `rgba(255,255,255,0.78)`。
（这条同样是"外层圆角 + 内层直角"这一类问题 —— 我已经在列表、顶部、日历上
各修了一次。要找根因的话：**面板圆角不能靠 `overflow: hidden` 裁**（它会杀滚动），
所以每一层自己都要圆角。这是这套"浮动面板"设计的固有代价，写在这里备查。）
|
2026-09-14 13:47:58 +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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
f9d757b5e5
|
chore: directory migration - gateway→server, web→client/electron
|
2026-09-08 19:16:35 +08:00 |
|
