Files
cc-web/.trellis/tasks/07-16-composer-slash-trigger/research/composer-slash-analysis.md
2026-07-16 18:04:37 +08:00

1.5 KiB
Raw Blame History

Composer slash 行为调研

根因

  • public/app.js 的 findActiveComposerToken 对 / 使用 value.startsWith('/') 特判,只允许整段首字符触发;@、$ 则允许行首或空白后触发。
  • public/app.js 的 sendMessage 对任意 text.startsWith('/') 都进入命令发送分支,未知路径也不会走 submitUserMessage。
  • server.js 的 WebSocket 消息分发对任意 slash 前缀调用 handleSlashCommand,其默认分支只发未知指令系统消息,随后不调用 handleMessage。
  • scripts/regression.js 现有契约断言未知 slash 必须恢复草稿,与新需求相反,需要更新为“提示但继续普通发送”。

推荐实现

  • 前端新增基于 SLASH_COMMANDS 第一 token 精确匹配的已知命令判断,仅已知命令进入现有 slash 分支。
  • 服务端让 handleSlashCommand 返回是否已处理;未知分支先发送提示并返回 false,WebSocket 分发随后调用正常 handleMessage。
  • findActiveComposerToken 统一解析 (^|\s)([/@$])([^\s]*)$ 的当前行 token 边界,保留既有插入逻辑。
  • 回归测试同时覆盖源码契约和 WebSocket 真实行为。

风险

  • 必须确保未知 slash 的系统提示不带 preserveComposerDraft,否则会在普通发送后错误恢复已发送内容。
  • 必须确保已知命令仍携带 requestId,失败时仍可恢复草稿。
  • 服务端必须独立判断,不能只信任前端,避免旧客户端仍拦截未知 slash。