remote_seatslisted

# remote_seats — two postures, one broker A shell drives another machine only through the host-side vm-broker. It holds the libvirt connection, every SSH key, and the known-hosts files; the shell calls `./sc vm` and `./sc remote`, which speak to the broker's unix socket, and never runs `ssh`, `scp`, or `virsh` itself — on bare metal or in a sandbox. That is the whole access model (decision #353). Two postures share it (decision #355): | Posture | Who owns lifecycle | Shell verbs | |---|---|---| | 1 · host to VM | this engine, through `./sc vm` | adopt, status, start, stop, restart, snapshot, bake, reset (`--running` or `--off`), push, pull, exec, capture | | 2 · VM to VM | the FnB or the upstream instance | `./sc remote` status, exec, push, pull | Under posture 2 lifecycle and snapshots are someone else's job: never ask for a start, reset, or snapshot on a named remote; report the need instead. ## Set up once per fork The FnB links the targets; each command writes only its own block of the gitignored `instance.json` and reports whether the broker is up plus the command that starts it (`./sc vm-broker-up`). ```bash ./sc vm adopt --domain <libvirt-domain> --ssh-user <guest-account> ./sc vm init --domain <libvirt-domain> --snapshot <baseline> \ --ssh-host <guest-address> --ssh-user <guest-user> --ssh-key-path </abs/host/key> ./sc remote add <name> --host <address> --user <user> --key-path </abs/host/key> [--port 22] [--known-hosts-path </abs/path>] ./sc ts init ...