副作用分類からヒューリスティクスを撤廃する

[6uclz1]

--read-only の保証がコマンド名の語尾に依存していた。

read_suffixes = (" get", " info", " list", " find", " observe", " keys")
if command_name.endswith(read_suffixes):
    return True

この戻り値が read_only_remote_command_names() を経て _client_core._dispatch() の --read-only ゲートになる。" get" で終わる書き込みコマンドが追加された瞬間に --read-only は静かに破れ、テストでは「命名規約に従っているか」しか検証できない。

_DESTRUCTIVE_COMMANDS も同じ問題を持つ。コマンド定義から離れた手書き frozenset で、分類漏れは検出されず write（requires_confirmation=False）として黙って扱われる。

変更

• _is_read_command() を削除（未使用関数を残さない）。
• _DESTRUCTIVE_COMMANDS frozenset を削除。
• 全 250 コマンドを _SIDE_EFFECTS に明示宣言。
• _side_effect_spec() は未宣言コマンドに対して 例外を投げる。デフォルト値を返さないため、宣言漏れがあれば command_specs() の呼び出し自体が落ちて CI が止まる。

差分ゼロの確認

移行前の分類を機械的に書き出し、移行後の command_specs() 出力とプログラムで突合して 完全一致を確認済み。tests/snapshots/public_contract_snapshot.json は無変更。分類が変わったコマンドは なし。

idempotent は現状「read なら True」の一律であり、本 PR では意図的に見直していない（分類変更と表現形式変更を混ぜると差分ゼロの検証ができなくなるため）。transport tempo set などの個別見直しは後続の別 PR で 1 件ずつ根拠を添えて行う。

指示からの逸脱 1 点（レビュー希望）

テーブルは 1 行ごとに SideEffectSpec(...) を書き下すのではなく、共有の frozen 定数 3 つ（_READ / _WRITE / _DESTRUCTIVE）を使っている。

現行の分類は実測で ちょうど 3 通り（write 136 / read 88 / destructive 26）しか存在しないため無損失であり、1 行ごとの構築子展開は DRY 原則と重複検出閾値の両方に逆らう。コマンドごとの宣言が明示的である点は変わらない。

範囲外だが記録した依存

public_command_names() が commands/ を正規表現で走査している問題（レビュー項目 2.2）は本 PR では直していない。ただし grep が壊れるとテーブルの網羅性検証も同時に無意味になるという依存関係を command_specs.py の該当箇所にコメントとして明記し、2.3 の descriptor 化で両方が解消される見込みであることも書き添えた。

テスト

• public_command_names() の全要素が _SIDE_EFFECTS に存在すること（両方向）
• 未宣言コマンド名で _side_effect_spec() を呼ぶと例外になること
• kind="destructive" ⇒ requires_confirmation=True、kind="read" ⇒ idempotent=True
• 動的生成されるコマンド族（synth {type} {keys|set|observe} 等）が個別に宣言されていること
• --read-only で到達可能な remote コマンドに非 read が混ざらないこと

公開契約への影響

なし（意図的にゼロ）。

検証

dev_checks / ruff check / ruff format --check / pytest（1019 passed）/ check_remote_script_runtime.py / generate_skill_docs.py + git diff --exit-code / update_public_contract_snapshot.py（差分なし）。

品質ハーネスは pristine main の時点で既に exit 1（baseline 陳腐化 + 既存 fail 1 件）。本 PR はテーブル 250 行を追加しても fail-level violation 集合を main と一致に保ち、警告も 1 件も増やしていない。

Ableton Live 手動検証

不要。純粋な機械的移行であり Live の挙動に触れない。

🤖 Generated with Claude Code