refactor: clean CLI taxonomy — canonical subcommands, merged memory.update, no aliases

- calendar: split write → create/read/update/delete/share
- contacts: rename lookup → read
- memory: merge write+forget → update (unified action field in operations)
- Remove all alias/normalization logic from adapter and handlers
- Update tool_postprocessor ui_hints builders to canonical keys
- Remove frontend legacy TOOL_CALL_START/ARGS/END events and ToolCallItem
- Update SKILL.md files and protocol docs
- Update tests and settings screens

docs/protocols/agent/api-endpoints.md

@@ -161,19 +161,28 @@ run 过滤语义：
   messages: Array<{
     id: string;
     seq: number;
-    role: "user" | "assistant";
+    role: "user" | "assistant" | "tool";
     content: string;
+    suggestedActions?: string[];
     attachments?: Array<{       // user 附件签名链接列表
       mimeType: string;
       url: string;
     }>;
-    ui_schema?: object | null; // assistant 的编译后 UI
+    ui_schema?: object | null; // tool 的编译后 UI
     timestamp: string;         // ISO-8601
   }>;
 }
 ```
 
-tool 消息在存储层用于运行时上下文续接，不在 `/history` 对外返回。续接时以 `metadata.tool_agent_output` 作为主信源（`content` 为轻量摘要）。
+`/history` 会返回 tool 消息用于 UI 重建。tool 消息的 `ui_schema` 来自 `metadata.tool_agent_output.ui_hints` 的编译结果。
+
+`messages[].content` 在当前协议中始终是字符串：
+
+- assistant: answer 文本
+- tool: tool result 的 JSON 文本投影
+- user: 用户输入文本
+
+结构化字段（如 tool result/ui hints、suggested actions）通过 metadata 派生，不要求把 `content` 升级为 JSON 对象。
 
 可见性说明：
 

docs/protocols/agent/sse-events.md

@@ -127,6 +127,11 @@ data: <json>
 
 ### 3.3 Tool 事件
 
+前端渲染约束（当前实现）：
+
+- tool UI 渲染仅消费 `TOOL_CALL_RESULT.ui_schema`。
+- `TOOL_CALL_START` / `TOOL_CALL_ARGS` / `TOOL_CALL_END` 仅作为执行观测事件保留，前端主聊天流不渲染中间态卡片。
+
 #### `TOOL_CALL_START`
 
 ```json
@@ -184,18 +189,22 @@ data: <json>
   "tool_call_id": "...",
   "tool_call_args": {},
   "status": "success" | "failure" | "partial",
