@einja/dev-cli 0.1.6

package/scaffolds/steering/branch-strategy.md

@@ -0,0 +1,362 @@
+# ブランチ運用戦略
+
+## 概要
+
+このドキュメントでは、タスク実行時のブランチ運用戦略を定義します。
+
+※ **IssueBranchBase**: Issue ブランチの作成元ブランチ（main, develop など）
+
+## ブランチ階層構造
+
+```
+IssueBranchBase（main, develop など）
+  └─ issue/{issue番号} (Issueブランチ)
+       ├─ issue/{issue番号}-phase1 (フェーズ1ブランチ)
+       ├─ issue/{issue番号}-phase2 (フェーズ2ブランチ)
+       └─ issue/{issue番号}-phase3 (フェーズ3ブランチ)
+```
+
+**注意**: Git の制約により、`issue/25` と `issue/25/phase1` は共存できません。
+そのため、Phase ブランチはハイフン区切り（`issue/25-phase1`）を使用します。
+
+### ブランチと Worktree の関係
+
+```mermaid
+graph TB
+    subgraph "Gitブランチ階層"
+        MAIN[IssueBranchBase] --> ISSUE[issue/123]
+        ISSUE --> PHASE1[issue/123-phase1]
+        ISSUE --> PHASE2[issue/123-phase2]
+    end
+
+    subgraph "Worktree（Vibe-Kanban管理）"
+        PHASE1 -.->|base_branch| WT1[worktree: task-1.1]
+        PHASE1 -.->|base_branch| WT2[worktree: task-1.2]
+        PHASE2 -.->|base_branch| WT3[worktree: task-2.1]
+    end
+```
+
+## ブランチ命名規則
+
+### 1. Issueブランチ
+
+**命名規則**: `issue/{issue番号}`
+
+**例**:
+- `issue/123`
+- `issue/456`
+- `issue/789`
+
+**作成元**: IssueBranchBase（`--branch` オプションで指定、デフォルトは main）
+
+**目的**:
+- GitHub Issue全体の作業を統合する親ブランチ
+- すべてのフェーズブランチはこのブランチから派生
+
+### 2. フェーズごとのブランチ
+
+**命名規則**: `issue/{issue番号}-phase{N}`
+
+**例**:
+- `issue/123-phase1`
+- `issue/456-phase2`
+- `issue/789-phase1`
+
+**作成元**: Issueブランチ
+
+**目的**:
+- フェーズ単位での作業を分離
+- Vibe-Kanbanタスクの実行ベースブランチとして使用（原則）
+- フェーズ完了後、親ブランチにマージ
+
+## ブランチ命名例
+
+| 仕様書ディレクトリパス | Issueブランチ | Phase 1ブランチ | Phase 2ブランチ |
+|------------------|---------------|----------------|----------------|
+| `docs/specs/issues/monorepo/issue123-turborepo-setup/` | `issue/123` | `issue/123-phase1` | `issue/123-phase2` |
+| `docs/specs/issues/auth/issue456-magic-link/` | `issue/456` | `issue/456-phase1` | `issue/456-phase2` |
+| `docs/specs/issues/user/issue789-profile/` | `issue/789` | `issue/789-phase1` | `issue/789-phase2` |
+
+---
+
+## task:loop 実行時のブランチ運用
+
+### タスク実行シーケンス
+
+```mermaid
+sequenceDiagram
+    participant User as 開発者
+    participant TL as task:loop
+    participant Git as Git
+    participant VK as Vibe-Kanban
+    participant CC as Claude Code
+
+    User->>TL: pnpm task:loop 123
+
+    rect rgb(230,240,255)
+        Note over TL,Git: 初期化フェーズ（Issueブランチのみ）
+        TL->>Git: git fetch origin
+        TL->>Git: git branch issue/123 origin/{IssueBranchBase}
+        TL->>Git: git push -u origin issue/123
+        Note over TL: Phaseブランチは作成しない
+    end
+
+    rect rgb(255,245,230)
+        Note over TL,CC: タスク実行フェーズ（各タスク開始時）
+        TL->>Git: syncPhaseBranch()
+        Note over Git: 既存なら最新化、なければ作成
+        TL->>VK: createTask(1.1)
+        TL->>VK: startTaskAttempt(base: issue/123-phase1)
+        VK->>Git: git worktree add
+        VK->>CC: Claude Code 起動
+        CC->>Git: 実装 & コミット & push
+        CC->>VK: タスク完了
+    end
+
+    rect rgb(230,255,230)
+        Note over TL,Git: 完了検知フェーズ（15秒ポーリング）
+        TL->>VK: listTasks() で Done 検知
+        TL->>Git: GitHub Issue チェックボックス更新
+        TL->>TL: 次の着手可能タスクを選定
+    end
+
+    rect rgb(255,245,230)
+        Note over TL,CC: 次タスク開始時（同期済み）
+        TL->>Git: syncPhaseBranch()
+        Note over Git: リモートの最新を取得
+        TL->>VK: createTask(1.2)
+        TL->>VK: startTaskAttempt(base: issue/123-phase1)
+        Note over Git: 前タスクの変更が含まれる
+    end
+```
+
+### ブランチ CRUD タイミング
+
+| 操作 | タイミング | 実行者 | 備考 |
+|-----|----------|--------|------|
+| **Create** Issue ブランチ | スクリプト起動時 | task:loop | IssueBranchBase から作成 |
+| **Sync** Issue ブランチ | タスク着手時 | task:loop | リモート最新化 + IssueBranchBase の変更取り込み |
+| **Create** Phase ブランチ | タスク着手時 | task:loop | 必要に応じて Issue ブランチから作成 |
+| **Sync** Phase ブランチ | タスク着手時 | task:loop | リモート最新化 + Issue ブランチの変更取り込み |
+| **Create** Worktree | タスク開始時 | Vibe-Kanban | 同期済み Phase ブランチをベースに作成 |
+| **Update** Phase ブランチ | PR マージ時 | GitHub | タスク完了後のマージで更新 |
+| **Merge** Phase → Issue | Phase 全タスク完了時 | task:loop | 完了した Phase を Issue ブランチに自動マージ |
+| **Delete** Worktree | タスク完了後 | Vibe-Kanban | 72時間後に自動削除 |
+| **Delete** Phase ブランチ | Issue 完了後 | 手動 | Issue ブランチにマージ後 |
+
+### Worktree ライフサイクル
+
+```mermaid
+stateDiagram-v2
+    [*] --> Created: startTaskAttempt()
+    Created --> Running: Claude Code 起動
+    Running --> Completed: タスク完了
+    Completed --> InReview: PR 作成待ち
+    InReview --> Merged: PR マージ
+    Merged --> Cleanup: 72時間後
+    Cleanup --> [*]: 自動削除
+```
+
+### syncPhaseBranch の動作
+
+タスク着手時に呼び出される `syncPhaseBranch` 関数は、以下のシーケンスでブランチを同期します：
+
+```mermaid
+sequenceDiagram
+    participant Main as main<br/>(base)
+    participant Issue as issue/123
+    participant Phase as issue/123-phase1
+    participant WT as worktree
+
+    Note over Main,WT: syncPhaseBranch() 実行時
+
+    rect rgb(240, 248, 255)
+        Note over Main,Issue: Step 1: Issue ブランチの同期
+        Issue->>Issue: fetch origin/issue/123
+        Issue->>Issue: merge origin/issue/123 (pull)
+        Main->>Issue: merge main (base変更の取り込み)
+        Issue->>Issue: push origin
+    end
+
+    rect rgb(255, 248, 240)
+        Note over Issue,Phase: Step 2: Phase ブランチの同期
+        Phase->>Phase: fetch origin/issue/123-phase1
+        Phase->>Phase: merge origin/issue/123-phase1 (pull)
+        Issue->>Phase: merge issue/123 (他Phaseの変更取り込み)
+        Phase->>Phase: push origin
+    end
+
+    rect rgb(240, 255, 240)
+        Note over Phase,WT: Step 3: Worktree作成
+        Phase-->>WT: base_branch として使用
+        Note over WT: Claude Code がタスク実行
+    end
+```
+
+**同期の原則**:
+- ローカルの変更は保持（削除→再作成はしない）
+- リモートとローカルが分岐した場合はマージで統合
+- コンフリクト発生時はエラーで停止（手動解決を促す）
+
+### 変更の取り込み対象
+
+| 取り込み元 | 取り込み先 | 取り込み内容 |
+|-----------|-----------|-------------|
+| IssueBranchBase | Issue ブランチ | 他の Issue やホットフィックスがマージした変更 |
+| リモートの Issue ブランチ | ローカル Issue ブランチ | 他の Phase がマージした変更 |
+| リモートの Phase ブランチ | ローカル Phase ブランチ | 同じ Phase の先行タスクがマージした変更 |
+| Issue ブランチ | Phase ブランチ | 他の Phase がマージした変更（Phase 間の変更共有） |
+
+### 変更の伝播フロー
+
+```
+IssueBranchBase（main, develop など）
+    ↓ マージ
+issue/123
+    ↓ マージ
+issue/123-phase1
+    ↓ base_branch として使用
+worktree（タスク実行）
+```
+
+これにより：
+- IssueBranchBase の最新変更が全タスクに反映される
+- 同じ Phase 内の先行タスクの変更が後続タスクに反映される
+- 他の Phase の完了した変更も全ての Phase に伝播される
+
+---
+
+## 手動ブランチ操作
+
+### 初回実行時
+
+```bash
+# 0. IssueBranchBase を決定（デフォルトブランチを取得する場合）
+DEFAULT_BRANCH=$(git remote show origin | grep 'HEAD branch' | awk '{print $NF}')
+
+# 1. Issueブランチを作成（IssueBranchBase から）
+git checkout $DEFAULT_BRANCH
+git pull origin $DEFAULT_BRANCH
+git checkout -b issue/123
+
+# 2. フェーズ1ブランチを作成（Issueブランチから）
+git checkout -b issue/123-phase1
+
+# 3. リモートにプッシュ
+git push -u origin issue/123-phase1
+```
+
+### 次のフェーズへ移行時
+
+```bash
+# 1. 親ブランチに戻る
+git checkout issue/123
+
+# 2. 前フェーズの完了内容をマージ
+git merge issue/123-phase1
+
+# 3. 次のフェーズブランチを作成
+git checkout -b issue/123-phase2
+
+# 4. リモートにプッシュ
+git push -u origin issue/123-phase2
+```
+
+### 全フェーズ完了後
+
+```bash
+# 1. Issueブランチに最終フェーズをマージ
+git checkout issue/123
+git merge issue/123-phase3
+
+# 2. IssueBranchBase にPRを作成
+gh pr create --base main --head issue/123 \
+  --title "feat: Monorepo Turborepoセットアップ完了" \
+  --body "全フェーズ完了。Phase 1-3の統合PR。"
+```
+
+---
+
+## ブランチマージ戦略
+
+### フェーズ完了時
+
+```bash
+# フェーズブランチを親ブランチにマージ
+git checkout issue/123
+git merge --no-ff issue/123-phase1
+git push origin issue/123
+```
+
+### タスク完了時
+
+```bash
+# IssueブランチをIssueBranchBaseにPRとしてマージ
+gh pr create --base main --head issue/123 \
+  --title "feat: Monorepo Turborepoセットアップ" \
+  --body "..."
+```
+
+---
+
+## ブランチ削除ポリシー
+
+### フェーズブランチ
+
+- 親ブランチにマージ後、削除可能
+- ただし、トレーサビリティのため残しておくことを推奨
+
+### Issueブランチ
+
+- IssueBranchBase にマージ後、PRクローズと同時に削除
+
+---
+
+## 注意事項
+
+1. **ブランチ名の一貫性**: すべてのブランチは命名規則に従うこと
+2. **フェーズ番号の明示**: フェーズ番号は必ず数字で明示（phase1, phase2, ...）
+3. **親ブランチの更新**: フェーズ完了時は必ず親ブランチにマージすること
+4. **リモート同期**: ブランチ作成後は必ずリモートにプッシュすること
+
+---
+
+## トラブルシューティング
+
+### ブランチが存在しない場合
+
+```bash
+# リモートから最新情報を取得
+git fetch origin
+
+# ブランチ一覧を確認
+git branch -a
+```
+
+### ブランチ名を間違えた場合
+
+```bash
+# ブランチ名を変更
+git branch -m 旧ブランチ名 新ブランチ名
+
+# リモートのブランチ名も更新
+git push origin :旧ブランチ名 新ブランチ名
+git push origin -u 新ブランチ名
+```
+
+### マージコンフリクト発生時
+
+```bash
+# コンフリクトを解決後、マージを完了
+git add .
+git commit -m "Merge phase1 into task branch"
+git push origin タスクブランチ名
+```
+
+---
+
+## 関連ドキュメント
+
+- [task:loop コマンド](../instructions/task-vibe-kanban-loop.md) - コマンドの使用方法と Vibe-Kanban 操作手順
+- [タスク管理](task-management.md) - タスク階層と粒度基準
+- [開発ワークフロー](development-workflow.md) - 仕様書作成からタスク実行までの全体フロー

