feat: 扩展发布打包支持多组件多架构多格式产物

- 新增 web 组件独立发布为 nex-web_<version>.tar.gz
- server 新增 arm64 架构、macOS universal、Windows arm64 产物
- desktop 新增 arm64 架构支持（Linux/Windows）
- Linux desktop 新增 AppImage、deb、rpm 安装包格式
- macOS desktop 新增 unsigned DMG 安装包
- 统一发布资产命名为 {component}_{version}_{platform}_{arch}.{ext}
- 新增 SHA256SUMS 校验和清单覆盖全部发布资产
- versionctl 新增 asset-name CLI 支持按参数生成资产文件名
- Makefile release target 重构为组件/平台/架构参数化
- GitHub Actions release workflow 扩展多组件多架构构建矩阵
- 同步更新 openspec 主规范（desktop-app/release-pipeline/workspace-command-flows）

openspec/specs/desktop-app/spec.md

@@ -139,29 +139,92 @@ TBD - 提供跨平台桌面应用支持，将后端服务与前端静态资源
 
 ### Requirement: 跨平台构建
 
-系统 SHALL 支持跨平台构建和打包。构建 target SHALL 按平台分离，中间构建产物文件名 SHALL 保持 `nex-{os}-{arch}[.exe]` 格式，最终桌面发布资产文件名 SHALL 包含统一版本号和平台标识。
+系统 SHALL 支持跨平台构建和打包。构建 target SHALL 按平台和架构分离或参数化，中间构建产物文件名 SHALL 保持可区分目标平台和架构，最终桌面发布资产文件名 SHALL 包含统一版本号、组件、平台、架构和格式信息。
 
 #### Scenario: macOS 构建
 
-- **WHEN** 执行 `desktop-build-mac` 构建命令且当前版本为 `1.2.3`
-- **THEN** 生成 `nex-mac-arm64` 和 `nex-mac-amd64` 可执行文件
-- **AND** 系统生成可打包为 `.app` bundle 的 macOS 桌面产物
-- **AND** 最终发布资产文件名 SHALL 包含 `1.2.3` 和 `macOS` 平台标识
+- **WHEN** 执行 macOS desktop 构建命令且当前版本为 `1.2.3`
+- **THEN** 系统 SHALL 生成 macOS arm64 和 amd64 桌面可执行文件
+- **AND** 系统 SHALL 使用 `lipo` 生成 macOS universal 桌面可执行文件
+- **AND** 系统 SHALL 生成可打包为 `.app` bundle 的 macOS desktop 产物
+- **AND** 最终 macOS desktop 发布资产文件名 SHALL 包含 `1.2.3`、`macos` 和 `universal`
 
 #### Scenario: Windows 构建
 
-- **WHEN** 执行 `desktop-build-win` 构建命令且当前版本为 `1.2.3`
-- **THEN** 系统生成 Windows 桌面可执行文件
-- **AND** 生成 `nex-win-amd64.exe` 可执行文件
-- **AND** 使用 `-H=windowsgui` linker flag 隐藏控制台窗口
-- **AND** 最终发布资产文件名 SHALL 包含 `1.2.3` 和 `windows` 平台标识
+- **WHEN** 执行 Windows desktop 构建命令且当前版本为 `1.2.3`
+- **THEN** 系统 SHALL 生成 Windows amd64 和 arm64 desktop 可执行文件
+- **AND** Windows desktop 构建 SHALL 使用 `-H=windowsgui` linker flag 隐藏控制台窗口
+- **AND** 最终 Windows desktop 发布资产文件名 SHALL 包含 `1.2.3`、`windows` 和对应架构标识
 
 #### Scenario: Linux 构建
 
