build(release): 加固 v0.1.0 桌面发布链路 (#3)

docs/guides/branch-maintenance-sop-zh.md

@@ -106,8 +106,7 @@ npm run desktop:build:app
 npm run desktop:build:app
 ```
 
-正式桌面发布构建仍必须设置 updater 签名私钥和 Apple 签名/公证变量后，先执行
-`npm run desktop:release-readiness:check`，再执行 `npm run desktop:build:macos-release -- --ci`。
+正式桌面发布构建必须从同一正式 tag 分别在 macOS 和 Windows 原生 CI job 执行。两端都必须设置 updater 签名私钥；macOS 设置 Apple 签名/公证变量并以 `REQUIRE_DESKTOP_SIGNING=true` 执行 readiness 与 Universal 构建，Windows 设置 PFX 证书、密码和 RFC 3161 时间戳变量并以 `REQUIRE_WINDOWS_SIGNING=true` 执行 readiness、签名 NSIS 构建和 Authenticode 校验。两个平台通过后才能汇总正式 updater feed。
 
 后端改动应补充执行受影响模块的后端测试、迁移检查和接口回归。
 
@@ -207,6 +206,7 @@ dev -> main
 - 前后端测试通过
 - 网页端构建通过
 - macOS 桌面端构建通过
+- Windows x64 NSIS 兼容性构建通过；正式发布时签名和时间戳验证通过
 - 数据库迁移经过验证
 - 已知风险和回滚方式已记录
 
@@ -281,7 +281,7 @@ main -> release
 - 回归测试通过
 - 数据库迁移和回滚方案确认
 - 网页端生产构建通过
-- 桌面端生产构建通过
+- macOS 与 Windows 桌面端生产构建均从候选 tag 通过
 - 发布说明完成
 - 生产配置和密钥不在仓库中
 - 正式版本号已经统一
@@ -295,7 +295,7 @@ git tag -a v1.2.0 -m "CTMS v1.2.0"
 git push origin v1.2.0
 ```
 
-网页端和桌面端必须从同一个 `v1.2.0` 标签构建。不得从不同分支、不同提交或本地未提交状态构建正式制品。
+网页端、macOS 和 Windows 桌面端必须从同一个 `v1.2.0` 标签构建。不得从不同分支、不同提交或本地未提交状态构建正式制品。macOS 签名/公证、Windows 代码签名/RFC 3161 时间戳以及两个平台的 updater 签名制品必须全部验证通过后，才能分发安装包并最后原子替换生产 `latest.json`。
 
 发布记录至少包含：
 

docs/guides/client-release.md

@@ -66,8 +66,8 @@ Manual edits that leave these files inconsistent fail CI.
 ## Stabilization Gates
 
 Client builds require Node.js 22.13.0 or newer. The development frontend container,
-Web CI, macOS release candidates, Windows internal validation, and the production
-Web image use the same Node 22.13 baseline.
+Web CI, macOS and Windows release candidates, Windows internal validation, and the
+production Web image use the same Node 22.13 baseline.
 
 Client release candidates must pass the shared Web checks and the Desktop
 release/security gate before promotion:
@@ -85,8 +85,9 @@ npm run build
 npm run desktop:build:app
 ```
 
-`release:env:check` verifies build channel and commit metadata, and can be
-made strict for signed Desktop builds with `REQUIRE_DESKTOP_SIGNING=true`.
+`release:env:check` verifies build channel and commit metadata, and becomes
+platform-strict with `REQUIRE_DESKTOP_SIGNING=true` on macOS or
+`REQUIRE_WINDOWS_SIGNING=true` on Windows.
 `desktop:release:check` statically verifies the Tauri bundle, updater public
 key, CSP, capability scopes, command allowlist, query-token ban, generic system
 notification boundary, CI gate coverage, and secure session token boundary. The
@@ -96,7 +97,7 @@ full manual release, security, regression, and Desktop UX checklist lives in
 ## Promotion
 
 1. Merge feature branches into `dev`.
-2. Require the shared client/Web and macOS Desktop CI jobs to pass.
+2. Require the shared client/Web and macOS/Windows Desktop CI jobs to pass.
 3. Promote the accepted scope from `dev` to `main`.
 4. Set the release version and complete regression testing on `main`.
 5. Promote `main` to `release`.
@@ -130,11 +131,11 @@ for `localhost`, `127.0.0.1`, or `::1`.
 The release pipeline must:
 
 1. build from the accepted release tag and commit;
-2. build macOS Universal desktop artifacts;
-3. sign and notarize the macOS app;
-4. produce updater artifacts and `.sig` files with the updater private key;
-5. generate `latest.json` and a checksum manifest with `npm run desktop:update-feed:create`;
-6. verify the feed with `npm run desktop:update-feed:check -- --feed <release-dir>/latest.json --artifacts-dir <release-dir>`;
+2. build the Universal macOS app/DMG and Windows x64 NSIS installer from that tag;
+3. sign and notarize macOS, and Authenticode-sign Windows with an RFC 3161 timestamp;
+4. produce macOS `.app.tar.gz` and Windows `.nsis.zip` updater artifacts plus their `.sig` files with the shared updater private key;
+5. generate one combined `latest.json` and checksum manifest with `npm run desktop:update-feed:create`;
+6. verify all macOS and Windows entries with `npm run desktop:update-feed:check -- --feed <release-dir>/latest.json --artifacts-dir <release-dir> --require-platform windows-x86_64`;
 7. upload immutable artifacts first;
 8. atomically replace `latest.json` last.
 
@@ -142,6 +143,10 @@ For Universal macOS artifacts, `latest.json` must provide both
 `darwin-aarch64` and `darwin-x86_64` entries pointing at the same Universal
 update package.
 
+The same feed must also contain `windows-x86_64`, pointing to the signed NSIS
+`.nsis.zip` updater package. The Windows `.exe` installer is distributed next
+to the updater package but is not used as the updater URL.
+
 The signed release candidate workflow lives at
 `.github/workflows/desktop-release-candidate.yml`. It must be run from a
 matching `vX.Y.Z` tag and produces a verified release directory as a GitHub
@@ -149,21 +154,30 @@ artifact. That artifact is still only a release candidate; the release owner
 must upload immutable files to the production download origin and replace
 `latest.json` atomically after validation.
 
-## Windows Build Readiness
+## Windows Release and Internal Validation
 
-Second-phase Windows work is limited to CI compatibility validation. A
-`windows-latest` x64 NSIS build may be produced for verification, but it is not
-a formal deliverable until Windows code signing and release support are
-approved.
+Windows x64 NSIS is an approved formal Desktop target. Formal Windows builds
+run in `.github/workflows/desktop-release-candidate.yml` from the same exact
+`vX.Y.Z` tag and SHA as Web and macOS. They must:
 
-Windows validation must cover:
+- import a Base64-encoded PFX from `WINDOWS_CERTIFICATE` using
+  `WINDOWS_CERTIFICATE_PASSWORD`;
+- configure the imported certificate thumbprint, SHA-256 digest,
+  `WINDOWS_TIMESTAMP_URL`, and RFC 3161 timestamp mode dynamically in CI;
+- set `REQUIRE_WINDOWS_SIGNING=true` and use the updater signing secrets;
+- verify the application and installer with `Get-AuthenticodeSignature`,
+  including signer and timestamp certificates;
+- publish the signed NSIS `.exe`, `.nsis.zip`, and `.nsis.zip.sig` into the
+  combined verified Desktop release directory.
+
+Windows release validation also covers:
 
 - WebView2 runtime prerequisite behavior;
 - user-level installer assumptions;
 - Windows Credential Manager session storage;
 - path handling and temporary file cleanup;
 - notification and updater compilation;
-- future code-signing requirements.
+- code-signing trust, timestamp validity, and updater signature verification.
 
 The manual internal Windows validation workflow lives at
 `.github/workflows/desktop-windows-internal.yml`. It is `workflow_dispatch`
@@ -173,7 +187,24 @@ and Desktop safety gates, builds an unsigned NSIS installer with updater
 artifacts disabled, and uploads the `.exe` plus `SHA256SUMS.txt` as a GitHub
 Actions artifact. This workflow is for internal compatibility verification
 only; it must not generate `latest.json`, update feeds, signed release
-directories, or formal Windows release artifacts.
+directories, or formal Windows release artifacts. A successful internal build
+does not substitute for the signed tag-only release workflow.
+
+The formal workflow requires these organization settings:
+
+- secrets: `TAURI_SIGNING_PRIVATE_KEY`,
+  `TAURI_SIGNING_PRIVATE_KEY_PASSWORD`, `WINDOWS_CERTIFICATE`, and
+  `WINDOWS_CERTIFICATE_PASSWORD`;
+- variable: `WINDOWS_TIMESTAMP_URL`;
+- shared versioned HTTPS artifact prefix: `DESKTOP_UPDATE_BASE_URL` or the
+  manual workflow input.
+
+The checked-in workflow implements the exportable PFX path. Confirm that the
+organization's certificate policy permits an exportable CI certificate before
+provisioning it. If the selected CA provides only hardware- or cloud-backed
+keys, replace the PFX import with a reviewed Tauri `signCommand` integration
+(for example, the organization's Azure signing provider) while retaining the
+same Authenticode and timestamp verification gates.
 
 ## Required Checks
 
@@ -197,11 +228,12 @@ export REQUIRE_DESKTOP_SIGNING=true
 npm run release:env:check
 npm run desktop:release-readiness:check
 npm run desktop:build:macos-release -- --ci
-npm run desktop:update-feed:create -- --artifact <CTMS.app.tar.gz> --base-url <versioned-https-artifact-prefix> --output-dir <release-dir>
-npm run desktop:update-feed:check -- --feed <release-dir>/latest.json --artifacts-dir <release-dir>
+npm run desktop:update-feed:create -- --artifact <CTMS.app.tar.gz> --platform-artifact windows-x86_64=<CTMS.nsis.zip> --include <CTMS.dmg> --include <CTMS-installer.exe> --base-url <versioned-https-artifact-prefix> --output-dir <release-dir>
+npm run desktop:update-feed:check -- --feed <release-dir>/latest.json --artifacts-dir <release-dir> --require-platform windows-x86_64
 ```
 
-The Desktop build must run on macOS for the current first-phase target. A signed
-or notarized public release additionally requires the Apple credentials defined
-by the release owner. A formal second-phase desktop release also requires the
-updater signing key; unsigned internal builds are not formal distributions.
+The macOS and Windows signed builds run in their native CI jobs. macOS requires
+the Apple signing/notarization credentials defined by the release owner;
+Windows requires the PFX certificate/password and timestamp URL above. Both use
+the same updater signing key and are aggregated only after both native jobs
+pass. Unsigned internal builds are not formal distributions.