ユビキタス言語

用語	キー	定義
自動化	automation	実装リポジトリのテストがルールや具体例をlivt URIで引用し、その振る舞いを実行できる仕様として確かめること。テストのコメントに `livt:automates` とlivt URIを並べて書く。 BDD の Automation にあたる。livtが知るのは引用があるかどうかで、テストが通ったかではない。ルールと具体例はそれぞれ自分への引用で自動化され、一方が他方を兼ねない。
文脈	context	その用語の意味が通じる範囲。DDDの境界づけられたコンテキストにあたる。 livt では `ubiquitous/{ctx}/` のディレクトリとして切り、同じ言葉が範囲ごとに違う意味を持つことを表す。文脈を切らない用語は、範囲を跨いで共通の意味を指す。
ディスカバリー	discovery	何を作るべきかをチームで探索する協働活動。 livt はその結果を living text として残し、開発成果物との橋渡しをする。
実例マッピング	example-mapping	1つのストーリーについて、ルール・具体例・疑問点を色分け付箋で整理する手法。詳細ディスカバリーで仕様を具体化するために使う。
定式化	formulation	記録した素のマッピングを、ルールは言い切りに、具体例はその名前だけで何の話か分かる形にして、チームの誰が読んでも同じ振る舞いを思い浮かべられる文書に整える工程。実装は見ず、変えてよいのは表現と構造だけで、その差分がレビューの対象になる。 BDD の Formulation にあたり、Gherkin を書く行為に相当するのが実例マッピングの書き換え。Gherkin はそこから起こす生成物で、正となるのはマッピングのほう。
実装リポジトリ	implementation-repository	livtリポジトリのルールを、自プロダクトのテストとして自動化する側のリポジトリ。ストーリーの `repos:` で宣言する。外へ渡るのはIssueとlivt URIというポインタだけで、戻るのはテストが何を自動化しているかの引用。コードを読むのは実装リポジトリの中で走る走査であって、livtリポジトリのビルドはその結果しか読まない。 livtリポジトリと同一のリポジトリでも成立するが、それは両者が別々であるという一般形の特殊ケース。本リポジトリ自身がその特殊ケースにあたるため、同一である前提が暗黙に紛れ込みやすい。
livtリポジトリ	livt-repository	ディスカバリーで合意し記録した成果物（ストーリー・ユーザーストーリーマップ・実例マッピング・ユビキタス言語）を収める置き場で、全ての機能開発の起点。サイト・CLI・MCPの出力はすべてここからの導出物。livt URIはこの中の一点を指し、ルート（`--root` / `LIVT_ROOT`）は各環境における所在を指す。
livt URI	livt-uri	livtリポジトリの一点（オポチュニティ・オポチュニティキャンバス・ユーザーストーリーマップ・ストーリー・実例マッピング・ルール・具体例・疑問点・用語）を指す安定した名前。 `livt://` で始まり、MCP・CLI・SSGが同じ形を使う。デプロイ先のURLには依存しない。
オポチュニティキャンバス	opportunity-canvas	オポチュニティを1枚で記述するキャンバス。検証できる事実・解決策・価値についての仮定を10個のボックスに分けて並べる。「作るか」を決める前に埋めるもので、埋まっていないボックスはそのまま未回答の問いとして残る。
オポチュニティ	opportunity	プロダクトで取り組みうる機会。あるユーザーの課題と、それを解決したときに生まれる事業上の便益を、ひとつの検討単位として捉えたもの。 `opportunities/{key}.md` に1文で書き、同じkeyのユーザーストーリーマップがそのオポチュニティに引いたジャーニーになる。各一覧の絞り込み軸になる。
記録	record	会話で決めたことを、解釈も改善も加えず、ボードのままテキストへ残す工程。 Patton の「話して記録」にあたり、ここで残した素のマッピングが定式化のベースラインになる。
リリーススライス	release-slice	ユーザーストーリーマップを横方向に区切り、どのストーリーをどの順序でリリースするかを示すまとまり。リリース未指定のストーリーは未スコープ行にまとまる。
ユーザーストーリーマップ	story-map	アクティビティ・ユーザータスク・ストーリーをリリーススライスと共に俯瞰するボード。全体のストーリーを組み立て、ブラッシュアップするために使う。 livt ではオポチュニティ1つにつき1枚で、そのオポチュニティと同じキーのファイル（`discoveries/usm/{key}.yaml`）に置く。
ストーリー	story	ユーザーにとって価値のある振る舞いの単位。 3つのC のカードとして `stories/{story-key}.md` に書かれ、ユーザーストーリーマップや実例マッピングから参照される。
ユビキタス言語	ubiquitous-language	チームが協働と実装で共通して使う用語。 livt では用語ごとに Markdown ファイルとして管理し、一覧をテーブルとして閲覧する。
発見	discovery bdd	具体例を出しながらストーリーの振る舞いを洗い出し、ルールを立て、決めきれないものを疑問点として残す協働。実例マッピングがその手法。 BDD の Discovery にあたり、探索全体の傘であるディスカバリーとは別に、ストーリー1つ分のセッションを指す。部屋に誰がいるか——人間だけか、AIを招くか——は定義に入らない。