-- **WHEN** 执行 `desktop-build-linux` 构建命令且当前版本为 `1.2.3`
-- **THEN** 系统生成 Linux 桌面可执行文件
-- **AND** 生成 `nex-linux-amd64` 可执行文件
-- **AND** 最终发布资产文件名 SHALL 包含 `1.2.3` 和 `linux` 平台标识
+- **WHEN** 执行 Linux desktop 构建命令且当前版本为 `1.2.3`
+- **THEN** 系统 SHALL 生成 Linux amd64 和 arm64 desktop 可执行文件
+- **AND** Linux desktop 构建 SHALL 使用 CGO 和 GTK/AppIndicator 构建依赖
+- **AND** 最终 Linux desktop 发布资产文件名 SHALL 包含 `1.2.3`、`linux` 和对应架构标识
+
+### Requirement: Linux 桌面发布安装包
+
+系统 SHALL 为 Linux desktop amd64 和 arm64 生成 tar.gz、AppImage、deb 和 rpm 发布安装包，并 SHALL 在安装包中包含标准桌面集成元数据。
+
+#### Scenario: Linux desktop tar.gz 裸包
+
+- **WHEN** 构建 Linux desktop 发布资产
+- **THEN** 系统 SHALL 为 amd64 生成 `nex-desktop_<version>_linux_amd64.tar.gz`
+- **AND** 系统 SHALL 为 arm64 生成 `nex-desktop_<version>_linux_arm64.tar.gz`
+
+#### Scenario: Linux desktop AppImage 包
+
+- **WHEN** 构建 Linux desktop AppImage 发布资产
+- **THEN** 系统 SHALL 为 amd64 生成 `nex-desktop_<version>_linux_amd64.AppImage`
+- **AND** 系统 SHALL 为 arm64 生成 `nex-desktop_<version>_linux_arm64.AppImage`
+- **AND** AppImage SHALL 包含 desktop entry、应用图标和 desktop 可执行文件
+- **AND** AppImage SHALL 依赖目标系统提供 GTK3、Ayatana AppIndicator 和运行 AppImage 所需的 runtime/FUSE 能力
+
+#### Scenario: Linux desktop deb 包
+
+- **WHEN** 构建 Linux desktop deb 发布资产
+- **THEN** 系统 SHALL 为 amd64 生成 `nex-desktop_<version>_linux_amd64.deb`
+- **AND** 系统 SHALL 为 arm64 生成 `nex-desktop_<version>_linux_arm64.deb`
+- **AND** deb 包 SHALL 将可执行文件安装到 `/usr/bin/nex`
+- **AND** deb 包 SHALL 将 desktop entry 安装到 `/usr/share/applications/nex.desktop`
+- **AND** deb 包 SHALL 将 hicolor 图标安装到 `/usr/share/icons/hicolor/.../apps/nex.png`
+- **AND** deb 包 SHALL 声明 `libgtk-3-0`、`libayatana-appindicator3-1` 和 `xdg-utils` 运行时依赖
+- **AND** deb 包 metadata 的架构字段 SHALL 使用 `amd64` 或 `arm64`
+
+#### Scenario: Linux desktop rpm 包
+
+- **WHEN** 构建 Linux desktop rpm 发布资产
+- **THEN** 系统 SHALL 为 amd64 生成 `nex-desktop_<version>_linux_amd64.rpm`
+- **AND** 系统 SHALL 为 arm64 生成 `nex-desktop_<version>_linux_arm64.rpm`
+- **AND** rpm 包 SHALL 将可执行文件安装到 `/usr/bin/nex`
+- **AND** rpm 包 SHALL 将 desktop entry 安装到 `/usr/share/applications/nex.desktop`
+- **AND** rpm 包 SHALL 将 hicolor 图标安装到 `/usr/share/icons/hicolor/.../apps/nex.png`
+- **AND** rpm 包 SHALL 声明 `gtk3`、`libayatana-appindicator-gtk3` 和 `xdg-utils` 运行时依赖
+- **AND** rpm 包 metadata 的架构字段 SHALL 使用 `x86_64` 或 `aarch64`
+
+### Requirement: macOS DMG 打包
+
+系统 SHALL 为 macOS desktop universal `.app` 生成 unsigned DMG 安装包，并 SHALL 保留 universal zip 发布资产。
+
+#### Scenario: macOS universal zip 包
+
+- **WHEN** 构建 macOS desktop 发布资产且当前版本为 `1.2.3`
+- **THEN** 系统 SHALL 生成 `nex-desktop_1.2.3_macos_universal.zip`
+- **AND** zip 包 SHALL 包含 `Nex.app`
+
+#### Scenario: macOS universal DMG 包
+
+- **WHEN** 构建 macOS desktop DMG 发布资产且当前版本为 `1.2.3`
+- **THEN** 系统 SHALL 生成 `nex-desktop_1.2.3_macos_universal.dmg`
+- **AND** DMG SHALL 包含 `Nex.app`
+- **AND** DMG SHALL 包含指向 `/Applications` 的快捷方式
+- **AND** DMG SHALL NOT 要求 macOS 签名或 notarization 才能完成构建
+
+#### Scenario: macOS universal 架构校验
+
+- **WHEN** macOS desktop universal 可执行文件生成完成
+- **THEN** 系统 SHALL 验证该可执行文件包含 amd64 和 arm64 架构
 
 ### Requirement: macOS .app 打包
 

