merge: 解 origin/dev 三处冲突（M182 / M184+M190 / README §14），两边都留

冲突（都来自别人后来改同一批文件）： - crates/app-iced/src/platform/mod.rs：保留 M182 的 HostOs / host·linux·macos 分册表 / plan_corner_for，同时保留 M196 的 `[`win32::console`]` 落点说明；把 M182 措辞里已经不成立的「唯一 unsafe 落点 / 只此一处」改成「两处落点（transparency + console）」（unsafe-scope 门禁自 M196 起期望集合就是两处，不改这句文档就是错的）。注意：`pub mod console;` 属于 `platform/win32/mod.rs`，本次解冲突时一度被误加到 `platform/mod.rs`（`cargo check` 立刻报 E0583 文件不存在），已修回。 - .github/workflows/release-build.yml：M190 的「PE 版本资源读回」步、M184 的 linux-x64 xvfb 冒烟步与首帧上传步**全部逐字保留**；M196 的 PE 子系统门禁作为**兄弟步** 插在导入表门禁之后（两道 PE 门禁互不替代）。按块比对：dev 的 10 个步骤逐字未变，合并后 11 个步骤。 - packaging/README.md：保留 M184 的 §11 补充与 §12 行、M190 的 §14 签名段；§12 里 check_publish_slots 用 dev 的 11 条版本、另加 M196 的 check_pe_subsystem 行；§15 归位在 §14 之后。行数：release-build.yml 合并后 413 行会撞 400 行红线（dev 侧本来 393），故把 M196 那一步压到 6 行 + 1 空行（说明改由步骤名指路 packaging/README.md §15 与脚本 docstring 承载），最终正好 400 行。验证见 mission 报告：cargo check/test/fmt 全绿，两个 PE 门禁在同一批产物上都 exit 0 （子系统 GUI=2 / CLI=3，版本资源的 subsystem 读数同为 2 / 3）。
2026-11-09 05:49:38 +08:00
commit 1764301cdf
@@ -6,6 +6,9 @@ name: Release / build（可复用）
 #   `matrix.rustflags` → `inputs.rustflags`。
 # **M164 改了两步**（只这两步）：① `Windows ARM64 工具链体检` → `工具链取证`（不再 exit 1，判定权交回编译器；
 # 理由见该步上方的长注释）；② `cargo build` 步给 arm64 槽位显式备齐 target / `LIB`+`INCLUDE` / arm64 `link.exe`。
+# **M184 加了一步**：`linux-x64` 的 xvfb 运行时冒烟（真渲一帧 + `[theme]` / `[backend] final` 日志断言 + 像素判定）——
+# 这一档进了 `PUBLISH_SLOTS`，「发出去的包真能跑」从此由 CI 每轮证明；判据只在 `linux-x64` 槽位上跑（arm64 没有
+# 对应的运行时证据，不给它加一条没验证过的门禁）。同一轮把 arm64 的失败收尾注解按槽位分支。
 # 矩阵**仍由调用方** `release.yml` 的 `plan` job 生成并在外层展开（矩阵不能带 `if`，`strategy` 可读 `needs`），
 # 本文件只跑**单个槽位**，不持有槽位表 —— 改槽位只改 `release.yml` 里那一处。
 # `env` 必须在被调方重复声明：**被调工作流不继承调用方的 workflow 级 `env`**（CARGO_TERM_COLOR / RUST_BACKTRACE
@@ -203,11 +206,31 @@ jobs:
            fi
          fi
          cargo build --release --locked --bin unlucky-launcher-iced --bin ull
-          # 产物清单只给 arm64 打：x64（当前唯一在发的槽位）这一步零变化，不额外给它加失败面。
+          # 产物清单只给 windows-arm64 打：两档已发布的 x64（windows-x64 / linux-x64）这一步零变化，不额外给它们
+          # 加失败面（linux-x64 的证据在它自己那条 xvfb 运行时冒烟步里）。
          if [ "$SLOT" = "windows-arm64" ]; then
            ls -l "$BUILD_DIR"/unlucky-launcher-iced* "$BUILD_DIR"/ull* || true
          fi

