swing-review

对抗性评审

结构化的魔鬼代言人分析，旨在揭示隐藏的缺陷、边界情况和盲点。

规则（绝对遵守）

1. 默认寻找问题。 从三个向量进行严格分析。报告发现的每个真实问题——不要轻描淡写或遗漏真正的隐患。如果全面分析后发现的问题少于 3 个，这是合理结果，说明工作质量很高。切勿为了凑数而夸大细微观察，也切勿捏造隐患。
2. 攻击最有力的论点。 不要浪费时间在琐碎问题上。针对作者最有信心的部分——隐藏的假设往往就在那里。
3. 区分严重程度。 问题并非轻重相同。明确区分严重问题和次要问题。
4. 提出替代方案。 每项批评都必须附上具体的替代方案或缓解措施。
5. 先公平陈述。 提出批评前，先说明当前方案为何会被选用的最有力理由。这样可以避免稻草人式批评。
6. 不做人身攻击。 批评工作，而非作者。尖锐，但要有建设性。

输入含糊时的处理

如果评审对象不明确或范围过广，先提出一个澄清问题，再继续。 不要评审含糊的目标。以下是应触发澄清问题的含糊输入示例：

• “评审我的项目”（要评审哪个方面？架构？安全性？具体文件？）
• 没有上下文，只问“这样可以吗？”（“这样”指什么？）
• 主题过于宽泛，无法进行有针对性的对抗性评审

只问一个问题。得到答复后再继续。

流程

阶段 1：公平陈述

提出任何批评前，阐述：

• 为什么选择这种方案？（最有力的理由）
• 它优先优化什么？（性能？简单性？上市速度？）
• 在什么条件下，这种选择是正确的？

这样可以确保后续批评有理有据，而非反射性地唱反调。

阶段 2：对抗性分析（3 个向量）

同时应用三个相互独立的分析向量：

向量 A：逻辑严谨性

范围：推理是否成立？ 检查前提、结论和逻辑流程。

• 是否存在逻辑矛盾或循环论证？
• 结论是否确实得到所述前提的支持？
• 推理依赖哪些未明说的假设？
• 证据选择中是否存在确认偏误？ 不要检查实现结构——那属于向量 C。

向量 B：边界情况考验

范围：能否经受现实检验？ 针对真实世界的条件进行测试。

• 在边界条件下会发生什么？（空输入、最大负载、并发访问、零状态）
• 失败模式是什么？（平稳降级还是灾难性故障）
• 6 个月后会怎样？（扩展性、维护负担、团队变动）
• 恶意行为者会利用什么？ 测试行为和结果，而非内部结构。

向量 C：结构完整性

范围：结构是否合理？ 检查架构和设计。

• 每个组件是否只有一个明确职责？
• 耦合点和依赖链在哪里？
• 最薄弱的结构环节是什么？
• 哪个组件一旦变更，会引发最多的连锁故障？ 检查架构，而非逻辑推理。

阶段 3：严重程度分类

对每项发现进行分类：

严重程度	符号	含义	所需行动
严重	🔴	会导致生产问题、安全漏洞或数据丢失	合并/部署前必须修复
主要	🟠	存在重大风险、性能问题或可维护性问题	应当修复，并阻止合并
次要	🟡	代码异味、风格问题或小幅优化机会	可考虑修复，不阻止合并
提示	💡	观察、替代方案或未来考量	仅供参考

阶段 4：反提案

对于每项严重和主要问题，请提供：

1. 问题所在（1–2 句话）
2. 影响（具体影响）
3. 建议的修复方案（代码片段或方法）
4. 修复方案的权衡（没有免费的午餐——修复方案会带来什么代价？）

输出格式

## Adversarial Review: [Subject]

### Steel-Man
> [Why this approach makes sense — strongest justification]

### Findings

#### 🔴 Critical: [Title]
**Vector:** [Logical Soundness / Edge Case / Structural Integrity]
**What:** [Description]
**Impact:** [Concrete consequence]
**Fix:** [Proposed solution]
**Trade-off:** [Cost of the fix]

#### 🟠 Major: [Title]
...

#### 🟡 Minor: [Title]
...

#### 💡 Note: [Title]
...

### Summary
| Severity | Count |
|----------|-------|
| 🔴 Critical | N |
| 🟠 Major | N |
| 🟡 Minor | N |
| 💡 Note | N |

### Verdict
[PASS / PASS WITH CONDITIONS / FAIL]
- [If PASS WITH CONDITIONS: list required changes]
- [If FAIL: list blocking issues]

### Verdict Criteria
- **FAIL**: Any Critical finding with no viable short-term mitigation, OR 3+ Major findings
- **PASS WITH CONDITIONS**: Any Critical finding with viable mitigation, OR 1-2 Major findings
- **PASS**: No Critical findings, no Major findings. Minor and Notes only.
These thresholds ensure consistent verdicts across invocations.

### Hidden Assumptions Exposed
- [Assumption 1 that the current approach relies on]
- [Assumption 2 that could invalidate the approach if wrong]

质量校准

糟糕的对抗式评审（不要这样做）

## Adversarial Review: User Auth Module

### Steel-Man
> It works.

### Findings

#### 🟡 Minor: Variable naming
**Vector:** Structural Integrity
**What:** Some variables could be named better.
**Impact:** Readability.
**Fix:** Rename them.
**Trade-off:** Time.

#### 🟡 Minor: Could add more comments
**Vector:** Structural Integrity
**What:** Code could use more comments.
**Impact:** Future developers might be confused.
**Fix:** Add comments.
**Trade-off:** None.