openspec/specs/release-pipeline/spec.md

@@ -32,88 +32,116 @@
 
 ### Requirement: 三平台发布构建
 
-系统 SHALL 在发布流水线中构建 server 与 desktop 的 Linux、Windows、macOS 三个平台产物。
+系统 SHALL 在发布流水线中构建 server、web 与 desktop 的发布产物，并覆盖 Linux、Windows、macOS 的目标架构和格式矩阵。
 
-#### Scenario: Linux 发布构建
+#### Scenario: server 发布构建
 
-- **WHEN** 发布流水线执行 Linux 构建 job
-- **THEN** 系统 SHALL 在可访问 Go、Bun 和 Linux 桌面构建依赖的 shell 环境中执行 Linux 发布构建
-- **AND** 系统 SHALL 生成 Linux server 发布资产
-- **AND** 系统 SHALL 生成 Linux desktop 发布资产
+- **WHEN** 发布流水线执行 server 发布构建
+- **THEN** 系统 SHALL 生成 `nex-server_<version>_linux_amd64.tar.gz`
+- **AND** 系统 SHALL 生成 `nex-server_<version>_linux_arm64.tar.gz`
+- **AND** 系统 SHALL 生成 `nex-server_<version>_macos_amd64.tar.gz`
+- **AND** 系统 SHALL 生成 `nex-server_<version>_macos_arm64.tar.gz`
+- **AND** 系统 SHALL 生成 `nex-server_<version>_macos_universal.tar.gz`
+- **AND** 系统 SHALL 生成 `nex-server_<version>_windows_amd64.zip`
+- **AND** 系统 SHALL 生成 `nex-server_<version>_windows_arm64.zip`
 
-#### Scenario: Windows 发布构建
+#### Scenario: web 发布构建
 
-- **WHEN** 发布流水线执行 Windows 构建 job
-- **THEN** 系统 SHALL 在包含 MSYS2 / MINGW64 构建工具且可访问 Go 与 Bun 工具链的 shell 环境中执行 Windows 发布构建
-- **AND** 系统 SHALL 生成 Windows server 发布资产
-- **AND** 系统 SHALL 生成 Windows desktop 发布资产
+- **WHEN** 发布流水线执行 web 发布构建
+- **THEN** 系统 SHALL 使用 Bun 构建 `frontend/dist`
+- **AND** 系统 SHALL 将前端静态资源打包为 `nex-web_<version>.tar.gz`
+- **AND** server 发布资产 SHALL NOT 内置 Web 管理界面静态资源
 
-#### Scenario: macOS 发布构建
+#### Scenario: Linux desktop 发布构建
 
-- **WHEN** 发布流水线执行 macOS 构建 job
-- **THEN** 系统 SHALL 在可访问 Go、Bun 和 macOS 打包工具链的 shell 环境中执行 macOS 发布构建
-- **AND** 系统 SHALL 生成 darwin-amd64 server 发布资产
-- **AND** 系统 SHALL 生成 darwin-arm64 server 发布资产
-- **AND** 系统 SHALL 生成 macOS desktop universal 发布资产
+- **WHEN** 发布流水线执行 Linux desktop 发布构建
+- **THEN** 系统 SHALL 在可访问 Go、Bun、CGO、GTK3、Ayatana AppIndicator 和 Linux 打包工具链的环境中构建
+- **AND** 系统 SHALL 为 `amd64` 和 `arm64` 分别生成 tar.gz、AppImage、deb 和 rpm desktop 发布资产
+- **AND** Linux arm64 desktop 发布构建 SHALL 使用原生 arm64 runner 或等价的 arm64 Linux 构建环境
+
+#### Scenario: Windows desktop 发布构建
+
+- **WHEN** 发布流水线执行 Windows desktop 发布构建
+- **THEN** 系统 SHALL 在包含对应架构 MSYS2/MinGW 或等价 CGO 工具链的环境中构建
+- **AND** 系统 SHALL 生成 `nex-desktop_<version>_windows_amd64.zip`
+- **AND** 系统 SHALL 生成 `nex-desktop_<version>_windows_arm64.zip`
+
+#### Scenario: macOS desktop 发布构建
+
+- **WHEN** 发布流水线执行 macOS desktop 发布构建
+- **THEN** 系统 SHALL 在可访问 Go、Bun、Xcode 命令行工具、`lipo`、`hdiutil` 和 zip 打包工具的 macOS 环境中构建
+- **AND** 系统 SHALL 生成 `nex-desktop_<version>_macos_universal.zip`
+- **AND** 系统 SHALL 生成 `nex-desktop_<version>_macos_universal.dmg`
 
 ### Requirement: 三平台发布构建预检
 