+      # （M190）版本资源门禁：**读产物字节**，不信构建日志。`build.rs` 里写了 `CompanyName` 不等于
+      # 它进了 PE——资源在链接期被丢掉、或被后处理覆盖，都只有读回来才看得见。判据（字段值、四段式
+      # 版本号、FIXEDFILEINFO 的 dwFileVersion）全在 `packaging/check_pe_version.py`，本机可跑。
+      # 只在 Windows 槽位跑：Linux/macOS 产物没有 PE 头，那边 `build.rs` 整段不执行（见
+      # `packaging/pe_version.rs` 文件头）。**工具缺失也 fail**：找不到 python 就等于门禁失效。
+      - name: PE 版本资源读回（CompanyName / ProductName / 版权 / 版本号真的在产物里）
+        if: runner.os == 'Windows'
+        shell: bash
+        env:
+          BUILD_DIR: ${{ inputs.build_dir }}
+        run: |
+          set -euo pipefail
+          PY=$(command -v python3 || command -v python)
+          if [ -z "$PY" ]; then echo "::error::找不到 python，PE 版本资源门禁无法运行（门禁不降级）"; exit 1; fi
+          # 版本号与 Cargo.toml **同源**：`[workspace.package] version = "x.y.z"`。
+          version=$(sed -n 's/^version = "\(.*\)"/\1/p' Cargo.toml | head -n1)
+          echo "expect-version=$version"
+          "$PY" packaging/check_pe_version.py             "$BUILD_DIR/unlucky-launcher-iced.exe" "$BUILD_DIR/ull.exe"             --expect-version "$version"
+
      - name: Windows 单文件自检（导入表不得出现 VC++ 可再发行 DLL）
        if: runner.os == 'Windows'
        shell: bash
@@ -259,25 +282,55 @@ jobs:
            echo "::error::静态 CRT 未生效：exe 仍动态依赖 VC++ 可再发行包"; exit 1
          fi

-      # M196：**读产物 PE 头的 `Subsystem`**，不读源码。同一个修复 2026-11-01 曾打在已退役的 Slint 树
-      # （`37d3039` 只改了 `crates/app/src/main.rs`，而 `crates/app` 自 M118 起被 workspace `exclude`、
-      # 不进发布矩阵），于是「代码里写过」与「产物里有没有」彻底脱钩——双击多一个控制台窗口这个 bug
-      # 就是这么活到 2026-11-08 的。本步只认那 4 个字节：GUI 产物必须是 WINDOWS_GUI(2)，非 2 即红。
-      # 反方向一并守：CLI 产物 `ull.exe` 必须仍是 CONSOLE(3)——它靠真控制台做 stdout/stderr，
-      # 谁把属性抄到它头上，`ull --version | …` 会静默丢输出。守门本体在 packaging/check_pe_subsystem.py
-      # （零第三方依赖，本地同一份代码可跑；`--self-test` 注入 8 条回归（红 6 / 绿 2）证明它会红）。
-      - name: PE 子系统门禁（GUI 产物必须 WINDOWS_GUI/2，CLI 产物必须 CONSOLE/3）
+      - name: PE 子系统门禁（GUI=WINDOWS_GUI/2，CLI=CONSOLE/3；判据与理由见 packaging/README.md §15）
        if: runner.os == 'Windows'
        shell: bash
+        run: |
+          PY=$(command -v python3 || command -v python)
+          "$PY" packaging/check_pe_subsystem.py --gui "${{ inputs.build_dir }}/unlucky-launcher-iced.exe" --cli "${{ inputs.build_dir }}/ull.exe"
+
+      # （M184）linux-x64 的**运行时门禁**：这一档已进 PUBLISH_SLOTS，所以「发出去的包真能开窗渲出一帧」得由 CI 每轮证明，
+      # 不能只靠一次性的本机验收（证据与实测输出见 `packaging/docs/linux-evidence.md`）。
+      # **只在 linux-x64 槽位上跑**：判据是按 x64 软渲染实测标定的；`linux-arm64` 上这条链一次都没验过（没有 arm64 的
+      # xvfb 证据），写成无条件的 `runner.os == 'Linux'` 就等于给一个没验证过的槽位加一条会红的判据——正是 M171 那个
+      # 「豁免行要单独落」的同类事故。宁可这条只在有证据的槽位上真跑。
+      - name: Linux x64 运行时冒烟（xvfb 真渲一帧 + 主题/后端日志断言）
+        if: inputs.slot == 'linux-x64'
+        shell: bash
        env:
          BUILD_DIR: ${{ inputs.build_dir }}
        run: |
          set -euo pipefail
