symmetric-check

name	symmetric-check
description	コードパスの変更・バグ修正時、または計画レビュー時に使用。対称ペア（show/hide 等）とリソース生成/破棄の適用漏れを検証する。
argument-hint	[変更内容やキーワード, 例: 'result-clicked: emitSelectionUpdate を追加' / 'iconUrls Set を廃止して LruIconCache に移行']
allowed-tools	["Read","Grep","Glob"]

$ARGUMENTS に関連する対称性を2軸（コードパス対称・リソースライフサイクル対称）で検証する。 $ARGUMENTS が空の場合は、会話の直近の変更内容から対象を推定する。

実装後のコードレビューだけでなく、workspace/plan.md の計画レビューにも使える。計画段階で対称性を検証し、見落としがあれば計画を更新してから実装に進む。

背景

対称性の見落としは3種類ある:

1. コードパスの対称ペア: show を変更したら hide も要確認。片方だけ変更すると不変条件が壊れる
2. リソースライフサイクルの対称ペア: リソースの「生成 → 登録 → 破棄」の各ステップ間に早期リターンがあると、生成済み・未登録のリソースがリークする。特に追跡機構（Set/Map/配列）を廃止・移行するとき、旧機構が保護していたパスが新機構で保護されなくなるリスクが高い
3. 同型ペアの取り違え（swap）: 対称な 2 つの対象（main/results 窓、送信/受信、前景/背景）へ同じ型の値を配線するとき、対応が「順序」や「フィールド名」でしか決まっていないと、取り違えても型・テスト・スモークがすべて通る。1・2 が「片方が抜ける」漏れなら、これは「両方あるが入れ替わっている」誤りである

Step 1 — パターンの特定

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

• 影響を受ける関数 / イベント名 / 不変条件のキーワード
• 変更の種類（呼び出し追加、呼び出し削除、処理順序の変更、追跡機構の廃止・移行 等）

Step 2a — コードパスの対称ペア検索

コードベースを grep し、以下のようなペアを探す:

変更対象	確認対象
*clicked*	*double-clicked*
show / open	hide / close
enter*	exit*
expand	collapse
mount / setup	unmount / teardown
register	unregister

同じ関数やキーワードの他の呼び出し箇所も検索し、元の変更に含まれなかったコードパスを見つける。

Step 2b — リソースライフサイクルの対称性検索

変更がリソース管理に関わる場合（Blob URL、listen、Child プロセス、タイマー等）、以下を検索する:

確認項目	検索方法
生成箇所	createObjectURL / listen( / spawn / setTimeout 等を grep
登録箇所	.add( / .set( / 変数への代入
破棄箇所	revokeObjectURL / unlisten / kill / clearTimeout 等を grep

特に以下のパターンに注意:

• 生成→登録の間に早期リターン: 生成した後、登録する前に if (...) return があるパスで、生成済みリソースが破棄されない
• 追跡機構の廃止・移行: 旧 Set/Map に .add/.set していた全箇所を grep し、新機構で同等の保護があるか確認

Step 2c — 同型ペアの取り違えの検査

同じ型の値を対称な 2 対象へ配線している箇所を洗う（main / results、tx / rx、from / to 等）。newtype で分けても閉じないことがある——分岐点が「どちらの生成呼び出しの戻り値か」なら、包む時点ではまだ両方が同じ型である（#671 PR D の実例: attach(results, ..) と attach(window, ..) が同型の wake handle を返し、newtype でも取り違えは compile を通る）。

確認項目	方法
配線の起点	同型の値を作る呼び出しを列挙し、変数名でなく引数で「どちらの対象か」を確認する
中継の各段	構造体リテラルのフィールド短縮記法（Foo { a, b }）は取り違えを隠す。段ごとに読む
区別できる観測	取り違えたときにどちらか一方だけが壊れる観測を 1 つ特定する。無ければ「この誤りは検出手段が無い」と報告する

判定に「型で守られている」と書くときは、守っている箇所が起点かどうかを明示する。 起点が同型なら型は守っていない。

Step 3 — 各候補の評価

候補ごとに十分なコンテキストを読み、全実行ケースを列挙する:

候補: <file>:<line> — <説明>
  ケース A: <シナリオ> → <影響> → OK / 問題: <説明>
  ケース B: <シナリオ> → <影響> → OK / 問題: <説明>
  判定: [適用] 同じ変更が必要
        [不要] 理由: <ケースごとの明示的な根拠>

ケースごとの根拠なしの「不要」判定はレッドフラグ。根拠のない除外は未検証として扱う。

出力

根拠の規律: 全判定に根拠（file:line または grep 結果）を付ける。コードを確認せずに下した判定は [適用]/[不要] とせず [要確認] として報告する。

全候補を判定と根拠付きで列挙する。 対称ペアが見つからなかった場合は、その旨を明示する（Step 2 で実行した grep パターンを添える）。