♻️ refactor(ci): 重构为 Prepare 上游 + workflow_run 下游消费者模型

- 新增 prepare.yml：统一检查/安装公共工具并集中 fetch 到共享 bare 仓库
- 统计与发布改为消费成功的 Prepare workflow_run，各自维护 stats/release worktree
- 四个 workflow name 统一为带 emoji 的中文，同步 workflow_run 触发引用
- 系统信息 workflow 保持独立直接触发
- 删除 tests/ 手动验证脚本

WORKFLOW.md

@@ -11,23 +11,34 @@
 
 ```txt
 .gitea/workflows/
-├── changelog_and_release.yml    # CHANGELOG 生成 + Release 创建
-├── update_stats_badge.yaml      # 代码行数的统计
-└── ...                          # 更多 workflow 待添加
+├── prepare.yml                  # 公共工具 + shared bare repository
+├── changelog_and_release.yml    # Prepare 成功后的 Tag 发布消费者
+├── update_stats_badge.yml       # Prepare 成功后的主分支统计消费者
+└── ubuntu_system_info.yml       # 与仓库无关、独立直接触发
 ```
 
 ---
 
 ## 🧱 运行模型
 
-本模板中的 workflow 采用“按职责划分固定 slot”的方案：
+```text
+push / workflow_dispatch
+  ├─ Prepare
+  │    ├─ 检查并按需安装公共工具
+  │    └─ fetch → /data/workspace/<repo>/repository.git
+  │
+  └─ Ubuntu System Information（自身触发条件命中时独立并行）
 
-- 每个会写仓库的 workflow 职责拥有一个固定 slot，slot 本身就是 Git clone 根目录，不额外包含 `repo` 子目录
-- 第一次运行会 clone 仓库，后续运行通过 fetch、`git reset --hard` 和 clean 重置后复用已有 checkout
-- 同一 slot 的任务按 concurrency group 串行执行，不同 slot 之间可以并发运行
-- 任务结束后保留 slot checkout；长期依赖缓存应放在 checkout 之外，避免被清理命令删除
+Prepare completed successfully
+  ├─ main/master → update_stats_badge.yml
+  └─ refs/tags/[0-9]* → changelog_and_release.yml
+```
 
-这个设计适用于仓库和 workflow 职责固定的自托管 CI 服务器，在减少重复 clone 的同时避免多个任务并发修改同一个工作目录。
+`Prepare` 是仓库相关链路中唯一安装公共工具和 fetch 的 workflow。它保存一个 persistent bare repository，但不创建任何消费者 worktree。
+
+统计和发布通过 `workflow_run` 读取上游 `head_sha`；发布还从 Gitea 的 `workflow_run.path`（例如 `prepare.yml@refs/tags/1.2.0`）恢复原始 Tag。两个消费者分别拥有 `worktrees/stats` 和 `worktrees/release`，首次创建时通过 `worktree-admin.lock` 串行修改 Git worktree metadata，每次复用前都执行 detached checkout、hard reset 和 clean。
+
+三个仓库相关 workflow 使用各自的 per-repository concurrency group 且不取消排队运行。统计与发布使用不同 worktree，因此可以并行；系统信息 workflow 不依赖仓库或 Prepare，也可以独立并行。
 
 ---
 
@@ -51,6 +62,8 @@
 
 **触发方式**：
 
+推送数字开头的 Tag 会先触发 `Prepare`。Prepare 成功后，发布 routing job 从 `workflow_run.path` 恢复 Tag，确认 Tag peeled commit 等于 `head_sha`，随后才生成 CHANGELOG 和 Release。
+
 ```bash
 git tag 1.0.0
 git push origin 1.0.0
@@ -62,7 +75,7 @@ git push origin 1.0.0
 
 ---
 
-#### 2. 📊 代码统计徽章工作流 (`update_stats_badge.yaml`)
+#### 2. 📊 代码统计徽章工作流 (`update_stats_badge.yml`)
 
 **功能**：自动统计代码行数并生成 SVG 徽章与统计报告
 
@@ -76,15 +89,17 @@ git push origin 1.0.0
 
 **触发方式**：
 
+主分支 push 或在 `main`/`master` 上手动运行 Prepare 后，统计 workflow 通过成功的 `workflow_run` 启动，并始终从上游 `head_sha` 的 detached checkout 读取源码。
+
 ```bash
 # 推送到主分支时自动触发
 git push origin main
 
 # 手动触发
-# 仓库 → Actions → Update Code Statistics Badge → Run workflow
+# 仓库 → Actions → Prepare → Run workflow
 ```
 
-**配置文件**：[update_stats_badge.yaml](.gitea/workflows/update_stats_badge.yaml)
+**配置文件**：[update_stats_badge.yml](.gitea/workflows/update_stats_badge.yml)
 
 **markdown引用格式**: `![C++](https://你的gitea/用户名/仓库/raw/branch/stats/badges/cpp-lines.svg)`
 
@@ -100,7 +115,13 @@ stats
     └── <language>-lines.svg
 ```
 
-💡 **详细配置**：查看 `update_stats_badge.yaml` 文件顶部的 `env` 区域，包含语言分组、颜色、排除目录等配置
+💡 **详细配置**：查看 `update_stats_badge.yml` 文件顶部的 `env` 区域，包含语言分组、颜色、排除目录等配置
+
+---
+
+#### 3. 🖥️ 系统信息工作流 (`ubuntu_system_info.yml`)
+
+该 workflow 不读取仓库内容，保留自己的 `push` 和 `workflow_dispatch` 触发器；它不使用 `workflow_run`、`repository.git` 或任何消费者 worktree。
 
 ---