windows_devkitlisted

# windows_devkit — driving the Windows Test VM Real Windows, for the testing Wine can't fake: MSI installers, services, the registry, system-level behavior. Opt-in + link-only — the operator runs the VM; you drive a verified loop against it. Devs build + test; the reviewer independently verifies the dev's candidate artifact with exec → capture → reset. Grant is explicit, per-fork (`common=0`). ## Precondition — the link is configured VM config = `vm` key in `.super-coder/instance.json` (set via the GUI Scripts → **Windows Test VM** wizard, which live-tests every field before save): ```json "vm": { "domain": "win-test", "ssh_host": "127.0.0.1", "ssh_port": 22, "ssh_user": "tester", "ssh_key_path": "~/.ssh/sc_win_test", "transfer_dir": "/var/sc/win-xfer", "snapshot": "clean", "libvirt_uri": "qemu:///system" } ``` `libvirt_uri` optional — set it when the domain is system-scope (the default `qemu:///session` can't see it); omit otherwise. - No `vm` block → no VM linked: stop + ask the operator to run the wizard. - `configure_winbox` must also have run, or the box has no toolchain — the wizard's `toolchain` check confirms it did. - A wrong field → fix it in the wizard (it re-validates); NEVER hand-edit secrets into config. - `ssh_key_path` = a path, never key material. Never read it — the key lives host-side with the broker (below). ## Drive through the host broker — never ssh/virsh directly You run inside the sandbox; the VM lives on the host