WSL Documentation Boundary

Dubnium uses WSL in two different ways, and the docs should keep those roles separate.

WSL As Build Environment

Use WSL as a convenient Linux build environment. This includes:

• building the custom installer ISO
• preparing the local seed-model bundle
• running Nix commands that do not need bare-metal hardware

This role does not imply the wsl host target is being installed or validated. For the installer flow, WSL prepares artifacts and the platform writer prepares the USB unless the USB disk is deliberately exposed to WSL.

Primary docs:

• Build Installer Artifacts From WSL
• Custom Installer USB
• Fresh Install Checklist
• Model Seeding

WSL As Validation Target

Use the .#wsl host target only inside an existing nix-community/NixOS-WSL distro. This target validates shared Dubnium module composition and activation before touching the real workstation. It keeps resource-heavy services such as vllm and k3s disabled by default.

This role does not prove bare-metal behavior. Passing WSL validation does not prove EFI, bootloader, Hyprland, audio, or final GPU behavior for .#workstation.

Primary docs:

• WSL Bring-Up
• ADR-0007: WSL Is a Headless Validation Target

Boundary Rules

• Keep bare-metal install steps in fresh-install and custom-installer docs.
• Keep .#wsl activation and validation steps in the WSL bring-up runbook.
• Do not use the fresh-install checklist for WSL bring-up.
• Do not use WSL results as proof that workstation hardware configuration is correct.
• When a command is meant to run inside WSL, label it as WSL or Bash.