Superpowers 系列（十）：边界对照
Superpowers 和正式需求生命周期看起来相似，是因为它们最终都会出现设计、计划、实现、审查和验证。但它们不是同一层系统。Superpowers 是方法链路，生命周期 Controller 是状态权力系统。
这篇把整个系列收住：Superpowers 的流转为什么稳定，它稳定在哪一层，又为什么不能直接替代需求生命周期 Controller。
Superpowers 的流转控制是“下一步方法”控制
Superpowers 没有一个全局 phase 表，也没有单写 Handoff。但它通过 Skill 之间的出口规则，形成了一条方法链。
这条链的稳定性来自“每个方法知道下一个方法”。README 的 Basic Workflow 也按这个顺序组织：先 brainstorming，再 worktree 和 plan，再执行、TDD、review，最后 branch finishing。设计批准后进入计划，不直接进入实现。计划完成后选择执行方式，不让 Agent 自由发挥。执行完成后进入验证和分支收尾，不把“写完代码”当成交付结束。
它控制的是下一步该用什么工程方法。
生命周期 Controller 控制的是“谁有权改事实”
需求生命周期 Controller 要回答的是另一组问题：
- 当前需求处于哪个 phase；
- 当前 active Work Order 是谁；
- 哪个角色拥有哪个产物写入权；
- Return 是否匹配当前 Work Order；
- ledger_delta 是否能被原子应用；
- DRET 是否应该打开、关闭或路由；
- 是否进入设计审查、开发、实现审查或验收审查。
这些问题不是 Superpowers 的方法链路能自然解决的。Superpowers 可以让 Developer 更可靠地开发，但它不应该让 Developer 自己宣布需求进入验收。它可以帮助 Designer 澄清设计，但它不应该替 Design-Reviewer 判定设计通过。它可以要求 fresh verification，但 fresh verification 不等于 Accept-Reviewer 的验收结论。
最容易混淆的场景：实现发现设计问题
假设开发中发现原设计错了。
Superpowers 的方法层会说：停止盲目实现，重新思考设计或计划，必要时回到 brainstorming 或修改 plan。
生命周期层应该说：Developer 不能直接改正式设计并继续推进；Developer 应提交 DRET 或结构化 return_to_design，由 Controller 路由回 Designer，Designer 更新设计，再经过 Design-Reviewer。
表面看两者都是“回到设计”。本质差别是：Superpowers 关注 Agent 不要继续错误实现；生命周期 Controller 关注谁有权修改设计事实，以及修改后如何重新获得审查资格。
更好的融合方式：方法 Skill 放进角色内部
两者最稳的融合方式不是互相替代，而是分层。
Controller 保持瘦，只管理状态、权限、路由和事实写入。角色内部可以使用 Superpowers 方法提升质量。
这种分层有三个好处：
- Controller 不会膨胀成“超级大脑”。
- Superpowers 不会越权写生命周期事实。
- 角色方法可以演进，而不破坏流程状态机的稳定性。
判断边界的一句话
可以用一个判断式区分两层：
如果一条规则会改变 phase、Work Order、Return、ledger_delta、DRET、验收状态或正式需求事实，它属于生命周期 Controller。
如果一条规则只指导某个角色在当前授权范围内如何提问、计划、测试、调试、审查或收尾，它属于 Superpowers 这种行为控制层。
这个边界立住后，Superpowers 不再是“另一个需求流程”，而是角色内部的方法增强包。它让 Agent 更像靠谱工程师；生命周期 Controller 让多角色需求交付更像可恢复、可审计的组织系统。
最后的设计取舍
Superpowers 的优点是轻，安装后就能通过入口技能和方法链路改变 Agent 默认行为。它不需要每个任务都进入正式台账，因此适合大量普通编码任务。
生命周期 Controller 的优点是硬，能定义状态、角色、事实和返工协议。它适合跨角色、跨仓库、需要审计和验收的需求交付。
一个成熟系统不应该二选一。更合理的组合是：用 Controller 管交付权力，用 Superpowers 管角色习惯。前者防止流程乱，后者防止执行飘。
参考资料：
系列导航：