-系统 SHALL 在正式执行各平台 `make release-assets-*` 前验证对应发布 job 的关键工具链可用性，并在环境不完整时快速失败且输出明确诊断。
+系统 SHALL 在正式执行各平台 release 构建前验证对应 job 的关键工具链可用性，并在环境不完整时快速失败且输出明确诊断。
 
 #### Scenario: Linux 预检通过后开始构建
 
-- **WHEN** Linux 发布 job 中的 `go`、`bun` 与 Linux 桌面构建依赖均可用
+- **WHEN** Linux 发布 job 中的 `go`、`bun`、`gcc`、`pkg-config`、GTK3、Ayatana AppIndicator 和 Linux 打包工具均可用
 - **THEN** 系统 SHALL 输出关键工具的版本信息或解析路径
-- **AND** 系统 SHALL 继续执行 `make release-assets-linux`
+- **AND** 系统 SHALL 继续执行对应 Linux release 构建
 
 #### Scenario: Windows 预检通过后开始构建
 
-- **WHEN** Windows 发布 job 中的 `go`、`bun` 与 MSYS2 构建工具均可用
+- **WHEN** Windows 发布 job 中的 `go`、`bun`、`make`、对应架构 CGO 编译器和 resource 生成工具均可用
 - **THEN** 系统 SHALL 输出关键工具的版本信息或解析路径
-- **AND** 系统 SHALL 继续执行 `make release-assets-windows`
+- **AND** 系统 SHALL 继续执行对应 Windows release 构建
 
 #### Scenario: macOS 预检通过后开始构建
 
-- **WHEN** macOS 发布 job 中的 `go`、`bun` 与 macOS 打包工具均可用
+- **WHEN** macOS 发布 job 中的 `go`、`bun`、`ditto`、`lipo`、`vtool` 和 `hdiutil` 均可用
 - **THEN** 系统 SHALL 输出关键工具的版本信息或解析路径
-- **AND** 系统 SHALL 继续执行 `make release-assets-macos`
+- **AND** 系统 SHALL 继续执行对应 macOS release 构建
 
-#### Scenario: 任一平台预检发现工具缺失
+#### Scenario: web 预检通过后开始构建
 
-- **WHEN** 任一平台发布 job 中存在关键工具不可用
+- **WHEN** web 发布 job 中的 `bun` 和前端构建依赖均可用
+- **THEN** 系统 SHALL 输出 Bun 版本信息
+- **AND** 系统 SHALL 继续执行 web release 构建
+
+#### Scenario: 任一预检发现工具缺失
+
+- **WHEN** 任一发布 job 中存在关键工具不可用
 - **THEN** 发布流水线 SHALL 在正式构建前失败
 - **AND** 系统 SHALL 在日志中标识缺失的工具链名称
 
 ### Requirement: 发布流水线 LFS 资产拉取
 
-发布流水线 SHALL 在所有会 checkout 仓库并参与版本校验或平台构建的 job 中拉取 Git LFS 真实文件，确保发布构建读取到真实二进制资产而非 LFS pointer 文本。
+发布流水线 SHALL 在所有会 checkout 仓库并参与版本校验、web 构建、server 构建或 desktop 构建的 job 中拉取 Git LFS 真实文件，确保发布构建读取到真实二进制资产而非 LFS pointer 文本。
 
 #### Scenario: 发布 job 获取真实 LFS 图标资产
 
