Runner setup verified on clean Windows and Linux machines #199

Guided runner setup works and is verified on one Windows 11 Pro PC that was already set up. Verify it end to end on the computers it's for, and fix what's wrong.

1. A real Set up on clean Windows, end to end

In Hyper-V VMs on the owner's PC (with nested virtualization on: Set-VMProcessor -ExposeVirtualizationExtensions $true), install desktop 0.3.9 on each of these:

• a. Windows 11 Pro with nothing turned on. Expect both cards to need setting up, then one Set up, one UAC prompt, Restart needed and Restart now. After the restart, g1t opens by itself, downloads the image, and both kinds of job run.
• b. Windows 11 Home. Expect Linux jobs set up and running, and Windows jobs to say "Not in Windows Home".
• c. A VM with nested virtualization off. Expect "This VM can't run the sandbox" on both cards, and never Set up.
• d. Windows 10 22H2 with the WSL built into Windows. Expect "WSL needs an update", and that Set up updates it.

Screenshot every state from the real app. Check Win32_OptionalFeature InstallState right after an enable, before any restart: the restart logic assumes it is either 1 or 2.

2. Linux, on a real machine or a VM

Cover each of these: no KVM, no access to /dev/kvm (not in the kvm group), no QEMU, and Sysbox present. Check that each card's Copy command works in a terminal. Consider a pkexec one-click fix for kvm_group and qemu, but only if it can be as safe and plain as Windows' Set up.

Also

Check that the Home Ask box work, committed by mistake as 4491f3a4 under the runner setup's message and deployed, is what that session meant to ship (#145). Comment there with what you find.

Background: guided runner setup (shipped 2026-10-15, #142)

Anyone who installs the desktop app on a clean computer should get its runner running Linux jobs and Windows jobs (and later macOS jobs) without knowing what WSL, Hyper-V, virtualization or Docker are. Read apps/docs/src/content/docs/guides/desktop.md, "Getting the runner running".

How it works (g1t-runner 0.3.5, desktop 0.3.9):

• g1t-runner sandbox status --json gives each capability its needs, whatever must come first listed first: restart, windows_update, virtualization, nested_virtualization, vm_platform, wsl, wsl_update, windows_edition, windows_sandbox, kvm_module, kvm_group, qemu, macos_update, homebrew, vfkit (crates/runner/src/selfhosted/needs.rs). A need is named only when the computer says so for certain. Windows facts come from one PowerShell CIM probe and are kept in the state folder's windows-facts.json until Windows restarts. Set up's restart is the state folder's restart-pending, which holds the boot it was written in.
• The app's words for each need are in diagnosis.rs need_words. Set up (apps/desktop/src-tauri/src/runner/setup.rs) runs one fixed PowerShell script as -EncodedCommand through ShellExecuteExW "runas". The script turns on VirtualMachinePlatform and Containers-DisposableClientVM, and runs wsl --install --no-distribution / wsl --update (--web-download first). Exit code 3010 means a restart is needed. Restart now asks with a native MessageBox, and RunOnce reopens g1t after the restart.
• The cards for each kind of job are independent. Whole-runner code is NeedsSetup.

Already verified: the published 0.3.5 runner on the owner's PC (no needs), the elevated script with nothing to do (UAC, then Done), the script unelevated (fails plainly and changes nothing), its WSL step (--version), the fixture scenario tests, and the rendered Runner window and docs.

Rules (non-negotiable)

• Runner jobs run in host-proof sandboxes. Docker and running directly on the computer are only ever the person's choice, never a fallback.
• The app must stay responsive: never block the main thread, and never hold a lock across a Tauri menu or window call (that froze 0.3.7).
• Never restart the owner's PC or toggle its Windows features without the owner's OK for that specific restart. Use VMs.
• Ask before cutting any desktop or runner release. A release means: bump version (crates/runner/Cargo.toml, apps/desktop/src-tauri/Cargo.toml), merge, and push runner-v<version> / desktop-v<version> to the g1t remote. The workflows refuse a tag whose version doesn't match Cargo.toml.
• On Windows, run cargo from PowerShell, not Git Bash (it needs the VS Build Tools C++ toolchain). The target directories are shared: target/ at the root for the runner, and apps/desktop/src-tauri/target for the app.

Validation for every change

cargo test -p g1t-runner; in apps/desktop/src-tauri, cargo test and cargo clippy --all-targets; the ignored live tests where they apply (cargo test -- --ignored this_windows, the_script_runs, the_wsl_step; as_administrator needs a UAC click); docs rendered with astro dev. Report what was verified on real machines and what was verified only in fixtures.

How to work on this repository

• Claim this item before you start (g1t work claim <number>), and add G1t-Session: $G1T_SESSION to every commit.
• Other sessions share the main checkout: work in a worktree of your own and stage only your own files.
• Pushing to main deploys production, and pushes to main and release tags are the owner's. Land the work through a pull request on this item, or commit locally and hand the owner the exact git -C <path> push ….
• Shipped means on main and deployed. Check it live with real data and look at the rendered pages: a status code doesn't show it works.
• Docs ship in the same change as the feature (guides, reference, llms.txt), to a high standard.
• User-facing text never names other products or compares g1t to them. Internal notes and code comments may.