# gfo ロードマップ

既存ツール（gh / glab / tea）との比較調査に基づき、gfo のマルチフォージ思想に合致する新機能を優先度順に整理する。

## 実装予定機能

| # | 機能 | コマンド | 概要 | 対応サービス数 |
|---|------|---------|------|:---:|
| 1 | [browse](01-browse.md) | `gfo browse` | リポジトリ・PR・Issue をブラウザで開く | 全 9 |
| 2 | [jq フィルタ](02-jq-filter.md) | `--jq` オプション | JSON 出力に jq 式でフィルタをかける | 全共通 |
| 3 | [SSH Key 管理](03-ssh-key.md) | `gfo ssh-key` | ユーザー SSH 公開鍵の list / create / delete | 6 |
| 4 | [Organization 管理](04-org.md) | `gfo org` | 所属組織の一覧・メンバー・リポジトリ操作 | 7 |
| 5 | [通知管理](05-notification.md) | `gfo notification` | インボックス通知の一覧・既読化 | 5 |
| 6 | [ブランチ保護](06-branch-protect.md) | `gfo branch-protect` | ブランチ保護ルールの確認・設定 | 6 |
| 7 | [Secret / Variable](07-secret-variable.md) | `gfo secret` / `gfo variable` | CI/CD シークレット・変数の管理 | 5 |

## 優先度の根拠

- **1〜2**: 実装コストが低く、全サービス共通で即効性が高い
- **3〜4**: API が単純で複数サービスに共通、チーム利用で需要大
- **5〜6**: 日常ワークフロー / DevOps 自動化に有用だが API 差異が大きい
- **7**: GitHub・GitLab に偏るため最後に検討

## 各ドキュメントの構成

各機能の詳細計画は以下の構成で記述する:

1. **概要** — 機能の目的とモチベーション
2. **コマンド設計** — サブコマンド・引数・オプション
3. **対応サービス** — アダプターごとの対応状況と API エンドポイント
4. **データモデル** — `base.py` に追加するデータクラス
5. **アダプター抽象メソッド** — 基底クラスに追加するメソッド
6. **既存コードへの変更** — cli.py / commands / tests への影響
7. **テスト方針** — 単体テスト・統合テストの計画
