|
|
4a01297dfe
|
fix(安全)★★: 主进程零导航拦截 —— 加 will-navigate / 新窗口拒绝 + 单实例锁
**主进程此前没有任何守卫**（实测 grep 0 命中：setWindowOpenHandler、
will-navigate、requestSingleInstanceLock 全无）。
在 `loadFile(dist/index.html)` 下，邮件正文里的链接（react-markdown 会渲染
`<a href>`）点下去会**在应用窗口里导航走** —— 一个 `href="https://…"` 就足以
把整个应用窗口变成浏览器，而窗口标题与 preload 注入的 API base/token
全部暴露在那个站点上。
★ **本条防的不是 XSS**：`markdown-xss` 守的是渲染层（无 rehype-raw、
defaultUrlTransform 中和 javascript:），**目前没有 XSS 面**。
这里防的是**导航逃逸** —— 让外部站点**借用**这个窗口与 preload 上下文。
两者失效方式不同，所以分开钉。
**① setWindowOpenHandler** ⇒ 一律 `deny`，地址交系统浏览器。
`allow` 会给那个站点一个**带 preload 的窗口**。
**② will-navigate** ⇒ 拦下并 preventDefault。
★ 但必须**放行本应用自己的加载**（prod 的 `file://` / dev 的 `DEV_URL`）
—— 只会 preventDefault 的实现会把应用自己锁死，首屏进不去。
这是「过严的守卫同样是缺陷」，判据专门为它加了一格。
**③ 外跳只放行 http/https**：file: / javascript: / 自定义协议交给
`shell.openExternal` 意图不可控；`new URL()` 对畸形输入会抛，必须 catch。
**④ requestSingleInstanceLock**：双击图标此前会起**两个进程** ——
两条 SSE 连接、两套 `accounts.json` 并发写入（那个文件是 tmp+rename 原子写，
并发即「后写的赢」），而用户以为只有一扇窗。
**同时修的两处双提交**（形状与 ④ 同源，都是「busy/state 要到提交后才为真」）：
· PermissionPanel.submit：审批是本工程**唯一带副作用且不可撤销**的动作
⇒ 同帧两次激活会发出**两条** decidePermission（服务端记两次账）。
照同文件 ForwardBar 的 `inFlight` 形状改。
· Attachments.handleFiles：`uploading` 只加在按钮的 disabled 上，
`<input type=file>` 本身无闸门 ⇒ 上传期间重入会拿到**上一次的 items 闭包**
⇒ onChange 把上一次结果整批覆盖，表现为「附件少了」且**无任何提示**。
★ 清 `input.value` 必须与闸门**成对**提前：只提前清而不加闸门，
会亲手制造「上传中重选同一文件 ⇒ value 已空 ⇒ change 照触发 ⇒ 二次上传」。
**判据（新建 main-process-security.test.mjs，14 格，已接线）**
按括号配对取函数体/实参，**不用** `\{[\s\S]{0,80}` 窗口（§1 第三次露头）。
变异测试 **10 个全部抓住**：去掉 deny / 去掉 preventDefault / 守卫写死不放行自己 /
放开所有 scheme / 拿不到锁不退出 / sandbox:false / contextIsolation:false /
second-instance 删 show() / 删整个 if / 删 restore()。
★ PermissionPanel 那条新判据第一版是**假绿**：`fireEvent.click` 连发两次
（不在 act 里）**删掉闸门也照样绿** —— 两次 fireEvent 之间 React 提交了一次，
第二次点到的是已 disabled 的按钮。必须放进**同一个 act**（同批次、不提交）
才复现。`userEvent.click` 每次都 await 一轮 ⇒ 它测不到同帧。
这条已写进判据注释，免得下一个人再写一次。
**边界 / 未做**
· 这些是**静态**断言，证明守卫被写下来了，**不证明运行时生效**（那要真起窗口点链接）。
· 没有把 webPreferences 的值当"够不够安全"来评审 —— 那属于安全评审，不属可机检；
本条只钉「不许被放松」。
· X-2（index.html 无 CSP）没做：首帧防闪屏那段内联脚本要求 'unsafe-inline'，
加 CSP 是在**降低**强度的前提下加一层，值得单独一轮 + 真机验闪屏，不夹在本次。
|
2026-10-03 11:33:51 +08:00 |
|
|
|
18b148e476
|
跨端: fix(客户端) 换身份必须清全部账号数据 ＋ 鸿蒙管理台门禁改三态
两份审查报告（`docs/reviews/electron-gui-review.md` /
`harmony-client-review.md`）里两条**数据隔离**缺陷。
## ① 换身份不清数据 ⇒ 在新账号的界面下显示旧账号的邮件
`setActive` 之后 `api/config` 单例里的 API_BASE 与 bearer 就翻到了新账号，
于是此后每个请求都带**新账号**的凭证。而各 store 里还留着**旧**账号的：
· mailStore.sent / currentMail
· sessionStore.sessions / currentSession / currentSessionMails
· contactStore.contacts / archivedContacts
⇒ 肉眼完全看不出来（不报错、不空屏），而**从旧视图发出的写操作**
（归档 / 转发 / 批准权限）改的是**新账号**。
新增 `src/lib/resetAccountData.ts` —— **一处实现，三个入口都调它**：
① 主动切账号（AccountSwitcher.pick）
② 登出（authStore.logout）
③ 任意接口 401（api/client.ts 的 unauthorized 回调 → markAnonymous）
只在 ① 里清是最容易漏的那种做法：② 和 ③ 各自还会重新泄露一次，
而它们都不在切换账号的代码路径上，grep 也找不到。
**身份变化有三条路径，清空也该有三条。**
★ 只碰**数据** store；`uiStore` 的 reset 仍由 App.tsx 负责
（它还要复位窄屏分栏、写信态那些纯界面状态）。
判据：`test/stores/resetAccountData.test.ts`（4 格）。
## ② 鸿蒙管理台门禁**失败开放**（fail-open）
`AdminUsersPage.ets` 原来的条件是 `roleKnown && !this.isAdmin`，
于是 `roleKnown === false`（loadRole() 失败、**身份还没读到**）
落进 else 分支 ⇒ **把完整管理台整个渲染出来**。
一次网络抖动 = 管理入口对所有人可见。
讽刺的是该文件自己的头注释写的就是正确规则
（「不能把读不到当成是管理员」）—— 代码做的正是这条注释禁止的事。
⇒ 改三态：`!roleKnown` 显示「正在确认身份…」、`!isAdmin` 显示墙、
否则管理台。
服务端 `middleware/user.go` 的 `AdminOnly` 仍在，所以**不是越权**；
但非管理员会看到完整用户列表、建号表单、改密入口 ——
属于客户端信息泄露 + 无意义的失败请求风暴。
|
2026-09-28 08:46:01 +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 |
|
|
|
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 |
|
|
|
7ef3ea7306
|
fix(webui): 宽屏也同步折叠策略 —— 头部与回复框默认收起（正文 48% → 90%）
用户（2026-09-14）：「我发现宽屏布局也有邮件内容显示区域过小的问题，
宽屏也同步窄屏的折叠策略吧」。
上一版是「窄屏默认收起 / 宽屏恒展开」，理由是「宽屏横向空间够、不该引入多余
点击」。那条理由只看了**横向**：实测 1280x800 下详情栏里头部 139px(17%)、
回复框 246px(31%)，留给正文的只剩 385px（48%）—— 竖向一样不够用。
改法：两种宽度用同一套默认值（收起），点标题行 / 悬浮球展开。
- CollapsibleHeader：useState(false)，toggle 不再以 narrow 为条件，展开箭头常显；
- ReplyBar：收起态恒为悬浮球（原来只有窄屏才收），「收起」按钮宽窄都有，
autoFocus 不再以 narrow 为条件；
- MailView 两个根节点补 relative —— 否则宽屏下 `absolute` 会一路找到视口，
悬浮球会挂到窗口右下角而不是这块详情栏里。
实测（真浏览器量盒子，1280x800，同一封正文撑满的长信）：
头部 139 → 48px，回复框 246 → 0（收起为球），正文 385 → 722px（占视口 48% → 90%）；
点标题展开 / 点球开输入框（带焦点）/「收起」收回，三条都通。
窄屏 390x844 同项通过，横向溢出 0。
判据：narrow-layout 里三条旧判据钉的是「窄屏专属」，已改成钉「宽窄同一套」，
并新增两条（折叠分支里不得再有 `narrow &&`；悬浮球必须锚在详情栏内）。
wide-regression 补 6 条宽屏实测 —— 此前宽屏的折叠行为**一条判据都没有**，
这正是它坏掉而没人发现的原因。
已知遗留（另行报告，本次未改）：窄屏上回复框展开后，第一次点它上面的按钮
（抄送 / 回复全部 / 收起）会被吞掉 —— 焦点离开 textarea 会让 .form-editing
失效、底部导航重新占位 71px，按钮在 mousedown 与 mouseup 之间从指针下移走，
click 目标退化成公共祖先。HEAD 上已存在，与本次改动无关。
|
2026-09-14 15:38:49 +08:00 |
|
|
|
0c4100802f
|
fix(webui): 顶部改气泡式 —— 列表头与详情头从"通栏 + 下边框"改成浮动玻璃卡
用户：「同时顶部为什么不是气泡式的而是栏目式的」。
原因很直接：这两处写的是**通栏**（`px-4 py-3.5 border-b border-gray-200`）——
铺满面板宽度、靠一条下边框划分，就是"栏目/工具条"的语言；而列表项刚改成
"每项一张卡"之后，顶部还留着通栏，风格自然对不上。
- 列表顶部（标题 + 账号切换 + 计数）：`glass-card mx-2.5 mt-2.5 px-3.5 py-2.5`
- 详情顶部（发件人/主题/时间那条）：同样改成 `glass-card` 气泡
实测（自有浏览器，壁纸开）：圆角 **14px**、底色 `rgba(255,255,255,0.78)`、
在 320px 宽的面板里 left=90/top=65 ⇒ **四周有 10px 内缩**（真的浮起来，不是通栏）。
## 一个我没动的地方（需要你确认）
「通信」的内部页签（收件箱 / 发件箱 / 授权）现在是**下划线式**，不是气泡式。
我特意没动它：更早一轮你给过相反的意见 —— 那时它是"白色胶囊 + 阴影"浮在面板上，
你说「二级页面与其他位置极其割裂」，我才改成下划线。
如果你现在要的是**气泡式的分段控件**（半透明玻璃胶囊 —— 比当年那版少了阴影、
且底色走玻璃令牌，不会再有"白底压白底"的割裂感），说一声我就换；
或者你指的就是刚改的这两处，那这条就算完成。
|
2026-09-14 13:44:49 +08:00 |
|
|
|
4d6e944220
|
feat(webui): 打开即已读 + 回复即已读
用户：「现在邮件需要完全手动标记是否已读而不支持点进去自动已读或者回复自动已读」。
## 改法
- **打开即已读**：MailView 里加一个 effect —— 当前邮件是 unread 且**真正可见**时
调 `markRead`。两个刻意的细节：
1. 窄屏下 MailView 可能已经渲染但被列表覆盖层盖住（NarrowStack）⇒ 必须等到
`narrowPane === 'detail'` 才标，否则"滑过去但没看"的邮件也会被标已读；
2. 只对 `unread` 发请求（已读的再标一次是白跑，还会让接口日志一直响）。
- **回复即已读**：ReplyBar 发送**成功之后**才标（发送失败不该把"我处理过了"记下来）。
- 手动标记按钮保留（显式动作仍然有用）。
## 端到端验证（真浏览器 + 真库）
造一封未读 → 浏览器里展开会话分组、点开那封邮件 →
POST /read → 200
mail_reads 里出现 (reader=gui-lab)
冗余列 mails.status: unread → read
即"打开即已读"确实生效，而且是记在**读者维度**上（不会像旧的邮件级已读那样
被别人一标就没了）。
## 一个过程记录
前两次验证都"没有发出 /read 请求"，我一度以为代码没生效。其实是**点错了对象**：
会话分组默认折叠，`button:has-text(主题)` 匹配到的是**分组那颗**，点它只展开、
不选中邮件（所以不触发已读 —— 这恰恰是正确行为）。展开后再点具体邮件行才触发。
判据必须点"用户真正会点的那一层"，这句话这次又应验了。
套件：vitest 15 文件 / 258 用例全绿。
|
2026-09-14 13:12:36 +08:00 |
|
|
|
5ce25f6fdb
|
fix(webui): 修侧栏点击无法翻页 + 回信 UI 统一成一个组件
用户两句：「侧边导航栏完全不可用，点击无法翻页，而且窄屏显示不全」、
「按顺序做吧」（= 做回信 UI 统一）。
## ① 侧栏点击无法翻页（严重，我的错）
导航合并时我把点击目标写成：
onClick={() => setViewMode(target || commTab || modes[0])}
只有「通信」有意回上次的子页签，而**日历/联系人没有 target** ⇒ 点它们会跳到
`commTab`（收件箱）⇒ 表现为"点了没反应/不翻页"。
修成 `setViewMode(target ?? (isComm ? commTab : modes[0]))`。
**为什么没被拦住**：我的验证全在看**结构与样式**（导航项数、徽标、圆角、玻璃、
对比度），**一次都没点过**。所以补了 `test/components/Sidebar.test.tsx`：点每一项，
断言落到它自己那一项，并带一条反向对照。真浏览器点击也复验：日历→日历页、
联系→联系人、通信→回通信页。
## ② 回信 UI 统一（用户点名的欠账）
新增 `src/components/Composer.tsx`：**形状**（输入区 / 动作行 / 提示）只有一处定义，
**差异**用 `header`（选项胶囊）、`footerExtra`、`submit.tone`、`density`
（compact=批注、roomy=回信正文）条件渲染 —— 差异是数据，不是又一套 UI。
三处各写一套的地方现在都走它：提问型授权表单、审批型（同意/拒绝）、ReplyBar 回信。
输入框的边框/圆角/聚焦环/禁用态从"抄了三遍"变成一处。
**重构时我引入过一个危险的错**：给审批型加了个"提交备注"按钮，兜底用 `options[0]`
（= 同意）⇒ 点一下就**默认批准**。被既有判据当场抓住（`PermissionPanel` 两条红），
已改成"点选项即提交"（`submit` 现在是可选的），并用 `variant="action"`
把同意/拒绝的颜色语义恢复成原来的实心绿 / 浅红。
## ③ 我自己的流程问题（写下来）
- 结构类改动必须配一条"**点它**"的判据 —— 这次就是缺了它。
- 单测里改 store 后必须 `rerender` 再点：否则闭包里是旧值（我第一版因此误判代码有问题）。
- 窄屏"显示不全"**没能复现**：390×844 与 320×568 都量了 —— 无横向溢出、
内容面板完整落在悬浮导航之上、最后一行完整可见。需要用户指出具体页面。
判据：vitest **15 文件 / 258 用例全绿**（含新增 Sidebar 点击 4 条）。
|
2026-09-14 12:26:06 +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 |
|
|
|
2b6eb97bc9
|
test(webui): 横竖屏判据跟上新契约（横屏=侧边导航、列表固定 320）
`rotate-verify.mjs` 10/10。途中判据自己错了两次，都记在这里：
1. `content` 选择器取 `.narrow-shell > *:not(.narrow-nav)` —— 横屏改用侧边导航后，
第一个子元素变成了 60px 侧栏 ⇒ 把侧栏当内容区来判断排布，报出一条假失败。
改成同时排除 `.bg-chrome-900`。
2. 原先只断言"排布换了"，没断言"导航在哪边" ⇒ 用户后续追问的侧边栏
根本没被判据覆盖。现在补：横屏侧栏必须 60px 且在左侧、底部导航必须不存在；
竖屏反过来（底部导航存在、无侧栏）。
|
2026-09-14 11:36:50 +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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
bbddee26b9
|
feat(permission): 待办带上失效时刻；越窗的决策不再假装成功
# 起因：一次端到端验证暴露的静默缺口
建了示例工程让 pi 通过邮件干活（plan 档拦截、workspace 档审批、多 agent 指派）。
plan 档与多 agent 都通过，workspace 档却卡住：**人在界面上批准了一条待办，
接口回 200，但那件事什么都没发生。**
追下去是三件事叠在一起：
1. **桥**等不到决策时（pi 的回合超时 TURN_TIMEOUT_MS，默认 10 分钟）会拆掉 worker
与它的决策路由表；此后再来的决策只会作为**通知**投给 Agent，不恢复当时那次
工具调用 —— 该轮已经结束了。
2. **服务端**只有 `permission_requests.result IS NULL`，没有「失效」概念。
迟到决策照样回 `{"status":"decided"}`。
3. **前端**只看 `permission_result` 判待决/已决，没有任何时间或失效提示。
于是那条待办永远挂在授权页上显示「等待你决策」，人点了也白点。这是 I-5
（失败必须当场可见）要消灭的那类静默成功，而且**跨所有客户端**成立 ——
WebUI 不显示，Electron / Harmony 同样无从显示。
# 设计：邮件上给「时刻」，不给「是否失效」的布尔值
服务端不知道插件此刻是否还在等（那是它进程内的状态），所以只标出「这封待办已经
放了很久」，不替插件宣布裁决。
关键取舍：对外只发**截止时刻**（`permission_expires_at`），不发 `stale` 布尔值。
布尔值是「发出那一刻」的快照 —— 经 SSE 推送并被客户端缓存后会永久停在旧值，
界面就会一直显示「等待你决策」。时刻是持久事实，任何客户端在任何时候都能自己
比出现在过没过期。这也是为什么推导而非落库：它是 created_at 的函数，存下来会失真。
`DecidePermission` 的响应里则用布尔值（`expired`）—— 响应本身就是「此刻」的
一次性快照，不会像邮件那样被缓存反复展示。
# 改动
- `models.PermissionWaitWindow`（10 分钟，与 pi 桥的回合超时同量级）+
`PermissionDeadline(createdAt)`；两端共用这一处算式，避免「界面说已过期、
决策说没过期」。
- `Mail.PermissionExpiresAt` / `PermissionRequest.ExpiresAt`：由读路径推导填充。
5 个读路径各插一行（`AttachPermissionDeadline*`）—— 与审计修复① 加
permission_kind 时同一套路数，漏掉任一路径只会静默变成 nil。
只给**仍未决策**的待办填，已决策的不再是待办。
- `decideResponse`（抽出纯函数以便测试）：越窗时加 `expired` + `warning`，
讲清「决策已记录、但不会恢复原调用」。**不改 HTTP 状态码**：决策仍是人的真实
意愿、仍然有效（桥会当通知投递，Agent 重起一轮），所以不能拒掉，但必须说清。
- 前端：列表里失效项不再与「还能立刻生效」的长得一样（灰底 + 「可能已失效」）；
批准面板在决策**前**（人正要按下去）与决策**后**（人以为事情办了）都显示提示。
# 验证
- Go：models/repo/handler 三处新增测试全绿；全量 `go test ./...` 通过；vet 通过
- 前端：typecheck 通过；200 项测试全绿（含新增 4 条失效态）
- 真机（用现成的过期待办，未造合成数据）：
- `/permission/pending` 返回 `expires_at` = 创建 + 10 分钟，服务端判定已过窗
- 邮件载荷带上 `permission_expires_at`（前端列表的数据源）
- 对过期待办提交批准 → `{"expired":true, "expires_at":…, "warning":"该请求已超过
等待窗口（10 分钟）…不会恢复当时那次工具调用…"}`
- 已用 redeploy-gateway.sh 部署，服务 active、四 agent 心跳正常、日志无 panic
|
2026-09-11 22:02:25 +08:00 |
|
|
|
429149e118
|
chore(format): 撤销误入提交的整体重排，并关闭本仓库的格式化器
# 发生了什么
pi-lens 内置「安全格式化」：它会自动安装 biome 并对**编辑过的文件**跑
`biome format --write`。本机原先没有任何 biome 配置，于是 biome 用它自己的
默认值 —— tab 缩进 + 双引号 —— 把文件整体重写。
我在 19a3161 那次提交里用了 `git add -A`，把这批与功能无关的重排一起扫了进去：
约 7000 行改动散落在 20 个文件上，使那次提交无法审查，还掩盖了
server/internal/handler/permission.go 的一处删行（实为文件末尾空行，无代码丢失）。
# 为什么是「关掉」而不是「配置成我们的风格」
试过把缩进/引号/lineWidth 全部对齐本仓库习惯（biome.json + space/2/single/
lineWidth 120）：`biome format --write` 仍然改动 17 个文件。原因是本仓库从未按
biome 的规则排版过 —— 注释按语义换行、数组与调用按可读性手工折行，
这些无法由格式化器还原。也就是说只要格式化器开着，每次编辑都会产生与内容无关的
大面积 diff，把真正的改动埋掉。
因此 biome.jsonc 里 formatter 与 linter 都关闭：本仓库的静态检查由
tsc / go vet / tree-sitter / ast-grep 与各自测试套件承担，不引入会改动无关行的
自动修复。
（pi-lens 这一版把 format 服务的 enabled 硬编码为 true，没有配置开关，
所以只能在仓库侧用 biome 配置让它不动文件；已验证 `biome format --write`
对这些文件零改动。）
# 本提交内容
把 19a3161 里除「有意改动」外的 20 个文件还原到重排前的样子。
19a3161 中真正有意的改动是 deploy/install.sh 的扩展注册与
plugins/pi-mail-bridge/extension/index.ts 新文件，两者原样保留。
验证：Go 全量、三桥插件（320/362/409）、前端 196 全绿；
`biome format --write` 对还原后的文件零改动。
|
2026-09-11 12:03:51 +08:00 |
|
|
|
19a3161ee4
|
feat(pi): 交互式 pi 会话接入邮件工具（send_mail/read_inbox 等 10 个）
问题（⑧）：守护进程用 noExtensions:true 起会话，它的邮件工具只给模型在邮件
会话里用；人在 TUI 里敲的 pi 拿不到。结果是平台的建设者自己收不到邮件 ——
一个「邮件驱动」的平台，维护者只能绕到 curl + 密钥直连 Gateway 才能看收件箱。
新增 plugins/pi-mail-bridge/extension/index.ts：把同一套工具（createMailTools）
注册到交互式会话。两者是同一条 AgentMail 身份（agent pi）的两个入口，与 DSH 的
「TUI + 邮箱是同一个 Agent」一致。
密钥解析顺序（交互式 pi 的环境里没有 AGENTMAIL_*）：
1. 进程环境
2. AGENTMAIL_ENV_FILE（默认 /etc/agentmail/pi.env）—— 与守护进程同一把密钥，
因此身份一致
3. AGENTMAIL_CONFIG_DIR/agent.key 或 ~/.agentmail/agent.key
（兼容 key 与 key_token 两种字段名；实测本机文件用的是 key_token，
只认 key 会静默读不到）
拿不到密钥时不注册任何工具并明确告知 —— 挂一组永远 401 的工具比没有更糟。
不注册 connect_to_server：它会重写 Gateway 坐标并重新登记密钥，而交互式会话与
守护进程共用同一身份，一次 TUI 对话不该改到守护进程的配置。
为什么不会重复注册（读 SDK 实现确认，并用探针实测）：
resource-loader.js 里 noExtensions 为真时只用 cliEnabledExtensions，
settings.json 的 extensions 数组被排除 —— 即 noExtensions:true 只加载
命令行 -e 传入的扩展。
探针：noExtensions=true → 扩展数=0；false → 16 个且含 pi-mail-bridge。
deploy/install.sh 增加幂等的扩展注册步骤（写入 settings.json 的 extensions）。
验证：headless pi 实际调用 read_inbox 返回真实邮件主题；工具清单含
send_mail/read_inbox/read_mail/forward_mail/upload_attachment/download_attachment/
suggest_address/list_contacts/session_participants/read_thread（10 个），
connect_to_server 按设计排除。
|
2026-09-11 11:32:47 +08:00 |
|
|
|
f91efd2d8d
|
feat(question): DSH ask_user_question 桥接 + 前端问答面板 + 待办字段全路径透出
问题（P0）：DSH 有两个独立的人机交互 seam —— approval/request（危险工具审批）
与 ask_user_question → ctx.userQuestions（模型主动提问）。原来只桥接了前者。
邮件驱动的会话没有本地 UI，而 ask() 的 provider 是 DSH host 注册的本地 UI 实现，
于是在那里等人点选永久等不到，那一轮工具调用**静默挂死**。
修法（不抢注全局 provider —— registerProvider 只允许一个活动实例，抢注会让
平台自己的界面失效）：在 tools/execute around-dispatch 里只对**邮件驱动**的
会话接管 ask_user_question，其余原样 next()。失败一律当场报错而不是 next()：
下一个 answerer 是本地 UI，邮件会话没有兜底 UI，放过去就是挂死。
- lib/user-question.js（三桥逐字节同源，14 例测试）：DSH questions[] ↔ AgentMail
单问题询问邮件的双向映射。多问题时把选项并集摊平、按 label 归属分配回各问题
（label 认不出来就不猜测放行）；无选项题走自由文本 custom。
- Gateway：kind=question 且无选项时**不再**回落「同意/拒绝」（那会让自由文本
问题变成两个毫无意义的按钮）；主题按类型区分「权限请求 / 需要回答」；
推送 payload 带上 permission_kind / multi_select / options。
- mails.permission_kind / permission_multi_select 此前只存在于结构体与写入路径，
五个读路径的 SELECT/Scan 都没带 —— 前端永远拿到空串，把提问渲染成批准/拒绝。
container 修正五处并加 repo 测试（含反向验证：删掉任一处字段，测试即失败）。
- 前端 PermissionPanel：question 走「勾选 + 自由文本」，多选/单选、空回答禁止提交；
approval 路径不变（回归测试覆盖）。
测试：opencode 316 / dsh 349 / pi 405 / 前端 185 / Go 全量 全绿。
|
2026-09-11 10:44:18 +08:00 |
|
|
|
f9d757b5e5
|
chore: directory migration - gateway→server, web→client/electron
|
2026-09-08 19:16:35 +08:00 |
|
