← 実例マッピング | livt
ストーリー ルール 提案中のルール テストが自動化している 具体例 疑問点 ユビキタス言語
表示
ルールごとに合意が要る人を書く→

ルール

5
#R-01
ルールは、合意が要る人をdecision_makersとして持てる
具体例3
#EX-01
人はforgeのメンションの形で書く（@alice、@acme/design）。あとに続くactionが、forgeのIDへ機械的に結び付けられる
#EX-02
livtは書かれた文字列をそのまま運び、実在する人やチームかは確かめない
#EX-03
ルールのstatusに関わらず書ける（提案中のルールにも、合意済みのルールにも）
#R-02
decision_makersは任意で、書かれていないルールには何も求めない
具体例2
#EX-01
decision_makersのない実例マッピングは、これまでどおりに読める
#EX-02
提案中のルールにも書かなくてよい
#R-03
合意が要る人は、statusに関わらずルールと一緒に示される
具体例4
#EX-01
ボードのルール付箋に、合意が要る人が出る
#EX-02
提案中のルールでも合意済みのルールでも、同じ出方をする
#EX-03
タスクページの提案中のルールにも、合意が要る人が並ぶ
#EX-04
decision_makersのないルールは、これまでどおりに出る（未定とは書かない）
#R-04
MCPとCLIは、decision_makersをルールに付けて返す
具体例2
#EX-01
decision_makersのあるルールを読むと、書かれた順のまま返る
#EX-02
decision_makersのないルールには、項目そのものが載らない
#R-05
合意が要る人の変更は、差分にそのルールの変更として出る
具体例3
#EX-01
提案中のままマージしたルールにあとから人を足すと、足した人が緑で並ぶ
#EX-02
人を消すと、消した人が赤で並ぶ
#EX-03
人だけが変わったルールは、IDも文言も変わらない

疑問点

4
疑問点
#Q-01 同じ人を全ルールに繰り返し書く手間をどうするか（実例マッピング全体の既定を1か所に書き、違うルールだけ上書きする形が考えられる）
#Q-02 合意済みのルールに書かれた合意が要る人を、そのルールを変えるときにも合意が要る人として扱うか
#Q-03 GitHub以外のforgeでの書き方をどう扱うか（livtは文字列として運ぶだけだが、チェックとスキルは解釈する）
#Q-04 タスクページを合意が要る人で絞り込めるようにするか（自分を待っている提案だけを見たい。絞り込みの軸が1つ増えるので、別のストーリーになりそう）
ユビキタス言語
実例マッピング→ ストーリー→ livtリポジトリ→