Build OpenShell-MXC for Windows

This skill maintains the existing native Windows MSVC build lane in the OpenShell repository. The Windows lane is already present in main; do not treat this skill as a first-time porting recipe unless the user explicitly asks for a new fork or a from-scratch bring-up.

The lane is build-only. It validates that OpenShell can compile and test on Windows MSVC for the supported deliverables:

• openshell-gateway.exe
• openshell.exe

It intentionally does not make Windows a Docker, Kubernetes, Podman, or VM runtime host.

Current Repository Shape

The Windows build lane is implemented by these tracked files:

Use the code that is already in the repo. Do not generate a parallel Windows build system, duplicate the wrapper, or add repository automation that the user did not request.

Scope

In scope:

• Refreshing a local checkout to the latest upstream GitHub main.
• Maintaining tasks/windows.toml and tasks/scripts/windows-msvc.ps1.
• Running x64 and ARM64 MSVC checks.
• Building x64 and ARM64 release binaries for openshell-gateway and

openshell.

• Running workspace tests on a native x64 or ARM64 host.
• Running focused unsupported-driver contract tests.
• Reporting test counts, skipped/gated areas, warnings, artifacts, and logs.
• Keeping Linux and macOS build paths unchanged.
• Keeping unsupported Windows compute drivers explicit and testable.

Out of scope:

• Docker Desktop support on Windows.
• Kubernetes support on Windows.
• Podman, Podman machine, or Podman Desktop support on Windows.
• VM, Hyper-V, WSL, libkrun, or VM-backed sandbox execution on Windows.
• New MXC compute driver crate.
• OpenShell to MXC policy translation.
• Windows named-pipe driver IPC.
• Windows Credential Manager or DPAPI integration.
• MSI, WinGet, Windows service registration, or installer work.
• Windows supervisor runtime port.

Hard Rules

• Do not enable Docker, Kubernetes, Podman, or VM runtimes on Windows.
• Do not build, package, ship, or smoke-test standalone Windows binaries for

unsupported compute drivers.

• Exclude unsupported Windows runtime crates from the Windows gateway dependency graph.
• Unsupported Windows runtime entry points must return a clear unsupported

error.

• Keep Windows-specific code behind #[cfg(target_os = "windows")].
• Keep Unix/Linux-only code behind #[cfg(unix)] or

#[cfg(target_os = "linux")].

• Do not modify the default Linux mise run ci path unless the user explicitly

asks for it.

• Use mise run --skip-tools windows:* for Windows validation. The Windows

toolchain is rustup plus Visual Studio Build Tools, not mise-provisioned Rust.

• Prefer one cross-platform run command when the underlying tool supports it

(for example, npm --prefix). Add run_windows only when the Windows shell or validation contract genuinely differs.

Recommended Checkout Flow

From a fork checkout where upstream points to the official NVIDIA/OpenShell GitHub repository, use:

git fetch upstream main
git switch main
git merge --ff-only upstream/main
git branch --set-upstream-to=upstream/main main
git status --short --branch

For a direct checkout of the official repository, use origin instead of upstream. Confirm the remote URLs with git remote -v before refreshing.

If there are local changes, preserve or resolve them before refreshing. Do not discard user work unless the user explicitly asks to clean the checkout.

Prerequisites

The lane targets a Windows host with Visual Studio Build Tools and rustup.

Do not install Visual Studio, Rust, Docker, Kubernetes, Podman, WSL, or Hyper-V from this skill.

Environment Variables

Legacy fork variables such as OPENSHELLUPSTREAM, OPENSHELLMXCFORKDIR, and OPENSHELLMXCFORK_BRANCH are no longer part of the normal maintenance workflow. Use them only if the user explicitly asks for a new disposable fork.

Validation Workflow

Run the smallest useful slice first, then broaden:

mise run --skip-tools windows:check:x64
mise run --skip-tools windows:check:arm64
mise run --skip-tools windows:build:x64
mise run --skip-tools windows:build:arm64
mise run --skip-tools windows:test:x64
mise run --skip-tools windows:test:unsupported:x64

For full validation, detect the Windows host architecture first and choose the native lane dynamically:

$arch = [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture
switch ($arch.ToString()) {
    "X64" {
        mise run --skip-tools windows:ci
    }
    "Arm64" {
        mise run --skip-tools windows:check:arm64
        mise run --skip-tools windows:build:arm64
        mise run --skip-tools windows:test:arm64
        mise run --skip-tools windows:test:unsupported:arm64
        mise run --skip-tools windows:artifacts
    }
    default {
        throw "Unsupported Windows host architecture for OpenShell MSVC validation: $arch"
    }
}

On x64 hosts, windows:ci is the full current CI contract and runs in this order:

1. x64 check.
2. ARM64 check, unless OPENSHELLMXCSKIP_ARM64=1.
3. x64 release build.
4. ARM64 release build, unless skipped.
5. Native x64 workspace tests.
6. Focused unsupported-driver contract tests.
7. Artifact reporting.

The GitHub Actions jobs use architecture-specific Swatinem/rust-cache entries for the Cargo registry and dependency target artifacts. Failed runs also save their usable dependency artifacts. The workflow remains manually dispatched until cache-hit runtimes justify restoring automatic triggers.

The ARM64 check/build steps in this x64-host contract are cross-builds. The wrapper discovers and adds host-native LLVM and Ninja to PATH, requires the ARM64 compiler and Spectre-mitigated libraries, lets ARM64 crypto crates select clang-cl, and keeps bundled Z3 on native MSVC cl.exe with CMake's Visual Studio ARM64 generator. Z3 does not use Ninja because z3-sys 0.10.9 passes the MSBuild-only -m argument.

On ARM64 hosts, validate the native ARM64 check, build, and test path. The wrapper rejects test targets that do not match the host architecture, so x64 compatibility under emulation is not part of these tasks. The aggregate windows:ci task remains the x64-host CI contract; run the explicit ARM64 commands above on an ARM64 host.

The repository-wide mise run pre-commit task is also supported on Windows. Its Rust check, Clippy, and test dependencies enter the same MSVC environment for the native host target and clear inherited RUSTC_WRAPPER. Linux glibc installer tests and Linux service/RPM packaging-asset tests skip explicitly; the Linux build-environment shell-helper test also skips; cross-platform checks continue to run. The blocking Windows Clippy pass excludes unsupported Windows runtime packages as top-level targets. It allows only unused imports, dead code, and unused async functions that result from cfg-gated Windows stubs; other warnings remain errors.

The wrapper limits Cargo to four jobs by default and serializes wrapper-owned Cargo commands with a host-local mutex. It deliberately does not set CL or CL: those variables are also consumed by clang-cl, where a global MSVC option such as /MP4 can be interpreted as an input file and break ARM64 crypto dependency builds.

Expected Task Behavior

The unsupported driver package excludes are intentional. They prevent standalone driver crates from being top-level Windows check/test targets while allowing required libraries and Windows contracts to compile through gateway dependencies. This includes the Kubernetes Secrets and Vault packages: their libraries remain in the gateway build graph, but their Unix-socket standalone binaries do not.

Unsupported Driver Contract

Windows must continue to reject unsupported compute drivers clearly.

The focused contract tasks for either native architecture run:

windows_builtin_compute_drivers_report_unsupported

These tests are also included in the full x64 workspace test run; the focused task intentionally re-runs them so unsupported Windows behavior is visible in the CI report.

Test Accounting Guidance

When reporting windows:ci, distinguish these categories:

• Passed tests from the full x64 workspace test log.
• Passed tests from the full ARM64 workspace test log when run on a native

ARM64 host.

• The focused unsupported-contract re-run.
• Explicit Cargo ignored tests, usually ignored doc examples.
• Tests hidden by #[cfg(not(target_os = "windows"))]; these often appear as

running 0 tests, not as ignored tests.

• Test-name filtered out counts from focused cargo test invocations.
• Package-level exclusions for unsupported Windows crates; Cargo does not report

those as ignored tests.

Useful log files:

The first bundled-Z3 check or test can spend several minutes in CMake/MSBuild without much console output because Cargo output is redirected to the log. Look for native MSBuild.exe workers before treating the process as stalled. The wrapper fetches the pinned Z3 source through Git before Cargo starts. It caches under an explicitly configured CARGOTARGETDIR, or under the current user's local application data directory when Cargo uses its default target tree. Concurrent commands publish the validated source through an atomic directory rename, so x64 and ARM64 validation can share the cache safely. The wrapper does not rely on the rate-limited GitHub Contents API used by z3-sys. A failed fetch reports the partial checkout path for diagnosis. The artifact report computes SHA256 through .NET directly and does not rely on the Get-FileHash module being available inside the mise-launched Windows PowerShell process.

Common Fix Patterns

When Windows validation fails:

1. Identify whether the error is from a top-level Windows deliverable, a

gateway dependency stub, or a Unix-only module leaking into the Windows build.

1. Prefer existing local patterns in the same crate.
2. Gate Unix imports and modules with #[cfg(unix)] or

#[cfg(target_os = "linux")].

1. Add or preserve Windows stubs that return unsupported errors.
2. Keep Linux behavior unchanged.
3. Run cargo fmt --all, git diff --check, and the relevant windows:*

tasks after changes.

Do not add broad abstractions or new Windows runtime support to satisfy a build error. If a missing runtime feature is required, stop and propose a follow-on skill or design doc.

Final Report Checklist

Every substantial Windows build run should report: