diff --git a/.agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.i18n.yaml b/.agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.i18n.yaml
index eb3909cc4e..fb51fef157 100644
--- a/.agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.i18n.yaml
+++ b/.agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.i18n.yaml
@@ -1,6 +1,6 @@
 # Bilingual-pair consistency record (docs/i18n/README.md): the git blob hash of each
 # side as of the last confirmed-consistent state. Both languages carry equal authority;
 # after editing either side, bring the other along and re-record with:
-#   pnpm run verify-translation-pairing --write
-2026-07-27-wine-windows-gates-experiment.md: 9f7856dfef229f8f02c85f5968082a0c857bbc94
-2026-07-27-wine-windows-gates-experiment.zh.md: cb185293d7f22723a96448a774bd27dd31e1bc28
+#   pnpm run verify-translation-pairing --write .agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.md
+2026-07-27-wine-windows-gates-experiment.md: 9e2db947eceee7e3e2fee63f8fe2ac90de1cd13d
+2026-07-27-wine-windows-gates-experiment.zh.md: a4b938faa6ae27bd068db9a952ebb1432ec7ca3f
diff --git a/.agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.md b/.agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.md
index 9f7856dfef..9e2db947ec 100644
--- a/.agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.md
+++ b/.agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.md
@@ -12,9 +12,11 @@ The open question: can a plain Linux runner produce an equivalent win32 signal f
 
 ## Proposal
 
-[exp-wine-windows.yml](../../../../.github/workflows/exp-wine-windows.yml) (self-path-filtered, plus manual dispatch) runs the blocking gate commands on `ubuntu-latest` under Wine with real Windows binaries: a downloaded win-x64 Node.js executes `tsc -b`, `tsdown`, and the VitePress production build, so the win32 branches of the toolchain — backslash path handling, `CreateProcess` spawn semantics, PE loading of `@esbuild/win32-x64`, and the rolldown/rollup MSVC `.node` addons — actually execute.
+[exp-wine-windows.yml](../../../../.github/workflows/exp-wine-windows.yml) (self-path-filtered, plus manual dispatch) runs the blocking gate commands on `ubuntu-latest` under Wine with real Windows binaries: a checksum-verified win-x64 Node.js executes `tsc -b`, `tsdown`, and the VitePress production build, so the win32 branches of the toolchain — backslash path handling, `CreateProcess` spawn semantics, PE loading of `@esbuild/win32-x64`, and the rolldown/rollup MSVC `.node` addons — actually execute.
 
-Dependencies install natively on Linux with `supportedArchitectures` extended to win32-x64, which materializes the Windows platform packages in the same store; the cmd-shim layer is bypassed by invoking each tool's JavaScript entrypoint directly, the same processes `run-gates` ultimately spawns.
+Dependencies install natively on Linux with `supportedArchitectures` extended to win32-x64, which materializes the Windows platform packages in the same store; the cmd-shim layer is bypassed by invoking each tool's JavaScript entrypoint directly, the same processes `run-gates` ultimately spawns. `nodeLinker: hoisted` is load-bearing, not stylistic: the independent prototype in [PR #689](https://github.com/deepseek-harness/deepseek-harness/pull/689) kept pnpm's default isolated layout — including a faithful offline Windows-pnpm re-install over a Linux-prefetched store — and Windows Node under Wine still could not resolve `@esbuild/win32-x64` or load the koffi prebuild through the isolated symlink chain, failing before any repository gate ran. A flat layout with real files is what makes the gates reachable at all; #689's checksum pinning is adopted, while its Windows-pnpm-installs-the-tree goal is explicitly given up (the install contract stays Linux-tested here).
+
+The lane targets the wall clock of the Linux CI jobs (about two minutes), from four levers: the master-refreshed pnpm store cache (restore-only, same key as ci.yml), Wine provisioning (apt install, Windows Node download, `wineboot`) running concurrently with `pnpm install`, the two blocking surfaces running concurrently — the same shape `run-gates` gives them on native Windows — and an apt-archive cache keyed on the runner image so Wine's package downloads are paid once per image version.
 
 This is deliberately a fidelity probe, not a drop-in replacement: Wine reimplements the Win32 API over a case-sensitive ext4 (NTFS case-insensitivity is not emulated by default), provides no ConPTY, and substitutes its own security-descriptor and `MoveFileExW` semantics — exactly the surfaces the repo's `win32.ts` modules and PTY backend care about. The experiment measures which blocking gates pass, which fail for Wine reasons rather than product reasons, and the wall-clock cost relative to the recorded Windows benchmark lanes.
 
