コード品質ルール

本ドキュメントは、実装時に遵守すべきコード品質ルールを定義します。 すべてのエージェントはこのルールに従って実装を行います。

1. 500行ルール

1.1 ルール定義

1ファイルあたり500行を上限とします。 これはクリーンアーキテクチャ/オニオンアーキテクチャの単一責任の原則に基づきます。

1.2 500行を超えた場合の対応

1. 実装時にエージェントが自動で分割を実行
2. 分割後に品質チェックを再実行
3. すべて500行以下になるまで繰り返し
4. 分割が技術的に困難な場合のみTODOに記録

1.3 分割の指針

1.4 例外

以下の場合は500行超過を許容：

• 自動生成ファイル（マイグレーション、型定義等）
• 設定ファイル
• テストファイル（ただし1000行を上限とする）

2. アーキテクチャ選定戦略

Adaptive Strategy: プロジェクトの特性やフレームワークに合わせて最適なアーキテクチャを選択する。 一律の「固定アーキテクチャ」強制は廃止。

2.1 優先順位（Decision Tree）

実装エージェントは以下の優先順位で採用するアーキテクチャを決定します。

1. Project Definition (最優先)
   • docs/architecture.md または設計書（基本・詳細）に明記されたアーキテクチャ。
2. Framework Convention (フレームワーク標準)
   • Next.js (App Router), NestJS, Rails, Django 等、フレームワークが構造を規定している場合はそれに従う。
   • 禁止: フレームワークの流儀に逆らって無理にオニオンアーキテクチャ等を適用すること。
3. Recommended Patterns (デフォルト)
   • 上記に該当しない場合、以下の標準パターンを採用する。

2.2 推奨パターン（Default Fallback）

プロジェクト固有の定義がない場合の標準セットです。

2.3 プロンプト最適化ガイド（LLM事前学習活用）

選択されたアーキテクチャ名をプロンプトに含めるだけで、詳細説明は省略可能です（80-90%トークン削減）。

✅ 正しい指示の例

// Next.jsの場合
"Next.js App Router標準構成。Server ComponentsとClient Componentsを適切に分離。"

// 複雑なドメインの場合
"オニオンアーキテクチャ + TDD。Domain層の依存を排除。"

// 小規模ツールの場合
"シンプルなモジュール構成。過剰な抽象化は避けること。"

3. 設計原則

3.1 SOLID原則

3.2 その他の原則

4. 命名規則

4.1 共通

4.2 バックエンド

4.3 フロントエンド

5. テストカバレッジ要件

5.1 カバレッジ閾値

5.2 テストの種類

6. コードフォーマット

6.1 必須ツール

6.2 コミット前チェック

以下のチェックをコミット前に実行：

1. Lint（エラー0件）
2. Format（差分0件）
3. Type Check（エラー0件）
4. Unit Test（全件パス）

7. 禁止事項

7.1 絶対禁止

7.2 原則禁止（例外要申請）

変更履歴