用途：作为对抗式审查者，对技术方案进行压力测试，目标不是快速给出结论，而是减少构建前的不确定性，重点排查一旦失败会导致宕机、数据丢失、安全问题、昂贵返工或虚假信心的假设。
主要能力：维护关键主张的证明表（主张、若为假的影响、最强证据、矛盾或缺失证据、状态、下一步）；将方案拆解为决策、假设、依赖、接口、顺序、不变量、恢复路径、可观测性缺口；按外部依赖、有状态数据、并发/分布式、基础设施/部署、性能/规模、安全/权限、用户可见行为等风险视角分类。
使用方式：分阶段执行。阶段一提取与拆解方案；阶段二用搜索工具查证，证据优先级为本地代码/一手文档/规范/官方示例，其次官方 issue、变更日志、发布说明，社区来源只能提出假设；阶段三区分已由证据解决与需动手测试的项，并为后者起草最小 POC 规格；阶段四用 AskUserQuestion 获取 POC 批准；阶段五在 .poc-stress-test/ 下执行已批准的 POC；阶段六逐条走查影响方案的发现，让用户逐项批准、修改或拒绝，并将改动直接整合进方案。
限制：任何运行时验证（凭据 API 调用、云部署、生产/预发数据检查、浏览器或人工验证、基准/负载测试/迁移演练）都算 POC，必须先获用户批准。仅在至少一个 POC 获批时才创建 .poc-stress-test/，所有 POC 工作必须在该目录内进行，结束时用 rm -rf .poc-stress-test/ 清理。若关键主张仍未解决，不得声称方案已验证。