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
..
2026-09-13 06:16:59 +08:00
2026-09-14 11:07:03 +08:00
2026-09-15 13:55:01 +08:00
2026-09-18 01:08:04 +08:00
2026-09-19 17:12:40 +08:00
2026-09-08 19:16:35 +08:00
2026-09-14 14:57:18 +08:00
2026-09-14 11:07:03 +08:00
2026-09-08 19:16:35 +08:00
2026-09-14 16:00:34 +08:00
2026-09-08 19:16:35 +08:00
2026-09-12 09:54:31 +08:00
2026-09-08 19:16:35 +08:00
2026-09-14 09:11:36 +08:00
2026-09-12 08:02:30 +08:00