-          PY=$(command -v python3 || command -v python)
-          # 读数（含文件字节偏移）直接进日志：红的时候要看的就是这个数，而不是「脚本说不对」。
-          "$PY" packaging/check_pe_subsystem.py \
-            --gui "$BUILD_DIR/unlucky-launcher-iced.exe" \
-            --cli "$BUILD_DIR/ull.exe"
+          sudo apt-get update
+          sudo apt-get install -y --no-install-recommends xvfb xauth \
+            libxkbcommon-x11-0 libx11-6 libxcursor1 libxrandr2 libxi6 libfontconfig1 fonts-dejavu-core
+          out="$RUNNER_TEMP/linux-smoke"
+          mkdir -p "$out/data"
+          log="$out/launcher.log"
+          # 退出码单独取：`tee` 之后的 `$?` 是 tee 的，管道里 cargo/launcher 的失败会被吞成 0。
+          set +e
+          xvfb-run -a --server-args="-screen 0 1280x1024x24" \
+            "$BUILD_DIR/unlucky-launcher-iced" --software-renderer \
+            --screenshot "$out/linux-x64-first-frame.png" --data-dir "$out/data" 2>&1 | tee "$log"
+          code=${PIPESTATUS[0]}
+          set -e
+          echo "launcher exit=$code"
+          # 两条日志断言（两行都是**恒开**的，不依赖 ULL_ACCEPTANCE）：
+          #   `[theme] source=…flavor=…follows_system=…` 证明主题是按预期来源定的（截图通道默认 Light），
+          #   `[backend] final=… result=started` 证明渲染后端真的起来了（而不是起来前就崩了）。
+          grep -q '^\[theme\] source=' "$log" || { echo "::error::缺少 [theme] 行（主题来源没打印）"; exit 1; }
+          grep -q '^\[backend\] final=.* result=started' "$log" || { echo "::error::缺少 [backend] final=… result=started（渲染后端没起来）"; exit 1; }
+          python3 packaging/check_screenshot.py "$out/linux-x64-first-frame.png" --json
+          ls -l "$out"
+          exit "$code"
+
+      - name: 上传 Linux x64 首帧图（失败也传，人眼复核用）
+        if: always() && inputs.slot == 'linux-x64'
+        uses: actions/upload-artifact@v4
+        with:
+          name: linux-x64-first-frame
+          path: ${{ runner.temp }}/linux-smoke/
+          if-no-files-found: warn

      - name: 打包（产物 + SHA256SUMS）
        shell: bash
@@ -330,7 +383,18 @@ jobs:
      # 「不挡发布」——只剩一句 `Process completed with exit code 1.` 的教训见上面那条体检步骤。
      # M164 起本槽位的红**只可能来自真实构建链路**（体检已降级为取证、永不 exit 1），所以这条注解同时也是
      # 「arm64 到底能不能编出来」的答案所在：红了就把上面的编译器/链接器原文当根因，别再回去改体检。
+      # M184：Linux arm64 进来（它现在是 `mode: ci`，tag 推送默认就编），措辞按槽位分支 —— 两个 arm64 都**不在**发布名单里，
+      # 但理由不同：windows-arm64 等「能不能出 PE」的答案，linux-arm64 等「真机跑不跑得起来」的答案。
      - name: arm64 失败收尾注解（红不挡发布）
-        if: failure() && inputs.slot == 'windows-arm64'
+        if: failure() && (inputs.slot == 'windows-arm64' || inputs.slot == 'linux-arm64')
        shell: bash
-        run: echo "::error::[arm64] 本槽位已红，失败步骤见本 job 的步骤名（M164 起只会是 cargo build / 链接 / 导入表门禁 / 打包，体检步不再判红）；PUBLISH_SLOTS 当前只有 windows-x64 ⇒ 本次 Release 仍照发 x64，arm64 产物不进 Release"
+        env:
+          SLOT: ${{ inputs.slot }}
+        run: |
+          set -euo pipefail
+          if [ "$SLOT" = "linux-arm64" ]; then
+            reason="本槽位只有构建证据、运行时完全未验（没有 ARM64 真机跑过一帧）"
+          else
+            reason="失败步骤见本 job 的步骤名（M164 起只会是 cargo build / 链接 / 导入表门禁 / 打包，体检步不再判红）"
+          fi
+          echo "::error::[$SLOT] 本槽位已红：$reason。PUBLISH_SLOTS 当前是 windows-x64 + linux-x64 ⇒ 本次 Release 仍照发那两档，$SLOT 的产物不进 Release"
@@ -20,7 +20,8 @@ name: Release guard
 # （M164）同一个 job 还挂**发布名单守卫** `packaging/check_publish_slots.py`：`PUBLISH_SLOTS` 与槽位表/产物
 # 必须对得上。PR 阶段跑源码级断言（名单非空、每项都是 `release.yml` 槽位表里的 `mode: ci` 档）——
 # 名单里写错一个字此前只会表现为「Release 侧一个也不匹配、齐全性检查红在别处」，根因要翻两层日志；
