[codex] reduce command layer duplication and cache runtime client

[6uclz1]

概要

コマンド層とランタイム周辺で、責務の重複とエラー分類の曖昧さが混在していたため、実装の見通しと将来の拡張性を改善しました。今回の差分では、RuntimeContext のクライアント生成を 1 コンテキスト 1 回に統一し、プロトコル系の失敗理由をより明示的に扱えるようにしています。

何が問題だったか（利用者への影響）

これまで runtime.get_client() は呼び出しのたびに AbletonClient を新規生成しており、1 つのコマンド実行内で複数回参照した場合でも毎回初期化される状態でした。現時点で即時の体感劣化は限定的でも、クライアント初期化コストや接続準備が将来増えた場合に、不要なオーバーヘッドやテスト上の差し替え難易度を招く構造でした。

加えて、プロトコル応答の異常系で失敗理由の分類が粗く、利用者や開発者が「どのレイヤで壊れたのか」を追いにくい箇所がありました。結果として、トラブル時の切り分けに余計な手間が発生しやすい状態でした。

根本原因

ランタイムが「設定を保持する責務」と「クライアントライフサイクルを管理する責務」を分離しきれておらず、get_client() が毎回コンストラクタを直呼びしていました。これにより、呼び出し側が同一実行コンテキスト内での一貫した client インスタンスを前提にできませんでした。

また、プロトコル処理ではエラー種別を利用者が判断しやすい粒度で表現する設計が不足しており、異常系のセマンティクスが明確でない箇所が残っていました。

どう直したか

RuntimeContext に lazy 初期化の client 保持 (_client) と取得メソッドを追加し、get_client(ctx) は常にその経路を使うように変更しました。これにより、同一 runtime では 1 回だけ AbletonClient を生成し再利用します。

プロトコル周辺は、エラー分類を明確化する方向で整理し、関連するテストを更新・追加して期待値を固定しました。

変更ファイル

• src/ableton_cli/runtime.py
• src/ableton_cli/client/protocol.py
• src/ableton_cli/errors.py
• tests/test_runtime_quiet.py
• tests/test_protocol.py
• tests/test_exit_codes.py

検証

uv run python -m ableton_cli.dev_checks を実行し、以下を通過しています。

• uv run ruff check .
• uv run ruff format --check .
• uv run pytest（393 tests passed）