自動化

automation

実装リポジトリのテストがルールや具体例をlivt URIで引用し、その振る舞いを実行できる仕様として確かめること。テストのコメントに `livt:automates` とlivt URIを並べて書く。 BDD の Automation にあたる。livtが知るのは引用があるかどうかで、テストが通ったかではない。ルールと具体例はそれぞれ自分への引用で自動化され、一方が他方を兼ねない。

文脈

context

その用語の意味が通じる範囲。DDDの境界づけられたコンテキストにあたる。 livt では `ubiquitous/{ctx}/` のディレクトリとして切り、同じ言葉が範囲ごとに違う意味を持つことを表す。文脈を切らない用語は、範囲を跨いで共通の意味を指す。

ディスカバリー

discovery

何を作るべきかをチームで探索する協働活動。 livt はその結果を living text として残し、開発成果物との橋渡しをする。

実例マッピング

example-mapping

1つのストーリーについて、ルール・具体例・疑問点を色分け付箋で整理する手法。詳細ディスカバリーで仕様を具体化するために使う。

定式化

formulation

記録した素のマッピングを、ルールは言い切りに、具体例はその名前だけで何の話か分かる形にして、チームの誰が読んでも同じ振る舞いを思い浮かべられる文書に整える工程。実装は見ず、変えてよいのは表現と構造だけで、その差分がレビューの対象になる。 BDD の Formulation にあたり、Gherkin を書く行為に相当するのが実例マッピングの書き換え。Gherkin はそこから起こす生成物で、正となるのはマッピングのほう。

実装リポジトリ

implementation-repository

livtリポジトリのルールを、自プロダクトのテストとして自動化する側のリポジトリ。ストーリーの `repos:` で宣言する。外へ渡るのはIssueとlivt URIというポインタだけで、戻るのはテストが何を自動化しているかの引用。コードを読むのは実装リポジトリの中で走る走査であって、livtリポジトリのビルドはその結果しか読まない。 livtリポジトリと同一のリポジトリでも成立するが、それは両者が別々であるという一般形の特殊ケース。本リポジトリ自身がその特殊ケースにあたるため、同一である前提が暗黙に紛れ込みやすい。

livtリポジトリ

livt-repository

ディスカバリーで合意し記録した成果物（ストーリー・ユーザーストーリーマップ・実例マッピング・ユビキタス言語）を収める置き場で、全ての機能開発の起点。サイト・CLI・MCPの出力はすべてここからの導出物。livt URIはこの中の一点を指し、ルート（`--root` / `LIVT_ROOT`）は各環境における所在を指す。

livt URI

livt-uri

livtリポジトリの一点（オポチュニティ・オポチュニティキャンバス・ユーザーストーリーマップ・ストーリー・実例マッピング・ルール・具体例・疑問点・用語）を指す安定した名前。 `livt://` で始まり、MCP・CLI・SSGが同じ形を使う。デプロイ先のURLには依存しない。

オポチュニティキャンバス

opportunity-canvas

オポチュニティを1枚で記述するキャンバス。検証できる事実・解決策・価値についての仮定を10個のボックスに分けて並べる。「作るか」を決める前に埋めるもので、埋まっていないボックスはそのまま未回答の問いとして残る。

オポチュニティ

opportunity

プロダクトで取り組みうる機会。あるユーザーの課題と、それを解決したときに生まれる事業上の便益を、ひとつの検討単位として捉えたもの。 `opportunities/{key}.md` に1文で書き、同じkeyのユーザーストーリーマップがそのオポチュニティに引いたジャーニーになる。各一覧の絞り込み軸になる。

記録

record

会話で決めたことを、解釈も改善も加えず、ボードのままテキストへ残す工程。 Patton の「話して記録」にあたり、ここで残した素のマッピングが定式化のベースラインになる。

リリーススライス

release-slice

ユーザーストーリーマップを横方向に区切り、どのストーリーをどの順序でリリースするかを示すまとまり。リリース未指定のストーリーは未スコープ行にまとまる。

ユーザーストーリーマップ

story-map

アクティビティ・ユーザータスク・ストーリーをリリーススライスと共に俯瞰するボード。全体のストーリーを組み立て、ブラッシュアップするために使う。 livt ではオポチュニティ1つにつき1枚で、そのオポチュニティと同じキーのファイル（`discoveries/usm/{key}.yaml`）に置く。

ストーリー

story

ユーザーにとって価値のある振る舞いの単位。 3つのC のカードとして `stories/{story-key}.md` に書かれ、ユーザーストーリーマップや実例マッピングから参照される。

ユビキタス言語

ubiquitous-language

チームが協働と実装で共通して使う用語。 livt では用語ごとに Markdown ファイルとして管理し、一覧をテーブルとして閲覧する。

発見

discovery bdd

具体例を出しながらストーリーの振る舞いを洗い出し、ルールを立て、決めきれないものを疑問点として残す協働。実例マッピングがその手法。 BDD の Discovery にあたり、探索全体の傘であるディスカバリーとは別に、ストーリー1つ分のセッションを指す。部屋に誰がいるか——人間だけか、AIを招くか——は定義に入らない。