-- **WHEN** 发布流水线执行 `prepare`、`build-linux`、`build-windows` 或 `build-macos` job 的 checkout 步骤
+- **WHEN** 发布流水线执行任一参与版本校验、web 构建、server 构建或 desktop 构建的 job 的 checkout 步骤
 - **THEN** checkout 步骤 SHALL 拉取 Git LFS 文件
 - **AND** `assets/icon.ico`、`assets/icon.icns`、`assets/icon.png` 和 `frontend/public/icon.png` SHALL 在后续步骤中表现为真实图标文件而非 LFS pointer 文本
 
+#### Scenario: 新增矩阵 job 获取真实 LFS 资产
+
+- **WHEN** 发布流水线新增 server、web、desktop、platform 或 arch 矩阵 job
+- **THEN** 该 job 的 checkout 步骤 SHALL 使用与现有发布 job 一致的 Git LFS 拉取配置
+
 ### Requirement: 发布资产图标预检
 
-发布流水线 SHALL 在正式执行各平台发布构建前校验关键图标资产可用，并在检测到 LFS pointer 或错误格式时快速失败且输出明确诊断。
+发布流水线 SHALL 在正式执行任何需要图标资产、前端 public 图标或 desktop 打包资源的发布构建前校验关键图标资产可用，并在检测到 LFS pointer 或错误格式时快速失败且输出明确诊断。
 
 #### Scenario: 图标资产为 LFS pointer
 
 - **WHEN** 发布资产预检发现关键图标文件内容为 Git LFS pointer 文本
-- **THEN** 发布流水线 SHALL 在执行平台发布构建前失败
+- **THEN** 发布流水线 SHALL 在执行对应 release 构建前失败
 - **AND** 系统 SHALL 在日志中标识对应图标文件需要拉取 Git LFS 真实内容
 
 #### Scenario: 图标资产格式无效
 
 - **WHEN** 发布资产预检发现关键图标文件不是对应格式的有效资源
-- **THEN** 发布流水线 SHALL 在执行平台发布构建前失败
+- **THEN** 发布流水线 SHALL 在执行对应 release 构建前失败
 - **AND** 系统 SHALL 在日志中标识格式无效的图标文件路径
 
 #### Scenario: 图标资产预检通过
 
 - **WHEN** `assets/icon.ico`、`assets/icon.icns`、`assets/icon.png` 和 `frontend/public/icon.png` 均为真实且格式可用的图标资产
-- **THEN** 发布流水线 SHALL 继续执行对应平台的 `make release-assets-*` 构建
+- **THEN** 发布流水线 SHALL 继续执行依赖这些资产的 release 构建
 
 ### Requirement: 发布流水线运行时兼容性
 
@@ -131,34 +159,54 @@
 
 ### Requirement: 版本化发布资产命名
 
-系统 SHALL 为 server 与 desktop 的发布资产使用包含统一版本号和目标平台信息的文件名，确保 Release 页面可直接区分产物用途与平台。
+系统 SHALL 为 server、web 与 desktop 发布资产使用包含统一版本号、组件、目标平台和目标架构信息的文件名，确保 Release 页面可直接区分产物用途、平台、架构和格式。
 
 #### Scenario: server 资产命名
 
 - **WHEN** 当前发布版本为 `1.2.3`
-- **THEN** Linux server 发布资产文件名 SHALL 包含 `1.2.3`、`linux` 和 `amd64`
-- **AND** Windows server 发布资产文件名 SHALL 包含 `1.2.3`、`windows` 和 `amd64`
-- **AND** macOS server 发布资产文件名 SHALL 分别包含 `1.2.3`、`darwin`、`amd64` 与 `1.2.3`、`darwin`、`arm64`
+- **THEN** Linux server 发布资产文件名 SHALL 为 `nex-server_1.2.3_linux_amd64.tar.gz` 和 `nex-server_1.2.3_linux_arm64.tar.gz`
+- **AND** macOS server 发布资产文件名 SHALL 为 `nex-server_1.2.3_macos_amd64.tar.gz`、`nex-server_1.2.3_macos_arm64.tar.gz` 和 `nex-server_1.2.3_macos_universal.tar.gz`
+- **AND** Windows server 发布资产文件名 SHALL 为 `nex-server_1.2.3_windows_amd64.zip` 和 `nex-server_1.2.3_windows_arm64.zip`
+
+#### Scenario: web 资产命名
+
+- **WHEN** 当前发布版本为 `1.2.3`
+- **THEN** web 发布资产文件名 SHALL 为 `nex-web_1.2.3.tar.gz`
+- **AND** web 发布资产文件名 SHALL NOT 包含平台或架构字段
 
 #### Scenario: desktop 资产命名
 
 - **WHEN** 当前发布版本为 `1.2.3`
