## Context

### Background

現在の実装では、トークンストレージに macOS Keyring を使用しており、トークンアクセス時に毎回パスワードプロンプトが表示される問題が発生している。これにより、ユーザー体験が著しく低下し、特に自動化やスクリプト実行時に大きな障害となっている。

また、設定ディレクトリがプラットフォームごとに異なる（macOS: `~/Library/Application Support/slack-rs/`、Linux: `~/.config/slack-rs/`）ため、クロスプラットフォームでの一貫性が欠けている。

### Current State

**既存実装:**
- `KeyringTokenStore`: システムキーリングを使用したトークンストレージ（デフォルト）
- `InMemoryTokenStore`: テスト用のインメモリストレージ
- `FileTokenStore`: ファイルベースのストレージ（既に実装済み）
  - `~/.config/slack-rs/tokens.json` にトークンを保存
  - Unix システムでは 0600 パーミッションを設定
  - 環境変数 `SLACK_RS_TOKENS_PATH` でパスをオーバーライド可能

**設定ディレクトリ:**
- `storage.rs` の `default_config_path()` は既に `~/.config/slack-rs/` を使用
- レガシーパス（`~/Library/Application Support/slack-cli/`）からの移行機能も実装済み

**現在の使用箇所:**
- `src/auth/commands.rs`: `KeyringTokenStore::default_service()` を使用
- `src/cli/mod.rs`: 同上

### Constraints

- **後方互換性**: 既存の Keyring に保存されたトークンは自動移行しない（再ログイン必要）
- **セキュリティ**: ファイルベースでもセキュリティを維持（0600 パーミッション）
- **テスト容易性**: 環境変数でパスをオーバーライド可能
- **プラットフォーム**: Unix 系システム（macOS, Linux）を主要ターゲット

### Stakeholders

- **エンドユーザー**: パスワードプロンプトの排除による UX 向上
- **開発者**: テストとデバッグの容易化
- **運用担当者**: 自動化スクリプトでの利用が可能に

## Goals / Non-Goals

**Goals:**
- デフォルトのトークンストレージを `KeyringTokenStore` から `FileTokenStore` に変更
- すべてのプラットフォームで `~/.config/slack-rs/` を統一的に使用
- パスワードプロンプトの完全排除
- ファイルパーミッション（0600）によるセキュリティ確保
- 既存の `KeyringTokenStore` 実装は保持（将来的な選択肢として）

**Non-Goals:**
- Keyring からファイルへの自動トークン移行（ユーザーは再ログインが必要）
- Windows での特別なセキュリティ対応（現時点では Unix 系のみ対応）
- トークンの暗号化（ファイルパーミッションで保護）
- 設定 UI やコマンドラインオプションでのストレージ選択機能

## Decisions

### Decision 1: FileTokenStore をデフォルトに変更

**選択肢:**
1. **FileTokenStore をデフォルトに** (採用)
2. KeyringTokenStore を維持し、オプションで FileTokenStore を選択可能に
3. 両方をサポートし、環境変数で切り替え

**理由:**
- パスワードプロンプトの問題を根本的に解決
- 実装が既に完了しており、テストも充実
- ファイルパーミッション（0600）で十分なセキュリティを確保
- バックアップ・リストアが容易（単純なファイルコピー）
- 設定ファイルの可視性向上（デバッグが容易）

**トレードオフ:**
- システムキーリングの追加セキュリティ層を失う
- ファイルシステムへの依存が増加
- ディスク暗号化されていない環境ではリスクが増加

**代替案の却下理由:**
- 選択肢 2: デフォルトが変わらないため、問題が解決しない
- 選択肢 3: 複雑性が増し、ユーザーに設定負担を強いる

### Decision 2: 統一設定ディレクトリ `~/.config/slack-rs/`

**選択肢:**
1. **すべてのプラットフォームで `~/.config/slack-rs/` を使用** (採用)
2. プラットフォームごとに標準ディレクトリを使用（`directories` クレート）
3. 環境変数で完全にカスタマイズ可能に

**理由:**
- `storage.rs` で既に `~/.config/slack-rs/` を使用中
- クロスプラットフォームでの一貫性
- Unix 系システムでの標準的な慣習（XDG Base Directory 仕様に準拠）
- レガシーパスからの移行機能も既に実装済み

**トレードオフ:**
- macOS の標準（`~/Library/Application Support/`）から逸脱
- Windows では `~/.config/` が一般的ではない

**代替案の却下理由:**
- 選択肢 2: プラットフォームごとに異なるパスになり、一貫性が失われる
- 選択肢 3: 実装が複雑化し、ユーザーに設定負担を強いる

### Decision 3: KeyringTokenStore の保持

**選択肢:**
1. **KeyringTokenStore を残し、将来的な選択肢として保持** (採用)
2. KeyringTokenStore を完全に削除
3. KeyringTokenStore を deprecated としてマーク

**理由:**
- 既存のコードを削除する必要がない
- 将来的にユーザーが選択できるようにする可能性を残す
- テストコードでの利用も継続可能
- コードの複雑性はほとんど増加しない

