diff --git a/.project/objectives/p2-06b-windows-runner.md b/.project/objectives/p2-06b-windows-runner.md
index a94984cf..89fd1046 100644
--- a/.project/objectives/p2-06b-windows-runner.md
+++ b/.project/objectives/p2-06b-windows-runner.md
@@ -1,30 +1,49 @@
 ---
 id: p2-06b
-title: Register a Windows runner for forgejo to produce .dll + .exe on tag push
+title: Cross-compile Windows .exe + .dll from Linux via cargo-xwin (no Windows host)
 priority: p2
-status: missing
+status: in_progress
 scope: game1
 owner: shipwright
 updated_at: 2026-04-25
 evidence:
+  - "src/simulator/build-gdext.sh (cargo-xwin invocation when TARGET=x86_64-pc-windows-msvc)"
+  - "tools/export-single.sh (BUILD_WINDOWS_DLL hook + .dll relocation post-export)"
   - .forgejo/workflows/release.yml
   - .forgejo/RUNNER_SETUP.md
 ---
 
 ## Summary
 
-Godot does not cross-compile Windows binaries from a macOS or Linux EDIT host; native Windows is required to produce both the `.exe` (Godot export) and `libmagic_civ_physics.dll` (GDExtension cargo build for `x86_64-pc-windows-msvc`). Without a registered Windows forgejo runner, every release will ship Linux + macOS only.
+Originally framed as "register a Windows runner". Re-scoped 2026-04-25 (user pick) to **Option B: cargo-xwin cross-compile from Linux** — produces MSVC-ABI Windows binaries on the existing Linux runner, no Windows hardware required. Better ABI compatibility than mingw (especially for wgpu's d3d12 backend) and zero hardware cost.
 
-Spun out from p2-06 on 2026-04-25 after `p2-06-verify-20260425` confirmed the Windows export produces only a `.tmp` placeholder when run on macOS.
+Recipe:
+1. Linux runner installs `cargo-xwin` (one-off): `cargo install cargo-xwin`
+2. Add MSVC target to rustup: `rustup target add x86_64-pc-windows-msvc`
+3. Install `clang` + `lld` (xwin uses these as linker)
+4. `bash src/simulator/build-gdext.sh x86_64-pc-windows-msvc` → cargo-xwin downloads MS SDK on first run (~1.5GB, cached at `~/.cache/cargo-xwin/`), builds `magic_civ_physics_gdext.dll`, copies to `engine/addons/magic_civ_physics/magic_civ_physics.x86_64.dll`
+5. `bash tools/export-single.sh windows <ver>` → Godot Linux exports the Windows .exe (cross-export is native to Godot), the script then relocates the .dll into `engine/addons/magic_civ_physics/` next to the binary
+
+`.forgejo/workflows/release.yml` retargeted to `runs-on: [self-hosted, linux, x86_64]` with a "Setup MSVC cross-toolchain" step.
 
 ## Acceptance
 
-- ❌ A Windows runner is registered in forgejo (RUNNER_SETUP.md updated with the new runner instructions).
-- ❌ `.forgejo/workflows/release.yml` has a Windows job that runs cargo + Godot export and uploads `MagicCivilization.exe` + `libmagic_civ_physics.dll` as part of the release bundle.
-- ❌ A tag push produces a release containing all three desktop platforms (Linux .so + binary, macOS .dylib + .app, Windows .dll + .exe).
-- ❌ Windows archive boots-and-plays a 10-turn AUTO_PLAY game on a Windows machine.
+- ✓ `tools/export-single.sh windows` runs the cargo-xwin build inline (`BUILD_WINDOWS_DLL=1` default) and relocates the produced .dll into `engine/addons/magic_civ_physics/` post-export. (2026-04-25)
+- ✓ `src/simulator/build-gdext.sh x86_64-pc-windows-msvc` invokes `cargo xwin build` and copies the .dll to `engine/addons/magic_civ_physics/magic_civ_physics.x86_64.dll`. (2026-04-25)
+- ✓ `.forgejo/workflows/release.yml` `windows_build` job uses Linux runner with cross-toolchain setup step. (2026-04-25)
+- ❌ Apricot has cargo-xwin + clang + lld + the MSVC target installed (one-off setup).
+- ❌ End-to-end smoke: `bash tools/export-single.sh windows p2-06b-verify-<stamp>` on apricot produces a `.exe` + `.dll` archive.
+- ❌ Windows archive boots-and-plays a 10-turn AUTO_PLAY game (verified on Wine on apricot, OR on a real Windows machine).
+- ❌ Update `.forgejo/RUNNER_SETUP.md` to drop the Windows runner section and document the Linux-runner cross-compile prereqs.
 
 ## Non-goals
 
 - Windows code signing (separate later objective).
 - Windows installer (.msi / .exe self-extractor) — direct .zip is fine for EA.
+- mingw-w64 GNU toolchain path (Option A); kept as fallback if xwin proves too fragile but not pursued.
+
+## Caveats
+
+- cargo-xwin's first build downloads ~1.5GB of MS SDK; cache it on the runner (`~/.cache/cargo-xwin/`).
+- `wgpu 24` (in `mc-compute`, gated by `gpu` feature) uses d3d12-rs on Windows — should link cleanly under MSVC ABI. If linker errors surface, build the Windows .dll with `--no-default-features` to drop the GPU MCTS path; Game 1 ships fine without it (CPU rollouts only).
+- Wine smoke is acceptable for the boots-and-plays gate as long as the .pck loads, GDExtension classes register, and AUTO_PLAY reaches a turn-end without errors.