judge-arch

DECISIONS.md に記載された設計上の決定に照らして、現在のブランチの変更を評価します。

確認

1. リポジトリのルートにある DECISIONS.md を読みます。存在しない場合は、評価を中止してその旨を報告します。
2. 比較元を確認します。ユーザーが指定していない場合は、リポジトリのデフォルトブランチを使用します。
3. 差分全体（git diff <base>...HEAD）を読み、変更されたすべてのファイルを開いて、それぞれの変更を適用先ファイルの文脈で評価します。

評価

DECISIONS.md に記載された各決定を、記載順に確認します。決定は見出しのテキストで特定します。レポート内では常にその名前を正確に使用し、決定に番号を付けてはいけません。

• 対象はファイル内の決定だけです。それ以外の指摘、スタイルに関するフィードバック、改善提案は含めません。
• 違反には、この変更内の根拠を示す必要があります。根拠はファイルと行番号、ファイル全体、または関連するファイル群で示せます。記載された決定に明確に反していない場合は、違反ではありません。
• 同じ誤ったパターンが2か所にあれば、違反は2件です。

レポート

次の構成を正確に出力し、それ以外は何も出力しません。実際の 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 の記載順で ## セクションを1つ設けます。見出しの先頭に ❌ を付け、決定名を大文字にします。違反のない決定については、セクションを設けません。
• 違反ごとに **<where>** ブロックを1つ設け、セクション内ではファイル順に並べます。<where> は、該当箇所が1つの場合は file:line、ファイル全体に関わる問題の場合はファイル名、複数ファイルにまたがる違反の場合は関係するファイル名です。
• What breaks の行には、実際に発生する不具合とそのきっかけを記載します。後から発生するものでもかまいません（例：「loyalty の列名を変更すると refunds が壊れる」）。曖昧な品質上の不満（例：「保守性が損なわれる」）は記載しません。
• Potential fix の行は、他の情報を読まなくても実行できる具体的な内容にします。避けるべきことだけでなく、使用する具体的な仕組みを記載します（例：「マージ処理を app/Actions/MergeIdeas アクションに移し、コントローラーから呼び出す」。単に「コントローラーで処理しない」とは書きません）。

違反がない場合：

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

Every decision in DECISIONS.md holds for this change.