architecture-review

架构评审

找出可能导致技术提案错误、不安全或无法证明的设计选择。评审拟议的行为及权衡，而非文档的篇幅或格式。

使用一名未参与编写提案的新子 Agent。向评审者提供完整上下文，并要求其独立完成评审，不要委派任务。如果你就是评审者，请直接评审。保持只读。

如果无法使用新的子 Agent，请停止并报告独立评审受阻。只有用户明确接受有记录的自我评审时，才能继续。

流程

1. 阅读目标、提案、要求、预期架构、仓库说明、相关现有代码、测试、架构、配置和链接材料。在代码、测试、架构、配置、基础设施或相关运行时证据证实之前，将有关当前系统的说法视为未经核实。
2. 说明问题、受影响的用户、预期结果、成功衡量标准、范围、约束和主要权衡。指出提案未说明的内容。
3. 从输入到可观察结果，追踪一个真实案例。在相关之处说明所有权、验证、状态变更、副作用、响应时机、故障、重试、清理，以及用户看到的内容。
4. 根据下方的评审重点质疑所选设计。寻找更简单的方案，判断是否能以更少的状态、耦合、重复或运维工作，实现相同结果并提供同等证明。
5. 提出重要的未决问题。证据支持时，建议相应答案。不要提出不会影响设计的问题。
6. 返回发现、未决问题、简短评估和一个结论。不要改写提案、规划工作、评审实现代码或实施更改。

评审重点

• 检查是否符合要求和已接受的架构。核实有关当前状态的说法，但不要求新系统已有代码。
• 检查所有权、边界、接口、数据、兼容性、迁移、推出和回滚。
• 在部分故障、重试、取消、并发、启动、关闭和恢复会影响提案时，追踪这些情况。
• 只有当提案所声称支持的规模下，资源受限、延迟、吞吐量、存储、成本、依赖故障和运维恢复可能影响设计选择时，才检查这些方面。
• 检查身份、授权、不可信输入、凭据、破坏性权限和敏感数据处理。
• 对重要规则和故障路径，要求提供可观察的验收标准和证明。不要让实现过程擅自决定面向用户的行为、接口、数据规则、安全策略或故障行为。

重要问题

只有当两个能力相当的实现者可能给出不同答案，且这种差异会影响用户、数据、接口、安全、规模、性能、运维、成本、兼容性或证明时，才报告未决问题。

• **阻塞性：**未得到答案前不应开始实现。
• **重要：**提案应记录答案，但评审者可根据现有证据建议安全的默认方案。

忽略风格问题、可由实现局部安全决定的问题、范围外问题，以及超出提案所声称支持规模的推测性问题。

发现

仅报告可能改变设计或其安全性的缺陷：

• 阻塞项： 该选择不安全、与目标或当前系统相矛盾，或无法从重要故障中恢复。
• 重要项： 该提案允许存在实质差异的实现，或在行为、规模、性能、安全性、运维、兼容性或验证方面留下重大风险。

对于每项发现或待解决问题，请说明其位置、具体故障或歧义、影响、依据，以及最小修正方案或建议答复。如果措辞不清，导致新团队成员无法解释、评估或实施该设计，也请报告。省略其他写作偏好。

用平实的语言。明确说明具体条件、故障和影响。不要用「可能有问题」或「可能有风险」等含糊说法掩盖未知情况。

结论

• Approve：不存在未解决的阻塞项、重要发现或待解决问题。
• Request changes：该提案存在可修复的阻塞项、重要发现或待解决问题。
• Blocked：审查缺少必要背景、仓库依据、专家审查或独立审查人。

说明哪些内容仍未验证。不要因为文档详细，或因为模板的每个部分都已填写，就批准提案。