状態設計のチェック
- この状態は 判断がすでに完了した結果 だけを表しているか
- 「この状態の UI はあり得る？」と自分に聞いて、即答できるか
- nullable や flag の組み合わせで「状態を表現していないか」
- 状態を見ただけで、 これ以上判断が不要だ と分かるか
イベント設計のチェック
- このイベントは「これから判断してほしい」通知になっていないか
- イベントの型を見ただけで、何が確定したのか が分かるか
- Boolean や Int で「意味を持たせて」いないか
- sealed class にしたとき、アプリがとり得る状態として過不足がないか
境界設計のチェック
- この境界を越えたあと、判断が発生していないか
- 境界の向こう側で if / when が増えていないか
- Flow の各関数の前後が「意味の切れ目」になっているか
- 「ここから先は事実だけが流れる」と断言できるか
ViewModel / UI 分離のチェック（Android）
- ViewModel は「判断済みの世界」だけを外に出しているか
- UI は判断せず、状態とイベントを そのまま描画／反映 しているか
- UI の onClick などから、判断済みのイベントを作成しているか
- 「この判断、UI でも ViewModel でもできるよね」と思う箇所が残っていないか
統合チェック（最重要）
- 「これは判断前／判断後のどちらか？」と即答できるか
- 新しいコードを書く前に「判断はどこで終わらせる？」と自問しているか
→ これが自然にできていれば、設計は崩れにくい