--- description: GitHub Issueの最新情報を同期してタスクとの整合性を確認する（リファインメントグループ・カテゴリ考慮） argument-hint: [--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: 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内容の整合性が評価されている - 影響を受けるグループが特定されている - 必要な再リファインメント範囲が明確になっている ### カテゴリ・タスク整合性要件 - カテゴリ別の影響度が正確に評価されている - 依存関係の変更が適切に分析されている - 実行中タスクへの影響とリスクが明示されている - 完了タスクの保護策が実施されている ### 再構成提案要件 - 複数の再構成戦略が提示されている - 推奨戦略の根拠が明確に示されている - 実行プランが具体的で実行可能 - 安全対策とロールバック手順が提供されている ### ユーザー支援要件 - 次のアクションが明確で実行可能 - リスクと期待効果が適切に説明されている - 段階的実行でのチェックポイントが設定されている 実行を開始しますか？