-- **THEN** Linux desktop 发布资产文件名 SHALL 包含 `1.2.3` 和 `linux`
-- **AND** Windows desktop 发布资产文件名 SHALL 包含 `1.2.3` 和 `windows`
-- **AND** macOS desktop universal 发布资产文件名 SHALL 包含 `1.2.3` 和 `macOS`
+- **THEN** Linux desktop 发布资产文件名 SHALL 使用 `nex-desktop_1.2.3_linux_<arch>.<format>` 格式
+- **AND** Windows desktop 发布资产文件名 SHALL 为 `nex-desktop_1.2.3_windows_amd64.zip` 和 `nex-desktop_1.2.3_windows_arm64.zip`
+- **AND** macOS desktop 发布资产文件名 SHALL 为 `nex-desktop_1.2.3_macos_universal.zip` 和 `nex-desktop_1.2.3_macos_universal.dmg`
+- **AND** 发布资产文件名中的 macOS 平台字段 SHALL 使用 `macos` 而非 `darwin`
 
 ### Requirement: Draft Release 组装
 
-系统 SHALL 将发布流水线产物上传到 GitHub Draft Release，由人工确认后再公开发布。
+系统 SHALL 将发布流水线产物上传到 GitHub Draft Release，由人工确认后再公开发布，并 SHALL 生成覆盖全部发布资产的校验和清单。
 
 #### Scenario: 发布成功时创建 Draft Release
 
-- **WHEN** 版本校验通过且三平台发布资产构建完成
+- **WHEN** 版本校验通过且 server、web、desktop 的全部目标发布资产构建完成
 - **THEN** 系统 SHALL 创建或更新与该 tag 对应的 GitHub Draft Release
-- **AND** 系统 SHALL 上传 server 与 desktop 的全部发布资产
+- **AND** 系统 SHALL 上传 server、web 与 desktop 的全部发布资产
+- **AND** 系统 SHALL 上传 `SHA256SUMS`
+
+#### Scenario: 校验和覆盖全部资产
+
+- **WHEN** Draft Release 组装步骤生成 `SHA256SUMS`
+- **THEN** `SHA256SUMS` SHALL 包含除自身以外的全部发布资产文件
+- **AND** `SHA256SUMS` 中的文件名 SHALL 与实际上传的 release asset 文件名一致
 
 #### Scenario: 构建失败时阻止完成发布
 
-- **WHEN** 任一平台发布资产构建失败或版本校验失败
+- **WHEN** 任一目标发布资产构建失败、打包失败、校验失败、artifact 上传为空或版本校验失败
 - **THEN** 发布流水线 SHALL 失败
 - **AND** 系统 SHALL NOT 产生可直接公开的成功发布结果
+
+#### Scenario: artifact 缺失时快速失败
+
+- **WHEN** 任一构建 job 尝试上传 release artifact 但匹配不到目标文件
+- **THEN** 该 job SHALL 失败
+- **AND** Draft Release 组装 SHALL NOT 继续发布不完整资产集合

openspec/specs/workspace-command-flows/spec.md

@@ -8,17 +8,26 @@
 
 ### Requirement: 根目录公开命令分层
 
-根目录 `Makefile` SHALL 仅暴露全局命令、版本命令、server 产品命令、desktop 产品命令和 release 命令，不再作为 backend 局部维护命令或内部打包步骤的公开入口。
+根目录 `Makefile` SHALL 仅暴露全局命令、版本命令、server 产品命令、desktop 产品命令和 release 命令，不再作为 backend 局部维护命令或内部打包步骤的公开入口。release 命令 SHALL 使用 `release-assets` 前缀，并 SHALL 通过清晰的目标名或变量参数表达 component、platform、arch 和 format。
 
 #### Scenario: 查看根目录公开命令
