msd-core/docs/ja-JP/FEATURES.md

# MSD 機能リファレンス

> 全機能と要件の完全なドキュメントです。アーキテクチャの詳細については[アーキテクチャ](ARCHITECTURE.md)を、コマンド構文については[コマンドリファレンス](COMMANDS.md)をご覧ください。

---

## 目次

- [コア機能](#コア機能)
  - [プロジェクト初期化](#1-プロジェクト初期化)
  - [フェーズディスカッション](#2-フェーズディスカッション)
  - [UI デザインコントラクト](#3-ui-デザインコントラクト)
  - [フェーズプランニング](#4-フェーズプランニング)
  - [フェーズ実行](#5-フェーズ実行)
  - [作業検証](#6-作業検証)
  - [UI レビュー](#7-ui-レビュー)
  - [マイルストーン管理](#8-マイルストーン管理)
- [プランニング機能](#プランニング機能)
  - [フェーズ管理](#9-フェーズ管理)
  - [Quick モード](#10-quick-モード)
  - [自律モード](#11-自律モード)
  - [フリーフォームルーティング](#12-フリーフォームルーティング)
  - [ノートキャプチャ](#13-ノートキャプチャ)
  - [自動進行（Next）](#14-自動進行next)
- [品質保証機能](#品質保証機能)
  - [Nyquist バリデーション](#15-nyquist-バリデーション)
  - [プランチェック](#16-プランチェック)
  - [実行後検証](#17-実行後検証)
  - [ノードリペア](#18-ノードリペア)
  - [ヘルスバリデーション](#19-ヘルスバリデーション)
  - [クロスフェーズ回帰ゲート](#20-クロスフェーズ回帰ゲート)
  - [要件カバレッジゲート](#21-要件カバレッジゲート)
- [コンテキストエンジニアリング機能](#コンテキストエンジニアリング機能)
  - [コンテキストウィンドウ監視](#22-コンテキストウィンドウ監視)
  - [セッション管理](#23-セッション管理)
  - [セッションレポート](#24-セッションレポート)
  - [マルチエージェントオーケストレーション](#25-マルチエージェントオーケストレーション)
  - [モデルプロファイル](#26-モデルプロファイル)
- [ブラウンフィールド機能](#ブラウンフィールド機能)
  - [コードベースマッピング](#27-コードベースマッピング)
  - [既存コードベースオンボーディング](#27b-既存コードベースオンボーディング)
- [ユーティリティ機能](#ユーティリティ機能)
  - [デバッグシステム](#28-デバッグシステム)
  - [Todo 管理](#29-todo-管理)
  - [統計ダッシュボード](#30-統計ダッシュボード)
  - [アップデートシステム](#31-アップデートシステム)
  - [設定管理](#32-設定管理)
  - [テスト生成](#33-テスト生成)
- [インフラストラクチャ機能](#インフラストラクチャ機能)
  - [Git 連携](#34-git-連携)
  - [CLI ツール](#35-cli-ツール)
  - [マルチランタイムサポート](#36-マルチランタイムサポート)
  - [フックシステム](#37-フックシステム)
  - [開発者プロファイリング](#38-開発者プロファイリング)
  - [実行ハードニング](#39-実行ハードニング)
  - [検証デット追跡](#40-検証デット追跡)
- [v1.27 の機能](#v127-の機能)
  - [Fast モード](#41-fast-モード)
  - [クロス AI ピアレビュー](#42-クロス-ai-ピアレビュー)
  - [バックログパーキングロット](#43-バックログパーキングロット)
  - [永続コンテキストスレッド](#44-永続コンテキストスレッド)
  - [PR ブランチフィルタリング](#45-pr-ブランチフィルタリング)
  - [セキュリティハードニング](#46-セキュリティハードニング)
  - [マルチリポワークスペースサポート](#47-マルチリポワークスペースサポート)
  - [ディスカッション監査証跡](#48-ディスカッション監査証跡)
- [v1.28 の機能](#v128-の機能)
  - [フォレンジクス](#49-フォレンジクス)
  - [マイルストーンサマリー](#50-マイルストーンサマリー)
  - [ワークストリームネームスペーシング](#51-ワークストリームネームスペーシング)
  - [マネージャーダッシュボード](#52-マネージャーダッシュボード)
  - [Assumptions ディスカッションモード](#53-assumptions-ディスカッションモード)
  - [UI フェーズ自動検出](#54-ui-フェーズ自動検出)
  - [マルチランタイムインストーラー選択](#55-マルチランタイムインストーラー選択)
- [v1.29 の機能](#v129-の機能)
  - [Windsurf ランタイムサポート](#56-windsurf-ランタイムサポート)
  - [国際化ドキュメント](#57-国際化ドキュメント)
- [v1.31 の機能](#v131-の機能)
  - [スキーマドリフト検出](#59-スキーマドリフト検出)
  - [セキュリティエンフォースメント](#60-セキュリティエンフォースメント)
  - [ドキュメント生成](#61-ドキュメント生成)
  - [ディスカスチェーンモード](#62-ディスカスチェーンモード)
  - [単一フェーズ自律モード](#63-単一フェーズ自律モード)
  - [スコープ削減検出](#64-スコープ削減検出)
  - [クレーム出所タグ付け](#65-クレーム出所タグ付け)
  - [Worktree トグル](#66-worktree-トグル)
  - [プロジェクトコードプレフィックス](#67-プロジェクトコードプレフィックス)
  - [Claude Code スキルマイグレーション](#68-claude-code-スキルマイグレーション)
- [v1.32 の機能](#v132-の機能)
  - [STATE.md 整合性ゲート](#69-statemd-整合性ゲート)
  - [自律モード `--to N` フラグ](#70-自律モード---to-n-フラグ)
  - [リサーチゲート](#71-リサーチゲート)
  - [ベリファイヤーマイルストーンスコープフィルタリング](#72-ベリファイヤーマイルストーンスコープフィルタリング)
  - [Read-Before-Edit ガードフック](#73-read-before-edit-ガードフック)
  - [コンテキスト削減](#74-コンテキスト削減)
  - [ディスカスフェーズ `--power` フラグ](#75-ディスカスフェーズ---power-フラグ)
  - [デバッグ `--diagnose` フラグ](#76-デバッグ---diagnose-フラグ)
  - [フェーズ依存関係分析](#77-フェーズ依存関係分析)
  - [アンチパターン重大度レベル](#78-アンチパターン重大度レベル)
  - [メソドロジーアーティファクトタイプ](#79-メソドロジーアーティファクトタイプ)
  - [プランナー到達可能性チェック](#80-プランナー到達可能性チェック)
  - [Playwright-MCP UI 検証](#81-playwright-mcp-ui-検証)
  - [Pause-Work 拡張](#82-pause-work-拡張)
  - [レスポンス言語設定](#83-レスポンス言語設定)
  - [手動アップデート手順](#84-手動アップデート手順)
  - [新規ランタイムサポート (Trae, Cline, Augment Code)](#85-新規ランタイムサポート-trae-cline-augment-code)
  - [自律モード `--interactive` フラグ](#86-自律モード---interactive-フラグ)
  - [コミットドキュメントガードフック](#87-コミットドキュメントガードフック)
  - [コミュニティフックオプトイン](#88-コミュニティフックオプトイン)
- [v1.34.0 の機能](#v1340-の機能)
  - [グローバル学習ストア](#89-グローバル学習ストア)
  - [クエリ可能コードベースインテリジェンス](#90-クエリ可能コードベースインテリジェンス)
  - [実行コンテキストプロファイル](#91-実行コンテキストプロファイル)
  - [ゲート分類法](#92-ゲート分類法)
  - [コードレビューパイプライン](#93-コードレビューパイプライン)
  - [ソクラテス的探索](#94-ソクラテス的探索)
  - [セーフアンドゥ](#95-セーフアンドゥ)
  - [プランインポート](#96-プランインポート)
  - [高速コードベーススキャン](#97-高速コードベーススキャン)
  - [自律監査から修正](#98-自律監査から修正)
  - [改善されたプロンプトインジェクションスキャナー](#99-改善されたプロンプトインジェクションスキャナー)
  - [プランフェーズのストール検出](#100-プランフェーズのストール検出)
  - [/msd-progress --next のハードストップ安全ゲート](#101-msd-progress---next-のハードストップ安全ゲート)
  - [アダプティブモデルプリセット](#102-アダプティブモデルプリセット)
  - [ポストマージハンク検証](#103-ポストマージハンク検証)
- [v1.35.0 の機能](#v1350-の機能)
  - [新規ランタイムサポート (Cline, CodeBuddy, Qwen Code)](#104-新規ランタイムサポート-cline-codebuddy-qwen-code)
  - [GSD-2 逆マイグレーション](#105-gsd-2-逆マイグレーション)
  - [AI 統合フェーズウィザード](#106-ai-統合フェーズウィザード)
  - [AI 評価レビュー](#107-ai-評価レビュー)
- [v1.36.0 の機能](#v1360-の機能)
  - [プランバウンス](#108-プランバウンス)
  - [外部コードレビューコマンド](#109-外部コードレビューコマンド)
  - [クロス AI 実行デリゲーション](#110-クロス-ai-実行デリゲーション)
  - [アーキテクチャ責任マッピング](#111-アーキテクチャ責任マッピング)
  - [学習の抽出](#112-学習の抽出)
  - [コンテキストウィンドウ対応プロンプト薄化](#114-コンテキストウィンドウ対応プロンプト薄化)
  - [設定可能な CLAUDE.md パス](#115-設定可能な-claudemd-パス)
  - [TDD パイプラインモード](#116-tdd-パイプラインモード)
- [v1.37.0 の機能](#v1370-の機能)
  - [スパイクコマンド](#117-スパイクコマンド)
  - [スケッチコマンド](#118-スケッチコマンド)
  - [エージェントサイズ予算強制](#119-エージェントサイズ予算強制)
  - [共有ボイラープレート抽出](#120-共有ボイラープレート抽出)
  - [ナレッジグラフ統合](#121-ナレッジグラフ統合)
- [v1.40.0 の機能](#v1400-の機能)
  - [スキルサーフェス統合](#122-スキルサーフェス統合)
  - [ネームスペースメタスキル（2 段階ルーティング）](#123-ネームスペースメタスキル2-段階ルーティング)
  - [コンテキストウィンドウ使用率ガード](#124-コンテキストウィンドウ使用率ガード)
  - [フェーズライフサイクルステータス行リードサイド](#125-フェーズライフサイクルステータス行リードサイド)
- [v1.41.0 の機能](#v1410-の機能)
  - [フェーズタイプごとのモデル選択](#126-フェーズタイプごとのモデル選択)
  - [失敗ティアエスカレーション付き動的ルーティング](#127-失敗ティアエスカレーション付き動的ルーティング)
  - [アップデートバナーオプトイン](#128-アップデートバナーオプトイン)
  - [issue-driven-orchestration ガイド](#129-issue-driven-orchestration-ガイド)
  - [グラファイファイコミットベースの古さ検出](#130-グラファイファイコミットベースの古さ検出)
- [v1.42.1 の機能](#v1421-の機能)
  - [パッケージ正当性ゲート](#132-パッケージ正当性ゲート)
  - [スキルサーフェス予算](#133-スキルサーフェス予算)
  - [インストーラーマイグレーション](#134-インストーラーマイグレーション)
  - [カスタムシップ PR ボディセクション](#135-カスタムシップ-pr-ボディセクション)
  - [レビューデフォルトレビュアー](#136-レビューデフォルトレビュアー)
  - [ファロー構造レビュープリパス](#137-ファロー構造レビュープリパス)
  - [フェーズ終了時の人間検証モード](#138-フェーズ終了時の人間検証モード)
  - [クォータとレート制限の失敗分類](#139-クォータとレート制限の失敗分類)
  - [ステータス行コンテキスト位置](#140-ステータス行コンテキスト位置)
  - [マイルストーンタグ作成トグル](#141-マイルストーンタグ作成トグル)
  - [構造化 JSON エラーモード](#142-構造化-json-エラーモード)

---

## コア機能

### 1. プロジェクト初期化

**コマンド:** `/msd-new-project [--auto @file.md]`

**目的:** ユーザーのアイデアを、リサーチ、スコープ化された要件、フェーズ分けされたロードマップを持つ完全に構造化されたプロジェクトに変換します。

**要件:**
- REQ-INIT-01: システムはプロジェクトスコープが完全に理解されるまで適応的な質問を実施しなければならない
- REQ-INIT-02: システムはドメインエコシステムを調査するために並列リサーチエージェントを起動しなければならない
- REQ-INIT-03: システムは要件を v1（必須）、v2（将来）、スコープ外のカテゴリに分類しなければならない
- REQ-INIT-04: システムは要件トレーサビリティ付きのフェーズ分けされたロードマップを生成しなければならない
- REQ-INIT-05: システムは続行前にロードマップのユーザー承認を要求しなければならない
- REQ-INIT-06: `.planning/PROJECT.md` が既に存在する場合、システムは再初期化を防止しなければならない
- REQ-INIT-07: システムは `--auto @file.md` フラグをサポートし、インタラクティブな質問をスキップしてドキュメントから情報を抽出しなければならない

**生成物:**
| 成果物 | 説明 |
|--------|------|
| `PROJECT.md` | プロジェクトビジョン、制約、技術的決定、発展ルール |
| `REQUIREMENTS.md` | 一意の ID（REQ-XX）付きのスコープ化された要件 |
| `ROADMAP.md` | ステータス追跡と要件マッピング付きのフェーズ分割 |
| `STATE.md` | ポジション、決定事項、メトリクスを含む初期プロジェクト状態 |
| `config.json` | ワークフロー設定 |
| `research/SUMMARY.md` | 統合されたドメインリサーチ |
| `research/STACK.md` | 技術スタック調査 |
| `research/FEATURES.md` | 機能実装パターン |
| `research/ARCHITECTURE.md` | アーキテクチャパターンとトレードオフ |
| `research/PITFALLS.md` | よくある失敗パターンと対策 |

**プロセス:**
1. **質問** — 「ドリーム抽出」の哲学に基づく適応的な質問（要件収集ではなく）
2. **リサーチ** — 4つの並列リサーチャーエージェントがスタック、機能、アーキテクチャ、落とし穴を調査
3. **統合** — リサーチシンセサイザーが調査結果を SUMMARY.md に統合
4. **要件** — ユーザーの回答とリサーチから要件を抽出し、スコープ別に分類
5. **ロードマップ** — 要件にマッピングされたフェーズ分割、粒度設定によりフェーズ数を制御

**機能要件:**
- 質問は検出されたプロジェクトタイプ（Web アプリ、CLI、モバイル、API など）に応じて適応する
- リサーチエージェントは最新のエコシステム情報を取得するための Web 検索機能を持つ
- 粒度設定によりフェーズ数を制御: `coarse`（3-5）、`standard`（5-8）、`fine`（8-12）
- `--auto` モードではインタラクティブな質問なしで提供されたドキュメントからすべての情報を抽出
- 既存のコードベースコンテキスト（`/msd-map-codebase` から取得）がある場合は読み込む

---

### 2. フェーズディスカッション

**コマンド:** `/msd-discuss-phase [N] [--auto] [--batch]`

**目的:** リサーチとプランニング開始前に、ユーザーの実装に関する要望や決定事項を収集します。AI が推測する原因となるグレーゾーンを排除します。

**要件:**
- REQ-DISC-01: システムはフェーズのスコープを分析し、決定が必要な領域（グレーゾーン）を特定しなければならない
- REQ-DISC-02: システムはグレーゾーンをタイプ別に分類しなければならない（ビジュアル、API、コンテンツ、構成など）
- REQ-DISC-03: システムは過去の CONTEXT.md ファイルで既に回答済みの質問のみを除外しなければならない
- REQ-DISC-04: システムは決定事項を `{phase}-CONTEXT.md` に正規参照付きで永続化しなければならない
- REQ-DISC-05: システムは推奨デフォルトを自動選択する `--auto` フラグをサポートしなければならない
- REQ-DISC-06: システムはグループ化された質問取り込みのための `--batch` フラグをサポートしなければならない
- REQ-DISC-07: システムはグレーゾーンを特定する前に関連ソースファイルをスカウトしなければならない（コード認識型ディスカッション）
- REQ-DISC-08: USER-PROFILE.md が非技術的なオーナーを示す場合（learning_style: guided、frustration_triggers にジャーゴン、または高レベルの説明深度）、システムはグレーエリアの言語を製品アウトカム用語に適応しなければならない
- REQ-DISC-09: REQ-DISC-08 が適用される場合、advisor_research の根拠段落は平易な言語で書き直されなければならない — 同じ決定、翻訳されたフレーミング

**生成物:** `{padded_phase}-CONTEXT.md` — リサーチとプランニングに反映されるユーザーの要望

**グレーゾーンカテゴリ:**
| カテゴリ | 決定事項の例 |
|----------|-------------|
| ビジュアル機能 | レイアウト、密度、インタラクション、空状態 |
| API/CLI | レスポンス形式、フラグ、エラーハンドリング、詳細度 |
| コンテンツシステム | 構造、トーン、深さ、フロー |
| 構成 | グルーピング基準、命名、重複、例外 |

---

### 3. UI デザインコントラクト

**コマンド:** `/msd-ui-phase [N]`

**目的:** プランニング前にデザインの決定事項を確定し、フェーズ内のすべてのコンポーネントが一貫したビジュアル基準を共有できるようにします。

**要件:**
- REQ-UI-01: システムは既存のデザインシステムの状態を検出しなければならない（shadcn の components.json、Tailwind 設定、トークン）
- REQ-UI-02: システムは未回答のデザインコントラクトの質問のみを行わなければならない
- REQ-UI-03: システムは7つの次元（コピーライティング、ビジュアル、カラー、タイポグラフィ、スペーシング、レジストリセーフティ、インベントリプロビナンス）に対してバリデーションしなければならない
- REQ-UI-04: バリデーションが BLOCKED を返した場合、システムはリビジョンループに入らなければならない（最大2回の反復）
- REQ-UI-05: `components.json` のない React/Next.js/Vite プロジェクトに対して、システムは shadcn の初期化を提案しなければならない
- REQ-UI-06: システムはサードパーティの shadcn レジストリに対してレジストリセーフティゲートを適用しなければならない

**生成物:** `{padded_phase}-UI-SPEC.md` — エグゼキューターが参照するデザインコントラクト

**7つのバリデーション次元:**
1. **コピーライティング** — CTA ラベル、空状態、エラーメッセージ
2. **ビジュアル** — フォーカルポイント、視覚的階層構造、アイコンのアクセシビリティ
3. **カラー** — アクセントカラーの使用規律、60/30/10 準拠
4. **タイポグラフィ** — フォントサイズ/ウェイトの制約遵守
5. **スペーシング** — グリッド配置、トークンの一貫性
6. **レジストリセーフティ** — サードパーティコンポーネントの検査要件
7. **インベントリプロビナンス** — コンポーネントインベントリがインストール済みのデザインシステムから列挙されたものであり、記憶に頼っていないこと

**shadcn 連携:**
- React/Next.js/Vite プロジェクトで `components.json` が欠落していることを検出
- ユーザーを `ui.shadcn.com/create` のプリセット設定にガイド
- プリセット文字列はフェーズ間で再現可能なプランニング成果物になる
- セーフティゲートにより、サードパーティコンポーネント使用前に `npx shadcn view` と `npx shadcn diff` が必要

---

### 4. フェーズプランニング

**コマンド:** `/msd-plan-phase [N] [--auto] [--skip-research] [--skip-verify]`

**目的:** 実装ドメインをリサーチし、検証済みのアトミックな実行プランを作成します。

**要件:**
- REQ-PLAN-01: システムは実装アプローチを調査するフェーズリサーチャーを起動しなければならない
- REQ-PLAN-02: システムはそれぞれ2〜3タスクのプランを作成しなければならず、各タスクは1つのコンテキストウィンドウに収まるサイズとする
- REQ-PLAN-03: システムはプランを XML で構造化しなければならない。`<task>` 要素には `name`、`files`、`action`、`verify`、`done` フィールドを含む
- REQ-PLAN-04: システムはすべてのプランに `read_first` と `acceptance_criteria` セクションを含めなければならない
- REQ-PLAN-05: `--skip-verify` が設定されていない限り、システムはプランチェッカー検証ループ（最大3回の反復）を実行しなければならない
- REQ-PLAN-06: システムはリサーチフェーズをバイパスする `--skip-research` フラグをサポートしなければならない
- REQ-PLAN-07: フロントエンドフェーズが検出され UI-SPEC.md が存在しない場合、システムはユーザーに `/msd-ui-phase` の実行を促さなければならない（UI セーフティゲート）
- REQ-PLAN-08: `workflow.nyquist_validation` が有効な場合、システムは Nyquist バリデーションマッピングを含めなければならない
- REQ-PLAN-09: プランニング完了前に、すべてのフェーズ要件が少なくとも1つのプランでカバーされていることをシステムは検証しなければならない（要件カバレッジゲート）

**生成物:**
| 成果物 | 説明 |
|--------|------|
| `{phase}-RESEARCH.md` | エコシステムリサーチの結果 |
| `{phase}-{N}-PLAN.md` | アトミックな実行プラン（各2〜3タスク） |
| `{phase}-VALIDATION.md` | テストカバレッジマッピング（Nyquist レイヤー） |

**プラン構造（XML）:**
```xml
<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT. Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>
```

**プランチェッカー検証（8つの次元）:**
1. 要件カバレッジ — プランがすべてのフェーズ要件に対応しているか
2. タスクのアトミック性 — 各タスクが独立してコミット可能か
3. 依存関係の順序 — タスクが正しい順序で並んでいるか
4. ファイルスコープ — プラン間で過度なファイルの重複がないか
5. 検証コマンド — 各タスクにテスト可能な完了基準があるか
6. コンテキストフィット — タスクが1つのコンテキストウィンドウに収まるか
7. ギャップ検出 — 実装ステップに欠落がないか
8. Nyquist 準拠 — タスクに自動化された検証コマンドがあるか（有効時）

---

### 5. フェーズ実行

**コマンド:** `/msd-execute-phase <N>`

**目的:** ウェーブベースの並列化を使用して、フェーズ内のすべてのプランを実行します。各エグゼキューターにはフレッシュなコンテキストウィンドウが割り当てられます。

**要件:**
- REQ-EXEC-01: システムはプランの依存関係を分析し、実行ウェーブにグループ化しなければならない
- REQ-EXEC-02: システムは各ウェーブ内で独立したプランを並列実行しなければならない
- REQ-EXEC-03: システムは各エグゼキューターにフレッシュなコンテキストウィンドウ（200K トークン）を付与しなければならない
- REQ-EXEC-04: システムはタスクごとにアトミックな git コミットを生成しなければならない
- REQ-EXEC-05: システムは完了した各プランに対して SUMMARY.md を生成しなければならない
- REQ-EXEC-06: システムはフェーズ目標が達成されたかを確認する実行後検証を実行しなければならない
- REQ-EXEC-07: システムは git ブランチ戦略（`none`、`phase`、`milestone`）をサポートしなければならない
- REQ-EXEC-08: タスク検証失敗時、システムはノードリペアオペレーターを呼び出さなければならない（有効時）
- REQ-EXEC-09: システムはクロスフェーズ回帰を検出するため、検証前に過去のフェーズのテストスイートを実行しなければならない

**生成物:**
| 成果物 | 説明 |
|--------|------|
| `{phase}-{N}-SUMMARY.md` | プランごとの実行結果 |
| `{phase}-VERIFICATION.md` | 実行後検証レポート |
| Git コミット | タスクごとのアトミックなコミット |

**ウェーブ実行:**
- 依存関係のないプラン → ウェーブ 1（並列）
- ウェーブ 1 に依存するプラン → ウェーブ 2（並列、ウェーブ 1 完了を待機）
- すべてのプランが完了するまで継続
- ファイル競合がある場合、同一ウェーブ内で順次実行を強制

**エグゼキューターの機能:**
- 完全なタスク指示を含む PLAN.md を読み取り
- PROJECT.md、STATE.md、CONTEXT.md、RESEARCH.md にアクセス可能
- 構造化されたコミットメッセージで各タスクをアトミックにコミット
- 並列実行中のビルドロック競合を回避するため、コミット時に `--no-verify` を使用
- チェックポイントタイプに対応: `auto`、`checkpoint:human-verify`、`checkpoint:decision`、`checkpoint:human-action`
- プランからの逸脱を SUMMARY.md に報告

**並列安全性:**
- **pre-commit フック**: 並列エージェントではスキップ（`--no-verify`）、各ウェーブ後にオーケストレーターが一度実行
- **STATE.md ロック**: ファイルレベルのロックファイルにより、エージェント間の同時書き込みによるデータ破損を防止

---

### 6. 作業検証

**コマンド:** `/msd-verify-work [N]`

**目的:** ユーザー受け入れテスト — 各成果物のテストをユーザーに順に案内し、失敗を自動診断します。

**要件:**
- REQ-VERIFY-01: システムはフェーズからテスト可能な成果物を抽出しなければならない
- REQ-VERIFY-02: システムは成果物をユーザー確認のために1つずつ提示しなければならない
- REQ-VERIFY-03: システムは失敗を自動診断するためにデバッグエージェントを起動しなければならない
- REQ-VERIFY-04: システムは特定された問題に対する修正プランを作成しなければならない
- REQ-VERIFY-05: サーバー/データベース/シード/スタートアップファイルを変更するフェーズに対して、システムはコールドスタートスモークテストを注入しなければならない
- REQ-VERIFY-06: システムは合否結果を含む UAT.md を生成しなければならない

**生成物:** `{phase}-UAT.md` — ユーザー受け入れテスト結果、問題が見つかった場合は修正プランも含む

---

### 6.5. Ship

**コマンド:** `/msd-ship [N] [--draft]`

**目的:** ローカル完了からマージ済み PR への橋渡し。検証通過後、ブランチをプッシュし、プランニング成果物から自動生成された本文で PR を作成します。オプションでレビューをトリガーし、STATE.md で追跡します。

**要件:**
- REQ-SHIP-01: システムはシッピング前にフェーズが検証を通過していることを確認しなければならない
- REQ-SHIP-02: システムは `gh` CLI を使用してブランチをプッシュし PR を作成しなければならない
- REQ-SHIP-03: システムは SUMMARY.md、VERIFICATION.md、REQUIREMENTS.md から PR 本文を自動生成しなければならない
- REQ-SHIP-04: システムは STATE.md をシッピングステータスと PR 番号で更新しなければならない
- REQ-SHIP-05: システムはドラフト PR のための `--draft` フラグをサポートしなければならない
- REQ-SHIP-06: システムは `ship.pr_body_sections` で設定された追記専用プロジェクト PR ボディセクションをサポートしなければならない

**前提条件:** フェーズ検証済み、`gh` CLI がインストール・認証済み、フィーチャーブランチで作業中

**生成物:** リッチな本文を持つ GitHub PR、STATE.md の更新

---

### 7. UI レビュー

**コマンド:** `/msd-ui-review [N]`

**目的:** 実装済みフロントエンドコードに対する遡及的な6本柱のビジュアル監査。任意のプロジェクトでスタンドアロンで動作します。

**要件:**
- REQ-UIREVIEW-01: システムは6つの柱それぞれを1〜4のスケールで評価しなければならない
- REQ-UIREVIEW-02: システムは Playwright CLI を使用して `.planning/ui-reviews/` にスクリーンショットをキャプチャしなければならない
- REQ-UIREVIEW-03: システムはスクリーンショットディレクトリ用の `.gitignore` を作成しなければならない
- REQ-UIREVIEW-04: システムは優先度の高い修正トップ3を特定しなければならない
- REQ-UIREVIEW-05: システムは（UI-SPEC.md なしで）抽象的な品質基準を使用してスタンドアロンで動作しなければならない

**6つの監査柱（1〜4で評価）:**
1. **コピーライティング** — CTA ラベル、空状態、エラー状態
2. **ビジュアル** — フォーカルポイント、視覚的階層構造、アイコンのアクセシビリティ
3. **カラー** — アクセントカラーの使用規律、60/30/10 準拠
4. **タイポグラフィ** — フォントサイズ/ウェイトの制約遵守
5. **スペーシング** — グリッド配置、トークンの一貫性
6. **エクスペリエンスデザイン** — ローディング/エラー/空状態のカバレッジ

**生成物:** `{padded_phase}-UI-REVIEW.md` — スコアと優先度付き修正リスト

---

### 8. マイルストーン管理

**コマンド:** `/msd-audit-milestone`、`/msd-complete-milestone`、`/msd-new-milestone [name]`

**目的:** マイルストーンの完了を検証し、アーカイブし、リリースにタグを付け、次の開発サイクルを開始します。

**要件:**
- REQ-MILE-01: 監査はすべてのマイルストーン要件が満たされていることを検証しなければならない
- REQ-MILE-02: 監査はスタブ、プレースホルダー実装、未テストコードを検出しなければならない
- REQ-MILE-03: 監査はフェーズ間の Nyquist バリデーション準拠をチェックしなければならない
- REQ-MILE-04: 完了時にマイルストーンデータを MILESTONES.md にアーカイブしなければならない
- REQ-MILE-05: 完了時にリリース用の git タグ作成を提案しなければならない
- REQ-MILE-06: 完了時にブランチ戦略に応じてスカッシュマージまたは履歴付きマージを提案しなければならない
- REQ-MILE-07: 完了時に UI レビューのスクリーンショットをクリーンアップしなければならない
- REQ-MILE-08: 新しいマイルストーンは new-project と同じフロー（質問 → リサーチ → 要件 → ロードマップ）に従わなければならない
- REQ-MILE-09: 新しいマイルストーンは既存のワークフロー設定をリセットしてはならない


---

## プランニング機能

### 9. フェーズ管理

**コマンド:** `/msd-phase`、`/msd-phase --insert [N]`、`/msd-phase --remove [N]`

**目的:** 開発中のロードマップの動的な変更。

**要件:**
- REQ-PHASE-01: 追加は現在のロードマップの末尾に新しいフェーズを追加しなければならない
- REQ-PHASE-02: 挿入は既存フェーズ間に小数番号（例: 3.1）を使用しなければならない
- REQ-PHASE-03: 削除は後続のすべてのフェーズを再番号付けしなければならない
- REQ-PHASE-04: 削除は既に実行されたフェーズの削除を防止しなければならない
- REQ-PHASE-05: すべての操作は ROADMAP.md を更新し、フェーズディレクトリを作成/削除しなければならない

---

### 10. Quick モード

**コマンド:** `/msd-quick [--full] [--discuss] [--research]`

**目的:** MSD の保証を維持しながら、より高速なパスでアドホックなタスクを実行します。

**要件:**
- REQ-QUICK-01: システムは自由形式のタスク説明を受け付けなければならない
- REQ-QUICK-02: システムはフルワークフローと同じプランナー＋エグゼキューターエージェントを使用しなければならない
- REQ-QUICK-03: システムはデフォルトでリサーチ、プランチェッカー、検証をスキップしなければならない
- REQ-QUICK-04: `--full` フラグはプランチェック（最大2回の反復）と実行後検証を有効にしなければならない
- REQ-QUICK-05: `--discuss` フラグは軽量なプランニング前ディスカッションを実行しなければならない
- REQ-QUICK-06: `--research` フラグはプランニング前にフォーカスされたリサーチエージェントを起動しなければならない
- REQ-QUICK-07: フラグは組み合わせ可能でなければならない（`--discuss --research --full`）
- REQ-QUICK-08: システムは Quick タスクを `.planning/quick/YYMMDD-xxx-slug/` で追跡しなければならない
- REQ-QUICK-09: システムは Quick タスク実行時にアトミックなコミットを生成しなければならない

---

### 11. 自律モード

**コマンド:** `/msd-autonomous [--from N]`

**目的:** 残りのすべてのフェーズを自律的に実行します — フェーズごとにディスカッション → プラン → 実行を行います。

**要件:**
- REQ-AUTO-01: システムはロードマップの順序で未完了のすべてのフェーズを反復処理しなければならない
- REQ-AUTO-02: システムは各フェーズに対してディスカッション → プラン → 実行を実行しなければならない
- REQ-AUTO-03: システムは明示的なユーザー判断が必要な場面（グレーゾーンの承認、ブロッカー、バリデーション）で一時停止しなければならない
- REQ-AUTO-04: システムは各フェーズ後に ROADMAP.md を再読み込みし、動的に挿入されたフェーズを検出しなければならない
- REQ-AUTO-05: `--from N` フラグは特定のフェーズ番号から開始しなければならない

---

### 12. フリーフォームルーティング

**コマンド:** `/msd-fast`

**目的:** 自由形式のテキストを分析し、適切な MSD コマンドにルーティングします。

**要件:**
- REQ-DO-01: システムは自然言語入力からユーザーの意図を解析しなければならない
- REQ-DO-02: システムは意図を最も適切な MSD コマンドにマッピングしなければならない
- REQ-DO-03: システムは実行前にルーティング結果をユーザーに確認しなければならない
- REQ-DO-04: システムはプロジェクト既存 vs プロジェクト未作成のコンテキストを区別して処理しなければならない

---

### 13. ノートキャプチャ

**コマンド:** `/msd-capture`

**目的:** ワークフローを中断することなくアイデアを記録する、摩擦ゼロのメモ機能。タイムスタンプ付きメモの追加、全メモの一覧表示、または構造化された Todo へのプロモーションが可能です。

**要件:**
- REQ-NOTE-01: システムは1回の Write 呼び出しでタイムスタンプ付きメモファイルを保存しなければならない
- REQ-NOTE-02: システムはプロジェクトスコープとグローバルスコープからすべてのメモを表示する `list` サブコマンドをサポートしなければならない
- REQ-NOTE-03: システムはメモを構造化された Todo に変換する `promote N` サブコマンドをサポートしなければならない
- REQ-NOTE-04: システムはグローバルスコープ操作のための `--global` フラグをサポートしなければならない
- REQ-NOTE-05: システムは Task、AskUserQuestion、Bash を使用してはならない — インラインでのみ実行

---

### 14. 自動進行（Next）

**コマンド:** `/msd-progress --next`

**目的:** 現在のプロジェクト状態を自動検出し、次の論理的なワークフローステップに進めます。どのフェーズ/ステップにいるかを覚えておく必要がなくなります。

**要件:**
- REQ-NEXT-01: システムは STATE.md、ROADMAP.md、フェーズディレクトリを読み取り、現在のポジションを判定しなければならない
- REQ-NEXT-02: システムはディスカッション、プラン、実行、検証のいずれが必要かを検出しなければならない
- REQ-NEXT-03: システムは適切なコマンドを自動的に呼び出さなければならない
- REQ-NEXT-04: プロジェクトが存在しない場合、システムは `/msd-new-project` を提案しなければならない
- REQ-NEXT-05: すべてのフェーズが完了している場合、システムは `/msd-complete-milestone` を提案しなければならない

**状態検出ロジック:**
| 状態 | アクション |
|------|----------|
| `.planning/` ディレクトリなし | `/msd-new-project` を提案 |
| フェーズに CONTEXT.md がない | `/msd-discuss-phase` を実行 |
| フェーズに PLAN.md ファイルがない | `/msd-plan-phase` を実行 |
| プランはあるが SUMMARY.md がない | `/msd-execute-phase` を実行 |
| 実行済みだが VERIFICATION.md がない | `/msd-verify-work` を実行 |
| すべてのフェーズが完了 | `/msd-complete-milestone` を提案 |

---

## 品質保証機能

### 15. Nyquist バリデーション

**目的:** コード記述前に、フェーズ要件に対する自動テストカバレッジをマッピングします。Nyquist サンプリング定理にちなんで命名 — すべての要件に対してフィードバック信号が存在することを保証します。

**要件:**
- REQ-NYQ-01: システムは plan-phase リサーチ中に既存のテストインフラを検出しなければならない
- REQ-NYQ-02: システムは各要件を特定のテストコマンドにマッピングしなければならない
- REQ-NYQ-03: システムはウェーブ 0 タスク（実装前に必要なテストスキャフォールディング）を特定しなければならない
- REQ-NYQ-04: プランチェッカーは Nyquist 準拠を8番目の検証次元として適用しなければならない
- REQ-NYQ-05: システムは `/msd-validate-phase` による遡及的バリデーションをサポートしなければならない
- REQ-NYQ-06: システムは `workflow.nyquist_validation: false` で無効化可能でなければならない

**生成物:** `{phase}-VALIDATION.md` — テストカバレッジコントラクト

**遡及的バリデーション（`/msd-validate-phase [N]`）:**
- 実装をスキャンし、要件をテストにマッピング
- 自動検証がない要件のギャップを特定
- テストを生成するオーディターを起動（最大3回試行）
- 実装コードは決して変更しない — テストファイルと VALIDATION.md のみ
- 実装バグはユーザーが対処すべきエスカレーションとしてフラグ付け

---

### 16. プランチェック

**目的:** プランがフェーズ目標を達成するかを、実行前にゴールバックワード方式で検証します。

**要件:**
- REQ-PLANCK-01: システムは8つの品質次元に対してプランを検証しなければならない
- REQ-PLANCK-02: システムはプランが合格するまで最大3回の反復をループしなければならない
- REQ-PLANCK-03: システムは失敗に対して具体的かつ実行可能なフィードバックを提供しなければならない
- REQ-PLANCK-04: システムは `workflow.plan_check: false` で無効化可能でなければならない

---

### 17. 実行後検証

**目的:** コードベースがフェーズの約束を達成しているかを自動チェックします。

**要件:**
- REQ-POSTVER-01: システムはタスク完了だけでなく、フェーズ目標に対してチェックしなければならない
- REQ-POSTVER-02: システムは合否分析を含む VERIFICATION.md を生成しなければならない
- REQ-POSTVER-03: システムは `/msd-verify-work` が対処すべき問題をログに記録しなければならない
- REQ-POSTVER-04: システムは `workflow.verifier: false` で無効化可能でなければならない

---

### 18. ノードリペア

**目的:** 実行中にタスク検証が失敗した場合の自律的な回復。

**要件:**
- REQ-REPAIR-01: システムは失敗を分析し、RETRY、DECOMPOSE、PRUNE のいずれかの戦略を選択しなければならない
- REQ-REPAIR-02: RETRY は具体的な調整を加えて再試行しなければならない
- REQ-REPAIR-03: DECOMPOSE はタスクをより小さな検証可能なサブステップに分解しなければならない
- REQ-REPAIR-04: PRUNE は達成不可能なタスクを削除し、ユーザーにエスカレーションしなければならない
- REQ-REPAIR-05: システムはリペア予算を尊重しなければならない（デフォルト: タスクあたり2回の試行）
- REQ-REPAIR-06: システムは `workflow.node_repair_budget` と `workflow.node_repair` で設定可能でなければならない

---

### 19. ヘルスバリデーション

**コマンド:** `/msd-health [--repair]`

**目的:** `.planning/` ディレクトリの整合性を検証し、問題を自動修復します。

**要件:**
- REQ-HEALTH-01: システムは必須ファイルの欠落をチェックしなければならない
- REQ-HEALTH-02: システムは設定の一貫性を検証しなければならない
- REQ-HEALTH-03: システムはサマリーのない孤立したプランを検出しなければならない
- REQ-HEALTH-04: システムはフェーズ番号とロードマップの同期をチェックしなければならない
- REQ-HEALTH-05: `--repair` フラグは回復可能な問題を自動修正しなければならない

---

### 20. クロスフェーズ回帰ゲート

**目的:** 実行後に過去のフェーズのテストスイートを実行することで、フェーズ間での回帰の蓄積を防止します。

**要件:**
- REQ-REGR-01: システムはフェーズ実行後に、完了済みの過去のすべてのフェーズのテストスイートを実行しなければならない
- REQ-REGR-02: システムはテスト失敗をクロスフェーズ回帰として報告しなければならない
- REQ-REGR-03: 回帰は実行後検証の前に表面化されなければならない
- REQ-REGR-04: システムはどの過去フェーズのテストが壊れたかを特定しなければならない

**実行タイミング:** `/msd-execute-phase` の検証ステップの前に自動実行されます。

---

### 21. 要件カバレッジゲート

**目的:** プランニング完了前に、すべてのフェーズ要件が少なくとも1つのプランでカバーされていることを保証します。

**要件:**
- REQ-COVGATE-01: システムは ROADMAP.md からフェーズに割り当てられたすべての要件 ID を抽出しなければならない
- REQ-COVGATE-02: システムは各要件が少なくとも1つの PLAN.md に含まれていることを検証しなければならない
- REQ-COVGATE-03: カバーされていない要件はプランニング完了をブロックしなければならない
- REQ-COVGATE-04: システムはどの特定の要件にプランカバレッジがないかを報告しなければならない

**実行タイミング:** `/msd-plan-phase` の末尾、プランチェッカーループの後に自動実行されます。

---

## コンテキストエンジニアリング機能

### 22. コンテキストウィンドウ監視

**目的:** コンテキストが不足し始めた際にユーザーとエージェントの両方にアラートを出し、コンテキストの劣化を防止します。

**要件:**
- REQ-CTX-01: ステータスラインはユーザーにコンテキスト使用率をパーセンテージで表示しなければならない
- REQ-CTX-02: コンテキストモニターは残量 35% 以下で（WARNING）エージェント向け警告を注入しなければならない
- REQ-CTX-03: コンテキストモニターは残量 25% 以下で（CRITICAL）エージェント向け警告を注入しなければならない
- REQ-CTX-04: 警告はデバウンスされなければならない（繰り返し警告間に5回のツール使用）
- REQ-CTX-05: 重大度のエスカレーション（WARNING→CRITICAL）はデバウンスをバイパスしなければならない
- REQ-CTX-06: コンテキストモニターは MSD アクティブ vs 非 MSD アクティブプロジェクトを区別しなければならない
- REQ-CTX-07: 警告はアドバイザリーであり、ユーザーの意向を上書きする命令的なコマンドであってはならない
- REQ-CTX-08: すべてのフックはサイレントに失敗し、ツール実行をブロックしてはならない

**アーキテクチャ:** 2部構成のブリッジシステム:
1. ステータスラインがメトリクスを `/tmp/claude-ctx-{session}.json` に書き込み
2. コンテキストモニターがメトリクスを読み取り、`additionalContext` 警告を注入

---

### 23. セッション管理

**コマンド:** `/msd-pause-work`、`/msd-resume-work`、`/msd-progress`

**目的:** コンテキストリセットやセッション間でのプロジェクトの継続性を維持します。

**要件:**
- REQ-SESSION-01: 一時停止は現在のポジションと次のステップを `continue-here.md` と構造化された `HANDOFF.json` に保存しなければならない
- REQ-SESSION-02: 再開は HANDOFF.json（優先）または状態ファイル（フォールバック）から完全なプロジェクトコンテキストを復元しなければならない
- REQ-SESSION-03: 進捗は現在のポジション、次のアクション、全体の完了状況を表示しなければならない
- REQ-SESSION-04: 進捗はすべての状態ファイル（STATE.md、ROADMAP.md、フェーズディレクトリ）を読み取らなければならない
- REQ-SESSION-05: すべてのセッション操作は `/clear`（コンテキストリセット）後も動作しなければならない
- REQ-SESSION-06: HANDOFF.json にはブロッカー、保留中の人的アクション、進行中のタスク状態を含めなければならない
- REQ-SESSION-07: 再開時にセッション開始直後に人的アクションとブロッカーを即座に表面化しなければならない

---

### 24. セッションレポート

**コマンド:** `/msd-pause-work --report`

**目的:** 実施した作業、達成した成果、推定リソース使用量をキャプチャした、構造化されたセッション後のサマリードキュメントを生成します。

**要件:**
- REQ-REPORT-01: システムは STATE.md、git log、プラン/サマリーファイルからデータを収集しなければならない
- REQ-REPORT-02: システムは行ったコミット、実行したプラン、進行したフェーズを含めなければならない
- REQ-REPORT-03: システムはセッションアクティビティに基づいてトークン使用量とコストを推定しなければならない
- REQ-REPORT-04: システムはアクティブなブロッカーと行った決定事項を含めなければならない
- REQ-REPORT-05: システムは次のステップを推奨しなければならない

**生成物:** `.planning/reports/SESSION_REPORT.md`

**レポートセクション:**
- セッション概要（期間、マイルストーン、フェーズ）
- 実施した作業（コミット、プラン、フェーズ）
- 成果と成果物
- ブロッカーと決定事項
- リソース推定（トークン、コスト）
- 次のステップの推奨

---

### 25. マルチエージェントオーケストレーション

**目的:** 各タスクにフレッシュなコンテキストウィンドウを持つ専門エージェントを調整します。

**要件:**
- REQ-ORCH-01: 各エージェントはフレッシュなコンテキストウィンドウを受け取らなければならない
- REQ-ORCH-02: オーケストレーターは軽量でなければならない — エージェントを起動し、結果を収集し、次にルーティング
- REQ-ORCH-03: コンテキストペイロードには関連するすべてのプロジェクト成果物を含めなければならない
- REQ-ORCH-04: 並列エージェントは真に独立でなければならない（共有可変状態なし）
- REQ-ORCH-05: エージェントの結果はオーケストレーターが処理する前にディスクに書き込まれなければならない
- REQ-ORCH-06: 失敗したエージェントは検出されなければならない（実際の出力 vs 報告された失敗をスポットチェック）

---

### 26. モデルプロファイル

**コマンド:** `/msd-config --profile <quality|balanced|budget|inherit>`

**目的:** 各エージェントが使用する AI モデルを制御し、品質とコストのバランスを取ります。

**要件:**
- REQ-MODEL-01: システムは4つのプロファイルをサポートしなければならない: `quality`、`balanced`、`budget`、`inherit`
- REQ-MODEL-02: 各プロファイルはエージェントごとのモデルティアを定義しなければならない（プロファイルテーブル参照）
- REQ-MODEL-03: エージェントごとのオーバーライドはプロファイルより優先されなければならない
- REQ-MODEL-04: `inherit` プロファイルはランタイムの現在のモデル選択に従わなければならない
- REQ-MODEL-04a: 非 Anthropic プロバイダー（OpenRouter、ローカルモデル）を使用する場合、予期しない API コストを避けるために `inherit` プロファイルを使用しなければならない
- REQ-MODEL-05: プロファイル切り替えはプログラマティックでなければならない（スクリプト、LLM 駆動ではない）
- REQ-MODEL-06: モデル解決はオーケストレーションごとに1回のみ実行し、スポーンごとに実行してはならない

**プロファイル割り当て:**

| エージェント | `quality` | `balanced` | `budget` | `inherit` |
|-------------|-----------|------------|----------|-----------|
| msd-planner | Opus | Opus | Sonnet | Inherit |
| msd-roadmapper | Opus | Sonnet | Sonnet | Inherit |
| msd-executor | Opus | Sonnet | Sonnet | Inherit |
| msd-phase-researcher | Opus | Sonnet | Haiku | Inherit |
| msd-project-researcher | Opus | Sonnet | Haiku | Inherit |
| msd-research-synthesizer | Sonnet | Sonnet | Haiku | Inherit |
| msd-debugger | Opus | Sonnet | Sonnet | Inherit |
| msd-codebase-mapper | Sonnet | Haiku | Haiku | Inherit |
| msd-verifier | Sonnet | Sonnet | Haiku | Inherit |
| msd-plan-checker | Sonnet | Sonnet | Haiku | Inherit |
| msd-integration-checker | Sonnet | Sonnet | Haiku | Inherit |
| msd-nyquist-auditor | Sonnet | Sonnet | Haiku | Inherit |

---

## ブラウンフィールド機能

### 27. コードベースマッピング

**コマンド:** `/msd-map-codebase [area]`

**目的:** 新しいプロジェクトを開始する前、または `/msd-onboard` からのマッピングハンドオフとして既存のコードベースを分析し、MSD が既存の構成を理解できるようにします。

**要件:**
- REQ-MAP-01: システムは各分析領域に対して並列マッパーエージェントを起動しなければならない
- REQ-MAP-02: システムは `.planning/codebase/` に構造化されたドキュメントを生成しなければならない
- REQ-MAP-03: システムは技術スタック、アーキテクチャパターン、コーディング規約、懸念事項を検出しなければならない
- REQ-MAP-04: 後続の `/msd-new-project` はコードベースマッピングを読み込み、追加する内容に焦点を当てた質問を行わなければならない
- REQ-MAP-05: オプションの `[area]` 引数はマッピングを特定の領域にスコープしなければならない

**生成物:**
| ドキュメント | 内容 |
|-------------|------|
| `STACK.md` | 言語、フレームワーク、データベース、インフラストラクチャ |
| `ARCHITECTURE.md` | パターン、レイヤー、データフロー、境界 |
| `CONVENTIONS.md` | 命名、ファイル構成、コードスタイル、テストパターン |
| `CONCERNS.md` | 技術的負債、セキュリティ問題、パフォーマンスボトルネック |
| `STRUCTURE.md` | ディレクトリレイアウトとファイル構成 |
| `TESTING.md` | テストインフラ、カバレッジ、パターン |
| `INTEGRATIONS.md` | 外部サービス、API、サードパーティ依存関係 |

**増分リマップ — `--paths` (#2003):** マッパーはオプションの
`--paths <p1,p2,...>` スコープヒントを受け付けます。指定した場合、ツリー全体をスキャンする代わりに、リストされたリポジトリ相対プレフィックスに探索を制限します。
これはフェーズが実際に変更したサブツリーのみを更新するために、実行後コードベースドリフトゲートが使用するパスウェイです。各生成ドキュメントはその YAML フロントマターに `last_mapped_commit` を持ち、ドリフトを HEAD ではなくマッピング時点と照らし合わせて計測できます。

### 27b. 既存コードベースオンボーディング

**コマンド:** `/msd-onboard [--fast] [--text]`

**目的:** 既存リポジトリの初回セットアップを案内し、brownfield 状態を確認してコードベースマッピング、docs 取り込み、プロジェクト初期化へ安全にハンドオフします。

**要件:**
- REQ-ONBOARD-01: 既存コード、package manifest、計画ドキュメント、部分的な `.planning/`、コードベースマップの不足を検出する。
- REQ-ONBOARD-02: 必要な `.planning/codebase/` マップファイルがない brownfield では `/msd-map-codebase` または `/msd-map-codebase --fast` へハンドオフする。fast マップの readiness は部分的であり、`/msd-new-project` に十分として扱ってはならない。
- REQ-ONBOARD-03: ADR/PRD/SPEC/RFC 候補があり project がない場合、`/msd-new-project` の前に `/msd-ingest-docs` を提示する。
- REQ-ONBOARD-04: `PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md` が揃うまで完了扱いにしない。
- REQ-ONBOARD-05: project setup 後にのみ `.planning/onboarding/SUMMARY.md` を作成または確認する。
- REQ-ONBOARD-06: 対話型メニューがない runtime 向けに、`--text` で番号付きプレーンテキスト gate をサポートする。

**生成物:**
| Artifact | 説明 |
|----------|-------------|
| `.planning/codebase/` | `/msd-map-codebase` handoff が生成するコードベースマップ |
| `.planning/PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md` | `/msd-new-project` または `/msd-ingest-docs` が生成する planning setup |
| `.planning/onboarding/SUMMARY.md` | Onboarding status、artifact index、next-command summary |

### 27a. 実行後コードベースドリフト検出

**導入:** #2003
**トリガー:** すべての `/msd-execute-phase` 終了時に自動実行
**設定:**
- `workflow.drift_threshold`（整数、デフォルト `3`）— ゲートが動作するまでに必要な最小新規構造要素数。
- `workflow.drift_action`（`warn` | `auto-remap`、デフォルト `warn`）—
  警告のみ、または影響を受けたサブツリーにスコープした `--paths` で `msd-codebase-mapper` をスポーン。

**ドリフトとしてカウントされるもの:**
- マッピングされたパス外の新規ディレクトリ
- `(packages|apps)/*/src/index.*` の新規バレルエクスポート
- 新規マイグレーションファイル（supabase/prisma/drizzle/src/migrations/…）
- `routes/` または `api/` 下の新規ルートモジュール

**非ブロッキング保証:** 内部障害（STRUCTURE.md の欠如、git エラー、マッパースポーン失敗）は
1 行をログに記録し、フェーズは継続します。ドリフト検出が検証を失敗させることはありません。

**要件:**
- REQ-DRIFT-01: システムは `git diff --name-status last_mapped_commit..HEAD` から 4 つのドリフトカテゴリを検出しなければならない
- REQ-DRIFT-02: アクションは要素数が `workflow.drift_threshold` 以上の場合のみ発動する
- REQ-DRIFT-03: `warn` アクションはエージェントをスポーンしてはならない
- REQ-DRIFT-04: `auto-remap` アクションはサニタイズされた `--paths` をマッパーに渡さなければならない
- REQ-DRIFT-05: 検出/リマップの失敗は `/msd-execute-phase` に対して非ブロッキングでなければならない
- REQ-DRIFT-06: `last_mapped_commit` は各 `.planning/codebase/*.md` ファイルの YAML フロントマターを通じてラウンドトリップしなければならない

---

## ユーティリティ機能

### 28. デバッグシステム

**コマンド:** `/msd-debug [description]`

**目的:** コンテキストリセットを超えて持続する状態を持つ、体系的なデバッグ。

**要件:**
- REQ-DEBUG-01: システムは `.planning/debug/` にデバッグセッションファイルを作成しなければならない
- REQ-DEBUG-02: システムは仮説、証拠、排除された理論を追跡しなければならない
- REQ-DEBUG-03: システムはコンテキストリセット後もデバッグが継続するよう状態を永続化しなければならない
- REQ-DEBUG-04: システムは解決済みとマークする前に人的検証を要求しなければならない
- REQ-DEBUG-05: 解決済みセッションは `.planning/debug/knowledge-base.md` に追記されなければならない
- REQ-DEBUG-06: ナレッジベースは再調査を防止するために新しいデバッグセッション時に参照されなければならない

**デバッグセッションの状態:** `gathering` → `investigating` → `fixing` → `verifying` → `awaiting_human_verify` → `resolved`

---

### 29. Todo 管理

**コマンド:** `/msd-capture [desc]`、`/msd-capture --list`

**目的:** セッション中にアイデアやタスクをキャプチャし、後で作業できるようにします。

**要件:**
- REQ-TODO-01: システムは現在の会話コンテキストから Todo をキャプチャしなければならない
- REQ-TODO-02: Todo は `.planning/todos/pending/` に保存されなければならない
- REQ-TODO-03: 完了した Todo は `.planning/todos/completed/` に移動されなければならない
- REQ-TODO-04: check-todos は保留中のすべてのアイテムを一覧表示し、作業するアイテムを選択できなければならない

---

### 30. 統計ダッシュボード

**コマンド:** `/msd-stats`

**目的:** プロジェクトメトリクスを表示します — フェーズ、プラン、要件、git 履歴、タイムライン。

**要件:**
- REQ-STATS-01: システムはフェーズ/プランの完了数を表示しなければならない
- REQ-STATS-02: システムは要件カバレッジを表示しなければならない
- REQ-STATS-03: システムは git コミットメトリクスを表示しなければならない
- REQ-STATS-04: システムは複数の出力形式（json、table、bar）をサポートしなければならない

---

### 31. アップデートシステム

**コマンド:** `/msd-update`

**目的:** MSD を最新バージョンに更新し、チェンジログのプレビューを表示します。

**要件:**
- REQ-UPDATE-01: システムは npm 経由で新しいバージョンをチェックしなければならない
- REQ-UPDATE-02: システムは更新前に新しいバージョンのチェンジログを表示しなければならない
- REQ-UPDATE-03: システムはランタイムを認識し、正しいディレクトリを対象としなければならない
- REQ-UPDATE-04: システムはローカルで変更されたファイルを `msd-local-patches/` にバックアップしなければならない
- REQ-UPDATE-05: `/msd-update --reapply` は更新後にローカルの変更を復元しなければならない

---

### 32. 設定管理

**コマンド:** `/msd-settings`

**目的:** ワークフロートグルとモデルプロファイルのインタラクティブな設定。

**要件:**
- REQ-SETTINGS-01: システムは現在の設定をトグルオプション付きで表示しなければならない
- REQ-SETTINGS-02: システムは `.planning/config.json` を更新しなければならない
- REQ-SETTINGS-03: システムはグローバルデフォルト（`~/.msd/defaults.json`）としての保存をサポートしなければならない

**設定可能な項目:**
| 設定 | 型 | デフォルト | 説明 |
|------|-----|----------|------|
| `mode` | enum | `interactive` | `interactive` または `yolo`（自動承認） |
| `granularity` | enum | `standard` | `coarse`、`standard`、または `fine` |
| `model_profile` | enum | `balanced` | `quality`、`balanced`、`budget`、または `inherit` |
| `workflow.research` | boolean | `true` | プランニング前のドメインリサーチ |
| `workflow.plan_check` | boolean | `true` | プラン検証ループ |
| `workflow.verifier` | boolean | `true` | 実行後検証 |
| `workflow.auto_advance` | boolean | `false` | ディスカッション→プラン→実行の自動チェーン |
| `workflow.nyquist_validation` | boolean | `true` | Nyquist テストカバレッジマッピング |
| `workflow.ui_phase` | boolean | `true` | UI デザインコントラクト生成 |
| `workflow.ui_safety_gate` | boolean | `true` | フロントエンドフェーズで ui-phase を促す |
| `workflow.node_repair` | boolean | `true` | 自律的なタスクリペア |
| `workflow.node_repair_budget` | number | `2` | タスクあたりの最大リペア試行回数 |
| `planning.commit_docs` | boolean | `true` | `.planning/` ファイルを git にコミット |
| `planning.search_gitignored` | boolean | `false` | gitignore されたファイルを検索に含める |
| `parallelization.enabled` | boolean | `true` | 独立したプランを同時実行 |
| `git.branching_strategy` | enum | `none` | `none`、`phase`、または `milestone` |

---

### 33. テスト生成

**コマンド:** `/msd-add-tests [N]`

**目的:** 完了したフェーズに対して、UAT 基準と実装に基づいてテストを生成します。

**要件:**
- REQ-TEST-01: システムは完了したフェーズの実装を分析しなければならない
- REQ-TEST-02: システムは UAT 基準と受け入れ基準に基づいてテストを生成しなければならない
- REQ-TEST-03: システムは既存のテストインフラパターンを使用しなければならない

---

## インフラストラクチャ機能

### 34. Git 連携

**目的:** アトミックなコミット、ブランチ戦略、クリーンな履歴管理。

**要件:**
- REQ-GIT-01: 各タスクは独自のアトミックなコミットを持たなければならない
- REQ-GIT-02: コミットメッセージは構造化されたフォーマットに従わなければならない: `type(scope): description`
- REQ-GIT-03: システムは3つのブランチ戦略をサポートしなければならない: `none`、`phase`、`milestone`
- REQ-GIT-04: phase 戦略はフェーズごとに1つのブランチを作成しなければならない
- REQ-GIT-05: milestone 戦略はマイルストーンごとに1つのブランチを作成しなければならない
- REQ-GIT-06: complete-milestone はスカッシュマージ（推奨）または履歴付きマージを提案しなければならない
- REQ-GIT-07: システムは `.planning/` ファイルに対して `commit_docs` 設定を尊重しなければならない
- REQ-GIT-08: システムは `.gitignore` の `.planning/` を自動検出し、コミットをスキップしなければならない

**コミットフォーマット:**
```
type(phase-plan): description

# Examples:
docs(08-02): complete user registration plan
feat(08-02): add email confirmation flow
fix(03-01): correct auth token expiry
```

---

### 35. CLI ツール

**目的:** ワークフローとエージェント向けのプログラマティックユーティリティ。反復的なインライン bash パターンを置き換えます。

**要件:**
- REQ-CLI-01: システムは状態、設定、フェーズ、ロードマップ操作のためのアトミックなコマンドを提供しなければならない
- REQ-CLI-02: システムは各ワークフローのすべてのコンテキストを読み込む複合 `init` コマンドを提供しなければならない
- REQ-CLI-03: システムは機械可読な出力のための `--raw` フラグをサポートしなければならない
- REQ-CLI-04: システムはサンドボックス化されたサブエージェント操作のための `--cwd` フラグをサポートしなければならない
- REQ-CLI-05: すべての操作は Windows でスラッシュパスを使用しなければならない

**コマンドカテゴリ:** State（11サブコマンド）、Phase（5）、Roadmap（3）、Verify（8）、Template（2）、Frontmatter（4）、Scaffold（4）、Init（12）、Validate（2）、Progress、Stats、Todo

---

### 36. マルチランタイムサポート

**目的:** 複数の AI コーディングエージェントランタイムで MSD を実行します。

**要件:**
- REQ-RUNTIME-01: システムは Claude Code、OpenCode、Kilo、Codex、Copilot、Antigravity をサポートしなければならない
- REQ-RUNTIME-02: インストーラーはランタイムごとにコンテンツを変換しなければならない（ツール名、パス、フロントマター）
- REQ-RUNTIME-03: インストーラーはインタラクティブおよび非インタラクティブ（`--claude --global`）モードをサポートしなければならない
- REQ-RUNTIME-04: インストーラーはグローバルとローカルの両方のインストールをサポートしなければならない
- REQ-RUNTIME-05: アンインストールは他の設定に影響を与えることなく、すべての MSD ファイルをクリーンに削除しなければならない
- REQ-RUNTIME-06: インストーラーはプラットフォームの違い（Windows、macOS、Linux、WSL、Docker）を処理しなければならない

**ランタイム変換:**

| 側面 | Claude Code | OpenCode | Kilo | Codex | Copilot | Antigravity |
|------|------------|----------|-------|-------|---------|-------------|
| コマンド | スラッシュコマンド | スラッシュコマンド | スラッシュコマンド | スキル（TOML） | スラッシュコマンド | スキル |
| エージェント形式 | Claude ネイティブ | `mode: subagent` | `mode: subagent` | スキル | ツールマッピング | スキル |
| フックイベント | `PostToolUse` | N/A | N/A | N/A | N/A | N/A |
| 設定 | `settings.json` | `opencode.json(c)` | `kilo.json(c)` | TOML | Instructions | Config |

---

### 37. フックシステム

**目的:** コンテキスト監視、ステータス表示、アップデートチェックのためのランタイムイベントフック。

**要件:**
- REQ-HOOK-01: ステータスラインはモデル、現在のタスク、ディレクトリ、コンテキスト使用量を表示しなければならない
- REQ-HOOK-02: コンテキストモニターは閾値レベルでエージェント向け警告を注入しなければならない
- REQ-HOOK-03: アップデートチェッカーはセッション開始時にバックグラウンドで実行されなければならない
- REQ-HOOK-04: すべてのフックは `CLAUDE_CONFIG_DIR` 環境変数を尊重しなければならない
- REQ-HOOK-05: すべてのフックは3秒の stdin タイムアウトガードを含まなければならない
- REQ-HOOK-06: すべてのフックはエラー時にサイレントに失敗しなければならない
- REQ-HOOK-07: コンテキスト使用量は autocompact バッファ（16.5% リザーブ）に対して正規化されなければならない
- REQ-HOOK-08: アップデートバナーはオプトインであり、アップデートが利用可能でない限りサイレントでなければならない（PR #2795）

**ステータスライン表示:**
```
[⬆ /msd-update │] model │ [current task │] directory [█████░░░░░ 50%]
```

カラーコーディング: 50% 未満は緑、65% 未満は黄、80% 未満はオレンジ、80% 以上はドクロ絵文字付き赤

### 38. 開発者プロファイリング

**コマンド:** `/msd-profile-user [--questionnaire] [--refresh]`

**目的:** Claude Code のセッション履歴を分析し、8つの次元にわたる行動プロファイルを構築します。開発者のスタイルに合わせて Claude のレスポンスをパーソナライズするための成果物を生成します。

**次元:**
1. コミュニケーションスタイル（簡潔 vs 冗長、フォーマル vs カジュアル）
2. 意思決定パターン（迅速 vs 慎重、リスク許容度）
3. デバッグアプローチ（体系的 vs 直感的、ログの好み）
4. UX の好み（デザインセンス、アクセシビリティの認識）
5. ベンダー/テクノロジーの選択（フレームワークの好み、エコシステムへの精通度）
6. フラストレーションのトリガー（ワークフローで摩擦を引き起こすもの）
7. 学習スタイル（ドキュメント vs 例、深さの好み）
8. 説明の深さ（ハイレベル vs 実装詳細）

**生成される成果物:**
- `USER-PROFILE.md` — 証拠引用付きの完全な行動プロファイル
- `CLAUDE.md` プロファイルセクション — Claude Code により自動検出

**フラグ:**
- `--questionnaire` — セッション履歴が利用できない場合のインタラクティブなアンケートフォールバック
- `--refresh` — セッションを再分析してプロファイルを再生成

**パイプラインモジュール:**
- `profile-pipeline.cjs` — セッションスキャン、メッセージ抽出、サンプリング
- `profile-output.cjs` — プロファイルレンダリング、アンケート、成果物生成
- `msd-user-profiler` エージェント — セッションデータからの行動分析

**要件:**
- REQ-PROF-01: セッション分析は少なくとも8つの行動次元をカバーしなければならない
- REQ-PROF-02: プロファイルは実際のセッションメッセージからの証拠を引用しなければならない
- REQ-PROF-03: セッション履歴がない場合、アンケートがフォールバックとして利用可能でなければならない
- REQ-PROF-04: 生成された成果物は Claude Code により検出可能でなければならない（CLAUDE.md 連携）

### 39. 実行ハードニング

**目的:** 実行パイプラインに対する3つの段階的な品質改善。クロスプランの失敗が連鎖する前に検出します。

**コンポーネント:**

**1. プレウェーブ依存関係チェック**（execute-phase）
ウェーブ N+1 を起動する前に、前のウェーブの成果物からのキーリンクが存在し、正しく接続されていることを検証します。クロスプランの依存関係ギャップが下流の失敗に連鎖するのを防ぎます。

**2. クロスプランデータコントラクト — 第9次元**（plan-checker）
データパイプラインを共有するプランが互換性のある変換を持っているかチェックする新しい分析次元。あるプランが別のプランが元の形式で必要とするデータを削除する場合にフラグを立てます。

**3. エクスポートレベルスポットチェック**（verify-phase）
レベル3の配線検証が通過した後、個々のエクスポートが実際に使用されているかスポットチェックします。配線されたファイル内に存在するが呼び出されないデッドストアを検出します。

**要件:**
- REQ-HARD-01: プレウェーブチェックは次のウェーブを起動する前に、すべての前のウェーブの成果物からのキーリンクを検証しなければならない
- REQ-HARD-02: クロスプランコントラクトチェックはプラン間の互換性のないデータ変換を検出しなければならない
- REQ-HARD-03: エクスポートスポットチェックは配線されたファイル内のデッドストアを特定しなければならない

---

### 40. 検証デット追跡

**コマンド:** `/msd-audit-uat`

**目的:** 未解決のテストを持つフェーズを通過した際の UAT/検証項目のサイレントな喪失を防止します。すべての過去フェーズの検証デットを表面化し、項目が忘れられないようにします。

**コンポーネント:**

**1. クロスフェーズヘルスチェック**（progress.md ステップ 1.6）
すべての `/msd-progress` 呼び出しで、現在のマイルストーンのすべてのフェーズの未解決項目（pending、skipped、blocked、human_needed）をスキャンします。アクション可能なリンク付きのノンブロッキング警告セクションを表示します。

**2. `status: partial`**（verify-work.md、UAT.md）
「セッション終了」と「すべてのテスト解決済み」を区別する新しい UAT ステータス。テストがまだ pending、blocked、または理由なく skipped の場合に `status: complete` を防止します。

**3. `result: blocked` と `blocked_by` タグ**（verify-work.md、UAT.md）
外部依存関係（サーバー、物理デバイス、リリースビルド、サードパーティサービス）によりブロックされたテストのための新しいテスト結果タイプ。スキップされたテストとは別にカテゴリ分けされます。

**4. HUMAN-UAT.md の永続化**（execute-phase.md）
検証が `human_needed` を返した場合、項目は `status: partial` の追跡可能な HUMAN-UAT.md ファイルとして永続化されます。クロスフェーズヘルスチェックと監査システムに反映されます。

**5. フェーズ完了警告**（phase.cjs、transition.md）
`phase complete` CLI は JSON 出力に検証デット警告を返します。トランジションワークフローは確認前に未解決項目を表面化します。

**要件:**
- REQ-DEBT-01: システムは `/msd-progress` ですべての過去フェーズの未解決 UAT/検証項目を表面化しなければならない
- REQ-DEBT-02: システムは不完全なテスト（partial）と完了したテスト（complete）を区別しなければならない
- REQ-DEBT-03: システムはブロックされたテストを `blocked_by` タグでカテゴリ分けしなければならない
- REQ-DEBT-04: システムは human_needed の検証項目を追跡可能な UAT ファイルとして永続化しなければならない
- REQ-DEBT-05: システムは検証デットが存在する場合、フェーズ完了とトランジション時に警告（ノンブロッキング）しなければならない
- REQ-DEBT-06: `/msd-audit-uat` はすべてのフェーズをスキャンし、項目をテスト可能性別にカテゴリ分けし、人的テストプランを生成しなければならない

---

## v1.27 の機能

### 41. Fast モード

**コマンド:** `/msd-fast [task description]`

**目的:** サブエージェントの起動や PLAN.md ファイルの生成なしに、些細なタスクをインラインで実行します。プランニングのオーバーヘッドを正当化できないほど小さなタスク向け: タイポ修正、設定変更、小規模なリファクタリング、コミット忘れ、簡単な追加。

**要件:**
- REQ-FAST-01: システムはサブエージェントなしで現在のコンテキストでタスクを直接実行しなければならない
- REQ-FAST-02: システムは変更に対してアトミックな git コミットを生成しなければならない
- REQ-FAST-03: システムは状態の一貫性のためにタスクを `.planning/quick/` で追跡しなければならない
- REQ-FAST-04: リサーチ、マルチステッププランニング、または検証が必要なタスクにシステムを使用してはならない

**`/msd-quick` との使い分け:**
- `/msd-fast` — 2分以内に実行可能な一文のタスク（タイポ修正、設定変更、小規模な追加）
- `/msd-quick` — リサーチ、マルチステッププランニング、または検証が必要なもの

---

### 42. クロス AI ピアレビュー

**コマンド:** `/msd-review --phase N [--claude] [--codex] [--coderabbit] [--opencode] [--qwen] [--cursor] [--agy] [--antigravity] [--ollama] [--lm-studio] [--llama-cpp] [--kimi-code] [--all]`

**目的:** 外部の AI CLI（Claude、Codex、CodeRabbit、OpenCode、Qwen Code、Cursor、Antigravity、Kimi Code）とローカルの OpenAI 互換サーバー（Ollama、LM Studio、llama.cpp）を呼び出して、フェーズプランを独立してレビューします。レビュアーごとのフィードバックを含む構造化された REVIEWS.md を生成します。

**要件:**
- REQ-REVIEW-01: システムはシステム上で利用可能な AI CLI を検出しなければならない
- REQ-REVIEW-02: システムはフェーズプランから構造化されたレビュープロンプトを構築しなければならない
- REQ-REVIEW-03: システムは選択された各 CLI を独立して呼び出さなければならない
- REQ-REVIEW-04: システムはレスポンスを収集して `REVIEWS.md` を生成しなければならない
- REQ-REVIEW-05: レビューは `/msd-plan-phase --reviews` で使用可能でなければならない

**生成物:** `{phase}-REVIEWS.md` — レビュアーごとの構造化されたフィードバック

---

### 43. バックログパーキングロット

**コマンド:** `/msd-capture --backlog <description>`、`/msd-review-backlog`、`/msd-capture --seed <idea>`

**目的:** アクティブなプランニングの準備ができていないアイデアをキャプチャします。バックログ項目は 999.x の番号付けを使用して、アクティブなフェーズシーケンスの外に留まります。シードは、適切なマイルストーンで自動的に表面化するトリガー条件を持つ、将来を見据えたアイデアです。

**要件:**
- REQ-BACKLOG-01: バックログ項目はアクティブなフェーズシーケンスの外に留まるために 999.x の番号付けを使用しなければならない
- REQ-BACKLOG-02: `/msd-discuss-phase` と `/msd-plan-phase` が動作するよう、フェーズディレクトリは即座に作成されなければならない
- REQ-BACKLOG-03: `/msd-review-backlog` は項目ごとにプロモート、維持、削除のアクションをサポートしなければならない
- REQ-BACKLOG-04: プロモートされた項目はアクティブなマイルストーンシーケンスに再番号付けされなければならない
- REQ-SEED-01: シードは完全な WHY と表面化条件の WHEN をキャプチャしなければならない
- REQ-SEED-02: `/msd-new-milestone` はシードをスキャンして一致するものを提示しなければならない

**生成物:**
| 成果物 | 説明 |
|--------|------|
| `.planning/phases/999.x-slug/` | バックログ項目ディレクトリ |
| `.planning/seeds/SEED-NNN-slug.md` | トリガー条件付きシード |

---

### 44. 永続コンテキストスレッド

**コマンド:** `/msd-thread [name | description]`

**目的:** 複数セッションにまたがるが特定のフェーズには属さない作業のための、軽量なクロスセッションナレッジストア。`/msd-pause-work` よりも軽量 — フェーズ状態やプランコンテキストは不要です。

**要件:**
- REQ-THREAD-01: システムは作成、一覧、再開モードをサポートしなければならない
- REQ-THREAD-02: スレッドは `.planning/threads/` にマークダウンファイルとして保存されなければならない
- REQ-THREAD-03: スレッドファイルには Goal、Context、References、Next Steps セクションを含めなければならない
- REQ-THREAD-04: スレッドの再開時にその完全なコンテキストを現在のセッションに読み込まなければならない
- REQ-THREAD-05: スレッドはフェーズまたはバックログ項目にプロモート可能でなければならない

**生成物:** `.planning/threads/{slug}.md` — 永続コンテキストスレッド

---

### 45. PR ブランチフィルタリング

**コマンド:** `/msd-pr-branch [target branch]`

**目的:** `.planning/` のコミットを除外して、プルリクエストに適したクリーンなブランチを作成します。レビュアーにはコード変更のみが表示され、MSD プランニング成果物は表示されません。

**要件:**
- REQ-PRBRANCH-01: システムは `.planning/` ファイルのみを変更するコミットを特定しなければならない
- REQ-PRBRANCH-02: システムはプランニングコミットを除外した新しいブランチを作成しなければならない
- REQ-PRBRANCH-03: コード変更はコミットされた通りに正確に保持されなければならない

---

### 46. セキュリティハードニング

**目的:** MSD のプランニング成果物に対する多層防御セキュリティ。MSD は LLM のシステムプロンプトとなるマークダウンファイルを生成するため、これらのファイルに流入するユーザー制御テキストは間接的なプロンプトインジェクションの潜在的なベクターです。

**コンポーネント:**

**1. 集中型セキュリティモジュール**（`security.cjs`）
- パストラバーサル防止 — ファイルパスがプロジェクトディレクトリ内に解決されることを検証
- プロンプトインジェクション検出 — ユーザー提供テキスト内の既知のインジェクションパターンをスキャン
- 安全な JSON パース — 状態破損前に不正な入力をキャッチ
- フィールド名バリデーション — 設定フィールド名を通じたインジェクションを防止
- シェル引数バリデーション — シェル補間前にユーザーテキストをサニタイズ

**2. プロンプトインジェクションガードフック**（`msd-prompt-guard.js`）
`.planning/` を対象とする Write/Edit 呼び出しをインジェクションパターンでスキャンする PreToolUse フック。アドバイザリーのみ — 正当な操作をブロックせず、検出を認識のためにログ記録します。

**3. ワークフローガードフック**（`msd-workflow-guard.js`）
Claude が MSD ワークフローコンテキスト外でファイル編集を試行した際に検出する PreToolUse フック。直接編集の代わりに `/msd-quick` や `/msd-fast` の使用をアドバイスします。`hooks.workflow_guard`（デフォルト: false）で設定可能です。

**4. CI 対応インジェクションスキャナー**（`prompt-injection-scan.security.test.cjs`）
すべてのエージェント、ワークフロー、コマンドファイルに埋め込まれたインジェクションベクターをスキャンするテストスイート。

**要件:**
- REQ-SEC-01: すべてのユーザー提供ファイルパスはプロジェクトディレクトリに対して検証されなければならない
- REQ-SEC-02: プロンプトインジェクションパターンはテキストがプランニング成果物に入る前に検出されなければならない
- REQ-SEC-03: セキュリティフックはアドバイザリーのみでなければならない（正当な操作を決してブロックしない）
- REQ-SEC-04: ユーザー入力の JSON パースは不正なデータをグレースフルにキャッチしなければならない
- REQ-SEC-05: macOS の `/var` → `/private/var` シンボリックリンク解決がパスバリデーションで処理されなければならない

---

### 47. マルチリポワークスペースサポート

**目的:** モノレポおよびマルチリポ構成のための自動検出とプロジェクトルート解決。`.planning/` がリポジトリ境界を超えて解決する必要がある場合のワークスペースをサポートします。

**要件:**
- REQ-MULTIREPO-01: システムはマルチリポワークスペース設定を自動検出しなければならない
- REQ-MULTIREPO-02: システムはリポジトリ境界を超えてプロジェクトルートを解決しなければならない
- REQ-MULTIREPO-03: エグゼキューターはマルチリポモードでリポジトリごとのコミットハッシュを記録しなければならない

---

### 48. ディスカッション監査証跡

**目的:** `/msd-discuss-phase` 中に `DISCUSSION-LOG.md` を自動生成し、ディスカッション中の決定事項の完全な監査証跡を残します。

**要件:**
- REQ-DISCLOG-01: システムは discuss-phase 中に DISCUSSION-LOG.md を自動生成しなければならない
- REQ-DISCLOG-02: ログは質問内容、提示されたオプション、行われた決定をキャプチャしなければならない
- REQ-DISCLOG-03: 決定 ID は discuss-phase から plan-phase へのトレーサビリティを可能にしなければならない

---

## v1.28 の機能

### 49. フォレンジクス

**コマンド:** `/msd-forensics [description]`

**目的:** 失敗または停滞した MSD ワークフローのポストモーテム調査。

**要件:**
- REQ-FORENSICS-01: システムは git 履歴の異常（停滞ループ、長いギャップ、繰り返しコミット）を分析しなければならない
- REQ-FORENSICS-02: システムは成果物の整合性をチェックしなければならない（完了したフェーズに期待されるファイルがあるか）
- REQ-FORENSICS-03: システムは `.planning/forensics/` に保存されるマークダウンレポートを生成しなければならない
- REQ-FORENSICS-04: システムは調査結果で GitHub Issue の作成を提案しなければならない
- REQ-FORENSICS-05: システムはプロジェクトファイルを変更してはならない（読み取り専用の調査）

**生成物:**
| 成果物 | 説明 |
|--------|------|
| `.planning/forensics/report-{timestamp}.md` | ポストモーテム調査レポート |

**プロセス:**
1. **スキャン** — git 履歴の異常を分析: 停滞ループ、コミット間の長いギャップ、繰り返しの同一コミット
2. **整合性チェック** — 完了したフェーズに期待される成果物ファイルがあるか検証
3. **レポート** — 調査結果を含むマークダウンレポートを生成し、`.planning/forensics/` に保存
4. **Issue** — チームの可視性のため、調査結果で GitHub Issue の作成を提案

---

### 50. マイルストーンサマリー

**コマンド:** `/msd-milestone-summary [version]`

**目的:** チームオンボーディングのためにマイルストーン成果物から包括的なプロジェクトサマリーを生成します。

**要件:**
- REQ-SUMMARY-01: システムはフェーズプラン、サマリー、検証結果を集約しなければならない
- REQ-SUMMARY-02: システムは現在のマイルストーンとアーカイブ済みマイルストーンの両方で動作しなければならない
- REQ-SUMMARY-03: システムは単一のナビゲート可能なドキュメントを生成しなければならない

**生成物:**
| 成果物 | 説明 |
|--------|------|
| `MILESTONE-SUMMARY.md` | マイルストーン成果物の包括的でナビゲート可能なサマリー |

**プロセス:**
1. **収集** — 対象マイルストーンからフェーズプラン、サマリー、検証結果を集約
2. **統合** — 成果物をクロスリファレンス付きの単一のナビゲート可能なドキュメントに結合
3. **出力** — チームオンボーディングとステークホルダーレビューに適した `MILESTONE-SUMMARY.md` を作成

---

### 51. ワークストリームネームスペーシング

**コマンド:** `/msd-workstreams`

**目的:** 異なるマイルストーン領域での同時作業のための並列ワークストリーム。

**要件:**
- REQ-WS-01: システムはワークストリーム状態を個別の `.planning/workstreams/{name}/` ディレクトリに分離しなければならない
- REQ-WS-02: システムはワークストリーム名を検証しなければならない（英数字とハイフンのみ、パストラバーサルなし）
- REQ-WS-03: システムは list、create、switch、status、progress、complete、resume サブコマンドをサポートしなければならない

**生成物:**
| 成果物 | 説明 |
|--------|------|
| `.planning/workstreams/{name}/` | 分離されたワークストリームディレクトリ構造 |

**プロセス:**
1. **作成** — 分離された `.planning/workstreams/{name}/` ディレクトリで名前付きワークストリームを初期化
2. **切り替え** — 後続の MSD コマンドのためにアクティブなワークストリームコンテキストを変更
3. **管理** — ワークストリームの一覧表示、ステータス確認、進捗追跡、完了、または再開

---

### 52. マネージャーダッシュボード

**コマンド:** `/msd-manager`

**目的:** 1つのターミナルから複数のフェーズを管理するためのインタラクティブなコマンドセンター。

**要件:**
- REQ-MGR-01: システムはすべてのフェーズの概要をステータス付きで表示しなければならない
- REQ-MGR-02: システムは現在のマイルストーンスコープにフィルタリングしなければならない
- REQ-MGR-03: システムはフェーズの依存関係と競合を表示しなければならない

**生成物:** インタラクティブなターミナル出力

**プロセス:**
1. **スキャン** — 現在のマイルストーンのすべてのフェーズとそのステータスを読み込み
2. **表示** — フェーズの依存関係、競合、進捗を示す概要をレンダリング
3. **操作** — 個々のフェーズのナビゲーション、検査、操作のコマンドを受け付け

---

### 53. Assumptions ディスカッションモード

**コマンド:** `/msd-discuss-phase`（`workflow.discuss_mode: 'assumptions'` 設定時）

**目的:** インタビュー形式の質問をコードベースファーストの仮定分析に置き換えます。

**要件:**
- REQ-ASSUME-01: システムは質問の前にコードベースを分析して構造化された仮定を生成しなければならない
- REQ-ASSUME-02: システムは仮定を信頼度レベル（Confident/Likely/Unclear）で分類しなければならない
- REQ-ASSUME-03: システムはデフォルトのディスカスモードと同一の CONTEXT.md フォーマットを生成しなければならない
- REQ-ASSUME-04: システムは信頼度ベースのスキップゲートをサポートしなければならない（すべて HIGH の場合は質問なし）

**生成物:**
| 成果物 | 説明 |
|--------|------|
| `{phase}-CONTEXT.md` | デフォルトのディスカスモードと同じフォーマット |

**プロセス:**
1. **分析** — コードベースをスキャンして実装アプローチに関する構造化された仮定を生成
2. **分類** — 仮定を信頼度レベル別にカテゴリ分け: Confident、Likely、Unclear
3. **ゲート** — すべての仮定が HIGH 信頼度の場合、質問を完全にスキップ
4. **確認** — 不明確な仮定をターゲット化された質問としてユーザーに提示
5. **出力** — デフォルトのディスカスモードと同一フォーマットで `{phase}-CONTEXT.md` を生成

---

### 54. UI フェーズ自動検出

**対象:** `/msd-new-project` および `/msd-progress`

**目的:** UI 重視のプロジェクトを自動検出し、`/msd-ui-phase` の推奨を表面化します。

**要件:**
- REQ-UI-DETECT-01: システムはプロジェクト説明の UI シグナル（キーワード、フレームワーク参照）を検出しなければならない
- REQ-UI-DETECT-02: システムは該当する場合に ROADMAP.md のフェーズに `ui_hint` をアノテーションしなければならない
- REQ-UI-DETECT-03: システムは UI 重視フェーズのネクストステップに `/msd-ui-phase` を提案しなければならない
- REQ-UI-DETECT-04: システムは `/msd-ui-phase` を必須にしてはならない

**プロセス:**
1. **検出** — プロジェクト説明と技術スタックの UI シグナル（キーワード、フレームワーク参照）をスキャン
2. **アノテーション** — ROADMAP.md の該当フェーズに `ui_hint` マーカーを追加
3. **表面化** — UI 重視フェーズのネクストステップに `/msd-ui-phase` の推奨を含める

---

### 55. マルチランタイムインストーラー選択

**対象:** `npx @golem15/msd-core`

**目的:** 1回のインタラクティブなインストールセッションで複数のランタイムを選択します。

**要件:**
- REQ-MULTI-RT-01: インタラクティブプロンプトはマルチセレクトをサポートしなければならない（例: Claude Code + Antigravity）
- REQ-MULTI-RT-02: CLI フラグは非インタラクティブインストールで引き続き動作しなければならない

**プロセス:**
1. **検出** — システム上で利用可能な AI CLI ランタイムを特定
2. **プロンプト** — ランタイム選択のためのマルチセレクトインターフェースを提示
3. **インストール** — 1回のセッションで選択されたすべてのランタイムに対して MSD を設定

---

## v1.29 の機能

### 56. Windsurf ランタイムサポート

**対象:** `npx @golem15/msd-core`

**目的:** Windsurf AI IDE のサポートを追加します。

**要件:**
- REQ-WINDSURF-01: インストーラーは `--windsurf` フラグによる Windsurf インストールをサポートしなければならない
- REQ-WINDSURF-02: Windsurf ルール形式に対応したプロンプトファイルを生成しなければならない

**プロセス:**
1. **検出** — Windsurf のインストール状態を確認
2. **変換** — MSD プロンプトを Windsurf ルール形式に変換
3. **インストール** — Windsurf 設定ディレクトリに MSD を設定

---

### 57. 国際化ドキュメント

**対象:** `docs/` ディレクトリ

**目的:** MSD ドキュメントをポルトガル語、韓国語、日本語で提供します。

**要件:**
- REQ-I18N-01: ドキュメントはポルトガル語（pt）、韓国語（ko）、日本語（ja）で提供されなければならない
- REQ-I18N-02: 翻訳は英語のソースドキュメントと同期を維持しなければならない

**プロセス:**
1. **翻訳** — コアドキュメントを対象言語に変換
2. **公開** — 翻訳されたドキュメントを英語版と並んでアクセス可能にする

---

## v1.31 の機能

### 59. スキーマドリフト検出

**コマンド:** `/msd-execute-phase` 実行時に自動

**目的:** ORM スキーマファイルが対応するマイグレーションまたは push コマンドなしに変更された場合を検出し、誤検知の検証を防止します。

**要件:**
- REQ-SCHEMA-01: システムは ORM スキーマファイル（Prisma、Drizzle、Payload、Sanity、Mongoose）の変更を検出しなければならない
- REQ-SCHEMA-02: スキーマ変更が検出された場合、対応するマイグレーション/push コマンドの存在を確認しなければならない
- REQ-SCHEMA-03: 二層防御を実装しなければならない: 計画時注入と実行時ゲート
- REQ-SCHEMA-04: 検出をオーバーライドする `MSD_SKIP_SCHEMA_CHECK` 環境変数をサポートしなければならない
- REQ-SCHEMA-05: マイグレーションなしのスキーマ変更時に誤検知の検証を防止しなければならない

**プロセス:**
1. **検出** — 計画実行中の ORM スキーマファイルの変更を監視
2. **確認** — 計画に対応するマイグレーション/push コマンドが含まれていることを確認
3. **ゲート** — マイグレーションなしのスキーマドリフトが検出された場合、実行をブロック（実行時ゲート）
4. **注入** — 計画生成中にマイグレーションリマインダーを追加（計画時注入）

**設定:** `MSD_SKIP_SCHEMA_CHECK` 環境変数で検出をバイパス。

---

### 60. セキュリティエンフォースメント

**コマンド:** `/msd-secure-phase <N>`

**目的:** フェーズ実装に対する脅威モデルアンカードのセキュリティ検証。

**要件:**
- REQ-SEC-01: システムは脅威モデルアンカードの検証（ブラインドスキャンではない）を実行しなければならない
- REQ-SEC-02: 設定可能な OWASP ASVS 検証レベル（1-3）をサポートしなければならない
- REQ-SEC-03: 設定可能な重大度しきい値に基づいてフェーズ進行をブロックしなければならない
- REQ-SEC-04: 分析のために `msd-security-auditor` エージェントを起動しなければならない

**生成物:**
| 成果物 | 説明 |
|--------|------|
| セキュリティ監査レポート | 重大度分類付きの脅威モデルアンカードの発見事項 |

**プロセス:**
1. **モデル** — フェーズ実装コンテキストから脅威モデルを構築
2. **監査** — `msd-security-auditor` を起動して脅威モデルに対して検証
3. **ゲート** — 発見事項が `security_block_on` 重大度以上の場合、フェーズ進行をブロック

**設定:**
| 設定 | 型 | デフォルト | 説明 |
|------|-----|-----------|------|
| `security_enforcement` | boolean | `true` | 脅威モデルセキュリティ検証を有効化 |
| `security_asvs_level` | number (1-3) | `1` | OWASP ASVS 検証レベル |
| `security_block_on` | string | `"high"` | フェーズ進行をブロックする最小重大度 |

---

### 61. ドキュメント生成

**コマンド:** `/msd-docs-update`

**目的:** 正確性チェック付きのプロジェクトドキュメントを生成・検証します。

**要件:**
- REQ-DOCS-01: システムはドキュメント生成のために `msd-doc-writer` エージェントを起動しなければならない
- REQ-DOCS-02: システムは正確性チェックのために `msd-doc-verifier` エージェントを起動しなければならない
- REQ-DOCS-03: システムは生成されたドキュメントを実際の実装に対して検証しなければならない

**生成物:**
| 成果物 | 説明 |
|--------|------|
| 更新されたプロジェクトドキュメント | 生成および検証されたドキュメントファイル |

**プロセス:**
1. **生成** — `msd-doc-writer` を起動して実装からドキュメントを作成・更新
2. **検証** — `msd-doc-verifier` を起動してコードベースに対するドキュメント正確性をチェック
3. **出力** — 正確性アノテーション付きの検証済みドキュメントを生成

---

### 62. ディスカスチェーンモード

**フラグ:** `/msd-discuss-phase <N> --chain`

**目的:** 手動のコマンド連続実行を削減するため、discuss、plan、execute フェーズを1つのフローで自動チェーンします。

**要件:**
- REQ-CHAIN-01: `--chain` フラグが提供された場合、システムは discuss → plan → execute を自動チェーンしなければならない
- REQ-CHAIN-02: チェーンされたフェーズ間のすべてのゲート設定を尊重しなければならない
- REQ-CHAIN-03: いずれかのフェーズが失敗した場合、チェーンを停止しなければならない

**プロセス:**
1. **ディスカス** — コンテキスト収集のためにディスカスフェーズを実行
2. **プラン** — 収集されたコンテキストでプランフェーズを自動的に呼び出し
3. **エクセキュート** — 生成されたプランでエクセキュートフェーズを自動的に呼び出し

---

### 63. 単一フェーズ自律モード

**フラグ:** `/msd-autonomous --only N`

**目的:** 全残りフェーズではなく、1つのフェーズだけを自律的に実行します。

**要件:**
- REQ-ONLY-01: `--only N` が提供された場合、システムは指定されたフェーズ番号のみを実行しなければならない
- REQ-ONLY-02: フル自律モードと同じ discuss → plan → execute フローに従わなければならない
- REQ-ONLY-03: 指定されたフェーズが完了した後に停止しなければならない

**プロセス:**
1. **選択** — `--only N` 引数からターゲットフェーズを特定
2. **実行** — そのフェーズに対してフル自律フロー（discuss → plan → execute）を実行
3. **停止** — 次のフェーズに進まず、フェーズ完了後に停止

---

### 64. スコープ削減検出

**対象:** `/msd-plan-phase`

**目的:** 三層防御により、計画生成中のサイレントな要件削除を防止します。

**要件:**
- REQ-SCOPE-01: プランナーは明示的な正当化なしにスコープを削減することを禁止されなければならない
- REQ-SCOPE-02: プランチェッカーは要件ディメンションカバレッジを検証しなければならない
- REQ-SCOPE-03: オーケストレーターは削除された要件を回復して再注入しなければならない
- REQ-SCOPE-04: 三層防御を実装しなければならない: プランナー禁止、チェッカーディメンション、オーケストレーター回復

**プロセス:**
1. **禁止** — プランナー指示でスコープ削減を明示的に禁止
2. **チェック** — プランチェッカーがすべてのフェーズ要件が計画でカバーされていることを確認
3. **回復** — オーケストレーターが削除された要件を検出してプランニングループに再注入

---

### 65. クレーム出所タグ付け

**対象:** `/msd-plan-phase --research-phase`

**目的:** リサーチのクレームにソースエビデンスのタグを付け、仮定を別途記録します。

**要件:**
- REQ-PROVENANCE-01: リサーチャーはクレームにソースエビデンス参照をマークしなければならない
- REQ-PROVENANCE-02: 仮定はソース付きクレームとは別に記録されなければならない
- REQ-PROVENANCE-03: システムはエビデンス付き事実と推論された仮定を区別しなければならない

**プロセス:**
1. **リサーチ** — リサーチャーがコードベースとドメインソースから情報を収集
2. **タグ** — 各クレームにソース（ファイルパス、ドキュメント、API レスポンス）をアノテーション
3. **分離** — 直接的なエビデンスのない仮定を別セクションに記録

---

### 66. Worktree トグル

**設定:** `workflow.use_worktrees: false`

**目的:** 順次実行を好むユーザーのために git worktree 分離を無効化します。

**要件:**
- REQ-WORKTREE-01: システムは分離戦略を決定する際に `workflow.use_worktrees` 設定を尊重しなければならない
- REQ-WORKTREE-02: 後方互換性のためにデフォルトは `true`（worktree 有効）でなければならない
- REQ-WORKTREE-03: worktree が無効な場合、順次実行にフォールバックしなければならない

**設定:**
| 設定 | 型 | デフォルト | 説明 |
|------|-----|-----------|------|
| `workflow.use_worktrees` | boolean | `true` | `false` の場合、git worktree 分離を無効化 |

---

### 67. プロジェクトコードプレフィックス

**設定:** `project_code: "ABC"`

**目的:** マルチプロジェクトの曖昧さ解消のためにフェーズディレクトリ名にプロジェクトコードをプレフィックスします。

**要件:**
- REQ-PREFIX-01: 設定された場合、システムはフェーズディレクトリにプロジェクトコードをプレフィックスしなければならない（例: `ABC-01-setup/`）
- REQ-PREFIX-02: `project_code` が設定されていない場合、標準命名を使用しなければならない
- REQ-PREFIX-03: すべてのフェーズ操作で一貫してプレフィックスを適用しなければならない

**設定:**
| 設定 | 型 | デフォルト | 説明 |
|------|-----|-----------|------|
| `project_code` | string | (なし) | フェーズディレクトリ名のプレフィックス |

---

### 68. Claude Code スキルマイグレーション

**対象:** `npx @golem15/msd-core`

**目的:** MSD コマンドを Claude Code 2.1.88+ のスキル形式に後方互換性を維持してマイグレーションします。

**要件:**
- REQ-SKILLS-01: インストーラーは Claude Code 2.1.88+ 向けに `skills/msd-*/SKILL.md` を書き込まなければならない
- REQ-SKILLS-02: インストーラーはレガシー `commands/msd/` ディレクトリを自動クリーンしなければならない
- REQ-SKILLS-03: レガシー `commands/msd/` パスを通じて古い Claude Code バージョンとの後方互換性を維持しなければならない

**プロセス:**
1. **検出** — Claude Code のバージョンをチェックしてスキルサポートを判定
2. **マイグレーション** — 各 MSD コマンドに対して `skills/msd-*/SKILL.md` ファイルを書き込み
3. **クリーン** — スキルがインストールされた場合、レガシー `commands/msd/` ディレクトリを削除
4. **フォールバック** — 古い Claude Code バージョンのためにレガシー `commands/msd/` パス互換性を維持

---

## v1.32 の機能

### 69. STATE.md 整合性ゲート

**コマンド:** `state validate`、`state sync [--verify]`、`state planned-phase --phase N --plans N`

**目的:** STATE.md と実際のファイルシステム間のドリフトを検出・修復し、古い状態からのカスケードエラーを防止します。

**要件:**
- REQ-STATE-01: `state validate` は STATE.md フィールドとファイルシステムの実態間のドリフトを検出しなければならない
- REQ-STATE-02: `state sync` はディスク上の実際のプロジェクト状態から STATE.md を再構築しなければならない
- REQ-STATE-03: `state sync --verify` は書き込みなしで提案される変更を表示するドライランを実行しなければならない
- REQ-STATE-04: `state planned-phase` はプランフェーズ完了後の状態遷移を記録しなければならない（Planned/Ready to execute）

**生成物:**
| 成果物 | 説明 |
|--------|------|
| 更新された `STATE.md` | ファイルシステムの実態を反映した修正済み状態 |

**プロセス:**
1. **検証** — STATE.md フィールドをファイルシステム（フェーズディレクトリ、計画ファイル、サマリー）と比較
2. **同期** — ドリフトが検出された場合、ディスクから STATE.md を再構築
3. **遷移** — エクセキュートフェーズの準備状態として計画数付きのポストプランニング状態を記録

---

### 70. 自律モード `--to N` フラグ

**フラグ:** `/msd-autonomous --to N`

**目的:** 特定のフェーズ完了後に自律実行を停止し、部分的な自律実行を可能にします。

**要件:**
- REQ-TO-01: システムは指定されたフェーズ番号の完了後に実行を停止しなければならない
- REQ-TO-02: N までの各フェーズに対して同じ discuss → plan → execute フローに従わなければならない
- REQ-TO-03: `--to N` は境界付き自律範囲のために `--from N` と組み合わせ可能でなければならない

**プロセス:**
1. **境界設定** — `--to N` 引数から上限フェーズを設定
2. **実行** — フェーズ N まで（含む）の各フェーズに対して自律フローを実行
3. **停止** — フェーズ N の完了後に停止

---

### 71. リサーチゲート

**対象:** `/msd-plan-phase`

**目的:** RESEARCH.md に未解決のオープンクエスチョンがある場合にプランニングをブロックし、不完全な情報に基づく計画を防止します。

**要件:**
- REQ-RESGATE-01: プランニング開始前に RESEARCH.md の未解決オープンクエスチョンをスキャンしなければならない
- REQ-RESGATE-02: オープンクエスチョンが存在する場合、プランフェーズのエントリをブロックしなければならない
- REQ-RESGATE-03: 具体的な未解決クエスチョンをユーザーに表示しなければならない

**プロセス:**
1. **スキャン** — RESEARCH.md のオープンクエスチョンセクションで未解決項目をチェック
2. **ゲート** — 未解決クエスチョンが見つかった場合、プランニングをブロック
3. **表示** — 解決が必要な具体的なオープンクエスチョンを表示

---

### 72. ベリファイヤーマイルストーンスコープフィルタリング

**対象:** `/msd-execute-phase`（ベリファイヤーステップ）

**目的:** 真のギャップと後続フェーズに延期された項目を区別し、検証の偽陰性を削減します。

**要件:**
- REQ-VSCOPE-01: ベリファイヤーはギャップが後続マイルストーンフェーズで対処されるかチェックしなければならない
- REQ-VSCOPE-02: 後続フェーズで対処されるギャップは「ギャップ」ではなく「延期」とマークされなければならない
- REQ-VSCOPE-03: 真のギャップ（将来のフェーズでもカバーされない）のみが失敗として報告されなければならない

**プロセス:**
1. **検証** — 標準的なゴール逆行検証を実行
2. **フィルター** — 検出されたギャップを後続マイルストーンフェーズとクロスリファレンス
3. **分類** — 延期された項目を真のギャップとは別にマーク

---

### 73. Read-Before-Edit ガードフック

**対象:** フック（`PreToolUse`）

**目的:** ファイルが編集前に読み込まれることを確認し、非 Claude ランタイムでの無限リトライループを防止します。

**要件:**
- REQ-RBE-01: フックはセッションで以前に読み込まれていないファイルを対象とする Edit/Write ツールコールを検出しなければならない
- REQ-RBE-02: フックはまずファイルを読み込むよう勧告しなければならない（勧告的、非ブロッキング）
- REQ-RBE-03: フックは組み込みの read-before-edit 強制のないランタイムで一般的な無限リトライループを防止しなければならない

---

### 74. コンテキスト削減

**対象:** プロンプトアセンブリ・パイプライン

**目的:** Markdown 切り詰めとキャッシュフレンドリーなプロンプト順序により、コンテキストプロンプトサイズを削減します。

**要件:**
- REQ-CTXRED-01: システムはコンテキスト予算内に収まるよう、大きすぎる Markdown アーティファクトを切り詰めなければならない
- REQ-CTXRED-02: キャッシュフレンドリーなアセンブリのためにプロンプトを順序付けなければならない（安定したプレフィックスを先頭に）
- REQ-CTXRED-03: 削減は必須情報（見出し、要件、タスク構造）を保持しなければならない
- REQ-CTXRED-04: スキルの `description:` フィールドは ≤ 100 文字でなければならない；`npm run lint:descriptions` で強制（`scripts/lint-descriptions.cjs` と `tests/skill-frontmatter-contract.test.cjs` 参照）

**プロセス:**
1. **計測** — ワークフローの総プロンプトサイズを計算
2. **切り詰め** — 大きすぎるアーティファクトに Markdown 対応の切り詰めを適用
3. **順序付け** — KV キャッシュ再利用の最適化のためにプロンプトセクションを配置

---

### 75. ディスカスフェーズ `--power` フラグ

**フラグ:** `/msd-discuss-phase --power`

**目的:** ディスカスフェーズのファイルベースの一括質問回答で、準備済み回答ファイルからのバッチ入力を可能にします。

**要件:**
- REQ-POWER-01: システムはディスカッション質問への事前記述済み回答を含むファイルを受け付けなければならない
- REQ-POWER-02: システムは回答を対応するグレーエリア質問にマッピングしなければならない
- REQ-POWER-03: システムはインタラクティブなディスカスフェーズと同一の CONTEXT.md を生成しなければならない

---

### 76. デバッグ `--diagnose` フラグ

**フラグ:** `/msd-debug --diagnose`

**目的:** 修正を試みず調査のみを行う診断専用モード。

**要件:**
- REQ-DIAG-01: システムは完全なデバッグ調査（仮説、エビデンス、根本原因）を実行しなければならない
- REQ-DIAG-02: システムはコード変更を一切行ってはならない
- REQ-DIAG-03: システムは発見事項と推奨修正を含む診断レポートを生成しなければならない

---

### 77. フェーズ依存関係分析

**コマンド:** `/msd-manager --analyze-deps`

**目的:** フェーズ依存関係を検出し、`/msd-manager` 実行前に ROADMAP.md への `Depends on` エントリを提案します。

**要件:**
- REQ-DEP-01: システムはフェーズ間のファイルオーバーラップを検出しなければならない
- REQ-DEP-02: システムはセマンティック依存関係（API/スキーマのプロデューサーとコンシューマー）を検出しなければならない
- REQ-DEP-03: システムはデータフロー依存関係（出力プロデューサーとリーダー）を検出しなければならない
- REQ-DEP-04: システムは依存関係エントリを提案し、書き込み前にユーザー確認を要求しなければならない

**生成物:** 依存関係提案テーブル；オプションで ROADMAP.md の `Depends on` フィールドを更新

---

### 78. アンチパターン重大度レベル

**対象:** `/msd-resume-work`

**目的:** 重大度ベースのアンチパターン強制によるリジューム時の必須理解チェック。

**要件:**
- REQ-ANTI-01: システムはアンチパターンを重大度レベルで分類しなければならない
- REQ-ANTI-02: システムはセッションリジューム時に必須の理解チェックを強制しなければならない
- REQ-ANTI-03: より高い重大度のアンチパターンは承認されるまでワークフロー進行をブロックしなければならない

---

### 79. メソドロジーアーティファクトタイプ

**対象:** プランニングアーティファクト

**目的:** メソドロジードキュメントの消費メカニズムを定義し、エージェントによって正しく消費されることを確保します。

**要件:**
- REQ-METHOD-01: システムはメソドロジーを独自のアーティファクトタイプとしてサポートしなければならない
- REQ-METHOD-02: メソドロジーアーティファクトはエージェント向けの定義された消費メカニズムを持たなければならない

---

### 80. プランナー到達可能性チェック

**対象:** `/msd-plan-phase`

**目的:** 実行にコミットする前にプランステップが達成可能であることを検証します。

**要件:**
- REQ-REACH-01: プランナーは各プランステップが到達可能なファイルと API を参照していることを検証しなければならない
- REQ-REACH-02: 到達不可能なステップは実行中ではなくプランニング中にフラグ付けされなければならない

---

### 81. Playwright-MCP UI 検証

**対象:** `/msd-verify-work`（オプション）

**目的:** ベリファイフェーズ中の Playwright-MCP を使用した自動ビジュアル検証。

**要件:**
- REQ-PLAY-01: システムはベリファイフェーズ中のオプションの Playwright-MCP ビジュアル検証をサポートしなければならない
- REQ-PLAY-02: ビジュアル検証はオプトインであり、必須であってはならない
- REQ-PLAY-03: システムは UI-SPEC.md の期待値に対してビジュアル状態をキャプチャ・比較しなければならない

---

### 82. Pause-Work 拡張

**対象:** `/msd-pause-work`

**目的:** よりリッチなハンドオフデータで非フェーズコンテキストをサポートし、pause-work の適用範囲を拡大します。

**要件:**
- REQ-PAUSE-01: システムは非フェーズコンテキスト（クイックタスク、デバッグセッション、スレッド）でのポーズをサポートしなければならない
- REQ-PAUSE-02: ハンドオフデータは現在の作業タイプに適切なよりリッチなコンテキストを含まなければならない

---

### 83. レスポンス言語設定

**設定:** `response_language`

**目的:** 非英語ユーザーのためのクロスフェーズ言語一貫性。

**要件:**
- REQ-LANG-01: システムはすべてのフェーズとエージェントで `response_language` 設定を尊重しなければならない
- REQ-LANG-02: 設定はすべてのスポーンされたエージェントに伝播し、一貫した言語出力を確保しなければならない

**設定:**
| 設定 | 型 | デフォルト | 説明 |
|------|-----|-----------|------|
| `response_language` | string | (なし) | エージェントレスポンスの言語コード（例: `"pt"`、`"ko"`、`"ja"`） |

---

### 84. 手動アップデート手順

**対象:** `docs/manual-update.md`

**目的:** `npx` が利用不可または npm パブリッシュに障害が発生している環境のための手動アップデートパスを文書化します。

**要件:**
- REQ-MANUAL-01: ドキュメントはステップバイステップの手動アップデート手順を記述しなければならない
- REQ-MANUAL-02: 手順は npm アクセスなしで機能しなければならない

---

### 85. 新規ランタイムサポート (Trae, Cline, Augment Code)

**対象:** `npx @golem15/msd-core`

**目的:** Trae IDE、Cline、Augment Code ランタイムへの MSD インストールを拡張します。

**要件:**
- REQ-TRAE-01: インストーラーは Trae IDE インストールのための `--trae` フラグをサポートしなければならない
- REQ-CLINE-01: インストーラーは `.clinerules` 設定を通じて Cline をサポートしなければならない
- REQ-AUGMENT-01: インストーラーはスキル変換と設定管理で Augment Code をサポートしなければならない

---

### 86. 自律モード `--interactive` フラグ

**フラグ:** `/msd-autonomous --interactive`

**目的:** ディスカスフェーズをインタラクティブ（ユーザーが質問に回答）に保ちながら、プランと実行をバックグラウンドエージェントとしてディスパッチするリーンコンテキスト自律モード。

**要件:**
- REQ-INTERACT-01: `--interactive` はインタラクティブな質問（自動回答なし）で discuss-phase をメインコンテキスト内でインラインに実行しなければならない
- REQ-INTERACT-02: `--interactive` はコンテキスト分離のために plan-phase と execute-phase をバックグラウンドエージェントとしてディスパッチしなければならない
- REQ-INTERACT-03: `--interactive` はパイプラインの並列性を有効にしなければならない — フェーズ N のビルド中にフェーズ N+1 をディスカス
- REQ-INTERACT-04: メインコンテキストはディスカッション会話のみを蓄積しなければならない（リーンコンテキスト）

**プロセス:**
1. **インラインディスカス** — メインコンテキストでユーザーインタラクションとともに discuss-phase を実行
2. **ディスパッチ** — プランと実行を新鮮なコンテキストウィンドウを持つバックグラウンドエージェントに送信
3. **パイプライン** — バックグラウンドエージェントがフェーズ N をビルドする間、フェーズ N+1 のディスカッションを開始

---

### 87. コミットドキュメントガードフック

**フック:** `msd-commit-docs.js`

**目的:** `commit_docs` 設定を強制する PreToolUse フックで、`planning.commit_docs` が `false` の場合に `.planning/` ファイルがコミットされることを防止します。

**要件:**
- REQ-COMMITDOCS-01: フックは `.planning/` ファイルをステージングする git commit コマンドを傍受しなければならない
- REQ-COMMITDOCS-02: フックは `commit_docs` が `false` の場合に `.planning/` ファイルを含むコミットをブロックしなければならない
- REQ-COMMITDOCS-03: フックは勧告的でなければならない — `commit_docs` が `true` または不在の場合はブロックしない

---

### 88. コミュニティフックオプトイン

**フック:** `msd-validate-commit.sh`、`msd-session-state.sh`、`msd-phase-boundary.sh`

**目的:** MSD プロジェクト向けのオプションの git およびセッションフックで、設定の `hooks.community: true` の背後にゲートされています。

**要件:**
- REQ-COMMUNITY-01: すべてのコミュニティフックは `.planning/config.json` の `hooks.community` が `true` でない限りノーオペレーションでなければならない
- REQ-COMMUNITY-02: `msd-validate-commit.sh` は git コミットメッセージに Conventional Commits 形式を強制しなければならない
- REQ-COMMUNITY-03: `msd-session-state.sh` はセッション状態遷移をトラッキングしなければならない
- REQ-COMMUNITY-04: `msd-phase-boundary.sh` はフェーズ境界チェックを強制しなければならない

**設定:**
| 設定 | 型 | デフォルト | 説明 |
|------|-----|-----------|------|
| `hooks.community` | boolean | `false` | コミット検証、セッション状態、フェーズ境界のオプションコミュニティフックを有効化 |

---

## v1.34.0 機能

  - [グローバル学習ストア](#89-グローバル学習ストア)
  - [クエリ可能コードベースインテリジェンス](#90-クエリ可能コードベースインテリジェンス)
  - [実行コンテキストプロファイル](#91-実行コンテキストプロファイル)
  - [ゲート分類法](#92-ゲート分類法)
  - [コードレビューパイプライン](#93-コードレビューパイプライン)
  - [ソクラテス的探索](#94-ソクラテス的探索)
  - [セーフアンドゥ](#95-セーフアンドゥ)
  - [プランインポート](#96-プランインポート)
  - [高速コードベーススキャン](#97-高速コードベーススキャン)
  - [自律監査から修正](#98-自律監査から修正)
  - [改善されたプロンプトインジェクションスキャナー](#99-改善されたプロンプトインジェクションスキャナー)
  - [プランフェーズのストール検出](#100-プランフェーズのストール検出)
  - [/msd-progress --next のハードストップ安全ゲート](#101-msd-progress---next-のハードストップ安全ゲート)
  - [アダプティブモデルプリセット](#102-アダプティブモデルプリセット)
  - [ポストマージハンク検証](#103-ポストマージハンク検証)

---

### 89. グローバル学習ストア

**コマンド:** フェーズ完了時に自動トリガー；プランナーが消費
**設定:** `features.global_learnings`

**目的:** セッションを超えてプロジェクトをまたいだ学習をグローバルストアに永続化し、プランナーエージェントがプロジェクト履歴全体のパターンから学習できるようにします（現在のセッションだけでなく）。

**要件:**
- REQ-LEARN-01: 学習はフェーズ完了時に `.planning/` からグローバルストアに自動コピーされなければならない
- REQ-LEARN-02: プランナーエージェントはスポーン時にインジェクションを通じて関連する学習を受け取らなければならない
- REQ-LEARN-03: インジェクションはコンテキストの肥大化を避けるために `learnings.max_inject` でキャップされなければならない
- REQ-LEARN-04: 機能は `features.global_learnings: true` によるオプトインでなければならない

**設定:**
| 設定 | 型 | デフォルト | 説明 |
|------|-----|-----------|------|
| `features.global_learnings` | boolean | `false` | クロスプロジェクト学習パイプラインを有効化 |
| `learnings.max_inject` | number | (システムデフォルト) | プランナーにインジェクトされる最大学習エントリ数 |

---

### 90. クエリ可能コードベースインテリジェンス

**コマンド:** `/msd-map-codebase --query [<term>|status|diff|refresh]`
**設定:** `intel.enabled`

**目的:** コードベース構造、API サーフェス、依存関係グラフ、ファイルロール、アーキテクチャ決定のクエリ可能な JSON インデックスを `.planning/intel/` に維持します。コードベース全体を読み込まずにターゲット検索を可能にします。

**要件:**
- REQ-INTEL-01: インテルファイルは `.planning/intel/` に JSON として保存されなければならない
- REQ-INTEL-02: `query` モードはすべてのインテルファイルをまたいで用語を検索し、ファイルごとに結果をグループ化しなければならない
- REQ-INTEL-03: `status` モードは鮮度を報告しなければならない（FRESH/STALE、古さの閾値：24 時間）
- REQ-INTEL-04: `diff` モードは現在のインテル状態を最後のスナップショットと比較しなければならない
- REQ-INTEL-05: `refresh` モードはすべてのファイルを再構築するために intel-updater エージェントをスポーンしなければならない
- REQ-INTEL-06: 機能は `intel.enabled: true` によるオプトインでなければならない

**生成されるインテルファイル:**
| ファイル | 内容 |
|---------|------|
| `stack.json` | テクノロジースタックと依存関係 |
| `api-map.json` | エクスポートされた関数と API サーフェス |
| `dependency-graph.json` | モジュール間の依存関係 |
| `file-roles.json` | 各ソースファイルのロール分類 |
| `arch-decisions.json` | 検出されたアーキテクチャ決定 |

---

### 91. 実行コンテキストプロファイル

**設定:** `context_profile`

**目的:** 特定の作業タイプに合わせて調整されたあらかじめ設定された実行コンテキスト（モード、モデル、ワークフロー設定）を選択します（個別設定を手動で調整せずに）。

**要件:**
- REQ-CTX-01: `dev` プロファイルは反復開発に最適化しなければならない（balanced モデル、plan_check 有効）
- REQ-CTX-02: `research` プロファイルはリサーチ重視の作業に最適化しなければならない（高いモデルティア、research 有効）
- REQ-CTX-03: `review` プロファイルはコードレビュー作業に最適化しなければならない（verifier と code_review 有効）

**利用可能なプロファイル:** `dev`、`research`、`review`

**設定:**
| 設定 | 型 | デフォルト | 説明 |
|------|-----|-----------|------|
| `context_profile` | string | (なし) | 実行コンテキストプリセット：`dev`、`research`、または `review` |

---

### 92. ゲート分類法

**参照:** `msd-core/references/gates.md`
**エージェント:** plan-checker、verifier

**目的:** すべてのワークフロー決定ポイントを構造化する 4 つの正規ゲートタイプを定義し、plan-checker と verifier エージェントが一貫したゲートロジックを適用できるようにします。

**ゲートタイプ:**
| タイプ | 説明 |
|--------|------|
| **確認** | ユーザーが進行前に承認（例：ロードマップレビュー） |
| **品質** | 自動化された品質チェックが通過しなければならない（例：プラン検証ループ） |
| **安全** | 検出されたリスクまたはポリシー違反でのハードストップ |
| **遷移** | フェーズまたはマイルストーン境界の確認 |

**要件:**
- REQ-GATES-01: plan-checker は各チェックポイントを 4 つのゲートタイプのいずれかに分類しなければならない
- REQ-GATES-02: verifier はゲートタイプに適したゲートロジックを適用しなければならない
- REQ-GATES-03: ハードストップ安全ゲートは `--auto` フラグでバイパスされてはならない

---

### 93. コードレビューパイプライン

**コマンド:** `/msd-code-review`、`/msd-code-review --fix`

**目的:** フェーズ中に変更されたソースファイルの構造化レビューで、各修正をアトミックにコミットする別の自動修正パスを伴います。

**要件:**
- REQ-REVIEW-01: `msd-code-review` は SUMMARY.md と git diff フォールバックを使用してフェーズにファイルをスコープしなければならない
- REQ-REVIEW-02: レビューは 3 つの深さレベルをサポートしなければならない：`quick`、`standard`、`deep`
- REQ-REVIEW-03: 所見は重大度で分類されなければならない：Critical、Warning、Info
- REQ-REVIEW-04: `msd-code-review --fix` は REVIEW.md を読み込み、デフォルトで Critical および Warning の所見を修正しなければならない
- REQ-REVIEW-05: 各修正は説明的なメッセージとともにアトミックにコミットされなければならない
- REQ-REVIEW-06: `--auto` フラグは修正と再レビューの反復ループを有効にしなければならない（最大 3 回）
- REQ-REVIEW-07: 機能は `workflow.code_review` 設定フラグでゲートされなければならない

**設定:**
| 設定 | 型 | デフォルト | 説明 |
|------|-----|-----------|------|
| `workflow.code_review` | boolean | `true` | コードレビューコマンドを有効化 |
| `workflow.code_review_depth` | string | `standard` | デフォルトのレビュー深度：`quick`、`standard`、または `deep` |
| `workflow.code_review_depth_overrides` | array | `[]` | 変更ファイル集合に対するパスプレフィックス一致で特定ディレクトリのレビュー深度をエスカレートする、順序付き `{ paths, depth }` ルール（#2554）。詳細は下記参照。 |

**パススコープのコードレビュー深度オーバーライド**

`workflow.code_review_depth_overrides` は、レビュー対象の変更ファイル集合に対して、セグメント単位のディレクトリパスプレフィックスでルールを照合します。`src/auth` は `src/auth/token.ts` および `src/auth` 自体に一致しますが、`src/authfoo/x.ts` や `docs/src/auth/x.ts` には一致しません。照合は git と同様に大文字小文字を区別します。

エスカレーションは**レビュー全体単位であり、ファイル単位ではありません**：深度はレビューエージェントに渡される単一のスカラー値であり、ファイルごとの設定ではないため、ルールセット全体で一致した最も強いティアがレビュー内のすべてのファイルに適用されます — 機密ファイルが無関係なファイルと同じレビューに含まれたために浅くレビューされることはありません。

v1 は**ディレクトリプレフィックス一致のみをサポートし、glob 構文はサポートしません**：このプロジェクトには glob エンジン（`minimatch`、`picomatch`、`fast-glob`）が存在せず、この機能のために追加もされていません。`*` や `?` を含むパス（例：`src/auth/**`）は、静かな近似一致ではなく設定エラーとして扱われます。

---

### 94. ソクラテス的探索

**コマンド:** `/msd-explore [topic]`

**目的:** プランにコミットする前にソクラテス的な問いかけを通じてアイデアの探索を開発者にガイドします。出力を適切な MSD アーティファクトにルーティングします：ノート、TODO、シード、リサーチクエスチョン、要件更新、または新規フェーズ。

**要件:**
- REQ-EXPLORE-01: 探索はソクラテス的な問いかけを使用しなければならない — ソリューションを提案する前に質問する
- REQ-EXPLORE-02: セッションは出力を適切な MSD アーティファクトにルーティングするオプションを提供しなければならない
- REQ-EXPLORE-03: オプションのトピック引数は最初の質問をプライムしなければならない
- REQ-EXPLORE-04: 探索はオプションで技術的実現可能性のためにリサーチエージェントをスポーンしなければならない

---

### 95. セーフアンドゥ

**コマンド:** `/msd-undo --last N | --phase NN | --plan NN-MM`

**目的:** フェーズマニフェストと git log を使用して MSD フェーズまたはプランのコミットを安全にロールバックし、依存関係チェックとリバート適用前のハード確認ゲートを伴います。

**要件:**
- REQ-UNDO-01: `--phase` モードはマニフェストと git log フォールバックを通じてフェーズのすべてのコミットを識別しなければならない
- REQ-UNDO-02: `--plan` モードは特定のプランのすべてのコミットを識別しなければならない
- REQ-UNDO-03: `--last N` モードはインタラクティブな選択のために最近の MSD コミットを表示しなければならない
- REQ-UNDO-04: システムはリバート前に依存するフェーズ/プランをチェックしなければならない
- REQ-UNDO-05: git revert が実行される前に確認ゲートを表示しなければならない

---

### 96. プランインポート

**コマンド:** `/msd-import --from <filepath>`

**目的:** 外部プランファイルを `PROJECT.md` 決定との競合検出とともに MSD プランニングシステムに取り込み、有効な MSD PLAN.md に変換して plan-checker で検証します。

**要件:**
- REQ-IMPORT-01: インポーターは外部プランと既存の PROJECT.md 決定間の競合を検出しなければならない
- REQ-IMPORT-02: 検出されたすべての競合は書き込み前にユーザーに提示されなければならない
- REQ-IMPORT-03: インポートされたプランは有効な MSD PLAN.md 形式として書き込まれなければならない
- REQ-IMPORT-04: 書き込まれたプランは `msd-plan-checker` 検証を通過しなければならない

---

### 97. 高速コードベーススキャン

**コマンド:** `/msd-map-codebase --fast [--focus tech|arch|quality|concerns]`

**目的:** 1 つまたは 2 つの組み合わせたフォーカスエリアに対して単一のマッパーエージェントをスポーンする `/msd-map-codebase` の軽量な代替手段で、4 つの並列エージェントのオーバーヘッドなしに `.planning/codebase/` にターゲット出力を生成します。

**要件:**
- REQ-SCAN-01: スキャンは（4 つの並列エージェントではなく）正確に 1 つのマッパーエージェントをスポーンしなければならない
- REQ-SCAN-02: フォーカスエリアは次のいずれかでなければならない：`tech`、`arch`、`quality`、`concerns`、または組み合わせた `tech+arch` 省略形（デフォルト：`tech+arch`）；組み合わせフォーカスは 1 回のパスで両エリアをカバーする単一エージェントとして実行
- REQ-SCAN-03: 出力は `/msd-map-codebase` と同じ形式で `.planning/codebase/` に書き込まれなければならない

---

### 98. 自律監査から修正

**コマンド:** `/msd-audit-fix [--source <audit>] [--severity high|medium|all] [--max N] [--dry-run]`

**目的:** 監査を実行し、所見を自動修正可能と手動のみに分類し、テスト検証とアトミックコミットで自動修正可能な問題を自律的に修正するエンドツーエンドパイプライン。

**要件:**
- REQ-AUDITFIX-01: 所見は変更前に自動修正可能または手動のみとして分類されなければならない
- REQ-AUDITFIX-02: 各修正はコミット前にテストで検証されなければならない
- REQ-AUDITFIX-03: 各修正はアトミックにコミットされなければならない
- REQ-AUDITFIX-04: `--dry-run` は修正を適用せずに分類テーブルを表示しなければならない
- REQ-AUDITFIX-05: `--max N` は 1 回の実行で適用される修正数を制限しなければならない（デフォルト：5）

---

### 99. 改善されたプロンプトインジェクションスキャナー

**フック:** `msd-prompt-guard.js`、`msd-read-injection-scanner.js`
**スクリプト:** `scripts/prompt-injection-scan.sh`、`scripts/base64-scan.sh`

**目的:** プランニングアーティファクトおよび取り込んだコンテンツ内のプロンプトインジェクション試行の多層防御検出。ライブフックはフック独立性のために独自のパターンサブセットをインライン化します（`security.cts` からインポートしません）。CIスキャナー（`security.cts` の `scanForInjection`）は、テストでのコードベース全体スキャン用の集中エンジンを提供します。

**要件:**
- REQ-SCAN-INJ-01: ライブフックは不可視 Unicode 文字（ゼロ幅スペース、ソフトハイフン、Unicode タグブロック U+E0000–E007F）を検出しなければならない
- REQ-SCAN-INJ-02: ライブフックは既知のインジェクションパターン（命令オーバーライド、ロール操作、システムプロンプト抽出、偽のメッセージ境界）を検出しなければならない。Base64 デコードスキャンは CI 時制御（`scripts/base64-scan.sh`）であり、ライブフックではない — ライブフックは base64 持ち出しフレーズ正規表現のみを一致させ、デコードはしない。
- REQ-SCAN-INJ-03: ~~スキャナーはエントロピー分析を適用しなければならない~~ — エントロピー分析（`scanEntropyAnomalies`）は #2198 でデッドコードとして削除された（本番呼び出し元ゼロ；ライブフックはエントロピー分析を実行しない）。この要件は保守可能なライブ実装まで保留。
- REQ-SCAN-INJ-04: スキャナーは勧告的のみでなければならない — 検出はログに記録されるが、ブロッキングではない

---

### 100. プランフェーズのストール検出

**コマンド:** `/msd-plan-phase`

**目的:** プランナーの修正ループが停止した（複数のイテレーションにわたって同じ出力を生成している）ことを検出し、異なる戦略にエスカレートするか明確な診断で終了してサイクルを破ります。

**要件:**
- REQ-STALL-01: 修正ループは連続するイテレーション全体で同一のプラン出力を検出しなければならない
- REQ-STALL-02: ストール検出時、システムは再試行前に戦略をエスカレートしなければならない
- REQ-STALL-03: 最大ストール再試行数は制限されなければならない（既存の最大 3 イテレーションでキャップ）

---

### 101. /msd-progress --next のハードストップ安全ゲート

**コマンド:** `/msd-progress --next`

**目的:** 繰り返し同一ステップが検出された場合に自律チェーニングを中断するハードストップ安全ゲートと連続呼び出しガードを追加し、`/msd-progress --next` の暴走ループを防止します。

**要件:**
- REQ-NEXT-GATE-01: `/msd-progress --next` は連続した同一ステップ呼び出しをトラッキングしなければならない
- REQ-NEXT-GATE-02: 同一ステップの繰り返し時、システムはユーザーにハードストップゲートを提示しなければならない
- REQ-NEXT-GATE-03: ユーザーはハードストップゲートを通過して続行するために明示的に確認しなければならない

---

### 102. アダプティブモデルプリセット

**設定:** `model_profile: "adaptive"`

**目的:** すべてのエージェントに単一のティアを適用するのではなく、現在のエージェントのロールに基づいて適切なモデルティアを自動的に選択するロールベースのモデル割り当て。

**要件:**
- REQ-ADAPTIVE-01: `adaptive` プリセットはエージェントロールに基づいてモデルティアを割り当てなければならない（planner → quality ティア、executor → balanced ティアなど）
- REQ-ADAPTIVE-02: `adaptive` は `/msd-config --profile adaptive` で選択可能でなければならない

---

### 103. ポストマージハンク検証

**コマンド:** `/msd-update --reapply`

**目的:** アップデート後のローカルパッチ適用後、すべてのハンクが実際に適用されたことを期待されるパッチ内容とライブファイルシステムを比較することで検証します。不完全なマージをサイレントに受け入れるのではなく、ドロップされたまたは部分的なハンクを即座に表示します。

**要件:**
- REQ-PATCH-VERIFY-01: reapply-patches はマージ後に各ハンクが適用されたことを検証しなければならない
- REQ-PATCH-VERIFY-02: ドロップされたまたは部分的なハンクはファイルと行のコンテキストとともにユーザーに報告されなければならない
- REQ-PATCH-VERIFY-03: 検証はパッチごとではなく、すべてのパッチが適用された後に実行されなければならない

---

## v1.35.0 機能

- [新規ランタイムサポート (Cline, CodeBuddy, Qwen Code)](#104-新規ランタイムサポート-cline-codebuddy-qwen-code)
- [GSD-2 逆マイグレーション](#105-gsd-2-逆マイグレーション)
- [AI 統合フェーズウィザード](#106-ai-統合フェーズウィザード)
- [AI 評価レビュー](#107-ai-評価レビュー)

---

### 104. 新規ランタイムサポート (Cline, CodeBuddy, Qwen Code)

**対象:** `npx @golem15/msd-core`

**目的:** Cline、CodeBuddy、Qwen Code ランタイムへの MSD インストールを拡張します。

**要件:**
- REQ-CLINE-02: Cline インストールは `.clinerules` を `~/.cline/`（グローバル）または `./.cline/`（ローカル）に書き込まなければならない。カスタムスラッシュコマンドなし — ルールベースの統合のみ。フラグ：`--cline`。
- REQ-CODEBUDDY-01: CodeBuddy インストールはスキルを `~/.codebuddy/skills/msd-*/SKILL.md` にデプロイしなければならない。フラグ：`--codebuddy`。
- REQ-QWEN-01: Qwen Code インストールはスキルを `~/.qwen/skills/msd-*/SKILL.md` にデプロイしなければならない（Claude Code 2.1.88+ で使用されるオープン標準に従う）。`QWEN_CONFIG_DIR` 環境変数はデフォルトパスをオーバーライドします。フラグ：`--qwen`。

**ランタイムサマリー:**

| ランタイム | インストール形式 | 設定パス | フラグ |
|-----------|----------------|---------|-------|
| Cline | `.clinerules` | `~/.cline/` または `./.cline/` | `--cline` |
| CodeBuddy | スキル (`SKILL.md`) | `~/.codebuddy/skills/` | `--codebuddy` |
| Qwen Code | スキル (`SKILL.md`) | `~/.qwen/skills/` | `--qwen` |

---

### 105. GSD-2 逆マイグレーション

**コマンド:** `/msd-import --from-gsd2 [--dry-run] [--force] [--path <dir>]`

**目的:** GSD-2 形式（Milestone→Slice→Task 階層の `.gsd/` ディレクトリ）のプロジェクトを v1 の `.planning/` 形式に移行し、すべての MSD v1 コマンドとの完全な互換性を復元します。

**要件:**
- REQ-FROM-MSD2-01: インポーターは指定または現在のディレクトリから `.msd/` を読み込まなければならない
- REQ-FROM-MSD2-02: Milestone→Slice 階層は連続したフェーズ番号に平坦化されなければならない（M001/S01→フェーズ 01、M001/S02→フェーズ 02、M002/S01→フェーズ 03 など）
- REQ-FROM-MSD2-03: `--force` なしに既存の `.planning/` ディレクトリを上書きしないよう保護しなければならない
- REQ-FROM-MSD2-04: `--dry-run` はファイルを書き込まずにすべての変更をプレビューしなければならない
- REQ-FROM-MSD2-05: マイグレーションは `PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md`、および連続したフェーズディレクトリを生成しなければならない

**フラグ:**

| フラグ | 説明 |
|-------|------|
| `--dry-run` | ファイルを書き込まずにマイグレーション出力をプレビュー |
| `--force` | 既存の `.planning/` ディレクトリを上書き |
| `--path <dir>` | GSD-2 ルートディレクトリを指定 |

---

### 106. AI 統合フェーズウィザード

**コマンド:** `/msd-ai-integration-phase [N]`

**目的:** プロジェクトフェーズで AI/LLM 機能の選択、統合、評価計画を開発者にガイドします。プランニングと検証に組み込まれる構造化された `AI-SPEC.md` を生成します。

**要件:**
- REQ-AISPEC-01: ウィザードはフレームワーク選択、モデル選択、統合アプローチをカバーするインタラクティブな決定マトリックスを提示しなければならない
- REQ-AISPEC-02: システムはプロジェクトタイプに関連するドメイン固有の失敗モードと評価基準を表示しなければならない
- REQ-AISPEC-03: システムは 3 つの並列専門家エージェントをスポーンしなければならない：domain-researcher、framework-selector、eval-planner
- REQ-AISPEC-04: 出力はフレームワーク推奨、実装ガイダンス、評価戦略を含む `{phase}-AI-SPEC.md` を生成しなければならない

**生成物:** フェーズディレクトリ内の `{phase}-AI-SPEC.md`

---

### 107. AI 評価レビュー

**コマンド:** `/msd-eval-review [N]`

**目的:** 実行された AI フェーズの評価カバレッジを `AI-SPEC.md` プランと照合して遡及的に監査します。フェーズが閉じられる前に計画済みと実装済みの評価間のギャップを特定します。

**要件:**
- REQ-EVALREVIEW-01: レビューは指定されたフェーズから `AI-SPEC.md` を読み込まなければならない
- REQ-EVALREVIEW-02: 各評価ディメンションは COVERED、PARTIAL、または MISSING としてスコアリングされなければならない
- REQ-EVALREVIEW-03: 出力は所見、ギャップ説明、および修正ガイダンスを含まなければならない
- REQ-EVALREVIEW-04: `EVAL-REVIEW.md` はフェーズディレクトリに書き込まれなければならない

**生成物:** スコアリングされた評価ディメンション、ギャップ分析、修正ステップを含む `{phase}-EVAL-REVIEW.md`

---

## v1.36.0 機能

### 108. プランバウンス

**コマンド:** `/msd-plan-phase N --bounce`

**目的:** プランがチェッカーを通過した後、外部スクリプト（2 番目の AI、リンター、カスタムバリデーター）を通じてオプションで精製します。バウンスステップは各プランをバックアップし、スクリプトを実行し、結果の YAML フロントマターの整合性を検証し、プランチェッカーを再実行し、何か失敗した場合は元に戻します。

**要件:**
- REQ-BOUNCE-01: `--bounce` フラグまたは `workflow.plan_bounce: true` がステップを有効化；`--skip-bounce` は常に無効化
- REQ-BOUNCE-02: `workflow.plan_bounce_script` は有効な実行ファイルを指していなければならない；スクリプトが見つからない場合は警告を生成してスキップ
- REQ-BOUNCE-03: 各プランはスクリプト実行前に `*-PLAN.pre-bounce.md` にバックアップされる
- REQ-BOUNCE-04: YAML フロントマターが壊れているまたはプランチェッカーが失敗したバウンスされたプランはバックアップから復元される
- REQ-BOUNCE-05: `workflow.plan_bounce_passes`（デフォルト：2）はスクリプトが受け取る精製パス数を制御する

**設定:** `workflow.plan_bounce`、`workflow.plan_bounce_script`、`workflow.plan_bounce_passes`

---

### 109. 外部コードレビューコマンド

**コマンド:** `/msd-ship`（強化版）

**目的:** `/msd-ship` の手動レビューステップの前に、設定されている場合は外部コードレビューコマンドを自動的に実行します。コマンドは stdin を通じて diff とフェーズコンテキストを受け取り、JSON verdict（`APPROVED` または `REVISE`）を返します。結果に関わらず既存の手動レビューフローにフォールスルーします。

**要件:**
- REQ-EXTREVIEW-01: `workflow.code_review_command` はコマンド文字列に設定されなければならない；null はスキップを意味する
- REQ-EXTREVIEW-02: diff は `--stat` サマリーを含めて `BASE_BRANCH` に対して生成される
- REQ-EXTREVIEW-03: レビュープロンプトは stdin を通じてパイプされる（シェルインターポレートされない）
- REQ-EXTREVIEW-04: 120 秒タイムアウト；失敗時に stderr をキャプチャ
- REQ-EXTREVIEW-05: `verdict`、`confidence`、`summary`、`issues` フィールドの JSON 出力をパース

**設定:** `workflow.code_review_command`

---

### 110. クロス AI 実行デリゲーション

**コマンド:** `/msd-execute-phase N --cross-ai`

**目的:** 個々のプランを実行のために外部 AI ランタイムにデリゲートします。フロントマターに `cross_ai: true` があるプラン（または `--cross-ai` 使用時はすべてのプラン）が stdin を通じて設定済みコマンドに送信されます。正常に処理されたプランは通常の executor キューから削除されます。

**要件:**
- REQ-CROSSAI-01: `--cross-ai` はすべてのプランをクロス AI に強制；`--no-cross-ai` は無効化
- REQ-CROSSAI-02: `workflow.cross_ai_execution: true` とプランフロントマター `cross_ai: true` がプランごとのアクティベーションに必要
- REQ-CROSSAI-03: タスクプロンプトはインジェクションを防ぐために stdin を通じてパイプされる
- REQ-CROSSAI-04: ダーティなワーキングツリーは実行前に警告を生成する
- REQ-CROSSAI-05: 失敗時、ユーザーは選択する：再試行、スキップ（通常の executor にフォールバック）、またはアボート

**設定:** `workflow.cross_ai_execution`、`workflow.cross_ai_command`、`workflow.cross_ai_timeout`

---

### 111. アーキテクチャ責任マッピング

**コマンド:** `/msd-plan-phase`（強化されたリサーチステップ）

**目的:** フェーズリサーチ中に、phase-researcher が各機能をそのアーキテクチャティアオーナー（ブラウザ、フロントエンドサーバー、API、CDN/スタティック、データベース）にマッピングします。プランナーはこのマップに対してタスクをクロスリファレンスし、plan-checker はディメンション 7c としてティアコンプライアンスを強制します。

**要件:**
- REQ-ARM-01: Phase researcher は RESEARCH.md にアーキテクチャ責任マップテーブルを生成しなければならない（ステップ 1.5）
- REQ-ARM-02: プランナーはマップに対してタスクからティアへの割り当てをサニティチェックしなければならない
- REQ-ARM-03: Plan checker はディメンション 7c としてティアコンプライアンスを検証しなければならない（一般的な不一致は WARNING、セキュリティに敏感なものは BLOCKER）

**生成物:** `{phase}-RESEARCH.md` 内の `## Architectural Responsibility Map` セクション

---

### 112. 学習の抽出

**コマンド:** `/msd-extract-learnings N`

**目的:** 完了したフェーズのアーティファクトから構造化された知識を抽出します。PLAN.md と SUMMARY.md（必須）および VERIFICATION.md、UAT.md、STATE.md（オプション）を読み込み、決定、教訓、パターン、驚きの 4 カテゴリの学習を生成します。オプションで `capture_thought` ツールを通じて各項目を外部ナレッジベースにキャプチャします。

**要件:**
- REQ-LEARN-01: PLAN.md と SUMMARY.md が必要；見つからない場合は明確なエラーで終了
- REQ-LEARN-02: 各抽出された項目にはソース帰属（アーティファクトとセクション）が含まれる
- REQ-LEARN-03: `capture_thought` ツールが利用可能な場合、`source`、`project`、`phase` メタデータとともに項目をキャプチャする
- REQ-LEARN-04: `capture_thought` が利用不可の場合、正常に完了し、外部キャプチャがスキップされたことをログに記録する
- REQ-LEARN-05: 2 回実行すると前の `LEARNINGS.md` が上書きされる

**生成物:** YAML フロントマター（phase、project、カテゴリごとのカウント、missing_artifacts）を含む `{phase}-LEARNINGS.md`

**オプション統合 — `capture_thought`:** `capture_thought` は**バンドルされたツールではなく、規約**です。MSD はそれを同梱せず、必須でもありません。ワークフローは現在のセッションの MCP サーバーが `capture_thought` という名前のツールを公開しているかどうかを確認し、公開している場合は以下のシグネチャで抽出した学習ごとに 1 回呼び出します。そのようなツールが存在しない場合、ステップはサイレントにスキップされ、`LEARNINGS.md` が主要な出力として残ります。

期待されるツールシグネチャ：
```javascript
capture_thought({
  category: "decision" | "lesson" | "pattern" | "surprise",
  phase: <phase_number>,
  content: <learning_text>,
  source: <artifact_name>
})
```

メモリ / ナレッジベース MCP サーバー（例：ExoCortex スタイルのサーバー、`claude-mem`、または `mem0` スタイルのサーバー）を実行するユーザーは、このツール名を実装して、`project`、`phase`、`source` メタデータとともに学習を自動的にナレッジベースにルーティングできます。それ以外のユーザーは追加のセットアップなしに `/msd-extract-learnings` を使用できます — `LEARNINGS.md` アーティファクトが機能です。

---

### 114. コンテキストウィンドウ対応プロンプト薄化

**目的:** 200K トークン未満のコンテキストウィンドウを持つモデルのスタティックプロンプトオーバーヘッドを最大 40% 削減します。拡張例とアンチパターンリストがエージェント定義から `@` required_reading を通じてオンデマンドで読み込まれる参照ファイルに抽出されます。

**要件:**
- REQ-THIN-01: `CONTEXT_WINDOW < 200000` の場合、executor と planner のエージェントプロンプトはインライン例を省略する
- REQ-THIN-02: 抽出されたコンテンツは `references/executor-examples.md` と `references/planner-antipatterns.md` に存在する
- REQ-THIN-03: 標準（200K-500K）と拡張（500K+）ティアは影響を受けない
- REQ-THIN-04: コアルールと決定ロジックはインラインのまま；詳細な例のみが抽出される

**参照ファイル:** `executor-examples.md`、`planner-antipatterns.md`

---

### 115. 設定可能な CLAUDE.md パス

**目的:** プロジェクトが CLAUDE.md をルート以外の場所に保存できるようにします。`claude_md_path` 設定キーは `/msd-profile-user` および関連コマンドが生成された CLAUDE.md ファイルを書き込む場所を制御します。

**要件:**
- REQ-CMDPATH-01: `claude_md_path` はデフォルトで `./CLAUDE.md`
- REQ-CMDPATH-02: プロファイル生成コマンドは設定からパスを読み込み、指定された場所に書き込む
- REQ-CMDPATH-03: 相対パスはプロジェクトルートから解決される

**設定:** `claude_md_path`

---

### 116. TDD パイプラインモード

**目的:** オプトインの TDD（レッドグリーンリファクタリング）をファーストクラスのフェーズ実行モードとして提供します。有効にすると、プランナーは適切なタスクに対して積極的に `type: tdd` を選択し、executor は RED/GREEN/REFACTOR ゲートシーケンスを強制し、RED 前の予期しない GREEN でフェイルファストします。

**要件:**
- REQ-TDD-01: `workflow.tdd_mode` 設定キー（boolean、デフォルト `false`）
- REQ-TDD-02: 有効時、プランナーは `references/tdd.md` の TDD ヒューリスティックをすべての適格なタスク（ビジネスロジック、API、バリデーション、アルゴリズム、ステートマシン）に適用する
- REQ-TDD-03: Executor は `type: tdd` プランのゲートシーケンスを強制する — RED コミット（`test(...)`）は GREEN コミット（`feat(...)`）より先でなければならない
- REQ-TDD-04: Executor は RED フェーズ中にテストが予期しなくパスした場合にフェイルファストする（機能がすでに存在するかテストが間違っている）
- REQ-TDD-05: フェーズ終了時の協調レビューチェックポイントがすべての TDD プランにわたるゲートコンプライアンスを確認する（勧告的、非ブロッキング）
- REQ-TDD-06: ゲート違反は SUMMARY.md の `## TDD Gate Compliance` セクション下に表示される

**設定:** `workflow.tdd_mode`
**参照ファイル:** `tdd.md`、`checkpoints.md`

---

## v1.37.0 機能

### 117. スパイクコマンド

**コマンド:** `/msd-spike [idea] [--quick]`

**目的:** 実装アプローチにコミットする前に 2〜5 つの焦点を絞った実現可能性実験を実行します。各実験は Given/When/Then フレーミングを使用し、実行可能なコードを生成し、VALIDATED / INVALIDATED / PARTIAL verdict を返します。コンパニオンの `/msd-spike --wrap-up` は所見をプロジェクトローカルのスキルにパッケージ化します。

**要件:**
- REQ-SPIKE-01: 各実験はコードが書かれる前に Given/When/Then 仮説を生成しなければならない
- REQ-SPIKE-02: 各実験は動作するコードまたは最小限の再現を含まなければならない
- REQ-SPIKE-03: 各実験はエビデンスとともに VALIDATED、INVALIDATED、または PARTIAL verdict のいずれかを返さなければならない
- REQ-SPIKE-04: 結果は `.planning/spikes/NNN-experiment-name/` に README と MANIFEST.md とともに保存されなければならない
- REQ-SPIKE-05: `--quick` フラグはインテーク会話をスキップし、引数テキストを実験方向として使用する
- REQ-SPIKE-06: `/msd-spike --wrap-up` は所見を `.claude/skills/spike-findings-[project]/` にパッケージ化しなければならない

**生成物:**

| アーティファクト | 説明 |
|---------------|------|
| `.planning/spikes/NNN-name/README.md` | 仮説、実験コード、verdict、エビデンス |
| `.planning/spikes/MANIFEST.md` | verdict を含むすべてのスパイクのインデックス |
| `.claude/skills/spike-findings-[project]/` | パッケージ化された所見（`/msd-spike --wrap-up` 経由） |

---

### 118. スケッチコマンド

**コマンド:** `/msd-sketch [idea] [--quick] [--text]`

**目的:** 実装にコミットする前に使い捨ての HTML モックアップを通じてデザイン方向を探索します。デザインの質問ごとに 2〜3 のインタラクティブなバリアントを生成し、ビルドステップなしにブラウザで直接閲覧できます。コンパニオンの `/msd-sketch --wrap-up` は勝利した決定をプロジェクトローカルのスキルにパッケージ化します。

**要件:**
- REQ-SKETCH-01: 各スケッチは 1 つの特定のビジュアルデザイン質問に答えなければならない
- REQ-SKETCH-02: 各スケッチはタブナビゲーションを持つ単一の `index.html` に 2〜3 の意味のある異なるバリアントを含まなければならない
- REQ-SKETCH-03: すべてのインタラクティブ要素（ホバー、クリック、トランジション）は機能しなければならない
- REQ-SKETCH-04: スケッチはリアルに近いコンテンツを使用しなければならない（ lorem ipsum ではない）
- REQ-SKETCH-05: 共有の `themes/default.css` は合意された美観に適応した CSS 変数を提供しなければならない
- REQ-SKETCH-06: `--quick` フラグはムードインテークをスキップ；`--text` フラグは非 Claude ランタイム用に `AskUserQuestion` を番号付きリストに置き換える
- REQ-SKETCH-07: 勝利バリアントは README フロントマターと HTML タブの ★ でマークされなければならない
- REQ-SKETCH-08: `/msd-sketch --wrap-up` は勝利した決定を `.claude/skills/sketch-findings-[project]/` にパッケージ化しなければならない

**生成物:**
| アーティファクト | 説明 |
|---------------|------|
| `.planning/sketches/NNN-name/index.html` | 2〜3 のインタラクティブ HTML バリアント |
| `.planning/sketches/NNN-name/README.md` | デザイン質問、バリアント、勝者、注目点 |
| `.planning/sketches/themes/default.css` | 共有 CSS テーマ変数 |
| `.planning/sketches/MANIFEST.md` | 勝者を含むすべてのスケッチのインデックス |
| `.claude/skills/sketch-findings-[project]/` | パッケージ化された決定（`/msd-sketch --wrap-up` 経由） |

---

### 119. エージェントサイズ予算強制

**目的:** CI で強制される段階的な行数制限でエージェントプロンプトファイルをリーンに保ちます。過大なエージェントは本番のコンテキストウィンドウを肥大化させる前にキャッチされます。

**要件:**
- REQ-BUDGET-01: `agents/msd-*.md` ファイルは 3 つのティアに分類される：XL（≤ 1,600 行）、Large（≤ 1,000 行）、Default（≤ 500 行）
- REQ-BUDGET-02: ティア割り当てはファイルの YAML フロントマターで宣言される（`size: xl | large | default`）
- REQ-BUDGET-03: `tests/agent-size-budget.test.cjs` は制限を強制し、違反時に CI を失敗させる
- REQ-BUDGET-04: `size` フロントマターキーのないファイルはデフォルト（500 行）制限にデフォルトする

**テストファイル:** `tests/agent-size-budget.test.cjs`

---

### 120. 共有ボイラープレート抽出

**目的:** 共通の 2 つのボイラープレートブロックをオンデマンドで読み込まれる共有参照ファイルに抽出することでエージェント間の重複を削減します。エージェントファイルをサイズ予算内に保ち、ボイラープレートの更新を単一ファイルの変更にします。

**要件:**
- REQ-BOILER-01: 必須初期読み込み命令は `references/mandatory-initial-read.md` に抽出される
- REQ-BOILER-02: プロジェクトスキルディスカバリー命令は `references/project-skills-discovery.md` に抽出される
- REQ-BOILER-03: 以前これらのブロックをインライン化していたエージェントは `@` required_reading を通じてそれらを参照しなければならない

**参照ファイル:** `references/mandatory-initial-read.md`、`references/project-skills-discovery.md`

---

### 121. ナレッジグラフ統合

**目的:** `.planning/graphs/` にプロジェクトの軽量なナレッジグラフを構築、クエリ、検査します。プロジェクトごとのオプトイン。ユーザー向けコマンドの `/msd-graphify` とプログラマティックな `msd-tools.cjs graphify …` 動詞ファミリーとして公開されています。コマンド、エージェント、ワークフロー、フェーズをまたいだノードとエッジのグラフ指向ビューで `/msd-map-codebase --query`（スナップショット指向）を補完します。

**要件:**
- REQ-GRAPH-01: `.planning/config.json` の `graphify.enabled: true` によるオプトイン。無効時、`/msd-graphify` はアクティベーションヒントを表示して書き込みなしで停止。
- REQ-GRAPH-02: スラッシュコマンド `/msd-graphify` はサブコマンド `build`、`query <term>`、`status`、`diff` を公開。プログラマティック CLI `node msd-tools.cjs graphify …` はさらに `snapshot` を公開し、`graphify build` の最終ステップとして自動的に呼び出される。
- REQ-GRAPH-03: ビルドは設定可能な `graphify.build_timeout`（秒）内で実行；タイムアウトを超えた場合、部分的なグラフを残さずにクリーンに中断。
- REQ-GRAPH-04: `graphify.cjs` は `graph.edges` が存在しない場合に `graph.links` にフォールバックし、古いグラフアーティファクトが引き続きレンダリングされるようにする。
- REQ-GRAPH-05: Graphify は `msd-tools.cjs graphify ...` コマンドハンドラーを通じて呼び出される。

**設定:** `graphify.enabled`、`graphify.build_timeout`
**参照ファイル:** `commands/msd/graphify.md`、`bin/lib/graphify.cjs`

---

## v1.40.0 機能

### 122. スキルサーフェス統合

**目的:** 31 のマイクロスキルを 4 つの新しいグループ化された親と、サブ操作をフラグとして吸収する 6 つの既存の親に折りたたんで、積極的なスキルリストのオーバーヘッドを削減します。機能的な損失はゼロ — 削除されたすべてのマイクロスキルの動作は統合された親のフラグを通じて存続します。統合後、`commands/msd/*.md` は 59 のサブスキル（plus 6 つのネームスペースメタスキル、#123 参照）を搭載。

**要件:**
- REQ-CONSOLIDATE-01: 4 つの新しいグループ化されたスキルがマイクロスキルのクラスターを置き換える：
  - `/msd-capture` — add-todo（デフォルト）、note（`--note`）、add-backlog（`--backlog`）、plant-seed（`--seed`）、check-todos（`--list`）を折りたたむ
  - `/msd-phase` — add-phase（デフォルト）、insert-phase（`--insert`）、remove-phase（`--remove`）、edit-phase（`--edit`）を折りたたむ
  - `/msd-config` — settings-advanced（`--advanced`）、settings-integrations（`--integrations`）、set-profile（`--profile`）を折りたたむ
  - `/msd-workspace` — new-workspace（`--new`）、list-workspaces（`--list`）、remove-workspace（`--remove`）を折りたたむ
- REQ-CONSOLIDATE-02: 6 つの既存の親がラップアップ/サブ操作をフラグとして吸収：`/msd-update --sync`、`/msd-update --reapply`、`/msd-sketch --wrap-up`、`/msd-spike --wrap-up`、`/msd-map-codebase --fast`、`/msd-map-codebase --query`、`/msd-code-review --fix`、`/msd-progress --do`、`/msd-progress --next`。
- REQ-CONSOLIDATE-03: 削除されたマイクロスキルスラッシュフォーム（`msd-add-todo`、`msd-add-backlog`、`msd-plant-seed`、`msd-check-todos`、`msd-add-phase`、`msd-insert-phase`、`msd-remove-phase`、`msd-edit-phase`、`msd-new-workspace`、`msd-list-workspaces`、`msd-remove-workspace`、`msd-settings-advanced`、`msd-settings-integrations`、`msd-set-profile`、`msd-sketch-wrap-up`、`msd-spike-wrap-up`、`msd-reapply-patches`、`msd-code-review-fix`、…）は「Unknown command」に解決しなければならない — シャドウスタブなし。
- REQ-CONSOLIDATE-04: `autonomous.md` は（削除された `msd-code-review-fix` を以前呼び出していた代わりに）`/msd-code-review --fix` を呼び出す。

**参照 issue:** [#2790](https://github.com/open-gsd/gsd-core/issues/2790)

---

### 123. ネームスペースメタスキル（2 段階ルーティング）

**目的:** フラットな積極的スキルリストを 2 段階の階層的ルーティングレイヤーに置き換えます。モデルは 86 エントリの代わりに 6 つのネームスペースルーターを認識し、ネームスペースを選択してからサブスキルにルーティングします。説明にはルーティング密度のためにパイプ区切りのキーワードタグ（≤ 60 文字）を使用します。

**コマンド:**
- `/msd-workflow` — フェーズパイプラインルーター（discuss / plan / execute / verify / phase / progress）
- `/msd-project` — プロジェクトライフサイクル（マイルストーン、監査、サマリー）
- `/msd-quality` — 品質ゲート（コードレビュー、デバッグ、監査、セキュリティ、評価、UI）
- `/msd-context` — コードベースインテリジェンス（マップ、グラファイファイ、ドキュメント、学習）
- `/msd-manage` — 設定 / ワークスペース / ワークストリーム / スレッド / アップデート / シップ / インボックス
- `/msd-ideate` — 探索とキャプチャ（探索、スケッチ、スパイク、スペック、キャプチャ）

**トークンコスト:**

| | エントリ数 | 概算トークン |
|---|---|---|
| v1.40 以前のフルインストール | 86 | ~2,150 |
| ネームスペースメタスキル | 6 | ~120 |

**要件:**
- REQ-NS-01: 6 つの `commands/msd/ns-*.md` ネームスペースルーターはパイプ区切りのキーワードタグ説明（≤ 60 文字）とともに搭載される。
- REQ-NS-02: 既存のサブスキルは変更されず、引き続き直接呼び出し可能 — ネームスペーススキルは直接スラッシュフォームの置き換えではなく追加的。
- REQ-NS-03: 各ネームスペースルーターの本体には、#2790 以後の統合されたサーフェス上の正しい具体的なサブスキルへのユーザーインテントをマッピングするルーティングテーブルが含まれる。

**参照 issue:** [#2792](https://github.com/open-gsd/gsd-core/issues/2792)

---

### 124. コンテキストウィンドウ使用率ガード

**コマンド:** `/msd-health --context`

**目的:** コンテキストウィンドウの飽和に対する品質ガード。2 つの閾値：60% 使用率で警告（「`/msd-thread` を検討してください」）、70% でクリティカル（「推論品質が低下する可能性があります」；最近のコンテキストアテンション研究による破断点に一致）。

**要件:**
- REQ-CTX-GUARD-01: `/msd-health --context` は現在の使用率、閾値ティア（`ok` / `warn` / `critical`）、修正提案を含む構造化されたステータス行を出力する。
- REQ-CTX-GUARD-02: 同じトリアージは `msd-tools.cjs validate context --tokens-used <int> --context-window <int>` として公開されている — ステータス行とフック呼び出し元の構造化エンベロープ（#125）。両フラグは必須；ハンドラーは REQ-CTX-GUARD-03 の純粋な分類器と同じ `{ percent, state }` エンベロープを返す。
- REQ-CTX-GUARD-03: 分類器（`bin/lib/context-utilization.cjs`）は純粋：入力 `(tokensUsed, contextWindow)`、出力 `{ percent, state }`。ユニットテストが容易で、任意の呼び出し元から再利用しやすい。

**参照 issue:** [#2792](https://github.com/open-gsd/gsd-core/issues/2792)

---

### 125. フェーズライフサイクルステータス行リードサイド

**目的:** ステータス行にフェーズオーケストレーション状態を表示します。`parseStateMd()` は 4 つの新しい STATE.md フロントマターフィールドを読み込み、`formatMsdState()` は実行中、アイドル、および進行状況シーンをレンダリングします。ライトサイドの配線は後の RC で行われます。

**要件:**
- REQ-LIFECYCLE-01: `parseStateMd()` は 4 つのオプションフィールドを読み込む：
  - `active_phase` — オーケストレーターが実行中のフェーズ番号
  - `next_action` — アイドル時の推奨される次のコマンド
  - `next_phases` — 次のフェーズ番号の YAML フロー配列
  - `progress` — ネストされた `total_phases` / `completed_phases` / `percent` ブロック
- REQ-LIFECYCLE-02: `formatMsdState()` はライフサイクルフィールドを優先順位の順にチェックし、最初に一致するシーンを出力する（フェーズアクティブ → アイドル次推奨 → マイルストーン完了 → デフォルトフォールバック）。
- REQ-LIFECYCLE-03: 4 つのフィールドはすべてデフォルトで undefined；既存の STATE.md ファイルはバイト単位で同一にレンダリングされる。

**参照 issue:** [#2833](https://github.com/open-gsd/gsd-core/issues/2833) — フルフィールドリファレンスとレンダリングルールについては [`docs/STATE-MD-LIFECYCLE.md`](../reference/state-md.md) を参照。

---

## v1.41.0 機能

### 126. フェーズタイプごとのモデル選択

**目的:** フルエージェント分類法を習得せずにフェーズレベル（プランニング、リサーチ、実行、検証）でモデルチューニングを表現します。エージェントごとの `model_overrides`（精密、冗長）とグローバル `model_profile` ティア（粗い、均一）の中間に位置します。

**設定キー:** `.planning/config.json` の `models`

**フェーズタイプスロット:**

| スロット | 割り当てられたエージェント |
|---------|----------------------|
| `planning` | `msd-planner`、`msd-roadmapper`、`msd-pattern-mapper` |
| `discuss` | `msd-assumptions-analyzer` |
| `research` | `msd-phase-researcher`、`msd-project-researcher`、`msd-research-synthesizer`、`msd-codebase-mapper`、`msd-ui-researcher` |
| `execution` | `msd-executor`、`msd-debugger`、`msd-doc-writer` |
| `verification` | `msd-verifier`、`msd-plan-checker`、`msd-integration-checker`、`msd-nyquist-auditor`、`msd-ui-checker`、`msd-ui-auditor`、`msd-doc-verifier`、`msd-code-reviewer` |
| `completion` | （将来のサブエージェント用に予約） |

**受け入れられる値:** `"opus"` / `"sonnet"` / `"haiku"` / `"inherit"`

**解決の優先順位（高→低）:**

```text
1. model_overrides[<agent>]
2. dynamic_routing.tier_models[<tier>]   (有効時)
3. models[<phase_type>]                  (この機能)
4. model_profile
5. ランタイムデフォルト
```

**要件:**
- REQ-PHASE-MODELS-01: 6 つの名前付き `models.*` スロットが `config-schema.cjs` と `config-schema.ts` に受け入れられる；`config-set` は不明なフェーズタイプを拒否する。
- REQ-PHASE-MODELS-02: `models` ブロックのない設定は v1.41 以前の動作とバイト単位で同一に動作する。
- REQ-PHASE-MODELS-03: `discuss` と `completion` は前方互換性のためにスキーマに受け入れられる；今日それらを設定することはサブエージェントが各にマッピングされるまでノーオペレーション。

**参照 issue:** [#3023](https://github.com/open-gsd/gsd-core/pull/3030)

---

### 127. 失敗ティアエスカレーション付き動的ルーティング

**目的:** デフォルトで安価なティアを使用し、オーケストレーターがソフト失敗（検証が決定的でない、プランチェック FLAG など）を検出した場合に自動的により有能なモデルにエスカレートします。

**設定キー:** `.planning/config.json` の `dynamic_routing`

**動作:**
- `enabled: false`（デフォルト）— 機能はオフ；すべてのエージェントは変更なしに優先順位チェーンを使用。
- `enabled: true` — リゾルバーは最初のスポーンに `tier_models[default_tier]` を選択し、オーケストレーターが検出したソフト失敗で 1 ティア上にエスカレートし、`max_escalations` でキャップ。

**構成:** `model_overrides` は常に優先；`dynamic_routing.tier_models[<tier>]` は `models.<phase_type>` と `model_profile` より上で解決。

**要件:**
- REQ-DYNROUTE-01: `dynamic_routing.enabled` はマスタースイッチとして機能；`false` またはブロックが存在しない場合、動作変更はゼロ。
- REQ-DYNROUTE-02: 新しいリゾルバー `resolveModelForTier(cwd, agent, attempt)`（`core.cjs` 内）はオーケストレーター統合の単一コールサイト。
- REQ-DYNROUTE-03: `max_escalations` はランナウェイコストを防ぐためにエスカレーションチェーンをキャップ。

**参照 issue:** [#3024](https://github.com/open-gsd/gsd-core/pull/3031)

---

### 128. アップデートバナーオプトイン

**目的:** MSD ステータス行を拒否またはバイパスしたユーザーに、ステータス行を必要とせずにアップデートの可用性を表示します。

**動作:**
- インストール時、インストーラーが MSD ステータス行を検出しない場合、オプトインの `SessionStart` フックを提供します。
- フックはステータス行で使用されているのと同じキャッシュ `~/.cache/msd/msd-update-check.json` を読み込み、アップデートが利用可能な場合のみバナーを表示します。
- 最新の場合はサイレント。
- 障害診断は 24 時間に 1 回に制限。
- `npx @golem15/msd-core --uninstall` によってクリーンに削除。

**要件:**
- REQ-BANNER-01: バナーは明示的なオプトインなしにインストールされない。
- REQ-BANNER-02: 追加のネットワークリクエストなし — 既存のバックグラウンドアップデートチェックキャッシュを再利用。
- REQ-BANNER-03: アンインストールパスはバナーフックを削除する。

**参照 issue:** [#2795](https://github.com/open-gsd/gsd-core/pull/2795)

---

### 129. issue-driven-orchestration ガイド

**目的:** GitHub / Linear / Jira issue から MSD ワークフロー全体を駆動するレシピを文書化し、トラッカー中心の概念を既存の MSD プリミティブにマッピングします。

**ドキュメント:** [`docs/issue-driven-orchestration.md`](../issue-driven-orchestration.md)

**対象ワークフロー:**
1. issue ごとに分離されたワークスペースを作成（`/msd-workspace --new`）
2. マネージャーダッシュボードを実行して全体を把握（`/msd-manager`）
3. 自律的に実行（`/msd-autonomous`）
4. 検証とレビュー（`/msd-verify-work`、`/msd-review`）
5. シップして issue をクローズ（`/msd-ship`）

新しいコマンドやデーモンプロセスはなし — 既存のプリミティブをトラッカー駆動ワークフローにマッピングする純粋なドキュメントアーティファクト。

**参照 issue:** [#2840](https://github.com/open-gsd/gsd-core/pull/2840)

---

### 130. グラファイファイコミットベースの古さ検出

**目的:** アーキテクチャグラフが現在のコミットから構築されたか古いコミットから構築されたかを表示し、既存の mtime ベースの古さシグナルを補完します。

**コマンド:** `/msd-graphify status`

**返される新フィールド（graphify v0.7+ グラフ）:**

| フィールド | 型 | 説明 |
|-----------|-----|------|
| `built_at_commit` | string | グラフが構築されたコミット SHA |
| `current_commit` | string | 現在の `git HEAD` |
| `commits_behind` | number | グラフが HEAD から何コミット遅れているか |
| `commit_stale` | boolean \| null | `true`=古い、`false`=最新、`null`=利用不可（v0.7 以前、非 git） |

**レンダリング出力（シグナルが利用可能な場合）:**
```
Source commit: abc1234 (3 commits behind HEAD)
```

**セキュリティ:** `built_at_commit` は `git` に到達する前に 4〜40 の 16 進文字として検証される — 悪意のある `graph.json` はダッシュオプションを argv にインジェクトできない。

**フォールバック:** v0.7 以前のグラフと非 git チェックアウトは `commit_stale: null` を返す；呼び出し元は既存の mtime ベースの `stale` フラグにフォールバック。既存ユーザーの動作変更なし。

**参照 issue:** [#3170](https://github.com/open-gsd/gsd-core/issues/3170)

---

## v1.42.1 機能

### 132. パッケージ正当性ゲート

**目的:** 幻覚的、疑わしい、またはスロップスクワッティングのパッケージ名がシェルインストールコマンドに到達する前に停止します。

**動作:**
- フェーズリサーチは推奨パッケージの `## Package Legitimacy Audit` テーブルを書き込む。
- 検索のみで確認されたパッケージは `[ASSUMED]` として扱われ、信頼されない。
- `[SLOP]` パッケージは推奨から削除される。
- `[ASSUMED]` または疑わしいパッケージを必要とするプランは人間の確認チェックポイントを追加する。
- Executor のインストール失敗は、同様の名前のパッケージを自動的に試みる代わりに人間の確認のために停止する。

**要件:**
- REQ-PKG-GATE-01: リサーチはパッケージレジストリ、年齢、ダウンロード/ソースシグナル、正当性判定、および処分を記録しなければならない。
- REQ-PKG-GATE-02: プランナーは実行前に未検証または疑わしいパッケージのインストールをゲートしなければならない。
- REQ-PKG-GATE-03: Executor はパッケージマネージャーのインストール失敗後にパッケージ名を自動置換してはならない。

**参照:** [v1.42.1 リリースノート](../RELEASE-v1.42.1.md)

---

### 133. スキルサーフェス予算

**目的:** コンテキスト予算が重要な場合に、インストールされたスキルとエージェントのサーフェスエリアをユーザーが削減できるようにします。

**インストールプロファイル:**
| プロファイル | 目的 |
|------------|------|
| `core` | 最小限のメインループサーフェス |
| `standard` | コアに加えて一般的なフェーズ管理コマンド |
| `full` | 完全なサーフェス；デフォルト |

**ランタイムコントロール:** `/msd-surface` はプロファイル状態をリストし、再インストールなしにスキルクラスターを有効化、無効化、またはリセットします。

**要件:**
- REQ-SURFACE-01: インストーラーは `--profile=<name>` を解決し、アクティブなプロファイルを `.msd-profile` に永続化しなければならない。
- REQ-SURFACE-02: `--minimal` と `--core-only` は `--profile=core` のエイリアスとして残らなければならない。
- REQ-SURFACE-03: ランタイムサーフェス状態はインストールプロファイルマーカーの外側に永続化されなければならない。

**参照:** [ADR-0011](../adr/0011-skill-surface-budget-module.md)

---

### 134. インストーラーマイグレーション

**目的:** インストールとアップデート中のランタイム設定クリーンアップを明示的で監査可能、かつロールバック対応にします。

**機能:**
- 初回ベースラインマイグレーションは管理されたファイルを記録する。
- レガシーステールファイルのクリーンアップは削除または再書き込み前に所有権のエビデンスを使用する。
- ユーザー所有のアーティファクトは保存される。
- 曖昧な MSD らしいファイルはサイレントに上書きされる代わりに明確なレポートでブロックする。
- マイグレーションプランはドライラン報告とロールバック保護をサポートする。

**要件:**
- REQ-INSTALL-MIGRATION-01: マイグレーション記録はメタデータ、インストールスコープ、所有権のエビデンスを含まなければならない。
- REQ-INSTALL-MIGRATION-02: 所有権が曖昧な場合、破壊的なアクションはフェイルドクローズでなければならない。
- REQ-INSTALL-MIGRATION-03: インストール失敗はロールバックデータが存在する場合、インストール前の状態を復元しなければならない。

**参照:** [インストーラーマイグレーション](../installer-migrations.md)

---

### 135. カスタムシップ PR ボディセクション

**コマンド:** `/msd-ship`

**設定キー:** `ship.pr_body_sections`

**目的:** MSD ワークフローファイルを編集せずに、生成された PR ボディにプロジェクト固有の PRD スタイルセクションを追加します。

**動作:** 設定されたセクションは必須の `Summary`、`Changes`、`Requirements Addressed`、`Verification`、および `Key Decisions` セクションの後に追加されます。アーティファクトの見出しからコピー、テンプレートをレンダリング、またはスタティックテキストにフォールバックできます。

**要件:**
- REQ-SHIP-SECTIONS-01: カスタムセクションは必須の PR セクションを置き換え、削除、または並べ替えてはならない。
- REQ-SHIP-SECTIONS-02: 不明なテンプレートトークンは設定検証によって拒否されなければならない。
- REQ-SHIP-SECTIONS-03: 無効化されたセクションは PR 出力に表示されることなく設定に残らなければならない。

**参照:** [カスタム PR ボディセクション](../ship-pr-body-sections.md)

---

### 136. レビューデフォルトレビュアー

**コマンド:** `/msd-review`

**設定キー:** `review.default_reviewers`

**目的:** チームがフラグなしの `/msd-review` 実行のデフォルトレビュアーサブセットを選択できるようにします。

**優先順位:**
```text
明示的なレビュアーフラグ -> --all -> review.default_reviewers -> すべての検出されたレビュアー
```

**要件:**
- REQ-REVIEW-DEFAULTS-01: `review.default_reviewers` が欠如している場合、以前のすべて検出動作を維持しなければならない。
- REQ-REVIEW-DEFAULTS-02: 空の配列は拒否されなければならない；すべて検出動作を復元するにはキーを削除する。
- REQ-REVIEW-DEFAULTS-03: 既知だが利用不可のレビュアーは実行をハードフェイルさせる代わりに診断とともにスキップされなければならない。

**参照:** [設定リファレンス](../CONFIGURATION.md#reviewer-defaults-for-msd-review)

---

### 137. ファロー構造レビュープリパス

**コマンド:** `/msd-code-review`

**設定キー:** `code_quality.fallow.*`

**目的:** エージェントレビューの前にオプションの構造分析パスを追加します。

**動作:** 有効時、MSD は `fallow` バイナリを解決し、境界付き監査を実行し、`FALLOW.json` を書き込み、`REVIEW.md` に構造的な所見を埋め込みます。

**要件:**
- REQ-FALLOW-01: Fallow はオプトインであり、デフォルトで無効でなければならない。
- REQ-FALLOW-02: 欠如または失敗した fallow 実行は明確な診断を生成しなければならない。
- REQ-FALLOW-03: 埋め込み予算を超えた所見は、生の JSON アーティファクトを保存しながら警告とともにスキップされなければならない。

**参照:** [設定リファレンス](../CONFIGURATION.md#code-quality-settings)

---

### 138. フェーズ終了時の人間検証モード

**設定キー:** `workflow.human_verify_mode`

**目的:** フライト中の人間チェックポイントの中断を減らしながら、人間の検証要件を保持します。

**動作:** デフォルトの `"end-of-phase"` モードは人間チェックをフェーズレビューのための `<verify><human-check>` ブロックに埋め込みます。`"mid-flight"` はブロッキングの `checkpoint:human-verify` タスクを復元します。

**要件:**
- REQ-HUMAN-VERIFY-01: `checkpoint:decision` と `checkpoint:human-action` はモードに関わらずブロッキングのまま。
- REQ-HUMAN-VERIFY-02: 人間が必要な検証はフェーズ終了時のレビューが解決するまで保留のまま。
- REQ-HUMAN-VERIFY-03: キーのない設定は `"end-of-phase"` を使用しなければならない。

**参照:** [チェックポイントリファレンス](../../msd-core/references/checkpoints.md)

---

### 139. クォータとレート制限の失敗分類

**コマンド:** `/msd-execute-phase`

**目的:** プロバイダーのクォータとレート制限の失敗を、通常の executor の失敗ではなく待機して再開の条件として扱います。

**動作:** エージェント出力は `429`、`rate limit`、`usage limit`、`RESOURCE_EXHAUSTED`、`usage_limit_reached` などのシグナルに対して分類されます。一致する失敗はリセット待ちの回復パスを提示します。

**要件:**
- REQ-QUOTA-01: クォータ失敗は即時再試行を主要な回復として提供してはならない。
- REQ-QUOTA-02: 分類は Claude、Copilot、Codex、および汎用プロバイダーセンチネルをカバーしなければならない。
- REQ-QUOTA-03: 非クォータ失敗は通常の実行失敗パスを継続しなければならない。

**参照:** [プロバイダーレート制限シグナル](../research/provider-rate-limit-signals.md)

---

### 140. ステータス行コンテキスト位置

**設定キー:** `statusline.context_position`

**目的:** 狭いターミナルでコンテキストメーターを見やすく保ちます。

**オプション:**
| 値 | 動作 |
|----|------|
| `"end"` | デフォルト；行末近くにコンテキストメーターをレンダリング |
| `"front"` | モデル名の直後にコンテキストメーターをレンダリング |

**要件:**
- REQ-STATUSLINE-POS-01: 無効な値は設定検証によって拒否されなければならない。
- REQ-STATUSLINE-POS-02: 設定が欠如している場合、既存の末尾位置レンダリングを維持しなければならない。

**参照:** [設定リファレンス](../CONFIGURATION.md#statusline-settings)

---

### 141. マイルストーンタグ作成トグル

**コマンド:** `/msd-complete-milestone`

**設定キー:** `git.create_tag`

**目的:** 外部リリース自動化を持つプロジェクトがローカル git タグを作成せずにマイルストーンを完了できるようにします。

**動作:** `git.create_tag: false` はマイルストーンタグ作成をスキップします。ワークフローは引き続きマイルストーンアーティファクトと状態を更新します。

**要件:**
- REQ-MILESTONE-TAG-01: 設定が欠如している場合、自動タグ作成を維持しなければならない。
- REQ-MILESTONE-TAG-02: 既存のタグの衝突はタグを上書きする代わりに明確に失敗しなければならない。
- REQ-MILESTONE-TAG-03: タグ作成の無効化はマイルストーンアーカイブをスキップしてはならない。

**参照:** [設定リファレンス](../CONFIGURATION.md#git-branching)

---

### 142. 構造化 JSON エラーモード

**CLI:** `msd-tools --json-errors`

**目的:** 自動化呼び出し元に安定した機械可読エラーエンベロープを提供します。

**動作:** `--json-errors` 下で失敗するコマンドは、散文のみの stderr の代わりに、エラーの種類、メッセージ、コマンドコンテキスト、および終了マッピングを含む構造化された `ok: false` ペイロードを返します。

**要件:**
- REQ-JSON-ERRORS-01: 不明なコマンド、検証エラー、タイムアウト、ネイティブ失敗、フォールバック失敗、および内部エラーは正規エラーの種類にマッピングされなければならない。
- REQ-JSON-ERRORS-02: CLI 終了コードマッピングは自動化呼び出し元に対して安定して維持されなければならない。
- REQ-JSON-ERRORS-03: 人間可読出力は `--json-errors` が存在しない場合にデフォルトのまま。

---

## 関連

- [コマンド](../COMMANDS.md)
- [設定](../CONFIGURATION.md)
- [ドキュメントインデックス](../README.md)

**参照:** [JSON エラーモード](../json-errors.md)