-# `--self-test` 再注入 8 条回归（缺资产 / 拼错 / 声明了 probe 档 / 名单声明了没产物 / 有产物没声明）证明它会红。
+# `--self-test` 再注入 11 条回归（缺资产 / 拼错 / 声明了 probe 档 / 名单声明了没产物 / 有产物没声明 /
+# `mode: ci` 却没产物 / 声明的 `linux-x64` 构建红了必须拦住发布 / 提前把 `linux-arm64` 写进名单必须红）证明它会红。
 # 发布侧那道「产物 ⇄ 名单」的运行时断言在 `release-publish.yml`（同一份脚本，`--dist`）。
 #
 # （M169）同一个 job 再挂**测试通道守门** `packaging/check_test_source_off.py`：core/cli/presenter/
@@ -67,3 +68,19 @@ jobs:
        run: python3 packaging/check_test_source_off.py --self-test
      - name: 发布产物不含测试通道（workflow / 打包脚本 / Cargo default 都不许开）
        run: python3 packaging/check_test_source_off.py
+      # M190：签名脚本与 PE 版本资源门禁自己的自检。前者验 RFC 8032 向量（Ed25519 实现错了就发不出
+      # 能被验过的签名），后者把「口径表 ⇄ pe_version.rs」「四段式版本号换算」对拍，并造一个没有版本
+      # 资源的假 PE 断言判据**会红**（否则那道门禁对任何输入都绿，等于没有）。
+      - name: 清单签名脚本自检（RFC 8032 向量 + 信任表标记解析）
+        run: python3 packaging/sign_manifest.py --self-test
+      - name: PE 版本资源判据自检（口径表对拍 + 假 PE 必红）
+        run: python3 packaging/check_pe_version.py --self-test
+      # M190 r1 复审 P1-1：`.github/workflows/release-build.yml` 的 sed 替换串里混进过一枚裸 0x01
+      # （本意是 `\1`）。GitHub 解析这种文件会直接失败 ⇒ **整个 run 起不来**，而所有文本扫描型守卫
+      # 都看不见它（它们把 workflow 读成文本）。这条用**真 YAML 解析器** parse 全部 workflow，
+      # 外加一条「C0 控制字符」字节判据（两种失败模式各自独立报 `::error file=…,line=…`）。
+      # PyYAML 在 GitHub runner 上自带；万一缺失，脚本自己装一次，仍失败则红（门禁不降级）。
+      - name: workflow YAML 自检（注入 0x01 / 坏结构必须红）
+        run: python3 packaging/check_workflows_yaml.py --self-test
+      - name: workflow 全部可被真 YAML 解析器 parse（无裸控制字符）
+        run: python3 packaging/check_workflows_yaml.py
@@ -27,6 +27,14 @@ on:
      PUBLISH_TOKEN:
        description: "调用方透传 `secrets.GITHUB_TOKEN`（本 job 已声明 contents: write，`gh release` 用它发版）"
        required: true
+      # （M190 r1 复审 P1-2）**必须在这里声明**：可复用工作流只拿得到自己声明过的 secret，调用方
+      # `release.yml` 按名传了这一个，若被调方不声明，它要么在调用处报错、要么静默求值为空串——
+      # 两种结局都是「用户已把钥录进 Secret，发布仍在签名步红，而错误文案反过来指控 Secret 没配」。
+      # `required: false` 是刻意的：缺省为空串，由签名步的 `::error::` + `exit 1` 做 fail-closed
+      # （与 `release-build.yml` 的 `ULL_MSA_CLIENT_ID` 同一模式），失败信息才和事实一致。
+      ULL_MANIFEST_SIGNING_KEY:
+        description: "清单签名私钥（JSON：key_id + seed_hex）；未配置时签名步 fail-closed、不出 Release"
+        required: false

 # 权限取交集：调用方 release.yml 的 release job 与本文件都声明 contents: write，交集才是 write（不声明则被收窄成 read）。
 permissions:
@@ -40,18 +48,21 @@ jobs:
      contents: write
    env:
      # ── 发布白名单：唯一决定「哪几个槽位进 Release」的开关（空格分隔，键同 matrix.slot）──
