111 Commits

Author	SHA1	Message	Date
JianFeeeee	20fc8a5800	跨端: 修三个真崩溃/失败 —— @BuilderParam 丢 this、发送后退错页、漏校验 body ... 用户 2026-09-21：「点击发送邮件直接闪退，点击授权也直接闪退，所有功能全部不可用」。 三个都是**真 bug**，逐个拿到证据后修的（不是猜的）。 ## ① 点「授权」必崩：`@BuilderParam` 把 `this` 换掉了 崩溃日志（`jscrash-…-20260921150832132.log`）给出的栈： Reason: TypeError Error message: Cannot read property length of undefined at anonymous entry (MainPage.ets:1458:23) ← this.requests.length at … Surface.ets:717:7 ← AppHeader 里 this.trailing() `MainPage.ets:1458` 是 `if (this.requests.length > 0)`， 而它住在 `PendingTrailing()` 这个 `@Builder` 里 —— **传给 `AppHeader` 的 `@BuilderParam` 之后，它执行时的 `this` 变成了 `AppHeader`**， 而 `AppHeader` 上当然没有 `requests` ⇒ `undefined.length` ⇒ 崩。 ★ 这是 ArkUI 的老坑：`@BuilderParam` 是**按值传递一个函数**， 调用方的 `this` 不会跟着过去。全仓**4 处**都踩了（`MainPage` 的 `SentCountTrailing`/`PendingTrailing`、`AdminUsersPage`/`SettingsPage` 的 `HeaderTrailing`）—— 它们各自读 `this.loaded`/`this.load()`。 修法：改成**尾随闭包**（`AppHeader({...}) { this.XxxTrailing() }`）， 闭包捕获的是**定义处**的 `this`（本组件的），而不是 AppHeader 的。 ★ 为什么判据没抓到：那 4 处此前都只是"静态源码里有这个 builder"， 而崩溃只发生在**运行时的 `this` 绑定**上 —— 形态判据看不见绑定。 这一条只能靠设备实测（我这次是靠真机崩溃日志）。 ## ② 发送成功后"闪退"：其实是退错了页 `ComposePage.doSend()` 成功分支里是**无条件** `router.back()`。 而内嵌时（宽屏右栏 / 窄屏 `Navigation` 覆盖）写信只是 `MainPage` 的一个 **右栏状态** —— `router.back()` 退掉的是**整个 MainPage**，用户看到的就是 "发送之后 App 没了"（报成闪退）。 ★ 同一个文件里，顶栏「取消」键（上面几十行）**早就写对了**： if (this.embedded) { this.onBack(); return; } this.getUIContext().getRouter().back(); 我加 `doSend` 时没照着抄。`MailDetailView.goBack()` 也是这个正确形状 —— **只有 `doSend` 是那个异类**。已改成与取消键同一判据。 ## ③ 发送真的失败：校验漏了 `body`，且没 trim 日志里 `→ POST …/mail/send` 发出去了，但服务端 400。 直接打服务端复现： curl -d '{"to":"pi@root.new","subject":"t","body":""}' → {"error":"Missing to, subject, or body"} 而 WebUI 的 `canSend`（`ComposePage.tsx:132-138`）是**四个条件**： to.trim() !== '' && subject.trim() !== '' && body.trim() !== '' && … 鸿蒙这边只校验了 `to` 与 `subject` —— **漏了 `body`**。 ⇒ 用户在"正文本来就是可选的"观感下不填正文，请求照样发出去、被拒。 同时补 `trim()`：WebUI 发的是 `to.trim()` / `subject.trim()`， 而 `pi@root.new ` 与 `pi@root.new` 在服务端是**两条不同地址**。 ## 设备验证（改前 → 改后） · 点「授权」：崩（进程消失，新增 jscrash） → **进程存活，页面正常渲染， 待决策徽标 "4" 正确显示**（证明 `this.requests` 绑定对了） · 发送邮件：POST 发出但服务端 400，且"闪退" → **回到收件箱， 发件箱里 `realtest` 已落库**（服务端实测 9 封） ## 另修：候选补全的菜单按 WebUI 补齐四件 用户：「收件人填充能力完全不可用，根本没有与 webui 对齐」。 实测后确认功能是通的（`pi` → `pi@` → 路径 → 会话 → 完整地址， 三段链逐段验过），但**行内渲染漏了 WebUI 的四个要素**（`AddressInput.tsx:186-231`）： ① 别名 `font-mono`（地址类文本全仓等宽） ② 标题在**第二行**（原来挤在右边同一行） ③ `source` 三态视觉：`platform` 蓝胶囊 / `new` 灰字 / `mail` 无标 ④ `unread > 0` 红徽标（服务端 `SessionCandidate.Unread`，带 `omitempty`） `AddressSuggestion` 顺带补 `unread` 字段并守住 `omitempty` （缺键时裸 cast 是 `undefined`，不是类里的 `= 0` —— 与 `title` 同一个坑）。 ★ 另外修掉一个我自己写错的参数：`suggestAddress` 原来把 `'?name=…'` 传给 `ApiClient.get(path, query)`，而**问号是那个方法自己加的** ⇒ 会拼成 `??name=`。约定：`query` 只放 `k=v`，不含问号。	2026-09-21 15:21:47 +08:00
JianFeeeee	125aec1191	跨端: 2in1 键盘可达（Ctrl+N 写信 / ↑↓ 换补全 / Enter 选中）+ 三处判据被实测改判 ... 用户 2026-09-21：「接下来做一下 2in1 上的快捷键，比如快捷键打开发信页面」 「上下键切换发信目标」「回车展开输入框等」 ## ① 打开发信页：Ctrl+N，用官方 `keyboardShortcut` 先查了官方文档再动手，避开两条静默失败的坑： · `keyboardShortcut`（组件快捷键事件，API 10+）「**无论组件是否获焦** —— 只要窗口获焦，快捷键就会响应」。而 `onKeyEvent` 要求**组件先获焦**， 邮件列表里焦点落在哪是不确定的（点一下就换）⇒ 用它做全局快捷键会时灵时不灵。 · 「多个不同组件设置相同组合键 ⇒ 只响应节点树**深度最浅**的那个」。 ⇒ 再给别处的"写信"按钮补一个 Ctrl+N 不是"多一个入口"，而是**让后来那处永久失效**。 判据因此钉"全仓只许绑一处"。 绑定位置在 `MainPage` 的**根 Stack**（窗口组件树的根）—— 绑在 FAB 上不行， 它在 `if` 分支里、窄屏/宽屏位置也不同，会随分支挂卸。 键位 `Ctrl+N` 避开了官方列出的五个**禁止绑定**组合（Alt+F4/Alt+Tab/Ctrl+Shift+Esc…）。 判据直接解析调用参数校验这三点。 ## ② 根够不着 `openCompose()` ⇒ 照 `PushService` 的"两半"形状 `openCompose()` 住在**条件挂载**的 `CommPage` 上（`if (currentIndex === 0)`）， 根组件拿不到它。新建 `common/ComposeIntent.ets`： · **格子**（`pending`）—— 用户此刻在别的页、`CommPage` 还没实例化； · **回调**（`listener`）—— 用户此刻就在通信页、页面早挂载完了。 缺任何一半都是**按键静默失效**：只有格子 ⇒ `aboutToAppear` 不重跑； 只有回调 ⇒ 没有监听者。这形状与 `api/PushService.ets` 处理"点通知跳转"时 踩的是同一个坑，那边注释里已写过解法 —— 这次是照着抄，不是重新踩。 ## ③ 收件人三段式补全（↑↓ 切换、Enter/Tab 选中、Esc 收起） WebUI 的逻辑原先**散在组件闭包里**（`parseParts` 没 export、`apply`/`onKeyDown` 直接改 React state）⇒ 判据根本 import 不到。先把它抽成一对纯逻辑： `client/electron/src/lib/addressSuggest.ts` ↔ `model/AddressSuggest.ts`， **抽的时候行为一字不改**（抽出来顺手"改进"会让判据比新行为、线上跑旧行为，两边都错）。 `AddressInput.tsx` 改接这份 lib。 `cross-client-logic` 新增 `AddressSuggest` 一对，22 个用例两边逐例比。 其中 `nextActiveIndex(0,3,-1)` 是**负下标陷阱**：JS 的 `%` 对负数返回负数 （`-1 % 5 === -1`），而负下标在数组访问里**不报错**（返回 `undefined`）， 只表现为"按上键后没有任何一项高亮"。直接写 `(i-1) % n` 就会这样静默坏掉。 候选走**内联渲染**而不是 `bindPopup`/`bindMenu`：那两者各有焦点体系， 会先吃掉按键 ⇒ "↑↓ 换候选"落不到 `onToKey` 上。 ## ④ 另修一个真 bug：`AddressSuggestion` 字段名整套写错 模型声明 `value`/`kind`，而服务端（`contacts.go:206`）给的是 `alias`/`title`/`source` —— **从来没返回过** `value`/`kind`。按本仓纪律「声明了服务端从不返回的字段 ⇒ 删掉声明」改正。 顺带守住 `title` 的 `omitempty`：缺键时裸 cast 给 `undefined`（**不是**类里那个 `= ''`）， 直接读会 `Cannot read property of undefined` —— 本仓在 `MailDetail.normalize()` 上 踩过同一形状（整页白屏）。判据钉住那句 `typeof … === 'string'` 的守。 ## ⑤ 三处判据被**实测**改判（不是我挑一边，是拿数字定的） ### a. 卡片不该有模糊 —— 反转原断言 原判据断言「玻璃卡要走参数化 `backgroundEffect`」。那是**记录旧实现的副作用** （重言式）。逐字读 WebUI 的 CSS：全仓 `backdrop-filter` **只有两处** （`.glass-control` 8px/1.1、`.narrow-nav` 18px/1.5），而 `.glass-card`（`index.css:1629`） **完全没有** —— 它的玻璃感是 `rgb(255 255 255 / 0.92)` 这个 alpha。 留着旧断言更坏：下次谁把卡片改成正确的"白 + alpha"会被判红，然后去**把模糊加回来**。 ### b. 我试了"把模糊移到导航条"，被实测否掉 推断「真归属是底栏」，于是把底栏改成 `backgroundEffect({radius:18, saturation:1.5})`。 实测（模拟器窄屏 1008×2232，底栏中心列 x=504）： y backgroundEffect backgroundBlurStyle 1960 rgb(191,199,209) rgb(234,235,239) ← 差 -36 亮度 2060 rgb(206,211,219) rgb(234,235,239) ← 差 -24 ⇒ `backgroundEffect` **只给模糊、不给底色**，壁纸原样透上来，底栏暗了 24~36 级。 WebUI 的 `.narrow-nav` 是**两条声明**组合的（`background-color` + `backdrop-filter`）， 我只搬了后者。系统材质**同时含色调 + 模糊 + 深浅两套** ⇒ 在这里它才是正解 （§7.12 把它判成"有意差异"是对的，我的"改进"是退步）。 判据改成**反向钉住** `backgroundEffect`，并把这段实测数字留在 Theme.ets 里。 ### c. 页签条判据记录的是被否掉的"胶囊" 原判据钉 `TAB_BAR_RADIUS`/`TAB_BAR_SIDE`/`TAB_BAR_TOP` —— 那正是用户否掉的形状 （「你又在内部套了一个胶囊」）。CDP 读 WebUI 的实测几何： .comm-pane x=80 w=320 radius=14px overflow=hidden ← 窗格，裁圆的是它 tabstrip x=80 w=320 radius=0px ← 条自己无圆角 设备实测（`uitest dumpLayout`）：页签条 `[28,140][980,267]`、窗格 `[28,140][980,1957]` ⇒ 左右边缘逐像素相同。判据改为钉"与窗格齐平 + 只有左上角圆角"这两条**不变式**， `TAB_BAR_RADIUS`/`TAB_BAR_SIDE` 一并**删除**（留着就是孤儿，会邀请人把胶囊拼回来）。 ## ⑥ 顺带修两条判据自己的正则 `{6}` 看不见 8 位色 ⇒ 把 `glassCard`/`glassCardWall` 报成"清册过期"， **病因报错了**。改成 `{6}(?:[0-9A-Fa-f]{2})?`（不能写 `{6,8}`，那会连 7 位也放进来）。 半透明禁令改为**枚举白名单**（不是放宽：遮罩那个真实约束原样保留， `overlay` 写成 8 位单色照样红）。 新增判据 `harmony-2in1.test.mjs` 12 条；`files=34 checks=543 pass=540 fail=2`（收尾前）。	2026-09-21 13:29:24 +08:00
JianFeeeee	f83c23362a	跨端: 修卡片投影/页签条圆角/日视图/周视图 — 五处对 WebUI 的误读 ... 用户逐条指出后，用 CDP 读 WebUI 的 computed style 与祖先链，发现五处都是我读错/抄错。 ## ① 列表底部那条"不知道什么玩意的阴影"（用户原话） 根因：我把 `instance.shadow(Theme.glassShadow)` 挂在 **每张卡片** 上。 WebUI 全仓 `box-shadow` 只有三处 —— `.app-shell > *`（窗格）、 `html[data-bg='on'] .app-shell > *`、`.narrow-nav`（底部导航条）。 **卡片 `.glass-card` 一次都没有**（整个规则块只有 radius/border/bg/transition）。 一屏十几张卡各投一次 ⇒ 叠加成灰雾。设备实测（x=600，卡片底边 y≈1847）： 有投影 y=1846→231、y=1852→230（向下衰减的暗带） 去掉后 y=1846→255、y=1852→251（消失） ⇒ 投影移到 `PaneModifier`（窗格层），与 WebUI 一致。 ★ 判定实验还排除了一个嫌疑：`List` 默认 `edgeEffect(EdgeEffect.Spring)` （官方文档「支持弹簧效果和**阴影效果**」）。设 `EdgeEffect.None` 后暗带照样在 ⇒ 不是它。**弹簧是滚到边缘的正常反馈，不该为遮一个 bug 把它关掉。** ## ② 页签条右上角"那个圆角"（用户原话） 两道弧叠在一起。WebUI 实测（CDP 读祖先链）： .comm-pane x=80 w=320 radius=14px overflow=hidden ← 窗格 tabstrip x=80 w=320 radius=0px ← 页签条 **两者横向完全齐平**，页签条自己直角、靠窗格裁圆 ⇒ 只有一道弧。 我们内缩 16vp + 自己带角 ⇒ 两道弧，中间一弯月牙。 ⇒ 改成与窗格齐平、只留左上角圆角。 ★ 期间我犯过两个错，都记在注释里：先把半径设成 `HEADER_HEIGHT/2`=22（条高也是 44，那就是一个完整胶囊），后来自作主张把整条改成"通栏+下边框+无玻璃"—— 那是重做而不是用户要的小改，已还原。 ## ③ 日视图与周视图一样（用户原话） `DayTimeline()` 我写好了却**从未调用**。日视图一直走 `rows()`（周视图那套七列）。 ⇒ 按 scale 分流：日视图 → 24 小时时间轴（对齐 WebUI `DayGrid` 的 `HOURS` 逐行、 当前小时淡蓝底）；周/日格子改用 `WEEK_CELL_HEIGHT`(240) 并画日程标题条 （对齐 `EventChip`：`HH:mm` + 标题，停用的加删除线 + 灰底）。 ## ④ 邮件正文垂直居中（用户原话） 官方 FAQ `faqs-arkui-725` 原文：内容比 `Scroll` 矮时「**默认居中排布**」， 要 `.align(Alignment.Top)` 才是顶部排布。 实测内容块在 `Scroll` 里偏移 731px = (1944−481)/2 —— 正好居中。 ⇒ 4 处 Scroll/List 补 `.align(Alignment.Top)`（详情页 y 从 1018 → 287）。 ## ⑤ 窄屏圆角/留白全丢（用户：「你的邮件的圆角呢？日历的圆角呢？」） `borderRadius(this.isWide ? glassRadius : 0)` —— 窄屏恒 0； `left/right: isWide ? paneGap : 0` —— 把 WebUI「窄屏**底边**留白为 0」 错推广成「四边都为 0」。 WebUI 两条 shell 规则**都给圆角**，差的只是底边留白。 ⇒ 圆角两端都开；左右留白两端都给；只有底边分宽窄。 ## 连带修的两个真问题 · **底部导航避让**（用户：「为什么不避让底部导航栏」）：根是 `NavBar` 与内容 是 `Stack` 里的**并列兄弟**（互相重叠），所以每个滚动容器都得手写 `contentEndOffset` —— 我漏了 8 处。照 WebUI 改成 `Column{内容, NavBar}` （WebUI 实测 `scroller.bottom=861` / `nav.top=871`，内容停在导航上方）。 · **不透明的那一张卡**（用户：「有一个完全不透明的邮箱项」）：`MailRow` 手写 `Theme.surface`（系统卡片色 α=1），而 `GroupHeader` 用的是 `GlassCardModifier`。 ⇒ 改用同一件基础件 + 新增 `TintModifier` 合成状态色（`.attributeModifier` 是单一插槽，色必须参与合成）。实测 `(255,255,255)` → `(195,218,204)`。 判据随之反转 3 条（`harmony-widescreen` 两处把"窄屏 0"改成"两端都要"、 `cross-client-theme` 抓到我新写的 `Theme.border` 当 `fontColor`）。	2026-09-21 12:04:52 +08:00
JianFeeeee	139fa19f90	跨端: 转发入口移到头部动作行、右下只留回复球（我多摆了一个球） ... 承接上一条。用户之前说「还有其他行为都要一一对齐，例如邮件展示页面」， 我当时补了头部的「标记已读 / 对话树」，却把**转发**做成了右下角的第二个球。 照 WebUI 核对（`MailView.tsx:520-544` 与 `:994`）： · 头部动作行是**三个**：标记已读 → 对话树 → **转发** （`ForwardIcon` + 文字，`text-gray-500` = 导航样式） · 右下角只有**一个**球：`reply-fab`，点开才是回复框。**转发从来不是球。** 多出来那个球是我自己发明的，两个问题： ① 它没有任何对应物，纯属"看着缺就补一个"； ② 转发在 WebUI 是**导航**（灰、与对话树并列），球是**主操作** （蓝、抢注意力）—— 把导航做成主操作，页面里就有了两个同等重量的动作， 看不出主次。 改动：头部动作行补上「转发」（顺序与样式逐项对齐 WebUI），删掉右下角那个球。 设备已验：头部一行是「对话树 · 转发」（同 y），右下只剩一个蓝色回复球。 `files=33 checks=530 pass=530 fail=0`，`mutants=52 ran=52 skipped=0`，`baseline=7/7✓`。	2026-09-21 02:34:44 +08:00
JianFeeeee	6f1b4352cd	跨端: 回复/转发改内联底栏 + 入场动画对称化（照鸿蒙文档纠正三处误判） ... 用户：「点击回复按键与新建邮件部分的动画与 webui 不一致，动画不符合鸿蒙视觉 要求」。两个问题是分开的：结构是覆盖式弹层 vs WebUI 的内联底栏；动画则是我 单方面发明的不对称过渡 + 150ms 低于鸿蒙规范下限。 ## 结构：覆盖式弹层 → 底部内联条（回复 / 转发） WebUI `MailView.tsx:410/1057` 的 `ReplyBar`/`ForwardBar` 是 `border-t` 分出的 **内联底栏**，与正文并列（正文 `flex-1 overflow-y-auto` 保持可见可滚），高度由 内容决定。我们原先是整屏遮罩 + `height('60%')` + `position({x:0,y:0})`。 三条用户可感知的差异：弹层盖住正文（写回复时看不到原文）／固定 60% 高（写一行 也占半屏）／遮罩整屏变暗。结构不用动外层 —— 原版那两处本来就是正文 Stack 的 **兄弟**（同在 `Column` 里 ⇒ 本来竖直排列），错只错在给条加了遮罩/定高/绝对定位。 ## 动画 ① `paneRiseIn()` / `calendarSlide()` 去 `asymmetric`，改**对称**。 WebUI 是 `animation: rise-in 150ms … both` —— `both` 就是进出同一条关键帧。 我原先让出场只做 `opacity` 且更短（120ms），"出现时浮上来、消失时只淡出"， 正是"与 webui 不一致"的来源。当初写不对称的理由（换窗格时两层同时半透明会 "闪"）只对**换窗格**成立，对回复框/转发条不成立 —— 我把两种场景混用了。 ② `durRise` 150 → **200ms**（用户选定"折中"）。WebUI 是 150（web 常规档）， 鸿蒙官方「元素淡入/位移进入」建议 **200-300ms**，150 比下限还低 25%。 ## 照文档纠正三处误判（本轮的真正收获） 我为了搞清"为什么动画不播"，先后编出过三个错误理论，读文档后逐条推翻： ① **不是 "NavDestination 吃掉子组件的 `.transition()`"**。 实测：`ComposeView` 根上的 `.transition()` 一直在播。我之所以连测七八轮都报 "没有中间帧"，是因为**拿平均亮度当探针** —— 白底窗格 50% 透明叠在浅色背景上 平均亮度几乎不变。换成**位移**探针后，立刻看到"整栏下移 300vp 且半透明"的 中间帧。教训：**探针对被测变化不敏感时，量的是噪声**。 ② **不 `customTransition` 也能做**。`NavDestination` 确实有 `customTransition` (API 15+)，但它是**整页转场**，我们要的只是内容块的一次上浮淡入。 （顺带记一条：`NavDestinationTransition.curve` 的类型是枚举 `Curve`， 不收 `ICurve` —— 试过用 `curves.cubicBezierCurve` 会编译报错。） ③ **`.opacity()` 在 `NavDestination` 上是生效的**。先前判定"不生效"同样是那个 废探针害的；换 `opacity(0)` 二元判定后整页消失，证明它一直生效。 ## 连带修一个真 bug（判据抓的） 回复/转发改成内联后**失去了"弹层有固定高度"这层键盘保护** —— 官方默认 `KeyboardAvoidMode.OFFSET`（整页上移）会把贴底的「取消/发送/转发」顶出屏幕。 在 `EntryAbility` 里显式设 `RESIZE`（按剩余高度重排）。坑：`@kit.ArkUI` 与全局 作用域各有一个同名 `KeyboardAvoidMode`，**只有前者有 `RESIZE`**。 ## 判据（4 条红全部结算，逐条说明为什么不是放宽） · `harmony-nav` durRise：从"逐字等于 150"改为**区间 200-300**（钉住用户裁定， 退回 150 与写 800 都红，已变异验证）。 · `harmony-nav` asymmetric：**反转**为"不得 asymmetric"（旧断言把上一版设计锁住， 而 WebUI 本来就是对称的）。 · `harmony-admin` 弹层高度：原断言数的形状只属于废弃的覆盖式弹层 → 改为 **新结构下的等价不变式**（键盘避让必须 RESIZE）。这条判据当年抓的是真 bug， 该 bug 换了形态仍在，所以不能简单删。 · `cross-client-theme`：删掉我中途废弃留下的孤儿令牌 `riseCurveEnum`。 新增 4 条变异条目（全部 `红✓`）；`mutants=52 ran=52 skipped=0`。 `files=33 checks=530 pass=530 fail=0`，`baseline=7/7✓`。 设备已验：回复/转发确为内联底栏（正文可见、`border-t` 分隔）。	2026-09-21 02:19:30 +08:00
JianFeeeee	5e4a1b616c	跨端: B 的交付物（跨端纯逻辑一致性判据）+ 照 skill 回扫修掉两处隐形债 ... 用户：「你为什么不加载鸿蒙开发相关skill？」—— 说得对。那份 `arkts-grammar-standards` 写着 "REQUIRED before writing the first .ets file of a session"，而我这轮一直在写 `.ets`。补加载后照它的规则表**逐条回扫**， 当场抓出两处此前没人管的违规。 ══ ① 用户要做的 B：`cross-client-logic.test.mjs`（新，6 条判据） 背景：两套纯逻辑各写一份且已分叉（replyTarget 214/170 行、mailGroups 178/459、 appearance 187/324、calendar 208/446）。当天已**踩到**两处分叉 （`participantAddress` 的 `||`、`ThreadPage` 字段全错）。 做法：**同一张用例表喂给两边，逐条比结果**（`--experimental-strip-types` 直接在 node 里跑两侧源码 —— 两边的 model 层都是纯逻辑、无 SDK 依赖）。 不选"生成一份共享源码"：harmony 不能 import 工程外文件， 且两边类型系统不同（ArkTS 禁解构/any/对象字面量要具名类型）， 生成器要维护"两边都能过"的子集，是另一个大工程。 ★ **首轮运行就报出两处真分叉，都不是我踩到才发现**： ① `formatAddress('dsh', undefined, undefined)`：electron 返回 `"dsh"`， harmony **抛** `Cannot read properties of undefined`。 —— 又是 `omitempty` 那个坑（**第三次**），这次是判据先报的。 ② `monthGrid`：electron **固定 6 行**（`grid-rows-6`），harmony **4~6 行** ⇒ 翻月时网格高度跳动。WebUI 的注释明写要避免这个（"行数变化会让整个 网格高度跳动，翻月时页面内容上下弹"）。 ③ 顺着 ② 又发现：WebUI 邻月格子**填真实日期并置灰、可点** （`CalendarView.tsx:545-556`），harmony 留**空白格**。 ★ 判据自身的两次错，都留了档（判据的 bug 与代码的 bug 一样危险）： · 第一版把 `args[0]` 当单个参数传，字符串被当可迭代对象展开 ⇒ `formatAddress('d','s','h')` —— **判据自己造出假分叉**。 · 第一版 `weekStart` 传 0（周日），而两端实际都是 1（周一）⇒ 又一处假分叉。 差一点就去"修"一个不存在的问题。 · `monthGrid` 的投影第一版按 `inMonth ? [y,m,day] : null`， 把"邻月填不填真日期"这个**真分叉**抹平了 —— 投影只该换表示，不该替我看不看。 ★ 三类"不同"要分清（写进文件头）：**命名不同**（投影归一，不是分叉）、 **签名不同**（ArkTS 没 Date 重载习惯；语义必须一样）、**行为不同**（是分叉，以 electron 为准）。 ══ ② skill 回扫抓出的两处隐形债（编译器只告警、判据也不管） · **正则字面量**（`arkts-no-regexp-literals`）：`MailDetailPage.ets:615` 的 `/^\d+$/`（从 2026-09-19 活到今天）。 · **废弃的全局 `router`**：`api/Logout.ets:76` 的 `router.replaceUrl(...)`。 它是个独立函数（没有 `this`）⇒ 拿不到 `UIContext`，改成由调用方传 （两个调用点都持有 `getUIContext()`，零成本）。 ★ 这两条为什么能活这么久：**编译器对它们只告警、不挡构建**， 全仓也**没有判据**管 ⇒ 规则事实上不存在。已补两条判据，都做了变异验证。 ══ ③ 顺带修正一条**恒真的同义反复**断言 `harmony-calendar` 里 "today 不在本月：不许标在别的月" 那条： 它是在"邻月格子是空 `DayCell`（`iso` 为空串）"时写的 ⇒ `c.iso === today` **永远不可能**匹配 ⇒ `count === 0` 恒真，**看起来守着一条规则，其实什么都没守**。 改成真不变量：**"被标为今天的那一格，iso 必须就是 today；至多一格"**， 并反向核对"2026-10-01 确实出现在 9 月网格里"（否则那段是空转）。 实测 WebUI `CalendarView.tsx:547` 是逐格 `isSameDay` ⇒ **它会标**， 所以原来那条"不许标"本身就窄了一半。 ══ ④ 登记两处盘点发现（**没有**顺手改，因为需要人决定） · `harmony-dead-pages`：`InboxPage.ets`(238 行) 不可达（不在页面表、无人导航）， `SessionsPage.ets`(170 行) 唯一引用来自 InboxPage ⇒ 一起不可达。 没删是因为 `HARMONY-ALIGN-PLAN.md:214` 把它当变异测试靶子用过 —— 删掉会永久丢代码，是否只是"早期留存"我判断不了。 · `harmony-permission-history`：WebUI 授权栏显示**待决 + 已决策历史**两段 （拿 inbox 自己分组，`PermissionList.tsx:27/174/182`）；鸿蒙调专用端点 `/permission/pending`（SQL `WHERE pr.result IS NULL`）⇒ **只拿得到待决的**。 已在 `cross-client-logic` 的 gaps 里如实登记，判据会盯着"不要再少"。 ══ 判据状态 `files=33 ran=33 checks=530 pass=530 fail=0 skip=0 red=0 broken=0 unreported=0`； `baseline=7/7✓`（底本第 9 次重算，已按规矩先 `git diff --quiet HEAD` 取证 + 记录理由）。 `verdict=red` 残余仍是 5 条静态判据的**设备到期提示**（既有机制）。 ══ 环境 模拟器昨天起卡死（hdc 能连、shell 超时、CPU 150%、跑了 34 小时）， 导致设备判据各跑 836 秒后失败 —— 看起来像"套件卡死"。用户批准后杀掉重启 （`Emulator -start HATriple -noWindow`，`devecocli` 那套因 x11 起不来）， 现在**75~150 秒**跑完整套。	2026-09-20 22:35:35 +08:00
JianFeeeee	25e7d8f3bf	跨端: 补附件区（两端一直都有这个功能，我上次误判成"死代码"）+ 修两个真 bug ... ══ ① 更正我 2026-09-19 的一个**错误结论**（已写进 docs/DEBTS.json 留档） 那天我审计后写下：`GET /me/mail/inbox` 的回包**既没有 `attachments` 也没有 `has_attachments`** ⇒ `MailList.tsx:261` 的 `mail.attachments?.length ?? 0` 恒为 0、WebUI 那个 📎 是**死代码**。并据此在鸿蒙侧**有意不抄**这个标记。 **这个结论是错的**，错在取证方法：我**只看了一封没有附件的邮件**， 看到 key 不在，就断言服务端从不返回它。事实： · 服务端 `GetInbox`（`mail.go:586`）**明确调了 `fillAttachments`**，注释还写着 理由：「Agent 靠收件箱列表得知有哪些附件可下载，否则它不知道该调 attachment_id」 · `Mail.Attachments` 的 tag 带 **`omitempty`** ⇒ **没有附件的邮件根本不输出这个 key** 实测 `limit=200`（96 封）：带 `attachments` 的 **2 封**，正是真有附件那两封。 ★ 教训：**`omitempty` 字段的"缺失"不等于"服务端不返回"**。 判「某字段有没有」必须拿**确实有值的那条**去验，而不是拿一条恰好为空的数据。 这与同一天那个白屏崩溃（`session_workspace` 缺失 → `undefined` → 抛） 是**同一个坑的两面** —— 那天是"缺失 → 客户端崩"，今天是"缺失 → 我误判成不返回"。 ══ ② 补附件区（鸿蒙原来完全没有） · `model/Attachment.ts`（新）—— `formatSize` / `attachmentLabel`，纯逻辑无 SDK 依赖， 逐字对齐 WebUI `api/client.ts:390`（三档 + 保留一位小数）。 · `MailApi.downloadAttachment` —— 走 `getBytes`（不是 `get<T>`：后者假定 JSON， 取二进制会炸；壁纸当初踩过）。 · `IcsFile.saveBinaryFile` —— 与既有 `saveIcsText` 同一套流程，只是写 `ArrayBuffer`。 · `MailDetailPage` 正文之后渲染附件清单（回形针 + 文件名 + 大小 + 下载）， 位置/形态对齐 WebUI `Attachments.tsx`（无附件时**整块不渲染**）。 · 列表行的 📎 + 数字（`attach_count`，与 `cc_count` 同形状派生）。 ══ ③ 顺带撞出并修掉两个**真 bug** **bug A（差一点就是 94/96 必崩）**：我第一版写 `mail.attachments.length` —— 而 `Attachments` 带 `omitempty`，96 封里只有 2 封有这个 key ⇒ 其余 94 封是 `undefined` ⇒ `.length` 抛。**与当天早些时候那个白屏崩溃是同一个坑， 我刚修过、还在 `Models.ets` 里写了一大段注释，然后加新字段时照踩。** ⇒ 说明"记住别这么写"不管用，要在每个真正读的地方把 `?? []` 写出来。 **bug B（潜在白屏）**：`PermissionTab` 读 `req.session_alias` —— 而服务端 `PermissionRequest` struct **根本没有这个字段**（`models.go:239-255`）， `ListPendingPermissionsFor` 的 SELECT 也没查它，WebUI 的类型里同样没有。 它是我照"授权卡总得显示会话名"的直觉加出来的。⇒ 恒 `undefined`， 一旦有待办就抛。**一直没暴露只因为当前待办数一直是 0**（实测 `{"requests":[]}`）。 ⇒ 改成服务端确实有的 `agent_name`，并**删掉那个字段声明**： 让误用变成**编译错**，而不是运行时白屏。 同样是 `body_preview`（`omitempty`，值是 `Body` 的截断）—— 空正文 ⇒ 空串 ⇒ 服务端省略 key ⇒ `undefined.length` 抛。那批 96 封恰好都有正文， 所以"看起来没问题"——那正是这个坑的形态。已加 `?? ''`。 ══ ④ 新判据：`omitempty` 字段的读法（形状，不是实例） 从 `server/internal/models` **算出**"只以 omitempty 形式出现过"的字段名 （不在判据里手抄名单），再扫鸿蒙侧对它们的裸成员调用。 ★ 关键：**不能按字段名一刀切** —— 我第一版就是这么写的，报了 6 处、4 处误报： `session_alias` 在服务端有**两个**声明（`Mail` 上带 omitempty、`repo.Contact` 上不带）， 鸿蒙那 4 处读的全是 `Contact` ⇒ 恒有值、不是 bug。 ⇒ 只扫"从未不带 omitempty 出现过"的名字，那 4 处自动排除。 已逐个核实 4 处豁免（每条都写了取证理由，不是"看着像就放过"）。 变异验证：把 `?? []` 去掉 → 判据转红，且**正是**报 `MailStore.ets: mail.attach_count = mail.attachments.length`。 ══ ⑤ 数据路径已实测（模拟器） 临时把 `INBOX_PAGE_SIZE` 提到 200（因为有附件那两封在下标 51/52， 默认 limit=50 **根本取不到** —— 这也解释了为什么之前一直没发现）， 加临时 hilog 后拿到： AttProbe: mail=531a1629-… attach=1 AttProbe: mail=b68cbbe8-… attach=1 正好是那两封。验完已撤掉探针、`INBOX_PAGE_SIZE` 恢复 50。 ══ ⚠️ 本轮**未能**完成设备端视觉验收 模拟器已卡死（`hdc` 能连上但 `shell` 超时；进程 152% CPU、已跑 32 小时）， 导致套件里的设备判据各跑 836 秒后失败（"要能拉起应用"）。 主机可用内存只剩 ~3.7GB。附件区的**渲染**（清单外观、下载落盘） 尚未在设备上看过 —— 待模拟器恢复后补。	2026-09-20 21:14:20 +08:00
JianFeeeee	f1db99ef41	跨端: 发件箱接上 MailStore（A 的剩余）+ 修 3 处把原始 ISO 印到界面上的时间 ... ══ ① A 的剩余：发件箱走了 store（顺带撞出 store 里的一个真 bug） `SentTab.load()` 原来把收件箱那 107 行**抄了一遍**（注释里还写着"同收件箱" —— 抄的时候就知道是重复）。现在改成 3 行调用 `MailStore.loadSent`。 ★ 接上之后**立刻炸出一个真 bug**：`MailStore.loadSent` 里写的是 snap.groups = []; 而发件箱的列表**就是按会话分组渲染的**（`ForEach(this.groups, …)`） ⇒ 接上 store 之后发件箱会**一片空白**，而"接口有返回、loaded > 0" 会让症状看起来像"数据没到"。 为什么会写成空数组：它是照收件箱那半抄的，而收件箱的 `groups` 来自 `splitByPermission` **筛完之后**的 `inboxMails`（授权邮件要挑出去单独成栏）。 抄的时候只看到"要赋值"，没注意发件箱没有那一步筛选 ⇒ 把 `[]` 抄了过来。 发件箱也**不能**照搬那个筛选：那是为"授权待办栏"服务的，发件箱不显示那栏。 ★ 这段经历本身值得记：**死代码不会自己暴露错误**。 `loadSent` 写完到今天我接上它之前，那行 `groups = []` 一直没人执行过。 "写完就搁着"和"接上一个调用点"是两件事 —— 后者才算验过。 ══ ② 3 处把原始 ISO 直接印到界面上（看到屏幕才发现的） 发件箱那张卡的时间格显示的是 2026-09-19T02:55:33.10099Z （23 个字符，把「致 homeagent」那行挤到换行）。 WebUI **三种卡片全部格式化**、一个没漏：`MailList.tsx:151/262`、 `PermissionList.tsx:143/251`，全是 `toLocaleString('zh-CN', {month,day,hour,minute})` ⇒ `MM/DD HH:mm`。鸿蒙的 `compactMailTime` 就是那个实现，收件箱一直在用 —— 所以这不是"要不要格式化"的分歧，是**三处漏调**（收件箱 / 发件箱 / 授权栏）。 ══ ③ 补判据（形状而不是实例） 新判据：`Text(<x>.created_at)` 这个**形状**不许出现（`Text` 只负责画， 不做格式化）。为什么枚举形状而不是列举调用点：漏的三处分布在**三个不同 struct**， 按名字枚举一定会再漏第四个。 自检 + 变异验证都做了（把 SentRow 那处改回裸字段 → 判据转红；还原 → 绿）。 设备验证：发件箱正常渲染（会话组 + 条目，非空白）， 时间显示 `09/19 10:55` 而非 ISO。	2026-09-20 18:43:35 +08:00
JianFeeeee	99a7bbccf7	跨端: 联系人栏宽度随视图模式变（卡片 400 / 列表 320，原来写死 320） ... WebUI `ContactPanel.tsx:59-62` 原文： // 卡片要放两行摘要 + 预算条，320px 会挤；列表视图保持紧凑 view === 'card' ? 'lg:w-[400px]' : 'lg:w-[320px]' 而鸿蒙写死 `navBarWidth(320)` —— 两个视图一样宽。 卡片视图比列表视图多一行（`N 封 · 时间`）**再加一条预算胶囊**， 320 装不下；WebUI 早就为此单独放宽了，我们没跟上。 ★ 顺带一个很容易漏的点：范围也要一起抬（`navBarWidthRange([280, 400])`）。 只改 `navBarWidth(400)` 而 range 还是 `[280, 360]`，值会被**静默夹回 360** —— "改了宽度但没变"，且没有任何报错。这类"值被另一处覆盖"的坑 与 `.attributeModifier` 单一插槽（后一个挤掉前一个）是同一族。 设备验证（模拟器，密度 2.875，实测可点卡片右边界）： · 列表视图：`ListItem [265,326,1117,…]` → 右边界 1117 ⇒ **320vp** · 卡片视图：`ListItem [265,326,1347,…]` → 右边界 1347 ⇒ **400vp** 同时标题从「联系人」变「工作列表」（与 WebUI 的 `view === 'card' ? '工作列表' : '联系人'` 一致）。	2026-09-20 13:56:52 +08:00
JianFeeeee	6f7592d1c1	跨端: 按压反馈内联进基础玻璃卡 —— 18 个站点从 1 个变全部（基础组件自带动画） ... 用户问过两次： ·「各个组件带响应点击、滑动的动画了吗」 ·「基础组件包含动画」 之前按压反馈是**单独一个 modifier**，要靠调用点自己叠： CompositeModifier.of([GlassCardModifier.of(x), PressFeedbackModifier.of()]) 实测全仓 18 个玻璃卡站点里**只有 1 个**记得叠。 ★ 这不是"写的人不小心"—— **两个东西要一起用时，就该是一个东西**。 把按压并进基础卡之后，18 个站点**自动全都有**按压反馈， 且**不需要在每个调用点改一个字**。这才是"基础组件包含动画"的形状。 实现： · `GlassCardModifier` 加 `pressable`（**默认 true**），在自己的 `applyNormalAttribute` 末尾内联调用反馈 —— 不走 CompositeModifier， 那是给"调用点自己有好几个 modifier 要叠"用的，这里是基础组件内部要知道的事。 · `PressFeedbackModifier.attach(instance, color?)` 抽成静态方法， 两边共用同一段 `onTouch` 逻辑（`instance` 本来就是 `CommonAttribute`， 类型一致，不需要包一层）。 · 顺带把原先唯一"叠对了"的那处（`MainPage` 会话组头卡）简化掉 —— 它现在是全场唯一的例外写法，反而容易让人以为"要叠才生效"。 ★ 为什么默认 **true** 而不是"想按才开"：WebUI 那一侧是**全局**的 —— `index.css:1169` 对 `button, a, input, textarea, select, [role='button']` 统一给了 `transition`。"可点就有点击反馈"在两端都该是默认。 静态信息卡可以传 false —— 但不会有人漏，因为不可点的卡本来就没有按压语义， 而**漏掉真正可点的卡**才是原来那个问题（18 分之 17 漏）。 设备验证（模拟器）：在组头卡上长按，hilog 抓到 PressFB: touch type=0 ← Down PressFB: touch type=1 ← Up 成对到达。验证用的临时 hilog 已撤（不是留在代码里）。 ★ 记一个**没验成**的取证方法，免得下次再花时间： 想靠"按住时截图看底色变了"来取证，试了三轮都不行 —— `snapshot_display` 的往返延迟（~250ms + 传输）比一次按压的窗口长， 抓到的永远是松开后的画面。**延时不敏感的取证是 hilog**： 回调有没有触发是个**事件事实**，不需要抢时间窗。	2026-09-20 13:53:40 +08:00
JianFeeeee	6085159694	跨端: 5 处 Unicode 符号当图标换成 AmIcon（并把判据扩到"排版符号"这一类） ... 起因：做邮件详情时顺手把 `Text('‹')` 换成 `AmIcon('chevronLeft')`， 想着"本仓不是有这条判据吗，怎么没抓到" —— 去看了判据，发现它**只扫 emoji 那一段**。 判据（`harmony-arkts.test.mjs:168`）扫的是 U+2600–27BF / U+2B00–2BFF / U+FE0F， 而漏网的 5 处全在这三段**之外**： MainPage.ets Text('‹') 返回键（会话视图） MainPage.ets Text('›') 会话别名前的小箭头 SettingsPage.ets Text('›') 「管理」的进入下一级指示 ComposePage.ets Text(' ▾') 账号下拉指示 MailDetailPage.ets Text('‹') 返回键 ★ 它们与 emoji 那类**问题不同、但同样是"看着像图标其实不是"**： · 字形宽窄由**字体**决定，与旁边 20vp 的 `AmIcon` 对不齐； · 而且**WebUI 用的根本不是字符** —— `icons.tsx:135` 是 `ChevronRightIcon`（SVG）、`AccountSwitcher.tsx:84` 是它**转 90°**。 所以这同时是"两端不一致"，不只是"字形不好看"。 修法：5 处一律换 `AmIcon`，并按 WebUI 的**同一形状**给： · 两个返回键 → `chevronLeft` 20vp、可点区 `HEADER_BACK_HIT`（与 `AppHeader` 同值） · 会话别名 / 「管理」→ `chevronRight` · 账号下拉 → `chevronRight` + `rotate(open ? 90 : 0)`（照 `AccountSwitcher` 那句） ★ 判据扩了一类（`GLYPH_ISH`：U+2039/203A/00AB/00BB/25A0–25CF/25B2/25BC/25C0/25B6）， 并保持原有那条边界不被破坏：**U+2190–21FF 基本箭头仍不扫** —— `→`/`←` 在正文里是标点，扫进来会误伤大量正常文案（原注释里已经踩过这个坑）。 这次的符号是"单个字符整体"，所以 `Text('a → b')` 这类多字符本来也不匹配。 ★ 扩完之后判据**当场又抓到一处我自己没注意的**（`SettingsPage.ets` 的 `›`）—— 这正是"把判据从'枚举实例'扩到'枚举类'立刻多抓一个"的现场证据， 也说明原来那三条区间是照"已经出现过的实例"框的，不是照"这类东西的共同形状"框的。	2026-09-20 13:33:13 +08:00
JianFeeeee	d9bb4f766b	跨端: 三条判据转绿（登记新令牌 + 把一条断言错实现的判据改成断言真不变式） ... 上一步（写邮件右栏）之后整套跑红 3 条，逐个查清： ══ ① cross-client-theme —— 判据是对的，我漏登记 新加的 `accentEdge` / `accentEdgeDark` 是**手写色**，而这个仓有一条硬规矩： `Theme.ets` 里每个 `static readonly X: string = '#……'` 都必须在 `SELF_OWNED_COLORS` 名单里 + 在文件内的「手写色登记表」注释里写一行理由。 （这条规矩本身就是为防"新写死一个色悄悄溜过去"而立的 —— 第二处断言 会检查名单里没有化石名，所以名单不能只加不改。） 按规矩补两处： · 名单里登记，并写清它对齐的是 WebUI 的哪个 token （`MailList.tsx:280` 的 `border-blue-200`，与 `bg-blue-50` 成对） · `Theme.ets` 登记表里写一行理由 —— 重点记下**为什么"选中"必须两个 token**： 选中与未读的底色相同（都是 `accentSoft`），只靠底色的话 "选中一封未读邮件"看不出任何变化，那圈边才是信息。 并把表头计数 24 → 26 同步改掉。 ══ ② harmony-widescreen —— 判据错了，它断言的是一个 WebUI 明令禁止的实现 原断言：`assert.match(code_, /clip\(this\.isWide\)/, '面板内容要被圆角裁剪')` —— 它把"圆角"和"裁切"当成**同一件事**。而 WebUI `index.css:968` 在**同一个规则块**里就写明了这条教训： .app-shell > * { border-radius: var(--radius-card); // ★ 这里**不能**写 overflow: hidden（2026-09-14 用户： // 「通信页面完全无法上下滑动」）。 // 面板自己就是滚动容器，而这条规则的特异性比 Tailwind 的 .overflow-y-auto // 高 ⇒ 滚动被静默干掉：实测当时**一个可滚动容器都不存在**（scrollerCount=0）。 // 圆角仍然生效（border-radius 不影响滚动） 鸿蒙这边同一个形状：那层是内容列的根、`Navigation` 的 `List` 在它里面， 写了 `.clip(this.isWide)` 就是 `List` 节点还在（高 1750px）但**滚不动** （实测 fling 后第一封仍在 y=526）——这正是用户当时报的"列表没法滚动"。 ⇒ 判据改成断言**真正的不变式**：宽屏「圆角开（14）+ 面来自设计令牌 + **不写** `.clip(this.isWide)`」。原来那句测的是"某句实现写着没写着"， 而且那个实现是错的 —— 判据跟着错误实现一起钉住了 bug。 ══ ③ build-stamp —— 判据要求重构建，照做（**没有**去改 BUILD_INFO.json） 产物记的是 `c0ab3f5`，HEAD 已是新提交。这条判据自己的文本写得很清楚： > **别去改 BUILD_INFO.json 里的 gitRev / srcHash 了事** —— 那是把这条判据废掉。 > 正确修法只有一个：重跑构建。 所以 `npm run build` 重跑（rev 0）。注意 srcHash 本来就没变 （`6d1195a4008ebca7`）—— 因为 TRACKED 只扫 electron 侧（`src`/`index.html`/ `vite.config.ts`/…），我这几步改的全是 harmony；**变的只有 gitRev**。 这正说明这条判据在比对"产物来自哪个提交"，而不是"文件内容有没有动"。 ★ 三条各自的性质不同，值得分开记：① 是判据对、我漏登记（补）； ② 是判据错、钉住了一个反向实现（改判据）；③ 是判据对且给了唯一正确修法（照办）。	2026-09-20 13:05:59 +08:00
JianFeeeee	1df8245a6d	跨端: 写邮件改在宽屏右栏打开（原来盖住全屏、把列表栏也带走） ... 用户：「写邮件 webui 的宽屏样式不是在右侧打开吗」—— 是，这是**结构性不符**。 WebUI `App.tsx:179` 宽屏下写信只是把 `main` 那一格换掉： const main = composing ? <ComposePage /> : viewMode === 'account' ? ... : ... 侧栏与列表栏都还在。而鸿蒙无条件 `router.pushUrl('pages/ComposePage')` —— 一个 `@Entry` 全屏页，左侧列表整片消失。 修法照**既有先例** `MailDetailView` / `MailDetailPage`（同一个问题上次已经解过）： · `ComposePage` 拆成 `ComposeView`（真内容）+ `@Entry ComposePage`（只负责窗口避让） · 新增 `ComposeDestination`（`NavDestination` 壳），与 `MailDetailDestination` **完全同构** —— 宽屏由 `mode(Auto)` 自动并排在右栏，窄屏自动 push 覆盖全屏。 **两条路径同一套代码，不自己判断宽窄**（这正是 `Navigation` 该干的事）。 · 走本页自己的 `Navigation` 栈（`COMPOSE_ROUTE`）而不是布尔 `@State showCompose`： 路由让"返回"自动正确（系统返回键 / 手势 / 头部按钮弹同一个栈）； 布尔状态要自己接三条返回路径 —— 那正是 2026-09-17 那批「返回直接回登录页」的来源。 · `InboxTab` 里那个自己的 `openCompose` 也一起改（它抄了同一个 `pushUrl`）—— 收件箱内按筛选账号写信、收件箱外用活跃账号写信，两条入口现在共用 `CommPage.openComposeWith(accountId)`。 ★ 两个必须守住的细节（都是上一次踩过的坑，这里重复了一遍）： · 避让留给 **`@Entry` 包装层**，`ComposeView` 里 `embedded` 时取 0 —— 同一个 View 被内嵌复用，而 `MainPage` 已经加过避让，加在里面就是**让两次**。 · 「取消」内嵌时必须弹**自己的**栈（`onBack`），不能 `router.back()` —— 那会退掉整个 `MainPage`（写信只是它的一个右栏状态，不是一个页面）。 `MailDetailView.goBack()` 里是同一条判断。 · 内嵌时参数走 `@Prop` 初值，**不读** `getRouter().getParams()` —— 内嵌没走 router，那里拿到的是**上一次 push 的残留**， 会把上一封信的收件人带进来（比空更坏）。 设备验证（模拟器 3184×2232 宽屏）：点悬浮加号 → 写信在**右栏**打开， 侧栏与列表栏都在；点「取消」→ 弹回右栏空态，列表与选中态不受影响。	2026-09-20 12:57:55 +08:00
JianFeeeee	5c04b41900	跨端: 修一个真崩溃（omitempty）+ 邮件详情补"标记已读/对话树"两个动作 ... 用户：「还有其他行为都要一一对齐，例如邮件展示页面」。做这件事时**撞出一个真崩溃**。 ══ ① 崩溃：`Cannot read property trim of undefined`（整页白屏、应用重启） 崩在展开邮件头部的那一刻。崩溃日志 `jscrash-com.jianf.agentmail-...-20260920123121173.log`： at participantAddress (model/ReplyTarget.ts:87:40) at fromAddress (pages/MailDetailPage.ets:393:12) 根因是**服务端 `omitempty` + 客户端裸转型**这个组合： · 服务端 `Mail` 有 12 个字段带 `json:"...,omitempty"`（models.go:140-238）—— Go 对零值**根本不输出这个 key**。实测 `/api/v1/mail/{id}`： session_workspace ★缺失 body_preview ★缺失 permission_result ★缺失 attachments ★缺失 · `ApiClient` 是 `JSON.parse(rawText) as T`（裸转型、无归一化）—— ArkTS 对"JSON 里没这个 key"**不会**套用 class 的 `= ''` 默认值 （那只在**整个对象**缺失时生效）⇒ 字段变成 `undefined`。 · 于是 `workspace.trim()` 当场抛。 ★ 这正是用户要做的 **B**（两套纯逻辑各写一份）的实证分叉： electron 写的是 `(workspace || '').trim()`，鸿蒙写的是 `workspace.trim()`。 少了那两个 `||`，代价是一个崩溃。已在 `ReplyTarget.ts` 照 electron 逐字对齐。 ★ 但**不在那里了事**（同一个坑还有十几个字段，逐个打补丁必然漏）： 在**解析边界**加一层归一化 `MailDetail.normalize()`，接在 `mailApi.mailDetail()` 上。 下游从此可以按"字段一定存在"来写（那本来就是类型声明该保证的事）。 不改服务端去掉 omitempty —— 那会动已发布的 API 契约，代价大得多； 而且 electron 一直靠 `?.`/`|| ''` 兜，说明这个契约是既成事实。 ★ 为什么以前没暴露：`fromAddress()` 只在**展开头部**时才调用， 而展开头部是个 14px 的薄弱点击区（之前修过一次）。我把动作行加进展开区， 等于把这条路走宽了 —— 一展开就崩。 ══ ② 又一处 B 分叉：对话树回包类型整个是错的（接口 200，界面空白） 鸿蒙 `ThreadResponse` 声明的是 `dir / has_more_up / has_more_down / next_up / next_down` —— **服务端一个都没有**；服务端真正返回的 `root_mail_id / anchor_depth / has_more / next_offset` 这里**一个都没声明**。 更糟的是 `ThreadApiResponse` 还包了一层 `thread`，而服务端是**平铺**的： {"anchor_depth":1,"anchor_mail_id":"...","has_more":false,"hidden":0, "next_offset":60,"nodes":[...],"root_mail_id":"...","total":2} ⇒ `resp.thread.nodes` 永远读不到 ⇒ 点「对话树」什么都不显示。 已按 electron 的 `types/index.ts:179 ThreadPage` 与服务端实测回包对齐。 ★ 教训记下来：`JSON.parse as T` 是裸转型，**照自己直觉声明第三方回包类型， 编译器不会查**。改成 electron 那样的 `ThreadPage` 形状后才对。 ══ ③ 补两个动作（对齐 WebUI `MailView.tsx:520-544`） · **标记已读** —— 仅 `status === 'unread'` 时出现；成功后**就地**把 `this.status` 改成 `'read'`（只发请求不改状态的话按钮还挂着，用户会以为没生效再点一次）； 失败要 toast（写操作静默失败比报错更坏）。不做乐观更新 —— "标已读失败了却显示已读"比慢 0.2 秒更糟。 · **对话树** —— 盖在内容之上的弹层（不改路由），与 WebUI 的 `onThread` 同义。 · 转发不重复（右下球已有）。 · 位置、顺序、显隐条件逐项对齐：动作行在**元信息行之前**（WebUI 是 `mb-1.5` 那一行），蓝色表示动作、灰色表示导航，与 WebUI 的 `text-blue-600` / `text-gray-500` 同一取舍。 设备验证：展开头部不再崩（无新 faultlog）；`POST /mail/{id}/read` 已发出且 「未读」徽标与按钮同时消失；对话树弹出并显示真实数据（2 封，dsh → jianf）。 ★ 工具坑记一笔：这台模拟器上 `devecocli ui tap` **点了不生效**， `hdc shell "uitest uiInput click X Y"` 才有效 —— 为此白跑过两轮。	2026-09-20 12:48:37 +08:00
JianFeeeee	44e277e0b6	跨端: 补「当前选中邮件」高亮 —— 鸿蒙原来完全没有这个概念 ... 用户：「你自己看看跟 webui 相比，观感真的差很多」。逐项比对后找到的**行为缺口** （不是配色问题，是少了一个状态）。 WebUI 一直有：`MailList.tsx:104/116/229` 把 `currentMail?.mail_id` 传进卡片， 卡片据此上 `active ? 'bg-blue-50 border-blue-200'`。 鸿蒙**一个都没有** —— 点开一封邮件后，左侧列表那一行和旁边几行长得一模一样： 你不知道自己正在读哪一封、读完了该往哪回。 修法： · `CommPage` 拥有 `@State currentMailId`，`openMail()` 里记下，以 `@Prop` 下发给 `InboxTab`/`SentTab`。**单点写、多点读** —— 两个 tab 各存一份必然会分叉 （收件箱和发件箱都能触发同一个动作）。 · 存 `mail_id` 而非索引/组键：SSE 会让列表重排，索引会错位。 · 三级优先 **选中 > 未读 > 普通**。★ 这里有个必须成对的理由： 选中与未读底色**相同**（都是 `accentSoft`），只靠底色的话 "选中一封未读邮件"看不出任何变化 ⇒ 选中必须额外加那圈边。 这正是 WebUI 两个 token 并存的原因，不是随手加的边框。 · 新增 `Theme.accentEdge/accentEdgeDark/accentEdgeFor()`（= tailwind blue-200 及其深色值）——我第一版只搬了底、忘了边，选中态淡到几乎看不见。 ★ 顺带记一个工具坑：`devecocli ui tap` 在这台模拟器上**点了不生效** （截图前后一样、布局树无变化），而 `hdc shell "uitest uiInput click X Y"` 有效。以后点不动就先换这条，别以为是代码没生效 —— 我为此白跑了两轮。	2026-09-20 12:24:17 +08:00
JianFeeeee	d10c641e41	跨端: 账号徽标对齐 WebUI（中性灰胶囊 + 80px 截断，原来是被染成品牌蓝） ... 用户：「你自己看看跟 webui 相比，观感真的差很多」。逐字段对比卡片后找到这一处。 WebUI（`MailList.tsx:303-310`）： className="text-[10px] leading-4 px-1.5 rounded-full bg-gray-100 text-gray-600 shrink-0 max-w-[80px] truncate" 我们原来： .fontColor(Theme.accentFor()) .backgroundColor(Theme.accentSoftFor(this.isDarkNow)).borderRadius(4) （没有 maxWidth） **三处都不一样**： · 底色/字色：品牌浅蓝 + 品牌蓝 vs **中性灰**。徽标表达的是"这条来自哪个账号"， 是**中性的元信息**，不该与主操作抢注意力 —— WebUI 选 gray-100 正是这个意思。 我们把品牌色用在元信息上，等于把每一行的副标题都标成了"主操作"。 · 形状：圆角方(4) vs 全圆胶囊(rounded-full) · 截断：原来没有 `maxWidth` —— 账号名一长就把主题挤没了（WebUI 有 `max-w-[80px]`， 而多账号正是这个徽标存在的场景，名字长是常态）。 措辞上保持"用户看到什么"这个层次：这条判的是**渲染结果**， 不是"有没有这个字段"（两端字段集本来就是一致的）。	2026-09-20 12:12:08 +08:00
JianFeeeee	a97b83e221	跨端: 宽屏右栏空态（splitPlaceholder）—— WebUI 有引导，我们原来一片空白 ... 用户：「你自己看看跟 webui 相比，观感真的差很多」。同 1107vp 视口并排后， 差异确实明显，其中**最扎眼**的一条：宽屏两栏并排时，右栏是**一大片空白**。 WebUI 有引导（`MailView.tsx:121-129`）： 信封图标 + 「选择一封邮件查看，或点击左侧「新建」写邮件」 我们什么都没渲染。 ★ 第一版放错位置（记下来，这个坑很隐蔽） 我把它写进 `NavDestination` 的 `else` 分支 —— 而 **`NavDestination` 只在 push 之后才挂载**，栈空时它根本不存在 ⇒ 那个 else **一次都不会显示** （实测：加上去之后右栏仍然全空）。 正确入口是 `splitPlaceholder(ComponentContent)`：系统给"右栏默认页"的专用 API （`navigation.d.ts`，API 20+，我们是 23），由 `Navigation` 在栈空时自己渲染。 ★ 三个 ArkTS 约束（都撞了才过） ① `splitPlaceholder` 要的 `wrapBuilder` 只接受**全局** `@Builder` 函数 —— 写成 struct 成员方法会报 "The wrapBuilder's parameter should be '@Builder' function"。 内容本身是静态的（不需要 `this`），所以全局正好。 ② `wrapBuilder` 是**全局声明**（`common.d.ts:27448`），**不在** `@kit.ArkUI` 里 —— 从 kit 引会报 "has no exported member"。 ③ `ComponentContent` 要从 `@kit.ArkUI` 引。 文案**逐字对齐 WebUI**（同一句话，不自己改写）—— 与本仓既有纪律一致 （`harmony-logic` 里「空态主句与 WebUI 逐字一致」那条是同源要求）。 设备验证：`选择一封邮件查看，或点击左侧「新建」写邮件` 已在右栏渲染（布局树可见）。	2026-09-20 12:07:32 +08:00
JianFeeeee	e988b6f24d	跨端: 去掉宽屏内容列与两栏的 .clip（圆角保留、不裁切）+ 更正两处我自己的误判 ... ★ 改了什么 `MainPage.ets` 三处 `.clip(...)` 去掉，**圆角保留**： · 宽屏内容列的 `.clip(this.isWide)` —— 这处**本来就在**（不是今天加的）， 它是内容列的根，`Navigation` 的 `List` 在它里面 · 今天新加的两处（左栏 navBar 根、右栏 NavDestination） ★ 依据是 WebUI 自己写在**同一个规则块**里的教训（`index.css:968`）： .app-shell > * { border-radius: var(--radius-card); // ★ 这里**不能**写 overflow: hidden（2026-09-14 用户： // 「通信页面完全无法上下滑动」）。 // 面板自己就是滚动容器，而这条规则的特异性比 Tailwind 的 // .overflow-y-auto 高 ⇒ 滚动被静默干掉：实测当时**一个可滚动 // 容器都不存在**（scrollerCount=0），内容是直接被裁掉的。 // 圆角仍然生效（border-radius 不影响滚动）；角落的方角残影 // 改用 background-clip 处理……比不能滚动好得多。 我照"两栏各自圆角"改的时候，把 `overflow: hidden` 一起搬了过来 —— 而那条警告**就在同一个块里**，正是为了防这一手。 ★ 更正我自己两处**错误结论**（都写进注释，免得下次重犯） ① 「你一改了之后列表没法滚动了」——**不成立**。实测该账户只有 6 组 （内容 1434px），而列表容器 1750px，**内容比容器矮，本来就不需要滚动**。 用会溢出的页面验证（「我的」页）：fling 之后页面从「背景」滚到「管理」， **滚动是好的**。我把"内容没溢出"误读成了"滚动坏了"。 ② 「列表栏宽一倍」——不成立。两端**绝对宽度相同**（列表 320vp、侧栏 60vp）， 百分比差异只是视口宽度不同（1280 vs 1107vp）。我漏了密度换算（2.875）。 ★ 同视口并排的结论（1107vp × 2 端，逐项量过） 侧栏 60vp、列表栏 320vp、卡片 300×78vp —— **几何两端一致**。 真正的差异在**内容**，不在尺寸（下一步按这条去做）。	2026-09-20 11:58:16 +08:00
JianFeeeee	97037c0424	跨端: A 步 —— harmony 补 store 层（MailStore），搬走 InboxTab 107 行重复实现 ... 用户裁定：「A+B 都做」「electron 是唯一真实源泉」。本条做 A 的第一步。 ★ 量的结果（决定为什么要做） · harmony 48 文件 / 18,444 行，**无 store 层**，223 个 @State + 47 @Prop 散在各页 · electron 58 文件 / 13,801 行，**9 个 store**（mailStore/sessionStore/contactStore/ accountStore/appearanceSync/uiStore/themeStore/authStore/backgroundStore） · `MainPage.ets` 3,289 行，其中 4 个 load* 方法合计 250 行在重复 "遍历账号 → 逐账号拉 → 合并 → 派生 cc_count → 分流 → 分组 → 算未读 → 出提示" · 同一套多账号遍历在 `InboxTab`(107 行) / `SentTab`(40 行) / `ContactsTab` 各写一遍 ★ 做了什么 新增 `common/MailStore.ets`（318 行，照 `AppearanceStore` 的单例形状）： · `loadInbox(ctx, accountFilter)` —— 全仓**唯一**的收件箱取数实现 · `loadSent(ctx, accountFilter)` —— 与收件箱共用同一套聚合形状 · `dropSession(sessionId)` —— 归档后就地剔除（与 WebUI `mailStore.dropSession` 同动作） · `clear()` —— 退出/换账号时清空（否则下一账号会看到上一人的邮件，哪怕只有一帧） · `MailSnapshot` / `AccountError` / `INBOX_PAGE_SIZE`（从页面搬进来） 它只做"取数 + 组装 + 错误归类"——**纯逻辑仍留在 `model/MailGrouping.ts`**， 这样 `harmony-logic.test.mjs` 不必起设备/网络就能跑（本仓既有纪律）。 `MainPage.InboxTab` 的 `loadData()` 从 107 行变成 3 行调用 + 两个辅助 （`syncAccountFilter` / `applyStoreSnapshot`）。 ★ 途中撞到的四个 ArkTS 约束（都已修，记下来免得重犯） ① `INBOX_PAGE_SIZE` 在页面里已有一份 ⇒ 导入与本地声明冲突（`arkts-unique-names`） ② `MailApi.sent()` **不收参数**（与 `inbox(status, limit)` 不同），照着 WebUI 写会错 ③ `SentResponse` 定义在 `model/Models.ets`，**不在** `api/MailApi.ets` 里再导出 ④ store 持有接口类型 `MailLike[]`，页面字段是 `MailSummary[]` ⇒ `MailSummary implements MailLike` 成立，但**赋值要显式向下转型** ★ 为什么页面还保留 `@State` 镜像而不直接读 store 字段 ArkUI 的 `@State` 只观察**它持有的那个值**；store 是普通类实例，改内部字段 不触发刷新（本仓 `appearance-defaults` 判据钉过同类问题）。所以照既有约定： store 每次改完自增 `revision`，调用方把快照接进 `@State`。 设备验证：收件箱正常渲染（6 组 · 50 封、25 未读），与改动前逐项一致。	2026-09-20 11:28:48 +08:00
JianFeeeee	ed1ae02441	跨端: 宽屏两栏各自圆角（原来只有外壳有，内部两半是直角） ... 用户：「同时邮件展示左侧没有圆角」。 WebUI 宽屏的真结构是**三个独立圆角面板并排**（App.tsx:262）： <div className="app-shell"> ← padding/gap = 10px <Sidebar/> {list} {main} ← 每个子元素各自 border-radius:14px </div> （index.css:968 的 .app-shell > * 统一给 border-radius，第 1070 行在壁纸态再加 overflow:hidden + 阴影）。所以列表栏与详情栏**各有自己的四个圆角**， 中间的缝里透出壁纸。 我们这边是一个 Navigation，由系统 Split 成 navBar + content 两半， 圆角只加在**外壳**上 ⇒ 内部这两半是直角。实测（模拟器 3184×2232）： 详情栏白区左缘在 y=145 与 y=2195 都是 x=1152 —— **完全垂直，没有圆角**。 修法：给两栏**各自**补圆角 + 裁切（与 WebUI 的 .app-shell > * 逐条对应）， 左栏在 navBar 内容根、右栏在 NavDestination 上。 修后实测白区左缘：y=145→x=1178、y=165→1156、y=185→1152（圆弧正确）， 下角同理（y=2190→1165、y=2196→1172）。 ★ 顺带给 MailDetailDestination 补 bgActive 参数（圆角要在壁纸开启时才有 —— 与 WebUI 一致：非壁纸态 .app-shell > * 也圆角，但那时底色是实心的， 圆角看不出来；壁纸态才需要圆角把缝让出来）。	2026-09-20 11:14:05 +08:00
JianFeeeee	6ca0113fd2	跨端: 统一顶栏组件 + 按压反馈（真跑通）+ 滑动判定从"时长门"改"速度门" ... 用户四条意见，逐条都是真问题，且**两条是我写完没生效**： ① 「所有的顶栏都应该应用玻璃圆框效果」② 「抽象一个统一的顶栏组件出来吧」 ③ 「你不觉得发件箱太大了吗」④ 「各个组件带响应点击、滑动等的动画了吗」 ⑤ 「还有转场动画呢？」⑥ 「还有其他行为都要一一对齐，例如邮件展示页面」 ★ ① ② 统一顶栏 `AppHeader` 改造前**六处各写各的**：`AdminUsersPage`(40×40 返回键+16 号标题)、 `SettingsPage`(20 号标题+40×40「＋」+**实心 Theme.surface**)、 `MailDetailPage`(36×36 + 14 号标题，行高只有 14px 被裁过)、 `MainPage.SentTab`/`PermissionTab`(通栏、无圆角)、`CommTabBar`。 尺寸(36/40、14/16/20)、底色(实心白/透明/无)、返回键(有/无)三类都不一致； 且四处用 `Text('‹')` 当返回键 —— **用字符当图标**（本仓明令禁止，字形随字体变、 基线对不齐），而 `ICON_PATHS` 里**早就有** `chevronLeft`。 ⇒ 抽成 `AppHeader`（返回键 + 标题 + `@BuilderParam` 右侧动作区）， 几何复用底部条常量，材质走 `Theme.navMaterial`。已接入 5 处。 ★ `topInsetPx` 由调用方传：状态栏避让是**窗口级**事实（属页面）， 组件自己读会变成"每层各加一次"（平板侧栏 83+83 双计就是这么来的）。 ★ ③ 发件箱"太大"—— 我的理由错了 我第一版让 `HEADER_HEIGHT = NAV_BAR_HEIGHT`(56)，理由是"顶栏与底栏同在一根 竖轴上，高度不同会一眼看出来"。**那个理由不成立**： 底栏是**两行**（图标+文字标签）⇒ 需要 56；顶栏只有**一行标题** ⇒ 56 里一半是空白。 实测 `Row [277,315,1105,476]` = 161px = 56vp，标题那行只占 54px。 "两根轴上的条要一样高"是把**对齐**理解成了**等高**。真正要对齐的是**左右留白与圆角**。 ⇒ `HEADER_HEIGHT = 44`（= 可点区下限，返回键装得下）。 ★ ④ 按压反馈 —— 两次失败才跑通，两个坑都记进注释 · **坑一**：`.attributeModifier()` **一个组件只能挂一个**，链两个是**后者覆盖前者**。 会话组头卡同时挂了玻璃与按压反馈 ⇒ 只生效一个，**编译器不报错、运行不提示**。 WebUI 是 CSS，类名天然叠加；ArkUI 是单一插槽，"叠加"必须显式做 ⇒ 新增 `CompositeModifier`。 · **坑二**：`applyPressedAttribute` **只对自带按压状态机的组件**（`Button`）回调。 实测：挂 `Button` 上 → hilog 有输出；挂只有 `.onClick` 的 `Row`/`Column` 上 → **一次都不回调**（按下与常态逐像素相同 `239,244,255`）。而全仓 117 处 `onClick` 的主体正是纯 `Row`/`Column` ⇒ 那条路对本仓没用。 改用 `onTouch` + `animateTo`。 · 底色用**系统点击效果色** `ohos_id_color_click_effect`（不是我自己挑的）： 第一版用 `Theme.surfaceMuted`，实测只差 `3/3/3`，肉眼看不出 —— 因为"一块面的颜色"与"按下时叠的提示色"在系统色板里是**两个不同语义**。 设备验证：`onTouch type=0`(Down) → `type=1`(Up) 成对到达，像素确有位移。 ★ ④ 滑动判定：从「时长门」改成「速度门」（**设计错误，不是调参**） 旧门 `SWIPE_MAX_DURATION_MS = 700`（"整个手势超 700ms 就拒"）。 而**时长 = 距离 ÷ 速度** —— 它把两个量混成一个 ⇒ 同样的手速下 **滑得越远越容易被拒**，屏幕越大越严重（平板同一手势像素更多）。 设备实测（3184×2232，位移恒 542.6vp）： 600px/s→5909ms | 1200→3161ms | 1800→2006ms | 2500→1429ms | 5000→616ms | 15000→123ms ⇒ 旧门意味着**只有 ≥5000px/s 才过**，而那一档重复测试也只有 2/4 成功 —— 用户报的"滑不动/时灵时不灵"就是这个。 改 `SWIPE_MIN_SPEED = 0.25`（vp/ms，取自上表两档中间）后实测： 1200px/s → 0/3（正确拒绝：那是拖动） 2500px/s → **0/4 → 3/3** 5000px/s → **2/4 → 3/3** 两条判据跟着改形态（**语义不变**：都是"够快才翻页"）： · `cross-client-gesture` 断言"算的是 dx/ms"——只断言"有个门"会漏掉这次的错 （旧的时长门**存在**、常量**有名字**、数值**是正数**，三条全过，而真机拒掉正常滑动）； · `harmony-logic` 的行为判据加了两条**回归钉**： `542.6vp/1429ms`（实测的正常甩动）必须过； `1200vp/3000ms`（同速度、更远）也必须过 —— 旧门正是在这里误拒。 ★ ⑤ 转场动画：查清了，"不做页面级"是**决定**而不是漏做 WebUI `index.css:1230` 写明：页面级淡入会让**已在那儿的框架**也一起暗一下 （"观感还是闪"），且用户 2026-09-14 **亲口否掉过**"整屏一起淡"， 所以那一档整体删掉，只保留**局部**动效。鸿蒙侧当前是： · `pushUrl` 推页 → **系统自带的滑动转场**（连拍 8 帧验证：第 3 帧能看到 写信页正在覆盖发件箱，是真实的横向滑入，不是硬切）； · 局部入场 → `paneRiseIn` / `menuIn` / `calendarSlide`（已接 12 处）。 所以"加 pageTransition"反而会与用户当时的否决冲突 —— 这一条**不做**， 理由记在这里，免得下次又当成遗漏。 判据：files=32 ran=32 checks=519 pass=519 fail=0 red=0；baseline 7/7✓。	2026-09-20 10:51:28 +08:00
JianFeeeee	c0ab3f57b2	跨端: 顶部页签条改悬浮玻璃 + 深色压暗下限（修 8 处深色可读性）+ 手势判据自搭现场 ... 用户：「顶部的收件箱发件箱和授权为什么不做成悬浮玻璃？」 问得对，而且它当时是**整页唯一一块实心白**。 ★ 顶部页签条 → 悬浮玻璃 `CommTabBar` 原来写的是 `backgroundColor(Theme.surface)`（系统卡片色＝实体）。 上一轮把列表容器、卡片、底部导航条都玻璃化了，**唯独漏了这条** —— 它既不是卡片也不是容器，是"条状 chrome"，逐处修时最容易漏的那一类。 ⇒ 现在与底部浮动条**同一族**：圆角 + 左右留白 + `Theme.navMaterial`。 ★ 几何常量复用底部条的（`TAB_BAR_RADIUS = NAV_BAR_RADIUS`、 `TAB_BAR_SIDE = NAV_BAR_SIDE`），不各写一份 —— 两个数一旦分叉， "同一条轴线上的两种条"就不齐了。为什么选悬浮而不是 WebUI 的"通栏无底色" （WebUI 页签条自己**没有**底色，靠父面板的玻璃）也记在那个常量的注释里。 新增判据：页签条必须与导航条同族（不许实体面 / 要引 TAB_BAR_* 常量）， 变异验证过（改回 `Theme.surface` 即红）。 ★ 深色压暗下限 —— 本轮最重要的真 bug 玻璃让壁纸**真的透进卡片**之后，"浅壁纸 + 深色文字令牌"这个组合会在 **卡片内部**发生。设备实测（深色、aurora、压暗 37）： 「角色」ink rgb(183,195,211) on bg rgb(68,95,128) = 2.57:1 「创建时间」2.27:1、「状态」2.68:1、「压暗」2.19:1（共 8 段 <3:1） 而**同一套代码在浅色下全部达标** ⇒ 差别不在"选错了色"，在"底没暗下来"。 WebUI 早就撞过并写下了必然值（`index.css:442`）： .dark { --bg-dim-min: 92%; } /* 浅色下是 0% */ background-color: rgb(var(--bg-scrim) / max(var(--bg-dim), var(--bg-dim-min))); 我们只有 `scrimOpacity(bgDim)`、**没有下限**。补上 `DARK_DIM_MIN = 0.92` （浅色下用户设的值照旧生效，不忽略设置）。 复扫：低对比 8 段 → 通信 0 / 日历 0 / 联系 1 / 我的 1 （剩下两条经手核是扫描器的假阳性：近黑底上把抗锯齿暗像素当成了"墨"）。 ★ 手势判据"没有自己搭现场"（套件红、单独绿） `cross-client-gesture` 只保证"在月档"、**不保证在哪一月**，而它算的是 相对最初那一月的 delta ⇒ 前面某个判据（或一次失败的手势）把日历翻到 10 月后， 期望值就差一格。修法：先点「今天」归位到本月（该按钮语义就是"回本月"）。 验证：从 9 月起步、从 10 月起步，两种脏状态都通过。 ★ 顺带确认手势本体是好的：`--speed 1500` 时 1000px 要走 670ms， 紧贴 `SWIPE_MAX_DURATION_MS=700` 而被丢弃；`--speed 3000` 两个方向都翻。 ★ 判据基建：修掉一个**静默失效**的 API 名（沿用上轮的教训修法） `Surface.ets` 里两处块注释内嵌了 `/* ... */` —— 会把块注释**提前闭合**， 于是后面的代码跑到注释外面（报"Use let instead of var"/"Invalid character"）。 本仓已有这条纪律（"当 `code()` 因注释里的 `/*` 吞掉 import 时，改注释文本"）， 这次又踩了两处（`Surface.ets` 与 `Appearance.ts`）。 判据：files=32 ran=32 checks=519 pass=519 fail=0 red=0；baseline 7/7✓。	2026-09-20 09:01:46 +08:00
JianFeeeee	eb4e413c67	跨端: 玻璃走基础组件（透明度/磨砂/投影）+ 判据去芜存菁（修 4 个判据自身缺陷） ... 用户两条：「玻璃不透明/不够磨砂炫酷，要更基础组件化」＋「判据去掉无意义的、保留有用的」。 ★ 玻璃的透明度与质感（逐层调出来的，不是拍的） · 透明度：`BlurStyle` 是固定档、没有 saturate 旋钮 ⇒ 观感偏灰。 改用参数化 `backgroundEffect({ radius, saturation })`，字段与 CSS `backdrop-filter` 一一对应，于是可以**照抄 WebUI 的数**：`blur(18px) saturate(1.5)` （WebUI `.narrow-nav`，那里最"玻璃"的一档）。**saturate 才是玻璃感的主要来源**。 · 质感：只模糊+饱和仍然"像一块平的白方块" —— 玻璃板之所以像板靠的是**边缘**。 WebUI 的完整配方是 `box-shadow: 0 8px 28px rgb(0 0 0 / 0.16)` + 发丝描边。 只有模糊没有投影 ⇒ 一片雾；加上投影 ⇒ 一块板。**这是"不够炫酷"的主因** （我先前两个方向都调了模糊与饱和，方向就偏了）。 · 投影用**系统预置档** `ShadowStyle.OUTER_FLOATING_SM`（"浮起的小面板"）， 不是手写 `{radius, color, offsetY}` —— 手写色要么是 `#AARRGGBB`、 要么是 `rgba()`，两者都被判据明令禁止，而那条禁令**是对的**： 手写阴影色在深色下看不见（深底叠深影 = 无变化），WebUI 在 `.dark` 里 要把同一处从 0.16 加重到 0.55 —— 那正是"替系统猜深浅"。 ★ 基础组件（用户：「定义一个基础玻璃容器给各个组件引用」） · `GlassCardModifier` / `PaneModifier`（`AttributeModifier<CommonAttribute>`）： **一处定义、处处引用**。页面里的玻璃从 15 处内联三连收敛成 `.attributeModifier(...of(this.bgActive))`。 ★ 为什么不是 `@Styles`：全局 `@Styles` 读不到 `this`（而玻璃要知道 `bgActive`）； 成员级 `@Styles` 能读 `this` 但**每个 struct 各一份**，MainPage 有 7 个 struct ⇒ 只是把"每处抄 3 行"换成"每 struct 抄 1 份"，没解决问题。 · `Motion.dur()`：接系统「减弱动态效果」（`isAnimationReduceEnabledSync()`，API 23）。 WebUI 有 `prefers-reduced-motion` 硬约束，鸿蒙这边**改造前一次都没调过**。 ★ 途中撞出并修掉的**真 bug**（都是我自己的） · 把 `@Styles glassCard()` 里也替换成 `attributeModifier` ⇒ 「我的」页 ProfileSection/AppearanceSection/PushSection **整块不渲染** （设备实测：Scroll 直接跳到「客户端连接密钥」）。删掉那个死 `@Styles` 即恢复。 · `Theme.shadowColor/hairline` 用了 `rgba()` + `#AARRGGBB` ⇒ 违反本仓两条既有禁令 （"鸿蒙侧不写 CSS 颜色函数"、"半透明属于系统材质/职责"）。改用系统阴影档。 ★ 判据去芜存菁：修了 4 个**判据自身的缺陷**（都是它声称在管、实际漏判/误判） · 材质来源只扫 `backgroundBlurStyle` —— 玻璃改成 `backgroundEffect` 后**整类漏判**。 实测：往 Modifier 里塞 `backgroundEffect({radius:99,saturation:9.9})` 照样全绿。 ⇒ 补上这一类，并加"参数必须引 Theme 令牌"（否则只是换个旋钮写死）。 · 参数抽取用 `[^)]*` —— 对 `this.materialOf()` 与 `{...}` 对象字面量都提前截断， **误伤合法写法**（本次被它误红两次）。改成配对括号 + 去外层花括号。 · 嵌套判定**没比文件**：拿 A 文件的字符偏移去比 B 文件 ⇒ 判出 "MainPage 内含 SettingsPage 的玻璃"这种物理上不可能的红。 假红比漏报更坏 —— 会让人去改本来对的代码（本次差一点）。 · `harmony-appearance` 数的是**内联字面量**（"三元出现 ≥5 次"）， 收敛成组件后写法变了、行为没变却变红 ⇒ 改成判不变式 （让位只有一条路径 + 每个窗格都收到开关）。 · 顺带：设备判据找「背景」时只在首屏可见节点里找（而 dumpLayout 只给可见节点）， 且我的第一版只朝一个方向滑（越滑越远）⇒ 改成"先回顶、再逐屏向下扫"。 判据：files=32 ran=32 checks=518 pass=518 fail=0 red=0；baseline 7/7✓（第 7 次，逐个取证）。	2026-09-20 08:16:10 +08:00
JianFeeeee	5103e0aee3	跨端: 抽出基础面/玻璃组件（Motion + Surface）+ 三处硬弹的弹层补过渡 ... 用户两条要求，各自都指向"决策被复制到各处"这个病根： ① 「应该定义一个基础玻璃容器给各个组件引用」 ② 「很多页面还是不够精致……封装为基础组件供所有页面使用。基础组件包含动画」 ★ 玻璃不透明的真根因（前几轮都没找到，这次是像素证据定的） 实测模拟器 3184×2232、壁纸 aurora + 压暗 37： Navigation [229,140,3156,2204] ← 255,255,255（整块内容区） y=2210（Navigation 之外那条缝） ← 226,225,235（壁纸清楚可见） 那条缝是决定性的：**壁纸层本身是好的**，白是因为上面盖了不透明的壳。 链路上一共三层，逐层修： · `Navigation` 外壳：不设背景 ⇒ 系统默认不透明白，把里面已透明的窗格整片盖住； · navBar 内容层（列表栏根容器）：同样没有背景； · **卡片**：铺的是 `Theme.surface`（实体系统色）。 修后：缝隙 203,213,228 / 卡片 191,204,220 —— 壁纸透得出来。 ★ 新增基础组件（common/） · `Surface.ets` —— `GlassPane`（正文面）/ `GlassCard`（嵌套面）/ `PageHeader` / `Pressable` · `Motion.ets` —— `Motion.dur()`：接系统「减弱动态效果」 （`accessibility.isAnimationReduceEnabledSync()`，API 23 正好够用）。 WebUI 侧有 `prefers-reduced-motion` 硬约束（index.css:1266）， 鸿蒙这边**改造前一次都没调过** —— 系统里关了动画，我们照样动。这是无障碍义务。 · `Theme.cardMaterial` —— 卡片材质令牌。不是拍脑袋选的： `COMPONENT_THIN` 实测卡片 252,254,254（吃掉 94% 壁纸，就是用户看到的"白卡"）； `BACKGROUND_THIN` → 185,190,201，壁纸透得出来且文字对比度仍够。 ★ 判定形状按"玻璃从例外变成默认"重写（判据 C 条） 原来是"允许出现玻璃的位置"白名单，逐处登记。那个形状在"玻璃是少数例外"时成立， 但用户要的是**全部玻璃化** ⇒ 白名单退化成"把每处抄一遍"，且挡不住新写的裸枚举。 改成**规则**：材质档次只能来自 `Theme.navMaterial` / `Theme.cardMaterial` （或 `BlurStyle.NONE`），页面里出现裸 `BlurStyle.XXX` 即红； 辅助方法（`this.materialOf()`）体内也查，否则等于开了后门。两条变异都验证咬得住。 ★ 判据 C 条自身的两个 bug（都被本次触发） · 嵌套判定**没比文件**：`c.at`/`o.at` 是各文件自己的字符下标，直接比大小 于是判出"MainPage 内含 SettingsPage 的玻璃"这种物理上不可能的红。 假红比漏报更坏 —— 会让人去改本来对的代码（本次差一点）。 · 参数抽取用 `[^)]*`：`this.materialOf()` 里含一层 `()`，在内层括号处截断， 把合法写法读成 `this.materialOf(` 判红。改成配对括号抽取。 ★ 出现/消失动画：用户点名的三处硬弹 这些挂在 `if (cond)` 上，条件一变整块出现/消失，原来一帧过渡都没有 —— 而代码上"看着像挂了动画"（外层页面有 transition），所以最容易漏。 · `MainPage` 账号选择器下拉 → `menuIn()`（从上往下落的浮层档） · `AdminUsersPage` 新建用户表单 → `paneRiseIn()`（就地展开档） ★ 过渡必须挂在**调用点的 Column**：`@Builder` 返回 void，链不上修饰符。 第一版写进了 `CreateForm()` 内部，是新判据抓出来的。 · `SettingsPage` 新增账号弹层 → `paneRiseIn()`（与回复/转发弹层同一挂法） 新增判据「出现/消失的那类元素真的挂了过渡」：**枚举所有条件挂载的浮层/展开块** （不是数数 —— 数数挡不住"新增第四处又漏了"），变异验证过。 ★ 顺手修的两处真嵌套玻璃 `SettingsPage` 的账号列表与密钥列表都是"卡里面的一段列表"，两层都铺材质 = WebUI 用 `.bg-white .bg-white { backdrop-filter: none }` 明确禁止的嵌套 （alpha 相乘 0.82×0.82=0.97 把壁纸吃光）。去掉内层材质，玻璃只留一层。 ★ 判据放宽一处（不是放水） `harmony-contacts` 那句写死 `pushUrl`，判的是"tryRestore 有没有跳转"， 与用哪个原语无关。修 LoginPage 返回栈时改成 `replaceUrl` 后它误报了； 改成 `(pushUrl|replaceUrl)`，原语该用哪个由 `harmony-nav` 那条专门判。 判据：files=32 ran=32 checks=518 pass=518 fail=0 red=0； baseline 7/7✓（第 6 次重算，两个文件逐个 `git diff --quiet HEAD` 取证为有意编辑）。	2026-09-20 07:37:16 +08:00
JianFeeeee	c1465e09ab	跨端: 平板三处真 bug（返回回登录页 / 避让重复叠加 / 联系人卡被裁 10vp） ... 用户报的「在主页返回为什么会直接回到登陆页」是**原语用错**： LoginPage 用 pushUrl 进 MainPage，路由栈成 [LoginPage, MainPage]， 返回自然弹回登录页。而 Logout.ets 早就是 replaceUrl 并写了理由 （「退出后不该还能'返回到已登出的页'」）—— 同一个不变式、相反方向， 只改了一半。三处 pushUrl → replaceUrl，设备实测：返回直接退出 app （前台变 com.huawei.hmos.browser），不再回登录页。 另两处平板（HUAWEI MatePad Pro, 2800x1840, ratio 1.52 ⇒ 宽屏）： · 内容列 `this.isWide ? Theme.surface : (bgActive ? 透明 : surface)` —— 宽屏分支把 bgActive 丢掉了 ⇒ 平板上壁纸永远被挡。 · `top: this.isWide ? paneGap : statusBar` —— 宽屏分支把状态栏避让丢掉 ⇒ 页签字压在系统时钟下。 · 侧栏自己也加了一次 topInset，而父 Row 的 padding 已经含状态栏 ⇒ 83+83=166px 空白（用户：「避让有点用力过猛」）。 · 联系人列表项硬写 .height(85)+clip，内容实际要 95vp ⇒ 写信/归档行被裁一半。 判据 harmony-nav 新增「登录/退出必须用同一个原语」并做变异验证 （改回 pushUrl 即红）；注册数 18→19，全绿 19/19。 ★ 途中发现的记账缺口：设备判据连续失败时走 noteBusySkip 计数， .tmp/harmony-busy-skips.json 累到 10 后拒绝再当'礼貌跳过'。 清除账本 + 让 app 真在前台后立刻 19/19 —— 说明**不是代码问题**， 是账本把'设备忙'当成了证据。这一点记进 DEBTS。	2026-09-19 23:38:35 +08:00
JianFeeeee	110de79401	跨端: 三级文字**浅色也一样不够**（12 处 2.85:1）+ 判据不再只验一半 ... ## 一、这是"我自己推的理由"被实测推翻 上一条我把 `textSubtleFor()` 写成**只改深色**，理由是： > 「浅色下这些令牌本来就是为浅底配的，量它们没有信息量」 **那个理由是错的。** 切到浅色主题复扫，立刻抓到 12 处： ``` "用户名 / 显示名 / 角色 / 状态 / 创建时间 / 最后登录" 2.85:1 "已同步" / "37%" / "3px"（外观区） 2.85:1 "这一天没有日程" 2.85:1 ``` `ink rgb(153,153,153)` 压白底 —— 全是 `textSubtle`。 对照 WebUI 浅色（`index.css` `:root`）： - `gray-400` = `107 114 128` = **4.83:1** - `gray-500` = `90 98 112` = **6.15:1** ⇒ 系统三级色**两个主题下都不够**。它的语义只是"比二级更淡"， **不保证任何可读性下限**；WebUI 那边两套主题都做过适配，这边一档都没有。 修：`textSubtleFor()` 两个主题都返回 `textMuted` （系统二级色，语义就是"次要文字"，且**跟随主题** —— 不必再维护两个手写常量、不必登记）。 ## 二、判据从"只验深色"改成"两个主题都验" 原来那条设备判据**在浅色下直接 skip**，skip 的理由正是上面那句错话。 现在两个主题都扫，断言消息里带上主题名（`深色主题下…` / `浅色主题下…`）。 ★ 纪律：**色令牌的可读性是两个主题各自的事，不能只验一半。** "另一半没问题"若没量过，就只是推测。 **变异验证**：把 `textSubtleFor()` 改回"两主题都用 textSubtle" （此时设备正在浅色主题）⇒ **判红**；还原 ⇒ 绿。 ## 三、设备复扫（浅色主题） ``` [通信] 扫 41 段，低对比 0 [日历] 扫 84 段，低对比 0 [联系人] 扫 50 段，低对比 0 [我的] 扫 40 段，低对比 0 ``` **215 段文字全部 ≥3:1。** 两个主题合起来：深色 219 段 + 浅色 215 段，全绿。 ## 四、顺手改掉的 测试名从「深色下短文本必须都读得动」改成「**当前主题**下…」 —— 名字得跟着它实际判的东西走（否则下一个人会以为它只管深色）。 `run-all.mjs` → `checks=515 pass=515 fail=0 skip=0 red=0 broken=0 unreported=0`。 **当前设备主题**：浅色（本轮为验另一半切过去的；服务端 `theme=light`）。	2026-09-19 20:58:59 +08:00
JianFeeeee	1da4e15a7b	跨端: 补齐「我的」页深色可读性（4 页 219 段全 ≥3:1）+ 判据自己漏报的那一类 ... 上一条把通信/日历/联系扫干净了，但**「我的」页没扫到** （扫描脚本按文案点不到它 —— 那是侧栏**底部的头像按钮**，不是导航项）。 补上后立刻又抓出问题，并把判据自身的**漏报形状**一并修了。 ## 一、「我的」页两处真 bug 1. **主题分段按钮 `SettingsPage.ets:834`**： `.fontColor(... ? Theme.surface : Theme.textPrimary)` —— `surface` 是 **会翻转的面色**，压在 `Theme.accent` 蓝底上，深色下变成近黑。 设备读数：`深色 2.93:1 ink rgb(32,34,36) bg rgb(34,96,228)`。 2. **权限档徽标 `MailDetailPage.ets:391`**：同一个错法（第 13 处）。 3. **账号名 `SettingsPage.ets:1179`**：三元里的裸 `Theme.accent` 压在 `accentSoftFor()` 底上 ⇒ `jianf 2.83:1`。 `AdminUsersPage.ets:386` 同形状（角色徽标）。 ## 二、判据自己的漏报形状（比 bug 本身更值得记） 静态防线（`C｜会翻转的 Resource 不得当前景色`）**在 bug 存在时是绿的**。 原因是它的提取正则： /\.fontColor\(Theme\.([A-Za-z0-9_]+)\)/ ← 要求令牌是**唯一实参** 于是**三元里的令牌全被漏掉**： .fontColor(this.appearanceTheme === t ? Theme.surface : Theme.textPrimary) 改成"在 `fontColor(` 之后的整段实参里找所有 `Theme.X`"之后， 它**立刻报出上面第 1、2 两处**（此前一直绿）。 ★ **判据漏报的常见形状是它自己的正则太窄，而不是被测代码太隐蔽。** 这条写成注释留在判据里了。 ## 三、我自己犯的批量替换错误（已加判据钉住） 把裸 `Theme.accent` 换成 `accentFor()` 时，**误把 6 处 `backgroundColor` 也换了**。 `accentFor()` 深色给浅蓝 `#80AFF9`，而搭档前景是白色 `accentFg` ⇒ 白字压浅蓝 ≈ **1.4:1**，主按钮文字会彻底看不见。 - 6 处已逐处还原（复核：`grep -c "backgroundColor(Theme.accentFor())"` = 0）。 - 新增判据 **`C2`**：`accentFor / dangerFor / approveFor / warnFgFor / textSubtleFor` **只能用于前景**，`backgroundColor(Theme.XFor(...))` 直接判红。 （`accentSoftFor` 是例外 —— 它本来就是"面"。） ★ 修法不是"下次小心点"：批量替换一定会再犯，**一行判据把它变成不可能**。 ## 四、设备复扫（修后） ``` [通信] 扫 42 段，低对比 0 [日历] 扫 85 段，低对比 0 [联系人] 扫 51 段，低对比 0 [我的] 扫 41 段，低对比 0 ← 新增 ``` **219 段文字全部 ≥3:1**（本轮全部针对深色）。 ## 五、底本 `baseline.sha` 第 5 次重算。重算前**专门复核**了"那 6 处误改有没有残留" （不只看 `git diff` 非空就放行）：`backgroundColor(accentFor)` 计数为 0、 `git diff HEAD~1` 里 backgroundColor 只有 calendar 那一处（有意改动）。 `run-all.mjs` → `checks=515 pass=515 fail=0 skip=0 red=0 broken=0 unreported=0`。 **未验**：浅色主题下的对比度没扫（本轮全部针对深色）。	2026-09-19 20:43:59 +08:00
JianFeeeee	4ecddfc2b6	跨端: 语义色/三级文字在深色下没提亮（设备扫出 12 处）+ 判据取样法修到第三版 ... ## 一、判据基建先修对，否则是在听噪声 深色可读性扫描的**取样法迭代了三版**，每版都因为**假红**才改的 （记在这里，因为"判据自己错"比"界面错"更费时间）： 1. **取中心一个像素** ⇒ 落在笔画之间、读到的是底色 ⇒ 一片 ratio=1.00 假红。 2. **取全局最暗/最亮** ⇒ 会采到**两个不同的东西**：细字的抗锯齿中间色。 实例：segmented「日」报 ink `rgb(32,34,35)` / bg `rgb(98,100,101)` 2.69:1 —— 而截图里它要么蓝底白字、要么深底浅字，两种都远高于 3:1。 **反复核对才确认是判据的错，不是界面的错。** 3. **步长采样 + 众数** ⇒ 仍然假红：周表头「一」报 2.03:1， 而逐像素的真实墨是 `rgb(166,167,167)`（**6.6:1**）—— 稀疏网格**整个跳过了笔画**。这不是调参能修好的（字越小越糟）。 4. **逐像素 + 众数=底 + 离底最远者=墨**（最终版）。 理由：一个文字框里**面积最大的一定是底**，而"离底色最远"就是笔画最实那部分。 ⚠️ 逐像素是**负担得起的**（整屏已解码在内存，一个框最多 9 万像素）—— **不要再为了省开销退回抽样**，前两版都因此假红。 ## 二、真 bug 三批（都是"深色下没提亮"） ### ① 语义色前景（12 处 → 修完设备复扫 0） WebUI 的语义色也是**双通道**，`.dark` 段把 `red/green/amber-700` 换成浅色 （`248/118/249 → 164/219/195` 那组）。鸿蒙只有一个深色值： - 「归档」按钮 `Theme.danger` #B91C1C 压深面 ⇒ **2.47:1**（联系人页 7 处） - 「今天」/「日」等 ⇒ **2.38–2.77:1** 加 `dangerDark/approveDark/warnFgDark`（逐字对齐 WebUI `.dark`） + `dangerFor()/approveFor()/warnFgFor()` 入口，22 处接入。 ### ② 日历工具条整块配色抄错（不是"深色档选错"） 对照 WebUI `CalendarView.tsx:313-331`： | 元素 | WebUI | 鸿蒙（改前） | |---|---|---| | 「今天」 | `border-gray-300` + `text-gray-700`（**中性**） | `accentSoft` 底 + `accentStrong` 字 | | 月/周/日 未选中 | `bg-white` + `text-gray-700` | `accentSoft` 底 | 鸿蒙把**次要的中性按钮**画成了**品牌色按钮** —— 视觉重量跟主操作一样， 三个档看起来"都像选中"。已按 WebUI 改成中性。 ### ③ 三级文字在深色下 2.82:1（**71 处**，全局最大的一个） WebUI 的 `.dark` 段注释逐字写着这个坑： > 「`gray-400/500`（次要文字）→ **提亮**。深底上的浅色 gray-400 > 只有约 2:1 对比度，远低于 WCAG AA 的 4.5:1 —— **看得见但读不动**。」 鸿蒙用的系统三级色 `ohos_id_color_text_tertiary` 深色下是 `rgb(102,103,105)` 压深面 **2.82–3.05:1**，而它被用在 10–11px 的**小字**上 （时间戳、农历、空态、辅助说明）。 **不换掉系统令牌**（"系统拥有的维度"纪律照旧），加 `textSubtleFor()`： 深色下改用二级色（实测 `rgb(166,167,167)` ≈ 7.15:1， 且与 WebUI 的 `gray-500` 同档位）。71 处接入。 **设备复扫（修后）**：通信/日历/联系三页 **176 段文字全部 ≥3:1**。 ## 三、欠账与底本 - `baseline.sha` 第 4 次重算。仍**先逐个取证**： `git diff --quiet HEAD -- <f> && echo STALE || echo INTENTIONAL` ⇒ 三个全是 `INTENTIONAL`（我改的），不是变异残留。 把这条取证命令也写进文件，下次照抄。 - `dangerDark/approveDark/warnFgDark` 已登记进 `SELF_OWNED_COLORS` + `Theme.ets` 登记表（各带理由与 WebUI 出处）。 `run-all.mjs` → `checks=514 pass=514 fail=0 skip=0 red=0 broken=0 unreported=0`。 **未验**：①「我的」页（底部头像按钮，扫描脚本没找到入口）没扫； ② 浅色下的对比度没扫（本轮全部针对深色）。	2026-09-19 20:27:09 +08:00
JianFeeeee	13b557a742	跨端: 品牌蓝深色下没提亮（24 处字/图标看不见）+ 补深色可读性设备判据 ... ## 一、真 bug：WebUI 深色下把品牌蓝**提亮**了，这边没有 WebUI 的强调色是**双通道**（`tailwind.config.js` 的 `backgroundColor` /`textColor` 覆盖 + `index.css` 两段定义）： | 通道 | 用途 | 浅色 | 深色 | |---|---|---|---| | `--s-blue-600` | **实心按钮底** | `37 99 235` | `37 99 235`（**同值**）| | `--c-blue-600` | 内容/交互的**蓝字与图标** | `37 99 235` | **`128 175 249`** | `index.css:353` 写了理由：主按钮底跟着变「会让主按钮在深色页面上 失去『这是主操作』的视觉重量」；而蓝字必须提亮，否则深底上读不动。 鸿蒙只有一个 `Theme.accent = '#2563EB'` ⇒ 24 处字/图标在深色下 对比度 **2.61:1**（设备实测：管理页返回箭头 `‹`），低于 WCAG 图形下限 3:1。 **取证方式**：在跑着的 WebUI 上用 CDP 读**计算样式**（不是读 CSS 源）—— 浅色 `37 99 235` / 深色 `128 175 249`，实测确认。 ## 二、修法：加前景专用的深色档 + 唯一入口 - `Theme.accentDark = '#80AFF9'`（= WebUI `.dark --c-blue-600`） - `Theme.accentFor(dark?)` 作为**前景**唯一入口 - **当背景的 20 处保持 `Theme.accent` 不动**（跟 WebUI 的 `--s-*` 一致） 24 处 `.fontColor/.iconColor(Theme.accent)` → `Theme.accentFor()`。 ## 三、顺手修掉「转述一层就会漏」这个结构问题 `accentSoftFor(isDark)` 原本的约定是"页面算好深浅色传进来"。 给 `accentFor` 做准备时一数：**8 处**直接用了 `Theme.accentSoft`（没走入口） —— 约定**已经漏了**，而漏掉的症状正是上一轮那个"深色下白底卡片刺眼"。 于是把两个 `For()` 的参数都改成**可选**：`AppStorage` 是 ArkTS 全局键值存储， 静态类可以直接读（原来"拿不到 Context"的理由不成立）。 ⇒ `Theme.isDarkNow()` 成为唯一判断点，调用方不必再各自转述。 ## 四、设备判据：深色可读性**扫一屏** 原来只有悬浮球那一条（单个点）。这个 bug 类一天撞到**两批**（12 处 + 24 处）， 逐处写判据追不上 ⇒ 改成把当前页所有小段文字都量一遍对比度。 三个实现要点（第一版全踩了，都写进注释）： - **不能只取中心一个像素**：中心多半落在笔画之间 ⇒ 读到的是底色， 报出一片 ratio=1.00 的假红。改成**框内网格扫描取极值**（最亮=底/最暗=墨）。 - **整屏解码一次**：每点 spawn 一次 ffmpeg 太慢 ⇒ 新增 `readPixels()`（157ms 解整屏，比逐点快三个数量级）。 - **只判"有真实墨迹"的框**（`hi.L - lo.L >= 0.02`），否则跳过而不是判红。 实测：修前 1 处低对比（2.61:1），修后 **40 段文字全部 ≥3:1**。 ## 五、判据自身的三个修正 - `accentSoftFor(dark:)` 的签名断言跟着放宽成 `dark?`，并**补上 `accentFor` 的**。 - **孤儿令牌判据从"一跳"改成"走整条链"**：`KEY_IS_DARK` ← `isDarkNow()` ← `accentFor()` ← 24 处页面。只查一跳时它假红 —— ★ **"有没有人用"是可达性问题，不是邻接问题**；加中间层（抽 `For()` 入口） 恰恰是我们鼓励的写法，而旧判据会因此假红。 - 手写色登记表补 `accentDark` 一行理由。 ## 六、`baseline.sha` 重算（先核过不是残留） 三个文件哈希对不上。逐个 `git diff --quiet HEAD -- <f>` 取证： - `AdminUsersPage.ets` / `SettingsPage.ets` —— 本次**有意编辑**； - `api/AppearanceApi.ets` —— **与 HEAD 逐字节相同** ⇒ 底本取完后被**合法改过** （提交 `f811c98`），属 `stale` 不是 `residue`。 按该文件自己那条纪律（「重算必须是一次有记录的动作」）在文件里记了理由。 `run-all.mjs` → `checks=514 pass=514 fail=0 skip=0 red=0 broken=0 unreported=0`。	2026-09-19 20:05:33 +08:00
JianFeeeee	21132647bc	跨端: 12 处「深色下字看不见」的真 bug + 判据基建补上「看像素」这一层 ... ## 一、判据基建：本目录终于能**看像素**了 此前只能靠 `dumpLayout` —— 那是**结构化描述**，报的是"组件声明了什么"， 不是"屏幕上画成什么样"。两者会分叉，而观感类结论只能在像素上得出来。 新增 `lib/harmony-device.mjs`：`screenshot()` / `pixelAt()` / `hexToRgb()` / `closeColor()`（用 ffmpeg 转 1×1 原始 RGB，不引依赖）。 **它当场证明了它的价值**：`cross-client-theme` 新增的设备判据 用真实像素抓到下面这个 bug —— 静态判据全绿时它藏得好好的。 ## 二、真 bug：**12 处**把 `Theme.surface` 当前景色用 `Theme.surface` 是 `sys.color.ohos_id_color_list_card_bg` —— 一个**跟随系统主题翻转**的 Resource：浅色近白、**深色近黑**。 - 浅色下当白字用**碰巧对**（白字压蓝底） - **深色下字变成黑的**，压在品牌蓝 / danger 红 / warn 琥珀上**几乎看不见** 设备现场：写邮件悬浮球是品牌蓝 `#2563EB`，截图里那个铅笔图标**几乎是隐形的**； 读圆心像素得到 `rgb(32,34,36)`。往左偏 50px 读到底色才见 `rgb(36,99,235)`。 `Theme.accentFg`（`#FFFFFF`）的注释原话就是「品牌底上的文字」—— 为这个场景存在， 却**一处都没用**。 修：12 处 `fontColor/iconColor(Theme.surface)` → `Theme.accentFg` （`MainPage` 10 + `InboxPage` 1 + `SessionsPage` 1）。改完全仓 0 处残留。 另在 `Theme.ets` 给 `surface` / `accentFg` 都补上"能当什么、不能当什么"的注释。 ## 三、判据（两条，都做了变异验证） 1. **设备条**（`cross-client-theme`）：读悬浮球像素 —— ① 品牌色**真的画成** `#2563EB`（声明 ≠ 渲染）； ② 球上图标与底色 **WCAG 对比度 ≥3:1**（压在上面的东西得看得见）。 把 `.accentFg` 改回 `.surface` ⇒ **判红**；还原 ⇒ 绿。 2. **静态防线**（同文件）：全局 grep「`fontColor/iconColor(Theme.surface)`」一处不许有。 设备条只能看一处，而这个错法有 12 处 —— 静态防线管住整类。 ## 四、判据自身踩的三个坑（都写进注释了） - **采样点撞上图标**：第一版取球心，读到 `rgb(32,34,36)`，差点当成"品牌色没渲染"。 截图一看球是蓝的，深色那点是**铅笔图标**。⇒ 往中心左偏 30% 球宽。 - **假设错了 FAB 的位置**：按"屏幕右下角"找（`x1 > 屏宽*0.6`）， 实测 `[942,1997]`（`x1=942` vs 阈值 1910）⇒ 永远找不到、**静默跳过**。 原因是列表窗格是**左栏**，球在"左栏的右下角"。⇒ 形状只用站得住的那部分（下半部）。 - **设备判据要自己搭现场**：不加自导航时它**永远跳过**（前面的判据把前台留在管理页）， 而那看起来像"功能没了"。加自导航后立刻开始工作并抓到 bug。 ## 五、欠账 - `harmony-maildetail-missing-three` → **count 0（结算）**：三块都做完了 （转发 `b7c5d8b` / 改名建议 `c2f35d1`+`e79a86a` / 往返预算 `ac62daf`）。 如实记着**未验**的那点：预算条的**点击**没在设备上走通 （模拟器顶部 155px 是系统手势区，折叠头部恰在其中）。 - `static-criteria` 5：`cross-client-theme` **升级了一半**，仍留在名单里 —— `.ets` 那半只有悬浮球这一处上了设备，其余令牌仍是静态对齐。 - `debt-visibility` 登记 `cross-client-theme` 1 处边界声明（带出处）。 `run-all.mjs` → `checks=513 pass=513 fail=0 skip=0 red=0 broken=0 unreported=0`； Go 侧 `./internal/repo/...` 通过。	2026-09-19 19:29:49 +08:00
JianFeeeee	ac62dafde1	跨端: 往返预算编辑上线（详情页缺的第三块）+ 修折叠头部点不中的真 bug ... 审计发现详情页缺三块功能之三：**往返预算**（WebUI `BudgetEditor`）。 `MailApi.setBudget` 早就有了，缺的是 `getBudget` 与 UI。 ## 一、预算条（对齐 WebUI，两态） 显示态是徽标（`已用/上限 来回` / 不限时「预算不限」/ 用尽时标红）， 点它进入编辑态：输入框 + 保存 + 重置 + 取消。 ★ 「用尽」的判定**走服务端的 `remaining`**，不自己拿 `used >= max` 算： 不限时服务端给 `remaining: -1`，那个式子在那种情形下会算出"已用尽"。 两端都得用服务端的口径。 ★ 「保存」与「重置计数」走**同一条 PUT**（服务端支持两者同时给， 它的注释原话：「加到 20 并从头算」是一次很自然的操作， 拆成两个请求只会让前端多一次往返）。 **契约实测**（不是形态检查）： GET → {"max_rounds":0,"used_rounds":1,"remaining":-1,"unlimited":true} PUT {"max_rounds":7,"reset":false} → {"max_rounds":7,"remaining":6,"unlimited":false} PUT {"max_rounds":0,"reset":false} → {"remaining":-1,"unlimited":true} ← 0 = 不限 ## 二、真 bug：折叠头部的展开区只有 **14px** 高 设备实测 dump：`Row [1277,112][3122,126]` —— 可点区高度 = 文字高度（14px 字号）。 而全屏之后**状态栏也在 y=112 那个区间** ⇒ 点它反复触发**系统手势（下拉通知）** 而不是展开头部。我为此试了七八次，每次都回到桌面。 而收起态头部里藏着**这个会话的全部旋钮**（收件人/时间/抄送/权限档/预算）—— 点不中就等于那些都看不到。 修：给那一行 `height(36)`（与左边返回键同高）。实测可点区 **14px → 43px**（`[1277,112][3122,155]`）。 ★ 判据 + **变异验证**：去掉 `.height(36)` ⇒ 判红；还原 ⇒ 绿。 ## 三、判据 `harmony-logic` 新增「折叠头部展开区高度 ≥32vp」一条（含变异自检）。 `run-all.mjs` → `checks=511 pass=511 fail=0 skip=0 red=0 broken=0 unreported=0`。 **未验**：预算条在设备上的**观感与点击**（模拟器顶部 155px 是系统手势区， 而头部恰在其中 —— 坐标式点击在那里会被系统抢走；真机上头部在状态栏之下）。 预算条的**数据链路**已用 curl 逐条实测（见上），但"点保存按钮后徽标变化" 这一步没在设备上走通。	2026-09-19 17:41:09 +08:00
JianFeeeee	e79a86ab79	跨端: 改名建议条接到详情页（端到端实测：点「接受」别名真的改了） ... 上一批做完了接口层，这批接 UI —— 详情页现在真的显示建议条并能操作。 ## 做了什么 提示条放在正文之前（与 WebUI 同位置）：Agent 给的理由 + **后果说明** （「改名后需用 name@path.xxx 寻址；旧别名立即失效……」）+ 「接受」/「忽略」。 蓝底（`accentSoft`）而不是警告色：它不是故障，是一个**待决定**； 深色下走 `accentSoftFor`（就是前一批修的那个主题感知浅底）。 `doAcceptRename` 走 `PUT /sessions/{id}/alias`（与"人手改别名"同一端点）， `doDismissRename` 走专用 dismiss 端点 —— 服务端记下被驳回的别名， 否则每次打开会话都要重新点一次「忽略」。 ## 途中三处**我自己的**错误（都值得记） 1. **写错了请求体字段名**：我按记忆写成 `session_alias`，而服务端 `updateAliasRequest` 的 tag 是 **`alias`**（`sessions.go:95-97`）， WebUI 也是 `{ alias }`（`client.ts:537`）。而它的 `Decode()` 是 `DisallowUnknownFields()` ⇒ 传错名字**直接 400**（不是"被忽略"）。 这是今天第三次同源错误（`AppearancePayload` / `ForwardMailRequest` / 这次）—— **请求体字段名必须去服务端 struct tag 里读，不能凭记忆写**。 2. **判据跟着实现一起错**：我把判据也写成"断言 `session_alias: alias`" —— 等于把这处错误**锁进两处**。判据已改成断言 `this.alias = alias`， 并加了一条反向断言"不许出现 `session_alias: alias`"。 ★ 这是"判据引自己的实现当依据"的又一次实证。 3. **UI 写完忘了接数据**：提示条的 UI 做完、编译过，但**没有调用 `getRenameProposal`** ⇒ 页面上永远不显示（服务端明明有建议）。 —— 正是本仓反复出现的"写好了但没人调用"：静态判据查得出"代码里有这个方法"， 查不出"页面从没调过它"。 ⇒ 补上 `loadRenameProposal()`，并**单独一个 try**（建议条是附加信息， 它失败不该把正文也变成错误态）。 ## 端到端验证（真数据） 造一封带标记的真邮件投进一个真会话 → 服务端识别（`rename_proposed: "rename-verify"`） → 详情页出现建议条（dump 读到理由 + 后果说明 + 两个按钮） → 点「接受」→ 库里别名真的变了： 处理四桥冒烟测试邮件 → rename-verify ## 判据 `run-all.mjs` → `checks=510 pass=510 fail=0 skip=0 red=0 broken=0 unreported=0`。 `hvigorw assembleHap` 成功；前端重建 + 重打包。 **未验**：「忽略」按钮的端到端（服务端记下驳回、不再重复弹）—— 接口层已有判据钉住路径，但没在设备上真点过。	2026-09-19 17:23:23 +08:00
JianFeeeee	c2f35d1023	跨端: 会话改名建议的接口层（详情页缺的第二块，服务端三个端点齐） ... 审计发现详情页缺三块功能之二：**Agent 的改名建议条**（WebUI `MailView.tsx:324` 的 `RenameProposalBar`）。这一批做**接口层**，UI 接线下一批。 ## 为什么这件事不只是"少个提示条" WebUI 那段的注释写得很清楚： > Agent 干到一半自己改掉，人上一秒记住的地址下一秒就失效。 > 提议 + 人确认，既让 Agent 表达意图，又保证寻址稳定性由人掌握。 也就是**寻址稳定性**的设计 —— 别名是人的寻址入口，Agent 只能**提议**。 ## 做了什么 1. `model/SessionRename.ets` —— `RenameProposal`（`alias` / `reason`， 字段名与服务端 json tag **逐字对齐**） 2. `api/SessionApi.ets` —— 三个动作： · `getRenameProposal(sessionId)` → `{"proposal": {...}}` 或 `{"proposal": null}` · `acceptRename(id, alias)` → **`PUT /sessions/{id}/alias`** · `dismissRename(id)` → `POST /sessions/{id}/rename-proposal/dismiss` 3. 判据（`harmony-logic`，+1 条）：字段名、响应外壳容忍 `null`、 接受走别名端点、驳回走专用端点、方法名与 WebUI store 同名、+ 变异自检。 ★ **接受为什么不另开端点**（服务端注释原话）： 「那条路径已经有唯一性校验与 409 处理，复制一遍只会多一个出错的地方」。 所以"接受建议"与"人手改别名"是**同一条路**，而"驳回"是另一条 （它不是改别名，是"别再问了"——服务端记下被驳回的别名， 否则每次打开会话都要重新点一次「忽略」）。 ## 端到端验证（真数据，不是形态检查） 造了一封带标记的真邮件投进一个真会话： POST /mail/send {reply_to: …, body: "内容正文。<!-- agentmail:rename-session alias=\"rename-verify\" reason=\"验证改名建议链路\" -->"} → 200 {"rename_proposed":"rename-verify", …} 然后： GET /sessions/{id}/rename-proposal → {"proposal":{"alias":"rename-verify","reason":"验证改名建议链路"}} ✓ 形状与我的一致 SELECT body FROM mails … → "内容正文。" ✓ 标记被剥掉 两件事都验到了：**服务端识别建议**，且**标记从人读的正文里剥离** （HTML 注释在 Markdown 渲染器里会变成可见文本，所以必须剥，不能指望渲染器吞掉）。 ## 判据 `run-all.mjs` → `checks=510 pass=510 fail=0 skip=0 red=0 broken=0 unreported=0`。 `harmony-logic` 30 → 31。`hvigorw assembleHap` 成功；前端重建 + 重打包。 **未做**：UI 接线（详情页的提示条）。接口层已完成并验证， 但"页面上真的显示建议条并能点接受/驳回"要下一批。	2026-09-19 17:12:40 +08:00
JianFeeeee	b7c5d8b1e7	跨端: 邮件转发上线（详情页缺的入口）+ 修两个真 bug（动作球重叠 / 键盘挡住按钮） ... 审计发现详情页缺三块功能之一 —— **转发**。服务端 `forward.go` 完整、 `MailApi.forward()` 也早就写好了，缺的只是这一页的入口。 ## 一、转发（对齐 WebUI `ForwardBar`） 字段与占位文案逐条对齐：收件人 / 抄送（**可折叠**，默认收起）/ 说明 / 引用原文。 `subject` 留空让服务端自动加 `Fwd: ` 前缀（它处理了 "Fwd: Fwd:" 无限叠加）。 ★ 请求体用了**专用类型** `ForwardMailRequest`，不复用 `SendMailRequest`： 服务端 `forwardRequest` 只认五个字段，而它的 `Decode()` 是 `DisallowUnknownFields()` ⇒ 多带一个（`body` / `reply_to` / `attachment_ids`…）就 **400**。 —— 这正是我今天在 `AppearancePayload` 上刚犯过的那个错，**端点一个类型一个请求体**。 ★ 顺带发现：`MailApi.forward` 的签名**原本就写错了**（参数类型是 `SendMailRequest`） —— 一直没被发现，因为**从来没有调用方**。"写好了但没人用"的代码， 连它自己的类型对不对都没人验过。 ## 二、真 bug ①：两个动作球**几乎完全重叠** 转发球与回复球**各自**写在 `Stack({alignContent: BottomEnd})` 里、各带一个 margin。 实测 dump 的 bounds（密度 2.875）： 转发 [2984,2010][3122,2148] 回复 [2949,1998][3110,2159] ← 重叠区 x ∈ [2984,3110] 屏幕上只看得到一个球，**转发入口等于不存在**。 根因：`Stack.alignContent` 把**每个**子元素都摆到同一个角，margin 只是各自微调。 修法：用 `Row({ space: 12 })` 包住两个球、由 Row 带 margin 到角落。 **设备实测**（修后 dump）：`[2776,2021][2914,2159]` 与 `[2949,1998][3110,2159]`，不重叠。 ## 三、真 bug ②：键盘一弹，「转发」按钮就被顶出屏幕 转发弹层第一版**没有高度**（只有 `padding(16)`）⇒ 尺寸由内容决定。 而 ArkUI 默认的键盘避让是 `KeyboardAvoidMode.OFFSET`（整体上移）—— 上移之后 `TextArea` 与「取消 / 转发」按钮**跑到键盘下面**，点不到。 实测截图：只看得见收件人输入框 + 键盘。 修法两半（缺一不可）： ① 弹层给明确高度 `height('60%')`（与回复弹层一致，它一直没出问题）； ② 说明框改 `layoutWeight(1)`（不是固定 `height(70)`）—— 键盘顶上来时它自己缩短， 把按钮留在屏内。 **设备实测**（键盘弹出时 dump）：`取消 [1196,2054][1426,2158]`、 `转发 [2880,2054][3110,2158]` 都在屏内（屏高 2232），且 `clickable=true`。 ## 四、判据（这两条固化了上面两个形状） `harmony-admin` 新增两条**静态形状**判据（它们抓的是写法，不需要设备）： 1. **同一 `Stack` 里的多个圆形按钮必须被 `Row` 包住**（否则重叠）； 2. **底部弹层必须有明确高度** + 会撑高的子元素用 `layoutWeight` （否则键盘一弹按钮就被顶出屏幕）。 ★ 为什么用静态判据而不是设备判据：这两个 bug 的**形状**在源码里就看得见 （`Stack` + 各自 margin / 弹层缺 `.height`），而设备判据要摆出"键盘弹出"这个态， 成本高且不稳。静态判据在这里是**更快更准**的那一层。 （设备判据仍保留在别处，验"真的能打开、真的渲染出来"。） ## 五、验证 `run-all.mjs` → `files=32 ran=32 checks=509 pass=509 fail=0 skip=0 red=0 broken=0 unreported=0`（`harmony-admin` 28 → 30）。`hvigorw assembleHap` 成功。 **设备实测**：转发球与回复球分开显示（各自图标可见）； 点转发球 → 转发框打开（「转发「…」」+「抄送」折叠开关 + 取消/转发）； 键盘弹出后按钮仍在屏内可点。 **未验**：真发一封转发（收件人输入在自动化里不稳 —— `uitest inputText` 是**追加**而非替换，且 `keyEvent Back` 会退出页面而不是收键盘。 这条留待真人操作窗口，与 `harmony-p4c-boundary-decls` 那笔同性质）。	2026-09-19 17:00:44 +08:00
JianFeeeee	fc295893cb	跨端: 深色模式下的品牌浅底不跟随 —— 12 处「选中/未读」底色在深色页上刺眼 ... ## 真 bug（设备实测） 深色主题下，「我的」页**选中**的那张账号卡片仍是接近纯白的浅蓝 （实测像素 `(255,255,255)` 级别的浅底压在 `(32,34,36)` 的深色页上）。 根因：`Theme.accentSoft = '#EFF6FF'` 是**写死的浅色**，而它被当作 「选中态背景」用在 12 处（未读邮件行、选中账号、分段选中、登录页模式切换…）。 **为什么只有 WebUI 没这个问题**：它有 CSS 变量的**反转发**机制 —— `index.css:113` 的 `--c-blue-50: 239 246 255` 在 `.dark` 段（`:475`）被换成 `28 37 54`（深蓝黑）。ArkTS 的 `static readonly` **一个常量一个值**， 没有那层机制 ⇒ 静态常量必须自己提供两个取值。 ## 修法 1. `Theme.accentSoftDark = '#1C2536'`（对齐 WebUI `.dark --c-blue-50` 的 `28 37 54`） 2. `Theme.accentSoftFor(dark)` 作为**唯一入口** —— 不在页面里各自 `isDark ? a : b`：那样每处都会各写一遍，迟早漏一处 （WebUI 那条"由 test/theme.test.mjs 逐档断言"就是为防这个） 3. **深浅色从哪来**：只有 `MainPage` 算得出（它读 `resourceManager` 的 `colorMode`）。所以走 `AppStorage` 单向发布（与徽标、windowInsets 同一套）： MainPage 算 → 写 `agentmail.appearance.isDark` → 各窗格 `@StorageProp` 读。 6 个文件、12 处，全部改用 `accentSoftFor(this.isDarkNow)`。 **设备实测**：深色下「我的」页账号卡片与收件箱未读行都变成深蓝底， 像素 `(32,34,36)` 与页面底一致（不再刺眼）。 ## 判据（这条是新加的，形状值得记） `cross-client-theme` 新增：**品牌浅底必须有深色变体**。断三件事： 1. 深色变体存在，且**取值从 WebUI 的 `.dark` 段反推**（不是随手挑一个深色）； 2. 有按主题选值的**入口**（防"页面各自写三元"）； 3. **用到它的地方真的走那个入口** —— 扫描所有 `backgroundColor(… accentSoft …)` 并排除 `accentSoftFor`，把漏改的位置**逐行报出来**。 第 3 条在我改到一半时**当场列出了剩下 9 处**（`CalendarPage:1172`、 `ComposePage:255`、`LoginPage:327`…）—— 这就是它该有的样子： 不是"断言存在某个常量"，而是"断言没有一处漏改"。 ★ 写这条判据时踩了自己一次：JS 模板串里嵌了反引号包围的标识符 （`` `accentSoft` ``），直接 SyntaxError。改用字符串拼接。 ## 判据 `run-all.mjs` → `checks=506 pass=506 fail=0 skip=0 red=0 broken=0 unreported=0`。 `hvigorw assembleHap` 成功；前端重建。 **未验**：日历/登录页在深色下的观感（只逐处改了底色，没逐页截图）。	2026-09-19 16:02:26 +08:00
JianFeeeee	81621974b9	跨端: 日历「新建」按钮补文字（原先只有一个加号）+ 详情页三处缺失登记 ... ## 一、日历的「新建」按钮（对齐 WebUI 的主动作） WebUI `CalendarView.tsx:362-369` 那个按钮是工具栏里**唯一的实心按钮**： `px-2.5 py-1 bg-blue-600 text-white` + `<PlusIcon/>` + **「新建」两个字**。 鸿蒙原先只有一个光秃秃的 `Button('＋')` —— 丢掉的不只是文字，是**主动作这层语义**： 用户得猜"这个加号加什么"（加日程？加订阅？加日历？）。 改成蓝底 + 图标 + 「新建」，与 WebUI 同形。**设备实测截图确认**。 ★ 与这条对照的是它左边那两条「导入/导出」：鸿蒙**有意**用文字而非图标， 理由已写在代码注释里（WebUI 有 `title` 可悬停，手指没有悬停）。 同一个道理在主动作上更成立 —— 主动作不该是个谜语。 ## 二、邮件详情页缺三块功能（审计发现，服务端都已支持） 对照 `MailView.tsx` 逐段核对，鸿蒙 `MailDetailPage.ets` 缺： | 功能 | WebUI | 服务端 | |---|---|---| | `RenameProposalBar` | `MailView.tsx:324` | ✅ `rename_proposal.go` 已在解析 `propose_alias` | | `ForwardBar`（转发） | `MailView.tsx:378` | ✅ `forward.go`（含 `forwardSubject` 的 Fwd: 叠加处理） | | `BudgetEditor`（预算） | `MailView.tsx:235` | ✅ `max_rounds` 字段 | 改名建议那条尤其重要（WebUI 注释：「Agent 干到一半自己改掉，人上一秒记住的 地址下一秒就失效」）—— 是否决制而不是 Agent 单方面改，这是**寻址稳定性**的设计。 三条都**没有**在这批里硬做：各含交互 + 接口 + 状态，不是顺手能补的量级。 登记进 `docs/DEBTS.json`（`harmony-maildetail-missing-three`）—— 硬塞的结果是每条都半成品，那比缺着更糟（缺着是可见的，半成品是不可见的）。 ## 三、审计中确认**已对齐**的部分（不是漏做） - 通信：工具条三页签分组与顺序、列表行的字段集（发件人/主题/摘要/时间/未读点/ 账号徽标/档位徽标）、会话折叠与组头（别名/主题/未读/封数）、空态文案、 发件箱的三处差异（数据源/`to_name`/不筛权限）、归档确认框。 - 日历：工具条分组与顺序、宽屏两栏（左网格 + 右 400vp 常驻）、右栏三态、 月/周/日三档网格与农历小字、非本月淡出、今天高亮、事件圆点、 点某天的行为（宽屏换右栏 / 窄屏滑入）、导入导出的三条结果分支。 - 联系人：卡片/列表两视图、字段集、归档确认框（含破坏性操作的二次确认）。 - 「我的」：八个分段的字段与顺序、壁纸选择器、主题三态、多账号入口。 - 管理页：列与操作、管理员门禁。 - 外壳：侧栏三项 + 底簇、底栏四项、徽标三档色调与位置、玻璃材质、让位。 ## 判据 `run-all.mjs` → `checks=504 pass=503 fail=1`（唯一那条是 build-stamp 的 产物过期，重建后 7/7）。`hvigorw assembleHap` 成功。 `docs/DEBTS.json` 新增三条登记（断点差异 / 列表附件数 / 详情页三功能）。	2026-09-19 15:19:57 +08:00
JianFeeeee	f655453424	跨端: 审计补强 —— 邮件行的「抄送 N」+ 断点差异登记 + 两处"看起来有其实没有"的澄清 ... 继续「全面对齐 WebUI 和鸿蒙」。这一轮做的是**逐页对照审计**（子代理通道被 session daemon 的端口占用堵死，改为自己逐处读源码对照）。 ## 一、补上邮件行的「抄送 N」（真缺失） WebUI `MailList.tsx:350` 行上有「抄送 N」，鸿蒙**完全没有**。而数据一直在： `cc_list` 服务端确实返回（实测回包字段列表里有），只是鸿蒙的 `MailLike` 接口漏了这个字段 ⇒ 一封抄送给多个人的邮件在列表里看不出任何区别。 修法：接口加 `cc_count`，`MailSummary` 加 `cc_list` + `cc_count`， 收件箱/发件箱两处填充派生值，行上按 WebUI 的位置渲染。 **设备实测**（造了一封带 2 个抄送的真邮件）：行上出现「抄送 2」， 位置与 WebUI 一致（主题行下方、灰字）。 ★ 接口用**数字**而不是 getter：`MailSummary implements MailLike`， 而 ArkTS 的 interface 里不能声明 getter（编译报 "incorrectly implements interface"）。 ## 二、有意**不抄**附件标记（发现 WebUI 那段是死代码） WebUI 行上还有一个 📎 + 数量的标记（`MailList.tsx:351-355`）。但核对服务端 **实测回包**：`GET /me/mail/inbox` 既没有 `attachments` 也没有 `has_attachments` ⇒ `mail.attachments?.length ?? 0` **恒为 0**，那个标记在 WebUI 上**从不出现**。 所以鸿蒙这一轮**有意不抄它** —— 照抄一个不工作的东西，只会多一处 "看起来有、永远不亮"的代码。要做这个功能得先让服务端在列表回包带上附件计数 （一次 JOIN 的事），那是独立的一件事，已登记进 `docs/DEBTS.json` （`mail-list-attachment-count`）。 ★ 这一条与鸿蒙 `MailSummary.has_attachments` 那个字段一起处理掉了： 它还留在那里会误导人（服务端永不返回它 ⇒ 恒 false）。 ## 三、两端宽屏断点不同 —— 登记 + 判据（此前**无任何记录**） 审计点名要核实的这条确认成立： WebUI: `NARROW_QUERY = '(max-width: 1023px)'` 含义 = 「三栏（60 导航 + 320 列表 + ≥520 详情 ≈ 900px，再加余量）放不下就退化单栏」 鸿蒙: `isWide = width >= 768` 含义 = 「要不要显示**侧栏**」（鸿蒙内容区是一个窗格，没有并排三栏） **含义不同，所以数值不同本身不算错** —— 这与手势阈值同一条口径 （语义各自成立时，数值不必强求一致）。但**用户可见的后果**是：768–1023 宽 （常见竖屏平板、窄窗口）下 WebUI 是单栏+底栏、鸿蒙是侧栏+内容， 同一宽度在两端长得不一样。 处理：① 登记进 `docs/DEBTS.json`（`wide-breakpoint-divergence`， 带三个待定选项）；② 加判据 —— 它**不**要求两端取值相同，而是要求 「取值可读 + 含义写清 + 差异被登记」三件事同时成立。 ★ 写这条判据时又踩了同一坑：用 `code()` 读注释 ⇒ 永远红。 `criteria-hygiene` 判据的头顶就写着"判代码用 code、判理由用 prose"。 ## 四、判据 `run-all.mjs` → `checks=505 pass=505 fail=0 skip=0 red=0 broken=0 unreported=0` （cross-client-theme 15→16）。`hvigorw assembleHap` 成功。 **未验**：附件标记（有意不做）；抄送行在**深色**下的对比度未单独验。	2026-09-19 15:13:51 +08:00
JianFeeeee	f811c9887a	跨端: 三个真 bug（外观保存 400 / 改档位界面不动 / 内容列溢出屏幕）+ 设备判据 ... 这一轮从「全面对齐 WebUI 和鸿蒙」开始，先做设备层判据升级，结果**判据一上线就连撞三个真 bug** —— 它们全都是静态判据照不到的形状：**数据对、界面不动**。 ## 一、外观保存从来就没成功过（PUT 400） `payloadFromLocal` 复用了 `AppearanceResponse` 当请求体，而那个类型是 **GET 的响应**： 带着 `has_image` / `image_bytes` / `saved`。服务端的 `Decode()` 是 `DisallowUnknownFields()`（严格，**有意为之**）⇒ **每一次保存都被拒收（400）**。 症状极隐蔽：本地 `@State` 立刻变 ⇒ 肉眼看着像成功了；只有看 hilog 的 HTTP 状态码 才发现 400。修法是加 `AppearancePayload`（**恰好**服务端 `models.Appearance` 的五个字段）。 ★ 这是"两端共用同一个类型"的代价：请求与响应本来就不该同形。 ★ 服务端严格是**对的** —— 它帮我们抓到了这个错误。修客户端，不是放宽服务端。 ## 二、改了档位，页面背景一点不变（两层原因） **第一层**：`SettingsPage` 存进 store 了，但 `MainPage` 的 `bgPlan` 只在启动时算一次， 之后没人动 ⇒ 发布一个 `AppStorage` revision（计数器，不是布尔 —— 布尔 true→true 不发变化通知），`MainPage` 用 `@StorageProp + @Watch` 接住。 **第二层（更隐蔽）**：接上之后**还是不动**。因为 `bgPlan` 是 `@State BackgroundPlan`， 而 **ArkTS 的 `@State` 观察不到类内部字段**的变化 —— 渲染读的正是 `this.bgPlan.kind` / `.layers`。hilog 一对证据同一次启动相差 100ms： Appearance: sync: bgKind=preset … hasImg=true ← 数据是对的 Wallpaper: kind=none layers=0 active=false ← 渲染读到的还是旧值 修法：加 `@State bgContentRev: number`，每次算完 plan 就 +1，**并在 Builder 的 条件表达式里消费它**（ArkUI 按"这个 Builder 读了哪些 @State"决定是否重渲染； 只加计数器而渲染不读，等于没加 —— 判据同时断这两半）。 ★ 同一个坑本仓出现过（`AppearanceStore` 的注释里写着这句），这次换了地方发作。 ## 三、「我的」页右端内容被顶出屏幕（追了很久的 `56.000000` 之谜） 真相有**两层，两层都值得记**： 1. `dumpLayout` 里 `Slider` 节点的 `text='56.000000'` 是**无障碍文本** —— 屏幕上根本没这串字（截图可证）。**dump 的 text ≠ 看得见的字**。 2. 真正的问题是那个**看得见的** `Text('56%')` 落在 `x=3250`，而屏宽 3184 ⇒ **它在屏幕外**。用户只看得到滑杆、看不到数值。 根因：`MainPage` 里"侧栏 + 内容列"是 `Row` 并排，内容列写 `.width('100%')` —— 在 Row 里 `100%` 是**父容器全宽**，与侧栏的 60vp **相加** ⇒ 必然溢出。 实测内容列 `[229,28][3357,2204]`，右边缘超出屏幕整整 173px（= 60vp）。 修法：改 `.layoutWeight(1)`（吃剩余空间）。修完实测 `[229,28][3156,2204]`， `Text('56%')` 落在 `[3049,1803]` —— 屏内。 ★ 为什么值得一条设备判据：**同一处错误在不同 pane 上表现不同** （日历页自己算宽度就没露出来），很容易被当成"某一页的样式问题"去调。 ## 四、设备判据基建（这一轮加的能力） - `lib/harmony-device.mjs` 新增 `launchOurApp` / `ourAppInFront` / `tapText` / `swipe`。 `swipe` 里 clamp velocity 并写明那个坑：`uitest` 的 velocity 越界**不报错**， 只回一句 "out of range, the default value will be used"，静默换成默认 600。 - 三条新设备判据（`harmony-appearance`）：壁纸档位真的切换 / 窗格内容不得超出屏幕。 - 修了一个**元问题**：设备判据在套件里**恒跳过**（要求"现场已经摆好"）， 只有手动摆好才通过 ⇒ 那等于没有判据。现在它们**自己搭现场** （拉起应用 → 导到目标页 → 操作 → 复位）。`cross-client-gesture` 与 `harmony-appearance` 都改成了这样，套件里 `skip=0`。 - 途中撞出的两个判据自身缺陷（都写了注释）： · `root0` 用**切页前**的快照 ⇒ 套件里红、单独跑绿（通过与否取决于跑之前那一屏） · 侧栏项筛选没排除**品牌标** ⇒ 想点「日历」却点到「通信」 ## 验证 `run-all.mjs` → `files=32 ran=32 checks=503 pass=503 fail=0 skip=0 red=0 broken=0 unreported=0`（含设备判据：gesture 9、appearance 27）。 `hvigorw assembleHap` 成功；前端重建 + 重打包（`build-stamp` 7/7、`packaging` 5/5）。 设备实测（HATriple 3184×2232）： · `PUT /me/appearance` 从 **400 → 200**（服务端访问日志）， 库里 `jianf` 的记录从空变成 `bg_kind=preset / bg_dim=56 / bg_blur=3`。 · 壁纸真的透出来了：预设档缝隙 `#E0E2E4`、不设档 `#FFFFFF`（像素级对比）。 · 「我的」页 `56%` / `3px` 正常显示在屏内。 **未验**：壁纸在真机上的观感（渐变是否好看、压暗 56% 是否合适）； 这一轮只验了"数据通了、界面响应了、内容没被裁掉"。	2026-09-19 15:03:40 +08:00
JianFeeeee	28e3da76d4	跨端: 左右滑动翻页（P6 第 3 步）+ 还 gesture-semantics 债 + 修跑不起来的判据基建 ... ★ 这一轮从用户一句「滑动手势呢？」开始。查下去发现它不是"顺手加个手势"， 而是 `docs/DEBTS.json` 里挂着的一笔债 —— `gesture-semantics` 的原话是： 「P6 第 3 步：鸿蒙侧出现滑动手势代码时**立即建**判据 （此前建 = 只有一端存在的假判据）」 也就是**先有手势、再钉语义**。WebUI 2026-09-14 就有滑动翻页（用户当时 亲口提的），鸿蒙一直没有 ⇒ 之前建判据会是空真（∀x∈∅）。 ## 一、手势本体（两端语义逐项对齐，数值各自定） 按 `HARMONY-ALIGN-PLAN.md:118-128` 显式选的 **(b) 口径**： 「手势的物理量本来就不该强求同值……该对齐的是**语义层**」。 · 判定逻辑放**纯逻辑层** `model/Calendar.ts` 的 `judgeSwipe`（可被 node 直跑， 写在 .ets 里就跑不了判据，语义没法被单测钉住）。四道门：位移 / 纵向优先 / 快滑窗口 / 方向。 · 阈值**不引用** WebUI 的 40 / 1.5 / 600（那是把巧合当契约）， 各自定为 56vp / 1.4× / 700ms，并在注释里写出取值依据。 · 接线在 `CalendarPage.ets`：`PanGesture({direction: Horizontal})` + `onActionStart`（记时 —— `GestureEvent` **没有时间戳字段**，我查了 SDK 的 gesture.d.ts 确认）+ `onActionEnd`（读 offsetX/offsetY）。 · ★ 挂在**网格列**上而不是整页：右栏（日程/编辑器）里有输入框与可滚内容， 整页挂会让「在表单里横划一下」变成翻月。 · ★ 翻页复用 `shiftRange()`（与 ‹ › 按钮**同一个来源**）—— WebUI 的注释 专门交代过：各写一套的话，阈值、边界、三档行为迟早分叉。 手势回调里**不准**直接改 year/month（锚点是唯一真相，年月只能由 `shiftRange → syncYearMonthFrom` 派生）。 **有意差异（记录在案，不是漏做）**：WebUI 在周/日档会额外检查「触点是否落在 可横向滚动的区域里」，是则让给滚动条（用户 2026-09-14 报过这个冲突）。 鸿蒙周档是「一行 7 格按 layoutWeight 等分」、**不横滚** ⇒ 该条件不适用。 哪天加了横滚必须同时补上它。 ## 二、判据（8 条语义契约 + 行为层） 新增 `cross-client-gesture.test.mjs`：两端都真有手势 / 方向映射逐项相同 / 纵向优先 / 快滑窗口 / 复用同一翻页函数 / 无边界回弹 / 有意差异被记录 / 自检。 **只比语义、不比数值**，并反向断言鸿蒙的阈值常量不得直接取 WebUI 的那三个数。 `harmony-logic.test.mjs` 加行为判据：真跑 `judgeSwipe`，把四道门各自验一遍 （只钉字符串的话，一个 return 写漏了照样全绿）。 ## 三、顺手修掉的三处**判据基建**缺陷（不修就没法验证上面这些） 1. `run-all.mjs` 只认 `# pass N`，而 node v24 打的是 `ℹ pass N` ⇒ **21 个文件被记成"没自报条数"**、套件在 HEAD 就恒红（memory 里记过这条， 修法也记过，今天终于落进代码：4 个正则加 `(?:#|ℹ)`）。修完 `unreported` 27 → 0。 代价是暴露出一批此前被"没自报"掩盖的真实问题（下面 4~6 条）。 2. `harmony-nav` 的设备判据 `navItemsOf`：宽屏过滤条件从「左边缘靠左 1/6」 改成「**整个盒子在侧栏轨道内**」。旧条件把**日历网格的格子** （实测 `[229,511][366,794]`）也当成导航项，一屏数出 11~12 个。 这是设备实测抓出来的 —— 我第一版还以为是"底部簇混进来了"， 打印真实数据才发现是隔壁页面的格子。 3. `harmony-logic` 两处：从 `NAV_ITEMS` / `NAV_SIDEBAR_ITEMS` **各自的数组**里取 label。原先把全文件 `label:` 一网打尽 ⇒ 得到 7 个（4+3 混在一起）， 任何一边改对了它都会红。 ## 四、被判据拦住后的正经修法（每条都按判据自己给的方向改，不改判据迁就代码） · `cross-client-theme` A2 拦住我：新增的 `navActiveBg`/`navBrandFg`/`badgePlain` 未登记；又拦住我：`sseColorOf` 里四个裸色值。→ 抽成 `Theme.sseConnected` 等 四个令牌（取值对齐 WebUI 的 Tailwind 类）+ 登记 + 在 Theme.ets 的表里写理由。 · 同一条判据的"死令牌"检出：`Theme.durBase` 声明了却从没人读。 **查 WebUI 才发现壁纸淡入是真有的动效**（`index.css:742-752` 的 `.app-backdrop` 从 opacity:0 → 1，180ms）⇒ 补上而不是删令牌 （删掉等于把差异抹平、还说成"清理"）。reset 在 `animateTo` **外**， 与 `calPaneIn` 同一条纪律。 · 玻璃登记：`NavItemBuilder` → `SidebarItem`（重构后按最近的 @Builder 命名）， 登记同步跟上。 · `harmony-admin` 的退出判据：退出逻辑抽成 `api/Logout.ets` 的 `performLogout()` （两个入口——「我的」页与侧栏底簇——必须做同一件事，尤其"先注销推送 token" 那一步）。判据相应改成**追到实际执行处**（两半都断：按钮调了 + 函数真清了全部）， 并写明"别再退回直接匹配 SETTINGS_PAGE 的写法"（那会随重构假红， 下一个人只会去改判据而不看行为）。 · `harmony-widescreen` 的连接点色值：色值搬进 Theme 后，判据改成断 「令牌定义对了 + 侧栏真的用了它」两半（只断任一半都有假绿形态）。 · `align-refs`：`CalendarView.tsx` 变了，按判据要求**读一遍差异**再更新登记 （差异只有农历小字的灰阶档位 gray-300→gray-400/500，**骨架未变**）。 · `criteria-hygiene`：`harmony-contacts` 自造了一个 `code()`、`harmony-widescreen` 裸用 `readFileSync` ⇒ 都改用 `lib/read.mjs` 的共享入口。 途中撞出一个**判据自己的 bug**：`code()` 的块注释正则 `/\*[\s\S]*?\*\//` 会把注释里出现的 `/*`（如 `/」**` 这种中文夹星号） 当成块注释起点，一路吃到几十行后的 `*/`，把中间的 import 全吞掉 —— 于是 hygiene 判据假红"没 import"。改掉那处写法后正常。 ## 五、验证 判据面：`run-all.mjs` → `files=32 ran=32 checks=497 pass=497 fail=0 skip=0 red=0 broken=0 unreported=0`。 其中新/改判据：gesture 8、nav 18、widescreen 7、logic 30、admin 27、 cross-client-theme 15、criteria-hygiene 6。 构建：`hvigorw assembleHap` 成功；前端 `npm run build` + 重新打 AppImage/deb （`build-stamp` 7/7、`packaging` 5/5）。 **设备实测（HATriple 三折叠 3184×2232，hdc 连 127.0.0.1:5555）**： · 农历在格子里真的显示（1=二十 / 7=廿六 / 19=**初九** / 11=八月），与 WebUI 一致； 这条同时验证了**服务端农历路由已部署**（之前线上是 404）。 · 日历左右两栏：编辑器出现在**右栏**、左栏月份仍可见（单栏模式下编辑器会整页盖掉它）。 · 侧栏 3 项 + 底部一簇；徽标回到图标右上角。 **仍未验（如实标注）**：滑动翻页的**手感**（阈值 56vp/1.4×/700ms 是否合适） 只能真人滑过才知道；我只验了判定逻辑与接线形态。动画同理 —— 机制已验证（`animateTo` 驱动 + reset 在窗口外），但"看起来顺不顺"未做取样验证。 docs：`DEBTS.json` 销掉 `gesture-semantics`（并记结算说明）、 `HARMONY-ALIGN-PLAN.md` P6 从「✅（滑动翻页除外）」改为 ✅。	2026-09-19 14:01:21 +08:00
JianFeeeee	36ef15a8f2	跨端: 顶栏不再自己铺白条 + 日历改左右两栏 + 常驻窗格动画真的会播（用户三处实测指出） ... 用户三条反馈，逐条对应： ① 「底栏数字为什么显示在图标下面？」 WebUI 的徽标是 `absolute top-1 right-[22%]`（脱离文档流、浮在图标右上角）， 我写成了 `Column` 的第三个子节点 ⇒ 参与竖向布局、掉到文字下面。 改用 `Stack({ alignContent: Alignment.TopEnd })` 锚在**图标**上。 （顺带撞了 skill 里明写的坑：Stack 没有 `.justifyContent()`。） ② 「一个横着过去的白条，我真的服了」/「期望：融进背景」 WebUI 的顶栏**自身没有底色** —— 只有 `border-b border-gray-200` （`ContactPanel.tsx:64`、`CommTabs.tsx:40`、`CalendarView.tsx:295`）， 底色由所在面板给；壁纸开启时那层面板是玻璃色（`index.css:876`）。 鸿蒙三个窗格顶栏写死了 `Theme.surface`（实心白）⇒ 无论壁纸开没开， 顶上都是一条不通明白带。改成与**页面底**同一口径 （`bgActive ? Transparent : surface`）+ 补下边框。 ③ 「日历页面和webui布局完全不同」 WebUI 是**左右两栏**（`CalendarView.tsx:452-457`）：左 `flex-1` 网格、 右 `400px` 常驻面板（日程 / 编辑器 / 小时网格三态互斥）。 鸿蒙原来是**单栏竖堆**。重搭为两栏，`paneWide` 由 `.onAreaChange` 量本页**自己的**宽度（不是屏幕宽度 —— 宽屏下这一页已被侧栏占掉一截）； 编辑器改占右栏位置（不再整页盖掉正在看的那个月）。 ④ 「最严重的动画问题你一点也不该改」 日历是**常驻挂载**（`visibility` 控制，因为它里面 today 要随时间重算、 也要保住"正在看哪个月"），而 `.transition()` 只在**挂载/卸载**时触发 （SDK 原话 \"when it **appears and disappears**\"）⇒ 挂在它上面的 `.transition(paneRiseIn())` **一帧也不会播**，切过去是硬弹。 WebUI 踩过同一个坑并把错法写进了 `index.css:1305-1320` （「只挂了类，却没让触发窗口出现 ⇒ 类挂着、动画永远不播」）， 它的解法是 `html.view-switch` 重放窗口。ArkUI 对应物是 `animateTo` + 显式 `calPaneIn` 属性（`opacity` + `translate`）。 ★ reset 必须在 `animateTo` **外**：写进回调里会与同帧的 1 相抵， 渲染层只看得见最终值 ⇒ 动画退化成一个瞬移。 顺带修： · 宽屏侧栏 = 3 项（通信/日历/**联系**）+ 底部一簇（头像/主题/退出）， 与底栏的四项（含「我的」）**不是同一份清单** —— WebUI 的 Sidebar 与 NarrowNav 本就不同（`Sidebar.tsx:26-44` vs `NarrowNav.tsx:37-40`+143）。 新增 `NAV_SIDEBAR_ITEMS` / `ME_PANE_INDEX` / `SIDEBAR_ITEM_*`。 · 退出登录抽成 `api/Logout.ets` 的 `performLogout()`：侧栏底簇与「我的」页 两个入口必须做同一件事（尤其"先注销推送 token"那一步），复制一份就会不一致。 · 徽标 `'plain'` 档底色：WebUI 是石板灰 `--c-chrome-600`（#475569）， 我写成与未读共用红色 ⇒ 「联系」的徽标看起来像"有未读"。 · 主题快捷开关（侧栏底簇）：对齐 `ThemeToggleButton` —— 从 `system` 翻转时 落到**当前生效值的反面**（不是回 system；那可能毫无变化、让按钮看起来坏了）。 · 「浓度」→「压暗」+ 数值带单位（原先屏上印 `56.000000`；WebUI 是 `suffix="%"`）。 判据（8 个套件全绿：logic 28 / nav 18 / widescreen 7 / window 9 / arkts 5 / contacts 5 / calendar 30 / system-api 5）： · `harmony-widescreen` ② 重写：**回读 `Sidebar.tsx` 数 `short:` 的个数** 要求鸿蒙同数，并断言底部一簇三键真的被调用（`this.onToggleTheme()` —— 第一版写成 `/onToggleTheme/`，变异测试当场证明它不咬：属性**声明**还在， 正则照样匹上）。新增 ⑧：三档色调各自底色，期望值从 `--c-chrome-600` 读出。 · `harmony-nav` 动画条重写：改判**机制真的存在且被驱动** （旧断言 `.visibility(...).transition(...)` 锁的正是那个 bug —— 判据引自己写的注释当依据，就会把错误锁死）。新增 reset-在-animateTo-外 这条断言（否则动画退化成瞬移）。 · `harmony-nav` 设备条：`navItemsOf` 的宽屏过滤从"左边缘靠左 1/6" 改成"**整个盒子在侧栏轨道内**" —— 旧条件把日历网格的格子 （实测 `[229,511][366,794]`）也当成导航项，一屏数出 11~12 个。 新增 `navRailItemsOf`：导航轨贴顶、底部簇在屏底，按位置切一刀。 · `harmony-logic` 两处：从 `NAV_ITEMS` / `NAV_SIDEBAR_ITEMS` **各自的数组**里取 label —— 原先把全文件 `label:` 一网打尽， 得到 7 个（4+3 混在一起），任何一边改对了它都会红。 设备实测（HATriple 三折叠，3184×2232）：侧栏 3 项 + 底簇 / 底栏徽标回到 图标右上角 / 日历左右两栏与 WebUI 并排同构。 server/go.mod：补 2da38bb 漏提交的 lunar-go 依赖。	2026-09-19 12:30:05 +08:00
JianFeeeee	d8277a5977	跨端: 导航项徽标两侧补齐（我上次"撤回"错了 —— WebUI 是有的） ... 上一笔我凭"两侧导航都没有徽标"把刚写好的徽标**撤回**了。那是错的： `client/electron/src/components/Sidebar.tsx:88-95,111-125` 明确有—— ``` const badge = isComm ? unread + pendingPerms : modes.includes('contacts') ? contacts.length : 0; const badgeTone = isComm && pendingPerms > 0 ? 'perm' : isComm ? 'unread' : 'plain'; ``` 并且是 `absolute top-0.5 right-1` 压在导航项右上角，`>99` 显示 `99+`。 我当时只看了底栏 `NavItem`（那里确实没有），就把结论推到了"两侧都没有"。 ## 补的东西 - 新增**纯逻辑** `model/NavItems.ts` 的 `navBadgeCount` / `navBadgeTone` / `navBadgeText`， 逐条对齐 WebUI 的口径： · **通信** = 未读 + 待决策（两类"要动手"合起来）； · **联系人** = 联系人数；日历/「我的」= 0（没有徽标）； · 色调：待决策**橙**（有人卡在那儿等）优先于未读**红**（只是还没看）； · 负数当 0（计数来自网络，不假设它干净）；`>99` → `99+`。 - **两侧**（底栏 `MainPage.NavItem` + 宽屏 `WideSidebar.NavItemBuilder`）都接上， 且读**同一组** AppStorage 键 —— 两处各算一套，数字迟早对不上，而用户同时看得到它们。 - 计数发布走 `AppStorage`（单向：窗格写、导航栏读），与 `KEY_WINDOW_INSETS` 同一套机制。 不把这两个数提到 `MainPage`：那样"从没进过通信页"也会去发请求。 - 徽标位置对齐 WebUI 的 `absolute top-0.5 right-1`（压在项的右上角）。 ★ 第一版我排在文字**下面**，截图一眼可见那颗 3 掉到了「联系人」标签底下、 还把 48vp 的项撑高了 —— 方阵节奏乱掉。 ## 判据（harmony-widescreen 6 → 7） 第 ⑦ 条**直接执行**鸿蒙侧的纯函数，且期望值在测试里**独立算一遍** （不复用被测函数，否则是"用实现验实现"）。 ★ 接线部分我写错过一次，变异测试当场拆穿：第一版只判 `assert.match(src, /navBadgeCount\(/)` —— 把**渲染处**的调用换成 `0` （徽标永远不显示），文件里仍留着一处调用，判据照样全绿。 ⇒ 改成判**把值交给 Text 的那一行**，并且认出两侧写法不同（底栏走 helper `Text(this.navBadgeOf(key))`，侧栏就地内联 `Text(navBadgeText(navBadgeCount(...)))`）。 **4 个变异方向全咬**：通信漏算待决策 ⇒ 红；色调优先级写反 ⇒ 红； 侧栏渲染处换空 ⇒ 红；底栏渲染处换空 ⇒ 红。 设备实测：侧栏「联系人」显示红 **3**（3 个联系人），位置在图标右上角。	2026-09-18 13:30:38 +08:00
JianFeeeee	1832937016	docs: 日历那两处"未做"清单早已过期（写侧早就做完了） ... `CalendarPage` 的文件头写着「没做：新建/编辑/删除事件（**写侧**）、……**ics 导入导出**」， 而写侧当时**早就做完了**（`createEvent`/`updateEvent` 已接线、表单在 765 行起）。 `docs/HARMONY-ALIGN-PLAN.md` 的 P6 行同样标着 ⬜ 未做。 注释把已完成的说成未做，比漏写更糟：下一个读的人会去"实现"一个已经存在的东西。 本仓反复在消的"说的与做的不一致"这次落在文档/注释上（判据看不见注释， 只有人读的时候才会发现 —— 所以更该在每次真做完时顺手改）。 - `CalendarPage` 文件头：补上月/周/日三档、农历、写侧、.ics，并写明为什么还没有滑动翻页。 - `HARMONY-ALIGN-PLAN.md` P6：⬜ → ✅（滑动翻页除外），带三笔提交号（fbe7879 / 2da38bb / bcd7e7f） 与"鸿蒙无下载目录概念、DocumentViewPicker 是唯一路径"这条平台差异。	2026-09-18 13:19:06 +08:00
JianFeeeee	bcd7e7f217	跨端: 鸿蒙日历补 .ics 导入导出（WebUI 有、鸿蒙一直没有） ... WebUI 工具条那两个入口（`CalendarView` 的导入/导出图标）鸿蒙侧一直缺， `CalendarPage` 的文件头也一直诚实写着"没做：…….ics 导入导出"。 ## 为什么不能照抄 WebUI 的做法 WebUI 在浏览器里：导出是 `Blob` + `<a download>`、导入是 `<input type=file>`， 两条都由浏览器提供。鸿蒙**没有"下载目录"这个概念**，必须显式走系统 `DocumentViewPicker` —— 这不是多此一举，是这个平台上唯一能让用户拿到／指定文件的路。 新增 `common/IcsFile.ets` 封装选/读/写（`pickIcsText` / `saveIcsText`）。 ## ApiClient 加两个方法（不能复用 `request<T>`） `request<T>` 无条件 `JSON.parse(response.result)`，而 iCalendar 不是 JSON （与 `getBytes` 取壁纸二进制同一个理由）。所以： - `getText()`：`expectDataType: STRING` 取原文； - `postText()`：raw body + **显式** `Content-Type: text/calendar` —— 服务端是**按 Content-Type 分流**的（`strings.HasPrefix(ct, "multipart/")`， 否则当 raw text）。写错成 `application/json` 会走对分支但语义不对。 ## 三处对齐 WebUI 的细节 - **区间用屏幕上正在看的那段**（`rangeFrom/rangeTo`），不写死 ±1 年 —— 服务端注释里写着同一条理由：「写死 ±1 年会让人点导出后得到一堆与屏幕上不符的事件」。 - **文件名带日期**：`agentmail-<selectedIso>.ics`（WebUI 是 `agentmail-${dayKey(anchor)}.ics`）。固定名的问题是连导两次就分不清哪份是哪份， 而导出天然会被重复做（看一个月导一份）。实测截图里默认文件名 `agentmail-2026-09-18.ics`。 - **`imported` 与 `skipped` 两个数都报**：只说"导入成功"会把 "20 条里跳过了 18 条"读成一切正常，而"跳过"正是用户需要知道的那部分。 ## 结果要分三种说（取消不是失败） 导出成功（给出落盘路径）/ 用户取消（**什么都不说**）/ 真失败（说原因）。 把"取消"弹成"导出失败"是"用户什么也没做却被骂一句"。 导入成功后**重拉当前区间** —— 不重拉用户看不到刚导进来的东西，会以为失败。 ## 验证 - 服务端两端点实测（curl）：导出 8 个 VEVENT、Content-Type/Disposition 正确； 把导出的原样导回去 `{"imported":8,"skipped":0,"total":8}`。 - ★ 这次验证**污染了生产库**（那 8 条真写进去了）：已按 event_id 逐条删除 （47 → 39），删除前备份 `/tmp/db-before-cleanup.db`。 教训：拿生产实例做写侧验证要先想清楚怎么回滚 —— 我这次是先写后想。 - 设备侧：导出选择器实测打开（系统 filemanager 的 `PathPicker`）， 默认文件名正确、目录可选；选中保存后回到日历。	2026-09-18 12:55:46 +08:00
JianFeeeee	7b3028342a	跨端: 宽屏侧栏根本不像 WebUI —— 因为我上一版"复刻"的依据是编的 ... 用户：「你自己看看宽屏的侧边栏和webui有哪怕一丁点的相似之处嘛？」 并排截图（WebUI 1100×700 @2x vs 三折叠展开态 3184×2232）之后，差异一眼可见： | | WebUI | 鸿蒙（改前） | |---|---|---| | 文字标签 | **有**（通信/日历/联系） | 没有 | | 选中态 | **浅蓝底块** | 只换颜色 | | 「我的」 | 底部头像按钮进入 | 甩给 `onSettings` → **pushUrl 推页** | | 品牌标颜色 | `#475569` 石板灰 | 品牌蓝 | | 项间距 | 48px 项 + 4px gap，**贴顶一簇** | `layoutWeight(1)` 等分铺满（395px/项） | ## 根因：`WideSidebar` 里那段"复刻 WebUI"的注释是**编的** ``` * WebUI 的 `Sidebar`（60px 宽）是**纯图标轨**（无 label 文字）…… * 选中态：图标变色（`navFgActive`），**不加背景块、不加指示条、不加文字** * （用户 2026-09-16：「底部导航栏不允许有文字」⇒ 侧栏同样按纯图标走） ``` 两条都错，而且都能在源码里当场证伪： - `Sidebar.tsx:110` 明明有 `<span className="text-3xs leading-none">{short}</span>` —— 通信/日历/联系三个标签一直都在； - `index.css:1590` 的 `.nav-item[data-active='true'] { background-color: … }` 就是底块，而且 CSS 注释**专门**说了侧栏必须有它： 「宽屏侧栏是 48px 宽的竖条，图标底下那一块底色是它**唯一的选中线索**， 所以"只变色"不能无差别推广到所有 `.nav-item`。」 我犯的错是**把底栏那条纪律套到了侧栏上**：用户 2026-09-14 说「底部导航栏选中 对应的文字和图标变色即可」、2026-09-16 说「底部导航栏不允许有文字」—— 两句都针对**底部导航栏**，而侧栏是另一种东西（`index.css:1595-1606` 把这个区别 写得很清楚）。更糟的是我把这个错误**写进了判据**（`harmony-widescreen` ②③ 与 `harmony-nav` 的宽屏分支），于是判据锁住的是我编的理由，一路全绿。 ## 修 - 侧栏项 = **图标 + 文字标签 + 选中底块**（`navActiveBg` = `--nav-active-bg` #DBEAFE， 判据**直接读 WebUI 的 CSS** 取值，不写死、更不引自己的注释）。 - 品牌标：`navBrandFg` = `#475569`（**像素取证**：2x 截图里品牌标附近最常见的墨色 是 `rgb(71,85,105) ×206` = `--nav-fg-muted`，即中性石板灰，**不是**品牌蓝）； 尺寸/圆角按 WebUI `w-10 h-10 rounded-xl`（40×40、圆角 16）；点它回收件箱。 - 项**贴顶一簇**（`Column({ space: 4 })` = WebUI 的 `gap-1`），不再 `layoutWeight(1)`。 - 删掉单列的"设置"入口（`onSettings` 回调一并删除）—— 那正是用户 2026-09-17 报过的 「我的页面完全没有遵守 nav 的导航规则」（push 页 ⇒ 侧栏整条消失）。 「我的」由 `ForEach(NAV_CONTENT_ITEMS)` 覆盖（该常量**含第 4 项**， 走 `onSelect(3)` = 窗格，与底栏同一套）。 - 补避让：侧栏原先**完全没有** `topInset` ⇒ 全屏之后品牌标被状态栏时钟压住。 ## 判据（并修掉它们锁住的错误） - `harmony-widescreen` ②③ **重写**：从"纯图标 / 只变色"改成 "有文字标签 / 有选中底块 / 不许留 `onSettings`"，并读 WebUI `index.css` 拿真实色值。 - `harmony-nav` 宽屏分支：原来断言「侧栏项**不该有文字**」—— 同一条编造。 改成"图标（Path）画出来了 **且** 文字命中源码 `NAV_ITEMS`"。 - `harmony-nav` 宽屏形状阈值 `boxH > screenH*0.08` 是**错的**：48vp 项在密度 2.875 下 是 138px，而阈值要求 >178px ⇒ 四项全被滤掉（当时"通过"只是因为项被另一个 bug 压成了 39vp）。改成 `*0.04`，并补一条"必须有文字"把**品牌标**（40vp 无文字的可点方块） 排除在外。 **变异测试 3 个方向全咬**：去掉文字标签 ⇒ 红；去掉选中底块 ⇒ 红；Theme 色值写错 ⇒ 红。 ★ 顺带记一条**我差点犯的错**：我一度按 density 3.5 换算，算出"60vp 侧栏被压成 49.4vp"， 去查 flex 压缩、加 `.flexShrink(0)` —— 全是假的。实测密度是 **2.875** （`138px ÷ 48vp = 2.875`），侧栏 173px ÷ 2.875 = **60.2vp**，与声明完全一致。 **没有压缩，是我除错了。** 已撤回那笔改动并把口径写进注释。 harmony-widescreen 6/6、harmony-nav 18/18、harmony-window 9/9、harmony-arkts 5/5、 harmony-contacts 5/5、harmony-calendar 30/30、harmony-system-api 5/5、harmony-logic 28/28。	2026-09-18 12:52:48 +08:00
JianFeeeee	4ff6b10260	跨端: 联系人页补齐「写信 / 归档」—— 顺带撞出三个只在跑起来才现形的 bug ... 用户：「你自己看看这些页面和webui有哪怕一丁点的相似之处吗？」 把两个客户端**同一个宽度**并排看之后，缺的很具体：WebUI 联系人卡片有 「写信 / 归档」，鸿蒙一个都没有。补的过程撞出三个缺陷，都不是"代码不合法"—— 编译器与既有判据全绿： ## ① 归档打的是**服务端不存在**的路由（死函数） `MailApi.archiveContact` 打的是 `DELETE /me/contacts/{name}/{path}`： - `grep 'me/contacts' server/cmd/server/main.go` **零命中** ⇒ 按钮接上去就是 404； - 全仓**没有任何调用方** ⇒ 它是个从没跑过的死函数，所以"没有归档按钮"这件事 一直没暴露这个错。 服务端真实形状是 `POST /api/v1/contacts/archive`（`handler.ArchiveContact`）， body 二选一 `{session_id}` / `{address}`。**跟 WebUI 同口径用 session_id**： address 会随别名变化，只有 session_id 是会话的身份。 ## ② 用已存 token 恢复登录**永远进不去主界面**（最恶劣的一个） `LoginPage.tryRestore` 验完 token 就结束了 —— 设了 `loggedIn = true` （界面出现「登录成功：jianf」）却**从无跳转**。本文件另外两条成功路径 （`aboutToAppear` 快速路径、`doLogin` 末尾）都有跳转，唯独这条没有， 而它**恰恰是老用户最常走的那条**（重启时 token 还在，`doLogin` 根本不会被调用）。 症状最坏的地方是它**看起来是成功的**。实测（模拟器 + jianf 的永久 key）： 日志只有 `→ GET /auth/me` 然后什么都没有。补齐 ① 跳转 ② 账号登记 ③ SSE 连接（后两条是 `doLogin` 有而这里缺的，少了它们进主界面是个瘸的状态， 而且因为 `aboutToAppear` 的快速路径靠账号命中，下次启动还会重走这里 ⇒ 永远进不去）。 修后实测：启动即进主界面（可见文本变成「发件箱/授权/收件箱 · 2 组 · 50 封」）。 ## ③ 时间戳原样印出来 卡片直接印 `last_activity` ⇒ 屏上是 `2026-09-18T02:50:35.49065Z`。 WebUI 是 `09/18 10:50`（`toLocaleString('zh-CN', {month,day,hour,minute})`，**本地**时区）。 加 `MailGrouping.shortTimeOf`（走 `Date` 取本地字段；**不许 `.slice()`** —— 那是拿 UTC 的月/日当本地时刻，UTC+8 的 09-15 00:30 会显示成 09-14 16:30）。 实测：`112 封 · 09/18 10:50`，与 WebUI 逐字一致。 ## 补的界面（三折叠模拟器 3184px 展开态实测） - 两种视图**各一处**「写信 / 归档」（WebUI 两视图同语义），WebUI 用 `.reveal` 悬停显形，**鸿蒙不能照抄**：`index.css` 那段注释已经踩过这个坑 （触摸设备没 hover ⇒ 按钮透明却仍可点，一个看不见却按得动的破坏性按钮更糟）， WebUI 的修法是只在真支持悬停的设备上隐藏 ⇒ 鸿蒙这两个按钮**常显**。 - 归档先确认，**两视图共用同一个确认框**（WebUI 原话：换个视图就换套确认 UI 只会让人对「自己点了什么」更没底）；文案逐字一致。 - 列表视图的 meta 行原来放 `last_preview`，于是同一联系人在两视图里的关键信息 不一致 ⇒ 改成与卡片视图同源（`N 封 · 时间`）。 - ★ 一处只有跑起来才会发现的坑：列表视图的 ListItem 钉死 `.height(85)` + `clip(true)`，而确认框比 85 高 ⇒ **按钮被裁掉、点不了也退不出**。 确认态下高度交给内容自己定。 ## 判据（新增 harmony-contacts，5 条；4 个变异方向都跑过） 判的都是"按下去会发生什么"，不是"按钮在不在"： ① 归档打的是服务端真有的路由（同时钉住**没有**再用那条不存在的 DELETE —— 只钉前者的话， 加个平行实现也能全绿）；② 两视图各一处动作且去向正确；③ 确认框只有 1 个定义、 两视图都调它、文案逐字一致、确认态下点卡片不开会话；④ 时间戳走了格式化且 函数本身不走 slice；⑤ **切出 `tryRestore` 的函数体**判它自己含跳转 （只判全文件出现次数的话，另外两条路径里那两句就够让它变绿）。	2026-09-18 12:17:41 +08:00
JianFeeeee	0e5eec61bd	跨端: 登录页那个"emoji"是 Unicode 符号 —— 顺手修好图标贴左上角（共 4 处） ... 用户两条反馈，都是**看着界面**报出来的，而编译器与所有既有判据全绿： ①「为什么登陆页不是app图标，而是一个emojy？」 ②「你自己看看那个图标的位置正常吗？」 ## ① `Text('✉')` 被系统渲染成彩色 emoji 登录页的品牌标识原先写的是 `Text('✉')`（Unicode U+2709）。HarmonyOS 字体链里有 **彩色 emoji 字体**，U+2709 自带 emoji 字形 ⇒ 渲染成一枚黄白色风信封 emoji： - `.fontColor(Theme.accent)` 对彩色 emoji **无效**（界面显示的是 emoji 自带颜色）； - 与底栏/侧栏那些 `AmIcon` 线描图标不是同一套视觉语言； - 实测截图硬证：大屏下那枚 emoji 比旁边的文字还显眼。 而本仓**早就有** `ICON_PATHS.brandMark`（就是 App 图标上那个信封，专为品牌标识画的）。 换成 `AmIcon({ iconName: 'brandMark' })` 即可 —— 走 `Path.stroke()`，跟主题色走。 ## ② 图标贴在卡片左上角（量出来的） `AmIcon` 内部那个 `Stack` 是 `iconSize` 那么大、**默认靠左上**排版。调用方写 `AmIcon({…}).width(48).height(48)` 想要个大点的可上色盒子时，**外层盒子变大、图标不动**。 实测（三折叠 3.5 密度，`dumpLayout` 读的**实际 bounds**）： 卡片 [1523,521][1661,659] 138×138px 图标 [1526,524][1589,587] 63×63px ← 左边距/上边距都只有 3px ⇒ 图标中心偏 10vp **不是一处**：全仓扫出 4 个同样写法。修法是套一层 `Stack({ alignContent: Alignment.Center })`（仓里回复球与悬浮加号本来就是这么写的， 所以它们一直是对的）： | 位置 | 图标 | 盒子 | 原状态 | |---|---|---|---| | 登录页品牌卡 | brandMark 24 | 48×48 | 贴左上 ✗ | | 用户管理刷新键 | repeat 20 | 40×40 | 贴左上 ✗ | | 联系人视图切换 | cardView 18 | 40×40 | 贴左上 ✗ | | 收件箱组头箭头 | chevronRight 12 | 20 槽位 | 贴左 ✗ | | 回复球 / 悬浮加号 | chatBubble / compose | 56×56 | 本来就对（尺寸在外层 Button 上） | 修后实测：偏移 **−34.5px → 0.5px**（0.14vp，亚像素级）。 ## 判据（harmony-arkts 3 → 5 条） - **图标不许用 Unicode 符号充当**：扫 `Text('…')` 里单个符号的情况。 ★ 只框 U+2600–U+27BF / U+2B00–U+2BFF / U+FE0F，**刻意不含基本箭头段**（U+2190–U+21FF）—— `→` 在正文里是标点不是图标，框进来会误伤大量正常文案。 （我第一版把箭头段也框了，结果自检自己先红 —— 断言写错就是写错，不靠放宽它来「修」。） - **尺寸不许直接链在 `AmIcon` 上**：把"图标贴左上角"这个坑的**形状**钉住， 并自检"套了 `Stack` 的正确写法不许被误判"。 **两个变异方向都跑过**：放回 `Text('✉')` ⇒ 红 ✓；给 `AmIcon` 直接加 `.width(48)` ⇒ 红 ✓。	2026-09-18 11:47:51 +08:00
JianFeeeee	2da38bba83	农历走服务端端点：换算只在服务端做一次（两边各写一遍天文算法迟早差一天） ... 用户定的方案：「加 api 端点」。 ## 为什么不移植到 ArkTS `lunar-javascript` 的 `lunar.js` 有 **43 万字节**，内部是**日月位置的级数展开** （实测：全文件最大的数字字面量是 16KB 的系数数组，**不是**"某年到某年的月长表"）。 即"照搬一张小数据表"这条路**不存在** —— 移植等于在 ArkTS 里再实现一遍天文算法。 两份实现迟早会在某个闰月或某个朔日上差一天，而那种错**表现为日期错位、不是报错**， 界面上完全看不出（用户得自己去查日历才知道）。 所以：`GET /api/v1/calendar/lunar?from=&to=`（服务端 `internal/lunar`，同一作者的 lunar-go）。 ## 形状是「按日期键索引的映射」，不是数组 客户端拿到 `map[iso] -> 标签` 直接按格子键查，不用自己遍历比对。 `text` 字段是**格子里直接显示的那个串**（初一=月名、其余=日名）—— 由服务端定，两端同源。客户端各拼一份的话，同一天在两边日历上可能长得不一样 （例如闰月到底写不写「闰」）。 几个刻意的取舍： - **不设默认 from/to**：默认范围会让「我要 3 月」与「服务端以为我要这个月」悄悄不一致； - 入参只收 `YYYY-MM-DD`（**日期键**，不是 RFC3339）：农历是"这一天是农历几号"的 纯日期语义，混用时间戳会被时区挪一天； - 换不出来的日子**不进 map**（客户端查不到 ⇒ 那格不显示农历），而不是塞空对象 —— 空对象会让客户端以为"有农历、只是没内容"； - 区间上限 400 天（不是安全边界，是防客户端传十年前到十年后）。 ## 判据（`server/internal/handler/lunar_test.go`） 参照物是服务端的 `internal/lunar`（权威实现），**不抄一份答案表** —— 库升级时判据跟着走。 钉的点各自对着一个会静默出错的错法： - `Full` 与权威实现逐字一致（5 个日期，含春节、跨世纪、29 天月的边界年份）； - 日名表覆盖 1..30 且**五种前缀形态都在**（WebUI 那版漏过「二十」）； - ★ 初一显示**月名**、其余显示**日名**（与 WebUI `cellLunarLabel()` 同一口径）； - 闰月必须带「闰」字（不带的话闰六月与六月在格子里一样）； - 极端值（公元 1 年 / 1900 / 2100 / 9999）**不许 panic**，且换出来时文字里不许含 「无效/NaN」这类失败标记。 ★ 最后一条我第一版**写错了**：断言「`time.Time{}` 应当换不出来」，实测库**换得出来** （0001-01-01 → 「〇年冬月十八」）—— 我断言的是自己的想象而不是实际行为。 改成断言真正的契约（不 panic / 失败就不给 / 给了就得是真结果）后才对。 ## 客户端 `LunarLabels` / `LunarRangeResponse` 两个模型 + `CalendarApi.listLunar(fromIso, toIso)`； `CalendarPage` 在 `loadEvents()` 之后**不 await** 地拉农历（附加信息不该拖慢事件列表）， 失败**不算 `this.error`**（否则"农历服务抖一下"会变成"整个日历打不开"）， 只写 hilog 留痕。区间按**网格**取（不只本月 —— 月视图首尾显示上/下月格子）。	2026-09-18 11:23:12 +08:00
JianFeeeee	fbe7879981	跨端: 鸿蒙日历补「月/周/日」三档 —— 原来只有月视图 ... 用户列的缺失之一（WebUI `CalendarView.tsx` 的 `type Scale = 'month'|'week'|'day'`）。 鸿蒙这边 `CalendarPage.ets` 自己的注释里就写着"没做"。 ## 三处必须一起改，所以档位进 model 而不是页面里一串 if 档位切换同时改变三件事，任一漏改都**不报错、只是静静地不对**： | | 月 | 周 | 日 | |---|---|---|---| | 标题 | `2026年9月` | 跨月时两头写月份 `9.28 – 10.4` | `2026年9月18日 周五` | | 翻页步长 | ±1 **月** | ±7 天 | ±1 天 | | 显示格子 | 整月网格 | 一行 7 天 | 一行、只亮一格 | 所以 `model/Calendar.ts`（纯逻辑，node 直接跑）新增： `CalendarScale` / `addDaysIso` / `weekDaysOf` / `rangeTitleOf` / `stepDaysOf` / `scaleLabel`。 页面只调用，不在渲染里重写 —— 重写就是"三处里漏改一处"。 ★ 步长按档走是**必须**的：周档按 1 天翻看起来像日档、日档按 7 天翻会跳过一周， 两者都不报错。判据钉"三档步长两两不同"。 ★ 周/日档的 7 天必须与月网格用**同一个** `weekStart`：不一致的话同一日期在两档下列位置 不同，用户看到的是"切个视图日期就跳位了"。 ★ 日档的格子仍摆在一行的**星期列**里（不是居中大字）：上下翻日时格子不会在屏幕上跳。 ## 实现要点 - 档位状态叫 `calScale` 而**不是** `scale` —— ArkUI 的 `CustomComponent` 已有 `scale` 修饰符，同名直接编译失败（实测报 `Property 'scale' ... is not assignable to ...`）。 判据钉住这个命名。 - 周/日档下 `year/month` 由锚点 `selectedIso` 推出来（`syncYearMonthFrom`）， 不允许两处各自保存"当前是几月" —— 否则会出现"标题写 9 月、周视图显示 10 月那周"。 - `monthKey()` 加上**档位**前缀：切档时那 7 个 iso 就是月网格里的 7 个， 不带档位的话键完全重叠 ⇒ 一个节点都不被替换 ⇒ 过渡静默不播、旧 `inMonth` 残留。 - 空态补 `layoutWeight(1)`：实测周视图下"这一天没有日程"贴顶、**下半屏是一大片空壁纸**。 ## 判据（harmony-calendar 23 → 30 条） 7 条新增，每条对着一个具体错法。**变异自检跑过两个方向**： - 周档步长改成 1（看起来像日档）⇒ 判红 ✓ - 跨月周标题漏掉结束月份（`9.28 – 4`）⇒ 判红 ✓ ## 实测（模拟器，逐档截图） 月/周/日三档切换后：周档标题 `2026年9月14–20日` + 一行 14~20，日档标题 `2026年9月18日 周五` + 只亮 18，月档回到整月网格。三张截图逐一核过。	2026-09-18 11:08:05 +08:00
JianFeeeee	af2d2b5cad	跨端: 鸿蒙动画补齐 —— 并且发现原来的「逐字一致」是假的（令牌存在 ≠ 动画用了它） ... 用户：「A，同时把鸿蒙app的动画补齐」。 ## 先纠一条错的前提（这是本轮最有价值的发现） `Theme.ets` 的注释与 `harmony-nav` 的判据**都**写着：「三个数与 WebUI **逐字一致**： `--ease-out-soft: cubic-bezier(0.22,1,0.36,1)`、`--dur-fast: 120ms`、`--dur-base: 180ms`」， `paneRiseIn()` 就按 `durBase(180)` + `easeOutSoft` 做。 三个令牌**确实存在**（`index.css:310-312`）—— 但这句话把「令牌存在」当成了「动画用了它」： | WebUI 里 | 真实用途 | |---|---| | `--dur-base: 180ms` | **只**用在壁纸淡入（`:747`） | | `--ease-out-soft (0.22,1,0.36,1)` | **只**用在 transition（壁纸、控件变色） | | **所有 @keyframes 动画** | 硬编码 **150ms / 200ms** + `cubic-bezier(0.22, 0.61, 0.36, 1)` | 全仓 `(0.22,0.61,0.36,1)` 出现 **5 次**（rise-in×3 / cal-in×2），`(0.22,1,0.36,1)` 只出现 **1 次**（令牌定义处）。**是两根不同的曲线** —— 旧代码的面板入场比 WebUI 慢 30ms 且曲线偏软。 所以令牌拆成两组，各对齐各的：控件类 `durFast + easeOutSoft`；动画类 `durRise(150)/durMenu(140)/durCal(200) + easeRise(0.22,0.61,0.36,1)`。 ## 补的动画（对齐 WebUI 三个 @keyframes） - `menuIn()` —— 弹层：下移 4vp + 缩到 0.985 + 淡入（`@keyframes menu-in`）。 ★ 适用范围照搬 WebUI 注释那条窄口径（「只给真正是弹层的东西」）：那条规则曾挂着 `glass-control`，于是每次切视图**所有按钮与输入框一起淡入位移**，09-15 被摘掉。 挂到写邮件页的账号候选列表上。 - `calendarSlide(forward)` —— 日历翻月：从 ±12% 横向滑入（`cal-in-next/prev`）。 方向由新增 `@State slideForward` 带进 `animateTo` 闭包；网格键加 `monthKey()` 前缀 保证月份一变所有键全变（否则"跨年同名月"那类边角会静默不播）。 - 写信页整页 `rise-in`、回复框 `rise-in`（WebUI 挂在回复框本身，不是外层遮罩 —— 挂遮罩上会让整个屏幕一起位移，看起来是"页面在动"而不是"框弹出来"）。 **实测确认真的会播**（不是"编译过了"）：按本仓记录的手法把 `durCal` 临时改成 8000 做慢动作，连拍三帧 —— 截图硬证**两张月历同时在屏**（九月淡出、十月从右侧 12% 滑入）， 验完还原成 200ms。 ## 判据：从「令牌存在」改成「动画真的用了那个令牌」 `harmony-nav` 那条判据原文锚在令牌上，所以它对上面那个 bug **一辈子全绿**。 重写为： - 从 WebUI `index.css` **读出** `rise-in` 的真实时长与曲线（`150ms` + 那条 bezier）， 再断言鸿蒙的 `durRise` 与曲线字面量与之逐字一致 —— 而不是"仓库里有没有 180 这个数"； - ★ 把 `paneRiseIn()` 的**函数体抠出来**单独断言它引的是 `durRise/easeRise`， 且**不得出现** `durBase/easeOutSoft`。 **这一步不能省 —— 我第一版就漏了它**：断言了令牌存在、也断言了曲线字面量存在， 但没断言函数用了它们；于是把函数体换回旧的错值后判据**仍然全绿**。 变异自检抓住了这一点，补上函数体断言后同一个变异 ⇒ 判红 ✓。 与今天修的另一处同源：**判据要锚在"这个东西被用在哪"，不是"它存在"**。	2026-09-18 10:56:57 +08:00
JianFeeeee	a87a88ea2a	跨端: 全屏是**窗口级**的 —— 光给 MainPage 让位，等于把黑边换成顶栏压字 ... 上一提交（cac026e）把黑边消掉了，但**只给 `MainPage` 加了避让**。 实测截图硬证：写邮件页的「取消」与时钟「09:49」重叠、「发送」与 wifi/电量图标重叠。 ## 根因：`setWindowLayoutFullScreen(true)` 不只作用于当前页 它是**窗口级**的：一旦设上，这个窗口里**所有**用 `router.pushUrl` 推上来的页 （写邮件/会话/收件箱/邮件详情/用户管理）都从 y=0 开始画。 所以上次那个错与更早那次（6861934 只删全屏不留避让）**同源**： 都是"同一件事只做了一半"。上次少的是**步骤**，这次少的是**页面**。 ## 改法：把"消费避让"变成每个 @Entry 页都得做的事 - `model/WindowInsets.ts` 加 `topInset(insets)`：取 0 时（未全屏/取不到） 表达式的值与旧代码**逐字相同** ⇒ 没全屏的环境行为不变，不会把谁顶下去。 - 五个页各按自己的形状让位： - 固定 56vp 顶栏（写邮件/会话/收件箱/用户管理）： `height(56 + topInset(...))` **与** `padding(… top: topInset(...))` 一起加 —— 只加 padding 会把固定的 56 切掉 39（按钮压扁），只加 height 则内容仍贴 y=0。 - 满高容器（邮件详情）：`padding({ top })` 加在 `@Entry` 包装层。 ★ **不能加在 `MailDetailView` 里面**：它同时被 `MainPage` 的 Navigation 内嵌复用， 而那层已经让过位了 —— 加在里面就变成让两次（39vp 变 78vp）。 这类"同一组件两种入口"的坑与"悬浮加号要放在 Navigation 内部"同源： **让位的量取决于它被挂在哪一层**。 ## 判据（harmony-window 8 → 9 条） 接线⑤ 枚举**所有** `@Entry` 页并要求它们消费避让 —— 口径是 "有人在窗口上开了全屏 ⇒ 每个 @Entry 页都得让"，而不是"检查 MainPage 做了没有"。 后者在新增一个推上来的页时会静默逃掉，而"新增一个页"正是最常发生的事。 豁免要带**可机器复核**的理由（不再是"这个页先不管"）： - `Index.ets`：DevEco 模板欢迎页，不在 `main_pages.json` 流程里； - `LoginPage.ets`：根容器 `.align(Alignment.Center)` ⇒ 结构上碰不到 y=0。 但"居中"是可能被改掉的性质 ⇒ 判据**断言那个居中写法仍然存在**， 谁把它改成贴顶，这条先红，逼他回来重新想这个页要不要避让。 **变异自检两个方向都跑过**： - 把 ComposePage 避让整个拿掉（重演"只给 MainPage 加"）⇒ 红 ✓ - 只加 padding 不加 height（会压扁按钮）⇒ 红 ✓ ★ 期间还修掉两处"判据锚在当时的字符串上"（不是放宽，是它把"加一个正当的避让" 与"真犯那个错"判得一模一样）： - `harmony-nav` ④ 的留白断言、`harmony-widescreen` ④ 的 navReserve 断言， 都改成剥注释后验**形状与不变量**，而不是写死字面表达式。改完变异仍咬得住。	2026-09-18 10:34:00 +08:00