+
 - **WHEN** 开发者查看根目录 `Makefile` 的公开 target
-- **THEN** SHALL 仅看到 `lint`、`test`、`clean`、`version-sync`、`version-check`、`server-run`、`server-build`、`server-lint`、`server-test`、`server-clean`、`desktop-build-mac`、`desktop-build-win`、`desktop-build-linux`、`desktop-lint`、`desktop-test`、`desktop-clean`、`release-assets-linux`、`release-assets-windows`、`release-assets-macos` 这类公共入口
+- **THEN** SHALL 仅看到 `lint`、`test`、`clean`、`version-sync`、`version-check`、`server-run`、`server-build`、`server-lint`、`server-test`、`server-clean`、`desktop-build-mac`、`desktop-build-win`、`desktop-build-linux`、`desktop-lint`、`desktop-test`、`desktop-clean` 和 `release-assets` 前缀的 release 公共入口
+- **AND** release 公共入口 SHALL 能覆盖 server、web、desktop 的目标发布产物
 
 #### Scenario: 根目录不暴露局部和内部命令
+
 - **WHEN** 开发者查看根目录 `Makefile` 的公开 target
 - **THEN** SHALL NOT 暴露 `backend-*`、`frontend-*`、数据库迁移命令、MySQL 专项测试命令或 `desktop-prepare-*` 之类内部步骤
 - **THEN** SHALL NOT 暴露 `dev`、`build`、`all`、`desktop-dev`、`desktop-build` 这类模糊或聚合式公共命令
 
+#### Scenario: release 内部步骤保持内部化
+
+- **WHEN** 根目录 `Makefile` 需要复用 release 构建、打包、校验辅助步骤
+- **THEN** 内部辅助 target SHALL 使用 `_` 前缀或 Make 变量参数化方式表达
+- **AND** 内部辅助 target SHALL NOT 成为文档化的公共入口
+
 ### Requirement: 全局质量与清理命令
 
 根目录 `Makefile` SHALL 提供 `lint`、`test`、`clean` 作为全仓默认入口。
@@ -97,12 +106,33 @@
 
 ### Requirement: Release 命令沿用根目录入口
 
-根目录 `Makefile` SHALL 继续提供 `release-assets-*` 作为发布资产入口，并与新的版本校验规则保持一致。
+根目录 `Makefile` SHALL 继续提供 `release-assets` 前缀 target 作为发布资产入口，并与版本校验、发布资产预检和多组件打包规则保持一致。
 
 #### Scenario: 执行 release 资产命令
-- **WHEN** 执行 `make release-assets-linux`、`make release-assets-windows` 或 `make release-assets-macos`
+
+- **WHEN** 执行任一 `release-assets` 前缀的公共 release target
 - **THEN** SHALL 在构建发布资产前执行版本一致性校验
-- **THEN** SHALL NOT 隐式执行 `version-sync` 或修改版本镜像文件
+- **AND** SHALL 在需要图标或桌面资源的构建前执行发布资产预检
+- **AND** SHALL NOT 隐式执行 `version-sync` 或修改版本镜像文件
+
+#### Scenario: release target 职责清晰
+
+- **WHEN** GitHub Actions 调用根目录 `Makefile` 生成 release 产物
+- **THEN** 对应 release target SHALL 明确生成的 component、platform、arch 或 format 范围
+- **AND** GitHub Actions SHALL NOT 以内联脚本替代 Makefile 中已有的核心构建和打包逻辑
+
+#### Scenario: web release 产物生成
+
+- **WHEN** 执行 web release 资产命令
+- **THEN** SHALL 使用 Bun 构建 `frontend/dist`
+- **AND** SHALL 打包生成 `nex-web_<version>.tar.gz`
+- **AND** SHALL NOT 修改前端版本镜像文件
+
+#### Scenario: checksum release 产物生成
+
+- **WHEN** 执行 release 汇总或 Draft Release 组装相关命令
+- **THEN** SHALL 能基于当前 release 产物目录生成 `SHA256SUMS`
+- **AND** `SHA256SUMS` SHALL 覆盖除自身以外的全部 release 资产
 
 ### Requirement: Backend 局部命令下沉