twg-jira-resolve-merged-work

twg-jira-resolve-merged-work

マージ済み PR の証拠が十分に強い場合に限り、古くなった Jira 作業項目を解決します。まず計画を立て、承認後にのみ変更を加えます。

ライブの twg help／twg help describe <path> に記載された正確なコマンド構文を使用してください。ボード、スプリント、トランジション、ワークスペース、リポジトリ、PR、フィールドの構文を推測しないでください。

CLI ランチャーのフォールバック

twg <command> を実行します。シェルで command not found が発生した場合は、$HOME/.local/bin/twg（macOS/Linux）または $env:LOCALAPPDATA\Programs\twg\bin\twg.exe（PowerShell）を使用し、そのディレクトリを PATH に追加するようユーザーに伝えてください。認証エラーやコマンドエラーを PATH の問題として扱わないでください。

対象範囲

次のいずれかの Jira 対象範囲を受け付けます。

• 1 件の Jira 作業項目キー／URL。
• 明示的に指定された少数の Jira 作業項目キー／URL。
• ボードまたはスプリントの ID／URL。
• エピックキー。
• Jira スペース／プロジェクトキー。

デフォルトではドライランにします。ユーザーがレビュー済みの実行を依頼していない限り、変更前に確認してください。対象期間を限定し、指定がない場合は最近の進行中／完了済みスプリントの作業と、その前後の PR マージ日を調べます。

ワークフロー

1. Jira の候補を読み込みます。

   • 単一／リスト：指定された各作業項目を直接取得します。
   • スプリント：jira sprint workitems query。
   • ボード：ライブヘルプに記載されたボード／バックログ／スプリントのコマンドを使用します。
   • エピックまたはスペース：JQL ベースの jira workitem query。
   • キー、タイトル、ステータス／カテゴリ、担当者、更新日時、親、サブタスク／ブロッカー、URL を取得します。

2. 対象を分類します。

   • 候補は完了／解決済みではない作業項目です。同じボード、スプリント、エピック、またはスペース内で完了している項目は比較対象です。
   • エピック／親項目は除外します。ユーザーが明示的に許可していない限り、未解決のブロッカーや未完了のサブタスクがある項目はスキップします。

3. 対象全体で共有リポジトリのコンテキストを特定します。

   • 1 件のみ、または短いリストの場合でも、対象全体のコンテキストをまとめて推定します。
   • リンクされた PR、コミット、ブランチ、プロジェクトリンク、Compass／コンポーネント、コンテキストクエリ、完了済みの比較対象から、リポジトリ／ワークスペースを抽出します。
   • 完了済みの比較対象から、共通リポジトリ、担当者、Jira キーを含むタイトル／ブランチの命名規則、PR リンク、マージからトランジションまでの所要時間を推定します。

4. 任意の探索シグナルを確認します。

   • rovo list-apps で Bitbucket または GitHub への接続が確認できた場合は、キー、タイトル、PR URL、ブランチ、リポジトリを Rovo で検索します。TWG／プロバイダー／Jira の証拠で詳細を取得するまでは、探索情報として扱います。
   • search-code が利用可能な場合は、まず完全一致するキーを検索し、次に特定しやすいタイトル語を判明済みのリポジトリで検索します。有力なヒットはブランチ名、コミットテキスト、変更ファイル、シンボルです。広範囲なあいまい検索のヒットは弱い証拠として扱います。

5. 実装者の候補を広げます。

   • 完了済みの比較対象と候補の担当者を優先します。報告者とコメント投稿者は弱い手掛かりとして扱います。
   • 指定期間内に担当者が作成したマージ済み PR を問い合わせます。まず判明済みのリポジトリに範囲を絞り、不明な場合は作成者／日付の結果からリポジトリを推定します。

6. マージ済み PR をまとめて検索します。

   • リポジトリ／期間ごとにマージ済み PR の検索を 1 回実行し、その後すべての候補キーとローカルで照合する方法を優先します。1 件の PR が複数の完全一致キーに該当する場合もあります。
   • PR のタイトル、説明、ブランチ、コミット、リンクされた課題のメタデータから、完全一致するキーを探します。
   • 証拠がない場合、優先度の高い項目、または曖昧な場合に限り、作業項目ごとの検索に切り替えます。

7. 信頼度を評価します。

   • 高：マージ済み PR またはリンクされた PR のメタデータにキーが完全一致し、タイミングが妥当で、同じキーのオープン PR がなく、ブロッカー／サブタスクもなく、対象のトランジションが存在する。
   • 中：担当者／リポジトリが一致し、タイトルの類似性が高い場合、またはコミット／search-code の証拠にキーが完全一致する場合。
   • 低：あいまいな類似性、作成者のみが一致、リポジトリが不明、または曖昧さがある場合。

8. ドライラン計画を作成します。

   • 表の列：作業項目のキー／タイトル、現在のステータス、提案するトランジション、信頼度、簡潔な根拠、PR のタイトル／URL、マージ日、Jira の最終更新日、リンク／リポジトリの提案、PR タイトル修正の提案、スキップ理由、検証。
   • ライブヘルプで確認した後に限り、正確なコマンドを記載します。信頼度の低い行を実行可能なものとして提示してはいけません。

変更

対象の行または計画について明示的な承認を得てから変更してください。

• ステータス遷移：最初に遷移先を一覧表示し、承認された完了／解決済みの遷移先のみを使用してください。
• リンクの補完：リンクがない場合は、リンクを照会してヘルプを確認したうえで、PR／リポジトリの URL に対する jira workitem link weblink を提案してください。これによってネイティブの開発パネルのリンクが作成されると断言しないでください。
• PR タイトルの修正：Bitbucket では、検証済みの bitbucket pull-requests get リーフで PR を読み取れること、書き込み権限が確認されていること、PR が対象アイテムに確実に関連付けられていること、そしてユーザーの承認がある場合に限り、タイトルを更新してください。GitHub では、認証済みの書き込みツールが利用可能で、アクセス権が確認されている場合に限り更新してください。それ以外の場合は、理由を添えてスキップしてください。
• 検証：変更した各作業項目と PR を再読み込みしてください。変更したキー、ステータス、URL、失敗した行を報告してください。

信頼度が中程度の項目を自動的に遷移させないでください。却下済み／後続の PR や、同じ作成者、同じリポジトリ、あいまいな類似性のみを根拠とする行は遷移させないでください。

出力

最初に判断の概要を示してください。

• 実行可能な信頼度の高い行
• レビューが必要な信頼度が中程度の行
• 安全性に懸念があるためスキップした行
• 不足しているリポジトリ／認証／権限の確認範囲

続けてドライランの表と、承認を求める具体的な質問を記載してください。根拠として使用したすべての作業項目と PR について、URL または安定した ID を含めてください。