@@ -26,6 +28,8 @@ Promotion, if the verdict is positive: fold the Wine lane in as the pull-request
 
 **A full Windows guest under QEMU/KVM inside the Linux runner.** Real NT kernel, so full fidelity including case-insensitive NTFS and ConPTY — but tens of minutes of image download and unattended install before the first gate runs. Explored as the sibling experiment branch `exp/kvm-windows-ci`; the two experiments price fidelity against latency.
 
+**Windows pnpm performing the install under Wine ([PR #689](https://github.com/deepseek-harness/deepseek-harness/pull/689)).** The higher-fidelity variant of this same idea: MinGit and pnpm staged into the prefix, a Linux prefetch filling the store, then `pnpm install --offline` run by Windows Node so the install contract itself executes as win32. It reached the install but not the gates — Wine's networking could not reach the registry directly, and the isolated `node_modules` layout defeated resolution of the Windows platform packages even after a clean offline install. This lane trades that fidelity away (hoisted layout, Linux-side install) to reach the gates; the two records are complementary halves of the same verdict.
+
 **Filesystem-semantics lanes on Linux (casefolded ext4, filename lint).** Catches the highest-frequency Windows breakage class for near-zero cost but proves nothing about win32 binaries. Explored as the sibling experiment branch `exp/casefold-windows-ci`.
 
 **Windows containers.** Not possible: Windows containers require a Windows host kernel; a hosted Linux runner cannot run them.
@@ -34,7 +38,8 @@ Promotion, if the verdict is positive: fold the Wine lane in as the pull-request
 
 ## Acceptance criteria
 
-- The workflow completes on `ubuntu-latest` with an independent pass/fail verdict per blocking gate (tsc, tsdown, production site) and a recorded wall-clock comparison against the Windows benchmark lanes.
+- The workflow completes on `ubuntu-latest` with an independent pass/fail verdict per blocking surface (build, production site) and a recorded wall-clock comparison against both the paid Windows lane and the Linux CI jobs.
+- End-to-end wall clock lands in the same band as the Linux CI jobs (minutes, not tens of minutes), demonstrating the pool-replacement case on cost as well as signal.
 - A decision is recorded here: promote the lane, keep it as a non-blocking canary, or reject it with the observed failure class.
 
 ## Risks
diff --git a/.agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.zh.md b/.agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.zh.md
index cb185293d7..a4b938faa6 100644
--- a/.agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.zh.md
+++ b/.agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.zh.md
@@ -12,9 +12,11 @@ Pull request 的 Windows 通道存在的意义是证明两个阻断性 win32 表
 
 ## 提案
 
-[exp-wine-windows.yml](../../../../.github/workflows/exp-wine-windows.yml)（自身路径过滤，外加手动触发）在 `ubuntu-latest` 上通过 Wine 用真实 Windows 二进制运行阻断门禁命令：下载的 win-x64 Node.js 执行 `tsc -b`、`tsdown` 与 VitePress 生产构建，因此工具链的 win32 分支——反斜杠路径处理、`CreateProcess` 派生语义、`@esbuild/win32-x64` 的 PE 加载、以及 rolldown/rollup 的 MSVC `.node` 插件——都真正执行。
+[exp-wine-windows.yml](../../../../.github/workflows/exp-wine-windows.yml)（自身路径过滤，外加手动触发）在 `ubuntu-latest` 上通过 Wine 用真实 Windows 二进制运行阻断门禁命令：校验和验证过的 win-x64 Node.js 执行 `tsc -b`、`tsdown` 与 VitePress 生产构建，因此工具链的 win32 分支——反斜杠路径处理、`CreateProcess` 派生语义、`@esbuild/win32-x64` 的 PE 加载、以及 rolldown/rollup 的 MSVC `.node` 插件——都真正执行。
 
-依赖在 Linux 上原生安装，`supportedArchitectures` 扩展到 win32-x64，使 Windows 平台包物化进同一个 store；通过直接调用各工具的 JavaScript 入口绕开 cmd-shim 层，这正是 `run-gates` 最终派生的那些进程。
+依赖在 Linux 上原生安装，`supportedArchitectures` 扩展到 win32-x64，使 Windows 平台包物化进同一个 store；通过直接调用各工具的 JavaScript 入口绕开 cmd-shim 层，这正是 `run-gates` 最终派生的那些进程。`nodeLinker: hoisted` 是承重的，不是风格问题：[PR #689](https://github.com/deepseek-harness/deepseek-harness/pull/689) 的独立原型保留了 pnpm 默认的 isolated 布局——包括在 Linux 预取的 store 上忠实地用 Windows pnpm 离线重装——而 Wine 下的 Windows Node 依然无法穿过 isolated 符号链接链解析 `@esbuild/win32-x64` 或加载 koffi 预编译产物，在任何仓库门禁运行前就失败了。扁平的真实文件布局才让门禁变得可达；本通道采纳了 #689 的校验和固定，同时明确放弃其"Windows pnpm 安装依赖树"的目标（安装契约在此仍由 Linux 侧验证）。
+
+该通道以 Linux CI 作业的墙钟（约两分钟）为目标，靠四个杠杆：master 刷新的 pnpm store 缓存（只恢复，与 ci.yml 同键）、Wine 供给（apt 安装、Windows Node 下载、`wineboot`）与 `pnpm install` 并发运行、两个阻断表面并发运行——与 `run-gates` 在原生 Windows 上给它们的形状相同——以及按 runner 镜像为键的 apt 归档缓存，使 Wine 的包下载每个镜像版本只付一次。
 
 这刻意是一次保真度探针，而非直接替换：Wine 在大小写敏感的 ext4 之上重实现 Win32 API（默认不模拟 NTFS 的大小写不敏感）、不提供 ConPTY、并用自己的安全描述符与 `MoveFileExW` 语义替代——恰是本仓库 `win32.ts` 模块与 PTY 后端关心的表面。实验度量哪些阻断门禁通过、哪些因 Wine 原因而非产品原因失败，以及相对已记录 Windows 基准通道的墙钟成本。
 
@@ -26,6 +28,8 @@ Pull request 的 Windows 通道存在的意义是证明两个阻断性 win32 表
 
 **在 Linux runner 内用 QEMU/KVM 跑完整 Windows 客户机。** 真实 NT 内核，保真度完整，包括大小写不敏感的 NTFS 与 ConPTY——但首个门禁运行前要花数十分钟下载镜像并做无人值守安装。作为兄弟实验分支 `exp/kvm-windows-ci` 探索；两个实验共同为保真度与延迟定价。
 
+**在 Wine 下由 Windows pnpm 执行安装（[PR #689](https://github.com/deepseek-harness/deepseek-harness/pull/689)）。** 同一想法的更高保真度变体：把 MinGit 与 pnpm 放进 prefix，用 Linux 预取填充 store，再由 Windows Node 运行 `pnpm install --offline`，让安装契约本身以 win32 身份执行。它到达了安装但没到达门禁——Wine 的网络无法直接访问 registry，且 isolated 的 `node_modules` 布局即便在干净的离线安装后也挫败了 Windows 平台包的解析。本通道用掉这份保真度（hoisted 布局、Linux 侧安装）来换取门禁可达；两份记录是同一裁决互补的两半。
+
 **Linux 上的文件系统语义通道（casefold ext4、文件名 lint）。** 以近零成本捕获最高频的 Windows 破坏类别，但对 win32 二进制什么也证明不了。作为兄弟实验分支 `exp/casefold-windows-ci` 探索。
 
 **Windows 容器。** 不可行：Windows 容器要求 Windows 宿主内核；托管 Linux runner 无法运行。
@@ -34,7 +38,8 @@ Pull request 的 Windows 通道存在的意义是证明两个阻断性 win32 表
 
 ## 验收标准
 
-- 该 workflow 在 `ubuntu-latest` 上完成，对每个阻断门禁（tsc、tsdown、生产站点）给出独立的通过/失败裁决，并记录与 Windows 基准通道的墙钟对比。
+- 该 workflow 在 `ubuntu-latest` 上完成，对每个阻断表面（构建、生产站点）给出独立的通过/失败裁决，并记录与付费 Windows 通道及 Linux CI 作业两者的墙钟对比。
+- 端到端墙钟落在 Linux CI 作业的同一档位（分钟级，而非数十分钟），从成本与信号两方面共同论证替换池的理由。
 - 在此记录一项决定：晋升该通道、保留为非阻断金丝雀、或以观察到的失败类别否决。
 
 ## 风险
diff --git a/.github/workflows/exp-wine-windows.yml b/.github/workflows/exp-wine-windows.yml
index 9ebc3ccc79..e67c0e7d79 100644
--- a/.github/workflows/exp-wine-windows.yml
+++ b/.github/workflows/exp-wine-windows.yml
@@ -1,10 +1,16 @@
 # EXPERIMENT: run the blocking Windows CI gates on a Linux runner through
-# Wine, and execute the gate commands with a real Windows Node.js binary.
-# Dependency provisioning happens natively on Linux with
+# Wine with a real Windows Node.js binary, at roughly the wall clock of the
+# Linux CI jobs (~2 min). Speed comes from four levers: the master-refreshed
+# pnpm store cache, provisioning Wine concurrently with the dependency
+# install, running the two blocking surfaces concurrently (the same shape
+# run-gates gives them on native Windows), and an apt package cache for Wine
+# itself. Dependency provisioning happens natively on Linux with
 # `supportedArchitectures` extended to win32-x64 so the Windows
-# esbuild/rolldown/rollup binaries are present in the store. The pnpm-run/cmd
-# shim layer is deliberately bypassed (a Linux install writes POSIX shims
-# only), so each gate invokes its tool's JavaScript entrypoint directly — the
+# esbuild/rolldown/rollup binaries are present, and `nodeLinker: hoisted`
+# because Windows Node under Wine does not realpath pnpm's isolated-layout
+# Unix symlinks — the sibling prototype in PR #689 kept the isolated layout
+# and failed on exactly that. The pnpm-run/cmd shim layer is deliberately
+# bypassed; each gate invokes its tool's JavaScript entrypoint directly — the
 # same commands run-gates ultimately spawns. Owning rationale and promotion
 # criteria:
 # .agents/notes/proposed/process/2026-07-27-wine-windows-gates-experiment.md
@@ -28,11 +34,17 @@ env:
 
 jobs:
   wine-blocking-gates:
-    name: wine / blocking windows gates
-    # Deliberately the cheapest hosted substrate: if Wine holds up here, the
-    # lane needs no special pool at all.
-    runs-on: ubuntu-latest
-    timeout-minutes: 120
+    name: wine / blocking windows gates (${{ matrix.runner }})
+    # Pull requests run the free standard runner only; a manual dispatch adds
+    # the 8-core benchmark pool for a like-for-like core-count comparison.
+    # The larger leg stays dispatch-only because those restricted pools can
+    # queue indefinitely (observed on the sibling KVM experiment).
+    runs-on: ${{ matrix.runner }}
+    strategy:
+      fail-fast: false
+      matrix:
+        runner: ${{ fromJSON(github.event_name == 'workflow_dispatch' && '["ubuntu-latest", "dsh-ubuntu-24-04-8core"]' || '["ubuntu-latest"]') }}
+    timeout-minutes: 30
     env:
       WINEDEBUG: '-all'
       WINEARCH: win64
@@ -47,18 +59,39 @@ jobs:
         with:
           node-version: ${{ env.PRIMARY_NODE_VERSION }}
 
-      - name: Enable corepack and install with win32-x64 artifacts
+      # The default-branch pnpm store cache ci.yml maintains; restore-only,
+      # same key, so this lane rides the cache master already refreshes.
+      - uses: actions/cache/restore@v4
+        with:
+          path: /home/runner/.local/share/pnpm/store/v11
+          key: ${{ runner.os }}-node-${{ env.PRIMARY_NODE_VERSION }}-pnpm-${{ hashFiles('pnpm-lock.yaml') }}
+          restore-keys: |
+            ${{ runner.os }}-node-${{ env.PRIMARY_NODE_VERSION }}-pnpm-
+
+      - name: Compose Wine apt cache key
+        id: wine-cache-key
+        run: echo "key=wine-debs-${ImageOS:-linux}-${ImageVersion:-v0}" >> "$GITHUB_OUTPUT"
+
+      - uses: actions/cache@v4
+        with:
+          path: ~/wine-debs
+          key: ${{ steps.wine-cache-key.outputs.key }}
+
+      - name: Install dependencies and provision Wine concurrently
         run: |
           corepack enable
+
           # Experiment-only install-time overrides. supportedArchitectures
           # additionally materializes the win32-x64 platform packages
-          # (@esbuild/win32-x64, rolldown and rollup MSVC bindings) that the
-          # Windows toolchain resolves at runtime. nodeLinker: hoisted lays
-          # node_modules out flat with real files: Windows Node under Wine
-          # does not realpath pnpm's Unix symlinks, so the default isolated
-          # layout breaks transitive ESM resolution (tsdown -> ansis,
-          # vite -> rollup). Neither override is recorded in the lockfile, so
-          # --frozen-lockfile stays valid.
+          # (@esbuild/win32-x64, rolldown and rollup MSVC bindings) the
+          # Windows toolchain resolves at runtime; nodeLinker: hoisted lays
+          # node_modules out flat with real files because Windows Node under
+          # Wine does not realpath pnpm's isolated-layout symlinks (PR #689's
+          # failure mode). Neither override is recorded in the lockfile, so
+          # --frozen-lockfile stays valid. --ignore-scripts skips the Linux
+          # esbuild/node-pty/lefthook lifecycle scripts: no gate in this lane
+          # loads them, and the win32 binaries ship prebuilt in their
+          # packages.
           cat >> pnpm-workspace.yaml <<'EOF'
 
           nodeLinker: hoisted
@@ -66,61 +99,60 @@ jobs:
             os: [current, win32]
             cpu: [current, x64]
           EOF
-          pnpm install --frozen-lockfile
 
-      - name: Resolve tool entrypoints in the hoisted layout
-        run: |
-          resolve() {
-            local name="$1"; shift
-            for p in "$@"; do
-              if [ -f "$p" ]; then echo "$name=$PWD/$p" >> "$GITHUB_ENV"; return 0; fi
+          pnpm install --frozen-lockfile --ignore-scripts &
+          install_pid=$!
+
+          provision_wine() {
+            set -euo pipefail
+            # Wine from the apt cache when present; else download the full
+            # dependency closure once and keep it for the next run. The
+            # `wine` dispatcher package (not bare `wine64`) is what puts a
+            # binary on PATH.
+            if compgen -G "$HOME/wine-debs/*.deb" > /dev/null; then
+              sudo apt-get install -y --no-install-recommends "$HOME"/wine-debs/*.deb
+            else
+              sudo apt-get update
+              sudo apt-get install -y --no-install-recommends --download-only wine
+              mkdir -p "$HOME/wine-debs"
+              cp /var/cache/apt/archives/*.deb "$HOME/wine-debs/" 2>/dev/null || true
+              sudo apt-get install -y --no-install-recommends wine
+            fi
+            WINE_BIN=''
+            for candidate in "$(command -v wine || true)" "$(command -v wine64 || true)" /usr/lib/wine/wine64; do
+              if [ -n "$candidate" ] && [ -x "$candidate" ]; then WINE_BIN="$candidate"; break; fi
             done
-            echo "::error::$name not found at any of: $*"; return 1
+            [ -n "$WINE_BIN" ] || { echo '::error::no wine binary found after install'; exit 1; }
+            echo "WINE_BIN=$WINE_BIN" >> "$GITHUB_ENV"
+
+            # Windows Node for the repo's primary line, checksum-verified
+            # against the same dist directory (adopted from PR #689).
+            version=$(curl -fsSL https://nodejs.org/dist/index.json \
+              | jq -r --arg p "v${PRIMARY_NODE_VERSION}." '[.[] | select(.version | startswith($p))][0].version')
+            echo "Windows Node: $version"
+            curl -fsSL -o "$RUNNER_TEMP/node-win.zip" \
+              "https://nodejs.org/dist/${version}/node-${version}-win-x64.zip"
+            curl -fsSL "https://nodejs.org/dist/${version}/SHASUMS256.txt" \
+              | awk -v a="node-${version}-win-x64.zip" '$2 == a { print $1 "  '"$RUNNER_TEMP"'/node-win.zip" }' \
+              | sha256sum --check -
+            unzip -q "$RUNNER_TEMP/node-win.zip" -d "$RUNNER_TEMP/node-win"
+            echo "NODE_WIN=$RUNNER_TEMP/node-win/node-${version}-win-x64/node.exe" >> "$GITHUB_ENV"
+
+            "$WINE_BIN" wineboot --init || true
+            wineserver -w || true
           }
-          resolve TSC_JS node_modules/typescript/bin/tsc
-          resolve TSDOWN_JS node_modules/tsdown/dist/run.mjs
-          resolve VITEPRESS_JS website/node_modules/vitepress/bin/vitepress.js node_modules/vitepress/bin/vitepress.js
-          # VitePress links vue into the site's node_modules at build time;
-          # Wine cannot CREATE Windows symlinks (ENOTSUP) but follows
-          # pre-existing Unix ones, so lay the link down host-side.
-          if [ -d node_modules/vue ] && [ ! -e website/node_modules/vue ]; then
-            mkdir -p website/node_modules
-            ln -s ../../node_modules/vue website/node_modules/vue
-          fi
+          provision_wine &
+          wine_pid=$!
 
-      - name: Install Wine (64-bit)
-        run: |
-          sudo apt-get update
-          # `wine` is the /usr/bin/wine dispatcher; its dependency pulls the
-          # wine64 loader. Ubuntu's wine64 package alone leaves nothing on
-          # PATH (the loader sits at /usr/lib/wine/wine64).
-          sudo apt-get install -y --no-install-recommends wine
-          WINE_BIN=''
-          for candidate in "$(command -v wine || true)" "$(command -v wine64 || true)" /usr/lib/wine/wine64; do
-            if [ -n "$candidate" ] && [ -x "$candidate" ]; then WINE_BIN="$candidate"; break; fi
-          done
-          if [ -z "$WINE_BIN" ]; then
-            echo '::error::no wine binary found after install'
-            dpkg -L wine wine64 2>/dev/null | grep -E '/bin/|wine64$' || true
-            exit 1
-          fi
-          echo "WINE_BIN=$WINE_BIN" >> "$GITHUB_ENV"
-          "$WINE_BIN" --version
+          install_status=0
+          wait "$install_pid" || install_status=$?
+          wine_status=0
+          wait "$wine_pid" || wine_status=$?
+          if (( install_status != 0 )); then exit "$install_status"; fi
+          exit "$wine_status"
 
-      - name: Fetch Windows Node.js
+      - name: Resolve entrypoints, link vue, smoke Windows Node
         run: |
-          version=$(curl -fsSL https://nodejs.org/dist/index.json \
-            | jq -r --arg p "v${PRIMARY_NODE_VERSION}." '[.[] | select(.version | startswith($p))][0].version')
-          echo "Windows Node: $version"
-          curl -fsSL -o "$RUNNER_TEMP/node-win.zip" \
-            "https://nodejs.org/dist/${version}/node-${version}-win-x64.zip"
-          unzip -q "$RUNNER_TEMP/node-win.zip" -d "$RUNNER_TEMP/node-win"
-          echo "NODE_WIN=$RUNNER_TEMP/node-win/node-${version}-win-x64/node.exe" >> "$GITHUB_ENV"
-
-      - name: Boot Wine prefix and smoke Windows Node
-        run: |
-          "$WINE_BIN" wineboot --init || true
-          wineserver -w || true
           # Node under Wine cannot attach stdio to the Actions runner's pipes
           # (Socket open EBADF at bootstrap), so every invocation runs through
           # this wrapper: stdio to a regular file, replayed after exit.
@@ -134,39 +166,60 @@ jobs:
           exit "$status"
           SH
           chmod +x "$RUNNER_TEMP/wine-node.sh"
+
+          resolve() {
+            local name="$1"; shift
+            for p in "$@"; do
+              if [ -f "$p" ]; then echo "$name=$PWD/$p" >> "$GITHUB_ENV"; return 0; fi
+            done
+            echo "::error::$name not found at any of: $*"; return 1
+          }
+          resolve TSC_JS node_modules/typescript/bin/tsc
+          resolve TSDOWN_JS node_modules/tsdown/dist/run.mjs
+          resolve VITEPRESS_JS website/node_modules/vitepress/bin/vitepress.js node_modules/vitepress/bin/vitepress.js
+
+          # VitePress links vue into the site's node_modules at build time;
+          # Wine cannot CREATE Windows symlinks (ENOTSUP) but follows
+          # pre-existing Unix ones, so lay the link down host-side.
+          if [ -d node_modules/vue ] && [ ! -e website/node_modules/vue ]; then
+            mkdir -p website/node_modules
+            ln -s ../../node_modules/vue website/node_modules/vue
+          fi
+
           "$RUNNER_TEMP/wine-node.sh" "$RUNNER_TEMP/smoke.log" -p "'smoke: ' + process.platform + ' ' + process.arch + ' ' + process.version"
 
-      # The continue-on-error gates below mirror ci-windows-blocking
-      # (scripts/run-gates.ts): `build` = tsc -b + tsdown, `production site` =
-      # vitepress build. Each reports independently so one failure does not
-      # hide the others' results; the summary step at the end owns the job
-      # conclusion.
-      - name: 'Gate: tsc -b (Windows node under Wine)'
-        id: tsc
-        continue-on-error: true
-        timeout-minutes: 45
-        run: '"$RUNNER_TEMP/wine-node.sh" "$RUNNER_TEMP/tsc.log" "$TSC_JS" -b --pretty false'
-
-      - name: 'Gate: tsdown (Windows node under Wine)'
-        id: tsdown
-        continue-on-error: true
-        timeout-minutes: 30
-        run: '"$RUNNER_TEMP/wine-node.sh" "$RUNNER_TEMP/tsdown.log" "$TSDOWN_JS"'
-
-      - name: 'Gate: production site (Windows node under Wine)'
-        id: site
-        continue-on-error: true
-        timeout-minutes: 30
-        working-directory: website
-        run: '"$RUNNER_TEMP/wine-node.sh" "$RUNNER_TEMP/site.log" "$VITEPRESS_JS" build .'
-
-      - name: Report gate outcomes
-        env:
-          TSC: ${{ steps.tsc.outcome }}
-          TSDOWN: ${{ steps.tsdown.outcome }}
-          SITE: ${{ steps.site.outcome }}
+      # The two blocking surfaces run concurrently, the same shape run-gates
+      # gives ci-windows-blocking on native Windows (DSH_GATE_CONCURRENCY):
+      # `build` = tsc -b then tsdown, `production site` = the VitePress
+      # build. Both statuses are captured so one failure cannot hide the
+      # other's result.
+      - name: Run blocking Windows gates concurrently under Wine
+        timeout-minutes: 20
         run: |
-          echo "tsc: $TSC"
-          echo "tsdown: $TSDOWN"
-          echo "production site: $SITE"
-          [ "$TSC" = success ] && [ "$TSDOWN" = success ] && [ "$SITE" = success ]
+          build_gate() {
+            "$RUNNER_TEMP/wine-node.sh" "$RUNNER_TEMP/tsc.log" "$TSC_JS" -b --pretty false || return $?
+            "$RUNNER_TEMP/wine-node.sh" "$RUNNER_TEMP/tsdown.log" "$TSDOWN_JS"
+          }
+          site_gate() {
+            cd website
+            "$RUNNER_TEMP/wine-node.sh" "$RUNNER_TEMP/site.log" "$VITEPRESS_JS" build .
+          }
+          start=$SECONDS
+          build_gate > "$RUNNER_TEMP/build-gate.out" 2>&1 &
+          build_pid=$!
+          site_gate > "$RUNNER_TEMP/site-gate.out" 2>&1 &
+          site_pid=$!
+          build_status=0
+          wait "$build_pid" || build_status=$?
+          site_status=0
+          wait "$site_pid" || site_status=$?
+          echo "== build gate (exit $build_status, $((SECONDS - start))s elapsed) =="
+          tail -n 120 "$RUNNER_TEMP/build-gate.out"
+          echo "== production site gate (exit $site_status, $((SECONDS - start))s elapsed) =="
+          tail -n 120 "$RUNNER_TEMP/site-gate.out"
+          if (( build_status != 0 )); then exit "$build_status"; fi
+          exit "$site_status"
+
+      - name: Shut down wineserver
+        if: always()
+        run: wineserver -k 2>/dev/null || true