-      # **M142 起只有 `windows-x64`**：arm64 连试四轮未走通，而齐全性检查是「名单内少一档就 fail」——名字挂着
-      # arm64 就等于 x64 编成功也发不出去。故把它移出名单：它照留在矩阵里跑取证，**红了不挡发布**。
-      # （M164）**为什么现在还只有 x64**：arm64 五轮全红其实都红在一个误判的编译前体检步（见 release-build.yml
-      # 顶部那段），真正的 cargo/link 一次都没跑过；M164 把那个门禁拆了、判定权交回编译器，但「arm64 能不能编出
-      # PE」只能由**下一 tag 的 CI** 证明，本机没有 ARM64 真机/工具链证不了。在拿到那次绿之前把 arm64 写进来，
-      # 等于拿 x64 的发布去赌它 —— 同一个事故不演第二遍（tower M164 裁决）。
-      # **可逆，且只是一行**：那句 CI 真出包之后把键加回这一行（`"windows-x64 windows-arm64"`），齐全性检查与
-      # SHA256SUMS 自动跟着扩，再同步 README §1/§9 与 release-notes.md 两张表。
+      # **M184 起是 `windows-x64` + `linux-x64`**：`linux-x64` 已真机验过 —— release 产物在 Linux 真机（WSLg 真窗口）
+      # 渲出一帧、主题/后端日志齐全，并有一条同槽位的 xvfb 运行时门禁常驻在 `release-build.yml`（证据与实测输出见
+      # `packaging/docs/linux-evidence.md`）。进名单的代价是「每轮发版都得真出这个包」：齐全性检查是「名单内少一档就 fail」，
+      # 所以这条名单同时也是「linux-x64 构建红了就挡住整次发布」的闸 —— 与任务要求一致（声明为 ci 就得真能出包）。
+      # **`linux-arm64` 不在名单里，且这一轮刻意不放**：它只有构建证据，运行时完全没有证据（没有 ARM64 真机跑过一帧，
+      # 也没有 arm64 的 xvfb 冒烟）。解锁条件 = arm64 真机（或原生 runner）上真跑出一帧 + 主题日志 → 再把键加进这一行。
+      # 只加进矩阵不加进名单时，它的产物会被下面的裁剪步删掉，但守卫会先打 `::warning::` 明说「未发布、会被裁掉」，
+      # 不是静默丢弃（这条是任务里点名要验的反方向）。
+      # `windows-arm64` 同理仍不在名单（M142/M164：它的五轮红全红在误判的体检步，判定权已交回编译器，等下一 tag 的 CI 证）。
+      # **可逆，且只是一行**：真出包之后把键加进这一行（`"windows-x64 linux-x64 <新键>"`），齐全性检查与 SHA256SUMS
+      # 自动跟着扩，再同步 README §1/§9 与 release-notes.md 两张表。
      # 判据不再靠注释保证：`packaging/check_publish_slots.py`（下面第二个 step 跑它；PR 阶段由 release-guard.yml
      # 跑同一份脚本）两个方向都查——声明了缺产物 ⇒ `::error::` + exit 1；有产物但没声明 ⇒ `::warning::` 明说未发布。
-      # 四档 Linux/macOS 仍未验证，默认连构建都不跑（M139）。
-      PUBLISH_SLOTS: "windows-x64"
+      # macOS 两档仍未验证，默认连构建都不跑（M139）。
+      PUBLISH_SLOTS: "windows-x64 linux-x64"
    steps:
      - uses: actions/checkout@v4

@@ -63,7 +74,7 @@ jobs:
      # （M164）发布名单守卫：**声明了就必须有产物**（名单内某个槽位缺 GUI 或 CLI 就红，少一档不发版），
      # 反方向的「产物在、名单没声明」则打 `::warning::` 明说未发布 —— M142 之后那个方向是**静默**的（裁剪步只
      # echo 一行 `drop:`，没有注解、也没有非零退出），一个真编出来的 arm64 会被就地 `rm` 掉而没人知道。
-      # 判据全在 `packaging/check_publish_slots.py`：同一份代码本地可跑，`--self-test` 注入 8 条回归断言每条都红。
+      # 判据全在 `packaging/check_publish_slots.py`：同一份代码本地可跑，`--self-test` 注入 11 条回归断言该红的红。
      # 它跑在**裁剪前**的全量集上（裁剪只删名单外的文件），所以是原来「裁剪后再查」那次检查的严格超集。
      - name: 发布名单守卫（声明 ⇒ 必须有产物；有产物没声明 ⇒ 显式未发布）
        shell: bash
@@ -87,7 +98,7 @@ jobs:
                echo "publish: $base"
                ;;
              *)
-                echo "drop:    $base（$platform_arch 不在发布白名单：四档未验证 / arm64 待下一 tag 验证；仍留在 dist-<slot> artifact 里取证）"
+                echo "drop:    $base（$platform_arch 不在发布白名单：macOS 两档未构建验证 / 两个 arm64 槽位待真机跑一帧；仍留在 dist-<slot> artifact 里取证）"
                rm -f "$f"
                ;;
            esac
