Clarify active Windows client architecture

README.md

@@ -53,6 +53,60 @@ docker compose -f docker-compose.client.yml logs -f
 docker compose -f docker-compose.client.yml restart
 ```
 
+## Windows: standalone desktop client direction
+
+Windows app routing lives in a separate Tauri 2 desktop utility, not as
+`APP_MODE=windows` inside the current Node gateway/client server. The active
+workspace slice is `apps/windows-client`.
+
+Active design documents:
+
+- Product/tech brief: `docs/windows-client-product-tech-brief.md`
+- Execution plan: `docs/goals/windows-modular-client/PLAN.md`
+- Windows client README: `apps/windows-client/README.md`
+
+Target shape:
+
+- Control App: compact Windows UI for status, profiles, targets, components,
+  logs, and diagnostics.
+- Proxyfier Layer: adapter boundary with ProxiFyre as the first engine for
+  per-app TCP/UDP routing.
+- Local sing-box: optional local runtime; external SOCKS5/HTTP targets must
+  work without it.
+
+Development checks:
+
+```powershell
+cd apps/windows-client
+npm install
+npm run build
+npm run tauri -- info
+
+cd src-tauri
+cargo test
+```
+
+Native Tauri build requires WebView2, Rust/rustup, and Visual Studio Build
+Tools with MSVC and Windows SDK components. In the current checkpoint, frontend
+builds pass, while native Rust/Tauri tests require that Windows toolchain.
+
+The three Windows pieces are installed and operated separately:
+
+```powershell
+cd apps/windows-client
+& .\scripts\install-control-app.ps1 -PlanOnly
+& .\scripts\install-proxyfier.ps1 -PlanOnly
+& .\scripts\install-singbox.ps1 -PlanOnly
+```
+
+`-PlanOnly` returns structured JSON without install side effects. Real install
+or service operations must be explicit; profile apply must not silently install
+Proxyfier or Local sing-box.
+
+Windows source configuration is owned by JSON under
+`C:\ProgramData\VpnProxy\config`. Generated ProxiFyre and sing-box files under
+`C:\ProgramData\VpnProxy\generated` are derived artifacts.
+
 ---
 
 # VPN Proxy Gateway