410 lines
14 KiB
Markdown
410 lines
14 KiB
Markdown
---
|
||
description: GitHub Issueの最新情報を同期してタスクとの整合性を確認する（リファインメントグループ・カテゴリ考慮）
|
||
argument-hint: <issue_number> [--force-rerefine] [--preserve-completed]
|
||
allowed-tools: Bash, Read, Write, Edit, Glob
|
||
---
|
||
|
||
# GitHub Issue 同期
|
||
|
||
指定されたGitHub Issue #$1 の最新情報をローカルのPBIデータと同期し、リファインメントグループとカテゴリ構造を考慮した再構成を提案します。
|
||
|
||
## 同期オプション
|
||
|
||
```bash
|
||
/task-sync 123 # 標準同期（変更検知時のみ更新）
|
||
/task-sync 123 --force-rerefine # 強制的にリファインメント再実行
|
||
/task-sync 123 --preserve-completed # 完了タスクは保護して同期
|
||
```
|
||
|
||
## 実行内容
|
||
|
||
### 1. 多層同期状況確認
|
||
|
||
**ローカル情報の取得:**
|
||
- `tasks/pbi-$1/README.md` からローカルの最終更新日時を取得
|
||
- リファインメント完了フェーズ（phase）の確認
|
||
- `.refine-progress.json` からグループ進捗の確認
|
||
- カテゴリ別タスク状況の把握
|
||
|
||
**リモート情報の取得:**
|
||
```bash
|
||
gh issue view $1 --json title,body,url,updatedAt,labels,milestone
|
||
```
|
||
|
||
**多層変更検知:**
|
||
- **Issue層**: タイトル、本文、ラベル、マイルストーンの変更
|
||
- **リファインメント層**: 既存のGroup決定事項との整合性
|
||
- **タスク層**: カテゴリ構造と実装方針の妥当性
|
||
- **時系列層**: Issue更新とローカル更新の時間差分析
|
||
|
||
### 2. 同期状況の表示（多層分析）
|
||
|
||
```
|
||
=== GitHub Issue #$1 同期状況 ===
|
||
|
||
📊 基本情報
|
||
ローカル最終更新: 2024-01-15T10:30:00Z
|
||
Issue最終更新: 2024-01-16T14:20:00Z
|
||
リファインメントフェーズ: completed (Group 3完了)
|
||
実装進捗: 3/8 タスク完了 (37.5%)
|
||
|
||
🔍 変更検出結果
|
||
✅ タイトル: 変更なし
|
||
⚠️ 本文: 更新あり (新機能要件追加の可能性)
|
||
✅ ラベル: 変更なし
|
||
⚠️ マイルストーン: v1.0 → v1.1 に変更
|
||
|
||
📋 リファインメント整合性チェック
|
||
Group 1 (要件・制約): 📝 再確認が必要
|
||
- Issue本文の新要件がGroup 1決定と矛盾する可能性
|
||
Group 2 (技術設計): ✅ 整合性維持
|
||
- 技術スタック選択に影響なし
|
||
Group 3 (タスク構成): ⚠️ 見直し推奨
|
||
- 新要件により追加タスクが必要な可能性
|
||
|
||
🏗️ カテゴリ別影響分析
|
||
Setup: ✅ 影響なし (完了済み)
|
||
Models: ⚠️ 新データ要件の可能性
|
||
Services: ⚠️ API拡張が必要な可能性
|
||
UI: 📝 新画面要件を確認必要
|
||
Tests: ⚠️ テストケース追加が必要な可能性
|
||
|
||
=== 更新されたIssue内容（抜粋） ===
|
||
【新機能要件】
|
||
+ "ユーザーは複数の認証方法を選択できる"
|
||
+ "ソーシャルログイン（Google、GitHub）を追加"
|
||
|
||
【変更された要件】
|
||
~ "パスワードリセット" → "パスワードリセット + 2FA設定"
|
||
|
||
... (続きは GitHub Issue で確認)
|
||
```
|
||
|
||
### 3. 多層ローカル情報の更新
|
||
|
||
**README.mdの段階的更新:**
|
||
```yaml
|
||
---
|
||
issue: $1
|
||
title: <最新のタイトル>
|
||
url: <最新のURL>
|
||
phase: <current_phase>
|
||
sync_history:
|
||
- date: 2024-01-16T14:30:00Z
|
||
changes: ["milestone_updated", "requirements_added"]
|
||
impact_analysis: "Group1_recheck_required"
|
||
created: <元の作成日時>
|
||
updated: <現在の日時>
|
||
---
|
||
```
|
||
|
||
**同期履歴の記録:**
|
||
- 同期実行日時と検出した変更内容
|
||
- 影響を受けるリファインメントグループの特定
|
||
- カテゴリ別の影響度評価
|
||
- 推奨される次のアクション
|
||
|
||
**リファインメント整合性の更新:**
|
||
- `.refine-progress.json` に同期結果を反映
|
||
- Group決定事項の再検証が必要な箇所をマーク
|
||
- カテゴリ別タスクの妥当性フラグ更新
|
||
|
||
### 4. 構造化タスク再構成の検討
|
||
|
||
**変更内容のレイヤー別分析:**
|
||
```
|
||
📊 要件レイヤー分析
|
||
新機能: ソーシャルログイン追加
|
||
機能拡張: 2FA機能の追加
|
||
削除機能: なし
|
||
優先度変更: マイルストーン v1.0 → v1.1
|
||
|
||
🏗️ アーキテクチャへの影響
|
||
認証フロー: 大幅変更が必要
|
||
データモデル: user_auth_methods テーブル追加
|
||
API設計: OAuth エンドポイント追加
|
||
セキュリティ: 外部プロバイダ連携考慮
|
||
|
||
📋 カテゴリ別インパクト評価
|
||
Setup: ✅ 影響小 (OAuth ライブラリ追加のみ)
|
||
Models: 🔴 影響大 (新テーブル設計必要)
|
||
Services: 🔴 影響大 (OAuth実装、2FA実装)
|
||
UI: 🟡 影響中 (ソーシャルログインボタン追加)
|
||
Tests: 🟡 影響中 (OAuth/2FA テストケース追加)
|
||
```
|
||
|
||
**現在のタスク状況とリスク評価:**
|
||
```
|
||
📊 現在のタスク状況
|
||
✅ 完了: 1タスク (Setup完了)
|
||
影響: なし（完了済みタスクは保護）
|
||
|
||
⏳ 実行中: 1タスク (Models: User model実装)
|
||
リスク: 🔴 高
|
||
理由: 認証データ構造の大幅変更が必要
|
||
推奨: 現在の作業を一時停止し、設計見直し
|
||
|
||
⬜ 未着手: 6タスク
|
||
影響: 🔴 大部分で見直し必要
|
||
Services: OAuth/2FA実装により大幅変更
|
||
UI: ソーシャルログイン対応で変更
|
||
Tests: 新機能に対応したテスト設計が必要
|
||
```
|
||
|
||
**リファインメントグループへの影響:**
|
||
```
|
||
🔄 Group 1 (要件・制約) - 再実行推奨
|
||
現在の決定: 基本認証のみ、中規模対応
|
||
新要件: マルチ認証、外部連携、2FA
|
||
→ 要件確定からやり直しが必要
|
||
|
||
🔄 Group 2 (技術設計) - 部分見直し
|
||
現在の設計: JWT単体、シンプル認証
|
||
新設計: OAuth対応、2FA統合、プロバイダ管理
|
||
→ 認証アーキテクチャの再設計が必要
|
||
|
||
🔄 Group 3 (タスク構成) - 全面見直し
|
||
現在: 8タスク、シンプル実装フロー
|
||
新構成: 12-15タスク想定、複雑な依存関係
|
||
→ 完全なタスク再分解が必要
|
||
```
|
||
|
||
### 5. 段階的再構成提案
|
||
|
||
**再構成戦略の選択肢:**
|
||
```
|
||
🎯 戦略A: 部分的更新（推奨）
|
||
対象: 未着手タスクのみ更新
|
||
期間: 2-3時間
|
||
リスク: 低
|
||
適用条件: 実行中タスクの影響が限定的
|
||
|
||
🔄 戦略B: 段階的リファインメント
|
||
対象: Group 2から再実行
|
||
期間: 4-6時間
|
||
リスク: 中
|
||
適用条件: 技術設計の大幅変更が必要
|
||
|
||
🏗️ 戦略C: 完全リファインメント
|
||
対象: Group 1から全面やり直し
|
||
期間: 1-2日
|
||
リスク: 高（既存作業の無駄）
|
||
適用条件: 要件が根本的に変更
|
||
```
|
||
|
||
**推奨戦略: 戦略B（段階的リファインメント）**
|
||
```
|
||
📋 実行プラン:
|
||
|
||
1. 現在の実行中タスク (wip-models-2.md) を一時停止
|
||
- 作業内容を実装メモに記録
|
||
- todo状態に戻して保留
|
||
|
||
2. Group 2 (技術設計) から再実行
|
||
- OAuth/2FA対応のアーキテクチャ設計
|
||
- 新しいデータモデル設計
|
||
- API仕様の見直し
|
||
|
||
3. Group 3 (タスク構成) で新しいタスク分解
|
||
- Setup: OAuth ライブラリ追加
|
||
- Models: 認証関連テーブル設計（拡張版）
|
||
- Services: OAuth実装、2FA実装、既存API
|
||
- UI: ソーシャルログイン、2FA設定画面
|
||
- Tests: 統合認証テスト
|
||
|
||
4. 既存完了タスクの統合
|
||
- Setup-1 (完了済み) は新Setup-1にマージ
|
||
- Models-1 (実行中) は新Models-1として再設計
|
||
```
|
||
|
||
**カテゴリ別タスク影響分析:**
|
||
```
|
||
📂 Setup (影響: 小)
|
||
現在: todo-setup-1.md "プロジェクト環境構築"
|
||
新規: OAuth ライブラリ (passport, google-auth) 追加
|
||
|
||
📂 Models (影響: 大)
|
||
現在: wip-models-2.md "認証関連テーブル設計"
|
||
新規: user_auth_methods, oauth_tokens テーブル追加
|
||
2FA設定テーブル追加
|
||
|
||
📂 Services (影響: 大)
|
||
現在: 2タスク (基本認証API)
|
||
新規: 4-5タスク (OAuth, 2FA, 統合認証)
|
||
|
||
📂 UI (影響: 中)
|
||
現在: 2タスク (ログイン・登録フォーム)
|
||
新規: 3-4タスク (ソーシャル選択、2FA設定追加)
|
||
|
||
📂 Tests (影響: 中)
|
||
現在: 1タスク (基本認証テスト)
|
||
新規: 2-3タスク (OAuth, 2FA, 統合テスト)
|
||
```
|
||
|
||
### 6. 実行オプションと安全対策
|
||
|
||
**Option A: 安全な部分更新（推奨）**
|
||
```bash
|
||
/task-sync 123 --preserve-completed
|
||
|
||
実行内容:
|
||
1. 完了タスク (done-*.md) は保護
|
||
2. 実行中タスク (wip-*.md) は todo に戻して保留
|
||
3. 未着手タスク (todo-*.md) のみ削除・再生成
|
||
4. README.md の履歴に同期ログ追加
|
||
5. Group 2 から段階的リファインメント実行
|
||
```
|
||
|
||
**Option B: 強制的な完全リファインメント**
|
||
```bash
|
||
/task-sync 123 --force-rerefine
|
||
|
||
⚠️ 危険: 全ての進行中作業が失われます
|
||
実行内容:
|
||
1. .refine-progress.json をリセット
|
||
2. 全タスクファイル削除（backup作成後）
|
||
3. Group 1 から完全リファインメント実行
|
||
4. 新しいカテゴリ構造で再構築
|
||
```
|
||
|
||
**手動調整オプション**
|
||
```bash
|
||
段階的手動調整:
|
||
1. 特定カテゴリのみ更新
|
||
find tasks/pbi-$1 -name "todo-services-*.md" -delete
|
||
# サービス系タスクのみ手動再作成
|
||
|
||
2. 実行中タスクの内容更新
|
||
# wip-models-2.md の要件を新仕様に合わせて編集
|
||
# 実装メモに移行作業を記録
|
||
|
||
3. 依存関係の再調整
|
||
# カテゴリ間依存関係を新要件に合わせて更新
|
||
# タスクファイルの depends_on フィールド修正
|
||
```
|
||
|
||
**安全対策とバックアップ**
|
||
```bash
|
||
# 実行前の自動バックアップ
|
||
cp -r tasks/pbi-$1 tasks/pbi-$1.backup.$(date +%Y%m%d_%H%M%S)
|
||
|
||
# 段階的実行での中断ポイント
|
||
# Group 2 完了後、Group 3 実行前にユーザー確認
|
||
# カテゴリ別タスク生成後、依存関係確認でユーザー確認
|
||
|
||
# ロールバック機能
|
||
# 問題が発生した場合、前回の同期状態に戻すオプション
|
||
```
|
||
|
||
## 使用するコマンド
|
||
|
||
```bash
|
||
# 多層情報取得
|
||
gh issue view $1 --json title,body,url,updatedAt,labels,milestone,assignees
|
||
|
||
# ローカル状態の包括的確認
|
||
grep "^updated:" tasks/pbi-$1/README.md
|
||
grep "^phase:" tasks/pbi-$1/README.md
|
||
ls tasks/pbi-$1/.refine-progress.json 2>/dev/null
|
||
|
||
# リファインメントグループ進捗の確認
|
||
if [ -f "tasks/pbi-$1/.refine-progress.json" ]; then
|
||
jq -r '.current_group, .completed_groups[].group' tasks/pbi-$1/.refine-progress.json
|
||
fi
|
||
|
||
# カテゴリ別タスク状況確認
|
||
for category in setup models services ui tests; do
|
||
echo "$category:"
|
||
find tasks/pbi-$1 -name "done-$category-*.md" | wc -l
|
||
find tasks/pbi-$1 -name "wip-$category-*.md" | wc -l
|
||
find tasks/pbi-$1 -name "todo-$category-*.md" | wc -l
|
||
done
|
||
|
||
# 依存関係とブロック状況の確認
|
||
for todo_file in tasks/pbi-$1/todo-*.md; do
|
||
if [ -f "$todo_file" ]; then
|
||
depends=$(grep "depends_on:" "$todo_file" | cut -d: -f2)
|
||
echo "$(basename $todo_file): depends on [$depends]"
|
||
fi
|
||
done
|
||
|
||
# 同期履歴の更新
|
||
sync_entry="{
|
||
\"date\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",
|
||
\"changes\": [\"issue_updated\"],
|
||
\"impact_analysis\": \"group2_recheck_required\"
|
||
}"
|
||
|
||
# README.mdの拡張メタデータ更新
|
||
sed -i.bak "s/^updated:.*/updated: $(date -u +%Y-%m-%dT%H:%M:%SZ)/" tasks/pbi-$1/README.md
|
||
echo "sync_history:" >> tasks/pbi-$1/README.md
|
||
echo " - $sync_entry" >> tasks/pbi-$1/README.md
|
||
|
||
# バックアップの作成
|
||
backup_dir="tasks/pbi-$1.backup.$(date +%Y%m%d_%H%M%S)"
|
||
cp -r tasks/pbi-$1 $backup_dir
|
||
echo "Backup created: $backup_dir"
|
||
```
|
||
|
||
## 同期判定ロジック
|
||
|
||
**変更検知の条件:**
|
||
1. **タイトル変更**: ローカルタイトル ≠ Issue タイトル
|
||
2. **内容更新**: Issue updatedAt > ローカル updated
|
||
3. **URL変更**: ローカルURL ≠ Issue URL
|
||
|
||
**同期の必要性:**
|
||
- いずれかの変更が検知された場合
|
||
- ユーザーが明示的に同期を要求した場合
|
||
|
||
## 再構成時の安全対策
|
||
|
||
**実行中タスクの保護:**
|
||
- wipタスクがある場合は慎重な操作を促す
|
||
- 破壊的変更前の確認プロンプト
|
||
|
||
**完了タスクの保護:**
|
||
- doneタスクは原則として変更しない
|
||
- 履歴として保持
|
||
|
||
**バックアップの推奨:**
|
||
- 重要な変更前のディレクトリバックアップ提案
|
||
|
||
## エラーハンドリング
|
||
|
||
- GitHub CLI未認証時のエラー
|
||
- 指定されたIssueが存在しない場合
|
||
- PBIディレクトリが存在しない場合
|
||
- ネットワーク接続エラー時の対応
|
||
|
||
## 完了条件
|
||
|
||
### 基本同期要件
|
||
- Issue情報が正常に取得されている
|
||
- ローカル情報が最新の内容で更新されている
|
||
- 変更内容が適切に分析・表示されている
|
||
- 同期履歴が記録されている
|
||
|
||
### リファインメント整合性要件
|
||
- Group 1-3 の決定事項と新Issue内容の整合性が評価されている
|
||
- 影響を受けるグループが特定されている
|
||
- 必要な再リファインメント範囲が明確になっている
|
||
|
||
### カテゴリ・タスク整合性要件
|
||
- カテゴリ別の影響度が正確に評価されている
|
||
- 依存関係の変更が適切に分析されている
|
||
- 実行中タスクへの影響とリスクが明示されている
|
||
- 完了タスクの保護策が実施されている
|
||
|
||
### 再構成提案要件
|
||
- 複数の再構成戦略が提示されている
|
||
- 推奨戦略の根拠が明確に示されている
|
||
- 実行プランが具体的で実行可能
|
||
- 安全対策とロールバック手順が提供されている
|
||
|
||
### ユーザー支援要件
|
||
- 次のアクションが明確で実行可能
|
||
- リスクと期待効果が適切に説明されている
|
||
- 段階的実行でのチェックポイントが設定されている
|
||
|
||
実行を開始しますか？ |