|
|
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 |
|
|
|
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 |
|
|
|
d5cfcbdc9c
|
fix(权限): 409 的第二种含义是「本档不该问」——四桥都补上；状态写入点不再兜默认档
线上事故（jianf 经 pi 转达）：补投路径漏传 permission_mode，插件拿 undefined 兜了
workspace 档，把 full 档会话写成 workspace-write + ask —— 不是"拦一次"，是一整轮
工具能力降级，且状态留在会话里；随后该会话每次受守卫调用都撞 409。
四件事：
1. **状态写入点不接受默认值**（新增共享 `modeForStateWrite`）：缺字段/脏值 → `null`
= 不写状态。"默认值可以出现在**决策**里，不可以出现在**状态写入**里。"
同时保留共享契约的 fail-closed：真读到 workspace 才写 workspace。
2. **409 的两种含义分开处理**。`allowed-once` 只绕过**审批**，改不了**沙箱** ——
所以 dsh 桥在放行前先把服务端给的权威档位**写回会话**（这也就成了自愈路径：
已经降级的会话，下一次带档位的 409 会把它修回来）；只认服务端明说的 full，
plan 与"链上没有人类"照旧 fail closed。
3. **同一处缺陷在 zcode / opencode 也在**（`hooks/permission.mjs` 与 `index.js`
都把 409 当永久失败拒绝）。我先前在回信里写过"这两个桥不转发权限询问，不需要改"
—— 那句话是错的，我当时的搜索面只有 `<plugin>/src/*.mjs`。按 pi 的要求把这条
**否定性事实变成常驻判据**后，它第一次运行就红给我看。四桥现在都有
「409 + full → 放行」，且**排在永久失败分支之前**（含顺序变异自检）。
4. **共用测试重新同源**：`test/catchup.test.mjs` 从 `153985e` 起就是分叉的
（我那版把平台专属路径写进了共用文件），而 `deploy/install.sh` 第 24 行会跑
`check-shared-libs.sh` —— 也就是说**部署一直是红的**，我没跑过那个脚本。
共用文件只放契约（值/行为），跨平台配对judge 移到平台专属文件，四份逐字节相同。
另外把"判代码 vs 判理由"从记忆变成代码：`test/lib/read.mjs` 提供 `code()/prose()/bytes()`，
判据目录里不得再裸用 `readFileSync`（新判据 `criteria-hygiene` 管，含读取器自检）。
判据证据（每条都做过"能不能红"的变异）：
- 写回去掉 → 红；纠正块挪到普通 409 之后 → 红；状态写入点退回兜默认 → 红；
- zcode/opencode 的放行分支拿掉 → 各自红；共用测试分叉 → check-shared-libs 红。
各套件：dsh 388、pi 443、zcode 387、opencode 333（均经 npm test，含 tsc）；
electron `npm test` 15/15 判据绿 + vitest 266 + typecheck；`check-shared-libs.sh` 退出 0；
Go `go test ./...` 全 ok。
|
2026-09-14 16:21:27 +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 |
|
|
|
ecde1f7542
|
test(webui): 焦点判据钉到回复框自己的 Composer（变异测试抓到的弱判据）
上一版写的是全文件搜裸 `autoFocus`，而 MailView 里预算输入框、编辑器还有几处
autoFocus ⇒ 把回复框改回 `autoFocus={narrow}` 时判据**照样绿**。
按判据规范 §1 改成取那个标签自己的 `/>` 体再断言。
四组变异全部红在对的那条上：
useState(false)→useState(!narrow) → 红 1（头部不再分叉）
if(!open)→if(narrow && !open) → 红 2（悬浮球 + narrow-only 分支）
去掉一个根节点的 relative → 红 1（悬浮球锚点）
autoFocus→autoFocus={narrow} → 红 1（焦点）
|
2026-09-14 15:39:24 +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 |
|
|
|
ec90cba129
|
test(criteria): 抽出共享 check/finish（marker 不再靠记性）＋ 失败信息自带修法
pi 的三条增量，前两条落地：
1. **错误信息自带修法**：受众不只是读过规范的人 —— 并发写 WebUI 的 agent 新加判据时不会打开
CRITERIA.md，看到红的第一反应可能是"套件坏了"。所以把可照抄的修法写进那条错误本身
（共享 helper 的用法 + 样板文件路径），并说明 node:test 的判据不用管。
**red 是 ta 一定会看到的，文档不一定被打开。**
2. **marker 由共享 helper 打印**：新增 test/lib/checks.mjs（导出 check/finish），
计数只可能在该模块内发生 → "漏打 marker"与"计数写错位置"这两类在新文件上不可能发生。
为避免"写了没人用"（本仓踩过的坑），同时把两个手工计数的判据改用它：
narrow-layout（原来只有 failed 计数）与 markdown-xss（原来根本没有计数器）——
条数不变（52 / 9），套件仍全绿。
未回改其余 10 个文件：run-all 的 marker 检查已经覆盖它们。
|
2026-09-14 15:11:47 +08:00 |
|
|
|
a8ac2fc28b
|
test(criteria): 闭环——判据自报条数 + 每文件期望条数（只增不减的棘轮）
pi 指出的残余缺口：我上一轮加的自检 4 是**文本证据**（文件里有 `test(` / `check(` /
`process.exit(1)`），只能证明"**有能红的路径**"，不能证明"**它跑过**"。反例很短：
```js
const check = () => {}; // 实现被换空（现实形态：合并冲突改坏实现）
check('a', false); // 存在、也执行了，但什么都不会红
console.log('主题：通过'); // 有输出
```
## 落地（pi 给的闭环形状）
1. 自定义 `check()` 的判据结尾打一行机器可读汇总 `RESULT pass=<条数> fail=<失败数>`
（`node:test` 的判据不用改，已有 `# pass N`）；
2. `run-all.mjs` **只解析这个固定 marker**（不猜口语汇总——「窄屏布局：全部通过」里没有数字，
按数字猜会误报，这一点我上轮已经实测过）；
3. 与清单里登记的**期望条数**比对，**低于 → 红**。
关键细节：**计数写在 `check()` 内部**（theme/background 原本就在内部 ++；
narrow-layout 只有 failed 计数，补了 passed；markdown-xss 按 payload 条数算）。
写在调用点或靠扫源码的话，"实现被换空"就看不见了。
棘轮"只增不减"：加判据**不用**改那个数，只有"条数掉了"才红。期望值按**实测**回填
（9/52/8/30/42/15/28/5/23/5/3/2）。
附带的可见性收益：这几轮我一直用"13→14""19→28""34→42"当信号，现在它成了判据 ——
某次改动顺手删掉两条判据、或某条被跳过，会立刻红。
## 变异
- pi 那个反例（`check` 换成空函数）→ 红（`自报 0 条 < 登记的 30 条`）；
- 删掉 5 条 `check(` 调用 → 红（`自报 47 条 < 登记的 52 条`）。
## 规范
§6.5 新增"涉及运行时行为的结论必须实测过才能写进规范/判据"——同一个错这轮犯了两次
（我从"报告 0 个测试、退出 0"推断"退出码被吞"，实测是照传；pi 拿我这个结论又建了一个洞）。
规则：**一次观察只支撑你看到的那一层**。
§6.6 记闭环形状与代价（故意删判据要同步改数字，属于一次可复核的显式编辑）。
⚠️ 并且如实记下一次**我自己违反规范**的事：写 §3 那条"变异后别用 `git checkout` 还原"的人
（就是我）在这次变异验证里又用了 `git checkout -- <文件>`，把刚加、尚未提交的 marker 抹掉了。
规矩写下来不等于会遵守 —— 已把这条实例写进规范，让人知道它是活人踩的坑。
## 验证
`npm test` 退出码 0（12 个判据文件全绿 + vitest 258/258）；`run-all` 单独跑也 exit 0。
|
2026-09-14 15:06:14 +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 |
|
|
|
f9d757b5e5
|
chore: directory migration - gateway→server, web→client/electron
|
2026-09-08 19:16:35 +08:00 |
|
