FeedbackGate

Feedback Gate Protocol

核心规则

完成用户请求后，禁止直接结束回复。必须调用 feedback_gate_chat MCP 工具打开弹窗，等待用户反馈。只有用户在弹窗中回复 "TASK_COMPLETE"、"Done" 等完成信号后才可结束。

⚠️ 内容分发原则（最常见的误用）

Cursor 主聊天窗口是主要回复通道，Feedback Gate 弹窗只是确认关卡。

• ✅ 主回复（Cursor 聊天窗口）：所有工作输出、分析结果、代码变更说明、命令执行结果、详细解释。
• ✅ 弹窗 message：1-2 句话的简短摘要 + 询问是否继续/完成。
• ❌ 绝对禁止：把完整工作结果、代码块、日志输出、长段落放进弹窗 message。

正确示例

# 主回复中：
已完成数据库迁移，新增 users 表，修改了 3 个文件...（完整内容）

# 弹窗 message：
"已完成数据库迁移。需要其他修改吗？"

错误示例

# 主回复中：（空或只有一句话）

# 弹窗 message：
"已完成数据库迁移。以下是变更详情：\n1. 新增 users 表...\n2. 修改了 migration.sql...\n3. 更新了 schema.prisma...\n..."

判断标准：弹窗 message 不应超过 100 字。如果超过，说明内容应该在主回复中。

工作流程

1. 执行任务：正常完成用户请求（编码、分析、工具调用等）。
2. 在主回复中输出完整结果：所有工作内容写在 Cursor 主聊天窗口。
3. 打开 Feedback Gate：调用 feedback_gate_chat，仅传入简短摘要（≤100 字）。
4. 处理反馈：收到用户弹窗回复后继续执行，然后再次调用 feedback_gate_chat。
5. 循环直到完成：重复步骤 3-4，直到用户发送完成信号。

工具调用格式

• MCP Server: user-feedback-gate
• Tool Name: feedback_gate_chat
• 调用方式: CallMcpTool(server="user-feedback-gate", toolName="feedback_gate_chat", arguments={...})
• 绝不假设工具不可用。如果调用报错，重试一次后再告知用户。不要因为"找不到"而跳过。

CallMcpTool:
  server: "user-feedback-gate"
  toolName: "feedback_gate_chat"
  arguments:
    message: (≤100字的简短摘要 + 提问，如"已完成XX。需要调整吗？")
    title: "Feedback Gate" (可选)
    context: (可选，用于内部追踪，不展示给用户)
    session_id: (首次调用时生成一个随机 UUID，后续所有 re-entry 调用复用同一个值)
    workspace_path: (当前项目的绝对路径)

session_id 规则

• 首次调用：生成一个 UUID（如 crypto.randomUUID() 或类似方式），作为 session_id 传入。
• 后续所有调用：复用同一个 session_id，包括 [WAITING] 后的 re-entry 和后续新任务的 feedback gate 调用。
• 一个对话 = 一个 session_id，整个对话生命周期不变。不同的 Cursor agent chat 使用不同的 session_id。
• ⚠️ session_id 是插件在同一个 Cursor 窗口内区分对话的唯一依据（一个窗口只有一个 MCP 进程，PID 无法区分窗口内的多个对话）。
  • 换了 session_id = 插件认为这是另一个对话 → 会开一个新 Tab，原对话的排队消息不会送到新 Tab。
  • 只有真正的新对话（用户新开的 chat）才允许生成新 UUID；同一个对话里任何时候都不要换。

约束

• 每次回复结束前必须调用此工具，无例外。
• 如果工具不可用，告知用户 MCP 服务器可能未运行。
• 运行整个应用（Web 服务器、长期进程等）前需先征得用户确认。