refactor: hard-fork GSD -> MSD (Make Software Done)
Mechanical rename produced by scripts/msd-rename.cjs: gsd/Gsd/GSD -> msd/Msd/MSD across contents and paths, upstream package/repo coordinates -> @golem15/msd-core and golem15com/msd-core. Deep links into upstream history, sibling upstream packages, the GSD-2 import feature, CHANGELOG.md and .changeset/ are kept as-is. Hand edits on top: MSD block-letter banner and logos, LICENSE copyright line, package/plugin identity, regenerated lockfile, install-tree fixtures, derived registries and benchmark baseline; migration checksum baseline re-locked (MSD keeps its own install state, so no install had applied the old sums); sort-order and regex-escaped expectations in tests adjusted.
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# CONTEXT.md スキーマリファレンス
|
||||
|
||||
フェーズごとの `CONTEXT.md` は、`/gsd-discuss-phase` 中に収集された実装上の意思決定を格納する GSD Core のキャリアファイルです。リサーチエージェントとプランニングエージェントの両方にとって主要な上流インプットです。このページではそのスキーマを説明します。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
フェーズごとの `CONTEXT.md` は、`/msd-discuss-phase` 中に収集された実装上の意思決定を格納する MSD Core のキャリアファイルです。リサーチエージェントとプランニングエージェントの両方にとって主要な上流インプットです。このページではそのスキーマを説明します。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
例: `.planning/phases/03-post-feed/03-CONTEXT.md`
|
||||
|
||||
このファイルは `gsd-core/workflows/discuss-phase.md` の `write_context`(または PRD / ADR インジェストのエクスプレスパス)によって生成されます。通常の運用中は手動で編集されません — discuss-phase ワークフローが書き込み、下流エージェントが封印された信頼できる情報源として読み取ります。
|
||||
このファイルは `msd-core/workflows/discuss-phase.md` の `write_context`(または PRD / ADR インジェストのエクスプレスパス)によって生成されます。通常の運用中は手動で編集されません — discuss-phase ワークフローが書き込み、下流エージェントが封印された信頼できる情報源として読み取ります。
|
||||
|
||||
---
|
||||
|
||||
@@ -39,12 +39,12 @@
|
||||
|
||||
| ブロック | 用途 | 設定元 | 参照先 |
|
||||
|---|---|---|---|
|
||||
| `<domain>` | フェーズの境界を示します — このフェーズが何を提供し、何が明示的にスコープ外かを述べます。プランニングと実行を通じてスコープガードレールを固定します。 | `discuss-phase`(ROADMAP.md のフェーズゴールから) | `gsd-planner`、`gsd-plan-checker`(スコープ準拠) |
|
||||
| `<spec_lock>` | `check_spec` ステップが `*-SPEC.md` を発見した場合のみ存在します。ロックされた要件数とスコープ境界をリストします。エージェントは完全な要件を得るために直接 `SPEC.md` を読むよう指示されます。 | `discuss-phase`(条件付き) | `gsd-planner`(要件をここで再読みせず SPEC.md を読む) |
|
||||
| `<decisions>` | ディスカッションから収集された実装上の意思決定。`D-NN` 識別子でキー付け。カテゴリは固定の分類ではなく実際に議論された内容から生まれます。ユーザーが委任した領域のための `Claude's Discretion` サブセクションを含みます。 | `discuss-phase`(インタラクティブなディスカッション) | `gsd-planner`(ロックされた決定は必ず実装する)、`gsd-plan-checker`(ディメンション7準拠) |
|
||||
| `<canonical_refs>` | このフェーズに関連するすべての仕様、ADR、機能ドキュメント、設計ドキュメントへの完全な相対パス。必須 — すべての CONTEXT.md にこのセクションが必要です。エージェントはプランニングまたは実装の前にリストされたファイルを読む必要があります。 | `discuss-phase`(ROADMAP.md の参照 + ディスカッション中のユーザー参照 + コードベーススカウトから集積) | `gsd-phase-researcher`、`gsd-planner` |
|
||||
| `<code_context>` | `scout_codebase` ステップで発見された再利用可能なアセット、確立されたパターン、統合ポイント。エージェントを再実装ではなく既存コードに向けるためのガイダンス。 | `discuss-phase`(コードベーススカウト) | `gsd-planner`、`gsd-phase-researcher` |
|
||||
| `<specifics>` | ディスカッション中に verbatim で収集された「こんな感じにしたい」という具体的な参照、製品比較、特定の例。 | `discuss-phase`(自由形式のユーザー入力) | `gsd-planner` |
|
||||
| `<domain>` | フェーズの境界を示します — このフェーズが何を提供し、何が明示的にスコープ外かを述べます。プランニングと実行を通じてスコープガードレールを固定します。 | `discuss-phase`(ROADMAP.md のフェーズゴールから) | `msd-planner`、`msd-plan-checker`(スコープ準拠) |
|
||||
| `<spec_lock>` | `check_spec` ステップが `*-SPEC.md` を発見した場合のみ存在します。ロックされた要件数とスコープ境界をリストします。エージェントは完全な要件を得るために直接 `SPEC.md` を読むよう指示されます。 | `discuss-phase`(条件付き) | `msd-planner`(要件をここで再読みせず SPEC.md を読む) |
|
||||
| `<decisions>` | ディスカッションから収集された実装上の意思決定。`D-NN` 識別子でキー付け。カテゴリは固定の分類ではなく実際に議論された内容から生まれます。ユーザーが委任した領域のための `Claude's Discretion` サブセクションを含みます。 | `discuss-phase`(インタラクティブなディスカッション) | `msd-planner`(ロックされた決定は必ず実装する)、`msd-plan-checker`(ディメンション7準拠) |
|
||||
| `<canonical_refs>` | このフェーズに関連するすべての仕様、ADR、機能ドキュメント、設計ドキュメントへの完全な相対パス。必須 — すべての CONTEXT.md にこのセクションが必要です。エージェントはプランニングまたは実装の前にリストされたファイルを読む必要があります。 | `discuss-phase`(ROADMAP.md の参照 + ディスカッション中のユーザー参照 + コードベーススカウトから集積) | `msd-phase-researcher`、`msd-planner` |
|
||||
| `<code_context>` | `scout_codebase` ステップで発見された再利用可能なアセット、確立されたパターン、統合ポイント。エージェントを再実装ではなく既存コードに向けるためのガイダンス。 | `discuss-phase`(コードベーススカウト) | `msd-planner`、`msd-phase-researcher` |
|
||||
| `<specifics>` | ディスカッション中に verbatim で収集された「こんな感じにしたい」という具体的な参照、製品比較、特定の例。 | `discuss-phase`(自由形式のユーザー入力) | `msd-planner` |
|
||||
| `<deferred>` | ディスカッション中に浮上したが別のフェーズに属するアイデア。失われないよう保存されます。Todos がレビューされたがスコープに含まれなかった場合は `Reviewed Todos` サブセクションを含みます。 | `discuss-phase`(スコープクリープのリダイレクト) | 自動化されたエージェントには使用されない; 人間の参照のみ |
|
||||
|
||||
---
|
||||
@@ -107,7 +107,7 @@ No external specs — requirements fully captured in decisions above
|
||||
|
||||
## SPEC.md との統合
|
||||
|
||||
フェーズをディスカッションする前に `/gsd-spec-phase` が実行された場合、`check_spec` ステップが `*-SPEC.md` ファイルを見つけ `<spec_lock>` を有効にします:
|
||||
フェーズをディスカッションする前に `/msd-spec-phase` が実行された場合、`check_spec` ステップが `*-SPEC.md` ファイルを見つけ `<spec_lock>` を有効にします:
|
||||
|
||||
```markdown
|
||||
<spec_lock>
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# PLAN.md スキーマリファレンス
|
||||
|
||||
フェーズごとの `PLAN.md` は GSD Core の実行可能な作業単位です — エグゼキューターエージェントに何を構築し、正しく構築されたことをどのように検証するかを正確に伝える構造化ドキュメントです。このページではそのスキーマを説明します。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
フェーズごとの `PLAN.md` は MSD Core の実行可能な作業単位です — エグゼキューターエージェントに何を構築し、正しく構築されたことをどのように検証するかを正確に伝える構造化ドキュメントです。このページではそのスキーマを説明します。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
例: `.planning/phases/03-post-feed/03-02-PLAN.md`(フェーズ3、プラン2)。
|
||||
|
||||
プランは `gsd-planner` エージェント(`/gsd-plan-phase` によって起動)が生成し、`execute-phase` が使用します。通常、フェーズには1〜4つのプランが含まれます。フェーズ内のプランは実行ウェーブに割り当てられ、独立した作業が並行して実行されます。
|
||||
プランは `msd-planner` エージェント(`/msd-plan-phase` によって起動)が生成し、`execute-phase` が使用します。通常、フェーズには1〜4つのプランが含まれます。フェーズ内のプランは実行ウェーブに割り当てられ、独立した作業が並行して実行されます。
|
||||
|
||||
---
|
||||
|
||||
@@ -66,7 +66,7 @@ must_haves:
|
||||
| `phase` | はい | string | フェーズ識別子。例: `03-post-feed`。 |
|
||||
| `plan` | はい | string | フェーズ内のプラン番号。例: `02`。 |
|
||||
| `type` | はい | `execute` または `tdd` | 標準プランは `execute`; テスト駆動プラン(実装前にテストを書く)は `tdd`。 |
|
||||
| `wave` | はい | integer | 実行ウェーブ。ウェーブ1のプランは並行実行されます(依存なし)。ウェーブ2以降のプランは前のウェーブのすべてのプランが完了するまで待機します。`gsd-planner` がプランニング時に事前計算します。 |
|
||||
| `wave` | はい | integer | 実行ウェーブ。ウェーブ1のプランは並行実行されます(依存なし)。ウェーブ2以降のプランは前のウェーブのすべてのプランが完了するまで待機します。`msd-planner` がプランニング時に事前計算します。 |
|
||||
| `depends_on` | はい | プラン ID の配列 | このプランが待機する必要があるプランの一覧。空配列 = ウェーブ1。例: `["03-01"]` はこのプランがフェーズ3のプラン01の後に実行されることを意味します。 |
|
||||
| `files_modified` | はい | パスの配列 | このプランが作成または変更するすべてのファイル。プランチェッカーが同一ウェーブのファイル競合を検出するため、および execute-phase がマージ追跡のために使用します。 |
|
||||
| `autonomous` | はい | boolean | すべてのタスクが `auto` タイプの場合に `true`。プランに人間の操作が必要な `checkpoint:*` タスクが含まれる場合は `false`。 |
|
||||
@@ -78,7 +78,7 @@ must_haves:
|
||||
|
||||
## `must_haves` フィールド
|
||||
|
||||
`must_haves` はフェーズゴールを達成するために観察可能に真でなければならないことを記録します。プランニング中に導出され、実行後に `gsd-verifier` エージェントによって検証されます。
|
||||
`must_haves` はフェーズゴールを達成するために観察可能に真でなければならないことを記録します。プランニング中に導出され、実行後に `msd-verifier` エージェントによって検証されます。
|
||||
|
||||
### サブフィールド
|
||||
|
||||
@@ -122,8 +122,8 @@ Output: PostFeed and PostCard components wired to /api/feed.
|
||||
|
||||
```xml
|
||||
<execution_context>
|
||||
@~/.claude/gsd-core/workflows/execute-plan.md
|
||||
@~/.claude/gsd-core/templates/summary.md
|
||||
@~/.claude/msd-core/workflows/execute-plan.md
|
||||
@~/.claude/msd-core/templates/summary.md
|
||||
</execution_context>
|
||||
```
|
||||
|
||||
@@ -194,7 +194,7 @@ Output: PostFeed and PostCard components wired to /api/feed.
|
||||
|
||||
## プラン品質ディメンション
|
||||
|
||||
`gsd-plan-checker` エージェントは実行開始前に12のディメンションにわたってすべての PLAN.md をレビューします。BLOCKER 深刻度のチェックに失敗したプランは `gsd-planner` に差し戻されます(最大3回のイテレーション):
|
||||
`msd-plan-checker` エージェントは実行開始前に12のディメンションにわたってすべての PLAN.md をレビューします。BLOCKER 深刻度のチェックに失敗したプランは `msd-planner` に差し戻されます(最大3回のイテレーション):
|
||||
|
||||
| ディメンション | チェック内容 |
|
||||
|---|---|
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# プランニングアーティファクト リファレンス
|
||||
|
||||
`.planning/` ディレクトリはプロジェクトの GSD Core 共有メモリです。すべてのワークフローはここから読み取り、書き込み、意思決定の監査可能な証跡を残します。このページではすべてのファイル、その目的、どのコマンドが生成・使用するかをマッピングします。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
`.planning/` ディレクトリはプロジェクトの MSD Core 共有メモリです。すべてのワークフローはここから読み取り、書き込み、意思決定の監査可能な証跡を残します。このページではすべてのファイル、その目的、どのコマンドが生成・使用するかをマッピングします。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -50,32 +50,32 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | プロジェクトの正規アイデンティティ: 概要、対象ユーザー、コアバリュー、要件、制約、主要な意思決定。プロダクトの進化に伴いプロジェクトライフサイクル全体を通じて更新されます。 |
|
||||
| **生成元** | `/gsd-new-project`(初回作成、`/gsd-onboard` のハンドオフを含む); 意思決定が検証されると `/gsd-complete-milestone` によって更新されます。 |
|
||||
| **参照先** | すべてのプランニングワークフロー; `gsd-phase-researcher`、`gsd-planner`(コンテキスト); `discuss-phase`(過去の意思決定); `gsd-plan-checker`(プロジェクト制約)。 |
|
||||
| **生成元** | `/msd-new-project`(初回作成、`/msd-onboard` のハンドオフを含む); 意思決定が検証されると `/msd-complete-milestone` によって更新されます。 |
|
||||
| **参照先** | すべてのプランニングワークフロー; `msd-phase-researcher`、`msd-planner`(コンテキスト); `discuss-phase`(過去の意思決定); `msd-plan-checker`(プロジェクト制約)。 |
|
||||
|
||||
### `ROADMAP.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | マイルストーンおよびフェーズ一覧。ゴール、要件 ID、成功基準、フェーズごとの正規リファレンスを含みます。プロジェクトが何をどの順序で構築するかに関する唯一の信頼できる情報源です。 |
|
||||
| **生成元** | `/gsd-new-project`(初回作成、`/gsd-onboard` のハンドオフを含む); `/gsd-phase --insert` および `/gsd-complete-milestone` によって更新されます。 |
|
||||
| **参照先** | `/gsd-discuss-phase`、`/gsd-plan-phase`、`/gsd-execute-phase`; フェーズ情報を必要とするすべてのオーケストレーションコマンド; `gsd-planner`、`gsd-plan-checker`、`gsd-phase-researcher`。 |
|
||||
| **生成元** | `/msd-new-project`(初回作成、`/msd-onboard` のハンドオフを含む); `/msd-phase --insert` および `/msd-complete-milestone` によって更新されます。 |
|
||||
| **参照先** | `/msd-discuss-phase`、`/msd-plan-phase`、`/msd-execute-phase`; フェーズ情報を必要とするすべてのオーケストレーションコマンド; `msd-planner`、`msd-plan-checker`、`msd-phase-researcher`。 |
|
||||
|
||||
### `REQUIREMENTS.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 番号付きのチェック可能な受け入れ基準。各要件はロードマップフェーズにマッピングされる ID(例: `AUTH-01`)を持ちます。フェーズが実行されると要件を完了済みとしてマークします。 |
|
||||
| **生成元** | `/gsd-new-project`(初回作成、`/gsd-onboard` のハンドオフを含む); `execute-phase` によって要件が完了済みとしてマークされます。 |
|
||||
| **参照先** | `gsd-planner`(プランはすべてのフェーズ要件 ID に対処しなければならない); `gsd-plan-checker` ディメンション1(要件カバレッジ); `discuss-phase`(過去の要件)。 |
|
||||
| **生成元** | `/msd-new-project`(初回作成、`/msd-onboard` のハンドオフを含む); `execute-phase` によって要件が完了済みとしてマークされます。 |
|
||||
| **参照先** | `msd-planner`(プランはすべてのフェーズ要件 ID に対処しなければならない); `msd-plan-checker` ディメンション1(要件カバレッジ); `discuss-phase`(過去の要件)。 |
|
||||
|
||||
### `STATE.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 現在地を追跡するリビングドキュメント — 現在のフェーズとプラン、進捗指標、蓄積された意思決定、セッション継続性ノート。すべてのワークフロー実行の開始時に読み込まれます。重要なアクションのたびに更新されます。 |
|
||||
| **生成元** | `/gsd-new-project`(初回作成、`/gsd-onboard` のハンドオフを含む); すべてのフェーズワークフロー、`/gsd-pause-work`、`/gsd-resume-work` によって継続的に更新されます。 |
|
||||
| **参照先** | すべてのオーケストレーションワークフロー; `/gsd-progress`; `/gsd-quick` 経由のアドホックタスク実行; `gsd-planner` および `gsd-phase-researcher`(プロジェクトの意思決定)。 |
|
||||
| **生成元** | `/msd-new-project`(初回作成、`/msd-onboard` のハンドオフを含む); すべてのフェーズワークフロー、`/msd-pause-work`、`/msd-resume-work` によって継続的に更新されます。 |
|
||||
| **参照先** | すべてのオーケストレーションワークフロー; `/msd-progress`; `/msd-quick` 経由のアドホックタスク実行; `msd-planner` および `msd-phase-researcher`(プロジェクトの意思決定)。 |
|
||||
|
||||
完全なフィールドリファレンスは [STATE.md スキーマ](state-md.md) を参照してください。
|
||||
|
||||
@@ -84,8 +84,8 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | ワークフロー設定: モデルプロファイル、リサーチおよびプランチェッカーのトグル、Git ブランチング戦略、Nyquist バリデーション、並列化設定、エージェントごとのモデルオーバーライド。 |
|
||||
| **生成元** | `/gsd-new-project`(初回作成); `/gsd-settings`(インタラクティブ編集)。 |
|
||||
| **参照先** | すべてのワークフローとサブエージェント — `gsd-tools query config-get` 経由で初期化時に読み込まれます。 |
|
||||
| **生成元** | `/msd-new-project`(初回作成); `/msd-settings`(インタラクティブ編集)。 |
|
||||
| **参照先** | すべてのワークフローとサブエージェント — `msd-tools query config-get` 経由で初期化時に読み込まれます。 |
|
||||
|
||||
完全なスキーマは [CONFIGURATION](../../CONFIGURATION.md) を参照してください。
|
||||
|
||||
@@ -93,17 +93,17 @@
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | ブラウンフィールドオンボーディングの索引。アーティファクト状態、コードベースマッピングの完了状況、初回セットアップ後に推奨される次の GSD コマンドを記録します。 |
|
||||
| **生成元** | `PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md` がすべて存在した後の `/gsd-onboard`。 |
|
||||
| **参照先** | 初回セットアップを確認する人間、および既存オンボーディング状態を確認する今後の `/gsd-onboard` 実行。 |
|
||||
| **用途** | ブラウンフィールドオンボーディングの索引。アーティファクト状態、コードベースマッピングの完了状況、初回セットアップ後に推奨される次の MSD コマンドを記録します。 |
|
||||
| **生成元** | `PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md` がすべて存在した後の `/msd-onboard`。 |
|
||||
| **参照先** | 初回セットアップを確認する人間、および既存オンボーディング状態を確認する今後の `/msd-onboard` 実行。 |
|
||||
|
||||
### `MILESTONES.md`(オプション)
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 完了したマイルストーンの履歴記録。各マイルストーンのクローズ時に追記されます。何がいつリリースされたかのアーカイブスナップショットを提供します。 |
|
||||
| **生成元** | `/gsd-complete-milestone`。 |
|
||||
| **参照先** | `/gsd-audit-milestone`; 人間によるレビュー。 |
|
||||
| **生成元** | `/msd-complete-milestone`。 |
|
||||
| **参照先** | `/msd-audit-milestone`; 人間によるレビュー。 |
|
||||
|
||||
### `DECISIONS-INDEX.md`(オプション)
|
||||
|
||||
@@ -118,8 +118,8 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 作業が中断されたときに書き込まれる機械可読な一時停止状態。再開ポイント、進行中のコンテキスト、継続指示を含みます。再開時に一度だけ使用されます。 |
|
||||
| **生成元** | `/gsd-pause-work`。 |
|
||||
| **参照先** | `/gsd-resume-work`。 |
|
||||
| **生成元** | `/msd-pause-work`。 |
|
||||
| **参照先** | `/msd-resume-work`。 |
|
||||
|
||||
---
|
||||
|
||||
@@ -132,8 +132,8 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | プランニング開始前に収集された実装上の意思決定。フェーズ境界(`<domain>`)、`D-NN` 識別子付きのロックされた意思決定(`<decisions>`)、正規のドキュメント参照(`<canonical_refs>`)、既存のコードのインサイト(`<code_context>`)、具体的な参考例(`<specifics>`)、延期されたアイデア(`<deferred>`)を含みます。 |
|
||||
| **生成元** | `/gsd-discuss-phase`(インタラクティブなディスカッションまたは PRD/ADR エクスプレスパス)。 |
|
||||
| **参照先** | `gsd-phase-researcher`(調査すべき内容); `gsd-planner`(ロックされた意思決定); `gsd-plan-checker` ディメンション7(コンテキスト準拠)。 |
|
||||
| **生成元** | `/msd-discuss-phase`(インタラクティブなディスカッションまたは PRD/ADR エクスプレスパス)。 |
|
||||
| **参照先** | `msd-phase-researcher`(調査すべき内容); `msd-planner`(ロックされた意思決定); `msd-plan-checker` ディメンション7(コンテキスト準拠)。 |
|
||||
|
||||
完全なフィールドリファレンスは [CONTEXT.md スキーマ](context-md.md) を参照してください。
|
||||
|
||||
@@ -142,7 +142,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | discuss-phase セッションの人間可読な監査証跡: 議論された領域、提示されたオプション、行われた選択、延期されたアイデア、Claude の裁量に任せられた項目。自動化されたワークフローには使用されません。 |
|
||||
| **生成元** | `/gsd-discuss-phase`(`git_commit` ステップ)。 |
|
||||
| **生成元** | `/msd-discuss-phase`(`git_commit` ステップ)。 |
|
||||
| **参照先** | 人間によるレビュー; 振り返り。 |
|
||||
|
||||
### `<NN>-RESEARCH.md`
|
||||
@@ -150,32 +150,32 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | プランニング前に生成される技術リサーチの所見。「このフェーズをうまくプランニングするために何を知る必要があるか?」という問いに答えます — ドメイン分析、パターン、リスク、Architectural Responsibility Map、Validation Architecture セクション(Nyquist ゲートで使用)をカバーします。 |
|
||||
| **生成元** | `/gsd-plan-phase`(`gsd-phase-researcher` エージェント経由)。 |
|
||||
| **参照先** | `gsd-planner`(プランニングインプット); `gsd-plan-checker` ディメンション7c(ティア準拠)、ディメンション8(Nyquist)、ディメンション11(リサーチ解決); `gsd-pattern-mapper`(ファイルリストのソース)。 |
|
||||
| **生成元** | `/msd-plan-phase`(`msd-phase-researcher` エージェント経由)。 |
|
||||
| **参照先** | `msd-planner`(プランニングインプット); `msd-plan-checker` ディメンション7c(ティア準拠)、ディメンション8(Nyquist)、ディメンション11(リサーチ解決); `msd-pattern-mapper`(ファイルリストのソース)。 |
|
||||
|
||||
### `<NN>-VALIDATION.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | RESEARCH.md の `## Validation Architecture` セクションから導出された Nyquist インスパイアのバリデーション戦略。プランが遵守しなければならない自動テストカバレッジ要件を指定します。 |
|
||||
| **生成元** | `/gsd-plan-phase`(ステップ5.5、`workflow.nyquist_validation` が有効で RESEARCH.md に Validation Architecture セクションが含まれる場合)。 |
|
||||
| **参照先** | `gsd-plan-checker` ディメンション8(チェック8e ゲート — Nyquist チェック進行前に存在しなければならない); `gsd-verifier`。 |
|
||||
| **生成元** | `/msd-plan-phase`(ステップ5.5、`workflow.nyquist_validation` が有効で RESEARCH.md に Validation Architecture セクションが含まれる場合)。 |
|
||||
| **参照先** | `msd-plan-checker` ディメンション8(チェック8e ゲート — Nyquist チェック進行前に存在しなければならない); `msd-verifier`。 |
|
||||
|
||||
### `<NN>-PATTERNS.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | `gsd-pattern-mapper` によって生成されたコードベースアナログマップ。このフェーズで作成または変更される各ファイルに対して、最も近い既存のアナログを特定し、ファイルの役割とデータフローを分類し、具体的なコード抜粋を抽出します。プランナーを一貫したパターンに向けます。 |
|
||||
| **生成元** | `/gsd-plan-phase`(`gsd-pattern-mapper` エージェント経由、オプション; `workflow.pattern_mapper: false` の場合はスキップ)。 |
|
||||
| **参照先** | `gsd-planner`(パターンガイダンス); `gsd-plan-checker` ディメンション12(パターン準拠)。 |
|
||||
| **用途** | `msd-pattern-mapper` によって生成されたコードベースアナログマップ。このフェーズで作成または変更される各ファイルに対して、最も近い既存のアナログを特定し、ファイルの役割とデータフローを分類し、具体的なコード抜粋を抽出します。プランナーを一貫したパターンに向けます。 |
|
||||
| **生成元** | `/msd-plan-phase`(`msd-pattern-mapper` エージェント経由、オプション; `workflow.pattern_mapper: false` の場合はスキップ)。 |
|
||||
| **参照先** | `msd-planner`(パターンガイダンス); `msd-plan-checker` ディメンション12(パターン準拠)。 |
|
||||
|
||||
### `<NN>-<PP>-PLAN.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | フェーズ内の単一作業単位の実行可能プラン。YAML フロントマター(ウェーブ、依存関係、ファイル、要件、`must_haves`)、目的、コンテキスト参照、`<read_first>`、`<action>`、`<verify>`、`<acceptance_criteria>` フィールドを持つ XML 構造化タスク、検証基準を含みます。 |
|
||||
| **生成元** | `/gsd-plan-phase`(`gsd-planner` エージェント経由)。プランごとに1ファイル — 例: `03-02-PLAN.md` はフェーズ3、プラン2。 |
|
||||
| **参照先** | `/gsd-execute-phase`(エグゼキューターエージェントがプランを読んでタスクを実行); `gsd-plan-checker`(実行前の品質レビュー); `gsd-verifier`(実行後の検証のために `must_haves` を読む)。 |
|
||||
| **生成元** | `/msd-plan-phase`(`msd-planner` エージェント経由)。プランごとに1ファイル — 例: `03-02-PLAN.md` はフェーズ3、プラン2。 |
|
||||
| **参照先** | `/msd-execute-phase`(エグゼキューターエージェントがプランを読んでタスクを実行); `msd-plan-checker`(実行前の品質レビュー); `msd-verifier`(実行後の検証のために `must_haves` を読む)。 |
|
||||
|
||||
完全なフィールドリファレンスは [PLAN.md スキーマ](plan-md.md) を参照してください。
|
||||
|
||||
@@ -185,30 +185,30 @@
|
||||
|---|---|
|
||||
| **用途** | プラン完了後に書き込まれる実行記録。構築された内容、プランからの逸脱、受け入れ基準に対するセルフチェック、フェーズの依存グラフを記録します。 |
|
||||
| **生成元** | `execute-phase` エグゼキューターエージェント(各プランの実行終了時に書き込まれます)。 |
|
||||
| **参照先** | `/gsd-progress`(フェーズステータス); `gsd-planner`(後続のプランが以前のプラン出力への真の依存を持つ場合); `milestone-summary`。 |
|
||||
| **参照先** | `/msd-progress`(フェーズステータス); `msd-planner`(後続のプランが以前のプラン出力への真の依存を持つ場合); `milestone-summary`。 |
|
||||
|
||||
### `<NN>-VERIFICATION.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | フェーズゴール検証レポート。実行後に実際のコードベースに対してすべてのプランの `must_haves.truths`、`must_haves.artifacts`、`must_haves.key_links` を確認します。`status: passed | gaps_found | human_needed` を記録します。 |
|
||||
| **生成元** | `/gsd-verify-work`(または `/gsd-execute-phase` 内の検証ステップ)。 |
|
||||
| **参照先** | `plan-phase` クローズドフェーズゲート(`status: passed` の VERIFICATION.md はフェーズを `Complete` としてマークし、`--force` なしの再プランニングをブロックする); `/gsd-progress`; 人間によるレビュー。 |
|
||||
| **生成元** | `/msd-verify-work`(または `/msd-execute-phase` 内の検証ステップ)。 |
|
||||
| **参照先** | `plan-phase` クローズドフェーズゲート(`status: passed` の VERIFICATION.md はフェーズを `Complete` としてマークし、`--force` なしの再プランニングをブロックする); `/msd-progress`; 人間によるレビュー。 |
|
||||
|
||||
### `<NN>-UAT.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 永続的な UAT セッション追跡。ライブ UAT セッション全体を通じて各テストケース、期待される観察可能な動作、結果、開発者のレスポンスを記録します。YAML フロントマター(`status`、`phase`、`source`、タイムスタンプ)を持ちます。 |
|
||||
| **生成元** | `/gsd-audit-uat`(インタラクティブな UAT セッション)。 |
|
||||
| **参照先** | `/gsd-audit-uat`(以前の UAT セッションの再開)。 |
|
||||
| **生成元** | `/msd-audit-uat`(インタラクティブな UAT セッション)。 |
|
||||
| **参照先** | `/msd-audit-uat`(以前の UAT セッションの再開)。 |
|
||||
|
||||
### `.continue-here.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | フェーズの作業が一時停止されたときに書き込まれる人間可読な再開指示。再開エージェントのためのコンテキストを含みます: 重要なアンチパターン、ブロッキング問題、必要な参照、再開するための正確なコマンド。 |
|
||||
| **生成元** | `/gsd-pause-work`。 |
|
||||
| **生成元** | `/msd-pause-work`。 |
|
||||
| **参照先** | フェーズで開始するすべてのワークフロー — `discuss-phase` と `plan-phase` は両方ともエントリ時にこのファイルを確認し、処理を進める前にエージェントが `blocking` アンチパターンへの理解を示すことを要求します。 |
|
||||
|
||||
---
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
# STATE.md スキーマリファレンス
|
||||
|
||||
`STATE.md` は GSD Core のプロジェクト記憶ファイルです — プロジェクトの現在地、直近の作業内容、次に実行すべきコマンドを記録する単一の Markdown ドキュメントです。このページではそのスキーマを説明します。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
`STATE.md` は MSD Core のプロジェクト記憶ファイルです — プロジェクトの現在地、直近の作業内容、次に実行すべきコマンドを記録する単一の Markdown ドキュメントです。このページではそのスキーマを説明します。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
|
||||
---
|
||||
|
||||
## 概要
|
||||
|
||||
GSD Core で管理するプロジェクトはすべて `.planning/STATE.md` に `STATE.md` を1つ保持します。このファイルはすべてのワークフロー開始時に読み込まれ、重要なアクションのたびに書き込まれます。ファイルは以下を組み合わせた構成です:
|
||||
MSD Core で管理するプロジェクトはすべて `.planning/STATE.md` に `STATE.md` を1つ保持します。このファイルはすべてのワークフロー開始時に読み込まれ、重要なアクションのたびに書き込まれます。ファイルは以下を組み合わせた構成です:
|
||||
|
||||
- **YAML フロントマター** — ステータスラインフック(`parseStateMd`)および `gsd-tools state` コマンドが読み取る機械可読フィールド。
|
||||
- **YAML フロントマター** — ステータスラインフック(`parseStateMd`)および `msd-tools state` コマンドが読み取る機械可読フィールド。
|
||||
- **Markdown 本文** — 現在の進捗、蓄積されたコンテキスト、セッション継続性、パフォーマンス指標を記述する人間可読なセクション。
|
||||
|
||||
ファイルは意図的にコンパクトに保たれています(目標: 100行以内)。プロジェクト状態のダイジェストであり、アーカイブではありません。
|
||||
@@ -17,13 +17,13 @@ GSD Core で管理するプロジェクトはすべて `.planning/STATE.md` に
|
||||
|
||||
## YAML フロントマター
|
||||
|
||||
フロントマターはファイルの先頭にある `---` デリミタの間に記述します。`gsd_state_version` と `status` 以外のフィールドはすべてオプションで、データが未取得の場合は省略できます。
|
||||
フロントマターはファイルの先頭にある `---` デリミタの間に記述します。`msd_state_version` と `status` 以外のフィールドはすべてオプションで、データが未取得の場合は省略できます。
|
||||
|
||||
### 注釈付きサンプル
|
||||
|
||||
```yaml
|
||||
---
|
||||
gsd_state_version: '1.0'
|
||||
msd_state_version: '1.0'
|
||||
milestone: v2.0
|
||||
milestone_name: Code Quality
|
||||
status: executing
|
||||
@@ -56,7 +56,7 @@ paused_at: null
|
||||
|
||||
| フィールド | 型 | 設定タイミング | 用途 |
|
||||
|---|---|---|---|
|
||||
| `gsd_state_version` | string (`'1.0'`) | 常時 | スキーマバージョン。`syncStateFrontmatter` が最初の `state.*` 呼び出し時に書き込む。 |
|
||||
| `msd_state_version` | string (`'1.0'`) | 常時 | スキーマバージョン。`syncStateFrontmatter` が最初の `state.*` 呼び出し時に書き込む。 |
|
||||
| `milestone` | string (例: `v2.0`) | マイルストーン設定時 | 現在のマイルストーンバージョン。プロジェクト設定から読み取る。 |
|
||||
| `milestone_name` | string | マイルストーン設定時 | 人間可読なマイルストーンラベル (例: `Code Quality`)。 |
|
||||
| `status` | string | 常時 | 現在のライフサイクルステージ。`normalizeStateStatus()` によって正規化される — [ステータス値](#ステータス値) 参照。 |
|
||||
@@ -83,7 +83,7 @@ paused_at: null
|
||||
|
||||
| フィールド | 多重度 |
|
||||
|---|---|
|
||||
| `gsd_state_version` | one |
|
||||
| `msd_state_version` | one |
|
||||
| `milestone` | optional |
|
||||
| `milestone_name` | optional |
|
||||
| `current_phase` | optional |
|
||||
@@ -105,7 +105,7 @@ paused_at: null
|
||||
|
||||
### ステータス値
|
||||
|
||||
`gsd-core/bin/lib/state-document.cjs` の `normalizeStateStatus()` が本文の生テキストを以下の正規値にマッピングします:
|
||||
`msd-core/bin/lib/state-document.cjs` の `normalizeStateStatus()` が本文の生テキストを以下の正規値にマッピングします:
|
||||
|
||||
| 正規値 | マッチするテキスト(大文字小文字不問) |
|
||||
|---|---|
|
||||
@@ -121,10 +121,10 @@ paused_at: null
|
||||
|
||||
| コマンド | 実行中の `status` |
|
||||
|---|---|
|
||||
| `/gsd-discuss-phase` | `discussing` |
|
||||
| `/gsd-plan-phase` | `planning` |
|
||||
| `/gsd-execute-phase` | `executing` |
|
||||
| `/gsd-verify-work` | `verifying` |
|
||||
| `/msd-discuss-phase` | `discussing` |
|
||||
| `/msd-plan-phase` | `planning` |
|
||||
| `/msd-execute-phase` | `executing` |
|
||||
| `/msd-verify-work` | `verifying` |
|
||||
|
||||
<!-- STATE-MD-SCHEMA:START:status-lifecycle — generated by scripts/gen-state-md-docs.cjs from src/state-md-schema.cts; do not edit by hand -->
|
||||
### ステータスライフサイクル (ADR-2207)
|
||||
@@ -145,7 +145,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
|
||||
## ステータスライン描画シーン
|
||||
|
||||
`hooks/gsd-statusline.js` の `formatGsdState()` がパース済みフロントマターを読み取り、**最初にマッチしたシーン** を出力します。新しいライフサイクルフィールドが適用されない場合は、v1.38.x から一切変更なくオリジナルのフォーマットにフォールスルーします。
|
||||
`hooks/msd-statusline.js` の `formatMsdState()` がパース済みフロントマターを読み取り、**最初にマッチしたシーン** を出力します。新しいライフサイクルフィールドが適用されない場合は、v1.38.x から一切変更なくオリジナルのフォーマットにフォールスルーします。
|
||||
|
||||
| シーン | トリガー | 表示例 |
|
||||
|---|---|---|
|
||||
@@ -154,7 +154,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
| **3. マイルストーン完了** | `percent` が `100` または `completed_phases == total_phases` | `v2.0 [██████████] 100% · milestone complete` |
|
||||
| **4. デフォルトフォールバック** | 上記のいずれにも該当しない | `v1.9 Code Quality · executing · ph 1/5`(既存フォーマット) |
|
||||
|
||||
**シーン優先度:** `active_phase` と `next_action` が両方設定されている場合、シーン1が優先されます — オーケストレーターが実行中であるため「次の推奨」は誤解を招くためです。この優先度は `formatGsdState()` のチェック順序によって強制され、`tests/gsd-statusline.test.cjs` の `"scene priority"` スイートでカバーされています。
|
||||
**シーン優先度:** `active_phase` と `next_action` が両方設定されている場合、シーン1が優先されます — オーケストレーターが実行中であるため「次の推奨」は誤解を招くためです。この優先度は `formatMsdState()` のチェック順序によって強制され、`tests/msd-statusline.test.cjs` の `"scene priority"` スイートでカバーされています。
|
||||
|
||||
進捗バー(`[██░░░░░░░░] 20%`)はフロントマターに `progress.percent` が存在する場合のみマイルストーンセグメントに追加されます。不在の場合はバーは表示されません。
|
||||
|
||||
@@ -162,7 +162,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
|
||||
## フロントマターパースの制約
|
||||
|
||||
ステータスラインフックは正規表現ベースのパース(完全な YAML ライブラリを使用しない)を使用するため、以下の制約が適用されます。これらは `tests/gsd-statusline.test.cjs` でテストされています。
|
||||
ステータスラインフックは正規表現ベースのパース(完全な YAML ライブラリを使用しない)を使用するため、以下の制約が適用されます。これらは `tests/msd-statusline.test.cjs` でテストされています。
|
||||
|
||||
1. **フロントマターはファイルの先頭文字から始まる必要があります。** コメントを含む何かが開始 `---` の前にあると、マッチが無効になります。開始 `---` 行は末尾のスペースなしで正確にそれだけである必要があります。
|
||||
|
||||
@@ -176,7 +176,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
|
||||
## Markdown 本文セクション
|
||||
|
||||
本文(末尾の `---` 以降のすべて)は `gsd-core/templates/state.md` のテンプレートに従います。標準セクションは以下の通りです:
|
||||
本文(末尾の `---` 以降のすべて)は `msd-core/templates/state.md` のテンプレートに従います。標準セクションは以下の通りです:
|
||||
|
||||
### Project Reference
|
||||
|
||||
@@ -200,7 +200,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
|
||||
進捗の*履歴*はここには属しません。それは、増えていくように設計されたセクションである以下の [`### Performance Metrics`](#performance-metrics) に蓄積されます。
|
||||
|
||||
このセクションの `Status:` および `Last activity:` フィールドは、既存の値が既知のテンプレートデフォルト値の場合に GSD ハンドラーによって更新されます(クヌース不変式: エグゼキューター作成値は保存されます)。既知のハンドラーデフォルト値の完全なリストは `gsd-core/bin/lib/state-document.cjs` の `KNOWN_TEMPLATE_DEFAULTS` に記載されています。
|
||||
このセクションの `Status:` および `Last activity:` フィールドは、既存の値が既知のテンプレートデフォルト値の場合に MSD ハンドラーによって更新されます(クヌース不変式: エグゼキューター作成値は保存されます)。既知のハンドラーデフォルト値の完全なリストは `msd-core/bin/lib/state-document.cjs` の `KNOWN_TEMPLATE_DEFAULTS` に記載されています。
|
||||
|
||||
### Performance Metrics
|
||||
|
||||
@@ -213,11 +213,11 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
|
||||
### Accumulated Context
|
||||
|
||||
**Decisions** — 現在の作業に影響する最近の意思決定のサマリー(完全なログは `PROJECT.md` に保存)。`gsd-tools state add-decision` で追加。
|
||||
**Decisions** — 現在の作業に影響する最近の意思決定のサマリー(完全なログは `PROJECT.md` に保存)。`msd-tools state add-decision` で追加。
|
||||
|
||||
**Pending Todos** — 件数と `.planning/todos/pending/` への参照。`/gsd-capture` で取得。
|
||||
**Pending Todos** — 件数と `.planning/todos/pending/` への参照。`/msd-capture` で取得。
|
||||
|
||||
**Blockers/Concerns** — 今後の作業に影響する課題。起点フェーズのプレフィックス付き。`gsd-tools state add-blocker` で追加し、`gsd-tools state resolve-blocker` で解決。
|
||||
**Blockers/Concerns** — 今後の作業に影響する課題。起点フェーズのプレフィックス付き。`msd-tools state add-blocker` で追加し、`msd-tools state resolve-blocker` で解決。
|
||||
|
||||
### Session Continuity
|
||||
|
||||
@@ -236,7 +236,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
- ライフサイクルフィールドの追加はオプトインです — フィールドが不在の場合レンダラーはグレースフルに縮退します。
|
||||
- 進捗バーは `progress` ブロックが存在する場合でもオプトインです: バーをトリガーするのは `progress.percent` のみで、`total_phases` と `completed_phases` だけではトリガーされません。
|
||||
|
||||
`tests/gsd-statusline.test.cjs` の `formatGsdState #2833 backward compatibility` テストスイートがこの保証を固定しています。レガシー `STATE.md` 描画を壊す変更があればスイートが失敗します。
|
||||
`tests/msd-statusline.test.cjs` の `formatMsdState #2833 backward compatibility` テストスイートがこの保証を固定しています。レガシー `STATE.md` 描画を壊す変更があればスイートが失敗します。
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user