Merge branch 'feat/releasename-explicit-run-name-for-releas'

.github/workflows/release-guard.yml

@@ -1,5 +1,12 @@
 name: Release guard
 
+# （M268）显式 `run-name`：本文件**不是**可复用工作流（`on:` 是 push main / pull_request / workflow_dispatch），
+#   每次都在 Actions 列表里单独占一行，所以同样吃「运行名 = 提交信息」这条默认行为——v0.2.4 的发布提交推到 main 时，
+#   那段「孤儿提交 / 无父 / 树 = dev …」在这里也会再泄漏一次。PR 事件的 `github.ref_name` 是 `<PR 号>/merge`，
+#   贴出来不人读，故按事件分两支：PR 用 `github.event.pull_request.number`（`github` 上下文，run-name 可用且必有值），
+#   其余（push main / dispatch）用 `ref_name`（`refs/heads/main` ⇒ `main`，非空）。**`name:` 一字未动。**
+run-name: "${{ github.event_name == 'pull_request' && format('Release guard · PR #{0}', github.event.pull_request.number) || format('Release guard · {0}', github.ref_name) }}"
+
 # 发布标记语义守门（M163）：**push tag 默认创建稳定版**这条不许只靠注释保证。
 #
 # 判据全部在 `packaging/check_release_semantics.py`，它做四件事：

.github/workflows/release-publish.yml

@@ -1,5 +1,10 @@
 name: Release / publish（可复用）
 
+# （M268）**故意不加 `run-name`**：本文件只有 `on.workflow_call`，由 `release.yml` 的 `release` job `uses:` 调用。
+#   可复用工作流**不产生自己的 run**——它的 job 挂在调用方那一次 run 里（Actions 列表里只有 `release.yml` 那一行，
+#   运行名由 `release.yml` 的 `run-name` 决定），所以这里写 run-name 是死代码，写了也不会显示。同理没有 `name:`
+#   改动。真正需要 run-name 的另一处是 `release-guard.yml`（那是独立触发的，会单独占一行）。
+#
 # Release 流水线的**发布侧**（M145 拆分：`release.yml` 顶到 400 行红线）。本文件 = 拆分前 `release.yml` 的 `release`
 # job **逐字搬家**：裁剪白名单外的槽位产物、重算全量 `SHA256SUMS.txt`、渲染 `packaging/release-notes.md` 模板、
 # `gh release create/edit` 的同 tag 幂等，全部照旧。留在调用方 `release.yml` 的只有三件事：`needs: build`、

.github/workflows/release.yml

@@ -1,5 +1,16 @@
 name: Release
 
+# （M268）显式 `run-name`：**不写这一行，GitHub 就把提交信息当运行名**贴到 Actions 列表上——公开界面曾经出现
+#   「release: v0.2.4 里程碑快照（孤儿提交，无父；树 = dev 68362e5）」，把 D41 快照模型的实现术语泄漏给所有人。
+#   取值面已核（文档：`run-name` 可用 `github` / `inputs` / `vars`，无特殊函数限制）：
+#     push tag `v0.2.4`   ⇒ `github.ref = refs/tags/v0.2.4` / `ref_type = tag`    ⇒ `Release v0.2.4`
+#     dispatch 在 tag ref 上 ⇒ 同上（`gh workflow run release.yml --ref v0.2.4`）⇒ `Release v0.2.4`
+#     dispatch 在分支 ref 上 ⇒ `github.ref_name = main` / `ref_type = branch`   ⇒ `Release 试跑 main（分支 ref，不发布）`
+#   两种 ref 面上 `ref_name` 都非空（`ref` 一定存在），故不需要兜底分支。分支 ref 单独成一种写法是因为它被
+#   `release` job 的 `if: github.ref_type == 'tag'` 挡在发布之外——一律写 `Release main` 会让人以为 main 上发了版。
+#   **只新增 run-name，`name:`（工作流标识符）一字未动**：改名会断掉历史 run 与分支保护/规则的匹配。
+run-name: "${{ github.ref_type == 'tag' && format('Release {0}', github.ref_name) || format('Release 试跑 {0}（分支 ref，不发布）', github.ref_name) }}"
+
 # 发布流水线：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、

packaging/README.md

@@ -13,7 +13,7 @@
 | 节 | 主题 | 承载文件 |
 |----|------|---------|
 | §1 | 产物矩阵 | `packaging/docs/artifacts-and-version.md` |
