AskaEth/Unlucky-Launcher
1
0 Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
586 Commits 3 Branches 5 Tags
bb8be87c8f9c0a9d83a37338acccedf01e42bf27
Commit Graph
14 Commits
Author SHA1 Message Date
AskaEth 50d13d26ab fix(m201): 测试钥改由 #[cfg] 编译期剔除，无测试档产物里不再留那段字节 
`keyring()` 原先用 `cfg!(...)` 判断要不要并入测试钥 —— 那是「运行期值为假的分支」，
`TEST_ONLY` 的字节照编进产物（实测：无 feature 的 dev / release 两档 core rlib 里，
测试公钥十六进制与 key_id 都能 grep 到）。

* `TEST_ONLY` 拆成两条同名 const：`#[cfg(any(test, feature = "update-test-source",
  feature = "update-test-key"))]` 的真条目 + `#[cfg(not(any(...)))]` 的空表；
  `keyring()` 删掉 `cfg!` 判断，改成无条件 `extend_from_slice(TEST_ONLY)`（空表那档等于
  什么都没并，`mut` 两档都有用武之地，不需要 `unused_mut` 口子）。
* 文档把 M199 降级掉的那句强断言改回真话，并贴出六行实测读数（dev / release 均 0 命中，
  带 `--features update-test-key` 的对照臂 2 命中）。
* 明确划界：读数只到 rlib 为止；最终 exe 经 `lto = "fat"` + `strip = "symbols"` 之后是否
  仍有那段字节**未验**。

验收：cargo fmt --all --check → 0；cargo clippy --workspace --all-targets -- -D warnings → 0；
cargo test -p unlucky-presenter → 311 passed / 0 failed（1 ignored）；
cargo test --workspace --all-targets → 0。
 2026-11-09 08:19:04 +08:00
AskaEth 540b82e197 fix(m200-r1): 文档降到实测能撑的程度 + 守门收紧 core 声明内容（复审 P2-1 / P3-1） 
复审 reviewer-presenterfix-r1 的 fix-then-merge 两条，逐条落地。

P2-1(a)「两档」措辞被本次提交自己作废 ⇒ 三处全改成三档：
* `crates/core/src/update/trust.rs` 模块文档（读者最先看到的那句，上次漏了）
* `crates/core/src/update/tests/support_sign.rs` 模块文档 + `TEST_SIGNING_SEED` 的文档

P2-1(b)「三者都进不了发布产物」被复证实测证伪（`cfg!()` 是运行时假分支，不是 `#[cfg]`
编译期剔除；无 feature 的 dev 与 --release 两档 core rlib 里公钥十六进制与 `test-only-key` 都在）
⇒ 降级到事实能撑的断言：「不会被 `keyring()` 并进信任表，正式构建永远不认这把测试钥」，
并明写「字节仍编在产物里」「字节级不在产物里未证、也未声称」「换 `#[cfg]` 是另一条结构性改动」。
没有换成 `#[cfg]`（那是复审建议另开的 mission）。

P3-1 守门对 core「自己的声明」只认形状 ⇒ 收紧为只许空数组：
`DECLARATION` 从 `^\s*update-test-key\s*=\s*\[` 改成 `^\s*update-test-key\s*=\s*\[\s*\]\s*$`，
并加一条自检向量（core 声明里偷偷带子 feature ⇒ 必须红）。`--self-test` 从 6 条变 7 条
（5 红 / 2 绿）+ 基线，`packaging/README.md` 的计数同步。

⚠ 一个自己踩出来的坑，已被既有守门抓住：收紧时我先在 `check_test_key_off.py` 里把那条更宽的
测试通道 feature 写成**字面量**（自检向量 + 文档表格），`check_test_source_off.py` 立刻红
（`packaging/**` 按字面扫，这次提交前它一直是绿的）。改法照该文件自己的声明办——用
`OTHER_FEATURE = "-".join(("update", "test", "source"))` 拼出来，源码里字面量为 0，
自检向量仍然构造出完整字符串并必须判红。

验证（均在最终树上）：`cargo test --workspace --all-targets` 0、`cargo fmt --all --check` 0、
`check_test_key_off.py --self-test` 0（7 向量）/ 正式扫描 0、`check_test_source_off.py` 0、
`check_workflows_yaml.py` 0。
 2026-11-09 07:56:33 +08:00
