judge-arch

根据 DECISIONS.md 中的设计决策，评审当前分支的更改。

查看

1. 阅读仓库根目录中的 DECISIONS.md。如果文件不存在，请停止评审并报告这一情况。
2. 确定基准分支：使用仓库的默认分支，除非用户指定了其他分支。
3. 阅读完整差异（git diff <base>...HEAD），并打开每个已更改的文件，以便结合文件上下文评审每项更改。

评审

按 DECISIONS.md 中各项决策的顺序逐一检查更改。决策以其标题文本标识——在报告中始终使用该准确名称，切勿为决策编号。

• 仅评审文件中列出的决策。不提供其他发现、风格反馈或改进建议。
• 违规必须有证据支持，且能在本次更改中明确指出：具体文件和行、整个文件，或涉及的一组文件。如果某项更改没有明确违反书面决策，就不算违规。
• 同一种错误模式出现在两个位置，算两项违规。

报告

严格按以下结构输出，不得包含其他内容。使用真正的 Markdown 标题，以便报告按决策分组显示：

# JUDGMENT · <branch> vs <base> · <n> violations

## ❌ <DECISION NAME, UPPERCASE>

**<where>**
<what the code does, one sentence>
- **What breaks:** <the concrete consequence of shipping this as is, one sentence>
- **Potential fix:** <the smallest concrete change that satisfies the decision, one sentence>

报告规则：

• 每项违规决策对应一个 ## 小节，按 DECISIONS.md 中的顺序排列。标题前加上 ❌，并将决策名称设为大写。没有违规的决策不创建小节。
• 每项违规对应一个 **<where>** 块，并在所属小节内按文件排序。<where> 可以是单个位置的 文件:行号、涉及全文件问题的文件名，或涉及多个文件时的相关文件名。
• What breaks 一行须描述有具体触发条件的实际故障，即使触发条件要到以后才出现（例如：“重命名 loyalty 中的列后，refunds 会出错”），不得使用含糊的质量问题描述（例如：“这会降低可维护性”）。
• Potential fix 一行必须提供无需查阅其他内容即可执行的方案：明确指出应采用的具体机制，而不只是指出应避免什么（例如：“将合并步骤移入 app/Actions/MergeIdeas 操作类，并让控制器调用它”，而不是“不要在控制器中这样做”）。

如果没有违规：

# JUDGMENT · <branch> vs <base> · clean

Every decision in DECISIONS.md holds for this change.