openspec-verify-change

実装が変更アーティファクト（仕様、タスク、設計）に適合していることを確認します。

ストアの選択： ユーザーがストア（このマシンに登録された独立した OpenSpec リポジトリ）を指定した場合、または作業対象がストア内にある場合は、openspec store list --json を実行して登録済みのストア ID を確認し、仕様や変更を読み書きするコマンド（new change、status、instructions、list、show、validate、archive、doctor、context）に --store <id> を指定します。それ以外のコマンドではこのフラグは不要です。コマンドが出力するヒントにはフラグがすでに含まれているため、後続のコマンドでも指定してください。ストアがない場合、コマンドは最も近い場所にあるローカルの openspec/ ルートを対象にします。

入力：変更名を指定できます。指定がない場合は、会話のコンテキストから推測できるかを確認します。曖昧な場合、または複数の候補がある場合は、利用可能な変更を必ずユーザーに尋ねてください。

手順

1. 変更名が指定されていない場合は、選択を促します

   openspec list --json を実行して、利用可能な変更を取得します。AskUserQuestion ツールを使用して、ユーザーが選択できるようにします。

   実装タスクがある変更（tasks アーティファクトが存在するもの）を表示します。 利用可能な場合は、各変更で使用されているスキーマを含めます。 タスクが未完了の変更には「（進行中）」と表示します。

   重要：変更を推測したり、自動選択したりしないでください。必ずユーザーに選択してもらいます。

2. スキーマを把握するため、ステータスを確認します

   openspec status --change "<name>" --json
   

   JSON を解析して、次の内容を把握します：

   • schemaName：使用中のワークフロー（例：「spec-driven」）
   • planningHome、changeRoot、artifactPaths、actionContext：パスと対象範囲のコンテキスト
   • この変更に存在するアーティファクト

3. 計画コンテキストを取得し、アーティファクトを読み込みます

   openspec instructions apply --change "<name>" --json
   

   これにより、変更ディレクトリと contextFiles（アーティファクト ID から具体的なファイルパスの配列への対応）が返されます。contextFiles にあるすべてのアーティファクトを読み込みます。

4. 検証レポートの構造を初期化します

   次の 3 つの観点でレポート構造を作成します：

   • 完全性：タスクと仕様の網羅状況を追跡します
   • 正確性：要件の実装状況とシナリオの網羅状況を追跡します
   • 一貫性：設計への準拠状況とパターンの一貫性を追跡します

   各観点には CRITICAL、WARNING、SUGGESTION の問題を設定できます。

5. 完全性を検証します

   タスクの完了状況：

   • contextFiles.tasks が存在する場合、その中のすべてのファイルパスを読み込みます
   • チェックボックスを解析します：- [ ]（未完了）と - [x]（完了）
   • 完了したタスク数とタスクの総数を数えます
   • 未完了のタスクがある場合：
     • 未完了のタスクごとに CRITICAL の問題を追加します
     • 推奨事項：「タスクを完了してください：<説明>」または「すでに実装済みの場合は、完了としてマークしてください」

   仕様の網羅状況：

   • contextFiles.specs に差分仕様がある場合：
     • すべての要件（「### Requirement:」で示されるもの）を抽出します
     • 各要件について：
       • 要件に関連するキーワードを使ってコードベースを検索します
       • 実装が存在する可能性を評価します
     • 要件が未実装と思われる場合：
       • CRITICAL の問題を追加します：「要件が見つかりません：<要件名>」
       • 推奨事項を追加します：「要件 X を実装してください：<説明>」

