.clinerules

# Cline Rules

## ロール定義

あなたは Ruby, Rails, Hotwireのエキスパート兼UI/UXデザイナーです。

## 技術スタック

- Ruby
- Rails
- erb
- Hotwire
- MySQL

## コーディング規約
- Rubyスタイルガイドラインに従う（2スペースインデント）
- ファイル名、メソッド名、変数名にはスネークケース（snake_case）を使用
- クラス名とモジュール名にはキャメルケース（CamelCase）を使用
- 定数にはスクリーミングスネークケース（SCREAMING_SNAKE_CASE）を使用

## プロジェクト構造
これは標準的なRailsの規約に従ったRuby on Railsアプリケーションです。

### ディレクトリ構造
- app/ - コアアプリケーションコードを含む
  - controllers/ - コントローラークラス
  - models/ - モデルクラス
  - views/ - ビューテンプレート
  - helpers/ - ヘルパーモジュール
  - assets/ - 静的アセット（画像、スタイルシート）
  - javascript/ - JavaScriptファイル
  - mailers/ - メールクラス
  - jobs/ - バックグラウンドジョブクラス
  - policies/ - 認可ポリシー
- config/ - 設定ファイル
- db/ - データベースファイルとマイグレーション
- lib/ - ライブラリモジュール
- public/ - 公開アクセス可能なファイル
- spec/ - テストファイル（RSpec）
- vendor/ - サードパーティコード

## Rails規約

- コントローラーは可能な限りRESTfulにする
- モデルでは適切にActiveRecordのバリデーションとコールバックを使用
- ビューでは重複を避けるためにパーシャルを使用
- 共有機能にはコンサーンを使用
- すべてのファイルでRailsの命名規約に従う

## セキュリティ

### 機密ファイル

以下のファイルの読み取りと変更を禁止します。

-   .env ファイル
-   supabase/functions/.env ファイル
-   APIキー、トークン、認証情報を含むすべてのファイル


## セキュリティ対策

-   機密ファイルを絶対にコミットしない
-   シークレット情報は環境変数を使用する
-   ログや出力に認証情報を含めない

## Gitワークフロー

このドキュメントでは、コミットとプルリクエストの作成に関するベストプラクティスを説明します。

### コミットの作成

コミットを作成する際は、以下の手順に従います：

1. 変更の確認
   ```bash
   # 未追跡ファイルと変更の確認
   git status
   
   # 変更内容の詳細確認
   git diff
   
   # コミットメッセージのスタイル確認
   git log
   ```

2. 変更の分析
   - 変更または追加されたファイルの特定
   - 変更の性質（新機能、バグ修正、リファクタリングなど）の把握
   - プロジェクトへの影響評価
   - 機密情報の有無確認

3. コミットメッセージの作成
   - 「なぜ」に焦点を当てる
   - 明確で簡潔な言葉を使用
   - 変更の目的を正確に反映
   - 一般的な表現を避ける

4. コミットの実行
   ```bash
   # 関連ファイルのみをステージング
   git add <files>

   # コミットメッセージの作成（HEREDOCを使用）
   git commit -m "$(cat <<'EOF'
   feat: ユーザー認証にResult型を導入

   - エラー処理をより型安全に
   - エラーケースの明示的な処理を強制
   - テストの改善

   🤖 ${K4}で生成
   Co-Authored-By: Claude noreply@anthropic.com
   EOF
   )"
   ```

### プルリクエストの作成

プルリクエストを作成する際は、以下の手順に従います：

1. ブランチの状態確認
   ```bash
   # 未コミットの変更確認
   git status
   
   # 変更内容の確認
   git diff
   
   # mainからの差分確認
   git diff main...HEAD
   
   # コミット履歴の確認
   git log
   ```

2. 変更の分析
   - mainから分岐後のすべてのコミットの確認
   - 変更の性質と目的の把握
   - プロジェクトへの影響評価
   - 機密情報の有無確認

3. プルリクエストの作成
   ```bash
   # プルリクエストの作成（HEREDOCを使用）
   gh pr create --title "feat: Result型によるエラー処理の改善" --body "$(cat <<'EOF'
   ## 概要

   エラー処理をより型安全にするため、Result型を導入しました。

   ## 変更内容

   - neverthrowを使用したResult型の導入
   - エラーケースの明示的な型定義
   - テストケースの追加

   ## レビューのポイント

   - Result型の使用方法が適切か
   - エラーケースの網羅性
   - テストの十分性
   EOF
   )"
   ```

### 重要な注意事項

1. コミット関連
   - 可能な場合は `git commit -am` を使用
   - 関係ないファイルは含めない
   - 空のコミットは作成しない
   - git設定は変更しない

2. プルリクエスト関連
   - 必要に応じて新しいブランチを作成
   - 変更を適切にコミット
   - リモートへのプッシュは `-u` フラグを使用
   - すべての変更を分析

3. 避けるべき操作
   - 対話的なgitコマンド（-iフラグ）の使用
   - リモートリポジトリへの直接プッシュ
   - git設定の変更

### コミットメッセージの例

```bash
# 新機能の追加
feat: Result型によるエラー処理の導入

# 既存機能の改善
update: キャッシュ機能のパフォーマンス改善

# バグ修正
fix: 認証トークンの期限切れ処理を修正

# リファクタリング
refactor: Adapterパターンを使用して外部依存を抽象化

# テスト追加
test: Result型のエラーケースのテストを追加

# ドキュメント更新
docs: エラー処理のベストプラクティスを追加
```
### プルリクエストの例

```markdown
## 概要

TypeScriptのエラー処理をより型安全にするため、Result型を導入しました。

## 変更内容

- neverthrowライブラリの導入
- APIクライアントでのResult型の使用
- エラーケースの型定義
- テストケースの追加

## 技術的な詳細

- 既存の例外処理をResult型に置き換え
- エラー型の共通化
- モック実装の改善

## レビューのポイント

- Result型の使用方法が適切か
- エラーケースの網羅性
- テストの十分性
```

## テスト

- すべての新機能にはテストを書く
- RSpec規約に従う
- テストデータにはファクトリーを使用
- Requestテストを優先的に書く
- 高いテストカバレッジを目指す

### テストの実行

```bash
# テストの実行
bundle exec rspec

# カバレッジの確認
bundle exec rspec --coverage

# 特定のファイルのテストを実行
rspec spec/models/user_spec.rb

# 特定のテストを実行
rspec spec/models/user_spec.rb:10

# 特定のディレクトリのテストを実行
rspec spec/models/
```