跨端: 日历「新建」按钮补文字（原先只有一个加号）+ 详情页三处缺失登记

## 一、日历的「新建」按钮（对齐 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` 新增三条登记（断点差异 / 列表附件数 / 详情页三功能）。

client/harmony/entry/src/main/ets/pages/CalendarPage.ets

@@ -38,6 +38,7 @@ import { CalendarApi } from '../api/CalendarApi';
 import { hilog } from '@kit.PerformanceAnalysisKit';
 import { CalendarEvent, CalendarEventInput, LunarLabels, LunarRangeResponse } from '../model/Models';
 import { Theme } from '../common/Theme';
+import { AmIcon } from '../common/Icons';
 import {
   DayCell,
   monthGrid,
@@ -1205,13 +1206,29 @@ export struct CalendarPage {
           .fontColor(this.icsBusy ? Theme.textSubtle : Theme.accent)
           .margin({ left: 8 })
           .onClick(() => { this.exportIcs(); })
-        Button('＋')
-          .fontSize(Theme.fontBody)
-          .backgroundColor(Theme.accent)
-          .fontColor(Theme.accentFg)
-          .height(26)
-          .margin({ left: 8 })
-          .onClick(() => this.openNew())
+        /*
+         * 新建 —— 对齐 WebUI `CalendarView.tsx:362-369`：**蓝底 + 图标 + 文字「新建」**。
+         *
+         * ★ 2026-09-19 审计改：原先这里是光秃秃的 `Button('＋')`。
+         *   而 WebUI 那个按钮是 `px-2.5 py-1 bg-blue-600 text-white text-xs` +
+         *   `<PlusIcon/>` + **「新建」两个字** —— 它是工具栏里唯一的实心按钮，
+         *   视觉上是"主动作"。只画一个加号会丢掉这层语义：
+         *   用户要猜"这个加号加什么"（加日程？加订阅？加日历？）。
+         *
+         * 上面「导入/导出」两条也刚因此保留为**文字**而不是图标
+         * （理由见它们上面的注释：WebUI 有 title 可悬停，手指没有悬停）。
+         * 同一个道理在这里更成立 —— 主动作不该是个谜语。
+         */
+        Row({ space: 4 }) {
+          AmIcon({ iconName: 'plus', iconSize: 13, iconColor: Theme.accentFg })
+          Text('新建').fontSize(Theme.fontSmall).fontColor(Theme.accentFg)
+        }
+        .padding({ left: 10, right: 10 })
+        .height(26)
+        .backgroundColor(Theme.accent)
+        .borderRadius(Theme.radiusControl)
+        .margin({ left: 8 })
+        .onClick(() => this.openNew())
       }
       .width('100%')
       .padding({ left: 10, right: 10, top: 6, bottom: 4 })

docs/DEBTS.json

@@ -8,7 +8,8 @@
     "已结算（2026-09-14）：calendar-today-recompute —— P6 第 1 步（日历页 pages/CalendarPage.ets）落地，today 走 `@Prop @Watch('onVisibleChanged') visible` 在 pane 变可见时重算（另有 aboutToAppear 覆盖重新挂载），判据 test/harmony-calendar.test.mjs 的「★ today 在 pane **变可见时**重算」。结算即从此清单移除，余额里不再计这一笔。",
     "已结算（2026-09-19）：gesture-semantics —— P6 第 3 步（左右滑动翻页）落地：鸿蒙侧 `CalendarPage.ets` 加了 `PanGesture`、判定逻辑在纯逻辑层 `model/Calendar.ts` 的 `judgeSwipe`。按该条自己的口径（「鸿蒙侧出现滑动手势代码时**立即建**」）同步建了语义契约判据 `test/cross-client-gesture.test.mjs`（8 条）—— 按 (b) 口径钉**语义**不钉数值：左滑=下一段/右滑=上一段/纵向优先/快滑窗口/手势与按钮共用同一翻页函数/无边界回弹/有意差异被记录/方向写反必红。另在 `harmony-logic.test.mjs` 加了行为判据（跑 `judgeSwipe` 的四道门）。结算即从此清单移除，余额里不再计这一笔。",
     "2026-09-19 新增 wide-breakpoint-divergence：两端断点不同且含义不同（审计发现，此前无记录）。它不是\"已确认的缺陷\"，而是**未决的口径** —— 登记它是为了让「两者不同」这个事实本身可见，而不是让它藏在两处代码里。",
-    "2026-09-19 新增 mail-list-attachment-count：邮件列表的附件数两端都拿不到（WebUI 那段是死代码）。鸿蒙侧只补了有真数据的「抄送 N」。"
+    "2026-09-19 新增 mail-list-attachment-count：邮件列表的附件数两端都拿不到（WebUI 那段是死代码）。鸿蒙侧只补了有真数据的「抄送 N」。",
+    "2026-09-19 新增 harmony-maildetail-missing-three：邮件详情页缺三块功能（改名建议 / 转发 / 预算编辑），服务端都已支持。"
   ],
   "debts": [
     {
@@ -124,6 +125,14 @@
       "where": "server/internal/handler(邮件列表的响应构造) —— 客户端侧见 client/harmony/entry/src/main/ets/pages/MainPage.ets 的 MailItem",
       "kind": "scope",
       "note": "2026-09-19 审计发现：**两端都没有**附件数可用，而 WebUI 里那段代码看起来像有。实测 `GET /me/mail/inbox` 的回包字段列表里**既没有 `attachments` 也没有 `has_attachments`** ⇒ `MailList.tsx:351` 的 `mail.attachments?.length ?? 0` 在列表里**恒为 0**，那个 📎 标记在 WebUI 上**从不出现**（死代码）。鸿蒙这一轮只补了「抄送 N」（`cc_list` 服务端确实返回，真数据），**有意不抄附件标记** —— 照抄一个不工作的东西只会多一处「看起来有、永远不亮」的代码。要真做这个功能，先让服务端在列表响应里带上附件计数（一次 JOIN 的事），然后两端一起接。"
+    },
+    {
+      "id": "harmony-maildetail-missing-three",
+      "count": 3,
+      "due": "鸿蒙详情页对齐 WebUI 时（三块功能，服务端都已支持）",
+      "where": "client/harmony/entry/src/main/ets/pages/MailDetailPage.ets （对照 client/electron/src/components/MailView.tsx）",
+      "kind": "scope",
+      "note": "2026-09-19 审计发现：邮件详情页缺**三块 WebUI 有的功能**，而且**服务端三块都已支持**（不是做不了）：① `RenameProposalBar`（MailView.tsx:324）—— Agent 建议改会话别名，人确认/驳回。服务端 `server/internal/handler/rename_proposal.go` 已在解析 `propose_alias` 标记并把提议从正文剥掉。**这条对寻址稳定性很重要**（WebUI 那里的注释：「Agent 干到一半自己改掉，人上一秒记住的地址下一秒就失效」）。② `ForwardBar`（MailView.tsx:378）—— 转发。服务端 `forward.go` 完整（含 `forwardSubject` 的 Fwd: 叠加处理）。③ `BudgetEditor`（MailView.tsx:235）—— 会话往返预算编辑（`max_rounds`，服务端 `forward.go:304` 有此字段）。三条都不是顺手能补的量级（各含交互 + 接口 + 状态），所以先登记，不在审计那一批里硬塞 —— 硬塞的结果是每条都半成品。"
     }
   ]
 }