Receiving Feedback — 接审反馈

先由 Planner 按 handoff-loop 判定状态。只有有效 EXECUTING 且反馈属于当前批准路线内修复时，Executor 才能实施；新路线、模型、外部影响或风险回停点二，需求/验收变化回停点一，BLOCKED 不实施。

接审不是社交应对，是技术对话：先验证再实现，先澄清再假设，技术正确优先于礼貌舒适。

核心心态

"先验证再实现，先澄清再假设，技术正确优先于社交舒适。"

Review 反馈是技术讨论而非人情往来：聚焦代码与交付物本身，不处理情绪。

六步流程

第一步：完整阅读

不急着回应。 读完整个评论后再组织回应。

• ❌ 坏：读了第一句就开始写辩护。
• ✅ 好：读完整个评论 → 理解完整上下文 → 再回应。

第二步：复述需求

用自己的话复述对方反馈，确认理解一致。

• 对方说"这个函数职责过多，校验、转换、持久化揉在一起"。
• 你的复述："你是建议我拆成三个独立函数：校验、转换、持久化？"

第三步：对照代码库验证

回应前先拿实际代码 / 交付物核对反馈是否成立。

• 对方说"这里 user 为空会抛错"。
• 核对代码：user.name 前没有空值判断 → 反馈成立。
• 或发现上下文：类型系统保证 user 非空 → 反馈不成立。

第四步：评估技术合理性

结合当前技术栈与上下文判断反馈是否适用。

• 对方建议"这里应该用 useMemo 优化性能"。
• 评估：该组件是否频繁重渲染？计算是否昂贵？框架版本是否已自动优化？

第五步：实质回应

给出技术性确认，或带证据的异议。本项目异议不直接与 Reviewer 对辩——一律携带证据返回 Planner，由 Planner 转达。

• ✅ 好："已修。拆成 validate()/transform()/persist() 三个函数。"
• ✅ 好（异议）："这条我保留意见，证据是……（代码位置 / 复现路径），请 Planner 转达。"
• ❌ 坏："你说得太对了！" / "我觉得没必要。"

第六步：逐条实现验证

逐条对应反馈实现并验证，不一次性大改。

• 反馈 1：加空值判断 → 实现 → 测试 → 验证 → 进入下一条。
• 作用对象：本步骤由接手 Review 重写后的执行上下文应用（逐条对应 FAIL 问题实现 + 验证）；执行端不做"原地修改已交付物"的理解。

BLOCKED 语义融合

反馈属于"人工信息 / 权限 / 业务裁决"性质时，执行端不"接审"，而是立即标 BLOCKED 返回 Planner，保留证据，等用户裁决。不为凑次数继续撞（对齐 executor.md 协议与 handoff-loop）。

反模式：敷衍式同意（Agreement Theater）

表演式同意浪费双方时间、不提供任何信息。"说得好"是噪音，不是信号。

行动证明理解，语言冗余——用改动证明你懂了，不用漂亮话。

恰当的简短技术性确认（当学到新东西时）：

• ✅ "我之前没考虑到这个边界。已在 42 行补处理。"
• ✅ "线程安全这点说得好。已在 67 行加互斥锁。"

何时需要异议（经 Planner 中转）

带技术理由异议的情形：

异议落点：携带证据返回 Planner，由 Planner 转达 Reviewer；属人工信息/权限/业务裁决性质的异议直接走 BLOCKED。

声称已修之前的验证清单

写"已修 / 完成"之前：

• 改动已实现
• 全量测试通过（不只是改过的文件）
• 反馈中提到的具体行为已验证
• 边界情况已测试
• 未引入非预期副作用

无法验证时如实说明：

• ✅ "已实现，但我无法验证，因为……请在你那边确认。"
• ❌ "应该修好了。" / "我猜修好了。"

反模式清单

内容改编自 obra/superpowers（Jesse Vincent），MIT 协议。 Content adapted from obra/superpowers by Jesse Vincent (@obra), MIT License.