## コーディング実行規約

あなたはこのリポジトリで作業するコーディングエージェントです。以下の規約を**すべてのタスクで例外なく**適用してください。

### 1. 実装前:必ず調査してから書く

- コードを書く前に、関連ファイルを**必ず読んで**現状を把握する。ファイルの内容・関数のシグネチャ・型定義を推測で書かない。
- 既存のコード規約(命名、フォーマット、エラーハンドリングの流儀、使用ライブラリ)を確認し、それに合わせる。新しいライブラリを勝手に導入しない。
- 依存関係・import先が実在するか、使用前に確認する。存在しないAPI・メソッドを呼ばない。
- 要件が曖昧な場合は実装せず、**先に質問する**。仕様を勝手に補完しない。

### 2. 計画:着手前に手順を宣言する

タスク開始時、以下を短く箇条書きで出力してから実装する:

1. 変更するファイル一覧
2. 各ファイルでの変更内容(1行ずつ)
3. 影響範囲(呼び出し元・テストなど)
4. 検証方法(実行するコマンド)

計画にないファイルは触らない。計画変更が必要になったら、変更点を明示してから続行する。

### 3. 実装:最小差分の原則

- 依頼されたことだけを実装する。リファクタ・整形・「ついでの改善」は指示がない限り行わない。
- 1回の変更は小さく保つ。大きなタスクは独立して検証可能な単位に分割し、1単位ずつ「実装→検証」を完了させてから次に進む。
- 既存のテスト・動作を壊す変更をする場合は、必ず事前に報告する。
- コメントアウトでのコード温存、`TODO`での実装放棄、ダミー値での仮実装をしない。動く完成形だけをコミット対象にする。
- エラーハンドリングを省略しない。失敗しうる処理(I/O、外部API、パース)には必ず対処を入れる。

### 4. ファイル構成の規約

- **1ファイルが200行を超える見込みなら、必ず新しいファイル・モジュールに分割する。**
- **1ファイルに複数の責務(UI、ビジネスロジック、データ処理など)を混在させない。** 責務ごとにファイルを分ける。
- 分割時は既存のディレクトリ構成の慣例に従う。

### 5. 検証:実装後に必ず自己チェックする

実装完了を宣言する前に、以下を**順番に実行**し、結果を報告する:

1. ビルド / コンパイル(該当する場合)
2. 型チェック(`tsc --noEmit`、`mypy` など、プロジェクトにあるもの)
3. リンター(`eslint`、`ruff` など)
4. 関連テストの実行(テストが存在する場合。なければ手動での動作確認手順を示す)

いずれかが失敗した場合:
- エラーメッセージを**全文読んで**原因を特定してから修正する。当てずっぽうの修正を繰り返さない。
- 同じ修正を2回試して失敗したら、アプローチを変えるか、状況を報告して指示を仰ぐ。

### 6. 禁止事項

- ファイル内容・API仕様・コマンド出力の**推測**(必ず読む・実行して確認する)
- `rm -rf`、`git push --force`、`git reset --hard` などの破壊的操作を確認なしに実行すること
- 秘密情報(APIキー、パスワード)のハードコード
- テストを通すためだけのテスト改変・スキップ
- 検証をスキップした「完了しました」報告

### 7. 報告フォーマット

タスク完了時は以下だけを簡潔に報告する:

- 変更ファイルと変更概要
- 実行した検証コマンドと結果
- 残課題・注意点(あれば)

---

## 運用のコツ(プロンプト本体には含めない)

- 低エフォートでは長い自由記述の指示より、上記のような**番号付き手順と禁止リスト**のほうが遵守率が高い。
- タスク依頼時も「〇〇を修正して。完了条件: テストXが通ること」のように**完了条件を毎回明記**すると精度が上がる。
- 大きな機能追加は最初から1メッセージで頼まず、「計画だけ出して」→承認→「ステップ1だけ実装して」と分けると失敗が減る。



## ファイル分割・設計ルール

コードを書くときは以下を**既定**として適用する。守れない事情がある場合は、その理由を述べたうえで判断を仰ぐこと。

### ディレクトリ構成
- **モノレポ（Monorepo）構成** 。基本的なタスクで小さなプロジェクトを作ってスタンドアローンで動作することをしたうえで連結していくシステムの構成がメンテナンス開発がしやすいため。 **トークンの削減ができる場合に限る**

### 設計の基本方針
- **オブジェクト指向で実装する**。データとそれを扱うロジックをまとめ、責務ごとにモジュール／クラス／関数へ分ける。
- **1ファイル＝1責務**。UI・ロジック・データ処理などを同じファイルに混在させない。
- **部品を作って組み立てる**。再利用できる小さな部品（関数・モジュール）に分け、既存の部品が使えるなら優先して使う。全体のコード量を増やさないことを意識する。

### ファイルサイズと分割の基準
- **1ファイルが400行を超える場合は、原則として新しいファイル／モジュールに分割する**（仕様上どうしても分けられない場合のみ例外）。
- 行数が閾値に近づいてきた、または1ファイルに責務が集まりすぎていると感じたら、放置せず分割を検討する。

### リファクタリングの方針
- 既に肥大化・責務過多になっているファイルでも、**特別な指示がない限り、いきなり全体を作り直さない**。機能の修正・追加でそのコードに手を入れるタイミングに合わせてリファクタリングする。
- **リファクタリングを行ったら、必ず「何を・どこで・どの機能を」変更したかを報告する**（報告は必須）。

### マジックナンバーの禁止
- **意味のある数値をコードに直接埋め込まない**（マジックナンバー禁止）。後から手を入れる人が混乱する原因になる。
- 名前付き定数・変数にする、または設定用ファイルへ集約する。**用途が分かる名前とコメント**を必ず添える。

## セキュリティルール（コード生成時に必ず守ること）

新規・修正を問わず、コードを書くときは以下を**既定**として適用する。違反しそうな場合は実装前に必ず指摘・代替案の提示・確認を行う。
このプロジェクトで実際に対応した既存の共通部品を**再利用**し、各所で作り直さないこと。

### 認可（アクセス制御）
- **状態を変更する処理（追加・更新・削除・アップロード・移動）には必ず認証・権限チェックを入れる**。「管理画面が守られているから」では不十分で、その画面が呼ぶ **API/エンドポイント自体**にもチェックを入れる
- 公開してよいのは**表示専用の読み取り（GET）に限定**する。書き込み(POST/PUT/PATCH/DELETE)はログイン必須。
- API共通ガードを各エンドポイント冒頭で呼ぶ。
- ロール（admin / user）の境界を意識する。一般ユーザーが触れる編集機能から、管理者しか許されない操作や他者への影響（保存型XSS等）が起きないようにする。

### 破壊的・危険な操作（ユーザーのグローバル `safe` ルールに従う）
- `rm -rf` / `git push --force` / `git reset --hard` / `DROP`・`DELETE`/`UPDATE` without WHERE / `chmod 777` / 本番環境への直接操作などは、**実行前に必ず確認**し、必要に応じて代替案を提示する。
- 「全部やって」「シンプルに」など曖昧で危険な指示は、影響範囲を確認してから着手する。