AskaEth 528f5706a0 docs(m200): 补 update-test-key 的两处文档一致性（cherry-pick 之外） 
`80b291c` 原样落盘（与本提交前一个 commit 逐字节相同），这里只补两处**文档一致性**，
不改任何判据、不改任何 feature 行为：

1. `crates/core/src/update/trust.rs`：`TEST_ONLY` 的文档注释还写着「**只**在 `cfg(test)` 与
   `update-test-source` 构建里存在」——同一文件里 `keyring()` 新增的表已经把三档（`cfg(test)` /
   `update-test-source` / `update-test-key`）讲清了，上面这句变成了自相矛盾的旧口径。改成三档，
   指向 `keyring()` 的说明。
2. `packaging/README.md` §12「文件清单」：新守门 `packaging/check_test_key_off.py` 已接进
   `release-guard.yml`，但清单表里没有它（同类守门 `check_test_source_off.py` 在表里），补一行。

验证：`cargo test --workspace --all-targets` exit 0（311 passed）、`cargo clippy --workspace
--all-targets -- -D warnings` exit 0、`cargo fmt --all --check` exit 0、
`packaging/check_test_key_off.py`（自检 + 正式扫描）exit 0、`packaging/check_workflows_yaml.py`
exit 0。
 2026-11-09 07:56:33 +08:00
AskaEth 19cc5c7950 fix(m190): presenter 更新链路用例补上清单签名（6 条既有测试回绿）+ 测试公钥守门 
背景：M190 把「验签」做成了强制且唯一收口（`source::verified_manifest`，先验签再解析），而
`crates/presenter` 的更新链路用例只写 `manifest.json`、不写 `.sig` —— 它们写在验签之前，所以在
dev 上红成 6 条 `signature_missing`。真发布本来就必须带 `.sig`，所以修的是**夹具**，不是判据：
没有放宽任何断言、没有在测试里关掉验签、没有把 `available=true` 改成「接受 Failed」。

夹具（`crates/presenter/src/host/update_tests.rs`）：
* `write_manifest()` 把清单**连签名**成对落盘（`dist/stable.json` + `dist/stable.json.sig`），
  `dir_source()` 改走它；三处直接写清单的用例（坏清单 / 空清单 / 缺本平台产物）也改走它。
* 签名用 `TEST_SIGNING_SEED` + `key_id = test-only-key`，信封形状与 core 的
  `tests/support_sign.rs` **同源**（文件头写明「改一处要改两处」；presenter 不依赖 core 的
  `#[cfg(test)]` 资产，也没把测试资产导出成生产 API）。

为了让这把**公开**测试公钥在 presenter 的测试构建里被认得：
* core 新增 feature `update-test-key`（**只**把 `trust::TEST_ONLY` 并进信任表，不开任何数据源开关）；
* 只有 `crates/presenter` 的 `[dev-dependencies]` 打开它（库/发布构建拿不到）；锁里只多
  `ed25519-dalek` 这一行（presenter 的 dev-dep，包已在锁里，无新包、无版本变动）；
* 新守门 `packaging/check_test_key_off.py`（238 行，带 6 条变异自检）接进 `release-guard.yml`：
  core 的 `Cargo.toml` 只许自己的声明、presenter 只许 `[dev-dependencies]` 段内，其余（workflow /
  packaging 脚本 / 根 Cargo.toml / cargo 配置）出现即红 —— 这把钥进发布构建就等于「谁都能签出官方更新」。
* 没有用 `debug_assertions`/`cfg(test)` 旁路：那会让「测试构建的信任表和发布构建不同」变成一句注释，
  而不是一条门禁。
 2026-11-09 07:56:32 +08:00
AskaEth a219a21db8 fix(m190): r2 复审——dalek strict 口径照实测写正、补小阶 R 用例、锁里 toml_datetime 退回 1.1.2 
三条 P2 都是「文档/注释与事实不符 + 一条上报事实错了」，代码行为没变。

P2-1 dalek 的 strict vs 非 strict 口径改成正测试出来的样子：
* `VerifyingKey::from_bytes` **不**校验编码规范性（`y = p` 的非规范写法返回 Ok，`is_weak() == true`），
  先前写的「要求规范编码」是错的；
