cdrf-expert

CDRF エキスパート

手順

1. リクエストを分類します。

ユーザーのリクエストを、次のカテゴリの1つ以上に分類します。

• クラスの選択（APIView、GenericAPIView、具体的なジェネリックビュー、ViewSets）
• ライフサイクルの追跡（リクエストからレスポンスまでのフロー）
• オーバーライド戦略（カスタマイズするフック）
• MRO のデバッグ（メソッドがどのミックスイン／基底クラスに由来するか）
• バージョンの違い（DRF のバージョン間で動作が変わったか）

2. 必要な参照ファイルだけを読みます。

必要最小限のコンテキストを読み込みます。

• クラスの選択には references/class-selection-matrix.md
• フックの配置とライフサイクルには references/lifecycle-and-overrides.md
• MRO／メソッドの出典を追跡するには references/mro-debugging-playbook.md
• DRF のバージョン比較には references/version-check-workflow.md

3. バージョンを最初に確認する手順で cdrf.co を参照します。

• ユーザーのコンテキストから、プロジェクトの DRF バージョンを特定します。
• バージョンが不明な場合は、バージョンを確認するか、バージョンに依存しない回答を提示し、前提を明示します。
• まず該当する CDRF のバージョン名前空間を開きます（例：https://www.cdrf.co/3.16/）。
• 対象クラスのページを開き、以下を抽出します。
  • 祖先クラスと MRO
  • 利用可能なメソッドと、各メソッドの定義元クラス
  • 動作に影響するデフォルト属性（queryset、serializer_class、ページネーション／フィルターバックエンド）

4. 最小限のオーバーライドポイントを選びます。

• 広範なメソッド（create、update、destroy）より、範囲の狭いフック（perform_create、perform_update、perform_destroy）を優先します。
• リクエストごとの動作には、クラス属性のハードコードより get_queryset と get_serializer_class を優先します。
• HTTP のオーケストレーションはビューのメソッドに置き、ビジネスロジック／ドメインロジックはビューの外に置きます。
• リクエストで動作の変更が必要な場合を除き、DRF のデフォルトを維持します。

5. メソッドのフローに基づいた回答を作成します。

以下を提示します。

• 推奨するクラス
• オーバーライドするメソッド
• MRO／ライフサイクル上、これらのメソッドが適切である理由
• 簡潔なコードの修正案またはひな形
• リスク／リグレッションと追加すべきテスト

6. 最終回答の前に検証します。

よくあるリグレッションがないか確認します。

• パーミッション／認証／フィルター／ページネーションのフックを誤って迂回していないか
• シリアライザーとビューの間でオブジェクト保存ロジックを重複させていないか
• 範囲の狭いフックで十分なのに、広範なメソッドをオーバーライドしていないか
• 選択した DRF バージョンに存在しないメソッドに依存していないか

エラー処理

1. cdrf.co を利用できない場合は、その制限を伝え、DRF の公式ドキュメントとインストール済みのソースコードを代わりに参照します。
2. ユーザーが DRF のバージョンを提示できない場合は、バージョンに依存しない手順を示し、前提を明確にします。
3. 複数のオーバーライドポイントが有効に見える場合は、まず最も範囲の狭いフックを推奨し、トレードオフを説明します。

出力ルール

• CDRF のクラス名とメソッド名を正確に引用します。
• DRF のバージョンが不明な場合は、前提を明示します。
• DRF の CBV の内部動作と、すぐに適用できるコード変更に焦点を絞ります。