-| §2 | 版本来源（唯一真相源） | `packaging/docs/artifacts-and-version.md` |
+| §2 | 版本来源（唯一真相源）；§2.1 里程碑快照**提交信息**怎么写（M268） | `packaging/docs/artifacts-and-version.md` |
 | §3 | 怎么构建（本地 / CI） | `packaging/docs/build-and-ci.md` |
 | §4 | 每平台运行时依赖 | `packaging/docs/runtime-deps.md` |
 | §5 | 软渲染兜底 | `packaging/docs/runtime-deps.md` |

packaging/docs/artifacts-and-version.md

@@ -51,3 +51,50 @@
 - `ull --version` 必报同一版本（脚本打包前跑一次冒烟 `ull --version` 断言版本串在其中），
   这是 `env!("CARGO_PKG_VERSION")` 的实际输出，不是估算。
 - 发布流程：先改 `Cargo.toml` 版本 + 提交 → `git tag v<ver>` → 推送 tag 触发流水线。
+
+### 2.1 里程碑快照的提交信息该长什么样（M268）
+
+发布提交的信息**会出现在公开界面上**（commit 列表、PR、`git log`，以及——没有 `run-name` 时——Actions 的运行名），
+所以它是对外文案，不是内部工作记录。
+
+默认行为（GitHub 文档原文）：`run-name` 省略或只有空白时，运行名取「事件相关的信息」，push / pull_request 触发的
+run 就是**提交信息原文**（PR 则是 PR 标题）。M268 之前 `.github/workflows/` 里 `run-name` 零命中，于是 v0.2.4 那一条的
+标题直接是提交信息：「release: v0.2.4 里程碑快照（孤儿提交，无父；树 = dev 68362e5）」——D41 快照模型的实现术语
+（无父提交、树取自 dev）泄漏到了任何人点开仓库就能看到的地方。v0.2.1~v0.2.3 那几条看着正常，只是因为那几次的
+提交信息本身干净，不是因为流水线做了什么。
+
+现在的兜底：`release.yml` 与 `release-guard.yml` 都加了显式 `run-name`（`Release v0.2.4` / `Release guard · main`），
+发布相关的 run 名不再由提交信息决定。`release-publish.yml` / `release-build.yml` 是 `workflow_call` 可复用工作流，
+**不产生自己的 run**，所以那里不加（理由写在该文件头部注释里）。**但提交信息本身照样公开可见，规矩照旧要守。**
+
+规矩只有两条：
+
+1. **版本 + 一句话**，例如 `release: v0.2.4`。想交代一句就写对外的话：
+   `release: v0.2.4（首个带 Linux 产物的稳定版）`。
+2. **不许写实现细节**：「孤儿提交」「无父」「树 = dev <hash>」「squash 了哪几个提交」这类快照模型的内部术语一个都不要。
+   过程写进 `DevDocs/` 或 PR 描述，不写提交信息。
+
+正面例子（就这样写）：
+
+```text
+release: v0.2.4
+```
+
+反面例子（真实发生过，就是泄漏到 Actions 列表的那一条）：
+
+```text
+release: v0.2.4 里程碑快照（孤儿提交，无父；树 = dev 68362e5）
+```
+
+问题不在长度，在于这段话讲的是**我们怎么做的快照**（无父提交、树取自 dev 68362e5），跟用户无关，还暴露了内部模型。
+
+**抓得住什么 / 抓不住什么**：
+
+- 抓得住（只有这两条）：加了 `run-name` 的两个工作流——`Release`（= `release.yml`）与 `Release guard`——的运行名不再
+  由提交信息决定，Actions 列表里固定是 `Release v0.2.4` / `Release guard · main` 这类人读名字。下次谁把提交信息写成
+  内部术语，**这两行不会显示它**。（已发生的那条 v0.2.4 不会追溯改名：历史 run 名是快照。）
+- 抓不住（一半）：**同一份提交信息在别的 run 上照样公开**。`ci.yml` / `guards.yml` / `dev-guards.yml` /
+  `gpu-evidence.yml` / `signing-status.yml` 都还是默认行为（没加 `run-name`），所以发布提交推进 `main` 时，那几行仍以
+  提交信息为名。要么给它们也加 `run-name`，要么就别在提交信息里写内部术语——**目前是后者**。
+- 抓不住（另一半）：**提交信息本身**。`git log` / commit 页面 / PR 里那段字照旧公开，`run-name` 管不到；这一层只有本节
+  + review 时人看一眼。没有任何门禁会因此变红——写一个能判「这段话是不是内部术语」的脚本不现实，别指望它存在。