* 非 strict 的 `verify` **也**查 `S` 规范性 —— 先前把它写成「不做可锻检查」是半错；
* 于是这批拒绝类用例里，strict 与非 strict 唯一的分歧是**小阶点**：承重的是
  `small_order_public_key_is_rejected`，其余几条（malleable / non_canonical_r / empty）换掉 strict 后
  **仍然绿**，文件头的表与用例注释都改成这个口径，别让人误以为它们也是守卫。
* 新补 `small_order_r_is_rejected_only_by_strict`：R = 单位元 + S = k·a mod L 的伪造，**两边都断言**
  —— dalek 的非 strict `verify` 接受它、我们的 `verify` 拒绝。这是第二条「只由 strict 拒」的判据。
* `non_canonical_r_encoding_is_rejected` 里那条「非规范公钥编码」原来对两种实现都绿（等于没测），
  现在断言 dalek 的**真实**行为（`from_bytes(...).is_ok()` + `is_weak()`），dalek 升级改口径会红。

P2-2 `packaging/sign_manifest.py` 里指向已删除 `ed25519/{field,group}.rs` 的旧注释删掉（那段还写着
「same formulas」，而两套实现现在是**互相独立**才构成交叉验证）。

P2-3 `Cargo.lock`：`toml_datetime` 从 1.1.3 **退回 1.1.2**（`cargo update -p toml_datetime --precise
1.1.2` 实测可降、`cargo metadata --locked` 自洽）。先前报告里「被 `toml` 拒绝所以无法避免」的理由
**不成立**，已在报告里更正。现在相对 `44a0c87` 的锁变更是**纯新增**：16 个包、零既有版本变动。

变异证明（本轮按要求重跑）：把 `verify_strict` 换成 `verify`（并补 `Verifier` trait 使其可编译）
⇒ `test result: FAILED. 110 passed; 2 failed`，红的两条正是
`small_order_public_key_is_rejected` 与 `small_order_r_is_rejected_only_by_strict`；其余拒绝类用例全绿
（与修正后的口径一致）。恢复后 `112 passed; 0 failed`。
 2026-11-09 02:33:08 +08:00
AskaEth 918d826645 fix(m190): r1 复审——0x01 修成 \1 + YAML 门禁、被调方声明 secret、拆两个超限测试文件、验签换 ed25519-dalek 
四条 P1 + 四条 P2 一并处置（不变的是判据，变的是「谁在承重」）。

P1-1 `.github/workflows/release-build.yml` 的 sed 替换串是裸 0x01（本意 `\1`）：GitHub 解析该文件会
失败 ⇒ 整个 run 起不来；即便容忍，版本号也会被求值成单字节，PE 判据报「与 Cargo.toml 不同源？」把
排障引向错方向。修成字面 `\1`，并新增 `packaging/check_workflows_yaml.py`（真 YAML 解析器 parse
全部 workflow + 裸 C0 控制字符字节判据；带 --self-test 注入 0x01/坏结构断言必红），接进
`release-guard.yml` 两步。文本扫描型守卫看不见这类字节，这道门禁专门挡它。

P1-2 `release-publish.yml` 没在 `on.workflow_call.secrets` 里声明 `ULL_MANIFEST_SIGNING_KEY`，调用方
却传了：可复用工作流只拿得到自己声明过的 secret ⇒ 用户配好钥也会在签名步红，而错误文案反过来指控
Secret 没配。补声明（required: false，fail-closed 由步内 ::error:: + exit 1 承担，同
ULL_MSA_CLIENT_ID 的模式）。

P1-3 两个测试支撑文件越过 400 行守卫：签名夹具拆到 `tests/support_sign.rs`（support.rs 458→392），
CLI e2e 的签名部分拆到 `support/update_e2e_sign.rs`（update_e2e.rs 406→348）。纯搬家。

