Click Path Audit

# /click-path-audit — 行動フロー監査

静的コード読み取りが見落とすバグを見つけ：状態相互作用の副作用、順序を付けられた呼び出し間の競合状態、および互いに静かに取り消すハンドラー。

## この解決する問題

従来のデバッグチェック：
- 関数が存在しますか？（不足している配線）
- クラッシュしますか？（ランタイムエラー）
- 正しいタイプを返しますか？（データフロー）

しかし、それはチェック**しません**：
- **最終UI状態がボタンラベルが約束したものと一致しますか？**
- **関数Bが関数Aが行ったばかりをサイレンス的に取り消しますか？**
- **共有状態（Zustand/Redux/context）に意図した操作をキャンセルする副作用がありますか？**

実例：「新しいメール」ボタンが`setComposeMode(true)`を呼び出してから`selectThread(null)`。両方は個別に機能しました。しかし、`selectThread`には`composeMode: false`をリセットする副作用がありました。ボタンは何もしなかった。54のバグは体系的なデバッグによって見つかりました — これは見落とされました。

---

## 動作方法

対象領域のすべてのインタラクティブなタッチポイントについて：

```
1. ハンドラーを特定（onClick、onSubmit、onChangeなど）
2. ハンドラーのすべての関数呼び出しを**順序で**追跡
3. 各関数呼び出し**について**：
   a. どの状態を読んでいますか？
   b. どの状態を書き込んでいますか？
   c. 共有状態に副作用がありますか？
   d. 副作用として状態をリセット/クリアしますか？
4. チェック：後の呼び出しが以前の呼び出しからの状態変更を取り消しますか？
5. チェック：最終状態はユーザーがボタンラベルから期待するもの？
6. チェック：競合状態がありますか（非同期呼び出しが間違った順序で解決される）？
```

---

## 実行ステップ

### ステップ1：マップ状態ストア

任意のタッチポイントを監査する前に、すべての状態ストアアクションの副作用マップを構築：

```
範囲内の各Zustand ストア / React コンテキストについて：
  各アクション/セッター：
    - どのフィールドをセットしますか？
    - 副作用として他のフィールドをリセットしますか？
    - ドキュメント：actionName → {sets: [...], resets: [...]}
```

これは重要な参照です。「新しいメール」バグは`selectThread`が`composeMode`をリセットしていることを知らないと見えなくなりました。

**出力形式：**