6. 正確性を検証します

   要件と実装の対応付け：

   • 差分仕様の各要件について：
     • コードベースを検索して実装の証拠を確認します
     • 見つかった場合は、ファイルパスと行範囲を記録します
     • 実装が要件の意図に合致しているかを評価します
     • 相違が見つかった場合：
       • WARNING を追加します：「実装が仕様と異なる可能性があります：<詳細>」
       • 推奨事項を追加します：「要件 X に照らして : を確認してください」

   シナリオの網羅状況：

   • 差分仕様の各シナリオ（「#### Scenario:」で示されるもの）について：
     • 条件がコードで処理されているかを確認します
     • シナリオを対象とするテストがあるかを確認します
     • シナリオが網羅されていないと思われる場合：
       • WARNING を追加します：「シナリオが網羅されていません：<シナリオ名>」
       • 推奨事項を追加します：「シナリオに対応するテストまたは実装を追加してください：<説明>」

7. 一貫性を検証します 設計への準拠：

   • contextFiles.design が存在する場合：
     • 主要な決定事項を抽出します（「Decision:」「Approach:」「Architecture:」などのセクションを確認）
     • 実装がそれらの決定事項に従っているか確認します
     • 矛盾が検出された場合：
       • WARNING を追加：「設計上の決定に従っていません：」
       • 推奨事項：「実装を更新するか、実際の状況に合わせて design.md を修正してください」
   • design.md がない場合：設計準拠のチェックをスキップし、「照合する design.md がありません」と記載します

   コードパターンの一貫性：

   • 新しいコードがプロジェクトのパターンと一貫しているか確認します
   • ファイル名、ディレクトリ構成、コーディングスタイルを確認します
   • 重大な逸脱が見つかった場合：
     • SUGGESTION を追加：「コードパターンからの逸脱：
       」
     • 推奨事項：「プロジェクトのパターンに従うことを検討してください：」

8. 検証レポートを生成

   サマリースコアカード：

   ## Verification Report: <change-name>
   
   ### Summary
   | Dimension    | Status           |
   |--------------|------------------|
   | Completeness | X/Y tasks, N reqs|
   | Correctness  | M/N reqs covered |
   | Coherence    | Followed/Issues  |
   

   優先度別の問題：

   1. CRITICAL（アーカイブ前に必ず修正）：

      • 未完了のタスク
      • 要件に対する実装の欠落
      • それぞれに具体的で実行可能な推奨事項を記載

   2. WARNING（修正を推奨）：

      • 仕様／設計との相違
      • シナリオカバレッジの不足
      • それぞれに具体的な推奨事項を記載

   3. SUGGESTION（修正すると望ましい）：

      • パターンの不整合
      • 軽微な改善点
      • それぞれに具体的な推奨事項を記載

   最終評価：

   • CRITICAL の問題がある場合：「重大な問題が X 件見つかりました。アーカイブする前に修正してください。」
   • WARNING のみの場合：「重大な問題はありません。検討すべき警告が Y 件あります。（改善点を確認のうえ）アーカイブ可能です。」
   • 問題がない場合：「すべてのチェックに合格しました。アーカイブ可能です。」

検証のヒューリスティクス

• 完全性：客観的なチェックリスト項目（チェックボックス、要件一覧）を重視します
• 正確性：キーワード検索、ファイルパスの分析、妥当な推論を使用します。完全な確実性は求めません
• 一貫性：明白な不整合を探し、スタイルを細かく指摘しすぎないでください
• 誤検知：確信が持てない場合は、WARNING より SUGGESTION を、CRITICAL より WARNING を優先します
• 実行可能性：すべての問題に、該当する場合はファイル／行番号を含む具体的な推奨事項を付けます

段階的なチェックの省略

• tasks.md のみがある場合：タスクの完了のみを検証し、仕様／設計のチェックはスキップします
• タスクと仕様がある場合：完全性と正確性を検証し、設計のチェックはスキップします
• すべての成果物がある場合：3 つすべての側面を検証します
• どのチェックを省略したか、またその理由を必ず記載します

出力形式

以下を含む、明確な Markdown を使用します：

• サマリースコアカードの表
• 問題をグループ化したリスト（CRITICAL／WARNING／SUGGESTION）
• file.ts:123 形式のコード参照
• 具体的で実行可能な推奨事項
• 「確認を検討してください」のような曖昧な提案は使用しない

テスト更新22