chore: rebuild CentOS7 release package

AGENTS.md

@@ -158,3 +158,37 @@ home-cc-web
   - 顶层是否没有重复 `effort`
 - `ccweb` 能力是否走 `mcpToolCall`，而不是再次退回 `dynamicToolCall`
 - mock / regression 中是否覆盖了上述断言
+
+## Composer 快捷指令设计基线
+
+cc-web 的输入框快捷指令是“本轮消息装饰器 / mention”系统，不是 Codex 原生工具面板，也不是手动填写 MCP tool 参数的执行面板。后续维护 `/`、`$`、`@` 时默认遵守以下语义，避免再次出现 `ccweb_prompt_user` 这类“真实可调用但快捷入口消失或语义跑偏”的问题。
+
+### 1. 三类触发符的职责
+
+- `/`：展示 cc-web 命令和当前会话可用的 MCP server/tool mention。选择 MCP tool 后，应插入类似 `mcp:ccweb/ccweb_prompt_user` 的标记，表示“本轮优先/明确使用这个 MCP”。真正的 tool 参数由模型在 MCP tool call 时生成。
+- `$`：展示 Codex skills。选择后插入 skill mention，语义同样是给本轮消息增加上下文/偏好，不应直接执行 skill 内声明的 MCP。
+- `@`：展示文件/目录和 `.codex/prompts` prompt 模板。不要把 MCP 塞进 `@`，否则会破坏“选文件/选 prompt”的用户预期。
+
+### 2. MCP 候选显示原则
+
+- `/` 中的 MCP 候选必须来自当前会话可运行的配置源：
+  - 内置 `ccweb` MCP：来自线程级 `mcp_servers.ccweb`
+  - 项目 MCP：来自当前会话 `cwd` 下可用的项目级 Codex MCP 配置
+- 不要从历史消息、运行态 tool 名称、skill 的 `agents/*.yaml` 依赖声明里反推出“可用 MCP”。这些只能作为元数据，不代表当前 runtime 真能调用。
+- 如果同一个 MCP server/tool 已经能被当前会话注入并调用，不要在 composer 层对个别工具做硬编码过滤。`ccweb_prompt_user` 这类需要结构化参数的工具，也应作为普通 MCP mention 显示，由模型生成参数。
+
+### 3. MCP mention 不是参数构造 UI
+
+- 选择 `mcp:server/tool` 后，默认只插入 mention 文本，不打开自定义参数表单，也不直接调用 `/api/internal/mcp`。
+- 不要为某个 MCP tool 单独新增 `composer_mcp_tool_submit`、`tool_form`、`open_argument_form` 这类前端直调路径，除非产品明确新增“手动执行 MCP 工具”的独立能力。
+- 如果未来确实要做“手动执行工具”功能，应和 `/` mention 分开设计，不能混进快捷补全语义里。
+
+### 4. 回归覆盖要求
+
+涉及 composer 快捷指令时，至少补这些断言：
+
+- `/` 下应能看到当前会话可用的 MCP server/tool，包括 `mcp:ccweb/ccweb_prompt_user`。
+- `mcp:ccweb/ccweb_prompt_user` 应作为普通 `itemType: 'tool'` 候选插入 mention 文本，而不是参数表单入口。
+- `$` 不展示 MCP tool；`@` 不展示 MCP tool。
+- 不从运行态工具名或历史 `mcp:*` 文本反推 MCP 候选。
+- Codex App 侧仍要另行验证 `thread/start.config.mcp_servers.*` 注入和真实 MCP tool call 链路，不能只测 UI 候选。