package/scaffolds/steering/commit-rules.md

@@ -0,0 +1,217 @@
+# コミットルール
+
+## 重要：コミット分割ルールの厳守について
+
+- コミット分割ルールに違反した場合、重大なレビュープロセス阻害・履歴管理上の問題となるため、**絶対に違反しないこと**
+- 万一違反が発生した場合は、必ず即座に報告し、再発防止策（作業前の分割計画明示・コミット粒度の事前確認など）を徹底すること
+- 「まとめコミット」「複数目的の混在コミット」「コミット粒度の過剰肥大化」は**厳禁**
+- このルールは全開発者・AIアシスタントが例外なく厳守すること
+
+## コミットの流れ
+
+1. **コミット前の確認**
+   - コードがコンパイルできる状態か
+   - テストが通る状態か
+   - 不要なデバッグコードやコメントが残っていないか
+
+2. **最新化**
+   ```bash
+   git pull --rebase
+   ```
+
+3. **現在の状態確認**
+   ```bash
+   git status
+   ```
+
+4. **コミット分割方針の策定**
+   - 差分を「コミットの分割方針」に応じて分割
+   - 具体的なコミット分割とその内容、コミットメッセージの合意を取る
+   - 分割された各コミットの内容は「コミット内容の確認事項」に留意
+
+5. **コミットの実行**
+   - 合意したコミット方針でコミットを行う
+
+6. **プッシュ前の品質チェック（必須）**
+   ```bash
+   pnpm prepush
+   ```
+   - リント、型チェック、テストを一括実行
+   - エラーがある場合は修正してから再度実行
+
+7. **プッシュ**
+   ```bash
+   git push
+   ```
+
+## コミットの分割方針
+
+以下の場合は**必ず別々のコミットに分割**してください：
+
+### 1. 異なる目的や種類の変更
+- ソースコードの変更とドキュメントの更新
+- 機能追加と設定ファイルの変更
+- リファクタリングとバグ修正
+
+### 2. 異なるコンポーネントやモジュールの変更
+- 複数のマイクロサービスやコンポーネントの変更
+- フロントエンドとバックエンドの変更
+- インフラ構成とアプリケーションコードの変更
+
+### 3. レビューの容易さを考慮した分割
+- 大規模な変更は小さな論理的なまとまりに分割
+- 設定変更とその設定を使用するコードの変更は分割
+- テストコードの追加・更新は実装とは別のコミット
+
+## コミット分割の具体例
+
+以下のような変更がある場合の分割例：
+
+### 1. 構造的な変更
+```bash
+git commit -m "refactor: ディレクトリ構造の整理
+
+- 関連するファイルを適切なディレクトリに移動
+- 不要なファイルの削除
+- ファイル名の統一"
+```
+
+### 2. 実装の修正
+```bash
+git commit -m "fix: 実装の修正
+
+- バグの修正内容
+- 影響範囲
+- 修正理由"
+```
+
+### 3. テストの追加
+```bash
+git commit -m "test: テストの追加
+
+- 追加したテストの概要
+- テストでカバーする機能や条件
+- 既存テストの修正点"
+```
+
+### 4. 設定の更新
+```bash
+git commit -m "chore: 設定ファイルの更新
+
+- 更新した設定項目
+- 更新理由
+- 影響範囲"
+```
+
+### 5. ドキュメントの追加
+```bash
+git commit -m "docs: ドキュメントの追加
+
+- 追加したドキュメントの概要
+- 主な内容
+- 参照すべき関連ドキュメント"
+```
+
+## コミットメッセージの形式
+
+### 基本形式
+- プレフィックス: タイプを示す短い識別子
+- 日本語で記述
+- 1行目に概要、2行目以降に詳細を記述
+
+### プレフィックスの使い分け
+
+| プレフィックス | 用途 | 例 |
+|--------------|------|-----|
+| `feat:` | 新機能の追加 | `feat: ユーザー認証機能の追加` |
+| `fix:` | バグ修正 | `fix: ログイン時のエラー修正` |
+| `docs:` | ドキュメントの更新 | `docs: APIドキュメントの追加` |
+| `style:` | コードスタイルの修正 | `style: フォーマットの統一` |
+| `refactor:` | リファクタリング | `refactor: 認証処理の共通化` |
+| `test:` | テストの追加・修正 | `test: ユニットテストの追加` |
+| `chore:` | ビルドプロセスやツールの変更 | `chore: 依存パッケージの更新` |
+
+### 良いコミットメッセージの例
+
+```bash
+feat: ユーザー認証機能の追加
+
+- JWT認証の実装
+- ログイン・ログアウトエンドポイントの追加
+- 認証ミドルウェアの実装
+- テストケースの追加
+
+影響範囲：
+- /auth/*エンドポイント
+- ミドルウェア
+- ユーザーモデル
+```
+
+### 悪いコミットメッセージの例
+
+```bash
+update files  # 変更内容が不明確
+
+fix some bugs  # 具体的な修正内容が不明
+
+various changes  # 変更の種類や目的が不明確
+```
+
+## コミットの粒度と単位
+
+- **1つのコミットは1つの論理的な変更のみ**を含める
+- 機能追加やバグ修正は1つずつコミット
+- リファクタリングは機能変更と分けてコミット
+- 複数のファイルを変更する場合も、関連する変更は1つのコミットにまとめる
+- **1つのコミットの変更量は、レビューしやすい程度（100行程度）に抑える**
+- **コミット粒度の過剰肥大化・まとめコミットは禁止**
+
+## コミットのタイミング
+
+- 機能の実装が完了した時点でコミット
+- テストが通る状態でコミット
+- 1日の作業終了時には必ずコミット
+- 他の開発者と共有する前にコミット
+- 大きな変更は小分けにしてコミット
+- **コミットタイミングの逸脱やまとめコミットは禁止**
+
+## コミット内容の確認事項
+
+- 変更内容がコミットメッセージと一致しているか
+- 適切な粒度で分割されているか
+- 関連する変更が漏れなくコミットされているか
+
+## プッシュ前の必須確認
+
+**動作確認を必ず実行**: APIならcurl確認、スクリプトなら実行確認、画面ならMCPでブラウザ確認
+
+**重要**: プッシュ前には必ず `pnpm prepush` を実行してください。このコマンドは以下のチェックを行います：
+
+1. **コードフォーマット**: Biomeによる自動フォーマット
+2. **リントチェック**: コード品質の確認
+3. **型チェック**: TypeScriptの型エラーがないか確認
+4. **テスト実行**: 全てのテストが通ることを確認
+
+```bash
+# プッシュ前の必須コマンド
+pnpm prepush
+
+# エラーが出た場合は修正して再実行
+# 全てのチェックが通ってからプッシュ
+git push
+```
+
+**注意**: `pnpm prepush` を実行せずにプッシュしてCIで失敗した場合、履歴が汚れるため必ず事前実行すること。
+
+## ブランチ戦略
+
+| ブランチ | 用途 |
+|---------|------|
+| `main` | 本番環境用 |
+| `develop` | 開発環境用 |
+| `feature/*` | 機能開発用 |
+| `hotfix/*` | 緊急修正用 |
+
+## まとめ
+
+コミットルールの遵守は、プロジェクトの履歴管理とレビュープロセスの効率化に直結します。全ての開発者・AIアシスタントは、これらのルールを例外なく厳守してください。