|
|
d74f356f41
|
feat(web): 深色主题 —— 反转灰阶而非逐处 dark: 前缀
**逐处加 dark: 前缀的方案在这里必然失败**：约 700 处颜色散在 21 个组件里，
漏一处就是深色下的白底白字，而它不报错、不影响构建、只有肉眼能发现，
且往往只出现在某个不常开的页面。此后每加一个组件都要记得写两遍，
那种约定活不过三次改动。
改法是把颜色下沉到 CSS 变量，深色模式**反转灰阶**。这套代码的灰阶本身
就是语义色阶（white/gray-50 = 表面层次，gray-200/300 = 分隔线，
gray-900→400 = 文字主次），反转之后 `bg-white text-gray-900` 自动变成
深色卡片 + 浅色文字。零组件改动，新组件照常写浅色类名也自动适配。
变量存 **RGB 三元组**而非 #hex：代码里有 bg-blue-50/70 这类透明度修饰符，
Tailwind 生成 rgb(var(--x) / 0.7)，而 rgb(#f9fafb / 0.7) 是无效 CSS ——
那些半透明高亮会静默失效（不报错，只是不透明）。
---
实测撞了三个必须分离的语义，每一个共用变量就坏：
**1. text-white 不能跟 bg-white 走。**
`white` 服务两种冲突用途：卡片表面（深色下要变暗）与彩色按钮上的文字
（深色下必须保持浅色）。共用时后者跟着变暗 —— 激活导航项的「收件」在
bg-chrome-700 上只剩 **1.34:1**，几乎消失。拆出 --c-on-accent。
**2. 侧栏与底部导航不能跟 gray 走。**
它们在浅色模式下**本来就是深色的**（深色侧栏配浅色内容区是原本设计）。
并入反转灰阶后深色模式下变成近白色（实测 rgb(243,245,248)），比内容区
（rgb(17,19,24)）还亮，整个层次翻过来。独立成 chrome 色阶，深色下只微调、
保持「框架比内容更沉」。
**3. 强调色不能反转。**
blue/red 跟着变会让主按钮在深色页面上失去「这是主操作」的视觉重量，
而且白字落在变暗的 blue-600 上对比度掉到 3:1 以下。改成固定值。
---
顺带修的三处真实对比度不足（实测量出来的，不是猜的）：
- 待决策橙徽标：orange-500 上白字 2.80:1 → orange-700 5.18:1
（保留橙色语义，不能改成灰 —— 它与未读的红色是两种紧急）
- 空状态文案：gray-400 2.43:1 → gray-500。这类文字是**页面上唯一的内容**，
不是次要装饰，读不动等于页面空白
- 列表头计数：同上
---
主题是**三态**而非开关：system 不是 light 的别名 —— 只给开关的话，
白天设浅色之后晚上系统切深色应用不会跟着变。且只有 pref 为 system 时
才跟随系统，显式选了的人不该因为日落被切换。
index.html 加同步内联脚本消除首帧闪屏：bundle 有 430KB，从 HTML 解析完到
React 挂载之间页面是 body 默认色，深色用户每次刷新都被闪一下白屏。
外链或 defer 都晚于首次绘制。它与 themeStore 共用同一个 localStorage 键
（不一致会导致首帧按 A 键渲染、挂载后按 B 键重渲染，闪一下再变回去）。
body 显式设底色：移动端橡皮筋回弹露出的是 body 背景。
入口两处：侧栏单按钮快速翻转，「我的」页三选一设定偏好。单按钮不足以
表达三态，但只给单按钮的话用户一旦点过就永久脱离「跟随系统」——
那是个回不去的单向门。
测试：test/theme.test.mjs 20 条结构性断言（已进 npm test），
test/manual/theme-verify.mjs 真实渲染对比度验收（遍历可见文本节点算 WCAG
比值，往上找第一个不透明背景）。两种模式各 4 项全过。
|
2026-09-04 06:30:26 +08:00 |
|
|
|
e504eccf3a
|
fix(web): 授权独立成导航项 + 收件箱按会话分组 + 回复对端判定
**授权请求不是「一封信」而是「一件待办」。**
生产取证：一个 pi 会话独占 17 封权限邮件（后涨到 39），另外两个会话各
3 封 / 1 封 —— 收件箱被一件事塞满，失去了它唯一的作用（让人知道有哪几件
事在等我）。
第一版做成会话折叠，用户纠正后重做：权限请求的生命周期是「等人点头 →
决策完就作废」，与普通邮件混在一个箱子里两者互相伤害。收件箱只放要读的，
授权项只放要批的。
`groupPermissions` 的排序判据是「要不要我动手」而非时间：三天前发起、
至今还卡着的授权比十分钟前刚批完的重要得多。纯按时间排会把它压到底部，
而 Agent 那条会话正在等 —— 那正是权限死锁在 UI 上的样子。
未读徽标用红色、待决策用橙色，且两个数字**互不重复计数**：未读是
「有内容没看」，待决策是「有 Agent 卡着等我」。
---
**回复发给自己的 bug（用户报）。**
根因：ReplyBar 的对端判定写死 `from_name === 'human'` —— 单用户时代遗留
（当时人类只有 human@ 一个身份）。登录名是 jianf 时判据恒为假，
于是取 from_name（自己）。
生产链条：`27c22900 jianf→pi` 对（锚点是 pi 发来的），
`8e519925 jianf→jianf` 错（锚点是自己发的）。
两处修正：
1. **判据必须是当前登录用户名**，不是字面量 'human'。同一遗留判据在三处：
对端解析 / replyAll 去自己 / ThreadCard 图标。
2. **会话视图的回复对端是会话的属性，不看任何单封邮件。**
人在那儿打字就是「给这次任务的对方追加一句」；用「最后一封」当锚点时，
自己刚发过信就会把自己算成对端。sessionCounterpart 扫全会话取首个
非我参与方（收件人优先于发件人，同刻用 mail_id 定序）。
ThreadCard 顺带显示真实发件人名而不是统一渲染成 'human' —— 会话里可能有
多个人类参与方。
测试：mailGroups 30 例（含「生产实测形状：17 封权限邮件」）、
replyTarget 24 例（含生产链条重现：断言 target 以 pi@ 开头而非 jianf@）。
手工验收脚本 inbox-group-verify.mjs 六项全过。
|
2026-09-04 06:29:21 +08:00 |
|
|
|
514f443e54
|
fix: 「我的」页无法滚动 —— 缺滚动容器；顺带修矮屏登录页
用户反馈「我的页面点击进入后无法滑动」。
## 根因：AccountPage 根本没有滚动容器
窄屏外壳是 `h-full flex flex-col overflow-hidden`，页面本身是
`flex-1 min-w-0 flex flex-col`，中间缺一层 `overflow-y-auto` ——
内容超出的部分**直接被裁**，滚不到也点不到。
实测 390px 下内容（资料 + 权限 + 改密码 + 密钥 + 退出）需 860px、容器只有
795px，「退出登录」按钮连同下面 65px 一起消失；1280x800 的桌面上同样看不到。
其余六个页面级组件（AdminUsersPage / MailView / ComposePage / ThreadView /
ContactPanel / MailList）都有这一层，只有它漏了 —— 上一轮把退出登录搬进这页
之后内容变高，问题才显形。
## 顺带：登录页与初始化页在矮屏滚不到底
卡片高约 371px，而 `h-full flex items-center` 在内容超高时让它上下**同时**溢出，
溢出到顶部那段是滚不到的（`scrollTop` 最小是 0）—— 实测 568x280（横屏手机，
或软键盘弹出后的可视高度）下「登录」按钮完全在视口外，光加 `overflow-y-auto`
也够不着。
改用卡片自己的 `my-auto` 而不是容器的 `items-center`：auto margin 在空间不足时
自动退化为 0，矮屏变成正常的顶对齐可滚布局，高屏仍然垂直居中
（390x844 与 1280x800 实测 centered=true，568x280 下滚到底能看到按钮）。
## 两侧都加了检查
- 结构断言：七个页面级组件都必须含 `overflow-y-auto`；
登录/初始化页必须有 `my-auto` 且不用 `h-full ... items-center`
- 实测脚本新增 `scrollHealth()`：每页都有滚动容器，且没有内容被
`overflow-hidden` 的父级裁掉
判据刻意是「**有**滚动容器」而不是「当前正在滚动」—— 内容暂时不够高时后者
为假，但页面是健康的；真正的 bug 是根本没有那一层。
## 验证
窄屏实测 18 项 + 宽屏回归 5 项全通过；结构断言从 28 条扩到 37 条。
生产已部署。
|
2026-09-03 07:39:52 +08:00 |
|
|
|
342282b92c
|
fix: 窄屏实测修复 —— 删抽屉、44px 命中区、触摸设备可见的次要动作
用 playwright 连本机共享 Chromium，在 390px（iPhone 14 Pro）与 320px
（iPhone SE）量真实盒子。之前的窄屏适配是「照着规则写对」，实测发现
一个功能性 bug 加五处可用性问题。
## 抽屉式侧栏遮挡底部导航（真 bug）
抽屉是 `fixed left-0 top-0 bottom-0 z-50`，铺满整个视口高度；底部导航没有
z-index。抽屉打开时点最左那一项「收件」，elementFromPoint 命中的是抽屉里的
SVG，不是导航按钮 —— 按钮在那里、尺寸也够、CSS 规则也没写错，只有命中测试
才能发现。
**删掉抽屉而不是给导航加 z-index**：抽屉装的六项（收件/发件/联系/用户/新建/
管理）与底部导航完全重复，唯一独有的是退出登录。为一个按钮维护一套 fixed
层级加遮罩不划算，而它还附带「Esc 关不掉」「底层未锁滚」两个毛病。
退出登录移到「我的」页 —— 它与密码、密钥同属「账号自身」，而那页此前根本
没有退出入口。`NavToggle` 与 uiStore 的 navOpen/toggleNav/closeNav 一并删除。
## 触摸命中区：新增 .tap
详情页那排工具按钮视觉高度只有 15-16px（实测「标记已读」48x16、「对话树」
54x16、「转发」42x16、「抄送」20x15），移动端下限是 44x44。
直接加 padding 会把本来就挤的头部撑散、320px 下换行，因此用居中的透明伪元素
扩大命中区：**视觉一像素不动**。只在 max-width:767px 生效 —— 桌面用鼠标精度
足够，而扩大后的命中区在密排工具栏里会互相重叠，点一个可能命中隔壁那个。
覆盖 MailView / ContactPanel / WorkCard / ModelScopePanel / AdminUsersPage /
ComposePage / ThreadView / KeyPanel / QuotaPanel / Attachments / BackButton。
## 看不见却按得动的按钮：新增 .reveal
`opacity-0 group-hover:opacity-100` 在没有 hover 的设备上永远是 opacity:0，
**但仍然接收点击** —— 实测联系人列表里 elementFromPoint 命中的就是那个看不见的
「归档」。一个看不见却按得动的破坏性按钮比没有按钮更糟：人以为点的是卡片，
实际归档了一条会话。
改为默认可见，只在 `(hover: hover) and (pointer: fine)` 时隐藏。
单看 hover 会把带触摸板的平板算进去。
## 对话树
- 缩进随屏宽自适应：固定「每级 20px、上限 8 级」= 最多 160px，320px 屏还要
去掉 px-4 的 32px 与连接线 18px，卡片只剩 110px，发件人一行直接被 truncate
吃掉。窄屏改为每级 10px、上限 5 级
- 补返回出口：原先只有「关闭」。两者语义不同 —— 返回退出整个详情栏回到列表，
关闭只收起树、留在这封邮件上
## 把实测脚本留进仓库
`web/test/manual/`（`npm run test:narrow` / `test:wide`），不进 npm test ——
要一个跑着的浏览器加一个活的 Gateway。
留着而不是用完即删，是因为结构性断言守不住「按钮实际多大、点下去命中谁」，
而这次最严重的 bug 恰好只有 elementFromPoint 能发现。helper 里两个函数专门
为此：tapTargets() 量 .tap 的真实命中区（伪元素尺寸，不是 boundingBox），
hitTest() 验每个元素点下去是否命中自己。
## 验证
- 窄屏 13 项 + 宽屏 5 项全通过。宽屏回归特意验了两件只该在窄屏生效的事：
.tap 伪元素 content 为 none、没有返回按钮
- narrow-layout.test.mjs 从 20 条扩到 28 条，逐条钉住上面每个修复
- 无横向溢出：390px 与 320px 下 scrollWidth === clientWidth
- 生产已部署
|
2026-09-02 23:53:59 +08:00 |
|