P2-2 「唯一收口点」改成结构事实：从 `UpdateSource` 删掉 `fetch_manifest` 默认实现，调用方只能拿
`verified_manifest(&source, channel)`（源只交原文，想绕过验签就得自己重写解析与渠道判据）。
P2-3 文档写的第 ④ 条命令补进流水线：`sign_manifest.py --verify-pinned` 用 trust.rs 里钉住的公钥
回验刚落盘的 .sig（不碰私钥），发布侧因此验证的是「客户端的判据」而不是「签名脚本的自我声明」。
P2-4 随自写实现一起删除（`Fe` 的错误 PartialEq 不再存在）。
P2-5 app-iced/build.rs 注释里那个 windows_subsystem 属性本分支不存在（M196 才有），改为说明
「本文件只写版本资源，子系统由 rustc 属性决定，check_pe_version.py 会把 subsystem 打出来」。
P2-6 坏清单不再带 error.path 是有意降级（来源 id 在 message 里），保持。

裁定项：自写 Ed25519 换成 `ed25519-dalek::verify_strict`（信任锚不许自写密码学；此刻信任表还是空表，
零兼容负担）。删除 `update/ed25519/{field,group,mod}.rs`（含只服务它们的单测），新 `update/ed25519.rs`
只剩一个薄封装；拒绝类用例（可锻 S+L / 小阶公钥 / 非规范 R / 空签名 / 未知 key）**一条没删**，
改成钉 dalek 的 strict 语义——实测 dalek 对全部五类的结论与旧实现一致（非规范 R 的拒绝理由不同：
dalek 走「小阶点」而非「编码非规范」，用例注释里写明）。签名侧留在 `packaging/ed25519_ref.py`
（纯 Python、零 pip 依赖），`--self-test` 用 RFC 8032 同一组向量钉两边。
 2026-11-09 02:14:32 +08:00
AskaEth b7d9b99e12 feat(m190): 产物署名（PE VERSIONINFO）+ 清单 Ed25519 多签名与更新前验签 
两件事：让「这是谁发的」在产物与清单上都留下可验证的痕迹。

① PE 版本资源（两个 bin）：`packaging/pe_version.rs` 是唯一口径（CompanyName
   「Unlucky Launcher Project」/ ProductName、FileDescription「Unlucky Launcher」/
   LegalCopyright「© 2026 … · Apache-2.0」/ 四段式版本号与 Cargo.toml 同源），被
   `crates/{cli,app-iced}/build.rs` 各 include 一次；非 windows 目标整段不执行。
   判据是读产物字节的 `packaging/check_pe_version.py`（CI 的 Windows 槽位）。

② 清单签名：`manifest.json` 旁边多一份 `manifest.json.sig`（分离签名，签的是清单**原始
   字节**），信封是 `{format, signatures:[{alg,key_id,sig,manifest_sha256}]}` —— 多签名数组，
   任意一条命中钉住的钥即放行（换钥窗口）。信任锚是 `crates/core/src/update/trust.rs`
   里的编译期公钥表（正式表为空 = fail-closed，测试钥只在 cfg(test)/update-test-source 里）。
   管线顺序改成「先验签、再解析」：`UpdateSource` 只交原文 + `.sig`，`verified_manifest`
   是唯一收口点，`Job::apply` 因此在取包**之前**就拒。新增五类错误分类
   （signature_missing / malformed / unknown_key / keyring_empty / invalid ），全部不可重试，
   CLI 的 hint 单独说人话。

③ Ed25519 验签自带实现（`update/ed25519/*`，零新依赖）：scope 不含 core 的 Cargo.toml，
   用 RFC 8032 §7.1 向量 + 可锻/小阶/非规范编码的拒绝用例钉住；签名侧是
   `packaging/sign_manifest.py`（纯 Python 参考实现，零 pip 依赖，`--self-test` 同向量）。

④ 守门：`release-publish.yml` 加签名步（`set +x`，只回显公钥；没 Secret / 钥没钉 / 签不上
   一律红 ⇒ 不出 Release）；`release-build.yml` 加 PE 资源读回；`release-guard.yml` 跑两个
   脚本的 `--self-test`。密钥纪律与轮换（旧钥签新钥）写在 `packaging/docs/signing.md`。

Cargo.lock：新增 winresource（build-dependency）与 toml 系；toml_datetime 1.1.2→1.1.3 是
toml 1.2.1 的硬要求（`cargo update --precise 1.1.2` 已实测被拒）。
 2026-11-09 01:59:05 +08:00
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 04ac90911e fix(m159): r1 复审返工 —— parse.rs 拆出子模块 + 五条 P3 真问题 
按独立复审 `reviewer-updategui-r1` 的 p1-1 / fix-then-merge 返工。