-  "result": "...",
-  "error": null
+  "result": {},
+  "error": null,
+  "ui_schema": {}
 }
 ```
 
-说明：`TOOL_CALL_RESULT` 不再携带 `ui_schema`。tool 结果通过 `result` 字段提供紧凑、结构化、可执行的信息（优先包含 id/status/count 等关键事实），用于 agent 后续推理与工具编排。
+说明：`TOOL_CALL_RESULT` 中 `result` 字段提供紧凑、结构化、可执行的信息（优先包含 id/status/count 等关键事实），用于 agent 后续推理与工具编排。若对应工具输出存在 `ui_hints`，后端会在 codec 层编译得到 `ui_schema` 并随事件下发。
+
+当前 `ui_hints` 策略：仅对当前 canonical CLI 的 CRUD 子命令生成（`calendar.create/read/update/delete`、`contacts.read`、`memory.update`）；`calendar.share` 不生成 `ui_hints`。
 
 补充约束：
 
 - `tool_call_id` 必须与同次调用的 `TOOL_CALL_START/ARGS/END.toolCallId` 一致，并在每次工具调用中保持唯一。
 - `tool_call_args` 仅表示输入参数快照。
 - `result` 仅表示执行输出事实，不重复 `tool_call_args` 已包含的输入参数。
+- `ui_schema` 为可渲染 UI 线缆格式；其源数据来自 `metadata.tool_agent_output.ui_hints`。
 
 #### 3.3.1 tool 名称展示规范（前端本地化）
 
@@ -206,21 +215,22 @@ SSE 协议中的工具名字段保持后端原样，不做服务端翻译：
 
 前端展示层统一通过工具名本地化映射进行中文渲染，要求兼容两类命名风格：
 
-- dot 风格：`memory.write`、`calendar.read`
-- snake 风格：`memory_write`、`calendar_read`
+- dot 风格：`memory.update`、`calendar.read`
+- snake 风格：`memory_update`、`calendar_read`
 
 当前规范映射（canonical -> 中文）如下：
 
 - `calendar.read` -> `读取日程`
-- `calendar.write` -> `写入日程`
+- `calendar.create` -> `创建日程`
+- `calendar.update` -> `更新日程`
+- `calendar.delete` -> `删除日程`
 - `calendar.share` -> `共享日程`
-- `user.lookup` -> `查找联系人`
-- `memory.write` -> `写入记忆`
-- `memory.forget` -> `清理记忆`
+- `contacts.read` -> `读取联系人`
+- `memory.update` -> `更新记忆`
 
 兼容策略：
 
-1. 优先按 alias 归一化（例如 `memory_write` -> `memory.write`）
+1. 优先按 alias 归一化（例如 `memory_update` -> `memory.update`）
 2. 命中 canonical 映射后展示中文
 3. 未命中时回退显示原始工具名（保证向后兼容）
 

docs/protocols/agent/tool-protocol.md

@@ -24,10 +24,11 @@
 
 1. 项目 CLI 是受限工具执行边界，不是通用 shell。
 2. agent 只暴露一个 AgentScope tool：`project_cli`。
-3. skills 只负责向 agent 披露如何使用 `project_cli`，不承担执行 transport。
+3. skills 只负责向 agent 披露如何使用 `project_cli`，不承担执行 transport 或权限决策。
 4. Router 是 CLI 的唯一命令分发核心，只允许白名单 `command + subcommand`。
 5. 每个 CLI 子命令绑定 Python handler。
 6. handler 只能调用允许的内部能力，不开放任意系统命令执行。
+6.1 `project_cli` 命令权限由 runtime `allowed_commands` 与 CLI router 白名单共同约束，不能由 skills 启用状态隐式放开。
 7. `ToolAgentOutput.result` 是 canonical machine-oriented tool result。
 8. `ToolResponse` 不承载完整 `ToolAgentOutput`，只承载给 agent 使用的文本投影。
 9. tool UI 只来自 `ToolAgentOutput.ui_hints`，不再经过 worker `ui_hints -> ui_schema` 链路。
@@ -84,6 +85,12 @@ CLI 运行时输入通道采用“两者结合”：
 - CLI 不接受来自自然语言/模型参数的任意 token 字符串。
 - backend runtime 只能通过受控环境变量注入认证凭证。
 
+权限边界：
+
+- `enabled_skills` 仅控制 skill 文档可见性与注册。
+- `allowed_commands` 控制 `project_cli` 可执行命令集合。
+- 两者职责解耦，避免“技能可见即命令授权”的隐式耦合。
+
 ## 5. CLI Output Contract
 
 CLI handler 的原始成功输出必须是统一结构化结果。
@@ -148,6 +155,17 @@ post-processor 负责生成完整 `ToolAgentOutput`，至少包括：
 - tool 失败时 `error` 必须为结构化对象。
 - `status` 必须是 `success | failure | partial`。
 
+`ui_hints` 输出范围（当前协议）:
+
+- 输出：当前 CLI canonical 子命令中的 CRUD 调用
+  - `calendar.create`
+  - `calendar.read`
+  - `calendar.update`
+  - `calendar.delete`
+  - `contacts.read`
+  - `memory.update`
+- 不输出：非 CRUD 子命令（例如 `calendar.share`）
+
 ## 8. ToolAgentOutput Contract
 
 `ToolAgentOutput` 用于系统内部和前端消费，不直接作为模型上下文主输入。
@@ -176,6 +194,16 @@ post-processor 负责生成完整 `ToolAgentOutput`，至少包括：
 - tool message 的 UI 恢复从 `metadata.tool_agent_output.ui_hints` 读取，编译为 `ui_schema` 后返回。
 - tool message `content` 仍是 `result` 的 JSON 文本投影。
 
+### 9.1 `messages.content` 存储类型决策
+
+- 当前决策：`messages.content` 继续保持 `text`，不迁移到 `jsonb`。
+- 原因：
+  - `messages` 表承担多角色消息（user/assistant/tool），`content` 统一作为文本载荷更稳定；
+  - tool 的结构化数据已经由 `metadata.tool_agent_output.result` 与 `metadata.tool_agent_output.ui_hints` 承载；
+  - `/history`、SSE、context rebuild 当前都按“`content` 文本 + metadata 结构化字段”工作，避免双轨 schema 演进；
+  - 实测出现过 dict 直接写入 `messages.content` 导致驱动类型错误（`expected str, got dict`），保持 `text` 可减少写入歧义。
+- 约束：凡写入 `messages.content` 的数据必须是字符串；结构化对象必须进入 `metadata`。
+
 ## 10. SSE Contract
 
 规则：