6 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	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
AskaEth	06fe12d811	chore(release): M154 版本升到 0.2.2（第一个稳定通道版本，D51） ... - 根 Cargo.toml `[workspace.package] version` 0.2.1 → 0.2.2；`crates/{agent,app-iced,cli,palette-extract, presenter}` 里 9 处 intra-workspace path 依赖的 version 约束一并对齐（M137 既定做法）。`crates/app` 是 workspace `exclude` 的 Slint 退役树，manifest 不参与解析，原样保留。 - Cargo.lock 由 cargo 再生成：只有 8 个 `unlucky-*` 成员条目从 0.2.1 变 0.2.2，第三方依赖（含版本号恰好 也是 0.2.1 的 hexf-parse / windows-link / windows-threading / xkeysym / yazi）一字未动。这一步不是可选： CI 与发布流水线全走 `--locked`（ci.yml:236,274 / release-build.yml:135,142 / make_artifacts.py:50）， lock 不跟就是「tag 一打就红」。 - packaging 文档里的**示例 tag** 跟到 v0.2.2：docs/artifacts-and-version.md 两处（命名规则示例 + 「tag 说 X、产物里写 Y」的事故示例）、docs/build-and-ci.md 三处（`--version v…`、两次 `gh workflow run --ref v…`）、 docs/profiles-and-measurements.md 的「同一槽位现在叫 `unlucky-launcher_0.2.2_windows_x64.exe`」、 make_manifest.py 四处（Usage 示例 / `normalize_version` docstring / `--version` 的 argparse help）。 - **历史注记一律不动**：docs/runtime-deps.md 的「v0.2.1 首次真跑即红在工具链体检」（M140 事故记录）、 `.github/workflows/release.yml:71` 同一事故的另一处记录、`crates/core` 更新模块测试里的样本版本串 （`checker_cases.rs` / `version_cases.rs`，是解析器测试夹具，不是发布事实）、`microsoft.rs:224` 的 `21.0.13.0.2.1` 负例。 - README.md / README.zh-CN.md、packaging/release-notes.md 核实后**无需改动**：三份文件里没有任何写死的 版本号——下载表是 `<version>` / `<版本>` 占位符（M153 刚统一的口径，含非发布档位标「暂未发布」的行， 原样保留未回退），release-notes 正文是 `{{VERSION}}` / `{{SUMS}}` 模板占位符。 验证：`cargo check -p unlucky-cli --all-targets --locked` 过（编译日志里 unlucky-core/agent/cli 均报 v0.2.2）、 `cargo test -p unlucky-cli --lib --locked` 42 passed 0 failed、`cargo metadata --locked --offline` 过（全 workspace manifest + lock 一致）、`python3 packaging/make_manifest.py --self-test` ok、 `ull --version` 实跑输出 `ull 0.2.2（unlucky-cli）`。	2026-11-07 08:13:29 +08:00
AskaEth	54b81cbb7f	chore(release): M137 版本升到 0.2.1，发布只发两个 Windows 槽位 ... 版本：`[workspace.package] version` 0.2.0 → 0.2.1，并把全部 intra-workspace path 依赖的 version 约束一并对齐（`"0.2"` → `"0.2.1"`，M121 的教训）。Cargo.lock 里只有 8 个 unlucky-* 成员条目变化。`crates/app` 是 workspace `exclude` 的 Slint 退役树（manifest 连解析都过不了），不参与解析，故原样保留。 release.yml：新增 `PUBLISH_SLOTS` 白名单（唯一开关）＝ `windows-x64 windows-arm64`。 六槽位一律构建取证，release job 先按白名单裁掉 Linux/macOS 四档产物再重算 SHA256SUMS， 所以 tag 触发的 Release 只有 4 个资产 + SHA256SUMS.txt。release job 改成 `always() && !cancelled()`：未验证槽位构建失败不连坐 Windows 发布，真正的门禁是白名单 齐全性检查。将来某槽位真机验过后把它加进那一行即打开。 顺手修掉一处从未生效的门禁：齐全性检查的 glob 用的是连字符形态 （`dist/$prefix-*-$slot*`），对 D49 之后的下划线资产名永远匹配不上，改成 `dist/${prefix}_*_${stem}*`。资产命名规则 / SHA256SUMS / 合规文本并列资产 / `--version` 与 tag 交叉校验一律未动。 packaging/release-notes.md：清掉 v0.1.0 / Slint 时代的说明，Downloads 与 Support matrix 只描述本版实际发布的 Windows 两个槽位（其余标「built by CI, not published」）。 packaging/README.md §1/§3/§9 同步 gate（矩阵加「本版发布」列、§3 写清白名单与打开办法）。 起手顺带把示例 tag 从 v0.2.0 更到 v0.2.1，并把「winit / femtovg」更正为「winit / wgpu」。	2026-11-05 21:30:13 +08:00
AskaEth	bf6b0c4126	build(release): workspace 版本 0.1.0 → 0.2.0，README 的 tag 事实改成 v0.2.0 口径 ... - Cargo.toml [workspace.package] version = 0.2.0；Cargo.lock 由 cargo 重新解出一致 （只有 8 个 unlucky-* 成员条目变动，第三方版本一字未动） - 各 crate 的 `unlucky-*` path 依赖 `version = "0.1"` 同步提到 "0.2"，否则工作区 根本解析不出来（cargo metadata 会报 `failed to select a version for unlucky-core = "^0.1"`）；crates/app 虽被 exclude、cargo 不读，也一并跟上避免将来 重新纳入时立刻解析失败 - core::launch::LauncherConfig 兜底的 launcher_version 改成 env!("CARGO_PKG_VERSION")， 不再是把版本写死一份（CLI / presenter 本来就这么写） - README.md / README.zh-CN.md：删掉「v0.1.0 是目前唯一的 tag / the only tagged release」 这类随 v0.2.0 发布即变假的陈述，改写成「v0.1.0 是最后一个 Slint 版 tag，v0.2.0 是 重写后的第一个 tag」；所有讲 v0.1.0 资产 / Slint Royalty-Free 义务的历史记录原样保留 - packaging/README.md：命名与校验示例跟当前 tag 走（v0.2.0）；§7 实测记录里的 0.1.0 输出加一句「属实测记录、不回填」，并把过期的「四个 workspace member」改成「任何一个」	2026-11-05 14:08:37 +08:00
AskaEth	bc41dfcf7d	Unlucky Launcher v0.0.1-alpha ... Rust 原生单文件 Minecraft 启动器：CLI 完整可用（install/launch/accounts/java/diagnose/agent）， MCP server 接入外部 Agent 工具，GUI 开发中。	2026-10-31 21:54:10 +08:00