タスク

オポチュニティ

未解決の疑問点

24 — 会話で閉じる
ネットワーク（非ローカル）公開する場合の認証・公開モデルをどうするか（現状はローカル利用前提で認証なし）
Q-05 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
同一性（どのlivtリポジトリか）と版方針を宣言するネイティブマニフェストを持つか（R-15のenv契約が供給するのは所在のみ。名前→所在のレジストリ、spec_versionのピン留めが論点）
Q-06 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
走査が拾うパターンをリポジトリごとに宣言できるようにするか（マーカーを1つに決めたので今は要らないが、言語ネイティブのアノテーションを使いたい場合の拡張先）
Q-02 実装リポジトリのテストから自動化を集めてレポートにする ディスカバリーと開発のギャップ
同じ人を全ルールに繰り返し書く手間をどうするか（実例マッピング全体の既定を1か所に書き、違うルールだけ上書きする形が考えられる）
Q-01 ルールごとに合意が要る人を書く 律速する意思決定
合意済みのルールに書かれた合意が要る人を、そのルールを変えるときにも合意が要る人として扱うか
Q-02 ルールごとに合意が要る人を書く 律速する意思決定
GitHub以外のforgeでの書き方をどう扱うか（livtは文字列として運ぶだけだが、チェックとスキルは解釈する）
Q-03 ルールごとに合意が要る人を書く 律速する意思決定
タスクページを合意が要る人で絞り込めるようにするか（自分を待っている提案だけを見たい。絞り込みの軸が1つ増えるので、別のストーリーになりそう）
Q-04 ルールごとに合意が要る人を書く 律速する意思決定
解決した疑問点はどう扱うか（現状はルール化して付箋を消す運用のため、一覧は常に未解決のみを映す）
Q-01 未解決の疑問点を横断で見渡す 揮発するディスカバリー
同じ集約をMCPにも出すか（実装リポジトリのエージェントが着手前に未解決の疑問点を拾えるようにする）
Q-02 未解決の疑問点を横断で見渡す 揮発するディスカバリー
並び順を何を軸に決めるか（TDDのテストリストとして「どこから書くか」に答えるなら順序が要るが、リリーススライスは3マップ中2マップに存在せず軸にならない）
Q-01 未自動化のルールを横断で見渡す ディスカバリーと開発のギャップ
自動化Issueが起票済みのルールを「着手済み」として区別するか（livtリポジトリはIssueのリンクだけを持ち、その開閉状態は持たない）
Q-02 未自動化のルールを横断で見渡す ディスカバリーと開発のギャップ
合意済みのルールをADRのようにイミュータブルに扱うか（現状はchange-ruleがルール本文の書き換えを許しており、変更を退役＋新ルールで表してはいない）
Q-01 合意前のルールを提案中として実例マッピングに載せる 揮発するディスカバリー
差分を載せたサイトを公開するか（いまのサイトはGitHub Pagesへ公開される。差分はレビューのあいだだけのものなので、同じ出力先に出していいか）
Q-01 リビジョン間の差分をlivt URI単位で読む
レビュアーは手元でビルドを走らせるのか、PRから差分に辿り着けるべきか（後者ならCIとプレビューの公開が要る）
Q-02 リビジョン間の差分をlivt URI単位で読む
付箋の並び替えだけの変更を差分として映すか（livt URIは変わらないが、ボードの見えは変わる）
Q-04 リビジョン間の差分をlivt URI単位で読む
ルールにも具体例にも付かない引用（解決しないURIなど）が増減したとき、差分にどう映すか（付く先が無いので映らず、レポートのPRが開いても差分は空になりうる）
Q-05 リビジョン間の差分をlivt URI単位で読む
ボードごとに既定の文脈を宣言し、bare keyをその文脈で解決するか（現状はボード側が参照ごとに文脈を書く）
Q-01 用語を文脈で切り分ける 揮発するディスカバリー
文脈そのものに表示名や説明を持たせるか（現状はディレクトリ名がそのまま文脈名を兼ねる）
Q-02 用語を文脈で切り分ける 揮発するディスカバリー
どのユーザーストーリーマップにも載っていない実例マッピングをどこに映すか（オポチュニティのページには定義上載らない）
Q-01 オポチュニティごとに現況を映す ディスカバリーと開発のギャップ
ストーリーの分母をマップ上のカード数とストーリーファイル数のどちらで数えるか（前者はそのオポチュニティが取り上げた範囲、後者はlivtリポジトリ全体で、両者はズレる）
Q-02 オポチュニティごとに現況を映す ディスカバリーと開発のギャップ
いつ合意され、いつ自動化されたかという時間軸を映すか（livtはいまYAMLだけを読み、gitに依存していない。映すならビルドがgitリポジトリを要求する）
Q-03 オポチュニティごとに現況を映す ディスカバリーと開発のギャップ
1つのworkspaceが複数のlivtリポジトリを消費するとき、裸のlivt URIのスコープを何が復元するか（default宣言＋エイリアス修飾のxmlns型が候補。現時点では考慮外とし、R-08 EX-03で拡張の席だけ確保している）
Q-02 テストからルール・具体例へ辿る ディスカバリーと開発のギャップ
代替先URIの妥当性を検証するか（現状は解決しないURIも素通しする。未コミットのubiquitous参照を素通しで見せるのと揃えてはいるが、退役の代替先は誰の目にも触れないまま壊れうる）
Q-03 テストからルール・具体例へ辿る ディスカバリーと開発のギャップ
マージ前に却下された提案を、rejectedとして残すか削除するか（livt://mapping/propose-rule-before-agreement/rule/R-05/example/EX-02 は却下された提案を削除せずrejectedにすると言うが、デフォルトブランチに載らなかった提案まで含むかは決めていない。現状はrejectedとして残す）
Q-04 テストからルール・具体例へ辿る ディスカバリーと開発のギャップ

