Instruction file imported from Takas0522/change-log-lab (.github/instructions/code-review.instructions.md). Copyright stays with the author.

Copilot Code Review チェックリスト（C# / Angular / SQL）

共通（すべてのコード）

• 正確性: 仕様・要件に対するロジックの正しさ、境界値・例外ケースの網羅を確認する。テストやガード条件の欠落を検出せよ。
• 入力検証とセキュリティ: 外部入力の検証、認証・認可の漏れ、秘匿情報のハードコード、SQL インジェクション／XSS のリスクを指摘せよ。
• エラーハンドリング/ロギング: 例外の握り潰し、汎用 catch の濫用、再スローの不備、構造化ログ（フィールド付き）の欠落を検出せよ。
• パフォーマンス: 不必要な同期 I/O、重複計算、N+1 問題、不要なメモリ割り当て、大量データの非効率処理を指摘せよ。
• 設計・保守性: 命名の一貫性、関数の責務過多、循環依存、マジックナンバー、重複コード、コメントと実装の不一致を検出せよ。
• 並行性/スレッド安全性: 共有可変状態、競合条件、ロックの取り方、デッドロックリスク、非同期 API の誤用を指摘せよ。
• テスト: ユニット/統合テストの有無と妥当性、クリティカルロジックの未テスト、モックの誤用、回帰を検知するテスト不足を指摘せよ。
• アクセシビリティ/国際化（該当箇所）: UI の ARIA 属性、キーボード操作、色コントラスト、ハードコード文言の i18n 漏れを確認せよ。
• 依存関係: 未使用ライブラリ、既知の脆弱版、ライセンス上の注意点、ピン留め不足（バージョン）を指摘せよ。
• Publicコードのドキュメンテーション:Public API、クラス、メソッドに対してJSDocやXMLドキュメントコメントが適切に記述されているか確認せよ。

C#（.NET / ASP.NET Core など）

• 非同期の原則: async/await を用い、.Result/.Wait() の併用を避ける。キャンセレーション (CancellationToken) の伝播を確認せよ。
• nullable 参照型: #nullable 設定と null 安全の扱い（?, !）が妥当か、未初期化/ヌル参照のリスクを指摘せよ。
• 例外設計: グローバルでのエラーハンドリングとし、原則各所でTry/Cacthを行わない運用とします。空 catch を禁止。特定例外のハンドリング、例外メッセージの明確化、ドメイン例外の適切使用を確認せよ。
• DI とライフタイム: Singleton/Scoped/Transient の設定が適切か、スコープ越えの依存解決、Service Locator の使用を指摘せよ。
• IDisposable: IDisposable/IAsyncDisposable の確実な破棄（using/await using）、アンマネージ資源のリークを検出せよ。
• LINQ/EF Core: N+1 問題、不要な ToList()、追跡の必要性（AsNoTracking）、未パラメータ化クエリ、トランザクション管理を確認せよ。
• 構造化ロギング: ILogger のプレースホルダー形式（LogInformation("User {Id} ...", id)）を推奨し、文字列連結を指摘せよ。
• API/モデル: DTO/エンティティの分離、バリデーション属性、DateTime vs DateTimeOffset の選択、タイムゾーン考慮を確認せよ。

Angular（TypeScript / HTML / SCSS）

TypeScript

• 型安全: strict 設定を有効化、any の使用禁止（型が不確実な場合は unknown を使用）、型推論が明らかな場合は型推論を優先せよ。

コンポーネント設計

• スタンドアロンコンポーネント: Angular v20+ では standalone: true はデフォルトのため記述不要。常にスタンドアロンコンポーネントを使用し、NgModules は使用しないこと。
• 単一責務: コンポーネントを小さく保ち、単一の責務に集中させよ。
• 入出力: @Input/@Output デコレータではなく、input() と output() 関数を使用せよ。
• 変更検知: @Component デコレータに changeDetection: ChangeDetectionStrategy.OnPush を設定せよ。
• テンプレート: 小さなコンポーネントにはインラインテンプレートを優先。外部テンプレート/スタイルを使用する場合は、コンポーネントTSファイルからの相対パスを使用せよ。
• ホストバインディング: @HostBinding / @HostListener デコレータは使用禁止。代わりに @Component または @Directive デコレータの host オブジェクト内にホストバインディングを記述せよ。
• 画像最適化: すべての静的画像に NgOptimizedImage を使用せよ（インラインbase64画像には適用不可）。