**トレードオフ:**
- 使用されないコードが残る可能性
- メンテナンスコストが若干増加

**代替案の却下理由:**
- 選択肢 2: 将来的な柔軟性を失う
- 選択肢 3: deprecated マークは混乱を招く可能性がある

### Decision 4: トークンの暗号化は行わない

**選択肢:**
1. **ファイルパーミッション（0600）のみで保護** (採用)
2. トークンを暗号化して保存
3. マスターパスワードで保護

**理由:**
- ファイルパーミッション（0600）で所有者のみがアクセス可能
- 暗号化キーの管理が新たな問題を生む（どこに保存するか）
- マスターパスワードは Keyring と同じ問題（パスワードプロンプト）を引き起こす
- ディスク暗号化が有効な環境では追加の暗号化は不要

**トレードオフ:**
- ディスク暗号化されていない環境ではリスクが増加
- ファイルシステムのバックアップに平文トークンが含まれる

**代替案の却下理由:**
- 選択肢 2, 3: 複雑性が大幅に増加し、キー管理の問題が発生

## Risks / Trade-offs

### Risk 1: 既存ユーザーのトークンが失われる

**リスク:**
- Keyring に保存された既存トークンは自動移行されない
- ユーザーは再ログインが必要

**軽減策:**
- CHANGELOG と README に明記
- 初回実行時に警告メッセージを表示（オプション）
- `slack-rs login` コマンドで簡単に再認証可能

### Risk 2: ファイルパーミッションが正しく設定されない環境

**リスク:**
- Windows や一部の Unix システムでは 0600 パーミッションが機能しない可能性
- ファイルシステムがパーミッションをサポートしない場合

**軽減策:**
- Unix システムでのみパーミッション設定を試行（`#[cfg(unix)]`）
- パーミッション設定失敗時はエラーを返す
- ドキュメントでセキュリティリスクを明記

### Risk 3: ディスク暗号化されていない環境でのセキュリティリスク

**リスク:**
- ディスク暗号化が無効な環境では、トークンが平文で保存される
- バックアップに平文トークンが含まれる

**軽減策:**
- ドキュメントでディスク暗号化の推奨を明記
- セキュリティ要件が高い環境では Keyring を使用するよう案内（将来的な選択肢として）
- トークンの有効期限を短く設定することを推奨

### Risk 4: ファイルシステムの破損やアクセス権限の問題

**リスク:**
- ファイルシステムの破損でトークンが失われる
- ディレクトリのアクセス権限が変更される

**軽減策:**
- エラーハンドリングを充実させ、明確なエラーメッセージを提供
- ファイルが読めない場合は再ログインを促す
- バックアップ・リストアの手順をドキュメント化

## Migration Plan

### Phase 1: コード変更（既に完了）

- [x] `FileTokenStore` の実装（`src/profile/token_store.rs`）
- [x] `default_config_path()` の変更（`src/profile/storage.rs`）
- [x] テストの追加

### Phase 2: デフォルト変更

- [ ] `src/auth/commands.rs` で `KeyringTokenStore::default_service()` を `FileTokenStore::new()` に変更
- [ ] `src/cli/mod.rs` で同様の変更
- [ ] 既存のテストが引き続き動作することを確認

### Phase 3: ドキュメント更新

- [ ] README に変更内容を記載
- [ ] CHANGELOG に BREAKING CHANGE として記載
- [ ] セキュリティに関する注意事項を追加

### Phase 4: リリース

- [ ] バージョンを 0.2.0 にバンプ（BREAKING CHANGE のため）
- [ ] リリースノートに移行手順を記載

### Rollback Strategy

問題が発生した場合:
1. `KeyringTokenStore::default_service()` に戻す（1行の変更）
2. パッチバージョンをリリース
3. ユーザーに再ログインを依頼

## Open Questions

### Q1: Windows でのファイルパーミッション対応

**質問:** Windows でもファイルパーミッションを設定すべきか？

**現状:** Unix システムでのみ 0600 パーミッションを設定

**検討事項:**
- Windows では ACL（Access Control List）を使用する必要がある
- 実装の複雑性が増加
- Windows ユーザーの需要が不明

**決定:** 現時点では Unix のみ対応。Windows 対応は将来的な課題として残す。

### Q2: トークンストレージの選択機能

**質問:** ユーザーがトークンストレージを選択できるようにすべきか？

**現状:** FileTokenStore がデフォルト、KeyringTokenStore は残すが使用されない

**検討事項:**
- 環境変数 `SLACK_RS_TOKEN_STORE=keyring` で切り替え可能にする
- 設定ファイルで指定可能にする
- コマンドラインオプションで指定可能にする

**決定:** 現時点では実装しない。ユーザーからの要望があれば将来的に検討。

### Q3: トークンの自動ローテーション

**質問:** トークンの有効期限を管理し、自動的に再認証を促すべきか？

**現状:** トークンの有効期限は管理していない

**検討事項:**
- Slack API のトークン有効期限を確認
- 有効期限切れトークンの検出と再認証フロー
- 実装の複雑性

**決定:** 現時点では実装しない。API エラーで有効期限切れを検出し、ユーザーに再ログインを促す。
