4 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	ef77c67d3c	fix(m171): r2 —— 跨卷守卫不许静默跳过，崩溃现场不删唯一旧副本 ... 按首轮复审 p2-1items 的三条就地修。 P2-1（唯一阻塞项）跨卷守卫在只有一块卷的机器上静默变 ok：探不到第二块卷时 是 `eprintln! + return`，libtest 默认捕获 stdout/stderr，于是默认输出只有 `... ok`，跳过的记录只有 `--nocapture` 才看得见（复审 M3 变异实测）。 按复审给的方案 (b) 把裁决收成一条常跑用例（本仓口径同 `options_shot/feed.rs::not_fed`：跳过必须是响的）： 探到第二块卷 → 绿（真跨卷用例真跑） 探不到 + ULL_XDEV_TEST_WAIVE=1 → 绿（显式、记录在案的降级，打印一行） 探不到 + 没豁免 → 红（默认判红，失败正文给出三条出路） 另有 ULL_XDEV_TEST_REQUIRE=1：声明「必须有」，与豁免同给时以它为准（不许自相矛盾） 裁决是纯函数 `xdev_guard(found, waiver, require)`：逐条用例走同一个入口 （`cross_volume_scene`），没人能靠 `return` 静静跳过；core 与 CLI e2e 两处政策一致 （源头在 `install_xdev_cases`，CLI 侧 `support::cross_volume_waived` 照抄并注明）。 CI 选择：**windows 作业显式声明豁免**（不挂 VHD）。理由：VHD 要多一步 diskpart、 要管盘符、易碎；豁免是一行 env、写在 ci.yml 里可见，且只在探测失败时被咨询—— 将来 runner 真有第二块盘，真跨卷用例照样真跑。ubuntu 侧不豁免：`/tmp` 与 `/dev/shm` 是不同设备（本机 docker debian:bookworm-slim 实测设备号 119 / 158）， 真跨卷守卫在 Linux 上应当是真跑的。ci.yml 不在本 mission 的改动范围，已用 TowerFinding 登记那一行补丁。 P3-1 `update_e2e_test.rs` 里 `install::prune_stale_backups` → `prune_stale_artifacts`。 P3-2 `prune_stale_artifacts(None, dest)` 会删掉崩溃现场唯一幸存的旧 exe：上一次装到 「dest → .ullold-*」之后被杀时，dest 空着、旧字节只剩备份那一份；下次成功安装时 `symlink_metadata(dest)` 失败 ⇒ keep=None ⇒ 连它一起删，用户失去手工恢复的可能 （修前不会删）。改成 keep=None 时**只清 `.ullnew-*`、一个 `.ullold-*` 都不动**， 模块文档补上这条例外与其来由。 验证（本机，CARGO_TARGET_DIR=C:/Temp/ull-target/wt-171）： * `cargo test -p unlucky-core --lib update::tests` → 90 passed / 0 failed * `cargo test -p unlucky-core` → 623 passed（+ 各集成目标全绿），exit 0 * `cargo clippy -p unlucky-core --all-targets` / `-p unlucky-cli --all-targets --features update-test-source` → exit 0 * `cargo test -p unlucky-cli --features update-test-source --test update_e2e_test --test update_e2e_tamper_test` → 3 + 4 passed，含 `installs_across_volumes_from_the_cli` * fmt clean 变异实测（都验完再还原）： M3 让 probe 恒 None ⇒ 默认 `cargo test` 输出 2 failed（无须 --nocapture）， 正文「没有第二块可写卷，也没有显式豁免：跨卷守卫在这台机器上是空跑。」 M3 + WAIVE=1 ⇒ 3 passed；M3 + REQUIRE=1 ⇒ 2 failed 去掉 keep.is_some() 那一半 ⇒ `a_crashed_install_keeps_the_only_surviving_old_copy` 红	2026-11-08 13:34:29 +08:00
AskaEth	36ff193609	fix(m171): 跨卷替换改成「目标同目录中转名 + 同卷原子改名」 ... 已发布版本上的真 bug：暂存包在 <数据根>/cache/update/staging，目标 exe 在安装目录， 两者不同卷（便携版放 U 盘 / 数据根在 D 盘而程序在 C 盘 / 部分 macOS 配置）时 `rename(staged → dest)` 直接报 EXDEV / ERROR_NOT_SAME_DEVICE（io::ErrorKind::CrossesDevices）， 更新必然失败，而 is_transient 不含 CrossesDevices，也没有任何降级路径。 复现（本机真跨卷：C:/Temp NVMe ↔ D:/Temp 机械盘，原实现）： InstallFailure { error: UpdateError { kind: Io, message: "系统无法将文件移到不同的磁盘驱动器。 (os error 17)", path: Some("D:/Temp\ull-xdev-…\app\ull.exe") }, rolled_back: true } 失败点就是 `rename(暂存包 → dest)`；唯一调用方是 core::update::job::Job::apply（CLI/GUI 共用）。 修法（不把原子替换退化成可能留半截的复制）： 0. 新包 → <目标同目录>/.<文件名>.ullnew-<pid>-<seq> 同卷 rename；跨卷才 copy 到该中转名， 并核对写出字节数（少了直接判失败） 1. dest → <同目录 .ullold-…> 旧版本先安全落地 2. rename(中转名 → dest) 同卷，原子 3a. 成功 → InstallReceipt；3b. 失败 → 回滚 + 清中转名 目标路径上的新字节只来自一次原子命名，任何时刻都不是半截文件；同卷路径一个字节都不多搬 （注入用例断言 copies == 0，rename 恰好 3 次）。 备份清理策略一并定死：成功后只留最近一份 .ullold-*（更早的与残留的 .ullnew-* 删掉， 别的程序名的备份不碰）。旧行为是每次 apply 留一份、全仓无人调 remove_backup ⇒ 无限堆积。 顺手把文件动作抽成 replace_io::ReplaceFs（真实现 = std::fs），让「跨卷被拒」「复制到一半 失败」「改名失败」成为确定性输入；判据与顺序仍在 install 里，注入改不了。 守卫（都做过变异实测，均能变红）： * install_xdev_cases：真跨卷安装成功且目标字节完整（去掉降级 → 红，报 os error 17） * install_io_cases：跨卷降级只复制一次 / 半截复制后目标仍是旧字节且无 .ullnew- 残留 / 短复制被字节数判据拒掉 / 最后一步改名失败回滚并清中转名 / 同卷 copies == 0 * cli update_e2e_test::installs_across_volumes_from_the_cli：数据根一卷、安装目录另一卷， 整环从 CLI 入口跑通（去掉降级 → 红，输出 update_apply_failed + os error 17）	2026-11-08 13:06:57 +08:00
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	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