product-cli

Product

Product Framework 向けの CLI および MCP サーバー — 検証可能な What/How グラフとしてソフトウェアを仕様化します。

Product Framework は、ソフトウェア製品を機械可読な、ひとつにつながったグラフとして記述するためのオープンスタンダードです。グラフは What（ドメインモデル＋イベントモデル — エンティティ、コマンド、イベント、読み取りモデル、Abstract Interaction Objects に対して型付けされた UI ステップ、systems、triggers、Deciders、Projectors）、How（コントラクト、画面構成／具象化モデル、デリバリーフィーチャー）、およびそれらを結ぶ型付きリンクで構成されます。このグラフは生成を駆動し、ゲート検証を行い、自身を説明できます。そのため、「このシステムを説明して」は古くなったドキュメントではなく、クエリです。

このリポジトリはリファレンスツール一式です。単一の Rust バイナリ（product）と、エージェントがグラフを直接作成・検証できる MCP サーバーで構成されます。データベースもサービスも不要です。グラフは .product/ の下に YAML/Turtle 形式で保存されます。

$ product init --demo                 # scaffold + seed the bookstore What model
$ product domain new system sys-shop --system-kind application \
      --purpose "consumer e-commerce" --target-classes gui
$ product domain validate --strict    # per-node shapes + graph-level completeness
$ product decider derive Order        # derive an aggregate's executable signature
$ product decider validate Order-decider
$ product mcp --http                  # MCP server + a live Event-Modeling web view at /

---

インストール

# from source
cargo install --path product-cli

バイナリには、What→How→Build の Claude Code スキルが組み込まれています。 product init は、新しいリポジトリの .claude/skills/ にスキルを書き込みます（使わない場合は --no-skills を指定してください）。product skills install はスキルを（再）インストールし、product skills install --global はすべてのプロジェクトで使えるよう ~/.claude/skills/ に配置します。新しい Claude Code セッションを開始してスキルを読み込んだら、/product-session を実行してください。

エージェント CLI の選択

product session start（および product author domain）は、Claude Code または GitHub Copilot CLI のエージェント CLI で What→How→Build セッションを実行します。CLI は次の順序で解決されます。

1. --cli claude|copilot フラグ。指定がなければ、
2. リポジトリの .product/config.toml にある [author].cli。それもなければ、
3. $XDG_CONFIG_HOME/product/config.toml（または ~/.config/product/config.toml）にあるグローバルなユーザー既定値。それもなければ、
4. claude。

# .product/config.toml — make this repo default to Copilot CLI
[author]
cli = "copilot"

新しいリポジトリで product init --cli copilot を実行してひな形を作成するか、~/.config/product/config.toml に同じ [author] ブロックを設定して、すべてのリポジトリで使う個人用の既定値を指定します。既定値を設定すると、product session start で --cli フラグは不要になります。

60 秒ツアー

product init --demo                   # a worked What model to explore
product domain list                   # the captured nodes, by kind
product domain show Order             # one node and its links
product domain export                 # the graph as RDF/Turtle
product domain validate               # §3.1/§3.2 per-node conformance shapes
product domain validate --strict      # + §3.2.0/§3.2.5/§3.4/§4.5 completeness checks
product decider derive Order          # §3.3 — derive decide/evolve signature
product decider simulate Order-decider  # run its flow-derived scenarios
product guide                         # where you are + the next step

モデル

• What — product domain … でドメインモデルとイベントモデルを取り込みます。product decider …（§3.3）と product projector …（§3.4）で、振る舞いと読み取りモデルを実行可能にします。product primitive …（§3.5）で、これ以上分割できないアルゴリズムに名前を付けます。
• How — product how、product feature、product build、product seam、product preview で、How コントラクト、デリバリーフィーチャー、画面の接合部、§11/§12 のデザインシステム／コンテンツストアのプレビュープロファイルを扱います。
• すべてフレームワークの SHACL シェイプと SPARQL ルールに照らして検証されます。取り込んだ What は Turtle にシリアライズされます（product domain export）。

MCP とウェブビュー