提案中のルール

0 — 合意で閉じる

提案中のルールはありません。

未自動化のルール

80 — テストで閉じる
livtはlivtリポジトリをMCPサーバーとして公開し、消費側はlivtのソースを読まずに決定を取得する
R-01 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
実装リポジトリは別ディレクトリにあるlivtリポジトリの場所を指定できる
R-02 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
各レスポンス（ツール・リソース）はlivtリポジトリのバージョン（gitリビジョン）を返し、読んだ版のズレを防ぐ
R-03 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
実装リポジトリはストーリー単位で実例マッピングをリソースとして取得できる
R-04 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
実装リポジトリはルール単位で仕様をリソースとして取得できる
R-05 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
実装リポジトリは利用可能なストーリーの一覧を取得できる
R-06 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
消費側は stdio で livt mcp をサブプロセスとして起動し、消費者ごとに1対1で接続する
R-07 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
消費側は常駐する1つの livt mcp --http サーバーをURL参照で共有する
R-08 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
実装リポジトリはストーリー本文をリソースとして取得できる
R-10 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
実装リポジトリはユビキタス言語の用語をリソースとして取得できる
R-11 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
公開対象の一覧はツールとリソーステンプレートで提供し、concrete resources と変更通知には広げない
R-12 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
livtリポジトリの参照を成果物に残すときは、IDではなくlivt URIで引用する
R-14 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
livtリポジトリの所在は、消費側workspaceにコミットされる宣言で供給する
R-15 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
実装リポジトリはユビキタス言語の用語の一覧を取得できる
R-16 実装リポジトリがlivtリポジトリを見てテスト駆動で自動化する ディスカバリーと開発のギャップ
走査はルールと具体例を独立に拾い、構造を推論しない
R-02 実装リポジトリのテストから自動化を集めてレポートにする ディスカバリーと開発のギャップ
どの実装リポジトリが参加するかは実装側のCIが決め、livtリポジトリは宣言を持たない
R-03 実装リポジトリのテストから自動化を集めてレポートにする ディスカバリーと開発のギャップ
レポートは引用の事実だけを運び、判断を持たない
R-04 実装リポジトリのテストから自動化を集めてレポートにする ディスカバリーと開発のギャップ
レポートはlivtリポジトリにコミットし、書き戻しは機械だけが行う
R-05 実装リポジトリのテストから自動化を集めてレポートにする ディスカバリーと開発のギャップ
走査もPRも、引用の集合が変わったかだけで決める
R-07 実装リポジトリのテストから自動化を集めてレポートにする ディスカバリーと開発のギャップ
ルールをどこで引用するかは実装リポジトリで働くAIスキルが導き、走査は推論しない
R-08 実装リポジトリのテストから自動化を集めてレポートにする ディスカバリーと開発のギャップ
ビルドはレポートを入力として読み、ネットワークに出ない
R-01 自動化レポートからルールごとの状況を導く ディスカバリーと開発のギャップ
ルールと具体例は、それぞれ自分の引用で状況が決まる
R-02 自動化レポートからルールごとの状況を導く ディスカバリーと開発のギャップ
状況は引用の有無で決まり、レポートがあること自体が「見た」という宣言になる
R-03 自動化レポートからルールごとの状況を導く ディスカバリーと開発のギャップ
どの実装リポジトリで自動化されたかが分かる
R-04 自動化レポートからルールごとの状況を導く ディスカバリーと開発のギャップ
ruleのautomatedは、誰も書かなくなった後も、投影が単独でボードを支えられるまで読まれてから退役する
R-05 自動化レポートからルールごとの状況を導く ディスカバリーと開発のギャップ
走査と投影のテストは、ドッグフーディングでは現れない形を含む
R-06 自動化レポートからルールごとの状況を導く ディスカバリーと開発のギャップ
引用が古い意味を検証し続けないのは、意味が変わったルールが別のIDを取るから
R-08 自動化レポートからルールごとの状況を導く ディスカバリーと開発のギャップ
ルールメンテナーはlivtリポジトリのルールを指定して、対象実装リポジトリへ自動化Issueを起票できる
R-01 livt経由で各実装リポジトリに自動化Issueを起票する ディスカバリーと開発のギャップ
起票したIssueのURLは、スキルがマッピングYAMLのruleに書き戻す
R-02 livt経由で各実装リポジトリに自動化Issueを起票する ディスカバリーと開発のギャップ
dedupeはlivtリポジトリ側の記録で判定し、同じルール×対象リポジトリを二重起票しない
R-03 livt経由で各実装リポジトリに自動化Issueを起票する ディスカバリーと開発のギャップ
Issue本文はルール・具体例の本文とlivtリポジトリへのバックポインタを運ぶ
R-04 livt経由で各実装リポジトリに自動化Issueを起票する ディスカバリーと開発のギャップ
ストーリーにUS Issueが紐づいていれば、ルールIssueはそのsub-issueとして起票する
R-05 livt経由で各実装リポジトリに自動化Issueを起票する ディスカバリーと開発のギャップ
起票は実装リポジトリのコードを読まず、Issueというポインタだけを送る
R-06 livt経由で各実装リポジトリに自動化Issueを起票する ディスカバリーと開発のギャップ
本ストーリーはAIスキルとして提供し、livtのCLIコマンドやMCPツールは追加しない
R-07 livt経由で各実装リポジトリに自動化Issueを起票する ディスカバリーと開発のギャップ
実例マッピングYAMLの各ruleは、対応する自動化IssueのURLをissuesとして持てる
R-08 livt経由で各実装リポジトリに自動化Issueを起票する ディスカバリーと開発のギャップ
紐づけの正はlivtリポジトリが持ち、GitHub側の構造には依存しない
R-09 livt経由で各実装リポジトリに自動化Issueを起票する ディスカバリーと開発のギャップ
対象実装リポジトリは、ストーリーのfrontmatterのreposで宣言する
R-10 livt経由で各実装リポジトリに自動化Issueを起票する ディスカバリーと開発のギャップ
Issue本文の一次参照はlivt URIで、デプロイ済みURLは補助にとどめる
R-11 livt経由で各実装リポジトリに自動化Issueを起票する ディスカバリーと開発のギャップ
ユーザーストーリーマップメンテナーはストーリーを指定して、対象実装リポジトリへストーリー単位のIssueを起票できる
R-01 livt経由でストーリー単位のIssueを起票する ディスカバリーと開発のギャップ
起票したIssueのURLは、スキルがストーリーのfrontmatterのissuesに書き戻す
R-02 livt経由でストーリー単位のIssueを起票する ディスカバリーと開発のギャップ
dedupeはlivtリポジトリ側の記録で判定し、同じストーリー×対象リポジトリに二重起票しない
R-03 livt経由でストーリー単位のIssueを起票する ディスカバリーと開発のギャップ
ストーリー単位のIssueはルールIssueなしでも成立し、両方あるときだけ親子になる
R-04 livt経由でストーリー単位のIssueを起票する ディスカバリーと開発のギャップ
本ストーリーはAIスキルとして提供し、livtのCLIコマンドやMCPツールは追加しない
R-05 livt経由でストーリー単位のIssueを起票する ディスカバリーと開発のギャップ
対象実装リポジトリの宣言はfile-automation-issues-to-impl-reposと共通で、ストーリーのfrontmatterのreposを参照する
R-06 livt経由でストーリー単位のIssueを起票する ディスカバリーと開発のギャップ
絞り込み状態をURLで共有できる
R-04 一覧をオポチュニティで絞り込む 揮発するディスカバリー
ルールは、合意が要る人をdecision_makersとして持てる
R-01 ルールごとに合意が要る人を書く 律速する意思決定
decision_makersは任意で、書かれていないルールには何も求めない
R-02 ルールごとに合意が要る人を書く 律速する意思決定
合意が要る人は、statusに関わらずルールと一緒に示される
R-03 ルールごとに合意が要る人を書く 律速する意思決定
MCPとCLIは、decision_makersをルールに付けて返す
R-04 ルールごとに合意が要る人を書く 律速する意思決定
合意が要る人の変更は、差分にそのルールの変更として出る
R-05 ルールごとに合意が要る人を書く 律速する意思決定
ストーリーと実例マッピングの両方が名前を持つとき、2つは同じ名前にする（揃えるのはAIスキルで、livt本体は比べない）
R-05 実例マッピング自体に名前を付ける
未自動化のルールは全実例マッピングを横断して一覧できる
R-01 未自動化のルールを横断で見渡す ディスカバリーと開発のギャップ
各ルールはどのストーリーのものか分かり、その付箋まで辿れる
R-02 未自動化のルールを横断で見渡す ディスカバリーと開発のギャップ
一覧はオポチュニティで絞り込める
R-03 未自動化のルールを横断で見渡す ディスカバリーと開発のギャップ
アクティビティとユーザータスクを俯瞰できる
R-01 ブラウザでユーザーストーリーマップをプレビューする 揮発するディスカバリー
ストーリーファイルを持つストーリーは詳細ページにリンクする
R-02 ブラウザでユーザーストーリーマップをプレビューする 揮発するディスカバリー
リリーススライスでストーリー行が区切られる
R-03 ブラウザでユーザーストーリーマップをプレビューする 揮発するディスカバリー
ストーリーカードのリンクを容易に取得できる
R-04 ブラウザでユーザーストーリーマップをプレビューする 揮発するディスカバリー
MCPとCLIは、どのルールにもstatusを付けて返す
R-04 合意前のルールを提案中として実例マッピングに載せる 揮発するディスカバリー
提案はADRと同じ流れで閉じる — 合意されればaccepted、却下されればrejected
R-05 合意前のルールを提案中として実例マッピングに載せる 揮発するディスカバリー
どの成果物の一覧も、現在の内容を映したプレビュー付きのタイルで並ぶ
R-05 どの成果物の編集も即座にプレビューへ反映する
差分は追加・変更・廃止の3通りで、git diffの赤緑で読める。ただし赤緑が言うのはファイルではなく決定
R-03 リビジョン間の差分をlivt URI単位で読む
差分とそのURIのページは、互いに辿れる
R-05 リビジョン間の差分をlivt URI単位で読む
実例マッピングはボードとリストを切り替えて読める
R-01 実例マッピングをリストで見返す
リストではルールが1つにつき1行で並ぶ
R-02 実例マッピングをリストで見返す
具体例はルールの行の下に折りたたまれ、開いたときだけ見える
R-03 実例マッピングをリストで見返す
付箋へのリンクは、どちらの表示でもその付箋に着地する
R-04 実例マッピングをリストで見返す
用語は文脈ディレクトリで切れる
R-01 用語を文脈で切り分ける 揮発するディスカバリー
文脈は用語の識別子の一部になる
R-02 用語を文脈で切り分ける 揮発するディスカバリー
用語集は文脈で絞り込める
R-04 用語を文脈で切り分ける 揮発するディスカバリー
ルールと具体例は、それぞれ自分の付箋で自動化を見分けられる
R-01 ルールが自動化されているかを一目で映す ディスカバリーと開発のギャップ
表示はlivtリポジトリの記録だけから導出され、buildはネットワークに出ない
R-02 ルールが自動化されているかを一目で映す ディスカバリーと開発のギャップ
ルール付箋から、記録された自動化Issueへ辿れる
R-01 ルール付箋から対応Issue・テストへ辿る ディスカバリーと開発のギャップ
リンクはlivtリポジトリの記録をそのまま使い、buildはネットワークに出ない
R-02 ルール付箋から対応Issue・テストへ辿る ディスカバリーと開発のギャップ
livt URIはデプロイ先に依存しない
R-02 テストからルール・具体例へ辿る ディスカバリーと開発のギャップ
新しいIDはretiredを含めたmax + 1で採番する
R-06 テストからルール・具体例へ辿る ディスカバリーと開発のギャップ
一度使われたIDは、指す対象を変えない
R-07 テストからルール・具体例へ辿る ディスカバリーと開発のギャップ
livt URIはlivtリポジトリ相対の名前で、どのリポジトリかは運ばない
R-08 テストからルール・具体例へ辿る ディスカバリーと開発のギャップ
退役した項目は代替先をlivt URIで示し、そこから現行の決定へ辿り直せる
R-09 テストからルール・具体例へ辿る ディスカバリーと開発のギャップ
デフォルトブランチにマージされる前の項目は退役させず、書き換えるか削除する
R-10 テストからルール・具体例へ辿る ディスカバリーと開発のギャップ