dev-ruleslisted

# Development Guidelines 本規範は単体で完結する（メイン会話・サブエージェントのどちらで読まれても前提を欠かない）。 ## General Principles - **求められたものを作る** — 頼まれていない機能・抽象化・設定項目を先回りで足さない（YAGNI） - **Deletion Test で検品する** — 成果物の各要素に「これを削っても完了条件の証明は成立するか？」と問い、成立するなら削る（YAGNI の出口側の操作形）。ただし入力検証・エラー処理・セキュリティ対策は削る対象にしない——動くだけの近道は簡潔ではなく未完成である - **根拠なき数値を発明しない** — タイムアウト・リトライ回数・閾値・上限は、出所（依頼元の指定・仕様・実測・プラットフォーム制約）を言える値だけを書く。仮置きが避けられない場合は、仮置きである旨と選定理由を明示する - **先送りは grep 可能に刻む** — 意図的な仮置き・簡易実装には、天井（何で妥協したか）と昇格トリガー（何が起きたら本実装へ進むか）の二成分を `cc-defer:` コメントでコード内に残す（例: `# cc-defer: グローバルロック、スループット問題時にアカウント別へ`）。トリガーの無い先送りは、回収の機会を失って腐る - **短く、正確に書く** — コードも文章も、同じ内容ならより短い表現を採る。削れる語を削り、意味が落ちる手前で止める（KISS） - **変更は外科的に** — タスクの達成に必要な最小限のファイルだけに触れる - **既存の流儀に合わせる** — 命名・コメント密度・イディオムは周囲のコードに揃える - **完了はテストが定義する** — テストと静的チェックが通る状態だけを「完了」と呼ぶ --- ## Architecture: Clean Architecture 本プロジェクトは **Clean Architecture** を採用する。 ``` Infrastructure → Interface(Adapter) → UseCase → Domain 依存方向: 外から内へのみ ``` | Layer | 責務 | 依存先 | |-------|------|--------| | **Domain** | ビジネスロジック、エンティティ、値オブジェクト | なし（純粋） | | **UseCase** | アプリケーション固有のオーケストレーション | Domain のみ | | **Interface (Adapter)** | コントローラ、プレゼンタ、ゲートウェイ | UseCase, Domain | | **Infrastructure** | フレームワーク、DB、外部サービス | 全層（最外殻） | ### 原則 - **依存は内向きのみ** — Domain は外層を import しない - **Composition over Inheritance** — DI で組み立てる - **Interface で境界を切る** — テスト容易性と差し替え可能性の確保 - **データフローは明示的** — グローバル状態・隠れた依存を禁止 --- ## Process ### TDD Flow 1. **Understand** — 既存コードから類似機能を3つ探し、パターンを把握する。書き始める前に ①そもそも書かずに済むか → ②既