product mcp --http は MCP サーバー（フレームワークツール：product_domain_*、product_decider_*、product_projector_*、…）を起動し、/ でライブウェブビューを配信します。このビューでは、アクティブな What グラフを、相互に連携する 3 つのビューで表示します。Systems（product → systems と journeys のマップ、§3.0）、Domain（1 つの境界づけられたコンテキストを ER グラフで表示、§3.1）、Flows（あるシステムのイベントモデルを Event-Modeling のスイムレーンで表示 — 集約ごとのイベントストリームにおけるトリガー／コマンド／ビュー、§3.2）です。ノード詳細パネル、What→How→Build のフェーズステッパー、ダーク／ライトテーマ、ライブ SSE 更新も備えています。

ddd — Decision-Driven Design ガバナンス

ワークスペースには ddd（クレート ddd-core、ddd-lsp、ddd-mcp、ddd-cli）も含まれています。これは、別個のストア上で動作する独立したツールです。リポジトリ内の .ddd/ グラフには、述語、閉包の主張、決定、アナライザー／リンターのマニフェスト、パターンインスタンス、接合部の宣言、インターセプトイベントの行が保存されます（仕様、アンブレラ PRD、形式：マイグレーション）。

cargo run -p ddd-cli -- init        # scaffold .ddd/
ddd validate                        # schema + ontology rules (CI gate)
ddd diff --sarif build.sarif        # declared vs. detected rules (CI gate)
ddd report escapes                  # diff + cadence + basis-loss report, each section stating its coverage
ddd why CA2007                      # rule -> decision -> principal -> claims (or: detected but unfiled)
ddd render                          # static self-contained HTML projection of the graph
ddd serve                           # the ddd_* MCP surface (stdio)
ddd warmup                          # pre-load the LSP hosts (Roslyn solution load)
ddd what                            # What-graph boundaries carrying no declaration

What のガバナンス（フレームワークグラフ）

ddd what は、.product/ の What グラフを、C# と Bicep に並ぶ3つ目のガバナンス対象サーフェスとして扱います。言語サーバーは必要ありません。product-core が What をすでに型付きデータとして所有しているため、アダプターは DomainGraph から種別とコンテナーを直接読み取り、同じポリシーテーブルの仕組み（ddd-core/src/surface.rs、LSP アダプターと共有）を通して処理します。

行の種別は2つです。境界種別は、接続先が何であれサーフェスとなります。システム（§3.2.5）、コンテキストマッピング（§3.1）、ジャーニーの交差点（§3.0.1）、品質要求（§3.6）などです。公開種別は、§3.2.0 の Translation がその種別を運ぶ場合に限りサーフェスとなります。Translation が監視する View、発行する Command、その View が投影する Event が該当します。それ以外はすべて、それぞれのシステム内部にとどまり、宣言を要求しません。

この公開／内部の区別は、C# の可視性に相当する What の仕組みであり、重要な意味を持ちます。最初のテーブルではすべての Event と Command を境界として扱っていましたが、DDD-what-02 での測定により否定されました（39件中、何かを横断したものは0件）。dec/ddd/what-published-qualifier を参照してください。

継ぎ目の宣言にある contract_location が what:<element-id> の場合、その境界はガバナンス対象として数えられます。--strict を指定すると CI ゲートになります。既定では失敗させずに報告するため、まず実際のグラフに照らしてテーブルを調整できます。

MCP サーフェス（M3/M4）

ddd serve は、stdio 経由で ddd_* ツール名前空間を公開します。C#（公式のプレリリース版 .NET グローバルツールである roslyn-language-server --stdio --autoLoadProjects）と Bicep（Azure.Bicep.LangServer の bicep-ls）向けの LSP ベースの言語インテリジェンスとして、find_symbol、references、hover、diagnostics（ルール ID でマニフェストと結合します。SARIF パスと同じ結合です）、signature、rename（計算を行い、適用処理はインターセプターを経由します）を提供します。また、ガバナンスツールとして why、graph_query、declare_seam、declare_pattern、accept_risk を提供します。

3つの declare／accept ツールは、すでに登録済みのエントリを修正する場合に amend: true を指定します。このフラグはどちらの方向でも明示的です。新規作成で暗黙に上書きすることはなく、修正で暗黙に作成することもありません。分割はフィールド単位で行われます。判断に関する修正（verdict_knowledge、義務への回答、根拠）を行う一方、識別情報と LSP 由来の証拠（contract_location、metadata）はそのまま引き継ぐため、インターセプト行は引き続き機械生成となります。