P1-1（挡门）
- `crates/cli/src/cli/parse.rs` 406 → **382** 行：`fn parse_update` 搬到
  `crates/cli/src/cli/parse/update.rs`（与 `parse/{accounts,agent,instances}.rs` 同形状）。
  全仓 `crates/**/*.rs` 最大仍是 400（`design/tests/card_neutral.rs` 等三处，未越线）。
  上一轮报告里「所有改动文件都在 400 行内」那句是错的，已在 r2 报告里更正。

P3-6 `Job::apply` 不查包形态
- 新增 `self_replaceable(format)`（只有 `PortableExe` 允许）+ `ensure_self_replaceable`，
  **挡在取包之前**；错误分类 `InvalidManifest`（发布侧挂错，换源/重试无用）。
  比复审建议的 `needs_installer()` 更严：`portable-zip`/`appimage` 同样不能原地当 exe。
- 用例：`crates/core/src/update/tests/job_cases.rs`（msi/zip 被拒 + 目标零改动 + 暂存目录
  没被建 + 便携 exe 整环成功 + Nothing 不碰目标 + 闸门的源码锚点）。

P3-7 `ULL_UPDATE_DIR` 生产可用
- `default_source` 改走 `local_dir_override()`：`if !cfg!(debug_assertions) { return None }`，
  发布构建里整段被常量折叠掉（这条路径在 release 二进制里不存在）。判据与三档取舍写在
  `job.rs` 的文档表里（为什么不用 CLI 参数、为什么不用运行期开关）。

P3-1「忽略这个版本」语义
- `UpdateView.dismissed: bool` → `skipped: Option<String>`（记**版本号**）：忽略 0.2.3 之后
  同一次运行里冒出 0.2.4 **照常提示**；手动检查清空（`begin_check(manual)`），静默检查不清。
  文案保持「忽略这个版本」。presenter / app 侧视图模型 / 两处用例同步。

P3-3 CLI `--json` 失败信封缺结构化分类
- `CliError` 加 `detail`（`Option<Box<Value>>`，装箱避免 `result_large_err`）+ `with_detail`，
  `to_json` 输出 `error.detail`；`commands/update.rs` 的 failure 填
  `{"kind": core 分类 id, "retryable": 可重试位}`。
- 上一轮报告里引的 `{"kind":"digest_mismatch"}` 形状确实不存在（那是 CLI 的 user/internal），
  r2 报告换成了实机 dump。

P3-4 update 命令没有解析测试
- `crates/cli/tests/parse_test.rs`：`update_subcommands`（check / apply / `--dest` 两种写法）
  + `update_usage_errors`（无子命令 / 未知子命令 / 多余位置参数 / 缺少取值 / 未知选项）；
  `help_text_covers_every_command` 的 topic 列表补 `"update"`。

P3-5 `install.rs` 模块文档与实测矛盾
- 改成「可以改名、不能覆盖/删除」，写明 M159 在 Windows 真机验过运行中的 exe 自替换，
  并提醒别再照旧文档去设计「退出自身 → 另一个进程搬运」的双进程方案。

顺手（复审 P3-2/P3-8 里低成本的两条）
- 设置页补「下载中」态（`SettingsUpdateApplying` 不再是死 key，下载期间不画「下载并安装」）；
  渠道显示改读 `update.channel`（`stable` 走 key，其它原样）；删掉从未使用的
  `UpdateBannerRestartLater`（catalog + 金表同步，29 条 key 全部有引用）。
- `adopt` 只让**检查**刷新 `checked_at`（应用回报不再冒充「上次检查」）；
  `UpdateView::default()` 的 `current_version` 取本进程版本号（mock 下不再空白）。

门禁（`CARGO_TARGET_DIR=C:/Temp/ull-target/wt-159`）：fmt 绿、clippy -D warnings 绿、
`cargo test --workspace --all-targets --no-fail-fast -j 4` **exit 0**（51 个测试二进制全 ok，
`core::addon::pack` 未被 skip）。该族用例复现了复审记的泄漏：一次全量在 `/tmp` 留 72 个
`ull-pack-*`（`/tmp` 149M → 8853M），跑完已 `rm -rf` 清回 150M。
 2026-11-07 13:03:18 +08:00
AskaEth 1c8f6aa1b3 feat(m159): 自更新 GUI 客户端接线 + CLI update check/apply 同一内核 
D50 的「检查 → 提示 → 可拒绝 → 下载校验 → 下一次启动生效」整环接线，GUI 与
CLI 共用 core 的一条内核（`update::Job`），并顺带修掉 M157 最后一轮复审的三处 P3。

内核（core::update）
- 新增 job.rs：`Job { source, target, staging, dest }` + `check` / `apply`（复查 →
  取包 → 长度/SHA256 双检 → 原子替换），`default_source`（GitHub，`ULL_UPDATE_DIR`
  可切本地目录夹具）、`process_dest`、`staging_dir`。
- `mod.rs` 导出 job 一族；`source.rs` 为 `Box<dyn UpdateSource>` 补 trait 转发
  （壳层要运行期选源，`UpdateChecker` 是泛型的）。

presenter（宿主通道）
- `dto/update.rs`：`UpdateView` / `UpdateOutcome`（Idle/Checking/UpToDate/Available/
  MissingArtifact/Failed 六态，**失败与最新不折叠**）/ `UpdateBanner` 优先级判据。
- `host/update.rs`：Factory（生产 GitHub / 单测本地目录）+ core 结论 → DTO 的唯一映射
  + 更新域偏好（`cache/update/prefs.json`）。
- `host/update_state.rs`：Runtime（会话状态机：begin_check/adopt/begin_apply/dismiss/
  set_auto_check）+ `CoreHost` 派发与后台线程。
- `AppCommand::{CheckUpdate, ApplyUpdate, DismissUpdate, SetUpdateAutoCheck}`、
  `CoreEvent::Update`、`AppState.update`；`refresh_all` 按开关派发静默检查。

app-iced
- 设置页新增第 5 组「更新」（当前版本 / 渠道 / 自动检查开关 / 立即检查 / 上次检查与
  结果 / 下载并安装 / 就位后立即重启），走 `settings::view` 的 `update` 形参 + 按下标
  分发（与 M106 语言行同一取舍）。
- 顶部提示条（每页可见）：有新版本（版本号 + 体积 + 说明摘要，可安装/可忽略）、下载中、
  已就位（立即重启）；静默检查失败**不**弹条（原因进设置页）。
- `pages::Message::Update(UpdateAction)` → `app/update/update_action.rs`；「立即重启」
  拉同参数的新进程后退出（截图通道不重启）。

CLI
- `ull update check` / `ull update apply [--dest <path>]`：复用同一 `Job`；四种结论分开
  报（`--json` 的 `status`），失败退出码 1（`update_check_failed` / `update_apply_failed`）。

i18n
- 新增 `catalog/update.rs`（30 条，链尾追加）+ 金表对应 30 行。

M157 复审 P3 三件
- `app/update/instances.rs` 模块文档改成「清脏的唯一时机是回程快照等于表单」。
- `pages/instances/demo.rs` 的 `demo_form` 注释改成现状（两个参数框早已是单行输入）。
- `pages/instances/launch_args.rs`：门限不满足时只灰 `opengl`/`vulkan`，`default` 仍可点
  （它是「不下发」的安全档）；判据抽成 `backend_chip_enabled` 并补 3 条用例。浅色 + 灰化
  两张图：`C:/Temp/m159-shots/instances-launch-args-{light,gated}.png`。

顺带：harness 支持 `ULL_SETTINGS_GROUP=<下标>`（拍第 5 组的验收图需要它）。

验证：cargo fmt --check 绿；cargo clippy --workspace --all-targets -D warnings 绿；
cargo test --workspace --all-targets 51 个测试二进制全绿（唯一例外：core::addon::pack
一族要造 4 GiB 稀疏文件，本机磁盘 99% 满 ⇒ StorageFull，与本次改动无关）；CLI 用本地
目录夹具跑通「发现 9.9.9 → 下载 → 校验 → 替换运行中的 exe → 备份留旧文件」，并验证
摘要不符时拒绝应用、目标文件零改动、暂存目录零残留。
 2026-11-07 12:09:42 +08:00
AskaEth f001b93942 feat(core): M150 新增 GitHub Releases 更新源（D50） 
D50 定案 GitHub Releases 为唯一更新源，清单地址固定为
`releases/latest/download/manifest.json`。此前 update 模块只有对拍用的
DirSource，这次把真实源补上。

- `update::github::GitHubReleaseSource` 实现 `UpdateSource`：清单从
  `<base>/<owner>/<repo>/releases/latest/download/manifest.json` 取，
  产物按 D49 命名规则（文件名）拼到同一条 latest/download 路径下；清单里
  已写完整 http(s) 地址的原样使用。
- 网络全走 `core::download`，不新造栈：包体交给引擎 `download()`（镜像展开
  → 地区判定 → 健康度排序 → 退避 → 续传 → 原子落盘），清单走引擎的
  `plan()` + 共享 client 逐候选取文本（与 `game::java` 的一锤子 GET 同一手法）。
  两条路径都吃到 mirrors.json 与地区档案里生效的 gh-proxy 前缀。
- 可配置面只有 owner/repo（默认 AskaEth/Unlucky-Launcher）与 base（默认
  https://github.com，测试指向本地假服务）；渠道只有 stable 有清单，
  beta/alpha/nightly 返回 Ok(None)（D50「先只发 stable」），清单 404 也算
  「还没发布」而不是错误。
- `UpdateErrorKind` 新增 `Network`：远端取字节失败（连不上/超时/5xx/候选全挂）
  与本地 IO 分开——前者可重试，后者重试无意义。引擎把逐源失败压成
  AllSourcesFailed，本源从失败摘要里还原「所有源都 404」为 SourceMissing
  （产物没上传不该被报成网络抖动）。
- 校验仍只有一处：包体请求只带 expected_size，长度/摘要双检留在
  `update::verify`（与 DirSource 同口径）。
- 单测 13 条，全程离线（假 HTTP 服务在 127.0.0.1）：固定清单地址、产物 URL
  解析、自定义 base/owner/repo、清单 404/非 JSON/字段非法/渠道不符/5xx 各自
  归到白名单分类、产物下载、产物 404 → SourceMissing、镜像优先下 gh-proxy
  前缀（清单与产物都验）、与 DirSource 同清单同产物选择结果一致。
 2026-11-07 08:06:22 +08:00
AskaEth 2e718af711 feat(core): 新增 update 模块，做与更新源无关的自更新内核 
更新源还没拍板，所以先把与源无关的那半边做掉：语义化版本比较、发布清单模型、
渠道准入、下载校验、原子替换 + 回滚。源抽象成 UpdateSource trait（清单 + 包体两个
方法），core 里没有任何 CDN 常量；内置的 DirSource 吃本地目录或 file://，既是测试
实现也是将来 HTTP 源的对照物。

取舍：
- 版本比较严格按 semver 2.0 §11：数值比（0.9 < 0.10）、预发布 < 同号正式版、
  预发布标识逐段比（alpha < beta < rc 是 ASCII 序的自然结果，不另立阶段权重表）、
  构建元数据不参与排序与相等。
- 渠道准入两道判据：清单自报渠道的阶梯比较 + 版本号里的预发布阶段。清单可能写错，
  版本号不会，所以正式版渠道即使拿到一份自称 stable 的 rc 也不会提示更新。
- 校验两道判据且顺序有意：先比长度（抓截断，不必读全文件）再比摘要（抓内容错），
  长度要求**恰好**相等；失败即删暂存文件。StagedPackage 只能由 stage() 产出，
  于是「未校验的包」在类型上就进不了安装路径。
- 替换跨平台统一成「旧文件改名挪开 → 新文件搬进来 → 失败把备份搬回去」：Windows 上
  覆盖运行中的 exe 不存在，改名是唯一可用动作，而改名也可能被不共享删除的句柄拒绝，
  所以失败必须能回滚。Unix 也照这个顺序跑，避免回滚路径只有 Windows 被真正跑过。
- core 零 UI 依赖不变：只有 serde/serde_json + 复用的 sha1/sha2，无新依赖，
  Cargo.toml 未改；不接 presenter、不接 UI。

单测 62 条（crates/core/src/update/tests/）：版本边界、清单校验、渠道准入、
摘要不符、包体截断（短了/多了）、无权限写目标目录、Windows 占用文件、回滚与备份清理。
 2026-11-06 19:16:15 +08:00