dev-ruleslisted

# Development Guidelines 本規範は単体で完結する（メイン会話・サブエージェントのどちらで読まれても前提を欠かない）。 ## General Principles - **求められたものを作る** — 頼まれていない機能・抽象化・設定項目を先回りで足さない（YAGNI） - **短く、正確に書く** — コードも文章も、同じ内容ならより短い表現を採る。削れる語を削り、意味が落ちる手前で止める（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つ探し、パターンを把握する 2. **Test** — 失敗するテストを書く（red） 3. **Implement** — テストを通す最小限のコード（green） 4. **Refactor** — テストが通る状態を維持しつつ整理 5. **Commit** — "why" を説明するメッセージで記録。push 前に CI と同じ静的チェックをローカルで通す（例: `mypy` / `ruff check` / `ruff format --check` — pytest green だけでは CI は通らない） ### Implementation Staging 複雑なタスクは 3-5 段階に分割し `IMPLEMENTATION_PLAN.md` で管理する： ```markdown ## Stage N: [Name] **Goal**: [具体的な成果物] **Success Criteria**: [テスト可能な完了条件] **Tests**: [具体的なテストケース] **Status**: