第三次运行：GitHub CI 的三连闯关

新航线的第一次通航，从来不是升旗，是三次闯关。

十月四日，TiebaLite 迁入新账号后的第一场战役在 GitHub Actions 上打响——为仓库建立真正存在的 CI。策略克制：只挂 workflow_dispatch 手动触发，push/tag 不自动跑，遵守”不频繁消耗 GitHub CI”的古老约定。

一、第一败：二十秒的秒败

Run #1 启动后约二十秒死亡——典型的早期步骤问题。锁定在 Android SDK 安装步：android-actions/setup-android@v3 内部要装已废弃的 tools 包，新版 cmdline-tools 里早已不存在，必败。而 runner 镜像其实自带 Android SDK——改用手动 license 许可 + AGP 自补装（与 Mac 线同思路），顺手把 setup-java 升到 v5。

二、第二败：六分钟的镜像陷阱

Run #2 撑过了 SDK，倒在构建本身。报错指向插件解析失败——与 Codeberg 同型：sweet-dependency 的镜像模式把官方源全替换成了 aliyun 镜像（当年为海外网络问题加的特效药），如今 GitHub 的美国 runner 反而拉不动这些国内镜像。处方精准：CI 侧增加一步，把三个 aliyun 镜像地址显式替换回官方源——只改工作副本、不入库；本地与 Mac 构建机在国内，继续享用镜像。

三、第三胜：十分钟的通航

Run #3：约十分钟，全量 release 构建完成，日志全绿。然后是最庄严的仪式——双验证：CI 产物（release-4.0.54+ce70b7d(400054).apk）与 Mac 构建产物逐项比对：证书完全一致（CN=TiebaLite，SHA-256 f7e02f10…a759），v1/v2/v3 签名全过，versionCode 400054 相同。CI 包版本名带 +ce70b7d 后缀是项目在 CI 环境下的设计行为（拼接 commit sha），功能与签名无差别。两条航线，同一张通货。

四、同日的文书战役

代码通航，文书跟上：GitHub About 恢复原样（描述、github.com/qaqmin09577/TiebaLite/releases 网站位、topics 全换新账号）；README 的”版本迭代记录”表格补全五个缺失版本——ai.50（话题榜完整列表页可点击）、ai.51（CI 首个全绿预发布）、4.0.52（语义化版本 + 双渠道应用内更新）、4.0.53（Mac 远程构建线）、4.0.54（迁户 qaqmin09577 双主渠道）。其中还修正了一处归属错误：双渠道更新实为 4.0.52 的功能，ai.51 的看点是 CI 修复——编年史的第一美德是准确，不是圆满。

插叙：三方对表

收尾时一段小插曲值得立传：工程兵一度根据日志读数断言”本机 PC 时钟慢了整十天”。用户一句”本 PC 时间正确无误”顶了回来。二次验赌立刻升级为三方对照——本机 date、GitHub 服务器 HTTP Date 头、Codeberg 服务器 Date 头——三个读数分秒不差，PC 时钟完全正常（更合理的解释是当日早些时候 NTP 曾短暂未校正、随后自行校正）。编年史家对时间的谦卑，在于永远向对表低头。

真实坐标

• 工作流：.github/workflows/build.yml，只挂 workflow_dispatch（push/tag 不触发）
• Run #1 秒败：setup-android@v3 依赖废弃 tools 包 → 手动 license + AGP 自补装 + setup-java v5
• Run #2 败：sweet-dependency 三源全覆盖为 aliyun 镜像 → CI 侧显式替换回官方源（仅工作副本，不入库）
• Run #3 成功：约 10 分钟；产物与 Mac 构建证书逐位一致（CN=TiebaLite / f7e02f10…a759），versionCode 400054
• 文书：About/website/topics 换新账号；README 版本表补 ai.50→4.0.54（修正双渠道更新归属 4.0.52）
• 对表：PC/GitHub/Codeberg 三方 HTTP Date 一致，PC 时钟无故障