Files
2025-11-30 08:35:56 +08:00

14 KiB
Raw Permalink Blame History

description, argument-hint, allowed-tools
description argument-hint allowed-tools
GitHub Issueの最新情報を同期してタスクとの整合性を確認するリファインメントグループ・カテゴリ考慮 <issue_number> [--force-rerefine] [--preserve-completed] Bash, Read, Write, Edit, Glob

GitHub Issue 同期

指定されたGitHub Issue #$1 の最新情報をローカルのPBIデータと同期し、リファインメントグループとカテゴリ構造を考慮した再構成を提案します。

同期オプション

/task-sync 123                    # 標準同期(変更検知時のみ更新)
/task-sync 123 --force-rerefine   # 強制的にリファインメント再実行
/task-sync 123 --preserve-completed # 完了タスクは保護して同期

実行内容

1. 多層同期状況確認

ローカル情報の取得:

  • tasks/pbi-$1/README.md からローカルの最終更新日時を取得
  • リファインメント完了フェーズphaseの確認
  • .refine-progress.json からグループ進捗の確認
  • カテゴリ別タスク状況の把握

リモート情報の取得:

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の段階的更新:

---
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: 安全な部分更新(推奨)

/task-sync 123 --preserve-completed

実行内容:
1. 完了タスク (done-*.md) は保護
2. 実行中タスク (wip-*.md) は todo に戻して保留
3. 未着手タスク (todo-*.md) のみ削除・再生成
4. README.md の履歴に同期ログ追加
5. Group 2 から段階的リファインメント実行

Option B: 強制的な完全リファインメント

/task-sync 123 --force-rerefine

⚠️  危険: 全ての進行中作業が失われます
実行内容:
1. .refine-progress.json をリセット
2. 全タスクファイル削除backup作成後
3. Group 1 から完全リファインメント実行
4. 新しいカテゴリ構造で再構築

手動調整オプション

段階的手動調整:
1. 特定カテゴリのみ更新
   find tasks/pbi-$1 -name "todo-services-*.md" -delete
   # サービス系タスクのみ手動再作成

2. 実行中タスクの内容更新
   # wip-models-2.md の要件を新仕様に合わせて編集
   # 実装メモに移行作業を記録

3. 依存関係の再調整
   # カテゴリ間依存関係を新要件に合わせて更新
   # タスクファイルの depends_on フィールド修正

安全対策とバックアップ

# 実行前の自動バックアップ
cp -r tasks/pbi-$1 tasks/pbi-$1.backup.$(date +%Y%m%d_%H%M%S)

# 段階的実行での中断ポイント
# Group 2 完了後、Group 3 実行前にユーザー確認
# カテゴリ別タスク生成後、依存関係確認でユーザー確認

# ロールバック機能
# 問題が発生した場合、前回の同期状態に戻すオプション

使用するコマンド

# 多層情報取得
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内容の整合性が評価されている
  • 影響を受けるグループが特定されている
  • 必要な再リファインメント範囲が明確になっている

カテゴリ・タスク整合性要件

  • カテゴリ別の影響度が正確に評価されている
  • 依存関係の変更が適切に分析されている
  • 実行中タスクへの影響とリスクが明示されている
  • 完了タスクの保護策が実施されている

再構成提案要件

  • 複数の再構成戦略が提示されている
  • 推奨戦略の根拠が明確に示されている
  • 実行プランが具体的で実行可能
  • 安全対策とロールバック手順が提供されている

ユーザー支援要件

  • 次のアクションが明確で実行可能
  • リスクと期待効果が適切に説明されている
  • 段階的実行でのチェックポイントが設定されている

実行を開始しますか?