@@ -128,6 +139,35 @@ jobs:
            --asset-base-url "$RELEASE_BASE/$TAG" \
            --released-at "$(date -u +%Y-%m-%dT%H:%M:%SZ)"

+      # （M190）清单签名：**签不上就不发版**。私钥只从仓库 Secret `ULL_MANIFEST_SIGNING_KEY` 进环境变量，
+      # 本步 `set +x` 且只回显**公钥**（日志里永远不出现私钥）。四条命令任一非零 ⇒ 本步红 ⇒ 不出 Release：
+      #   ① `--self-test`：RFC 8032 向量（签名脚本自己没坏）
+      #   ② `--check-pinned-keyring`：Secret 里的钥**必须**已在 `crates/core/src/update/trust.rs` 钉住
+      #      （签出一份客户端不认的清单，比不发版更糟）
+      #   ③ `--sign`：签的就是上一步落盘的 `dist/manifest.json` 原始字节，产出 `dist/manifest.json.sig`
+      # 红了的处置见 `packaging/docs/signing.md` §4 那张表（缺什么、怎么补，都写在脚本的 stderr 里）。
+      - name: 签更新清单（Ed25519；签不上就阻断发布）
+        shell: bash
+        env:
+          ULL_MANIFEST_SIGNING_KEY: ${{ secrets.ULL_MANIFEST_SIGNING_KEY }}
+        run: |
+          set -euo pipefail
+          set +x
+          PY=$(command -v python3 || command -v python)
+          if [ -z "$PY" ]; then echo "::error::找不到 python，签名步骤无法运行（签名门禁不降级）"; exit 1; fi
+          "$PY" packaging/sign_manifest.py --self-test
+          if [ -z "${ULL_MANIFEST_SIGNING_KEY:-}" ]; then
+            echo "::error::仓库 Secret ULL_MANIFEST_SIGNING_KEY 没配（或为空）：没有签名私钥就不发版。"
+            echo "::error::补法见 packaging/docs/signing.md §3：python3 packaging/sign_manifest.py --generate-key，把打印的 JSON 贴进 Secret、把 PinnedKey 那行贴进 crates/core/src/update/trust.rs"
+            exit 1
+          fi
+          "$PY" packaging/sign_manifest.py --check-pinned-keyring
+          "$PY" packaging/sign_manifest.py --sign dist/manifest.json
+          # ④ 产出后**用 trust.rs 里钉住的公钥回验一遍**：复现「客户端会怎么判」，而不是信签名脚本
+          # 自己那句「签好了」。私钥不需要参与，所以这一步跑在同一个环境里也不多一个泄露面。
+          "$PY" packaging/sign_manifest.py --verify-pinned dist/manifest.json
+          ls -l dist/manifest.json dist/manifest.json.sig
+
      - name: 生成 Release 说明（支持矩阵模板）
        shell: bash
        env:
@@ -169,7 +209,9 @@ jobs:
          echo "create_mark=(${create_mark[*]:-}) edit_mark=(${edit_mark[*]:-})"
          # Windows 单 exe 装不下 LICENSE/NOTICE/README.md，故三份与产物并列挂 Release（条款随包）；`ull` 是独立资产。
          # manifest.json 是更新清单（D50）：固定文件名，客户端问 `releases/latest/download/manifest.json`。
-          assets=(dist/unlucky-launcher_* dist/ull_* dist/manifest.json dist/SHA256SUMS.txt LICENSE NOTICE README.md)
+          # `manifest.json.sig` 必须与清单一起上传：客户端取清单后取它旁边的签名（`GitHubReleaseSource`
+          # 拼的地址是 `<产物根>/manifest.json.sig`），漏传等于让所有人都验签失败（M190）。
+          assets=(dist/unlucky-launcher_* dist/ull_* dist/manifest.json dist/manifest.json.sig dist/SHA256SUMS.txt LICENSE NOTICE README.md)
          if gh release view "$TAG" >/dev/null 2>&1; then
            # 同 tag 重跑（补丁/重编）：Release 已存在 → 覆盖资产 + 刷新说明，再 `create` 会因已存在而失败。
            gh release upload "$TAG" "${assets[@]}" --clobber
@@ -1,13 +1,18 @@
 name: Release