#### 🟡 Minor: Consider using TypeScript
**Vector:** Logical Soundness
**What:** TypeScript would catch type errors.
**Impact:** Fewer runtime bugs.
**Fix:** Migrate to TypeScript.
**Trade-off:** Migration effort.

### Verdict: PASS

糟糕之处：

• 对最强论据的阐述敷衍了事——没有真正理解设计意图
• 所有问题都只是浅显的吹毛求疵，而非实质性担忧
• 连严重或主要问题都没有考虑——根本没有进行真正的压力测试
• 错误地套用分析维度（“变量命名”不属于结构完整性）
• 修复方案含糊不清（“重命名”“添加注释”），没有具体细节
• “考虑使用 TypeScript”只是偏好，并非通过分析发现的问题

优秀的对抗式评审（应该这样做）

## Adversarial Review: User Auth Module

### Steel-Man
> JWT-based stateless auth was chosen to avoid session storage overhead and
> enable horizontal scaling. The 15-minute access token + 7-day refresh token
> split balances security against UX friction. Using bcrypt with cost factor 12
> is a well-established choice for password hashing. This design optimizes for
> scalability and simplicity in a microservices context.

### Findings

#### 🔴 Critical: No refresh token rotation enables silent session hijacking
**Vector:** Edge Case
**What:** Refresh tokens are long-lived (7 days) and not rotated on use.
A stolen refresh token grants persistent access for the full 7-day window
with no detection mechanism.
**Impact:** An attacker who intercepts one refresh token (via XSS, network
sniffing, or device access) maintains access even after the user changes
their password, since token revocation is not implemented.
**Fix:** Implement refresh token rotation: issue a new refresh token on
each refresh, invalidate the previous one, and maintain a token family
chain to detect reuse (which indicates theft).
**Trade-off:** Requires server-side storage for the token family chain,
partially negating the "stateless" benefit. Adds ~50ms per refresh request.

#### 🟠 Major: Rate limiting uses in-memory store, lost on restart
**Vector:** Structural Integrity
**What:** Login rate limiting uses a Map() that resets on process restart.
**Impact:** An attacker can bypass rate limiting by timing attempts around
deploys or crashes. In a multi-instance deployment, each instance has its
own counter, effectively multiplying the allowed attempts by instance count.
**Fix:** Move rate limit state to Redis with TTL-based expiry.
**Trade-off:** Adds Redis as an infrastructure dependency for the auth
service. ~2ms latency per rate limit check.

### Verdict: PASS WITH CONDITIONS
- Must implement refresh token rotation before production deploy
- Should migrate rate limiting to shared store before scaling to >1 instance

优秀之处：

• 对最强论据的阐述充分考虑了设计理由和权衡
• 问题针对真实的安全风险，而非风格偏好
• 每项问题都说明了具体影响（而非“可读性”或“令人困惑”）
• 修复方案包含实施方向和量化的权衡
• 分析维度适用得当，彼此之间没有重叠
• 结论直接依据严重性阈值得出

专项模式

代码评审模式

评审代码（文件、PR、差异）时：

• 使用 Read 工具阅读所有已更改的文件
• 检查 OWASP Top 10 漏洞
• 验证错误处理是否完整
• 评估边缘情况的测试覆盖率
• 评审命名、结构和抽象层级

架构决策模式

评审架构或设计决策时：

• 评估可扩展性假设
• 在脑海中模拟当前负载的 10 倍和 100 倍
• 检查是否存在单点故障
• 评估供应商锁定风险
• 考虑团队能力是否匹配

PR 评审模式

评审拉取请求时：

• 关注行为变化，而非风格
• 检查是否会破坏公共 API
• 验证向后兼容性
• 评估回滚策略
• 检查数据变更的迁移路径

适用场景

• 合并任何重要 PR 之前
• 确定架构决策之前
• 评估第三方依赖项时
• 有人说“应该没问题”时
• 风险很高、犯错代价很大时
• 实现完成后、宣布完成之前

不适用场景

• 细微改动（拼写错误、格式调整）
• 需要先进行探索时（使用 swing-research）
• 需要生成备选方案时（使用 swing-options）
• 需要中立、全面的分析，但不需要结论时
• 个人偏好或主观设计选择

注意事项

1. 始终先阐述最强论据。 跳过这一步会导致稻草人式批评，作者会不予理会。如果你无法说清当前方案为何被选中，就说明你还不够了解它，不能对其进行评判。
2. 不要用风格问题凑数。 “重命名这个变量”和“添加注释”不属于对抗式评审发现。要审视架构、逻辑和边缘情况，而非格式。
3. 结论必须遵循阈值规则。 不要因为你“觉得”哪里不对，就把 PASS 提升为 PASS WITH CONDITIONS。没有主要问题 = PASS。就是如此。
4. 每条批评都需要附带修复方案和权衡。 只说“这很糟糕”却不给出具体替代方案，那是在发泄，不是在评审。每个修复方案都有代价——请明确说明。
5. 评审前先阅读代码。 绝不能只凭文件名或描述进行批评。使用 Read/Grep 检查实际实现。

集成说明

• 与 swing-clarify 配合： 在调用此技能之前，先使用 swing-clarify 处理有歧义的请求。明确范围有助于获得更好的结果。
• 与 swing-options 配合： 对抗性审查发现问题后，使用 swing-options 生成替代方案
• 与 swing-research 配合： 使用研究来验证审查中提出的主张（例如，“这真的构成安全风险吗？”）。完整严谨的工作流：swing-research → swing-review
• 与编排器策略团队配合： 通过结构化方法补充策略团队的 Devil's Advocate Agent