state-check

name	state-check
description	UI モード・状態遷移・ガード条件の追加・変更時、または計画レビュー時に使用。既存モードとの直交性・リセット経路・入力分岐・SPEC §8.6 整合を検証する。
argument-hint	[変更内容, 例: 'InstantCommandMode 追加' / 'indexing ガードを handleInput に追加']
allowed-tools	["Read","Grep","Glob"]

$ARGUMENTS のモード・状態遷移・ガード条件について、既存の状態モデルとの整合を検証する。 $ARGUMENTS が空の場合は、会話の直近の変更内容から対象を推定する。

実装後のコードレビューだけでなく、workspace/plan.md の計画レビューにも使える。計画段階で「このモード追加は既存モデルと整合するか？」を検証し、見落としがあれば計画を更新してから実装に進む。

背景

このプロダクトの UI 状態は複数の直交・排他モードの組み合わせで動く（SPEC.md §8.6 / §18.5 / §19.7）:

• folderState（フォルダ展開）と toolSelectionState（ツール選択）は直交
• interpKind() の instant は plain（NormalMode）/ command（CommandMode）と排他（入力解釈は単一の判別子値。query+prefix から純粋導出）
• 優先度: toolSelectionState !== null > folderState !== null > 通常モード

モードやガードを1つ追加・変更すると、既存の全モードとの組み合わせそれぞれについて「排他か・直交か・どちらが優先か」の明示的な判断が必要になる。判断されなかった組み合わせは「たまたま動く」状態で残り、別の変更で壊れる。

典型的なバグパターン:

1. リセット漏れ: 新モードのシグナルが resetForShow() でクリアされず、ホットキー再表示時に前回の状態が残る
2. Escape 連鎖の崩れ: Escape は「ツール選択 → フォルダ展開 → ウィンドウ非表示」の順で内側から復帰する（SPEC §8.1）。新モードがこの連鎖のどこに入るか未定義
3. 入力分岐の暗黙ホールド: 新モード中の Enter / Shift+Enter / ArrowLeft / ArrowRight / クリックの挙動が未定義のまま、既存分岐が偶然マッチする
4. ガードの過剰阻害: 正常運用向けの早期リターンガード（if (indexing()) return 等）が、初回起動・エラーリカバリ・別モードの特殊パスを意図せず塞ぐ（AGENTS.md「初回フローとガードの相互作用」）
5. SPEC §8.6 の陳腐化: 状態遷移図と「遷移ルール要約」が実装と乖離する

Step 1 — 変更の特定

$ARGUMENTS から以下を抽出する:

• 追加・変更されるモード / シグナル / ガード条件
• 変更の種類（モード新設、遷移条件の変更、ガードの追加・削除）

対象コードを読む。主な置き場所: src-tauri/src/egui_shell/search_state.rs（モード・view stack・reset-on-show の純粋核）、src-tauri/src/egui_shell/view.rs（キー入力分岐・driver）、src-tauri/src/egui_shell/lifecycle.rs（show/hide・blur 判定）。

Step 2 — 直交性マトリクス

新規・変更モードと既存の各状態の組み合わせを全列挙し、それぞれ明示的に判定する:

組み合わせ: <新モード> × <既存状態>
  同時成立: [排他（同時に true にならない）/ 直交（同時成立しうる）]
  直交の場合の優先度: <どちらの挙動が勝つか> — 根拠: <SPEC 該当節 / コード箇所>
  判定: [整合 / 未定義 — 要対処: <内容>]

最低限確認する既存状態: folderState、toolSelectionState、interpKind()（plain/command/instant。command=/ プレフィックス、instant=コマンドプレフィックス）、indexing、launching。

「未定義だが現状動いている」はレッドフラグ。偶然の動作として記録し、明示化を提案する。

Step 3 — リセット経路の検証

新規・変更される状態シグナルについて、全リセット経路を確認する:

リセット経路	トリガー	確認内容
resetForShow()	ホットキー再表示（window-shown）	新シグナルがクリアされるか
Escape 連鎖	Escape キー	連鎖のどの位置で復帰するか（内側優先）
実行完了	Enter / クリックによる起動成功	クエリクリア・非表示と同時に状態が片付くか
モード離脱	プレフィックス削除・フォルダ離脱等	デバウンス/RAF のキャンセルを伴うか（ui ルール）

各経路について「リセットされる / 意図的に保持 — 理由」を明示する。理由なしの保持はレッドフラグ。

Step 4 — 入力イベント分岐の網羅

新モード中（またはガード変更後）の各入力イベントについて、挙動を明示的に判定する:

イベント: <Enter / Shift+Enter / ArrowRight / ArrowLeft / Escape / 文字入力 / クリック / ダブルクリック>
  新モード中の挙動: <実行する / 無効化 / 別モードへ委譲>
  実装箇所: <file:line>（計画レビュー時: plan.md に記述があるか）
  判定: [明示済み / 未定義 — 既存分岐 <どれ> が偶然マッチしている]

ガードを追加・変更した場合は、そのガードが true になる全コンテキストを列挙し、初回起動・インデックス構築中・エラーリカバリの特殊パスを阻害しないか確認する。

Step 5 — SPEC.md §8.6 との整合

1. SPEC.md §8.6 の mermaid 状態遷移図を読む
2. 追加・変更された遷移が図に反映されているか（状態・遷移矢印・ガード条件 [...]）
3. 「遷移ルール要約」の箇条書きに新しいガード条件が追記されているか
4. モード固有の節（§15.4 / §18.5 / §19.7 等）に「他モードとの相互作用」の記述が必要か

乖離があれば SPEC.md の更新内容を具体的に提案する（仕様変更なら SPEC 先行、AGENTS.md「バグか仕様変更かを判定する」）。

出力

根拠の規律: 全判定に根拠（file:line・SPEC 該当節・grep 結果のいずれか）を付ける。コードを確認せずに下した判定は [整合] とせず [未定義] として報告する。

直交性マトリクス・リセット経路・入力分岐の判定を根拠付きで列挙する。 問題が見つかった場合は修正案（ガード追加 / リセット追加 / SPEC 更新）を提示する。 全項目が整合する場合は「状態モデルとの不整合なし」と明示する。