-# 发布流水线：tag `v*` → **只构建两个 Windows 槽位**（各自原生 `windows-latest` / `windows-11-arm`）→ 单文件产物 +
-#   SHA256SUMS → artifact + GitHub Release。**push tag 默认创建稳定版**（M163：不带 `--prerelease`，否则
-#   `releases/latest` 永远 404、自更新通道取不到清单）；同 tag 重跑幂等（覆盖资产与说明、不 create、不碰标记）。
-# **构建 ≠ 发布**：只有 `PUBLISH_SLOTS` 里的槽位才进 Release 与 SHA256SUMS ——**M142 起只有 `windows-x64`**（arm64 仍留
-#   矩阵里取证、红了不挡 x64 发布）。**M164 的更正**：arm64 那五轮红其实全红在一个误判的编译前体检步（cargo/link 一次
-#   都没跑过，见 `release-build.yml` 顶部），该门禁已拆、判定权交回编译器；但「arm64 能不能出 PE」只能由**下一 tag 的
-#   CI** 证明，故名单仍只列 x64（tower 裁决：不拿 x64 的发布去赌一个没验证过的槽位）。真出包之后把键加回那一行即可。
-#   四档 Linux/macOS 从未验证，默认连构建都不跑（M139：省配额、不留红叉）；整表六槽位取证走
+# 发布流水线：tag `v*` → **默认构建四个槽位**（原生 `windows-latest` / `windows-11-arm` / `ubuntu-22.04` /
+#   `ubuntu-22.04-arm`）→ 单文件产物 + SHA256SUMS → artifact + GitHub Release。**push tag 默认创建稳定版**（M163：不带
+#   `--prerelease`，否则 `releases/latest` 永远 404、自更新通道取不到清单）；同 tag 重跑幂等（覆盖资产与说明、不 create、
+#   不碰标记）。
+# **构建 ≠ 发布**：只有 `PUBLISH_SLOTS` 里的槽位才进 Release 与 SHA256SUMS ——**M184 起是 `windows-x64` + `linux-x64`**。
+#   `linux-x64` 本轮翻牌的依据在 `packaging/docs/linux-evidence.md`：x86_64 槽位在 `ubuntu-22.04`（glibc 2.35，与本地
+#   WSLg 验证同一地板）真编出 release 产物、真开窗渲出一帧，`release-build.yml` 里还有一条同槽位的 xvfb 运行时门禁
+#   ——「声明为 ci 就必须真能跑出帧」，不是「矩阵里写了就算支持」。
+#   **`linux-arm64` 本轮只构建、不发布**：它没有任何运行时证据（没有 ARM64 真机跑过一帧，也没有 arm64 的 xvfb 冒烟）。
+#   解锁条件写在 `packaging/release-notes.md` 与 `packaging/docs/compliance-support-boundaries.md` §9 ——真机跑一帧之后
+#   才把键加进 `PUBLISH_SLOTS`，不拿没跑过的包去发（M184 tower 裁决）。
+#   `windows-arm64` 仍留矩阵里取证、红了不挡 x64 发布（M142/M164：它那五轮红全红在一个误判的编译前体检步，该门禁已拆，
+#   判定权交回编译器）。`macos-*` 两档从未验证，默认连构建都不跑（M139：省配额、不留红叉）；整表六槽位取证走
 #   `gh workflow run release.yml -f all_slots=true`（槽位表在 `plan`）。
 # 名单 ⇄ 产物两个方向都有守卫（M164）：`packaging/check_publish_slots.py`（PR 阶段在 release-guard.yml，发布侧在
 #   release-publish.yml 的 `--dist` 模式）——声明了缺产物 ⇒ 红；有产物没声明 ⇒ `::warning::` 明说未发布。
@@ -31,7 +36,7 @@ on:
  workflow_dispatch:
    inputs:
      all_slots:
-        description: "构建全部六个槽位（含未验证的 Linux/macOS 四档）；默认只跑两个 Windows"
+        description: "构建全部六个槽位（含未验证的 macOS 两档）；默认只跑四个（Windows 两档 + Linux 两档）"
        type: boolean
        default: false
      prerelease:
@@ -58,7 +63,7 @@ jobs:
  # M139：矩阵不写死在 `build` 里，改由本 job 按 `inputs.all_slots` 生成 —— 矩阵不能带 `if`，而 `jobs.<id>.strategy`
  # 可读 `needs`，故用 `fromJSON(needs.plan.outputs.matrix)`。**槽位表只在下面这一处**，改槽位只改这里。
  plan:
-    name: 选槽位（默认两个 Windows）
+    name: 选槽位（默认四个：Windows 两档 + Linux 两档）
    runs-on: ubuntu-latest
    outputs:
      matrix: ${{ steps.pick.outputs.matrix }}
@@ -85,11 +90,18 @@ jobs:
              # 原生还让 `ull --version` 冒烟真跑，dumpbin 走 Hostarm64 分支。
              dict(slot="windows-arm64", os="windows-11-arm", build_dir="target/release",
                   rustflags="-C target-feature=+crt-static", mode="ci"),
