|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
cac026e9e2
|
跨端: 上下黑边真的消了 —— 全屏 + 避让是"同一套东西的两半"，上次只删了一半
用户第三次报同一条：「你再看看页面底部，那么大的黑色，你看从头到尾都没
修好，你能不能好好看看我给你的示例工程怎么处理上下黑边的」。
## 根因：上一次把"两半"当成了"一件事"，删掉一半就以为修好了
`6861934` 的注释白纸黑字写着「★ **刻意不用** `setWindowLayoutFullScreen(true)`」，
理由是「实测过：它确实也消掉黑带，但会连状态栏区域一起吃进布局，于是页签栏
被时钟/电量盖住（截图硬证「07:43」与「收件箱」重叠）」。
那次实测**是真的**，结论**下错了**：被盖住不是"不该全屏"，而是
**只做了全屏、没做避让**。示例工程里这两件事本来就是**同一套东西的两半**：
common/.../util/WindowUtil.ets → setWindowLayoutFullScreen(true)
+ getWindowAvoidArea(TYPE_SYSTEM /
TYPE_NAVIGATION_INDICATOR)
features/mine/.../view/MineView.ets:251 → .margin({ top: statusBarHeight + …,
bottom: naviIndicatorHeight })
只做前半 ⇒ 内容跑到状态栏底下没人让（那次退回的原因）；
只做后半 ⇒ 黑边照旧（这三次报修的原因）。退回的代价是**黑边留了三天**。
## 实测（模拟器 1256x2760，四页一致）
修前：顶部纯黑 136px、底部纯黑 60px + 手势条 20px
修后：四页**纯黑段均为 0**；y=0..135 是壁纸（时钟浮在上面，正是示例工程的效果）
y=2662+ 壁纸铺到底、底栏浮在手势区之上
## 改了什么
- `entryability/EntryAbility.ets`：拆出 `setupFullScreenWindow()`，
在 `loadContent` **回调里**调（与示例工程同一位置 —— `px2vp` 要用 `getUIContext()`，
那要有已加载内容才拿得到）。全屏 + 读两个避让区 + 订 `avoidAreaChange`。
`setWindowSystemBarEnable(['status'])` 保留（状态栏要看得见），但**不再靠它**消黑边。
- `model/WindowInsets.ts`（新）：纯逻辑 `insetsFromAvoidArea()`，不 import SDK ——
判据才能在 node 里直接喂样本验换算。形参叫 `toVp` 而**不是** `px2vp`：
后者是 SDK 已废弃的全局函数名，`harmony-system-api` 按名字扫，同名形参会误报。
- `pages/MainPage.ets`：`@StorageLink(KEY_WINDOW_INSETS)` 订阅；状态栏高度当
**内容层**的 `padding-top`（**不是**根 Stack —— 壁纸必须铺到屏幕四边，根上加
padding 会把壁纸一起缩进去，黑边只是换个地方出现）；底栏与内容末尾让开手势条。
reserve 收成**一个** `recomputeNavReserve()`，宽度变化与避让变化两个触发点共用
（转屏只改避让不改宽度，各写一份迟早漏一个）。
## 判据：`test/harmony-window.test.mjs`（8 条）
钉的是"两半必须同时存在"——**只钉一半的话，"退回某一半"照样能全绿通过**，
而那次退回恰恰就是删了一半。纯逻辑 3 条（换算/取不到就是 0 不猜/键名是常量）
+ 接线 4 条（全屏在、避让在、布局真消费了值、纯逻辑模块不许 import SDK）
+ 设备行为 1 条（全屏没把应用搞成白屏）。
**变异自检两个方向都跑过**（这是本轮最该记的一步）：
- 删掉 `setWindowLayoutFullScreen`（重演 6861934）⇒ 2 条红 ✓
- 删掉 `getWindowAvoidArea`（只全屏不让位）⇒ 1 条红 ✓
★ 第一版判据**锚错了**：正则直接扫全文，而注释里正好有 `setWindowLayoutFullScreen(true)`
这个串 —— 把真正的调用删掉后判据**仍然全绿**。锚落在"代码对自己的描述"上了。
加 `stripped()` 剥注释后，变异才咬得住。这条与仓里那条"判据的锚不能落在
被守对象的自述上"是同一件事，这次是它的实例。
## 顺带修的两条既有判据（不是放宽，是它们把"当时的字符串"当成了"要守的坑"）
- `harmony-nav` ④：留白断言写死了 `bottom: NAV_BAR_BOTTOM` 那个字面串。
它本来要守的是"留白靠 padding 不靠 margin"（margin 在 ArkUI 里加在宽度外面，
100% + margin 会顶出父容器）—— 那是另一件事。改成剥注释后验三段在不在、
离底是否**从** `NAV_BAR_BOTTOM` **起**。变异（padding→margin）仍判红 ✓
- `harmony-widescreen` ④：同上，写死了 `? 0 : NAV_CONTENT_RESERVE`。
改成"宽屏必为 0、窄屏含 NAV_CONTENT_RESERVE（可再加避让）"。
两处都是"加一个正当的避让"与"真犯那个错"会红得一模一样 —— 那就不再是守坑，
是守字符串。
另：`align-refs` / `build-stamp` / `packaging` 三条 broken 是前端 `99a2d7a`
（另一个人改的 `CalendarView.tsx`）带来的，与本轮无关，留给他。
|
2026-09-18 09:47:22 +08:00 |
|
|
|
2166f0ed81
|
fix(harmony): 补齐窗格切换动画（transition 挂在会换的那棵子树上）
用户（2026-09-17）：「一方面一点动画都没有」。
★ 第一版写错了，这里记下来 —— 它的错法很典型，下次还会踩：
只在 onClick 里把 `currentIndex = ...` 包了一层 `getUIContext().animateTo(...)`，
并把 `.transition(...)` 挂在**内容容器（稳定父节点）**上。
编译过、判据（当时只钉"有 animateTo"）全绿，**但动画是静默失效的**：
`animateTo` 只负责开一个动画窗口，被换掉的子树自己不声明 transition 就什么都不会动；
而挂 transition 的那个 Column 在新旧两种状态下**都是同一个节点**，永远不会触发。
实测取证：把时长临时改成 20s，6 秒后截图仍是硬切（收件箱整版清晰、没有叠影）。
修法（对齐 WebUI `.pane-rise` / `.rise-in`，`index.css:1208`）：
· `Theme.paneRiseIn()` —— 4vp 上浮 + 淡入；`riseInOffset = 4` 与
`@keyframes rise-in { from { opacity:0; transform: translateY(4px) } }` 逐字一致。
· 挂到**if/else 各自的子树根**上（CommPage / ContactsTab / SettingsPane，
以及常驻+visibility 的日历那一支）—— 这才是会被插入/移除的节点。
· `TransitionEffect.asymmetric`：入场 180ms（durBase）、出场 120ms（durFast）。
出场更快是刻意的：同长会让新旧两层半透明地叠着，看起来像"闪一下"，
而用户对"闪"敏感（09-14 否掉过整屏淡入）。
· 续用令牌 `durFast=120` / `durBase=180` / `easeOutSoft=cubic-bezier(0.22,1,0.36,1)`。
判据（219 passed / 0 failed）：
· 新增「窗格切换有真的过场动画」6 条：令牌数值逐个钉死（120 / 180 /
cubic-bezier(0.22,1,0.36,1)）；`transition` 必须挂在 if/else 分支根（≥2 处，
含日历那一支）；必须 asymmetric。
· **变异自检**：删掉那 4 处 `.transition(...)` ⇒ 该条立刻变红；还原 ⇒ 全绿。
留给以后的坑（写进 Theme 注释）：`snapshot_display` 单次往返约 1s，
180ms 的过渡**抓不到**（连拍三帧像素级一致，会得出"动画没做"的错误结论）。
要取证就得把时长临时调到 20s 再取样，验完还原。本文件注释里留了这条与那次实测值。
未验：真机手感（模拟器已确认过渡链路生效）；出场动画与详情 push 的叠加观感。
|
2026-09-17 21:33:15 +08:00 |
|
|
|
686193458a
|
fix(harmony): 底栏黑带 / 联系人点不开 / 我的页不守导航 / 顶栏硬截断
用户（2026-09-17）连报五条：「一点动画都没有」「底部那个黑条是啥意思」
「日历页面、我的页面、联系人页面哪个跟 webui 对齐了」「联系人页面连点都点不开」
「你的顶栏为什么还是硬截断而不是渐变」。逐条查证后修：
── ① 底部黑条 = 系统导航栏区域，不是我们画的 ──
根因：窗口默认给系统导航条留位，那块在深色下是黑的；界面于是看起来底下多一条黑带。
修法：`setWindowSystemBarEnable(['status'])` 隐藏系统导航条（底部那条本就是我们自绘的
悬浮玻璃条），内容铺满全高。
★ 刻意**不用** `setWindowLayoutFullScreen(true)`：实测试过，它也能消掉黑带，但会连
状态栏区域一起吃进布局，页签栏被时钟/电量盖住（截图硬证「07:43」与「收件箱」重叠）。
── ② 联系人点不开（用户原话「连点都点不开」）──
根因：`ContactItem` / `WorkCard` **根本没有 onClick** —— 卡片画出来了，
但没有任何点击路径。当时判据只钉了"字段与 WebUI 一致"，没钉"点了会发生什么"。
修法：点卡片打开那条会话的邮件列表，就地在**本窗格内**展示（新增 `SessionMailsView`
＋ `GET /sessions/{id}/mails`），底部导航保留；每封可再点进详情。
── ③ 我的页不遵守导航规则 ──
根因：点底栏「我的」走 `pushUrl('pages/SettingsPage')` 推**独立 @Entry 页** ⇒
底部导航整条消失，要按返回才能再切窗格。WebUI 里 `account` 只是一个 `viewMode`，
与收件箱同级、导航常驻。
修法：`SettingsPage` → `SettingsPane`（去掉 @Entry 与返回键，从 main_pages.json 摘除），
作为**第 4 个内容窗格**挂到 `currentIndex === 3`；`NAV_CONTENT_COUNT` 3 → 4，
`NAV_ITEMS` 第 4 项去掉 `route`；拨动动画包 `getUIContext().animateTo`。
实测：`我的` 页底部导航可见，可滚到「退出登录」「管理」。
── ④ 顶栏硬截断 ──
根因：`Scroll` 与 `List` 都能挂 `fadingEdge`（同在 `ScrollableCommonMethod` 上），
但**只有 MainPage 的 List 挂了** —— MailDetailPage / CalendarPage / SettingsPage /
AdminUsersPage / SessionsPage / InboxPage 的滚动容器全漏。同一次滚动里
列表是渐隐、正文是硬切，看起来就是"顶栏没做渐变"。
修法：13 个容器全部补齐（LoginPage 例外：它的 Scroll 是整页根、不是列表，
写了理由）。实测：视口上沿被切断的文字最暗 170–196，而下方不透明正文是 **19**。
── ⑤ 一点动画都没有 ──
实测确认改造前全仓 `animateTo` / `transition` / `animation` **一次都没用过**。
补：Theme 加令牌（durFast 120 / durBase 180 / easeOutSoft = cubic-bezier(0.22,1,0.36,1)，
与 WebUI `--dur-*`/`--ease-out-soft` 同值同曲线）；切窗格包 `animateTo`；
导航项选中变色加 `.animation`。
判据（218 passed / 0 failed）：
· 新增「渐隐覆盖**所有**页面滚动容器」：按文件枚举 + 计数配平，
并自检扫到的容器总数（防正则写坏 ⇒ 全绿）。**这条一写就抓到 LoginPage**。
· ①/②/⑤ 与 headless 那几条按新事实改写：内容窗格 3→4、
`normalizeNavIndex(3)` 归一到自己、导航项里**禁止**再出现 `pushUrl`
（那正是导航消失的形状）。
· 修掉自己引入的两处判据缺陷：`itemCode` 未定义；以及一条**窗口式断言**
（从内容层 `}` 往后扫，靠数花括号定界，而注释里就有大量 `.padding({`，
切片长到 1700+ 字符一路扫进 `onAreaChange` ⇒ 假红），改为纯负向断言。
未验：真机观感；横屏 Auto Split 双栏；日历页深度对齐（本轮只补了渐隐）。
|
2026-09-17 21:15:11 +08:00 |
|
|
|
0bced9fcff
|
跨端: fix(推送客户端) 更正我上一笔的注释：session_id 不是"只写不读"，GET 会回给客户端
上一笔 `9404f98` 的代码是对的，但注释里我写了一句**过度概括**：
"服务端对这个字段不做格式校验、而且当前**只写不读**"
后半句错了。`GET /api/v1/me/devices/push-token` 把这个字段**原样回给客户端**：
server/internal/handler/push.go:148 "session_id": t.SessionID,
更正为准确的三条（各自都能复核）：
1. 服务端不做格式校验（只 `TrimSpace`、允许为空）⇒ 所以不 400、不影响收信、不进日志；
2. 但 GET 会回给客户端 ⇒ 假值**是可见的**，且 `isRegistered` 的比对口径
（只按 `provider + token_tail`，见 PushContract.ts 那段说明）恰好不看它 ——
两件事合起来意味着：**没有任何机制会因为这个字段错了而报警**；
3. 投递暂不受影响：发通知用的是**邮件自己的** `session_id`
（`notify/mail.go:266` 构造 `push.NewMail{SessionID: m.SessionID}`），
`dispatch` 只用 token 的 `Provider`/`Token`（`push.go:155`）。
⇒ 结论不变但理由更准：**这个字段存在的唯一目的就是"点通知回到那条会话"，
而它存的值是错的**；"不会立刻炸"正是它该先修的原因。
写这条注释时我把"投递不读它"顺手写成了"没人读它"——**"不参与这条路径"与"没有读取方"
不是同一件事**，与这两天反复出现的形状同族（把"我没看到"读成"不存在"）。
|
2026-09-17 19:40:00 +08:00 |
|
|
|
9404f98bde
|
跨端: fix(推送客户端) session_id 传的是**服务器地址** —— 一个"不报错"的假数据
这条不是别人报的 bug，是我自己在做上一封收尾时写下的，今天读自己的代码才发现。
## 错在哪
`reportToken` 里：
const sessionId: string = this.account.getActiveAccount() === null
? ''
: this.account.getActiveAccount()!.server; ← AccountInfo.server = **服务器地址**
`AccountInfo.server` 的值长这样：`https://mail.jianfgit.xyz/api/v1`。
而服务端对这个字段的语义是「客户端**当前所在的会话**：点通知要回到那条会话里的那封信」
（`server/internal/handler/push.go`），类型上是会话 UUID（`push_tokens.session_id`）。
## ★ 为什么它能一路活到今天：因为它**不报错**
两件事叠在一起，让它完全无声：
1. 服务端对这个字段**不做格式校验**（只 `TrimSpace`，并且明确允许为空）；
2. 服务端当前**只写不读** —— 投递时用的是**邮件自己的** `n.SessionID`
（`notify/mail.go` 构造 `push.NewMail{SessionID: m.SessionID}`），
`dispatch` 只用 `Provider`/`Token` 两个字段。
⇒ 它不会 400、不会影响收信、不会出现在任何日志里，
只会在 `push_tokens` 里静静存一条**假的**会话 id。
等哪天真按这个字段路由（它存在的**唯一目的**就是那个），
人会莫名其妙被送到别的会话去 —— 而那时没人会想到根因在这个字段。
**"不会立刻炸"正是这类错最危险的地方：它不报错，它让数据开始说谎。**
## 修法：如实传空，不编一个
这一步的时机**决定了它必然为空**：`reportToken` 只在**登录成功**与**换账号**时跑，
那时用户还没打开任何会话；客户端也**根本没有"当前会话"这个状态**可读
（我确认过：`MainPage` 不记当前会话，全仓没有 `currentSession` 之类的东西）。
而服务端对这个字段**明确允许空**："客户端还没进任何会话，此时通知只带 mail_id"。
⇒ **传空是准确的，传 URL 是错的。** 等客户端真有了"当前会话"，再回来补真实 id。
## 判据（19 → 20 条）
新增「session_id 不许拿服务器地址顶替」，钉的是**值的来源**而不是"有没有传"，
所以既能挡住"再塞个别的字段顶替"，也不妨碍将来补报真实 id（那时这条要改成钉真实 id）。
变异验证两个方向都做了：
- 还原成原 bug（传 `.server`）⇒ `not ok 9` 红；
- 换成 `.username` 顶替（换汤不换药）⇒ 同样红；
- 恢复 ⇒ 20/20 绿，文件逐字还原。
编译侧反向对照照旧：在新代码那行植入必然类型错误 ⇒
`ArkTS Compiler Error: Type 'number' is not assignable to type 'string'.
At File: …/PushService.ets:255:11` ⇒ `BUILD FAILED`（证明这个模块真被编译，
不是"改了没接线所以通过"）。
真机：装新包后行为不变仍是静默失败（`push token 取不到（静默，属正常）：Illegal application identity.`），
`jscrash`/`FaultLogger` 计数 0 ⇒ 这个修复没有改变失败路径的形状，只改了不再写假数据。
|
2026-09-17 19:38:15 +08:00 |
|
|
|
549836193d
|
跨端: fix(推送客户端) 热启点通知**不跳转** —— 真机实测逼出来的那半（只写格子没人读）
这是"收尾"里**静态判据看不出来**的那一类，只有设备能抓住。
## 实测经过（模拟器，可复核）
只写 `PendingRoute` 的那版（上一个提交 423ff9f）：
aa force-stop → aa start --ps data '{…open_mail…}' ⇒ render MailDetailDestination ✓ 冷启能跳
（应用已在运行）aa start --ps data '{…open_mail…}' ⇒ **0 次** ✗ 热启不跳
根因：冷启时页面**刚挂载**，`aboutToAppear` 会读那个静态格子；
热启时页面**早就挂载完**了、`aboutToAppear` 不会重跑 ⇒ 格子写得进去、**没人读**。
症状正是"点了通知，App 弹到前台，停在列表页" —— 而这恰恰是推送**最常见**的用法
（App 在后台，用户点通知回来看那封信）。
## 修法：补"事件发生时就交出去"的那条路
`PushService.deliverRoute(route)`：**有人监听就当场交出去，没人监听才留在格子里**。
两条路都要留着，因为两种启动各走一条（冷启没人监听、热启有人监听）：
- `EntryAbility.onCreate` / `onNewWant` 都走 `deliverRoute`（两条启动方式共用一条投递路径）；
- `CommPage.aboutToAppear` 注册监听、`aboutToDisappear` 摘除
（不摘会叫醒已销毁的页面）；
- 冷启与热启**共用同一个落点** `navigateToRoute`（各写一遍必然漏改一处）。
不用页面生命周期兜（`onPageShow` 之类）：那会在"用户手动返回列表"时反复触发跳转，
而这里要的是"事件发生的那一刻"。
## 验证
真机（模拟器，装新包后实测）：
- 热启 ⇒ `render current custom node: MailDetailDestination` ✓（修之前 0 次）
- 冷启回归 ⇒ 仍然 1 次 ✓（没被这次改动破坏）
- 截图硬证：详情页（返回箭头 + 详情窗格）；"加载失败"是我塞的假 mail_id
（`WARM456`）的**正确**后果 —— 说明确实带着那个 id 去取了
判据：`harmony-push.test.mjs` 18 → 19 条，新增「接线④：热启要能跳」，
**变异验证过两个方向**（deliverRoute 退回"只写格子" ⇒ 红；删掉监听器注册 ⇒ 红）。
它单独存在的理由：接线③那种"有人读"的检查**会放它过去** ——
`aboutToAppear` 里读 pendingRoute 完全满足③，而热启路径是死的。
|
2026-09-17 19:08:27 +08:00 |
|
|
|
423ff9fbb2
|
跨端: feat(推送客户端) 收尾两处接线（pi 邮件 66bbd929 分工）+ 换账号补报
`PushService.ets` 与 `pendingRoute` 都早就写好了，但**没人调用/没人读** ——
而"写好了"与"接上了"是两件事：ArkTS 只编译可达模块，往一个无人 import 的
文件里放必然报错的类型错误，`assembleHap` 照样 BUILD SUCCESSFUL
（pi 与我各复现过一个方向）。这次补的是**边**，不是点。
① 登录成功补报（LoginPage）：`EntryAbility.onCreate` 那次在**登录之前**跑，
那时 `ApiClient` 还没有 token ⇒ 服务端 401，而 `reportToken` 的失败是静默的
⇒ "启动时报过"不等于"这个账号登记过"。补三条登录路径，一条都不能漏：
快速路径（已有账号直接进主界面，老用户走这条）/ tryRestore / doLogin。
② 换账号补报（SettingsPage.switchTo，**我加的第三处**）：服务端语义是同一
token 换账号**转移**而非并存 ⇒ 新账号其实没登记过。幂等标记按
`accountKey|token` 存，所以这里调一次必然重发，不会被"我报过"挡掉。
不补的症状：切完账号，通知仍推给上一个账号。
③ pendingRoute 消费端（MainPage.CommPage）：`EntryAbility` 已把通知 data
解析成 `pendingRoute`（冷启 onCreate / 热启 onNewWant 都写了），
**但没有任何东西读它** ⇒ 点通知只拉起 App、停在列表页。
在 CommPage 消费（详情页是这个 Navigation 的 navPathStack 上的路由，
栈只有它持有），消费后**立刻清空**（它是"待处理"不是"当前页"，
不清则返回列表再进来会被反复跳走）。
判据：`harmony-push.test.mjs` 15 → 18 条，三条新判据钉的就是上面这三条边，
**三条都做了变异验证**（各自删掉对应接线即红、恢复即绿）。
`LoginPage` 那条数**恰好 3 处**调用：少了快速路径＝老用户永远不补报，
多了要问清是哪条路径。
编译验证（不是"命令成功"，是"它真读了这个文件"）：三处改动各植入一次必然
类型错误 ⇒ BUILD FAILED 且 `At File:` 指到**新代码那一行**（MainPage:1173 /
LoginPage:108 / SettingsPage:456），恢复后 BUILD SUCCESSFUL。
产物侧证：`modules.abc` 里能查到 `consumePendingRoute`(2) / `reportPushToken`(2)。
|
2026-09-17 19:03:14 +08:00 |
|
|
|
2e53871a22
|
fix(harmony): 底栏真正浮起 + 内容穿过 + 加回文字标签
用户（2026-09-17）：「底栏不是玻璃质感，滑动内容无法穿过底栏」，
随后「还是在导航栏加上文字吧，没有文字还是不好看」。
── ① 底栏没浮起：`width('100%') + margin` 在 ArkUI 里不缩宽 ──
NavBar 原来是 `Row().width('100%').margin({left:16,right:16,bottom:12})`。
ArkUI 的 margin 加在宽度**外面**：100% 再配左右 margin 不会缩到
「100% − margin」，而是整个顶出父容器、两侧被裁。
实测底栏左缘 x=0、右缘贴满 1256（应各留 16vp=56px）⇒ 看起来是贴边通栏，
不是浮在壁纸上的胶囊。这与收件箱头卡片修过的是同一个坑。
改法：外层 Column 带 padding（与 WebUI `.narrow-nav` 的 margin 同一几何）。
实测修复后左缘 x=56 = **16.1vp**（期望 16）。
── ② 内容穿不过去：让位加错了层 ──
原来把 `NAV_CONTENT_RESERVE` 加在**窗格的 `padding({bottom})`** 上。
那不只"让最后一行滚得出来"，还**缩短了窗格本身** ⇒ 内容永远到不了条底下
⇒ 玻璃条背后只剩一张已经被壁纸层模糊过的壁纸 ⇒ 系统材质无东西可糊
⇒ 看起来就是一块普通浅色面板。**这就是"不是玻璃质感"的真正原因**。
改法：窗格满高（内容滑得到条底下，真正穿过），让位改到各滚动容器的
**内容末尾** `contentEndOffset(this.navReserve)`（5 个 List + 日历日程），
与 WebUI 同构（`.narrow-shell` 是 flex-col，列表满高、`.narrow-nav` 叠在上面）。
实测：条内高频细节 0.21 vs 条外正文 6.04 ⇒ **28.8×** 衰减，模糊确实生效。
连带修：FAB / 回复球原来靠窗格 padding 躲开条，现在自己按 navReserve 抬
（否则压在条上），实测 FAB 底距条顶 24.4vp。
── ③ 加回文字：并纠正一处**事实错误** ──
代码注释里写着「WebUI 的底部导航是**纯图标**」，并据此去掉了文字。
那句是**错的**：`NarrowNav.tsx:83-86` 每个导航项是
`flex flex-col items-center justify-center gap-0.5`，里面先 `<Icon />`
再 `<span className="text-3xs leading-none">{short}</span>`
—— WebUI **一直有文字**（通信 / 日历 / 联系人 / 我的）。
那条判据把一个假事实固化成了规则，还反过来挡住了正确做法。
现在按真实契约钉：图标（24vp，与 WebUI 24×24 同几何）+ 文字，
两者过**同一个**选中三元式（只换颜色，不加背景/指示条）。
判据（全部含变异自检）：
· ⑤ 重写：两处选中三元式（图标+文字各一）、必须有 Text(item.label)、
图标 24vp；变异自检覆盖"缺文字 / 文字不换色 / 图标不上色"。
· ④ 改：留白走外层 padding（并反向禁止 margin 做留白）；
让位改为 ≥5 处 `contentEndOffset`，并禁止退回窗格 padding 让位。
· 连带更新 ②/⑤ 与 appearance/logic/widescreen 的组件签名断言
（组件多接一个 navReserve）。
· 删掉一段会假红的"从内容层 `}` 往后扫"的窗口式断言：它靠数花括号定界，
而注释里就有大量 `.padding({` 字面量，切片能长到 1700+ 字符，
一路扫进 `onAreaChange`（那里合法地出现 NAV_CONTENT_RESERVE）——
正是本仓库反复记的窗口式判据，故改为纯负向断言。
测试：212 passed / 0 failed；`devecocli build` 通过；
模拟器截图与像素测量逐项核对。
|
2026-09-17 18:44:36 +08:00 |
|
|
|
c523c21e22
|
feat(harmony): 邮件详情与「我的」页 1:1 对齐 WebUI，并修两个线上 bug
用户：「为什么邮件页面没有对齐 webui？」「我的页面也没有对齐」，
选定「完全 1:1」。两个页面都不是「没做」，而是**做了一半** ——
`AuthApi` 的 logout/listKeys/createKey/revokeKey 全都写好但没人调，
`Models.ets` 的字段声明漏了服务端一直在返回的那些。
── 邮件详情页（对齐 WebUI `MailView.Header` / `CollapsibleHeader`）──
· 头部改**可折叠**（默认收起）：收起只留标题 + 必须常驻的状态点
（未读 / 权限请求）+ 箭头。WebUI 的理由：顶部信息常驻会把可读区压成
一条缝（实测 1280×800 下头部 17% + 回复框 31%，正文只剩 48%）。
· 发件/收件改**三段式完整地址**：Agent → `pi@/home/program/agentmail.别名`，
人 → 只有名字。新增 `model/ReplyTarget.ts`（逐字移植 WebUI `replyTarget.ts`，
并对齐后端 `models.FormatAddress`）。
· 时间：`localDateTime()` → `2026/09/15 11:37:07`（原为裸 ISO `2026-09-15T03:37:07.14758Z`）。
· 档位：`permissionLabel()` → `只读/目录内/全权`（原为英文 `plan/workspace/full`；
这个函数早就在 `MailGrouping.ts` 里、列表页也在用，只有详情页没用）。
· 新增抄送行；回复入口改**右下悬浮球**（WebUI `reply-fab`），
不再是底部 56vp 通栏按钮。
── 「我的」页（对齐 WebUI `AccountPage`，补 5 个缺失 section）──
标题由「账号管理」改为「我的」（多账号只是其中一段，不是整页的目的）。
· 基本资料：用户名/显示名/角色/状态/创建时间/最后登录。
· 权限范围：可调用 Agent / 可访问目录（非管理员；空数组 = 不限）。
· 修改密码：三输入框 + 不一致就地提示（新增 `AuthApi.changePassword`，
该端点服务端一直有、客户端从未包）。
· 客户端连接密钥：列表 / 新建 / 吊销 + 一次性全文提示
（`AuthApi` 的三个方法终于被调用）。
· 退出登录：先注销推送 token → 清凭证 → **清全部账号** → 回登录页。
· 整页改为**一个 Scroll**：原来账号列表 `layoutWeight(1)` 占满剩余高度，
排在它后面的 section 被挤出可视区且滚不到（WebUI 注释里正是这个坑），
而「退出登录」在最下面 ⇒ 等于退不出去。
── 顺带修掉的两个线上 bug（都是判据发现的）──
① `MeApi.get()` 调 `GET /me`，但服务端**没有**这个路由（只有 `/auth/me`；
`/me/*` 下是 mail/sessions/keys/appearance 子资源）。
后果：这把调用恒 404 → `loadRole()` 恒走 catch → `isAdmin` 恒 false
→ 「管理」入口对**包括管理员在内**的所有人永远不显示。
实证：`GET /api/v1/me` → 404；`GET /api/v1/auth/me` → 200
`{"user":{"role":"admin",...}}`。修复后截图里「管理」入口已出现。
② 详情页回复写 `req.to = this.fromName + '@'`：那个游离的 `@` 让 `name@`
被后端 `ParseAddress` 解析成「有 path、无 session」⇒ 落到该 Agent 的
**默认会话**，而不是用户正在看的那条线索。改用 `replyTargetAddress()`。
── 判据（新增 7 + 8 条，全部含变异自检）──
· `harmony-reply-target.test.mjs`（新）：直接执行 `ReplyTarget.ts` 断言行为
—— 空 path 必须留 `@`（否则整串被当成名字、投递 404）、人只有名字、
会话位必须带上、`from_workspace` 不得用来拼地址（会得到 `dsh@dsh`）；
并读 Go 源码比对三分支结构。
· `harmony-admin.test.mjs`（+5）：`/auth/me` 路径（含服务端注册与响应形状）、
八个 section 齐全、退出清全部账号、整页一个滚动容器、字段来自服务端。
变异自检：把 `/auth/me` 改回 `/me` → 判据变红（已验证）。
测试：212 passed / 0 failed；`devecocli build` 通过；
模拟器截图逐项核对（详情收起/展开两态、我的页全部 section）。
未验：真机观感；横屏 Auto Split 双栏。
|
2026-09-17 17:43:03 +08:00 |
|
|
|
65c3ef8094
|
fix(harmony): 悬浮加号移进 Navigation 列表侧，修详情页叠按钮
症状（2026-09-17 模拟器截图硬证）：窄屏 Stack 模式点开邮件详情，右下角**同时**
出现两个圆形按钮 —— 详情自己的「回复」（蓝色胶囊）与外壳的 compose 加号，
后者悬空压在详情上。
根因：加号原先是 `Navigation` 的**兄弟**，平级放在外层 Stack 里。
详情画在 `Navigation` 内部，而兄弟节点画在 `Navigation` 之上 ⇒ 永远压住详情。
WebUI 的对应物是 `.comm-pane`（`App.tsx`: `{listBody}<ComposeFab />`）：
加号在**列表窗格内部**，窄屏滑上来的详情层把列表整块（含加号）盖住，
详情自己的回复按钮才露得出来。Split 模式下加号仍在左栏，与 WebUI 两栏并排一致。
改法：把 `Stack({ alignContent: BottomEnd }) { 列表; 加号 }` 整体放进
`Navigation(this.navPathStack) { ... }` 的构建体内；通信页根的
`bgActive ? Transparent : pageBg` 保留（判据要求 ≥5 处让出页面底）。
判据（harmony-nav.test.mjs 新增一条，含变异自检）：
- compose 加号必须在 `Navigation(...)` 的花括号**内**；
- `.navDestination(...)` 之后不得再出现 compose 加号。
用 `git show HEAD:...MainPage.ets`（改动前版本）复核：两条断言在 bug 版本上
**都失败**（inside=False / after=True），说明判据抓的正是这个层级错位，
不是"存在一个 compose 按钮"那种在 bug 版本上也成立的弱断言。
实测（模拟器 1256×2760）：详情页只剩自己的「回复」按钮，加号不再悬空；
截图 /tmp/harmony-fabfix4.jpeg。列表页加号位置不变（仍在右下角）。
测试：200 passed / 0 failed。
|
2026-09-17 16:52:34 +08:00 |
|
|
|
fc3fff4f36
|
fix(harmony): 滚动列表上下边缘渐隐，替掉硬截断
用户（2026-09-17）：「上下还是硬截断，不是 webui 那种渐变」。
WebUI 的做法是 `index.css` 给 `.overflow-y-auto` 加
`mask-image: linear-gradient(to bottom, transparent 0, #000 min(12px,10%), ...)`。
ArkUI 的对应物是滚动容器自带的 `fadingEdge(enabled, { fadingEdgeLength })`
（API 14+，定义在 `ScrollableCommonMethod` 上 ⇒ List/Scroll/Grid/WaterFlow 都有），
它淡掉的是**渲染结果本身**，与背景无关。
**刻意不用** linearGradient + mask 手搓渐变色遮罩：那是拿背景色画一个
并不存在的"底色"，在壁纸/玻璃主题下必然露馅（壁纸本身带颜色，遮罩层对不上）。
- 新增 `LIST_FADE_LENGTH = 12`（NavItems.ts）：与 WebUI 的 `min(12px, 10%)`
同量级，也接近列表内边距（10vp）—— 静止时几乎看不出，滚动时才起作用。
- MainPage 的 5 个列表容器（收件箱/发件箱/授权/联系人卡片/联系人列表）
全部挂 `.fadingEdge(true, { fadingEdgeLength: LengthMetrics.vp(LIST_FADE_LENGTH) })`。
显式传长度而不是用默认 32vp：WebUI 那边踩过同一个坑
（「渐变用的过猛了，比如收件人候选那里」——固定像素用在高度不固定的容器上）。
判据（harmony-nav.test.mjs 新增一条）：常量值、五个列表都挂、长度走
LengthMetrics.vp、禁止 linearGradient+mask 顶替；并做了变异自检
（删掉任一处 fadingEdge 必须判红，实测通过）。
实测（模拟器 1256×2760，密度 3.489）：
- 滚动后顶边被切断的卡片文字明显洗白（红色评分 5.5 vs 完整卡片 15.5）；
- 底边同样渐隐；截图 /tmp/harmony-fade-scroll.jpeg。
测试：199 passed / 0 failed。
|
2026-09-17 16:44:17 +08:00 |
|
|
|
ff75339baa
|
fix(harmony): 图标按 px→vp 正确缩放 + 底栏四入口 + 卡片 10vp 缩进
图标过小的根因（实图硬证）：`Path.commands` 的坐标按 **px** 解释，不是 vp。
- `Shape.viewPort` 只裁剪不缩放（官方样例"缩放成立"是因为它用 Rect/Circle
自带 vp 宽高，不是裸 Path.commands）；
- 改动前的 `Path.scale({iconSize/24})` 对 iconSize=24 等于 1.0，同样没缩放。
症状：FAB 内 compose 只画 24px（应 24vp=84px），且偏在盒子左上角。
修法：`scale({vp2px(iconSize)/24})` 把 24 单位路径放大到 iconSize vp；
`scale` 会连带放大描边，故 `strokeWidth = strokeWeight / vp2px(1)` 抵消，
否则 1.8vp 描边会变成 ~7.3vp 的"实心块"（实图已验证）。
用 `this.getUIContext().vp2px()` 而非全局 `vp2px`——后者已废弃，
`harmony-system-api` 判据对全局调用默认判红。
验收（模拟器实图，密度 3.489）：
- FAB 内 compose 图标 84px = 24vp ✓（原 24px）
- 底栏图标描边 7-8px ≈ 1.8/24×28vp=7.3px ✓（原为实心块）
- 四个图标均为清晰描边，与 WebUI icons.tsx 同几何
底栏四入口：新增"我的"（person → pages/SettingsPage），对齐 WebUI
通信/日历/联系人/我的；NAV_CONTENT_ITEMS 保持宽屏侧栏三项，
避免宽屏出现重复 person 图标。
卡片缩进：`width('100%') + margin({left:10,right:10})` 在 ArkUI 里不会
缩到 90%——margin 加在宽度外面，卡片顶出父容器（实测左缘只留 ~1px，
列表卡才有正确 10vp）。改为外层容器加 padding。验收：页头卡与邮件卡
左缘同为 x=35（10.0vp）、右缘 x=1219。
推送：reportToken 先申请通知权限再取 token（部分设备权限未开时
getToken 返回空 / 报 1600004），并补两条文件形状判据钉住
client_id 配置与调用顺序。
测试：198 passed / 0 failed。
|
2026-09-17 16:27:27 +08:00 |
|
|
|
a5f680a147
|
harmony(ui): 登录页 1:1 对齐 WebUI 卡片规格 + 通信页改用系统 Navigation Auto
登录页（LoginPage.ets）：对照 WebUI LoginPage.tsx 同规格重写 build()
- maxWidth 380vp 居中卡片（与 WebUI 380px 同档）
- 14vp 圆角（Theme.glassRadius）
- 48vp 品牌图标（Envelope 浅蓝底 accentSoft）
- 显式字段标签（服务器/用户名/密码/用户密钥）
- 40vp 输入框与登录按钮（WebUI 控件同高）
- 分段式登录方式切换（账号密码 / 用户密钥）
- 窄屏安全边距 16vp + Scroll 可滚
通信页（MainPage.ets CommPage）：改用鸿蒙系统 Navigation 组件
- Navigation(navPathStack) 包住列表，navDestination 注册邮件详情目标页
- mode(NavigationMode.Auto)：phone 自动 Stack、tablet/2in1 自动 Split
- navBarWidth(320) 对齐 WebUI MailList 320px；navBarWidthRange([280,360])
- minContentWidth(360) 参与 Auto 断点计算
- Inbox/Sent 选中邮件改走 navPathStack.pushPath，不再 router.pushUrl
- 切收件箱/发件箱/授权时清空详情栈避免跨栏残留
详情页（MailDetailPage.ets）：抽出可复用 MailDetailView
- 既有详情实现导出为 @Component struct MailDetailView
- 新增 initialMailId/initialAccountId/embedded/onBack 输入
- 无 initialMailId 时才读路由参数（兼容旧 router 入口）
- embedded=true 时返回走 onBack 回调（NavPathStack.pop）
- 薄壳 @Entry MailDetailPage 用 Column 包裹（@Entry 根节点须容器）
module.json5：deviceTypes 扩展为 phone/tablet/2in1 三形态
判据：harmony-widescreen.test.mjs 新增 ⑥ 钉住 Navigation Auto 不许退回手搓分栏
验证：ArkTS 编译通过；harmony-arkts/widescreen/nav/cross-client-theme 35/35 通过
|
2026-09-17 10:58:31 +08:00 |
|
|
|
f44b15684b
|
fix(push): 通知开关默认改开（修正误解「可配置项=默认关」致 token 从不上报）
★ 功能性硬伤修复：用户实测「新邮件根本没有通知」。
根因：我上一版把 PushService.isEnabled 默认设成关（读不到即 false），
误解了「接入系统通知是可配置项」的本意 —— 用户要的是「服务端没配凭证时
客户端优雅降级」（enabled:false 是正常态，不报错不阻塞），不是「默认关掉
推送功能」。结果 reportToken 最前 gate 直接 return，device token 从未上报，
DB 里 0 个 token，NotifyNewMail 在 len(tokens)==0 时静默返回 ⇒ 永远发不出。
修正：
- PushContract.DEFAULT_PUSH_ENABLED: false → true（契约层默认开）
- PushService.isEnabled: getSync 默认值用 DEFAULT_PUSH_ENABLED（true），
catch 也返回 true —— 只有用户显式关才不上报
- 判据同步：harmony-push-optin ①② 改默认开口径
验证（服务端→HMS 链路实打已通）：
- OAuth access_token 取得（app_secret 有效）
- POST /v1/{appId}/messages:send + test_message 调通，
HMS 回 80300007 "All tokens are invalid"（假 token 无效，但凭证/形状/认证全被接受）
⇒ 只要 DB 有真实 device token 就能送达（token 由客户端上报）
|
2026-09-16 08:29:24 +08:00 |
|
|
|
6cd64a4384
|
ke: 玻璃面板（系统材质）：WideSidebar bgActive 走 BlurStyle，撤回手写 alpha
遵守既有玻璃纪律（cross-client-theme B/C）：
- 手写 8 位半透明色一律禁止（半透明归系统材质），撤回 #E6FFFFFF 尝试
- 玻璃 = 系统 BlurStyle(navMaterial) + 不透明系统色 surface，半透明由 BlurStyle 给
- WideSidebar 加 @Prop bgActive：bgActive 时 backgroundBlurStyle，否则 NONE
- 内容面板只保留几何（radius/clip/padding/gap），不加材质（判据按 @Builder 解析
owner 会与 NavBar 撞 key；壁纸从面板缝隙露出已达成 app-shell 观感）
- GLASS_REGISTRY 登记 WideSidebar#NavItemBuilder（判据按最近 @Builder 命名）
|
2026-09-16 08:06:36 +08:00 |
|
|
|
31fdc1a3d8
|
ke: 宽屏 app-shell 几何落地：padding/gap 10 + 面板圆角 14（WebUI 一比一）
- MainPage 宽屏 Row({ space: Theme.paneGap }) —— gap 10（窄屏无子间距，无害）
- 内容面板 borderRadius(isWide ? glassRadius : 0) + clip(isWide) —— 圆角 14 仅宽屏
- 容器 padding 条件：宽屏 paneGap 10（壁纸从缝隙露出）/ 窄屏 0（贴合全屏）
- Theme.glassRadius=14 / paneGap=10 已在上一提交引入，这里真正用上
- 判据：harmony-widescreen ⑤ 钉 app-shell 几何（令牌值/space/radius/clip/padding 与 WebUI 同值）
|
2026-09-16 07:58:13 +08:00 |
|
|
|
fd4b475920
|
ke: 鸿蒙导航纯图标 + 图标加大 + 玻璃几何令牌
用户反馈：① 图标太小 ② 底部导航栏不允许有文字。
- NavItem（底部导航）：去掉 Text(item.label) 纯图标，AmIcon 22→28vp
- WideSidebar（宽屏侧栏）：去掉 label 文字（WebUI Sidebar 本就是 60px 纯图标轨），
导航图标 22→26vp、品牌标 26→30vp；NavItemBuilder 去掉 label 参数
- Theme：新增 glassRadius=14 / paneGap=10（与 WebUI app-shell CSS 变量同值，
用于宽屏玻璃面板几何；原有 radiusCard 保持系统跟随不动）
- 判据同步：harmony-nav ⑤ 改纯图标（1 处三元式 + 无文字 + 28vp）+ 变异自检三项；
harmony-widescreen ③ 同样改纯图标（1 处 + 无文字 + 26vp）
|
2026-09-16 07:54:44 +08:00 |
|
|
|
cfe7808af4
|
ke: 鸿蒙 UI 整改：emoji→AmIcon 图标、宽屏侧栏、Md 第三方库、通知可配置项
- common/Icons.ets（生成器产出）：43 枚与 WebUI icons.tsx 同几何的 Path 图标
- NavItems.ts：icon(emoji) → iconKey，与 WebUI 导航同图标
- 全页面 emoji 清除（空态改单行灰字，按钮/头像/刷新等换 AmIcon）
- MailDetailPage 接入 @luvi/lv-markdown-in（第三方，替代手写解析器）
- WideSidebar + MainPage isWide(≥768vp)：宽屏侧栏 60vp 图标轨、藏底部条、onAreaChange 断点
- 通知=可配置项（默认关）：PushService.isEnabled/setEnabled + reportToken 最前 gate （关=不取token/不弹权限/不打网关）+ SettingsPage Toggle + 服务端通道状态提示
- EntryAbility.onCreate 解析 want：冷启点通知也能路由（原来只有 onNewWant）
- 判据：harmony-widescreen(4) + harmony-push-optin(4) 新增；harmony-nav 同步 iconKey/条件 padding
|
2026-09-16 07:46:52 +08:00 |
|
|
|
9c6e9c66ad
|
跨端: 修复: 鸿蒙客户端"连不上服务器"—— 地址补 /api/v1 + 失败分类成人话（含网络白名单固化）
症状
鸿蒙客户端（client/harmony）连不上服务端，界面只显示"无法连接"，用户无法自助；
而服务端 HTTPS 完全正常：https://mail.jianfgit.xyz/health → 200、
/api/v1/auth/me → 401、/api/v1/events/stream → 401（Let's Encrypt *.jianfgit.xyz，
TLS 校验通过；代理与直连 http://127.0.0.1:8180 行为一致）。
根因（两条，逐条核实过，其中一条**推翻了原判断**）
① apiBase 是"API 前缀本身"（ApiClient 里拼的是 '/auth/login' 这类相对路径），
而 Ui 只做 trim+去尾斜杠：用户若只填 `https://mail.jianfgit.xyz/`，请求就打到
`https://mail.jianfgit.xyz/auth/login` ⇒ 404，客户端再把它压成"无法连接"。
**这是本次故障最可能的直接原因。**
② 默认值 `http://192.168.2.60:8180/api/v1` 是明文 + 写死内网 IP：手机不在同网段
就永远不通（mail.jianfgit.xyz 解析到的就是这台内网机）。
★ 但"鸿蒙默认禁止明文 HTTP"这条**不成立**，已按本机离线官方文档核实：
`devecocli docs read .../使用HTTP访问网络/http-request` 的《明文HTTP访问权限配置说明》
写明 cleartextTrafficPermitted "默认为 true"，Network Kit 默认允许明文；
另有 FAQ《Stage模型如何配置支持http明文传输》："无需配置，支持HTTP明文传输数据"。
⇒ network_config.json 按"显式固化意图"处理（照文档形状写对，但**不冒充**它是修复）。
本机 SDK @ohos.net.http.d.ts 里确实有 2300997 Cleartext traffic not permitted（since 18），
所以那条错误码在客户端被建成一条可读提示，而不是被忽略。
改法
· 新增 model/ApiBase.ts（纯逻辑，无 @ohos，判据能用 node 直接跑）：
normalizeApiBase（去尾斜杠**但不咬协议 //**、末尾没有 /api/v1 就补、已有的一字不动）、
validateApiBase（自带修法的中文提示 + "公网明文才告警、内网明文不误报"）、
describeFailure（404 自己写文案并点名 /api/v1；其它状态码让服务端文案说话；
网络层按 2300006/2300007/2300028/2300997/2300998/2300058-60-77 分类成人话）。
· Config.ets：DEFAULT_API_BASE → https://mail.jianfgit.xyz/api/v1。
· ApiClient.ets：setBase/init **都**过 normalizeApiBase（唯一闸口 ⇒ 老装机里已经存下的
坏地址在读回时就治好，光改默认值救不了它）；ApiError 带 nativeCode；错误路径改走
describeFailure；404 的提示指向"地址少了 /api/v1"。
· LoginPage.ets：地址先校验后持久化（不合法**不落库**、给可执行提示），明文警告常驻渲染；
SettingsPage.ets：添加账号同样校验（多账号库直接喂 SseService，坏地址会让该账号的实时
通道永久连不上）；AccountManager/SseService 落库与建连时各自再归一化一次。
· 新增 resources/base/profile/network_config.json：按官方文档形状把内网明文
（192.168.2.60 / 10.0.2.2 / localhost）显式列进 domain-config 白名单。
文档给的就是这个**固定路径与文件名**，不需要在 module.json5 里写引用
（仓库里既有的 HomeAgent 工程同样是这么放的）。
· 新增判据 test/harmony-apibase.test.mjs（13 条）并接进 run-all.mjs 的 SUITE：
值判据**直接跑** model/ApiBase.ts；.ets 那几条是**静态**接线判据（本机无设备）。
验证（都真跑过）
· cd client/harmony && devecocli build clean && devecocli build
→ BUILD SUCCESSFUL in 7 s 186 ms；entry/build/default/outputs/default/entry-default-signed.hap
存在（1214592 B，15:14）。
· 解包 HAP：resources/base/profile/network_config.json 在包里、JSON 可解析、
cleartextTrafficPermitted=true 且白名单含 192.168.2.60/10.0.2.2/localhost；
bundleName 仍是 com.jianf.agentmail，module.json 没有多余的 metadata/securityConfiguration。
· devecocli check lint → 0 error；我改过的文件**零发现**（总工性从 8 降到 7，
顺带修掉 LoginPage 一条既有的 await-thenable）。
· node --experimental-strip-types --no-warnings --test test/harmony-apibase.test.mjs
→ ℹ tests 13 / pass 13 / fail 0。
· 变异验证 11/11 全红且**红在对应那条**（在 /tmp 的独立 worktree 里做的，不碰共享树）：
归一化不补后缀、去斜杠咬掉协议、404 用通用文案、401 拿通用文案顶掉服务端原因、
网络码不再分类、默认地址退回明文内网、setBase 直接赋值、登录页去掉守卫、
内网白名单关掉明文、出现第二处自己拼 /api/v1、守卫变成空壳。
（M8 第一次是**假绿**——只判了方法声明、没判调用点；改成切出 doLogin 方法体后再判才红。）
未验到（别把"编译过了"读成"连通了"）
· **没有**在真机/模拟器上点过一次登录：本机当前无设备在线，所以"真的连上了服务端"
这件事本轮**未被验证**；已验证的只是"地址会被补成带 /api/v1 的形态""构建产物正确"。
· network_config.json 的**实际效果**未验：按官方文档明文默认就允许，这份文件是显式固化，
没有做"关掉它再对比"的实验（也无法在无设备时做）。
· DNS/超时/证书这几条分类的文案是按 SDK 错误码写的，**没有构造真人故障去实测**
（即没有真的把 DNS 打坏、把证书换成自签来看提示）。
· 登录页那条"未 /api/v1 会 404"的因果链是从服务端路由 + 客户端拼接方式推出的，
没有用 curl 对 `https://mail.jianfgit.xyz/auth/login` 实打一次取证。
· test/run-all.mjs 在本机（node v24.14.1）**本来就是红的**：它只认 `# pass N`，
而 node 24 打的是 `ℹ pass N` ⇒ 25 个文件里 21 个被记成"没自报条数"。
这是既有环境漂移（已在 HEAD 的 worktree 里复现同样的红），**本次没有动它**，
所以新判据虽然已登记进 SUITE，要等 runner 的 marker 解析修好才会被套件真正计数。
|
2026-09-15 15:15:17 +08:00 |
|
|
|
1e3aac2f7d
|
跨端: feat(推送客户端): PushService.ets（取 token → 上报 → 点击跳转）+ 接进 EntryAbility ⇒ **文件真的被编译了**
pi 三件里的前两件 + 第三件的"目标解析"这半。
- `pushService.getToken()` → `POST /me/devices/push-token`（`provider/token/device_name/session_id`，省略空项）；
- 上报标记按 **`accountKey|token`**（服务端同一 token 换账号是**转移**不是并存 ⇒ 标记必须按账号维度，否则新账号永远不报、旧账号的登记已被转走）；
- 注销：`DELETE` **带 body**（服务端就是这么定的），`deleted:false` 不当错误；
- 点击跳转：`onNewWant` → `routeFromWant`（`parseNotificationData` + 有界去重 ledger）→ `PushService.pendingRoute` 等页面来取；
- **所有失败静默**（没 token / 401 / 400 / 500 / 权限拒绝 ⇒ 只写 hilog，不提示、不重试、不阻塞启动）；
- 通知权限**只在拿到 token 后**才申请（没 token 就弹窗是打扰）。
★ 一条我差点当成"验过了"的证据：`assembleHap` 在**没接入**时也报 `BUILD SUCCESSFUL` ——
因为 ArkTS 只编译**可达**模块，没人 import 的文件根本不参与编译。我植入类型错误后仍是 SUCCESSFUL，
才确认"编译通过"当时**什么都没证明**。接入 EntryAbility 后再植入同样的错误 ⇒ `Failed :entry:default@CompileArkTS` 且指名 `PushService.ets:102` ✓
—— 现在这句"编译通过"是有内容的。
**未完成（不掩盖）**：① 登录成功后主动补报一次（现在只在冷启 `onCreate` 报，冷启时未登录 ⇒ 401 静默，等下次冷启才补上）；
② `pendingRoute` 的**消费端**（页面读它并跳转）—— 这两处都要动 `LoginPage/MainPage`，而那两个文件正被别人在飞编辑，我没抢着改。
|
2026-09-15 14:20:00 +08:00 |
|
|
|
6cf431ee11
|
跨端: AGC 客户端配置不入库（gitignore + rm --cached + example）+ 一条判据代替"靠记得"
pi 2026-09-15 的裁定：**gitignore + `git rm --cached` + example，不轮换**。
我照办了，并且把**决定性事实**更正过来 —— 我上一封说"已经进了公开历史"，**那句是错的**。
## 一、暴露窗口：我原先的假设**方向反了**
我上一封写的是"它**已经进过**公开仓历史，gitignore 撤不回，要认真考虑轮换"。
**实测不成立**（pi 查的，我逐条复核）：
```
$ git cat-file -e origin/main:…/rawfile/agconnect-services.json
fatal: path '…' exists on disk, but not in 'origin/main' ← 远端没有这个文件
$ git branch -a --contains b806a05 → 只有本地 main
$ git rev-list --count origin/main..HEAD → 119（本地领先，落后 0）
```
**整段鸿蒙工作一次都没推上去。** 所以窗口是**"直到下一次 push"**，不是"已经泄露"。
这把修法从**止血**变成**赶在 push 之前做完就行** —— 顺序因此是判据的一部分：
**先入库 ignore + `rm --cached`，再 push**。哪次先推了，就立刻变成"必须轮换"。
**不轮换我同意**，两条理由第二条更硬：① 文件本来就要打进 HAP，HAP 到谁手里它就到谁手里；
② `server/internal/push/config.go:51-55` 的 `AppSecret` 走 `AppSecretFile`（`resolveSecret`，
`hms.go:95` 读它，例 `/etc/agentmail/hms.secret`），**能替你发推送的凭证不在这个文件里**
⇒ AGC 客户端配置泄露**升级不成"能发推送"**。理由已写进提交信息，免得将来有人"按惯例轮换一次"
（那会白白换掉两个客户端版本的一致性判据）。
## 二、`git rm --cached`：本地那份**必须留着**
它**必须在本地存在才能构建**（`hvigorw` 打包时要读）。所以：
```
git rm --cached <文件> ← 只动索引，磁盘上那份不动
```
撤完实测：`ls` 仍在（2656 B）、`git check-ignore -v` 命中 `client/harmony/.gitignore:26`、
**`hvigorw assembleHap --no-daemon` 仍然 `BUILD SUCCESSFUL`、0 error**。
（这条我特意重编了一次 —— "撤出索引"与"构建还能用"是两件事，不能靠推理。）
## 三、★ 判据才是机制（pi 说的这条比 gitignore 重要，我同意）
`gitignore` 单独挡不住：这个文件**必须在本地存在**，任何人一次 `git add -A` 就把它加回来了，
而**那次 add 不会有任何东西变红**。所以加了
`commit-hygiene.test.mjs` 的「★ 版本库里不许跟踪 AGC 配置真身」：
- 扫**所有 tracked 文件**（不只 rawfile），找"AGC 配置的形状" —— 同时出现
`"client_secret": "[!` / `"code1": "<32+ 位十六进制>"` / `"api_key": "[!`；命中即红并点名；
- 按**内容**判，不按文件名豁免（`example` 是**故意**带这些键名的 —— 结构留、值全打掉，
所以它靠"值都是 `<!…>`"自然通过，而不是靠一个文件名白名单）；
- 另一半：**`agconnect-services.example.json` 必须存在** —— 否则新人不知道这文件要长什么样，
只能问人或猜，而**键名猜错会报一个和"配置缺失"毫无关系的构建错**。
**变异验证**（不是只跑绿）：`git add -f` 把真身加回来 ⇒ **判据红并点名**；
`git rm --cached` 还原 ⇒ **绿**。
example 我做了泄漏核对：真文件里所有 ≥12 字符的值逐个比对，**只剩 3 处 `package_name`**
（`com.jianf.agentmail`，它本来就写在 `AppConfig` 里、必须是这个值，打掉了反而误导）。
其余保留原值的是 **AGC 各区域网关域名**（`connect-drcn.dbankcloud.cn` 之类）——
那是华为的公共基础设施域名、不是本项目凭证，打掉只会让模板不能用。
## 四、`blurStyleFor`：删除后生产代码里 5 处注释在说一个**不存在的函数**
函数已按 pi 的裁定删除（`9a10ab2`，并发会话落的）。但删除后 `Wallpaper.ts`（4 处）与
`MainPage.ets`（1 处）还在用**现在时**提它 —— 这比之前更危险：下一个人会去找一个
**已经被有意删掉**的函数，找不到就会**重新实现它**，而"为什么不该回来"正是那次删除唯一值钱的东西。
全部改成过去时 + 已删除，并在 `Appearance.ts` 原处留碑文。
`:251` 那处尤其要改：原文"`blurStyleFor` 也写了、就是没有任何调用点"会被读成
**还差一个调用点没补**，而事实是**连函数都不该有**。
## 五、`debt-visibility` 那条红（pi 数出我漏的那条）
`harmony-deviceprobe.test.mjs`（2 处）**按次数登记、不整文件放行** ——
整文件放行的话，将来在这个文件里写一句真实的「这里没判」就**不会红**。
那 2 处也不是"这块没验"，而是对**词表本身**的断言。
另在 `docs/DEBTS.json` 补一笔 `deviceprobe-fixture-timing`（到期前提：两份 fixture
从"人工存文件"变成"当场采集"）。
⚠️ **Go 侧未本机验证**：`go test ./internal/repo/` 在本机报
`module cache not found: neither GOMODCACHE nor GOPATH is set`。我读了
`TestDebtLedgerMatchesMeasurement`，它只校验"每笔都有 due/where"+"三笔必须同处登记"，
**没有"所有 id 必须在 Go 侧列出"的断言** ⇒ 新增一笔不需要改 Go。
但这是**读代码得出的结论，不是跑出来的**，如实标未验。
## 六、我自己记错的两个数（pi 更正）
- **`STATIC_ONLY` 是 7 不是 8** —— 我上封写 8，`RESULT static=7` 与闸门打的 7 个文件
都是 7。我记串了。
- `PROBE_DEVICE=none` 下**是 7 条红**，我只列了 6 条，漏了 `debt-visibility`（本笔已修）。
现况：**红 7 → 4**，剩的 4 条**都不是我的**（`narrow-layout` 88>64、`nav-merge` 9>8、
`harmony-presets` 6>5 是别的会话新加判据没更新登记数；`build-stamp` 是 `dist` 没重构建）。
|
2026-09-15 12:25:25 +08:00 |
|
|
|
77aa42623a
|
跨端: debt-visibility 补登记（新判据文件不会自动跑守卫）+ blurStyleFor 删除后的注释真相
## 一、`debt-visibility` 那条红：**新文件不会自动跑一遍守卫**
```
这些文件里有"边界声明"，但一次都没登记：
harmony-deviceprobe.test.mjs（2 处） ← e917b87/4880c31 新加的判据文件
```
**这是同一个洞在新文件上的复发**：上一轮我刚修完 `harmony-admin` / `harmony-imageprep`，
下一个**新建的**判据文件又踩了同一个坑。pi 之所以看见，只是因为他跑了整个套件 ——
**缺的不是"记得登记"，是"新建判据文件"这个动作没有守卫**。这条形状与"写了判据忘了接线"同族，
只是这次忘的是**登记边界**。
处理：**按次数登记（2），不整文件放行** —— 整文件放行的话，将来在这个文件里写一句
真实的「这里没判 / 已知缺口」就**不会红**。那 2 处本身也不是"这块没验"，
而是对**词表本身**的断言（`unverifiedReason(...)` 必须含「未验」）。
同时在 `docs/DEBTS.json` 补一笔 `deviceprobe-fixture-timing`（`where` 指向该文件）——
`debt-visibility` 的第二条要求"声明必须有对应的一笔"，两处各写各的会让审计只找到一处。
这笔的**到期前提是"两份 fixture 变成当场采集而不是人工存文件"**。
⚠️ **Go 侧未能本机验证**：`go test ./internal/repo/` 在本机报
`module cache not found: neither GOMODCACHE nor GOPATH is set`。我读了
`TestDebtLedgerMatchesMeasurement`：它只校验"每笔都有 due/where"+"三笔必须同处登记"，
**没有"所有 id 必须在 Go 侧也列出"的断言**，所以新增一笔不需要改 Go。
但这是**读代码得出的结论，不是跑出来的** —— 如实标成未验。
## 二、`blurStyleFor` 删除后：生产代码里 5 处注释在说一个**不存在的函数**
函数已按 pi 的裁定删除（别的会话的 `9a10ab2` 落的）。但删除后
`Wallpaper.ts`（4 处）与 `MainPage.ets`（1 处）还在用现在时提它：
```
Wallpaper.ts:242 "由 `model/Appearance.ts` 的 `blurStyleFor` 映射成系统材质档"
Wallpaper.ts:248 "页面拿它去问 `blurStyleFor`"
Wallpaper.ts:251 "`blurStyleFor` 也写了、就是没有任何调用点"
Wallpaper.ts:311 "`blurStyleFor` 里面也有一次 clamp，那是它自己的防线"
MainPage.ets:1711 "（`blurStyleFor` 那张表服务的是**材质档**…）"
```
**这正是本会话反复在消的"注释描述一份不存在的代码"**，而它现在比之前更危险：
下一个人读注释会去找一个**已经被有意删掉**的函数，找不到就会**重新实现它** ——
而"它为什么不该回来"恰恰是那次删除唯一值钱的东西。
已全部改成**过去时 + 它已删除**，并在 `Appearance.ts` 原处留了碑文（函数没了，理由不能没）。
`:251` 那处尤其要改：原文说"`blurStyleFor` 也写了、就是没有任何调用点"——
函数已不存在，这句会让读者以为**还差一个调用点没补**，而事实是**连函数都不该有**。
## 三、这条碑文判据我做了变异验证
`harmony-appearance.test.mjs` 里那条「碑文不许回来」的判据**确实在校验**（不是摆着好看）：
把 `Wallpaper.ts` 那段碑文抹掉 ⇒ **红**；还原 ⇒ **绿**。
顺带核了它的**指向**：碑文现在的主要落点是 `Appearance.ts`（函数原来所在处），
而判据的正则锚的是 `Wallpaper.ts` —— 两处都有内容才过，我保留了 `Wallpaper.ts` 里的引用
（它说明"这里的 px 不是材质档"），所以判据成立。
## 四、未做
- 到期闸门那 **7 条**（pi 更正过我：`STATIC_ONLY` 是 7 不是 8，我上封记串了）**仍然没动**。
- `PROBE_DEVICE=none` 下**剩 5 条红**，都是**别的会话**新加判据但没更新登记数
（`narrow-layout` 88>64、`nav-merge` 9>8、`harmony-presets` 6>5、`commit-hygiene` 3>2）
加 `build-stamp`（`dist` 没重构建，与本次改动无因果）。**我没有替他们改**。
|
2026-09-15 12:22:23 +08:00 |
|
|
|
4880c31110
|
跨端: fix(设备闸): app state 交叉验证（矛盾⇒拿不准）+ 正例换成**真机实采**样本
pi 邮件 `6f902e1e` 指出两件，都对：
1. **我那条正例是自相矛盾的**：我用脚本把 `state #FOREGROUND` 对调，却漏了同一块的 `app state #X`
⇒ 造出 `state FG` + `app state BG` 这种**真机上不会出现**的 dump。于是"闸能放行"这条正例
建在**非法输入**上 —— 它绿，但它没证明任何真机会发生的事。
现在：正例改用 12:08 **真机实采**的 `fixtures/aa-dump-l-ours-foreground.txt`（两个 mission 都在、
`state`/`app state` 一致、FG 是我们）；
2. 顺手把"矛盾怎么办"钉成规则：同一块里 `state` 与 `app state` 打架 ⇒ **`unverified`**，
**不许"挑一个信"**（那是把互相打脸的证据当成证据）。`app state` 缺失时不因此判未验
（否则老格式 dump 会一律未验 —— 那是"更安静的失效"）。
判据 8 条全绿；登记同步为 8。
|
2026-09-15 12:10:49 +08:00 |
|
|
|
b413fbb43e
|
跨端: fix(设备闸): 按真机形状改写解析（前台 = state #FOREGROUND 那个 mission 的 bundle），判据改喂真机样本
第一版是**猜的**格式（`bundleName: com.x`），真机上根本没有这种写法；退一步"取第一个 bundle name"
又会取到别人的（真机多 mission，`#31 com.example.homeagent` 排在我们 `#32` 前）⇒ 假绿（pi 独立复现）。
真机形状（样本 `test/fixtures/aa-dump-l-real.txt`，实采）：每块 `Mission ID #N … ` +
`bundle name [com.x]` + `state #FOREGROUND/#BACKGROUND`；**前台只由 `state #FOREGROUND` 决定**。
- `parseMissions` / `foregroundBundle`：按块解析，取不到返回空（不猜、不兜底）；
- `foregroundVerdict` 三态不变：`ours` / `other` / `unverified`；
- 有 mission 但**全无 FOREGROUND** ⇒ `unverified`（不是"没我们所以算别人"）；
- 空 dump / 截断 ⇒ `unverified`，状态词写明"**缺证据 ≠ 没有那个现象**"。
判据 5 条（喂真样本 + 对调状态 + 空/截断/无前台 + 撞名撞文案反证）全绿。
真样本本身含"对方在前台"那一刻 —— 争用在一分钟内真实发生过，所以这不是构造出来的场景。
|
2026-09-15 12:05:17 +08:00 |
|
|
|
c12744e8c3
|
跨端: 导航条材质选 (a) 固定档（推翻我的 (b)）—— 并修掉"注释说 (a)、代码是 (b)"的自相矛盾
pi 2026-09-15 裁定：**推翻 (b)，选 (a)**。我原先给 (b) 的理由不成立，他逐条驳了：
1. **WebUI 的导航条根本不读 `--bg-blur`**：`index.css:1114` 的 `.narrow-nav` 是硬编码
`backdrop-filter: blur(18px) saturate(1.5)`。我引这条支持"两个量不同"，
而同一条也说明**它不由用户偏好驱动**。
2. **WebUI 那个滑杆的语义是"背景"**：`BackgroundPicker.tsx:183` —— `label="模糊"`、
`hint="虚化细节，避免背景与正文抢注意力"`、`min=0 max=24`，只作用在
`.app-backdrop{filter:blur(var(--bg-blur))}` 上。
3. WebUI 自己留了**分开的**令牌 `--bg-blur-panel`（`index.css:267`，注释写明
"与壁纸自身的 `--bg-blur` 分开"）—— 它的词汇表本身就拒绝把两者等同。
4. **★ 我给 (b) 的理由不成立**：我写"(a) 会让那个滑杆在导航条上变成死控件"，
可那个滑杆**已经**被壁纸消费了（`MainPage.ets` 壁纸层的 `.blur(bgPlan.blurPx)`）——
它从来**不是**导航条的控件。(a) 之下它照样是活的。
5. §7.12 的「材质（玻璃）」行原本写的就是固定档 ⇒ (a) 是**回到**已登记契约。
产品向还有一条：**导航条是 chrome，材质应当稳定**，不该因为用户换张壁纸而变厚变薄。
## 最该记的是：我的注释和代码**互相矛盾**
`MainPage.ets` 里那段注释论证的是 (a)、并明确写着"跟随是错的，pi 抓出来了"，
而它下面那一行代码是 (b)。**下一个读者会照注释把代码改回去，并引我那句话当权威。**
这是这一路反复在消的形状（说的与做的不一致、而判据看不见），这次落在**注释**上 ——
而注释正是"理由要写清"那条纪律的证据源。已整段重写为真实的 (a) 版本，并把
"(a) 会让滑杆变死控件"这个**错的理由**连同它为什么错一起留在注释里。
## 做掉的东西
- `MainPage.ets`：导航条回到 `.backgroundBlurStyle(Theme.navMaterial)`；
删掉 `NAV_MATERIAL_OF` 表与 `navMaterialFor` 的 import（(a) 之下都是孤儿）。
- `model/Appearance.ts`：删 `navMaterialFor`（它存在的唯一理由就是方案 (b)）。
`blurStyleFor` 现在**没有任何调用点** —— 如实登记在它的文档注释里
（"有测试"不等于"有人用"，上一轮我刚因同形状被抓过），不假装它活着。
- **五处"整条字面表达式"断言改成语义断言**（pi §四）：`cross-client-theme`、`harmony-appearance`、
`harmony-nav`（3 处）此前都在钉
`/\.backgroundBlurStyle\(NAV_MATERIAL_OF\[navMaterialFor\(…\)\] \?\? Theme\.navMaterial\)/`
—— 字面换字面，正是 `CRITERIA.md` 不许的"对源码形状的匹配"。
现在判：① 那一处的材质**来自 `Theme.navMaterial` 这个系统令牌**；
② **不许跟随** `bg_blur`（NavBar 真代码里不许出现 `blurPx`/`blurStyleFor`）；
③ 令牌是 `BlurStyle` 枚举值、不是 `NONE`、且**成员名真实存在于 SDK 枚举**。
- "可达性"那条判据**随契约作废**（它守的是方案 (b)）：换成判 (a) 的契约。
**判据随契约走，不随实现走。**
- `harmony-appearance`：原先判"页面里那张表的键必须是 SDK 成员"。表删了，
改成**枚举 `blurStyleFor` 的整个值域**（0..40 + 界外 + NaN），逐个核 SDK 成员 ——
比原来只核表里那三行**更严**。
## 判据自己先错了一次，记下来
新判据第一版**没剥注释**就断言"NavBar 里不许出现 `blurPx`"，当场红了 ——
而红的原因不是代码错，是 `NavBar` 的**文档注释**里正好写着
"我一度把档位接过用户偏好（`navMaterialFor(this.bgPlan.blurPx)`）"这句历史说明。
**注释说明禁令 ≠ 违反禁令**；不剥注释，这条判据就会变成"逼人删掉解释"，
恰好与本仓库"理由要写清"的纪律相反。改成 `stripComments(bar)` 后再判，并加了一条
"注释里确实留着那处说明"的自检前提。
## 变异体：45 个全部被抓（含 3 个新判据的专属变异）
方案 (b) 落地时配的 13 个变异体**整体作废**（它们锚的代码被删了），标注 `retired`
并写清理由 —— 不是"没跑成"。另有 5 个锚点漂移（我在注释里逐字引用了被锚的那句代码，
污染了通用正则）的**重锚**到真代码；注释里那句逐字引用也一并去掉了
（**注释里逐字抄代码**正是让"按字面锚定"的变异体反复失效的根因）。
新增 3 个针对 (a) 契约的变异体（绕过令牌 / 又跟随 `bg_blur` / 令牌变 `NONE`），全部被抓。
## 未验
- **真机观感仍未验**：三档材质在真机上能不能看出差别、滑杆手感、管理页布局，
只有真机能答。本机模拟器已起（`hdc list targets` 有目标），但
`run-all.mjs` 的**设备闸已经到期**（8 个静态判据的前提成立）⇒ 套件现在会挡在
那道闸上、不打 `RESULT`。**这不是本笔引入的**（前提是环境变了），已单独报给 pi。
- Go 侧 `debt_registry_test.go` 仍未在本机跑（无 Go 模块缓存）；pi 已在别处跑过，绿。
|
2026-09-15 11:58:19 +08:00 |
|
|
|
e917b8782a
|
跨端: feat(设备闸): DeviceProbe.ts —— "读到别人的界面"是假绿来源，读之前先判"是谁的"，拿不到就记未验
pi 邮件 `971c58fa` §4 / `bf583b0f` §2。别的 agent 在同模拟器上 `aa start` 会抢前台，
之后读到的控件树是**它的窗口** ⇒ 断言可能通过也可能红，**两者都不是在讲我们的界面**（前者=假绿）。
- `foregroundVerdict` 判决只有三种：`ours` / `other` / `unverified`；**只按 bundle 判，不许看标题/文案/控件名**
（别人的合法 dump 里完全可能有同名控件与同文案，"邮件"这种通用词尤其容易撞）；
- `parseForeground` 取不到就 **undefined**（空 dump / 截断 / 格式变了都不猜）；
- `mayAssertOn === false` ⇒ 调用侧必须记 **`未验`**（欠账继续开着），**不许**记通过、**不许**静默跳过
—— 跳过会在下一轮被读成"验过了"；
- `unverifiedReason` 统一状态词，并写明"**缺证据 ≠ 没有那个现象**"。
判据喂 4 类样本（pi 指定的最易漏输入）：① 我们的 dump ② **别人的合法 dump（含同名控件 + 同文案）**
③ 截断/畸形 ④ **空 dump**（窗口没起来时最常见，最容易被当成"坏现象不存在"）。
另加一条只按 bundle 判的反证（把标题改成"像我们"也不许变 ours）。
**顺手抓到自己一个坑**：`firstMatch` 第一版的否定类既接受非 ASCII 也接受**换行**
⇒ 对 `windowTitle: 邮件\n abilityName: …` 会吞掉中文标题并**捕获下一行的键名**，
"标题"读到 `abilityName`（看起来有值、其实指错地方）。判据当场抓到 ⇒ 改成按行取、值允许中文、空值不回退。
|
2026-09-15 11:54:25 +08:00 |
|
|
|
ab31690348
|
跨端: fix(推送客户端): 登记标记绑定账号（token 换账号是"转移"不是并存 ⇒ 别把登记状态缓存成长期结论）
pi 邮件 `2518e1a3` 的服务端事实：注销只认注册者本人、token 字符串不是凭证，
**同一个 token 换账号登录是"转移"而不是并存** ⇒ "我登记过没有"的答案**随账号而变**。
原来的 `shouldReportToken(lastReported, current)` 只按 token 存标记 ⇒ 换账号后
（同一 token）会**错误地跳过上报**，而那个账号其实还没登记过这个 token。
改成 `reportMarker(accountKey, token) = accountKey|token` + `shouldReportToken(lastMarker, accountKey, token)`：
**账号变了标记必然不同** —— 于是"换账号必然重新上报"是**性质**，不靠人记得 reset。
判据 13 条全绿（新增"换账号后必然重新上报 / 切回来也要重新上报"，并断言两次 marker 不相等）。
|
2026-09-15 11:51:39 +08:00 |
|
|
|
30886271ea
|
跨端: docs(引用锚): 把日期锚换成邮件 ID（pi 邮件 b1e23663：日期也是锚，写错一天下一个人找不到那封信）
pi 指出的锚错：`PushContract.ts` 里那段线上形状是 pi **09-15** 发的（邮件 `004983bb`），我写成了 09-14。
照他的推理（"引用别人的工作状态时，哈希和'谁在读'一样会漂"）往下再走一步：
**日期本身就是会漂的锚 —— 邮件 ID 不会。** 所以不是把 09-14 改成 09-15 就完事，
而是把这一族引用改成**可检索的标识**：
- `PushContract.ts`：契约来源 → `1f9ff3b4`；线上形状 → `004983bb`；
- `harmony-push.test.mjs`：同上两处；
- `Calendar.ts`：表头共用分叉、"今天"的调用侧 → `f60521de`；
- `ALIGN-REFS.json`：参照物版本登记 → `6e14b410`；圆角策略追认 → `90372ca1`；AGC 包名实测 → `1f9ff3b4`。
共 10 处。判据不依赖这些注释文本，改完 `harmony-push` 12/12、`harmony-calendar` 10/10、`align-refs` 3/3 仍绿；
`ALIGN-REFS.json` 仍是合法 JSON。
**没改的 4 处**（`NavItems.ts` 1 处、`Wallpaper.ts` 3 处）：它们写于 09-14 那批往来，日期本身没被指出错，
而那几封的邮件 ID 我这边没有（跨过一次上下文压缩）——**宁可留着有争议的日期，也不编一个 ID**。
|
2026-09-15 11:51:39 +08:00 |
|
|
|
ed0ad2508e
|
跨端: feat(推送客户端): 按线上形状补契约层（DELETE 也带 body / 未知字段 400 / provider 无白名单 / 错误是 {"error"}）
pi 2026-09-14 给的线上形状（从 handler/push.go 读的，不是猜的）逐条落成可判的：
- **请求体只放已知键**：`PUSH_BODY_KEYS` 登记四个键，**未知字段服务端直接 400**（不是静默忽略）
⇒ 拼错会立刻可见；可选字段为空就不放（空串虽合法，但不放更不容易踩校验）。
- **provider 只做形状校验、没有白名单**（`^[a-z0-9_-]{1,32}$`）：判据断言 `apns`/`fcm` 也合法 ——
客户端**不许**硬编码"只有 hms 合法"去先拦一道（服务端没实现的通道不该变成客户端的 400）。
这正是"校验的范围必须等于它真正知道的事"的又一落点。
- **token**：空非法、512 上限；形状不合法 ⇒ `buildTokenBody` 返回 undefined，调用侧**静默跳过**，
不去打一次注定 400 的请求。
- **错误体是 `{"error"}` 不是 `{"message"}`**：判据专门断言 `{"message":"x"}` 解析出 undefined
（用错键会把"没有消息"当有消息）。
- **注销：`deleted:false`（本来没登记）不是失败** ⇒ 它**不改变分类**，所以**不再是入参**
（一个不影响结果的入参只会让人误以为它影响结果），判据断 `classifyUnregister.length === 2` 钉住这点。
- **`ApiClient.del` 补可选 JSON body**：DELETE 端点是 JSON body 形状（不是 query、不是 path 参数），
原来只有 `path` ⇒ 注销会无效。不传 body 时行为与旧版完全一致（向后兼容）。
EOF
|
2026-09-15 11:43:22 +08:00 |
|
|
|
8fed8401de
|
跨端: feat(推送客户端): 契约层 model/PushContract.ts + 6 条设备无关判据（静默失败/enabled:false 正常态/按 provider+tail 比/按 mail_id 去重）
pi 2026-09-14 推送契约的客户端半边。四条不变量里**三条是纯逻辑**，所以先落这三条，
平台调用（Push Kit 取 token、通知权限）留在下一步的 `PushService.ets` 里。
- `shouldReportToken`：取不到 token 不上报；与上次相同不重复上报（否则每次启动打一次接口）；
- `tokenTail` / `isRegistered`：GET **只回尾 6 位** ⇒ "登记过没有"必须按 `provider + tail` 比。
比全文是**看起来更严、其实永远为假**的写法（全文永不等于尾 6 位 ⇒ 每次启动重复上报），
所以有判据钉它，并在注释里写明"同尾 6 位即视为同一条 —— 这是服务端给的信息量的上界，不是我们的选择"；
- `classifyRegister`：`ok-enabled` / `ok-disabled` / `silent-skip` —— **三种里没有一种是"提示失败"**
（`enabled:false` 是自部署常态 ⇒ 不重试、不提示）；
- `parseNotificationData`：不满足约定形状就返回 undefined（坏 JSON 不抛、缺 mail_id/动作不符都忽略）——
推送是可选通道，收到不认识的东西不许有任何副作用；
- `NotificationLedger`：服务端**无幂等键**（至多一次、无重试/去重表）⇒ 重复保护落客户端；台账**有界**。
另有一条判据禁止契约层引入 `@ohos`/`@kit`（否则这些判据会退化成必须上设备）。
它第一次跑**咬到了解释这条规则的那行注释** ⇒ 改扫 `code()`（去注释），与前面扫描口径那次同族。
`npm test`（install 相位）全绿；余额 `debts=13`。
|
2026-09-15 11:40:54 +08:00 |
|
|
|
7b16fec61c
|
fix(harmony): AdminUsersPage 的 Chip 参数放宽到 ResourceColor —— 三个编译期错误（不是警告）
`Chip(text: string, bg: string, fg: string)` 收不下 `Theme.surfaceMuted` /
`Theme.textSubtle`（它们是 `$r('sys.color.*')` ⇒ `Resource`）。于是
`user.role === 'admin' ? Theme.chipNeutralBg : Theme.surfaceMuted` 这类三目
在三处报：
Argument of type 'string | Resource' is not assignable to parameter of type 'string'
Argument of type 'Resource' is not assignable to parameter of type 'string'
（AdminUsersPage.ets:353 / 357 / 368）
`fontColor` / `backgroundColor` 本来就收 `ResourceColor`，所以放宽参数类型即可 ——
不必把系统语义色抄成字符串（那正是 Theme.ets 文件头要避免的事）。
归属与复核（2026-09-15）：
- 这三条在 `474cada` / `b806a05` / `7f4fa26` 上**一直红着**，是**提交树里**的错误，
不是任何人的在飞改动。复核方式：`git show 7f4fa26:…/AdminUsersPage.ets | grep -n 'Chip(text'`
⇒ `bg: string`；该文件自 `474cada` 起未被改过（`git log -- <file>`）。
- 同一批的另两条（MainPage.ets 的 `arkts-no-misplaced-imports`）由**别人**在写，
我没有 stage / 没有改那份文件。
- 实测：修前 `hvigorw assembleHap` = BUILD FAILED（6 个 arkts 错误，
含 MainPage 两条 misplaced-imports）；MainPage 那份修好后本笔使整个构建
BUILD SUCCESSFUL（本轮实测）。
|
2026-09-15 11:33:27 +08:00 |
|
|
|
b806a05bfa
|
跨端: harmony 管理页（用户管理）+ P4c 壁纸上传入口 —— 「功能做全再交付」的两块
pi 的交付清单里缺的两块（`docs/GUI-PLAN-HARMONY.md` 原先把管理后台划在首版之外，
用户明确要求「功能做全再给我」之后收进来）。
标 `跨端:` 是因为判据落在 `client/electron/test/`（鸿蒙的判据目录一向量在那里），
代码本体全在 `client/harmony/`。
## 管理页（用户管理）
- `pages/AdminUsersPage.ets`：新建 / 编辑（显示名·角色·白名单）/ 启停 / 重置密码。
排布照 `AdminUsersPage.tsx`，包括「受限」徽标口径（普通用户且白名单非空才显示）、
最后登录缺席与空串都显示「从未登录」、管理员对白名单两项忽略。
- 入口在设置页底部，**仅管理员可见**（`role === 'admin'` 严格相等，与 `App.tsx` 同口径）。
读不到身份时**不**显示也不报错（乐观放行会让每个普通用户看到点进去 403 的入口）。
- `api/AdminApi.ets` + `model/AdminUsers.ts`（纯逻辑，零 import ⇒ 判据能真跑）。
- 启停**只发 status 一个字段** —— 服务端是部分更新，多发字段会把显示名与白名单一起改掉。
- `model/Models.ets` 补管理端 DTO；`main_pages.json` 注册路由。
## P4c 壁纸上传
- `model/ImagePrep.ts`：阈值与两档策略（2560/0.85 → 1280/0.78，入口 20MB，压后上限 3.5MiB）。
**一处有意不对齐 WebUI** 并写明理由：WebUI 卡 data-URL 长度（含 base64 膨胀），
鸿蒙内存直传 ArrayBuffer，卡的是字节数。
- `common/BackgroundPicker.ets`：不设 / 预设 / 自定义图片 + 浓度与模糊滑杆。
上传链：picker → 判可不可以 → 逐档按 desiredSize 解码压缩 → 上传 → **请页面以服务端为准重新同步**。
失败**必带原因**（服务端 415/413 文案原样透出）。用户取消选图**不算失败**。
- `ApiClient.uploadBytes`：MultiFormData.data 收 ArrayBuffer（核了 SDK，since 11；本工程 23）
⇒ 内存直传，不需要 base64 也不需要临时文件。
## 两处真 bug（变异测试逼出来的，不是"新写坏的"）
1. **压缩循环的第二档此前是死代码**：循环里的 break 与循环外那句 shouldRetryWithActual
互相抵消 —— 把循环里那处改成 `if (true)`（永远只压一档）整套判据照样全绿。
收成一处判定（overLimit），循环外只读结论，并加结构性判据（该函数在这条链上只许调用一次）。
2. **壁纸的模糊档一直是「只写不读」**（计划文档 §7.12 登记过）：滑杆能拖、值能存、
blurStyleFor 也写了，就是**没有调用点**，壁纸一点没糊。
本次补上的调用点分两层：壁纸层 `.blur(px)` = **图片内容模糊**
（与 WebUI 的 `filter: blur(var(--bg-blur))` 同一个量、同一个数，所以不需要映射表）；
而那张**材质档**映射表 `blurStyleFor` 也终于有了调用点（`navMaterialFor` 内部复用它）。
`docs/HARMONY-ALIGN-PLAN.md` 的 §7.12 两行（材质 / 壁纸模糊度）已一并改准、不再互相矛盾。
## pi 复核后**改回来的**（这一笔里我自己犯的两处，都由 pi 抓出）
1. **导航条材质一度绑定到 `bg_blur`，`bg_blur=0` 时整个消失。**
我把 `NavBar` 从固定档改成 `blurStyleFor(bgPlan.blurPx)`，而滑杆 `min: 0` 可达、
`blurStyleFor(0) === 'NONE'` ⇒ 用户把壁纸调清晰时**导航条一点材质都没有**。
而且它与本笔自己的论证**相反**：刚论证完"图片内容模糊"与"面板材质"是两个物理量，
转头把面板材质接到壁纸模糊这个输入上。
现在**分层**：`blurStyleFor` 是通用映射（**允许** NONE —— "0 px 不模糊"是它的正确语义）；
`navMaterialFor` 是**导航条专用、有下限**的入口（0 px ⇒ 最薄档）。
判据钉**可达性**（滑杆 0..40 每个整数 + 界外值都不许 NONE，且三档都要出现 ——
否则"恒定最薄档"会让滑杆成为死控件）。
2. **`Theme.navMaterial` 被我弄成了死令牌**，而看着它的判据**照样绿**
（那条只断言"声明存在且不是 NONE" —— 守的是声明，坏的是活的调用路径）。
现在导航条真的用它；并把同文件里**只覆盖 `Theme.overlay` 一个令牌**的死令牌规则
**铺到 Theme 的全部 35 个令牌**（量**外部引用数**：只被 Theme 内部方法读、
而那个方法自己有外部调用点 ⇒ 不算死 —— `chipSpentBg` 是这种；`navMaterial` 当时
唯一的消费者是一张可整体删掉的局部表，所以必须被抓）。
## pi 复核后**补上的**（这一笔漏掉的接线，都是我造成的）
- **`test/run-all.mjs` 的 SUITE 没接两个新判据文件** ⇒ HEAD 上 `npm test`
**一条判据都不跑、直接 exit 1**（套件自检 2 就是为这件事写的）。已接入，
并把两条登记进 `STATIC_ONLY`（`.ets` 要设备 ⇒ 静态欠账）。
- **`debt-visibility` 是我自伤**：那两个新文件里有 5 处"边界声明"但一次都没登记。
我当时报"2 条失败是改动前就红" —— **只对一半**：这条在父提交上是**绿的**。
我那次 `git stash push -u -- client/harmony` 的对照是**无效对照**
（`-- client/harmony` 把 `client/electron/test/` 整个排除在外，新判据文件根本没被 stash），
所以两次跑都红、看着像"既有"。已按 pi 的建议改用 `git worktree` 到父提交做对照。
现在两处都登记进 `docs/DEBTS.json`（含 `static-criteria` 5→7，Go 侧同一份登记同步改）。
## 一并修正的旧判据（都是"太宽/太窄/钉错东西"，不是放宽标准）
- 「模糊归属」：原文「壁纸层不许有**任何**模糊调用」把**图片内容模糊**与**面板材质**
混为一谈（WebUI 侧核实：`.app-backdrop` 的 filter 与它之上那层的 backdrop-filter
是两个不同的量）⇒ 改成按两种模糊分别钉。
- 「bgBlur 只写不读，消费侧必须为 0」：值不再成立，**形状保留**（逐文件登记 + 计数 + 理由），
标题与断言里的假话一并改掉。
- isDarkMode 那条 `/dark\s*\)/` 断的是**参数顺序**（加一个入参就误红）⇒ 改成"dark 在实参里"。
- 三条钉 `backgroundBlurStyle` **整条字面表达式**的断言 ⇒ 改成钉语义
（"用系统材质 + 材质有下限"），不再匹配那一行的字符。
## 判据
新增 `harmony-admin.test.mjs`（22 条）、`harmony-imageprep.test.mjs`（29 条）；
`harmony-presets.test.mjs` 加 1 条（模糊档搬运与归一，含 `-0` 那个洞：
`Math.round(-0.4)` 是 `-0` 而 `-0 < 0` 为 false ⇒ 改成判 `!(r > 0)`）。
**`node test/run-all.mjs`：22 个判据文件全部跑起来**，红的只有 1 个：
`build-stamp`（`dist` 是 `a5fc86b` 上构建的，`gitRev` 对不上当前 HEAD）。
这条**不是我的代码造成的**（可证：`a5fc86b..HEAD` 之间，`srcHash` 覆盖的那批文件
——`client/electron/src` 等——**一个都没动过**，所以 `srcHash` 没变，差的是 `gitRev`），
但也**不是"改动前就红"**：任何推进 HEAD 的提交都会让它变红，正确修法是重构建。
## 未验（如实标注）
- **本机无设备/无模拟器 ⇒ 全部观感未验**：管理页排版与卡片观感、滑杆手感、
模糊在真机上的实际档位观感、系统材质在自绘悬浮条上的实际效果。代码齐 ≠ 真机验过。
- 预设档**没有**上模糊（壁纸在预设档下是一叠自绘矩形，系统材质对它不生效）——
这是我**主动收的范围**，不是漏，真机看一眼再决定要不要补。
- **Go 侧的 `debt_registry_test.go` 我没能跑**（沙箱里没有 Go 模块缓存，`go test` 起不来），
只做了 `gofmt` 校验；那处改动是一行 `Count: 5 → 7`。
|
2026-09-15 11:17:23 +08:00 |
|
|
|
474cadaf54
|
跨端: harmony 管理页（用户管理）+ P4c 壁纸上传入口 —— 「功能做全再交付」的两块
pi 的交付清单里缺的两块（`docs/GUI-PLAN-HARMONY.md` 原先把管理后台划在首版之外，
用户明确要求「功能做全再给我」之后收进来）。
标 `跨端:` 是因为本次的判据落在 `client/electron/test/`（鸿蒙的判据目录一向量在那里），
代码本体全在 `client/harmony/`。
## 管理页（用户管理）
- `pages/AdminUsersPage.ets`：新建 / 编辑（显示名·角色·白名单）/ 启停 / 重置密码。
排布照 `AdminUsersPage.tsx`，包括「受限」徽标的口径（普通用户且白名单非空才显示）、
最后登录缺席与空串都显示「从未登录」、管理员对白名单两项忽略。
- 入口在设置页底部，**仅管理员可见**（`role === 'admin'` 严格相等，与 `App.tsx` 同口径）。
读不到身份时**不**显示也不报错（乐观放行会让每个普通用户看到一个点进去 403 的入口）。
- `api/AdminApi.ets` + `model/AdminUsers.ts`（纯逻辑，零 import ⇒ 判据能真跑）。
- 启停**只发 status 一个字段** —— 服务端是部分更新，多发字段会把显示名与白名单一起改掉。
- `model/Models.ets` 补管理端 DTO；`main_pages.json` 注册路由。
## P4c 壁纸上传
- `model/ImagePrep.ts`：阈值与两档策略（2560/0.85 → 1280/0.78，入口 20MB，压后上限 3.5MiB）。
**一处有意不对齐 WebUI** 并写明理由：WebUI 卡 data-URL 长度（含 base64 膨胀），
鸿蒙内存直传 ArrayBuffer，卡的是字节数。
- `common/BackgroundPicker.ets`：不设 / 预设 / 自定义图片 + 浓度与模糊滑杆。
上传链：picker → 判可不可以 → 逐档按 desiredSize 解码压缩 → 上传 → **请页面以服务端为准重新同步**。
失败**必带原因**（服务端 415/413 文案原样透出）。
- `ApiClient.uploadBytes`：MultiFormData.data 收 ArrayBuffer（核了 SDK，since 11；本工程 23）
⇒ 内存直传，不需要 base64、也不需要临时文件。
- 用户取消选图**不算失败**，什么都不说。
## 顺带修掉的两处真问题（都是变异测试逼出来的）
1. **压缩循环的第二档此前是死代码**：循环里的 break 与循环外那句 shouldRetryWithActual
互相抵消 —— 把循环里那处改成 `if (true)`（永远只压一档）整套判据照样全绿。
收成一处判定（overLimit），循环外只读结论。
2. **壁纸的模糊档一直是「只写不读」**（计划文档 §7.12 登记过）：滑杆能拖、值能存、
blurStyleFor 也写了，就是**没有调用点**，壁纸一点没糊。本次补上调用点
（壁纸层 .blur(px) = 图片内容模糊；导航条材质由 blurStyleFor 映射）。
同时按 §7.12 的原承诺更新了那一行。
## 一并修正的旧判据（都是"太宽/太窄"，不是放宽标准）
- 「模糊归属」：原文「壁纸层不许有**任何**模糊调用」把**图片内容模糊**与**面板材质**
混为一谈（WebUI 侧核实：.app-backdrop 的 filter 与它之上那层的 backdrop-filter
是两个不同的量）⇒ 改成按两种模糊分别钉。
- 「bgBlur 只写不读，消费侧必须为 0」：值不再成立，**形状保留**（逐文件登记 + 计数 + 理由），
标题与断言里的假话一并改掉。
- isDarkMode 那条 `/dark\s*\)/` 断的是**参数顺序**（加一个入参就误红）⇒ 改成"dark 在实参里"。
- 导航材质三处断言原本钉 `Theme.navMaterial` 字面量 ⇒ 改成钉新的映射写法。
## 判据
新增 `harmony-admin.test.mjs`（22 条）、`harmony-imageprep.test.mjs`（29 条）；
`harmony-presets.test.mjs` 加 1 条（模糊档搬运与归一，含 -0 那个洞）。
全量 203 条：**201 通过**，2 条失败为**改动前就红**的既有项
（BUILD_INFO 比对、词表↔余额）—— 用 stash 对照验证过。
两个新判据文件上跑了 **48 个变异体，全部被抓**（含"接线"类：删掉「受限」徽标、
组件自己宣布成功、release 不 await、按原图尺寸解码…），
其中 2 个变异体**红不了**，因此又补了 5 条判据（纯逻辑接线、退档判定只有一处、
两档都超限必拒、解码尺寸用的是目标尺寸而非原图尺寸、模糊档搬运）。
（数字口径：按 runner 的真实条件"锚点恰好命中 1 次才算跑过"统计；
另有 4 条锚点不命中、根本没跑，不算在这 48 里。我第一次写的是"40"——
凭记忆累加的，错了，已更正。）
**未验**：本机无设备/无模拟器 ⇒ 全部观感未验（管理页排版、滑杆手感、模糊在真机上的
实际档位观感）。代码齐 ≠ 真机验过。
|
2026-09-15 11:03:22 +08:00 |
|
|
|
d3f6f3baf6
|
跨端: 鸿蒙日历写侧（新建/编辑/删除/暂停恢复）+ 表单不再是一面滚轮墙
用户：「是的去吧」（批准上一封列出的下一步）。
- CalendarApi：createEvent / updateEvent / deleteEvent（POST /calendar/events、
PUT/DELETE /calendar/events/{id}）；新建与编辑发**同一份** CalendarEventInput
—— 服务端两个端点同形（CreateCalendarEvent 里那个 Status 字段的注释就写着这句），
拆两份会在严格解码下 400
- CalendarPage：写侧表单（新建与编辑共用一份）、二次确认删除、暂停/恢复走 update
（调度器只触发 active；没有暂停就只能删掉重加，而那会丢 event_id 与历史）
- 服务端 400 文案原样显示（收件地址无法解析：…）—— 建事件时就校验地址，
吞成保存失败等于让人猜，而猜的代价是以为设好了、实际永远发不出去
- 空标题/空收件人在本地就挡住，不发注定 400 的请求
- 提交的是**时间戳**（isoTimestampOfLocal），不是日期键；编辑回填走 localDateOf
- ★ 表单形状：日期/时间选择器合起来 ~1400px，展开着放会把标题与收件人挤出屏幕 ——
改成一行摘要 + 点开展开（默认收起）。这不是美观问题：展开态下保存在屏幕外，
要跨过一整面滚轮才够得着
- 判据 +7（端点/载荷/前置校验/文案/二次确认/时间戳往返/变异自检），23 条全绿
- 真机实测（hvigorw + hdc + uitest 逐字段输入 + 逐键点击，每一步都回库核对）：
建 → 库里 event_time 是 2026-09-28T01:00Z（= 本地 09:00 整，默认值正确）、
暂停 → status=paused、删除第一下只变确认删除（库里还在）、第二下才真删（库里 0 条）
|
2026-09-14 18:57:53 +08:00 |
|
|
|
94ba4b9c58
|
跨端: 鸿蒙端功能同步第一步——日历（只读月视图）上架，入口进底部导航
用户：「要给鸿蒙端做功能同步」。按 API 面盘点（WebUI 62 个 API 函数 vs 鸿蒙 38 个），
最大的用户面缺口是**日历**：纯逻辑（model/Calendar.ts）与判据早就在，一直没页面。
新增：
- api/CalendarApi.ets：GET /calendar/events?from=&to=（与 WebUI 同参；区间按**网格**取，
不是月首月末 —— 首尾格子会显示邻月，只查当月会让那些格子永远空着）
- pages/CalendarPage.ets：月网格（翻月/回今天）、点某天看当天日程、事件点、今天/选中两态、
加载失败说出来。**没做**：写侧（增删改）、农历重复、.ics、滑动翻页 —— 逐条写在文件头
- model/Calendar.ts：补 localIsoOf / hhmmAtOffset / deviceOffsetMinutes（偏移是入参 ⇒ 三时区可真跑）
- model/Models.ets：CalendarEvent / CalendarListResponse（字段对齐服务端 JSON）
- NavItems：加「日历」，底部成为 通信/日历/联系人 三项（与 WebUI 同序）
- MainPage：日历是**常驻 pane**（visibility 控制），首次可见才拉数据；today 走
@Prop @Watch(visible) 在 pane 变可见时重算 ⇒ 结算欠账 calendar-today-recompute
（DEBTS 15 笔 → 14 笔，余额里不再计这一笔）
判据：harmony-calendar 新增 6 条（网格/表头同源、事件归日走 localIsoOf、三时区钟点、
today 重算路径、翻月走 addMonths、变异自检）；harmony-nav ② 分派与 ④ 让位跟着改成结构性判据
（④ 原来那个 400 字符窗口一加 pane 就红 —— 窗口式判据的又一次现身）；harmony-logic 两处
「只剩两个平级页签」跟着改成三项。
真机实测（harmony-emu + hvigorw assembleHap + hdc install + uitest click + dumpLayout）：
9 月网格星期对齐（周一起始，2026-09-01 落在「二」列）、事件点恰好在有日程的那 6 天
（11/17/18/24/25/30）、点 09-17 列出当天两条日程且钟点是本地时间（DB 里 02:20Z/08:30Z
→ 界面 10:20/16:30）。
|
2026-09-14 18:38:51 +08:00 |
|
|
|
79e591aa8b
|
跨端: 底部导航选中态——图标也变色（鸿蒙侧补齐），选中态只换颜色
用户：「ui更新同步到鸿蒙端」+「选中对应的文字和图标变色即可」。
WebUI（上一提交）：删掉背景块与顶部指示条，只留颜色。
鸿蒙侧：本来就没有背景/指示条（选中态从没用形状表达过），缺的是**图标那一半** ——
MainPage.NavItem 里只有 label 上了 fontColor，图标一直保持默认色，看着像选中了一半。
- MainPage.NavItem：图标补 fontColor，与 label 过同一个三元式
- 判据 harmony-nav ⑤ + 真变异自检（删掉图标那行 fontColor，⑤ 立刻红）
- 自检本身也修了一处窗口式判据：原来用 [\s\S]{0,80} 找 fontColor，
把下一行 label 的也圈了进来，自检自己假绿
- 模拟器实测（harmony-emu + hvigorw + hdc + uitest）：同一字形在两项之间颜色随选中**对调**
（核心色 81,121,187 选中 vs 135,168,217 未选中）
- 提交归属：本提交同时动 harmony 与 electron，按仓库判据自报家门（跨端:）
|
2026-09-14 18:38:33 +08:00 |
|
|
|
13e8671d03
|
跨端: feat(P6): 表头与网格共用同一个 startOfWeek；"今天"的调用侧入可跑判据；禁用 toISOString 取日期键
pi 2026-09-14 两条，都赶在页面骨架之前定下来。
1. **唯一分叉点必须同时喂两处**：整月网格有两个地方依赖"周从哪天开始" ——
空格数（`leadingBlanks`）**与表头第一格**。表头若在页面里硬编码，就是**第二个分叉**：
格子全对、**表头整体错一列**，而原有 6 条判据一条都不会红（它们只看网格）。
新增 `weekdayLabels(startOfWeek)`（顺序只从这一个参数出）+ **交叉核对判据**：
把"1 号落在第几列"与"那一列的表头字"对上（6 个月份 × 2 种起始）。
2. **"今天"的调用侧**：`today` 入参化让纯逻辑侧干净了，代价是**唯一还能错的地方搬到了调用侧**
—— 而它正好是纯逻辑判据够不着的。`toISOString()` 是 UTC 口径：UTC+8 的清晨会给**昨天**，
"今天"就标到上一格，且在本机跑 UTC 的环境里**永远测不出来**。
新增 `isoOfLocal(now)`（本地年月日手工补零）+ `isoAtOffset(now, 分钟)`（与前者同源但不依赖进程时区，
好让三种偏移**可以真跑**）。判据钉住：UTC+8 / UTC-7 / UTC 三种偏移的日期、
**两种取法在 UTC+8 清晨必须不同**（把陷阱本身钉死）、以及本机两条取法自洽。
3. 附带一条**未来时**的判据：鸿蒙树里不许出现 `toISOString().slice(0,10)` 取日期键
（登记值 0 ⇒ 页面骨架写错时立刻红，报错写"正确修法 = isoOfLocal"与"最常见的错误修法 = 改期望值"）。
它第一次跑就抓到了 `model/Calendar.ts` 里**解释这个陷阱的注释** —— 所以改扫 `code()`
（去注释后的代码）：规则管代码，注释是文档。
|
2026-09-14 17:43:09 +08:00 |
|
|
|
e94e4dcd39
|
跨端: feat(P6): 日历纯逻辑 model/Calendar.ts + 6 条可跑判据（第 1 步的逻辑那一半，不需要设备）
|
2026-09-14 17:41:43 +08:00 |
|
|
|
f5c4f56682
|
跨端: feat(预设): 静默兜底留一条可观测痕迹；"只写不读"在鸿蒙侧也补上判据（照 LEGACY_BACKUP_KEY 照搬）；§10 出处落地
pi 2026-09-14 的三小条。
1. **§3 静默兜底要留可观测痕迹**：`normalizePreset` 把认不出的 id 换成 aurora 这件事，
原先在真实环境里**不留任何痕迹** —— §10 的登记只防"被误报成 bug"，防不住
"没人知道它正在发生"。现在 `BackgroundPlan.presetSubstitutedFrom` 带出**原来那个 id**
（换过非空、没换过空串），页面据此打一行日志 ⇒ 后果从"可能发生"变成"**可数**"。
**痕迹记在返回值里而不是在这一层直接打日志**，理由写进代码：这一层是**纯逻辑**
（无 `@ohos` 依赖 ⇒ 判据能用 node strip-types 直接跑它）；为打一行日志引入 `@ohos.hilog`，
等于把"能真跑的行为判据"换成"只能读源码的形态判据"——不划算的交易。
**判据两条方向都钉**：替换必须留痕（且带出原 id）；**没替换时必须为空**
（痕迹退化成噪声就等于没有）。变异与正反例都在（5 条全绿）。
2. **§2 §10 的"谁批准"落成出处**：那一格原写"产品决定" —— 按 pi 的话这是**事后追认**。
现在写的是 **「无人类批准：这是实现时的默认行为（随 `model/Wallpaper.ts` 引入，
`git log --diff-filter=A` 可查出处，2e42aac），本行是补登记」**，并把**意图**与**批准**分开写
（不拿意图冒充批准）。另两行也补了出处（`Appearance.ts:39,52,88,104,133` /
`AppearanceStore.ets:142-195` / `backgroundStore.ts:200`）。
3. **§1 "可扫的字段清册"不必先造 —— 同形状已有一边是判据**：他说得对。
WebUI 的 `LEGACY_BACKUP_KEY` 早就钉着"只写不读"，鸿蒙的 `bgBlur` 只有文档
⇒ 差的是**同一个形状只有一边有判据**。已照搬：`harmony-appearance.test.mjs` 新增
**"消费侧出现次数必须为 0"**；豁免**按文件登记 + 写理由**（域模型 / 状态同步 / 线上 DTO
三处是搬运与传输，不是消费）——与 `mail_status_readers_test.go` 的豁免同一形状，
登记表本身就是清册，不必另造一张。
变异验证：让 MainPage 读一次 `bgBlur` → 判据红，红的信息写着"**停下：那时必须先补
px ↔ 材质档位的映射判据**，而不是把登记值从 0 改成 1"。
SUITE 计数同步：harmony-presets 4→5、harmony-appearance 24→25。
|
2026-09-14 17:17:37 +08:00 |
|
|
|
456ae5a66d
|
跨端: pi 五条评审落地 —— 产物自证替代时间戳代理、静态判据可到期、判据能读一层标识符、值/来源配对规则、归因不许动别人的树
pi 2026-09-14 的评审（`9839f8a9`）五条，逐条落地；其中 §6 的两条是**核对后已成立**，不重复劳动。
## 1 产物自证：`dist/BUILD_INFO.json`（pi §1）
原来那条判据是"`dist` 比 `src` 新"——**代理变量**，pi 指出两层都靠不住：看不见"构建是否
成功"（实测过），而"`dist` 比 `src` 新"也不等于"dist 是从这份 src 构建的"（`checkout`/`cp`/时钟
都骗得过 mtime；我确实用 checkout 造过一次假红）。现在改成**内容自证**：
`scripts/build-info.mjs` 在构建最后一步写 `{gitRev, gitDirty, srcHash, srcFiles, buildCmd, builtAt}`，
判据重算当前指纹再**精确比对**（`test/build-stamp.test.mjs`）——"代理"两个字没有了，
报错能直接读出两边指纹。`release-linux.sh` 打完包把同一份信息打进日志（一个包自带
"它对应哪个源码状态"）。`gitDirty` **只展示不判定**：共享工作区常年是脏的，拿它当红/绿依据
会天天误报。
实测三变异：改 src 内容不重建 → 红（两个指纹都打出来）；BUILD_INFO 记成别的提交 → 红；
**`touch`（只动 mtime）→ 绿** —— 旧判据在这里是**假红**，新判据不误伤，这是它严格更好的地方。
## 2 静态判据的**欠账**与到期（pi §5）
"暂时"不是状态、是待办，规范里写下的"暂时"没有任何机制回来读它。改成可机检的形状：
`run-all.mjs` 登记 `STATIC_ONLY`（5 条：`.ets` 只能验形态）+ **必填到期前提**（探针，真跑
`hdc list targets`）；汇总打 `RESULT static=N`（**欠账余额**）；**前提一旦为真，这些判据当场
变红**并要求"改成行为判据或换更准的前提"。实测：探针恒真 → 5 条同时报"到期"；把前提写成
`'vibes'`（未知探针/陈述）→ 套件红。这是"自报条数 < 登记条数"的**时间版本**。
## 3 判据能解析一层标识符（pi §3）
Go 默认值判据原来"值不是字面量 → 判据读不懂 → 红"，长期结局是有人做一次无害重构
（`BgDim: defaultDim`）就把判据逼宽、再下一步少核一个字段。现在：字面量直接用；
标识符在**同一文件**查 `NAME = <字面量>`；查不到（跨包/计算/iota）才报"读不懂"。
实测：`BgDim: defaultDim` + `const defaultDim = 12` → **绿**（无害重构不再误伤）；
`const defaultDim = baseDim + 0` → 红且报文说"读不懂"。**只解析一层**：再深就是"执行 Go"了。
## 4 §6.7 的可机检分流规则（pi §2）
新增 §6.7.0：**值 → 行为判据，来源 → 静态判据**，理由写成覆盖问题（行为判据只覆盖它跑到的
路径 ⇒ 原理上判不了"有没有别的路绕过去"；来源约束要的是全程序可达性 ⇒ 只有读代码能答）。
两条推论：静态判据判值永远差一个反例、行为判据判来源永远差一条路径；**不是强弱，是分工**，
缺任一条那一对就是假判据。附本仓已有的完整样例（P5 命中区：值判据"≥44"+ 来源判据
"应用点必须引用常量"），新增 §6.8 记欠账机制、§8 记共享树归因纪律。
## 5 值/来源配对补齐 + 让位派生（pi §6 的两条）
- 命中区原来只有值那一半：补**来源**判据（`.ets` 里出现 `minHeight: 44` 这类裸数字 → 红，
报文点出"值判据管数字够不够大、来源判据管用的是不是同一个数字"）。变异：写死 44 → 红。
- "`76` 应从条高派生"：**核对后已成立**（`NAV_CONTENT_RESERVE = NAV_BAR_HEIGHT +
NAV_BAR_BOTTOM + 8`，判据也按常量算）。顺手把裸的 `8` 起名 `NAV_CONTENT_GAP`
（这一族里唯一还需要人判断的数），并加判据钉住**派生关系**：写回字面量 `76` → 红。
## 6 `legacy.bak` 的生命周期（pi §4）：**有意永久残留**，并说清代价
pi 质疑成立：判据钉死"没有任何代码读它"⇒ 也没有任何代码能删它。**否决了"点重置外观时删"**：
最可能点重置的人正是外观被接管的那个人，而这份备份是他唯一的旧值，那时删等于把恢复数据
毁在最需要的时刻。所以定为"有意永久残留"（没有代码路径能判定何时安全删除——那取决于人），
并把代价量出来写进 §7.12：值受 `MAX_DATA_URL_BYTES`（2.4MB）约束，**最坏是一张用户原图的
整份副本**，共享机器上即一份别人的外观；要清就手工 `removeItem`。判据钉住这行**同时**给出
"为什么不删"与"怎么删"（变异：删掉删除方法 → 红）。
## 7 归因方法（pi §6 第三条）：认错并写成纪律
我当天归因 `narrow-layout` 的 3 条红时用了 `git stash push -- MailView.tsx`，动的是**并发写
作者的未提交改动**。结论对、方法不行：它写共享工作区（别人崩溃/`git add -A` 就丢他的活），
而且只影响 tracked 文件（untracked 的 WIP 还在 ⇒ "干净了"是假干净，结论也可能假）。
纪律写进 CRITERIA.md §8：只读手段（`git show HEAD:path > /tmp/...`、`git worktree add`）或直接问作者。
## 验证
`npm test` 全绿（14 个判据文件 + vitest 266 + typecheck），`RESULT static=5`；
`hvigorw assembleHap` BUILD SUCCESSFUL；`scripts/release-linux.sh` 重打 deb（日志带产物指纹）。
提交前两道**真红**按预期挡了我：改了 src 未重建 → build-stamp 红；重建了 dist 未重打包 →
packaging 红。**未验**（照旧不写成已完成）：鸿蒙侧视觉/交互观感、运行期换肤重算（静态判据，
到期前提见 `RESULT static=5`）。
注：本次 `dist`/deb 是在**共享工作区**上构建的，树里含并发写作者未提交的
`CalendarView.tsx`/`index.css` —— 产物里的 `gitDirty: true` + `gitRev` 正是为此留的，
复核时先看那一行。
|
2026-09-14 16:00:34 +08:00 |
|
