A best-effort harness that routes heavy VMs, container stacks, x86 builds and GPU jobs from the 24 GB MacBook to the idle Windows PC over Tailscale — failing loud, never silently, when the PC is away. 一套「尽力而为」的分流机制:把重型虚拟机、容器栈、x86 构建和 GPU 任务从 24 GB 的 MacBook 转移到闲置的 Windows PC(经 Tailscale)。PC 不在线时大声报错,绝不静默降级。 重量級の VM・コンテナ群・x86 ビルド・GPU ジョブを、24 GB の MacBook から遊休中の Windows PC へ Tailscale 経由でベストエフォート委譲するハーネス。PC 不在時は明示的に失敗し、静かなフォールバックは絶対にしない。
Real incidents from the past months of session history (via /recall): 过去几个月会话记录中的真实事故(来自 /recall): 過去数ヶ月のセッション履歴に残る実際のインシデント(/recall より):
Colima x86_64 VM in TCG software emulation — pinned at 118% CPU for 3 straight days running an AI-service stack (MySQL + Redis + Qdrant + FastAPI). Load average 25 on 14 cores. "Why is my computer so laggy?"Colima x86_64 虚拟机跑在 TCG 软件模拟模式 —— 为一套 AI 服务栈(MySQL + Redis + Qdrant + FastAPI)连续 3 天钉在 118% CPU。14 核上负载均值 25。"我电脑怎么这么卡?"Colima の x86_64 VM が TCG ソフトウェアエミュレーションで稼働——AI サービス一式(MySQL + Redis + Qdrant + FastAPI)のため 3 日間 CPU 118% に張り付き。14 コアでロードアベレージ 25。「なんでこんなに重いの?」
The pattern repeats: OpenWrt x86_64 QEMU VM at 115% CPU during SDK builds · UTM test-router & QA VMs constantly evicted ("VM likely powered off") · Docker Desktop + Colima both installed, 20 GB disk bloat · WHMCS staging stacks fighting IDEs for RAM.同样的模式反复出现:OpenWrt x86_64 QEMU 在 SDK 构建时 115% CPU · UTM 测试路由器和 QA 虚拟机经常被迫关机("VM 可能已关闭") · Docker Desktop 和 Colima 同时安装,磁盘膨胀 20 GB · WHMCS staging 栈和 IDE 抢内存。同じパターンの繰り返し:OpenWrt x86_64 QEMU が SDK ビルド中 115% CPU · UTM のテストルーター/QA VM は常時強制停止気味(「VM の電源が落ちている模様」) · Docker Desktop と Colima の二重インストールで 20 GB のディスク肥大 · WHMCS ステージング環境が IDE とメモリを奪い合う。
The insight: the Mac's worst workload — software-emulating x86_64, hosting multi-GB Linux VMs, running fat container stacks — is exactly the i9-12900KF's native workload. And the 3090 adds a GPU class the Mac simply doesn't have. 核心洞察:Mac 最不擅长的工作 —— 软件模拟 x86_64、跑好几 GB 的 Linux 虚拟机、承载臃肿容器栈 —— 恰恰是 i9-12900KF 的原生强项。而 3090 提供的 GPU 算力级别,Mac 根本没有。 核心的な洞察:Mac が最も苦手とする仕事——x86_64 のソフトウェアエミュレーション、数 GB 級 Linux VM のホスト、重量級コンテナ群の稼働——は、まさに i9-12900KF のネイティブ領域。さらに 3090 は Mac には存在しない GPU 階級を追加する。
Everything rides the existing Tailscale tailnet, so it works identically from the home LAN and from outside. The key move: the WSL2 distro runs its own tailscaled, so Linux work never touches the fragile Windows→WSL relay path. 一切都走现有的 Tailscale 网络,在家和在外表现完全一致。关键一招:WSL2 发行版跑自己的 tailscaled,Linux 工作负载完全绕开脆弱的 Windows→WSL 中转链路。 すべて既存の Tailscale テールネット上で動くため、自宅 LAN でも外出先でも挙動は同一。要点は WSL2 ディストロが独自の tailscaled を持つこと——Linux ワークロードは脆弱な Windows→WSL 中継経路を一切通らない。
Windows OpenSSH :22. For Windows-native testing (VilaNet client, real TUN), WSL lifecycle control, reboots. Not for Linux payloads.Windows OpenSSH :22。用于 Windows 原生测试(VilaNet 客户端、真实 TUN)、WSL 生命周期管理、重启。不承载 Linux 负载。Windows OpenSSH :22。Windows ネイティブテスト(VilaNet クライアント、実 TUN)、WSL のライフサイクル管理、再起動用。Linux ペイロードには使わない。
tailscaled inside WSL2 Ubuntu → own tailnet IP, native sshd + docker-ce. One hop, no wsl.exe relay, no UTF-16 mangling, no port-proxy churn. Primary target for all Linux work.WSL2 Ubuntu 内跑 tailscaled → 独立 tailnet IP、原生 sshd + docker-ce。单跳直达,无 wsl.exe 中转、无 UTF-16 乱码、无端口代理漂移。所有 Linux 工作的主目标。WSL2 Ubuntu 内の tailscaled が独自 tailnet IP を持ち、ネイティブ sshd + docker-ce に直結。wsl.exe 中継なし、UTF-16 化けなし、ポートプロキシ漂流なし。全 Linux 作業の主ターゲット。
Always-on WOL relay: ssh vilanas synonet --wake works from anywhere via the tailnet — one code path, no "am I home?" detection. Also the LAN jump host if Tailscale on mesh ever breaks.常开 WOL 中继:ssh vilanas synonet --wake 经 tailnet 在任何地方可用 —— 单一代码路径,无需"我在家吗?"判断。也是 mesh 上 Tailscale 故障时的 LAN 跳板机。常時稼働の WOL 中継。ssh vilanas synonet --wake はテールネット経由でどこからでも有効——「在宅判定」不要の単一経路。mesh の Tailscale が壊れた際の LAN 踏み台も兼ねる。
| Channel通道チャネル | Verdict结论判定 | Why原因理由 |
|---|---|---|
| SSH · Windows OpenSSH + sshd-in-WSL mesh + mesh-wsl |
CONTROL PLANE控制平面制御プレーン | Scriptable, key-auth, identical from LAN or outside, drivable by Claude/Codex on both ends. The only channel agents can automate safely.可脚本化、密钥认证、内外网行为一致,两端的 Claude/Codex 都能驱动。唯一能让智能体安全自动化的通道。スクリプト化可能・鍵認証・LAN 内外で挙動同一・両端の Claude/Codex から駆動可能。エージェントが安全に自動化できる唯一のチャネル。 |
| Chrome Remote Desktop | GUI BREAK-GLASSGUI 应急GUI 非常用 | Mirrors the console session without locking it — safe alongside the WSL keepalive. But it's internet-reachable via Google: long PIN now, consider disabling once SSH is proven. Used once tonight for bootstrap.镜像控制台会话且不锁屏 —— 与 WSL 保活机制兼容。但它经 Google 可从公网到达:先设长 PIN,SSH 验证稳定后考虑停用。今晚引导安装时用它一次。コンソールセッションをロックせずミラーする——WSL キープアライブと共存可能。ただし Google 経由でインターネット到達可能:長い PIN を設定し、SSH 安定後は無効化を検討。今夜のブートストラップで 1 回だけ使用。 |
| RDP :3389 currently open当前开放現在開放中 |
RESTRICT收紧制限 | Creates a new session and locks the console — can kill console-scoped keepalives and CRD's view. Keep for full-fidelity GUI, but scope via tailnet ACL to the Mac only, and prefer CRD day-to-day.新建会话并锁定控制台 —— 可能杀掉控制台级保活和 CRD 画面。保留用于高保真 GUI,但用 tailnet ACL 限定仅 Mac 可达,日常优先 CRD。新規セッションを作りコンソールをロック——コンソール依存のキープアライブや CRD 表示を壊し得る。高忠実 GUI 用に残すが、tailnet ACL で Mac のみに限定し、日常は CRD を優先。 |
| Tailscale SSH server | IMPOSSIBLE不可行不可 | Verified: server side is Linux/macOS/BSD only as of 2026 (open GH issues #14942/#17261). Tailscale = network + ACL layer; Windows OpenSSH = the daemon.已验证:截至 2026,服务端仅支持 Linux/macOS/BSD(GH issue #14942/#17261 仍开放)。Tailscale 只当网络 + ACL 层;守护进程用 Windows OpenSSH。検証済み:2026 年時点でサーバー側は Linux/macOS/BSD のみ(GH issue #14942/#17261 未解決)。Tailscale はネットワーク+ACL 層、デーモンは Windows OpenSSH が担当。 |
| netsh portproxy → WSL sshd | REJECTED否决却下 | WSL IP churns on every reboot; proxy rules rot. tailscaled-in-WSL makes the whole mechanism unnecessary.WSL IP 每次重启都变,代理规则会烂掉。WSL 内跑 tailscaled 让这套机制完全没必要。WSL の IP は再起動ごとに変わりプロキシ規則が腐る。tailscaled-in-WSL によりこの仕組み自体が不要。 |
① Admin accounts ignore ~/.ssh/authorized_keys — keys go in ProgramData\ssh\administrators_authorized_keys with an exact icacls ACL, using SID *S-1-5-32-544 (the literal name "Administrators" fails on Japanese-locale Windows, silently). ② Set WSL_UTF8=1 machine-wide — wsl.exe emits UTF-16 into pipes. ③ sshd runs as SYSTEM in Session 0: wsl.exe can hang LxssManager at 100% CPU when no interactive session exists — this exact scenario is Gate G1 below.
① 管理员账户会忽略 ~/.ssh/authorized_keys —— 密钥要放进 ProgramData\ssh\administrators_authorized_keys 并用精确的 icacls ACL,且必须用 SID *S-1-5-32-544(日文版 Windows 上字面量 "Administrators" 会静默失败)。② 全局设置 WSL_UTF8=1 —— wsl.exe 向管道输出 UTF-16。③ sshd 以 SYSTEM 身份跑在 Session 0:无交互会话时 wsl.exe 可能把 LxssManager 卡死在 100% CPU —— 这正是下文 Gate G1 要测的场景。
① 管理者アカウントは ~/.ssh/authorized_keys を無視——鍵は ProgramData\ssh\administrators_authorized_keys に置き、正確な icacls ACL を SID *S-1-5-32-544 で設定(日本語版 Windows ではリテラル "Administrators" が静かに失敗)。② マシン全体に WSL_UTF8=1 を設定——wsl.exe はパイプへ UTF-16 を吐く。③ sshd は Session 0 の SYSTEM として動作:対話セッション不在時に wsl.exe が LxssManager を 100% CPU でハングさせ得る——まさにこれが後述の Gate G1。
docker-ce natively inside WSL2 (no Docker Desktop: no license, no GUI, survives headless). From the Mac: docker context → ssh://mesh-wsl and a buildx remote node so linux/amd64 images build natively on the i9 — the exact workload that melted the Mac. Repos and volumes live on WSL ext4, never /mnt/c (3–5× slower).WSL2 内原生装 docker-ce(不用 Docker Desktop:无授权问题、无 GUI、可无头运行)。Mac 侧:docker context → ssh://mesh-wsl 加 buildx 远程节点,让 linux/amd64 镜像在 i9 上原生构建 —— 正是烤化 Mac 的那类负载。仓库和卷放 WSL ext4,绝不放 /mnt/c(慢 3–5 倍)。WSL2 内にネイティブの docker-ce(Docker Desktop 不使用:ライセンス不要・GUI 不要・ヘッドレスで生存)。Mac 側は docker context → ssh://mesh-wsl と buildx リモートノードで、linux/amd64 イメージを i9 でネイティブビルド——Mac を溶かしたまさにあの負荷。リポジトリとボリュームは WSL の ext4 に置き、/mnt/c は使わない(3〜5 倍遅い)。
QEMU with KVM acceleration inside WSL2 — nested virtualization is default-on for Windows 11; /dev/kvm is gate-checked at dispatch (a Jan-2026 WSL regression can silently disable it). Replaces the UTM VMs that kept getting evicted on the Mac.QEMU 在 WSL2 内走 KVM 加速 —— Windows 11 上嵌套虚拟化默认开启;派发时强制检查 /dev/kvm(2026 年 1 月的 WSL 回归缺陷可能静默禁用它)。取代 Mac 上老被挤掉的 UTM 虚拟机。QEMU を WSL2 内で KVM アクセラレーション付きで実行——Windows 11 ではネスト仮想化が既定で有効。ディスパッチ時に /dev/kvm をゲート検査(2026 年 1 月の WSL リグレッションで静かに無効化される事例あり)。Mac 上で追い出され続けた UTM VM を置き換える。
Verified model: NVIDIA driver on Windows only, CUDA toolkit (never the cuda meta-package) inside WSL, PyTorch wheels matched to the toolkit. Mature path for ML/AI jobs; datasets on ext4.已验证的模式:NVIDIA 驱动只装在 Windows 侧,WSL 内装 CUDA toolkit(绝不装 cuda 元包),PyTorch 轮子与 toolkit 版本对齐。ML/AI 任务的成熟路径;数据集放 ext4。検証済み構成:NVIDIA ドライバは Windows 側のみ、WSL 内には CUDA toolkit(cuda メタパッケージは厳禁)、PyTorch は toolkit 版に一致させる。ML/AI ジョブの成熟経路。データセットは ext4 上に。
A capability the Mac never had: testing the VilaNet Windows client on real hardware — real TUN adapter, real firewall, the Hyper-V excludedportrange quirks seen in past sessions. Driven via ssh mesh (PowerShell).Mac 从来没有的能力:在真实硬件上测 VilaNet Windows 客户端 —— 真 TUN 网卡、真防火墙,还有历史会话里见过的 Hyper-V excludedportrange 怪癖。经 ssh mesh(PowerShell)驱动。Mac には無かった能力:VilaNet の Windows クライアントを実機でテスト——本物の TUN アダプタ、本物のファイアウォール、過去セッションで遭遇した Hyper-V excludedportrange の癖も含めて。ssh mesh(PowerShell)で駆動。
Reviewers cut my initial 24 GB ceiling to 20 GB: the WDDM/3090 driver, Hyper-V root partition and an RDP session all bill against Windows' share, and WSL reclaims memory lazily. QEMU guests + docker stacks must sum under the ceiling. Start at 20, tune from measurement.评审把我最初的 24 GB 上限砍到 20 GB:WDDM/3090 驱动、Hyper-V 根分区和 RDP 会话都算在 Windows 份额里,且 WSL 回收内存很懒。QEMU 客户机 + docker 栈总和必须低于上限。先 20,再按实测调。レビューで当初の 24 GB 上限は 20 GB に減額:WDDM/3090 ドライバ、Hyper-V ルートパーティション、RDP セッションはすべて Windows 側の取り分に計上され、WSL のメモリ回収は遅延的。QEMU ゲスト+docker スタックの合計は上限未満に。まず 20 GB、実測で調整。
G1 · Session-0: with nobody logged in (RDP disconnected, CRD closed), ssh mesh wsl.exe -d Ubuntu -e true must start WSL — not hang LxssManager. G2 · Durability: start a 30-min tmux job on mesh-wsl, disconnect, reboot the Mac, reconnect: job must have survived (vmIdleTimeout=-1 + instanceIdleTimeout=-1 + keepalive). G3 · Network: tailscaled-in-WSL holds a direct (non-DERP) path with sane MTU under sustained transfer. Fail any gate → the headless Linux target becomes a Hyper-V Ubuntu VM (auto-start, static IP, native sshd — structurally immune to all three), and WSL2 keeps only the CUDA lane.
G1 · Session-0:无人登录时(RDP 断开、CRD 关闭),ssh mesh wsl.exe -d Ubuntu -e true 必须能启动 WSL,而不是把 LxssManager 卡死。G2 · 持久性:在 mesh-wsl 上开一个 30 分钟 tmux 任务,断开连接、重启 Mac、重连:任务必须还活着(vmIdleTimeout=-1 + instanceIdleTimeout=-1 + 保活)。G3 · 网络:WSL 内 tailscaled 在持续传输下保持直连(非 DERP)且 MTU 正常。任一闸门失败 → 无头 Linux 目标改为 Hyper-V Ubuntu 虚拟机(开机自启、固定 IP、原生 sshd —— 结构上对这三个问题免疫),WSL2 只保留 CUDA 通道。
G1 · Session-0:誰もログインしていない状態(RDP 切断・CRD 終了)で ssh mesh wsl.exe -d Ubuntu -e true が WSL を起動できること——LxssManager をハングさせないこと。G2 · 持続性:mesh-wsl 上で 30 分の tmux ジョブを開始し、切断・Mac 再起動・再接続してもジョブが生存していること(vmIdleTimeout=-1 + instanceIdleTimeout=-1 + キープアライブ)。G3 · ネットワーク:WSL 内 tailscaled が持続転送下で直接経路(非 DERP)と正常 MTU を維持すること。いずれか失敗 → ヘッドレス Linux ターゲットは Hyper-V Ubuntu VM(自動起動・固定 IP・ネイティブ sshd——3 問題すべてに構造的免疫)へ切替え、WSL2 は CUDA レーン専任に。
linux/amd64 build · CUDA/GPU · long CPU-bound build · Windows-native test → mesh-run dispatches to the PC inside a named tmux session, with a job ID and a dispatch log.重活?任何完整虚拟机 · ≥3 容器或 ≥8 GB 的 docker 栈 · linux/amd64 构建 · CUDA/GPU · 长时间 CPU 构建 · Windows 原生测试 → mesh-run 派发到 PC,包在命名 tmux 会话里,带任务 ID 和派发日志。重量級?フル VM・3 コンテナ以上または 8 GB 以上の docker スタック・linux/amd64 ビルド・CUDA/GPU・長時間 CPU ビルド・Windows ネイティブテスト → mesh-run が名前付き tmux セッション内へディスパッチ。ジョブ ID とディスパッチログ付き。nc -z on TCP port 22探测 = 对 TCP 22 端口 nc -zプローブ = TCP 22 への nc -zdocker context ssh://mesh through Windows sshd + wsl.exe relaydocker context ssh://mesh 走 Windows sshd + wsl.exe 中转docker context ssh://mesh を Windows sshd + wsl.exe 中継でssh -o BatchMode=yes mesh-wsl true · docker info · test -e /dev/kvm · nvidia-smi -L · free disk/RAM按任务类型做能力探测:ssh -o BatchMode=yes mesh-wsl true · docker info · test -e /dev/kvm · nvidia-smi -L · 磁盘/内存余量ジョブ種別ごとの能力プローブ:ssh -o BatchMode=yes mesh-wsl true · docker info · test -e /dev/kvm · nvidia-smi -L · ディスク/RAM 残量mesh-up). Local fallback only with explicit --fallback local, always logged.默认大声失败:退出码 70 = mesh 不可达 · 71 = WSL 未就绪 · 72 = 资源不足,并附建议动作(mesh-up)。本地回退必须显式 --fallback local,且必留日志。既定でフェイルラウド:exit 70 = mesh 到達不能 · 71 = WSL 未準備 · 72 = リソース不足、加えて対処提案(mesh-up)。ローカルフォールバックは明示の --fallback local 時のみ、必ずログ。mesh-wsl: single shell layer, binary-safe, docker context works as designed单跳直达 mesh-wsl:一层 shell、二进制安全、docker context 按设计工作mesh-wsl へ 1 ホップ:シェル 1 層・バイナリ安全・docker context が設計どおり機能--platform linux/amd64 without a live remote builder refuses unless ALLOW_TCG=1; buildx asserts the remote node did the workMac 上结构性禁止 TCG:不装 amd64 模拟;没有存活远程 builder 时 --platform linux/amd64 直接拒绝,除非 ALLOW_TCG=1;buildx 校验确实由远程节点完成构建Mac 上で TCG を構造的に禁止:amd64 エミュレーションを入れない。リモートビルダー不在の --platform linux/amd64 は ALLOW_TCG=1 なしでは拒否。buildx はリモートノードが実際に仕事をしたことを検証
Wake path: PC asleep? mesh-up always goes one way: ssh vilanas synonet --wake <MAC> (works from anywhere via tailnet), then waits on a capability probe with a ~5-minute budget — cold boot + Tailscale + WSL is more than the naive 120 s. Prereqs: BIOS ErP off, NIC magic-packet wake on, Windows Fast Startup off.
唤醒路径:PC 睡了?mesh-up 永远只有一条路:ssh vilanas synonet --wake <MAC>(经 tailnet 任何地方可用),然后用能力探测等待,预算约 5 分钟 —— 冷启动 + Tailscale + WSL 可比天真的 120 秒要长。前提:BIOS ErP 关、网卡魔术包唤醒开、Windows 快速启动关。
ウェイク経路:PC がスリープ中なら mesh-up は常に一本道:ssh vilanas synonet --wake <MAC>(テールネット経由でどこからでも)。その後能力プローブで待機、予算は約 5 分——コールドブート+Tailscale+WSL は素朴な 120 秒では足りない。前提:BIOS の ErP オフ、NIC のマジックパケット起動オン、Windows 高速スタートアップオフ。
Bootstrap via the CRD session that's already open (elevated PowerShell on the PC):用当前已打开的 CRD 会话引导(PC 上提权 PowerShell):現在開いている CRD セッションから着手(PC 上の管理者 PowerShell):
# [mesh · PowerShell as admin] — OpenSSH Server Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0 Start-Service sshd; Set-Service sshd -StartupType Automatic # key for admin user → the SHARED admin key file (not ~/.ssh!) Add-Content -Path "$env:ProgramData\ssh\administrators_authorized_keys" -Value "<mac-pubkey>" # ACL by SID — literal "Administrators" breaks on JP-locale Windows icacls "$env:ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant "*S-1-5-32-544:F" /grant "*S-1-5-18:F" # wsl.exe pipes are UTF-16 by default — fix machine-wide [Environment]::SetEnvironmentVariable('WSL_UTF8','1','Machine') # scope sshd to the Tailscale interface, drop broad LAN exposure Set-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -RemoteAddress 100.64.0.0/10 # → verify key-login from the Mac BEFORE closing CRD
# [inside WSL2 Ubuntu] — give the distro its own tailnet identity # /etc/wsl.conf: [boot] systemd=true → wsl --shutdown once curl -fsSL https://tailscale.com/install.sh | sh sudo tailscale up --hostname mesh-wsl --ssh # Tailscale SSH works fine on LINUX sudo apt install -y docker.io tmux # docker-ce, no Docker Desktop
# [Mac] ~/.ssh/config → Host mesh / mesh-wsl (MagicDNS names, IP fallback in ONE place) # remote amd64 builder — the direct fix for the Colima TCG incident docker context create mesh-wsl --docker "host=ssh://mesh-wsl" docker buildx create --name pc-amd64 mesh-wsl --platform linux/amd64 docker buildx inspect pc-amd64 --bootstrap # assert the REMOTE node does the work
Run the Session-0, 30-min-durability and direct-path/MTU tests from §04 before building anything else on top. A failed gate = pivot to the Hyper-V Ubuntu VM, not a workaround pile.先跑 §04 的 Session-0、30 分钟持久性、直连/MTU 三项测试,再往上盖任何东西。闸门失败 = 转投 Hyper-V Ubuntu 虚拟机,而不是堆补丁。§04 の Session-0・30 分持続性・直接経路/MTU の各テストを、上に何かを積む前に実行。ゲート不合格 = 回避策の山ではなく Hyper-V Ubuntu VM へ転換。
# %USERPROFILE%\.wslconfig (then: wsl --shutdown) [wsl2] memory=20GB processors=16 swap=8GB vmIdleTimeout=-1 # WSL VM never idle-kills… # nestedVirtualization: default ON for Win11 — verify /dev/kvm anyway [experimental] instanceIdleTimeout=-1 # …and neither does the distro instance
Plus: a Task-Scheduler at-boot keepalive holding a wsl.exe child alive · mesh-up on the Mac (WOL via vilanas → 5-min capability wait) · BIOS ErP off, NIC wake on, Fast Startup off · disable Tailscale key expiry on mesh + vilanas (the default 180-day expiry is a scheduled outage) · DHCP reservation + ssh -J vilanas mesh-lan as the non-Tailscale escape path · Windows Update active hours so it never reboots mid-job.另加:任务计划程序开机保活(挂一个 wsl.exe 子进程) · Mac 侧 mesh-up(经 vilanas 发 WOL → 5 分钟能力探测等待) · BIOS ErP 关、网卡唤醒开、快速启动关 · 关掉 mesh 和 vilanas 的 Tailscale 密钥过期(默认 180 天过期就是个定时故障) · DHCP 保留 + ssh -J vilanas mesh-lan 作为非 Tailscale 逃生路径 · 设置 Windows 更新活跃时间,别让它在任务中途重启。さらに:タスクスケジューラの起動時キープアライブ(wsl.exe 子プロセスを保持) · Mac 側 mesh-up(vilanas 経由 WOL → 5 分の能力プローブ待機) · BIOS ErP オフ・NIC ウェイクオン・高速スタートアップオフ · mesh と vilanas の Tailscale 鍵有効期限を無効化(既定 180 日の失効は予定された障害) · DHCP 予約+ssh -J vilanas mesh-lan の非 Tailscale 脱出経路 · Windows Update のアクティブ時間設定でジョブ中の再起動を防止。
CUDA toolkit in WSL for the 3090 · KVM-accelerated QEMU for OpenWrt/merlin QA VMs (gate: test -e /dev/kvm at every dispatch) · VilaNet Windows-client test lane over ssh mesh · finally an offload skill for Claude sessions — instructions + decision tree only; all probing/waking stays in deterministic scripts (mesh-run, mesh-up), per the no-LLM-watchdog rule. Claude Code + Codex already on the PC can be driven headless inside tmux for remote implementation runs.WSL 内装 CUDA toolkit 伺候 3090 · KVM 加速 QEMU 跑 OpenWrt/merlin QA 虚拟机(每次派发前检查 test -e /dev/kvm) · 经 ssh mesh 的 VilaNet Windows 客户端测试通道 · 最后给 Claude 会话加一个 offload 技能 —— 只含说明和决策树;所有探测/唤醒都留在确定性脚本里(mesh-run、mesh-up),遵守"禁止 LLM 看门狗"规则。PC 上现成的 Claude Code + Codex 可在 tmux 里无头驱动,跑远程实现任务。WSL 内に CUDA toolkit を入れて 3090 を活用 · KVM 加速 QEMU で OpenWrt/merlin QA VM(毎ディスパッチ時に test -e /dev/kvm をゲート) · ssh mesh 経由の VilaNet Windows クライアントテストレーン · 最後に Claude セッション用 offload スキル——中身は説明と決定木のみ。プローブ/ウェイクはすべて決定的スクリプト(mesh-run・mesh-up)に置く(LLM ウォッチドッグ禁止規則に準拠)。PC 上の Claude Code + Codex は tmux 内でヘッドレス駆動し、リモート実装ランに使える。
| Decision决策決定 | Score评分スコア | Dominant factor主导因素支配要因 |
|---|---|---|
| SSH-over-Tailscale control plane, Windows OpenSSH doorSSH over Tailscale 控制平面 + Windows OpenSSH 门SSH over Tailscale 制御プレーン+Windows OpenSSH の扉 | 92 | Only scriptable channel; verified as the supported pairing; both reviewers concur唯一可脚本化通道;已验证为官方支持组合;两位评审一致同意唯一のスクリプト化可能チャネル。公式サポート構成と検証済み。両レビュアー一致 |
| tailscaled-in-WSL (mesh-wsl) as primary Linux endpointWSL 内 tailscaled(mesh-wsl)作为 Linux 主入口tailscaled-in-WSL(mesh-wsl)を Linux 主エンドポイントに | 80 | Dissolves five failure modes at once, but G1–G3 gates + MTU caveat must pass first; Hyper-V pivot priced in一举化解五种故障模式,但须先过 G1–G3 闸门和 MTU 校验;Hyper-V 备胎已入价5 つの故障モードを一挙に解消。ただし G1〜G3 ゲートと MTU 検証の通過が先。Hyper-V 転換も織込み済み |
| Fail-loud dispatcher + structural TCG ban大声失败派发器 + 结构性 TCG 禁令フェイルラウドなディスパッチャ+構造的 TCG 禁止 | 90 | Converts the recurring incident class into an impossible state, not a discouraged one把反复发作的事故类别变成"不可能状态",而非"不建议状态"再発するインシデント類型を「非推奨」でなく「不可能」な状態に変える |
| WOL via vilanas, single path经 vilanas 的单路径 WOLvilanas 経由の単一経路 WOL | 85 | Always-on relay already exists; residual: confirm same L2 broadcast domain + BIOS prep常开中继现成;残余:确认同一 L2 广播域 + BIOS 预设常時稼働の中継が既に存在。残課題:同一 L2 ブロードキャストドメインの確認と BIOS 設定 |
| My original draft, as first written我的初稿(原样)初稿(そのまま) | 66 | Codex 66, adversarial reviewer 68 — silent fallback + broken docker transport + no durability layer. Review earned its keep.Codex 66 分,对抗评审 68 分 —— 静默回退 + 坏掉的 docker 传输 + 无持久层。评审这钱花得值。Codex 66 点・敵対的レビュー 68 点——静かなフォールバック+壊れた docker 転送+持続層の欠如。レビューは元を取った。 |
| Hardened plan (this brief)加固后方案(本简报)強化後プラン(本ブリーフ) | 88 | Ship it. Residual risk lives in the three gates, priced with an explicit pivot.可以上。残余风险集中在三道闸门,且已配好明确的转向方案。出荷可。残余リスクは 3 ゲートに集約され、明示的な転換先まで用意済み。 |
mesh:22/3389 — a tailnet IP range is a network, not an authorizationTailnet ACL:只有 Mac 能到 mesh:22/3389 —— tailnet 网段是网络,不是授权テールネット ACL:mesh:22/3389 へ到達できるのは Mac のみ——IP レンジはネットワークであって認可ではない
Immediate next step: the CRD session is already open — Phase 1 is one paste-and-verify away. First win within the hour: docker buildx build --platform linux/amd64 running natively on the i9 while the Mac's fans stay silent.
马上可做:CRD 会话已经开着 —— 第一阶段就差一次粘贴加验证。一小时内的首个胜利:docker buildx build --platform linux/amd64 在 i9 上原生跑起来,而 Mac 的风扇保持安静。
直近の一手:CRD セッションは既に開いている——フェーズ 1 は貼り付けて検証するだけ。1 時間以内の初勝利:docker buildx build --platform linux/amd64 が i9 上でネイティブ稼働し、Mac のファンは沈黙したまま。