ストーリー
ルール
提案中のルール
テストが自動化している
具体例
疑問点
ユビキタス言語
実装リポジトリのテストから自動化を集めてレポートにする→
表示
ルール
8
#EX-01
livt automations <path> がそのチェックアウトを走査してレポートを出す
#EX-03
livtリポジトリはsubmoduleを持たない（ピン留めは投影の鮮度を殺す）
#EX-08
実装リポジトリは走査せず、マージしたrevを通知するだけで、そのrevをfetchして走査するのはlivtリポジトリ側
#EX-09
参加は実装リポジトリのCIにlivtが配るactionを1つ足すことで決まり、走査の作法を写す必要はない
#EX-10
資格情報は実装リポジトリ側がlivtリポジトリへdispatchを送る1本と、livtリポジトリ側が実装リポジトリを読む1本（publicなら後者は要らない）
#EX-11
livtリポジトリ自身が実装リポジトリを兼ねる場合も、既定のGITHUB_TOKENでは足りない（それが署名したdispatchはworkflowを起動しない）
#EX-12
参加には段階があり、通知を組む前に手元の走査から始められる（レポートの型が同じなので、後でCIに移しても同じものが出る）
#EX-04
レポートは生成物としてディスカバリーの成果物の外に置き、人は手で編集しない
#EX-06
レポートは生成時刻を名乗り、古いレポートは古いものとして映る
#EX-07
読み手はlivtリポジトリの権限だけで状況を読め、実装リポジトリへの権限は要らない
#EX-08
artifactや外部サービスには置かない（読むのに同じ権限が要り、期限で消え、過去のリビジョンで引けない）
#EX-10
置き場は automations/{owner}/{repo}.json で、実装リポジトリごとに1ファイル
#EX-11
内容が変わったときだけPRを出し、ブランチは実装リポジトリごとに1本を更新する
#EX-13
実装リポジトリのCIはマージしたrevを通知するだけで、走査もPR作成もlivtリポジトリ側が行う
#EX-14
置き場・ブランチ名・コミット・PR本文を知るのはlivtリポジトリ側だけで、実装リポジトリは通知先しか知らない
#EX-01
pushの差分がマーカー行を足すか消したときだけ走査する
#EX-02
マーカー行の削除も走査の理由になる（テストが消えたのに自動化済みのまま残ると、ボードは現在について嘘をつく）
#EX-03
行の移動やファイルの改名では走査しない（レポートはrevで固定した時点のスナップショットで、後の移動はリンクを壊さない）
#EX-04
走査するときは差分を当てず、リポジトリ全体のレポートを作り直す
#EX-05
比べる基点が無いpushは走査する（新しいブランチやforce pushでは差分を読めない）
#EX-06
PRを出すかは引用の集合で比べる（rev・生成時刻・revから組むURLは走行ごとに動く）
#EX-07
判定はlivtのコマンドが持ち、CIは答えを受けて分岐するだけ（マーカーの綴りはlivtのもので、CIに写すと二重定義になる）
#EX-01
ルールを囲むブロックがあるテストでは、ブロックにルールを、中の各ケースに具体例を引用する
#EX-03
具体例がすべて自動化されたからルールも自動化とみなすのはスキルの判断で、走査と導出は具体例の引用からルールを導かない
#EX-04
ルールを引用した後に具体例が増えても、スキルはルールの引用を外さず、増えた具体例に引用が無いことはサイトのボードで気付ける（ルールと具体例を独立に扱う以上、ルールの印だけでは崩れを言えない）
#EX-07
具体例はそれぞれ自分のテストケースを持ち、その引用はケースの直上に置く（入れ子でもフラットでも同じ）
#EX-08
囲むブロックのないフラットなテストでは、ルールの具体例がすべて引用されたときにルールの引用を足すが、具体例のURIがすでにルールを示すので近くで何度も繰り返さない（ファイルに1行はその一例で、置き方は決めない）