ddd_apply_edit はすべての編集を、言語ごとのコントラクトサーフェス分類器（ポリシーテーブル、PRD §9）に通します。サーフェスではない編集は適用されます。サーフェス編集は、同じセッションに対応する宣言がある場合に限り適用されます。それ以外は、事実（シンボル、種別、シグネチャ、可視性、参照数）が事前に入力され、判断フィールドが空欄の構造化された要求とともに却下されます（dec/ddd/rejection-facts-prefilled）。モードは intercept: enforce | warn | off で、intercept_by_class（設定フォーマット3）を使ってアーティファクトクラスごとに設定できます。adapter.csharp.internal_is_surface はライブラリリポジトリの姿勢を切り替えます（dec/ddd/internal-not-surface）。分類されたサーフェスの結果はすべて、対応関係データセットとして .ddd/seams/events/ の下に行として記録されます。ホストは遅延起動し、ヘルスチェックを受け、クラッシュ時には再起動します。Roslyn がソリューションを読み込んでいる間、ツールはハングせず、明示的に {"status": "loading"} を返します。CI はフィクスチャ品質のモックホストを使って実行します（dec/ddd/fixtures-not-sdk）。ゲート対象の実ホストスイートを実行するには、両方のツールを PATH に通したうえで DDD_LSP_E2E=1 を設定してください。

ddd diff は .ddd/manifest/ のマニフェストを、言語ごとに検出した2つのソースと比較し、UNGOVERNED（検出されたが、マニフェストにエントリがない）、STALE（マニフェストにエントリがあるが、設定にも出力にも存在しない）、UNCITED_SUPPRESSION（リスク受容の記録がない設定内またはソース内の抑制）を報告します。

• configured — .editorconfig（dotnet_diagnostic.<ID>.severity 行のみ。セクションのグロブは記録されますが、評価はされません。意図的に editorconfig エンジンではありません）、bicepconfig.json（analyzers.core.rules のレベル）、およびルートの Cargo.toml（このリポジトリ独自のゲート用の [workspace.lints.clippy]）から解析されます。 アナライザーパッケージのデフォルトで有効になっているルールには設定行がなく、出力されたソース経由でのみ表示されます。1 つのソースがルールをカバーしている場合は、diff がその旨を示します。

• emitted — 実際のビルドで生成された SARIF 2.1 ファイルを、共有モジュールで取り込みます。以下の方法で生成します（M2 時点の最新ツール文書に照らして検証済み）。

  • C#：dotnet build -p:ErrorLog=diag.sarif%2Cversion=2.1 — MSBuild の ErrorLog プロパティです。version=2.1 は必須です（デフォルトは SARIF 1.0）。 また、CLI では %2C でカンマをエスケープします（または、プロジェクトで <ErrorLog> を設定します）。
  • Bicep：bicep lint main.bicep --diagnostics-format sarif > bicep.sarif （az bicep lint も利用できます）。

  ソース内の抑制方法はツールチェーンごとに異なります。C# コンパイラーは #pragma で抑制された診断も SARIF に記録し（抑制済みとマークされます）、これによって UNCITED_SUPPRESSION が検出します。Bicep の #disable-next-line は診断を 出力から完全に取り除くため、Bicep のソース内抑制は検出できません。対象となるのは level: off の設定による抑制のみです。

ddd diff には、--sarif または .ddd/config.yaml の detect.sarif リストでファイルを指定します。 このリポジトリは自身を管理します。.ddd/manifest/clippy.yaml は clippy::unwrap_used をその判定に対応付けており、ddd diff はワークスペースの lint テーブルと照合して検証します。

ビルドとテスト

cargo build
cargo t                                          # full suite (alias: test --no-fail-fast)
cargo clippy -- -D warnings -D clippy::unwrap_used

アーキテクチャとコントリビューター向けワークフローについては CLAUDE.md を、 仕様については docs/product-framework-open.md を参照してください。

ライセンス

LICENSE を参照してください。