Unlucky-Launcher

459 Commits 3 Branches 5 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
worker-updatee2e	24826c1a7c	feat(m169): 更新通道端到端验收 —— 本地源改成编译期 feature，补一条可一键跑的 E2E + CI 守门 §6 欠账：更新链路的 GUI 端从来没验过，而 M167 发现它根本没法在本机验——`ULL_UPDATE_DIR` 只在 `debug_assertions` 下生效，发布产物却是 release；`apply` 又会替换本进程 exe，于是没人敢跑。判据换档（tower 定案 B）：`cfg!(debug_assertions)` → 编译期 cargo feature `update-test-source` （core 定义，cli/presenter/app-iced 链式转发，默认关）。带 feature 的构建里还要两档环境变量（`ULL_UPDATE_DIR` + `ULL_UPDATE_TEST_SOURCE=1`），只给路径什么都不会发生。官方发布二进制里那段分支根本编不进来——README「release builds do not contain that path at all」这句因此继续为真。 - core: `job::default_source` 的本地源分支整段 `#[cfg(feature = "update-test-source")]`；判据抽成纯函数 `test_source_root_from` 并逐条单测（半开一律关、空路径、承认值只认 `1`）； `the_test_channel_is_a_compile_time_opt_in` 在两种构建下各断各的（带 feature ⇒ 换源；不带 ⇒ 环境变量设满也走 GitHub）。 - cli: `update check/apply` 的 `--json` 增加 `test_source` 字段（判据派生自实际用了哪个源，不是回读环境变量），人读输出多一行点名；`help.rs` 的 `ULL_UPDATE_DIR` 说明按新判据重写。 - 验收：`crates/cli/tests/update_e2e_test.rs` + `update_e2e_tamper_test.rs` + 共用夹具 `tests/support/update_e2e.rs`。临时数据根 + 本地源 + 真形状清单（与 `manifest.golden.json` 同字段）+ 真 PE 产物（现场构建的 ull.exe 前 1 MiB，理由写在 `PAYLOAD_LIMIT`）。断言覆盖：发现新版本（source=file:… / test_source=true / size / notes）、下载 → 双检 → 就位（dest 字节、旧字节进备份、暂存无残留）、重复 apply 的幂等终态、篡改 sha256（清单撒谎 / 包体被换）与截断都必须拒绝且不动现有安装、修复后能重装。永远带 `--dest`：不带会真的改名换掉测试二进制。 - 守门：`packaging/check_test_source_off.py`（stdlib-only）扫 `.github/workflows/*`、 `packaging/.py\|*.sh` 与各 `Cargo.toml` 的 `default`，任何一处打开 feature（或 `--all-features`）就红；`--self-test` 注入 5 条真实回归证明每条都会红。CI 挂在 release-guard.yml 两步。验证（本机）：core update 单测 80 绿 / 带 feature 6 绿；E2E debug 6 绿； `cargo test --release --features update-test-source` 6 绿（tower 要求 release 档验收）； `cargo test -p unlucky-cli -p unlucky-presenter` 全绿；守门 self-test + 正式扫描绿（真注入后红）。已知没验：真 GitHub Release 下载、GUI 点击与重启替换（人工）；跨卷替换（另开 finding）。	2026-11-08 11:12:10 +08:00
AskaEth	e858664fca	ci(release): M164 arm64 判定权交回编译器 + 发布名单守卫（不翻牌）根因（拿到的真实证据，不是猜的）：v0.2.2（run 42322062879 / job 128248713926）与 v0.2.3 （run 42429017002 / job 128573547829）两份 check-run 注解逐字一致 —— 失败步骤是第 6 步 `Windows ARM64 工具链体检`，第 7 步 `cargo build` 状态 skipped。也就是说 v0.2.1~v0.2.3 五轮全红都红在一个编译前的启发式探针上，真正的编译器/链接器一次都没说话。该探针的结论还与它自己打印的快照矛盾：`SDK Lib 版本→um 架构: 10.0.22621.0→um:[arm,arm64,x64,x86,]` 明明在，却同时报 `kernel32=缺失`（同一个 `find -path` 模式在本地合成目录树上命中）。runner 实况是 Windows 11 Arm64 + Visual Studio 2026 镜像，`VC.Tools.ARM64` 与 `Windows11SDK.22621/26100` 都装好了，M142 的 `setup.exe modify` 反倒返回非 0。改： - release-build.yml：探针降级为「只取证」——vswhere 组件查询 + 各目录 `.lib` 计数 + arm64 `link.exe` 候选，一条 `::error::` 都不写、永不 exit 1；不再自动补装 VS。红绿只由 cargo/链接/静态 CRT 导入表门禁决定。cargo build 步给 arm64 显式备齐工具链： `rustup target add aarch64-pc-windows-msvc`、`vcvarsall.bat arm64` 取 `LIB`/`INCLUDE`、 vswhere 定位 arm64 `link.exe` 后导出 `CARGO_TARGET_AARCH64_PC_WINDOWS_MSVC_LINKER` （顺序不能反：只给链接器不给 LIB ⇒ LNK1181 kernel32.lib）。 - 新增 packaging/check_publish_slots.py（344 行，零依赖）：名单 ⇄ 产物两个方向。声明了缺 GUI/CLI ⇒ `::error::` + exit 1；有产物没声明 ⇒ `::warning::` 明说未发布（M142 之后这个方向是静默的，裁剪步只 echo 一行 drop:）。另有源码级断言（名单每项必须存在且 mode=ci、运行期名单必须等于文件里那行）与 8 条 `--self-test` 注入回归。 - release-publish.yml：裁剪前插一步跑那个守卫，原来内联的齐全性循环搬进脚本（一套判据一处实现）；重算 SHA256SUMS 的步骤只负责重算。 - release-guard.yml：PR 阶段跑守卫自测 + 源码级断言。 - 文档同步：release.yml / release-publish.yml / release-build.yml 头注释、packaging/README §12、 §1 矩阵、§3 构建与发布、§9 支持矩阵、§7.5 arm64 取证、release-notes.md、README/README.zh-CN 的产物矩阵与说明。口径统一为「arm64 构建取证中、未发布」，不写成已支持。没做的（按 tower 裁决「方案乙」）：`PUBLISH_SLOTS` 本轮不加回 arm64。arm64 从未产出过 PE、本机也证不了，写进名单就等于拿 x64 的发布去赌它（M142 移出名单正是为避免这个事故）。下一 tag 的 CI 真出包后翻一行即可，守卫与 SHA256SUMS 自动跟着扩。验证：workflow YAML 全部可被 PyYAML 解析；所有 `run:` 块过 `bash -n`；探针步在本机（无 VS/SDK）实跑 exit 0 并打出实况注解；守卫 `--self-test` 8 条全绿、正反两个方向都在合成 dist 上实测过； check_release_semantics.py（含 --self-mutation）/ release_marker / make_manifest 自检全绿； cargo metadata 正常。arm64 产物从未被构建过、也从未在真机跑过——本机 `rustc --target aarch64-pc-windows-msvc` 直接撞上没有 MSVC 链接器（git-bash 的 GNU `link` 被当成 link.exe）， `cargo check --workspace --target aarch64-pc-windows-msvc` 也死在 aws-lc-sys 的 cc-rs 阶段（GNU host 上没有该 target 的 C 编译器）。真实结论只能等下一 tag 的 CI。	2026-11-08 08:33:44 +08:00
AskaEth	1d2e84ed61	fix(m163): push tag 默认建稳定版（发布标记语义 + 0.2.3 bump）发布标记：`release.yml` 的 dispatch `prerelease` 默认值 true → false；`release-publish.yml` 的 create 路径不再塞 `--prerelease`（空串 = push tag ⇒ 稳定版），edit 路径行为不变（空串不碰标记）。三种触发各创建什么改由 `packaging/release_marker.py` 一张表定义，流水线 `--emit-bash` 出来两个数组直接用，自己不再写 case——v0.2.2 至今 `releases/latest` 404 的根因就是「push 默认 prerelease」这层叠上「dispatch 默认 true」。守门：新增 `packaging/check_release_semantics.py`（CI 在 `.github/workflows/release-guard.yml`， guards.yml 已 398 行不能再挂 job）：①标记表逐条对（push tag 的 create 不含 --prerelease）； ②把 `--emit-bash` 真灌进 bash 读回两个数组；③publish 的可执行内容里没有 --prerelease 字面量、必须调用 emit-bash、两个数组各喂 create/edit；④release.yml 的 dispatch 默认值 == false（读 YAML 结构）。`--self-mutation` 注入三项真实回归（默认值改回 true / 塞回字面量 / 表里 push 改成预发布），断言每项都红、基线绿。版本：0.2.2 → 0.2.3（workspace `[workspace.package]` + 五处 path 依赖 pin + Cargo.lock）。文档：README 中英两版版本行改 0.2.3，并把本阶段能力补进现有章节（Modrinth 匿名在线内容源、自更新与稳定通道、整合包导入逐文件决策、实例级启动参数），删掉「没有自动更新通道」「导入只有两份全局策略」两条过期说法；`release-notes.md` 写 0.2.3 的真实更新摘要（保留 {{VERSION}} / {{SUMS}}）；`packaging/README.md` 与 `docs/build-and-ci.md` 里「push 默认仍 prerelease」的旧口径全部改掉。	2026-11-07 18:56:01 +08:00

Author

SHA1

Message

Date

worker-updatee2e

24826c1a7c

feat(m169): 更新通道端到端验收 —— 本地源改成编译期 feature，补一条可一键跑的 E2E + CI 守门

§6 欠账：更新链路的 GUI 端从来没验过，而 M167 发现它根本没法在本机验——`ULL_UPDATE_DIR` 只在
`debug_assertions` 下生效，发布产物却是 release；`apply` 又会替换本进程 exe，于是没人敢跑。

判据换档（tower 定案 B）：`cfg!(debug_assertions)` → 编译期 cargo feature `update-test-source`
（core 定义，cli/presenter/app-iced 链式转发，**默认关**）。带 feature 的构建里还要两档环境变量
（`ULL_UPDATE_DIR` + `ULL_UPDATE_TEST_SOURCE=1`），只给路径什么都不会发生。官方发布二进制里那段
分支根本编不进来——README「release builds do not contain that path at all」这句因此继续为真。

- core: `job::default_source` 的本地源分支整段 `#[cfg(feature = "update-test-source")]`；判据抽成
  纯函数 `test_source_root_from` 并逐条单测（半开一律关、空路径、承认值只认 `1`）；
  `the_test_channel_is_a_compile_time_opt_in` 在**两种构建下各断各的**（带 feature ⇒ 换源；
  不带 ⇒ 环境变量设满也走 GitHub）。
- cli: `update check/apply` 的 `--json` 增加 `test_source` 字段（判据派生自实际用了哪个源，不是回读
  环境变量），人读输出多一行点名；`help.rs` 的 `ULL_UPDATE_DIR` 说明按新判据重写。
- 验收：`crates/cli/tests/update_e2e_test.rs` + `update_e2e_tamper_test.rs` + 共用夹具
  `tests/support/update_e2e.rs`。临时数据根 + 本地源 + 真形状清单（与 `manifest.golden.json` 同
  字段）+ 真 PE 产物（现场构建的 ull.exe 前 1 MiB，理由写在 `PAYLOAD_LIMIT`）。断言覆盖：发现
  新版本（source=file:… / test_source=true / size / notes）、下载 → 双检 → 就位（dest 字节、旧字节
  进备份、暂存无残留）、重复 apply 的幂等终态、篡改 sha256（清单撒谎 / 包体被换）与截断都必须
  拒绝且不动现有安装、修复后能重装。**永远带 `--dest`**：不带会真的改名换掉测试二进制。
- 守门：`packaging/check_test_source_off.py`（stdlib-only）扫 `.github/workflows/**`、
  `packaging/*.py|*.sh` 与各 `Cargo.toml` 的 `default`，任何一处打开 feature（或 `--all-features`）
  就红；`--self-test` 注入 5 条真实回归证明每条都会红。CI 挂在 release-guard.yml 两步。

验证（本机）：core update 单测 80 绿 / 带 feature 6 绿；E2E debug 6 绿；
`cargo test --release --features update-test-source` 6 绿（tower 要求 release 档验收）；
`cargo test -p unlucky-cli -p unlucky-presenter` 全绿；守门 self-test + 正式扫描绿（真注入后红）。

已知没验：真 GitHub Release 下载、GUI 点击与重启替换（人工）；跨卷替换（另开 finding）。

2026-11-08 11:12:10 +08:00

AskaEth

e858664fca

ci(release): M164 arm64 判定权交回编译器 + 发布名单守卫（不翻牌）

根因（拿到的真实证据，不是猜的）：v0.2.2（run 42322062879 / job 128248713926）与 v0.2.3
（run 42429017002 / job 128573547829）两份 check-run 注解逐字一致 —— 失败步骤是第 6 步
`Windows ARM64 工具链体检`，第 7 步 `cargo build` 状态 skipped。也就是说 v0.2.1~v0.2.3 五轮
全红都红在一个**编译前的启发式探针**上，真正的编译器/链接器一次都没说话。该探针的结论还与它
自己打印的快照矛盾：`SDK Lib 版本→um 架构: 10.0.22621.0→um:[arm,arm64,x64,x86,]` 明明在，却
同时报 `kernel32=缺失`（同一个 `find -path` 模式在本地合成目录树上命中）。runner 实况是
Windows 11 Arm64 + Visual Studio 2026 镜像，`VC.Tools.ARM64` 与 `Windows11SDK.22621/26100`
都装好了，M142 的 `setup.exe modify` 反倒返回非 0。

改：
- release-build.yml：探针降级为「只取证」——vswhere 组件查询 + 各目录 `.lib` 计数 +
  arm64 `link.exe` 候选，一条 `::error::` 都不写、永不 exit 1；不再自动补装 VS。红绿只由
  cargo/链接/静态 CRT 导入表门禁决定。cargo build 步给 arm64 显式备齐工具链：
  `rustup target add aarch64-pc-windows-msvc`、`vcvarsall.bat arm64` 取 `LIB`/`INCLUDE`、
  vswhere 定位 arm64 `link.exe` 后导出 `CARGO_TARGET_AARCH64_PC_WINDOWS_MSVC_LINKER`
  （顺序不能反：只给链接器不给 LIB ⇒ LNK1181 kernel32.lib）。
- 新增 packaging/check_publish_slots.py（344 行，零依赖）：名单 ⇄ 产物**两个方向**。
  声明了缺 GUI/CLI ⇒ `::error::` + exit 1；有产物没声明 ⇒ `::warning::` 明说未发布（M142 之后
  这个方向是静默的，裁剪步只 echo 一行 drop:）。另有源码级断言（名单每项必须存在且 mode=ci、
  运行期名单必须等于文件里那行）与 8 条 `--self-test` 注入回归。
- release-publish.yml：裁剪前插一步跑那个守卫，原来内联的齐全性循环搬进脚本（一套判据一处实现）；
  重算 SHA256SUMS 的步骤只负责重算。
- release-guard.yml：PR 阶段跑守卫自测 + 源码级断言。
- 文档同步：release.yml / release-publish.yml / release-build.yml 头注释、packaging/README §12、
  §1 矩阵、§3 构建与发布、§9 支持矩阵、§7.5 arm64 取证、release-notes.md、README/README.zh-CN
  的产物矩阵与说明。口径统一为「arm64 构建取证中、未发布」，不写成已支持。

没做的（按 tower 裁决「方案乙」）：`PUBLISH_SLOTS` 本轮**不加回** arm64。arm64 从未产出过 PE、
本机也证不了，写进名单就等于拿 x64 的发布去赌它（M142 移出名单正是为避免这个事故）。下一 tag 的
CI 真出包后翻一行即可，守卫与 SHA256SUMS 自动跟着扩。

验证：workflow YAML 全部可被 PyYAML 解析；所有 `run:` 块过 `bash -n`；探针步在本机（无 VS/SDK）
实跑 exit 0 并打出实况注解；守卫 `--self-test` 8 条全绿、正反两个方向都在合成 dist 上实测过；
check_release_semantics.py（含 --self-mutation）/ release_marker / make_manifest 自检全绿；
cargo metadata 正常。**arm64 产物从未被构建过、也从未在真机跑过**——本机 `rustc --target
aarch64-pc-windows-msvc` 直接撞上没有 MSVC 链接器（git-bash 的 GNU `link` 被当成 link.exe），
`cargo check --workspace --target aarch64-pc-windows-msvc` 也死在 aws-lc-sys 的 cc-rs 阶段
（GNU host 上没有该 target 的 C 编译器）。真实结论只能等下一 tag 的 CI。

2026-11-08 08:33:44 +08:00

AskaEth

1d2e84ed61

fix(m163): push tag 默认建稳定版（发布标记语义 + 0.2.3 bump）

发布标记：`release.yml` 的 dispatch `prerelease` 默认值 true → false；`release-publish.yml`
的 create 路径不再塞 `--prerelease`（空串 = push tag ⇒ 稳定版），edit 路径行为不变（空串不碰
标记）。三种触发各创建什么改由 `packaging/release_marker.py` 一张表定义，流水线
`--emit-bash` 出来两个数组直接用，自己不再写 case——v0.2.2 至今 `releases/latest` 404 的根因
就是「push 默认 prerelease」这层叠上「dispatch 默认 true」。

守门：新增 `packaging/check_release_semantics.py`（CI 在 `.github/workflows/release-guard.yml`，
guards.yml 已 398 行不能再挂 job）：①标记表逐条对（push tag 的 create 不含 --prerelease）；
②把 `--emit-bash` 真灌进 bash 读回两个数组；③publish 的可执行内容里没有 --prerelease 字面量、
必须调用 emit-bash、两个数组各喂 create/edit；④release.yml 的 dispatch 默认值 == false（读
YAML 结构）。`--self-mutation` 注入三项真实回归（默认值改回 true / 塞回字面量 / 表里 push
改成预发布），断言每项都红、基线绿。

版本：0.2.2 → 0.2.3（workspace `[workspace.package]` + 五处 path 依赖 pin + Cargo.lock）。

文档：README 中英两版版本行改 0.2.3，并把本阶段能力补进现有章节（Modrinth 匿名在线内容源、
自更新与稳定通道、整合包导入逐文件决策、实例级启动参数），删掉「没有自动更新通道」「导入只有
两份全局策略」两条过期说法；`release-notes.md` 写 0.2.3 的真实更新摘要（保留 {{VERSION}} /
{{SUMS}}）；`packaging/README.md` 与 `docs/build-and-ci.md` 里「push 默认仍 prerelease」的旧口径
全部改掉。

2026-11-07 18:56:01 +08:00