-              # ↓ 四档**未验证，不纳入 CI**：从未真构建成功、也没在真机跑过，默认一个都不编；`all_slots=true` 时照编
-              #   （将来验证 Linux/macOS 的唯一入口，别删）。真机验过后：mode 改 "ci" + 键加进 PUBLISH_SLOTS +
-              #   同步 README §1/§9 与 release-notes.md。Linux 固定 22.04 而非 latest：否则 glibc 地板跟着 runner 漂移。
-              dict(slot="linux-x64", os="ubuntu-22.04", build_dir="target/release", rustflags="", mode="probe"),
-              dict(slot="linux-arm64", os="ubuntu-22.04-arm", build_dir="target/release", rustflags="", mode="probe"),
+              # ↓ Linux 两档（M184）：**都改为 `mode: ci`** —— tag 推送默认就编，不再只在 `all_slots=true` 的取证跑里出现。
+              #   Linux 固定 22.04 而非 latest：否则 glibc 地板跟着 runner 漂移（22.04 = glibc 2.35，与本地 WSLg 验证同一地板）。
+              #   两档的差别只在「有没有运行时证据」，而这件事由 `PUBLISH_SLOTS`（发布侧那一行）决定，不在这里：
+              #   `linux-x64` 已真机验过（release 产物在 WSLg 真窗口渲出一帧 + 同槽位的 xvfb 门禁，证据见
+              #   `packaging/docs/linux-evidence.md`）⇒ 进名单；`linux-arm64` 只有构建、**运行时完全未验**（没有 arm64 真机
+              #   跑过一帧）⇒ 不进名单，产物照出 artifact 供取证，靠 `check_publish_slots.py` 打 `::warning::` 明说未发布。
+              #   **别把 arm64 直接加进名单**：解锁条件是真机跑一帧，不是「构建绿了」。
+              dict(slot="linux-x64", os="ubuntu-22.04", build_dir="target/release", rustflags="", mode="ci"),
+              dict(slot="linux-arm64", os="ubuntu-22.04-arm", build_dir="target/release", rustflags="", mode="ci"),
+              # ↓ 两档 macOS **未验证，不纳入 CI**：从未真构建成功、也没在真机跑过，默认一个都不编；`all_slots=true` 时照编
+              #   （将来验证 macOS 的唯一入口，别删）。真机验过后：mode 改 "ci" + 键加进 PUBLISH_SLOTS +
+              #   同步 README §1/§9 与 release-notes.md。
              # macOS：latest = arm64；Intel x64 用 macos-15-intel（macos-13 已下线）。
              dict(slot="macos-arm64", os="macos-latest", build_dir="target/release", rustflags="", mode="probe"),
              dict(slot="macos-x64", os="macos-15-intel", build_dir="target/release", rustflags="", mode="probe"),
@@ -126,8 +138,9 @@ jobs:
  release:
    name: GitHub Release
    needs: build
-    # `always()` + `!cancelled()`：白名单外的槽位（现在的 `windows-arm64`，以及只在 `all_slots` 取证跑里存在的四档）
-    # 红了**不能连坐** x64 发布 —— 真正拦发布的是被调方「发布白名单齐全性」那一步：白名单里少任何一个才 fail。
+    # `always()` + `!cancelled()`：白名单外的槽位（`windows-arm64`、`linux-arm64`，以及只在 `all_slots` 取证跑里
+    # 存在的 macOS 两档）红了**不能连坐**那两档已发布的 —— 真正拦发布的是被调方「发布白名单齐全性」那一步：
+    # 白名单里少任何一个才 fail（M184 之后 `linux-x64` 也在白名单里，它红了就该拦）。
    # tag 门禁留在这里（不在被调方）：分支 ref 的 dispatch 连发布 job 都不该起。
    if: always() && !cancelled() && github.ref_type == 'tag'
    # `contents: write` 必须由**调用方**授予：可复用工作流只能收窄权限、不能提权（交集语义）。
@@ -137,3 +150,6 @@ jobs:
    secrets:
      # 可复用工作流拿不到调用方未显式传入的 secret；`gh release` 用的就是这一枚安装令牌。
      PUBLISH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      # （M190）清单签名私钥：被调方 release-publish.yml 用它签 `manifest.json`。没配时是空串，
+      # 签名步会带着「缺什么、怎么补」的注解当场红（宁可不出 Release，也不出未签名的 Release）。
+      ULL_MANIFEST_SIGNING_KEY: ${{ secrets.ULL_MANIFEST_SIGNING_KEY }}