windows_devkitlisted

# windows_devkit — drive the supplied Windows test VM Use the operator-supplied VM and application state. Inspect first, start or open only what is absent, perform the test, and reset once at the end. Planning, probing, skill review, and static verification never reset the VM. ## Preflight The linked fork must have a `vm` block in `.super-coder/instance.json`, created and validated through Scripts → **Windows Test VM**. The operator owns the VM, testing snapshot, credentials, and guest toolchain. - No `vm` block: stop and ask the operator to link the VM. - Invalid configuration or missing broker: report the structured `./sc vm` error and ask the operator to run `./sc vm-broker-up`. Do not read key material, use `ssh` or `virsh` directly, or build raw broker requests. - Missing guest toolchain: ask the operator to run `configure_winbox` and re-bake. Never install tools during the test and poison the testing snapshot. - If GUI work reports adapter state `unknown` because `SC_HARNESS` is absent, the session predates the adapter identity contract. Relaunch the shell through the engine; do not add persistent harness configuration. A declared `unsupported` adapter is a capability stop, not a relaunch prompt. ## Canonical workflow 1. Assume the operator supplied a running VM with the testing application open. 2. Run `./sc vm status --json`. This is read-only: it never starts, restarts, or resets the VM. 3. If the domain is off, run `./sc vm start --json`. If it