← 実例マッピング | livt
ストーリー ルール 提案中のルール テストが自動化している 具体例 疑問点 ユビキタス言語
表示
自動化レポートからルールごとの状況を導く→

ルール

7
#R-01
ビルドはレポートを入力として読み、ネットワークに出ない
具体例3
#EX-02
レポートが1つも無ければ、自動化の状況はどこにも出ない
livt: build_index_test.go:139 livt: build_mapping_test.go:175 livt: build_mapping_test.go:190 livt: builder_test.go:73
#EX-03
forgeにもトラッカーにも問い合わせず、渡されたものだけから導く
#EX-04
livtリポジトリにコミットされたレポートを読むので、既定では何も渡さなくてよい
#R-02
ルールと具体例は、それぞれ自分の引用で状況が決まる
具体例4
#EX-01
ルール軸の母数はルール数、具体例軸の母数は具体例数で、別々に数える
#EX-02
退役した項目はどちらの母数にも数えない
#EX-03
オポチュニティの現況はルール軸だけを追う
#EX-04
具体例が全て自動化されていても、ルール自身の状況は変わらない
#R-03
状況は引用の有無で決まり、レポートがあること自体が「見た」という宣言になる
具体例4
#EX-01
レポートに引用があれば自動化済み
#EX-02
レポートはあるが引用が無ければ未自動化
#EX-05
来るはずだったレポートという概念を持たない（宣言が無いので、届かなかった相手を名指せない）
#EX-04
走査する実装リポジトリは走行ごとに変わってよく、母数もそれに従って動く
#R-04
どの実装リポジトリで自動化されたかが分かる
具体例3
#EX-01
レポートが名乗る実装リポジトリが、そのまま自動化された場所になる
#EX-02
ルールごとに自動化される実装リポジトリは違ってよい
#EX-03
1つのルールが複数の実装リポジトリで自動化されることもある
#R-05
ruleのautomatedは、誰も書かなくなった後も、投影が単独でボードを支えられるまで読まれてから退役する
具体例4
#EX-02
投影が動いてからフラグを落とし、その間のmainはどの時点でも整合する
#EX-03
YAMLスキーマとMCPペイロードの破壊的変更として、メジャーバージョンで切る
#EX-07
読まれる期間はリリース数で区切らない（投影に穴が残るうちに落とすと、フォールバックだけが消えて代わりが立たない）
#EX-08
automatedはもう読まれず、付けたままのruleも状況は引用だけで決まる（引用の無いフラグが残していた印はボードから消える）
livt: build_mapping_test.go:212 livt: example_mapping_test.go:41
#R-06
走査と投影のテストは、ドッグフーディングでは現れない形を含む
具体例4
#EX-01
複数の実装リポジトリのレポートを合わせて読む
#EX-02
一部の実装リポジトリにだけ引用がある
#EX-03
対象のレポートが欠けている
#EX-04
livtリポジトリ自身が唯一の実装リポジトリなので、これらは本番のサイトには現れない
#R-08
引用が古い意味を検証し続けないのは、意味が変わったルールが別のIDを取るから
具体例5
#EX-01
言い回しだけの変更ではIDが変わらず、引用はそのまま有効（結び目はlivt URIで、テストケース名を本文に追従させる必要はない）
#EX-02
意味が変わったルールは退役し、後継が新しいIDを取る（具体例を書き換えずに差し替えるのと同じ作法）
#EX-03
旧IDへの引用は退役したルールを指すので、ルール軸の母数から外れる
#EX-04
後継は引用を持たないので、未自動化のルールとしてTasksページに並ぶ
#EX-05
livtは意味が変わったかを判定しない（判断は書き手のもので、機械が代行すれば定式化のたびにボードが嘘をつく）
ユビキタス言語
livt URI→ livtリポジトリ→ 実装リポジトリ→ 実例マッピング→ ストーリー→ オポチュニティ→ 自動化→