状態管理

• シグナル: ローカルコンポーネント状態にはシグナルを使用せよ。
• 派生状態: 派生状態には computed() を使用せよ。
• 純粋性: 状態変換を純粋で予測可能に保ち、シグナルには mutate ではなく update または set を使用せよ。

テンプレート

• シンプルさ: テンプレートをシンプルに保ち、複雑なロジックを避けよ。
• 制御フロー: *ngIf, *ngFor, *ngSwitch ではなく、ネイティブ制御フロー（@if, @for, @switch）を使用せよ。
• 非推奨ディレクティブ: ngClass ではなく class バインディング、ngStyle ではなく style バインディングを使用せよ。
• 非同期処理: Observable を処理するために async パイプを使用せよ。
• 制限事項: テンプレート内でグローバル（new Date() など）を想定せず、アロー関数も記述不可（サポート外）。

フォーム

• フォーム選択: テンプレート駆動フォームではなく、リアクティブフォームを優先せよ。

RxJS

• メモリリーク防止: async パイプを活用し、手動 subscribe の場合は takeUntil 等で確実に解放せよ。Subject の過剰使用を指摘せよ。

サービス

• 単一責務: サービスを単一の責務を中心に設計せよ。
• シングルトン: シングルトンサービスには providedIn: 'root' オプションを使用せよ。
• 依存性注入: コンストラクタインジェクションではなく、inject() 関数を使用せよ。

ルーティング/遅延ロード

• 機能ルート: 機能ルートに遅延ロードを実装せよ。ガード/リゾルバーの適切性を確認せよ。

セキュリティ

• サニタイズ: バインディングのサニタイズ、[innerHTML] 使用時は DomSanitizer で制御、HTTP インターセプタで認証ヘッダ管理を確認せよ。

アクセシビリティ

• AXE準拠: すべてのAXEチェックをパスすること。
• WCAG AA準拠: フォーカス管理、カラーコントラスト、ARIA属性を含むWCAG AA最小要件に従うこと。
• フォーム/レスポンシブ: フォームのエラーメッセージ、レスポンシブ対応を指摘せよ。

テスト

• ユニットテスト: TestBed を用いたコンポーネントのレンダリング検証を実施せよ。
• 非同期テスト: 非同期テストの完了待ち（fakeAsync/waitForAsync）を確認せよ。

SQL

• 安全性: 常にパラメータ化クエリを使用し、動的 SQL の連結を禁止。権限は最小限、シークレットはコードに埋め込まない。
• スキーマ整合性: 主キー/外部キー/一意制約/チェック制約の適用、NULL/DEFAULT の妥当性、マイグレーションの整備を確認せよ。
• パフォーマンス: インデックスの有無と選択性、不要な SELECT * の禁止、EXPLAIN/実行計画のボトルネックを指摘せよ。
• クエリ品質: CTE/ウィンドウ関数の適切使用、集約の正当性、N+1 を誘発する逐次クエリを指摘せよ。
• トランザクション: 適切な分離レベル、コミット/ロールバックの確実性、長期ロックやデッドロックリスクを確認せよ。

レビューフィードバックの書き方（推奨）

• 重大度ラベル（Critical/Major/Minor）と再現手順/修正案をセットで提示する。
• 1 PR あたりの指摘は 実行可能な単位にまとめ、過剰な細分化を避ける。
• 日本語で記載

レビュー回答フォーマット

レビュー指摘に対する回答は、以下のフォーマットに従うこと。

各指摘への回答テンプレート

#### [重大度] 指摘タイトル

- **対応**: 修正済み / 対応不要 / 次回対応
- **対応内容**: 具体的に何をどう修正したか、または対応不要・次回対応の理由
- **該当コミット**: `<commit hash>` （修正済みの場合）

重大度ごとの対応方針

回答時の注意事項

• すべての指摘に対して漏れなく回答すること（未回答の指摘があるとマージ不可）
• 「対応不要」とする場合は、技術的根拠または設計意図を明記すること
• 「次回対応」とする場合は、対応予定の Issue 番号またはタスクを記載すること
• 回答は日本語で記載すること

Pull request overview テンプレート

PR の概要説明には、以下のテンプレートを使用してください。

## PR の目的
- { 何を変更したのか }
- { なぜこの変更が必要なのか }

## 変更内容
- { 変更の詳細な内容 }
- { 影響範囲 }

## レビュー結果のサマリ
- {要約}