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
104 Commits
Author SHA1 Message Date
AskaEth a91930e021 test(core): crash_scan 用例改用 slice::from_ref（clippy::cloned_ref_to_slice_refs） 2026-11-09 14:12:23 +08:00
AskaEth 4b30bf07f0 fix(launch): 会话事件流路径只留一个真相源 + crash_found 只认真实证据 + ull launch 也写 launcher.log 
M211（来自 M208 实机 e2e 的 D2/D3/D5）：

- D2「game/ 双写」：log_path 的契约原来有两种说法（字段文档写「相对 game/」，写入侧一直
  写「相对会话根」的 game/<sid>.jsonl），于是两处读取点各自又多 join 一层 game/，
  ull logs / ull diag / GUI 日志页对每个真实会话都报「找不到事件流」。现在解析只走 core 的
  session_index::event_file（CLI 与 presenter 共用），写入侧只走
  session_index::log_path_for。方向选的是「读取侧不再 join」：存量索引里的 log_path 从第一版
  起就是 game/<id>.jsonl，改读取侧能把用户盘上已有的旧会话一起救回来（零迁移、零改写）。
- D2 夹具：cli/tests/support 与 presenter/host/logs_tests 的索引夹具改成生产形状
  （game/<id>.jsonl）。夹具此前自己说了第三种形状，所以这个 bug 在测试里永远看不见——
  修夹具比修路径更重要。
- D3「crash_found 恒为 true」：logs/latest.log 每局都写，不再被当现场文件（只在已经找到
  权威现场时作为补充证据）。崩溃结论改由 crash_scan::has_crash_evidence 判定（权威现场文件
  / 非 0 退出 + 错误行），索引旗标由 SessionWriter::mark_crash 写入；crash_found 事件恢复
  成纯事实记录。
- D5「ull launch 从不写 launcher.log」：现在与 GUI 共用
  launcher_log::record_start / record_end（字段名与顺序只在一个地方定义），写的是同一份
  <data>/logs/launcher.log。

测试：core 新增 session_path_tests（写入形状 = 读取解析结果 = 真落点的往返）、crash_scan 的
干净退出用例、launcher_log 的行格式锁；CLI 新增 a_launch_attempt_writes_the_launcher_log。
 2026-11-09 14:12:23 +08:00
AskaEth d8ca411117 fix(core): bmclapi 库镜像补 /maven；install 进度行改说实话 
D1（high）：mirrors.json 的 bmclapi-libraries 少了 inject，官方
libraries.minecraft.net/<path> 被重写成镜像根 + <path>（BMCLAPI 的 maven 仓库挂在
/maven 下），实测 70/70 个库全 404、全部回落官方源（单请求 EMA 6.3 s）。本轮实测：
guava:32.1.2-jre 无 /maven → 404 / 9 B；带 /maven → 200（2 次 302）/ 3041591 B，
sha1 与官方逐字节一致。补法与 bmclapi-assets-objects 的 /assets 同一机制（inject），
不把 /maven 拼进 to（to 是镜像根）。

守卫两道，抓不同的东西：
- 形态：凡 from 指向 maven 仓库的规则，to+inject 必须以 /maven 结尾（并点名覆盖的
  5 条规则 id，删/改名都会红）；
- 行为：4 个真实官方 maven 根展开后必须逐字等于 /maven/<子路径>。
原有 prefix_rule_preserves_sub_path 的期望值曾把 D1 的 bug 钉成期望，一并改正。
变异（删掉 inject）实测三条同时红，恢复后 mirrors 14 passed。

D11（low）：进度回调只累加「处理到第几个文件」，还打「下载 {done}/{total}」，
重装同版本（全部已就绪）时会连打 3961 行「下载」而一个字节都没下。拆出
install/progress.rs：计数全部来自 FileOutcome.status（Downloaded/Skipped/Failed），
下载数为 0 时人读行不出现「下载」二字（改说「已就绪 d/t（跳过 N 个）」），--json 的
progress 事件补 downloaded/skipped/failed。用例构造 96 个全 Skipped ⇒ 断言每行都不含
「下载」且末行为「已就绪 96/96（跳过 96 个）」；变异（退回旧文本）实测红。

其它镜像表（assets / jar / version_manifest / 索引 / fabric / forge）的 inject 形状
实测一致，另有 liteloader 目标路径 404、quilt maven 无规则两条【不同类】观察，
不在本轮范围，报告里交回 tower。
 2026-11-09 13:57:32 +08:00
AskaEth e3ae71ac37 M207: UA 收成一份带联系方式 + 两处字符串副本（gh_proxy 键、用例注释） 
1) UA 只有一份定义：core 的 `download::http::USER_AGENT`
   （`Unlucky-Launcher/<CARGO_PKG_VERSION> (+仓库 URL)`，不用邮箱）。
   - 引擎侧：`EngineConfig::default().user_agent` 直接取它（config.rs 等量替换，仍是 400 行）
   - 带 header 侧：presenter 不再持有 UA 字面量，`get_with_headers` 发 `engine.config().user_agent`
   M205 复审核实过的缺口：Modrinth 收到的是引擎那份 `UnluckyLauncher/<ver>`（无连字符、无联系方式），
   带联系方式的那份只发给 CurseForge 搜索 —— Modrinth 的 UA 政策在真正会被限流的路径上没被满足。

   断言：core 一条钉形状（版本 == CARGO_PKG_VERSION、联系方式段 == 仓库 URL、不含 `@`）；
   presenter 一条在回环上抓**发出去的字节**（两条路径的 UA 逐字节相同且 == EngineConfig::default()）。

2) `app-iced/.../java/downloads/engine.rs`：`"download.gh_proxy"` 字面量改成 `KEY_GH_PROXY`。

3) `presenter/src/host/addon/http.rs` 的用例注释改成事实（Modrinth 走 core 的 EngineTransport，
   `get` 的无 header 分支生产零调用者），模块说明表格同步。

4) `docs/download-settings.md`：§6.1 / §6.1.1 / §7 按 M201（iced 真控件 + 快照通路）之后的现状重写。
 2026-11-09 13:13:20 +08:00
tower-worker 67a03f9402 M205 r1: 修 config.rs 的假话与「最坏 9」的措辞，UA 说明改成事实 
- download/config.rs: KEY_GH_PROXY 的「本文件没有断言把它与 schema 登记绑起来」是 M205 自己造出来的假话，改成指向 proxy.rs 的新用例（纯文字替换，400 行不变）
- addon/online/download.rs: 断言消息与边界段改说「出厂档 3x3 = 9；retry_limit 调到 N 时是 3xN（上限 10 => 30）」，别再让人把出厂值读成事实上限
- presenter/host/addon/http.rs: 「Modrinth 的请求走 get_via_engine」是错的（实际走 core::addon::online::EngineTransport -> download_bytes，带的是引擎 UA；get_via_engine 今天只有单测在用），改成事实
 2026-11-09 11:20:27 +08:00
tower-worker d4aa3b23f4 M205: gh-proxy 键绑定断言、外层重试预算判据、UA 版本号来源、下载设置文档更正 
- setting/keys/proxy: 新增断言把 KEY_GH_PROXY 常量与 schema 登记绑起来（键名 / Text{max_len:256} / 默认空串）
- addon/online/download: RETRY_ATTEMPTS 与引擎每源次数是两件事（层级相乘、管的失败类型不同），写清判据并用两条编译期断言钉住 3 与 3x3=9 的边界
- presenter/host/addon/http: UA 版本号改为从 CARGO_PKG_VERSION 拼出，补断言钉住版本 == CARGO_PKG_VERSION 且联系方式段不丢
- docs/download-settings: §3.1 四条 CLI 命令都吃设置（update 是自更新路径），§6 补 M11-M13 三条 CLI 变异，§1/§7 里 gh_proxy 已合入的事实
 2026-11-09 11:12:59 +08:00
AskaEth 7995f62908 fix(m203): 给第 4 条吃设置的路径（ull update）补打点，并清掉 KEY_GH_PROXY 的腐化 doc 
复审 r1 P2-1（p2-1items / fix-then-merge）：`ull update` 复用 `install::build_engine` 后成了第 4 条
吃设置的路径，但没有任何用例钉它——把 update 换回裸引擎，四条 download::tests 全绿。按 pack 的完全
同形接缝补上：

- `commands/update.rs` 新增 `pub(crate) fn engine(ctx)`（`job()` 改调它），doc 写明这条路径上并发
  不可观测（自更新只下一个 artifact），随设置变的是每源重试次数与 gh-proxy 前缀；
- `download/tests.rs` 新增 `update_engine_takes_the_concurrency_from_the_setting_store`：
  写 concurrency=4 ⇒ 断言 `config().max_concurrency` 与 `concurrency_probe()` 都是 4。

顺带收掉复审的三条观察：
1. 新增 `the_gh_proxy_setting_reaches_the_candidate_chain`：镜像优先地区档案下，出厂（空串 = 跟随
   内置）确实生成 gh-proxy 候选；手写 `gh_proxy: "off"` 后候选里没有 gh-proxy（读的是 `plan()` 的
   候选链，不是配置值；两段式，避免「本来就没有候选」的白绿）。
2. 测试写侧改用 `ctx.setting_path_for(KEY_CONCURRENCY)`（`ull config set` 用的那个表达式），不再与
   实现读侧的 `launcher_config()` 共用同一个表达式——实现改读别的文件时用例会红而不是一起漂移。
3. `core/download/config.rs` 的 `KEY_GH_PROXY` doc 已腐化（写「暂未登记、M197 才登记、别删这条弱
   断言」，而该键在 main 上就已登记、本文件根本没有针对该常量的断言）：改成事实，并保留「弱在哪」
   ——常量值与 schema 登记没被断言绑在一起，改名只会让宿主侧静默退化成 Builtin。

变异验证（只改实现侧，逐次还原）：
- update::engine 换回裸 `EngineConfig::default()` ⇒ 只有 update 那条红（left 8 / right 4），另五条绿；
- `download::tuning` 不读 `KEY_GH_PROXY`（传 None）⇒ 只有 gh_proxy 那条红（off 档仍有
  `https://gh-proxy.com/...` 候选），另五条绿；
- `gh_proxy_override("")` 返回 Off ⇒ gh_proxy 那条的「出厂该套内置前缀」与回落用例的
  `tuning == default` 同时红（两处都该红）。
 2026-11-09 10:07:41 +08:00
AskaEth b31ca636d1 feat(m203): CLI 三条下载命令改吃 download.* 设置（并发/重试/gh-proxy） 
`ull install` / `ull java` / `ull pack` 此前各自 `DownloadEngine::new(EngineConfig::default(), …)`：
用户在设置里配的 `download.concurrency` / `retry_limit` / `gh_proxy` 一概不生效；M193 把出厂并发
从 64 改成 8 之后，它们还静默跟着降了。现在三处都经 `crates/cli/src/download.rs::engine(ctx)`：

- core：`shared/tuned.rs` 新增 `engine_with_tuning(cache_root, tune)` = `set_tuning` + `engine_for`，
  由 `shared.rs` 重导出；`engine_for` 的签名与行为一字未改（presenter 的两步语义原样保留）。
  放子模块是为了不动 `engine.rs`（那是 400 行零余量），`shared.rs` 仍 398 行。
- CLI：`download::tuning(ctx)` 用 `SettingStore::load(ctx.launcher_config(), launcher_schema())` 读
  三个键（与 `ull config set` 同一份文件），默认值/夹取/回落在 `DownloadTuning::from_settings`；
  键缺失或坏值静默回落出厂值，`engine()` 没有错误通道，安装不会因此中断。
- 顺带：`ull update` 复用 `install::build_engine`，也随之吃到设置。
- 测试：`crates/cli/src/download/tests.rs` 三条命令各一条（读 `config().max_concurrency` 与
  `concurrency_probe()` 的真实值）+ 一条「缺失/越界/负数/类型不对 ⇒ 静默回落出厂值」；
  `shared/tuned.rs` 两条守住「灌调优与取引擎是一步」。变异实测：pack 换回裸 `EngineConfig::default()`
  ⇒ 只有 pack 那条红（left 8 / right 2）。
 2026-11-09 10:07:41 +08:00
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 aae9a233ff fix(m198): JAVAGUARD——首屏自动扫 / 子进程回收 / 参数长度三条守卫 + 设置页正文结构断言 
- 首屏自动扫：删掉 `cfg!(test)` 分叉，生产入口在测试里真跑；新增
  `the_first_hydrate_starts_a_real_scan_by_itself`（删掉那一行、或把实参翻成 `true`
  都红）。顺手删掉恒为假的 `seeded && !live`：截图种子档在上方就 return 了，编译器也
  报 "assigned but never used"。
- proc：`kill()` + `wait()` 收进 `terminate()`（三个分支共用）；用例先用同一条命令
  真跑一次证明子进程起得来（`spawn().ok()?` 的空跑假绿），并新增 Linux/Android 的
  僵尸回收用例（只 kill 不 wait ⇒ `/proc/<pid>` 留成僵尸）。
- java.extra_args：`MAX_JVM_ARGS = 1024` 镜像 schema，`Refusal::JvmTooLong` + 中英
  文案 + JVM 输入框变红；App 级用例断言回执是具名的「太长」而不是通用的「写不进去」。
- 设置页正文：判据①从「数 `stack = stack.push(` 的出现次数」升级成按角色断言
  （唯一来源 section_columns、`push(` 恰一次且实参是循环变量、尾表达式、禁
  extend/chain/once/concat/append），单行折叠变异体现在会红。
 2026-11-09 06:46:29 +08:00
AskaEth 6e80fd3563 merge: origin/dev（1623f68）合入 M197 分支——解 golden/tail.rs 冲突 
基线：合的是 **origin/dev**（`1623f68`）。`origin/main` 是 D41 的孤儿发布快照
（`d616d65` parents 为空），不参与合并。用 merge 而不是 rebase，保住三轮复审 clean 的 tip。

冲突只有一个：`crates/i18n/src/catalog/golden/tail.rs`（热点文件，多条 mission 都往这里加 key）。

解法（不重排别人的行、不改别人的译文）：
1. 以 **dev 侧 398 行**为底稿（含其它 mission 后加的 key）；
2. 把 M197 的 68 行（`SettingsJavaTooNew` … `SettingsJavaReasonInstallRootTooLong`）
   整块插在 `SettingsJavaReasonWriteFailed` 之后、M174 助手域（`SettingsGroupAssistant`）之前
   —— 即 `settings_java_entries` 那段之后，装配链的正确位置；
3. 两侧合起来 463 行会越过 400 行硬线，于是按既有先例把**M174 助手域起的那半截**
   （dev 的 260 行）整段纯搬移到 `golden/tail_ai.rs`：`tail.rs` 211 行 / `tail_ai.rs` 274 行，
   链序 `golden → tail → tail_ai → tail2` 不变，逐字节不删不改；
4. 解冲突时发现 dev 的 golden 行还是 M197 之前的旧文案（`SettingsJavaEmptyBody` /
   `SettingsJavaAddHint` 的反引号、`SettingsJavaNeverScannedBody` 的旧说法），已把这三条的
   金表行同步回域文件里的现行文案（`split_keeps_every_translation` 逐位置比对当场抓出来的）。

顺带（合并导致的越线）：`crates/core/src/download/engine.rs` 两侧各 400 行、合并后 401
（我 +1 行 `kind: err.kind`，dev +1 行），把模块文档里那三行散文重排成两行（一字未删）→ 400 行。
同一次还把这文件里对 `MirrorTable::set_gh_proxy` 的旧描述改成 M193 的现实（那两个函数已被删）。

验证：fmt 0 · check（app-iced+core+i18n all-targets）0 · i18n 36 · engine_mock 8 · app-iced java 45 ·
core lib java 71 · setting 116 · app-iced lib 全量 832；全仓 file-size 守门脚本复制执行 → 超限 0。
 2026-11-09 06:17:54 +08:00
worker-dlmsettings 54dde7f494 fix(m193): 复审 r2——台账三处失效引用、M39 注释逐字还原、schema doc 数字补守卫 
- P2-1：docs 的契约表把 retry_limit 范围从 (1,10) 改成 0–10（0 与 1 都 = 只试一次），
  与 §4 和 keys.rs 对齐；§2 与 §6 的守卫名统一成 the_schema_contract_is_single_sourced
  （原两条已合并），并把变异 M9（去掉 .max(1) ⇒ 红）补进 §6 台账。
- P3-4：keys.rs 的 M39（MCP server）既有注释按 origin/dev 原文逐字还原（含「同一安全策略、
  同一审计日志」）；腾出的 1 行用「去掉 alias use、两处常量改全路径」换，没有压任何既有论证。
  比对：版本史 / D20 / M39 三段与 origin/dev 逐字节相同。
- P3-2：SettingSpec.doc 是 &'static str（concat! 插不进常量），描述里的数字是第三处第二来源，
  现在有守卫 the_key_docs_quote_the_real_limits（改 1~64 → 1~99 ⇒ 红，变异 M10 已跑）。
  §6.1.1 用表登记三处「数字的第二来源」现状。
- P3-1：docs 里那个游离反引号删掉。
 2026-11-09 05:24:12 +08:00
worker-dlmsettings 94f56f9d9c fix(m193): 复审 r1 三条 P2——版本史还原、retry_limit 0 有诚实语义、装配点措辞更正 
- P2-2：keys.rs 的 schema 版本史按原文逐字还原（1.4.0/1.5.0 的键名、1.2.0 的迁移口径、
  旧读新的完整结论），不再用版本文档换行数；腾行改从我自己新加的注释里出。
- P2-1：download.retry_limit 范围恢复 0~10，并把 0 的语义定成「只试一次」（attempts = max(1, 0)）：
  老配置合法、零迁移、ull config get 读到的 0 与引擎真做的事一致（不再回落出厂 3）。
  schema 描述与 presenter/iced 两处 UI 都写清「0 与 1 都 = 只试一次，不代表不下载」。
- P2-3：shared.rs 的「唯一一处装配」更正为「presenter 侧唯一一处」（CLI 还有三处自建），
  docs 加「哪些路径吃这套设置」表，并立 finding（CLI install/java/pack 不读设置、并发 64→8）。
- P3-3：mirrors.rs 的 gh_proxies 注释改成「无生产读者，仅解析留档」。
- P3-4（presenter 侧）：并发/重试描述的出厂值与上限改用常量 format!，不再是第二处字面量。
- 出图重拍（含 0/1 = 只试一次）。
 2026-11-09 05:24:12 +08:00
worker-dlmsettings e8544b19a7 feat(m193): 下载并发/重试/gh-proxy 真接进引擎（schema 与引擎同源常量） 
- download.concurrency / download.retry_limit 以前引擎侧零消费者（恒用
  EngineConfig::default() 的 64，而 schema 说 8）。现在默认值与硬上限收成
  download/config.rs 的常量，schema、EngineConfig::default()、Semaphore 容量
  三处同源；宿主把三个键翻译成 DownloadTuning 后经 shared::set_tuning（按数据根）
  灌进装配点，改了设置下一次取引擎就生效。
- download.gh_proxy 三态（留空=跟随内置默认 / off=关 / 前缀=覆盖）下沉到
  shared::build，所有走共享引擎的下载路径（内容库/版本清单/字体/安装）一致。
- 删掉 MirrorTable::set_gh_proxy 与 default_gh_proxy 两个改了没用的入口。
- 下载设置页把三条假演示值换成说语义的中文行（含三态说明与 1~64 硬上限）。
- 守卫：探针读 Semaphore 真实许可数（不是读配置），每条配变异证明。
- docs/download-settings.md 记下取证表（另四个键仍零消费，已立 finding）。
 2026-11-09 05:24:11 +08:00
AskaEth db5b08b9ab fix(m195): 复审 r1 三项 —— 解压检查点真守卫、presenter 接线测试、取消文案改回真话 
P2-1（解压循环检查点没有真守卫）：那条用例原来的断言（status/target/files/bytes/无残留暂存）
在删掉 `extract_overrides` 的检查点后**依然成立**——提交前检查点⑤会替它停一次，于是几 GB 的包
会一直解到结束而测试全绿。改成数 `ImportStage::Extract` 事件：有检查点 = 1 条、删掉 = 3 条
（两面实测）。模块文档同时如实登记"还没有真守卫"的检查点：②③④⑤、全新导入 commit 的取消
分支、phase.rs 远端下载逐条、complete.rs 补全循环的 break。

P2-2（presenter 的真令牌接线零测试）：新增 `pack/tests/cancel.rs`，直接调 `import::run` 并把
传入的 `Arc<AtomicBool>` **预先置 true**，判据只能是盘上事实（目标目录不存在 + profiles.json
零实例）——"没收到 Report"那种判据两条路都成立，`run` 早退条件里的 `cancel.load()` 会把
"没接线"完全遮住。

P2-3（用户可见文案说反了话）：`PackCancelled` 中英双语从「导入会在后台继续跑完 / Import keeps
running in the background…已经写下的文件会留下」改为「导入已取消 —— 后台已停手并回滚：没有留下
半包，也没有覆盖已有文件」；golden 金表同步；`model/tests.rs` 那条把旧文案钉死的用例改成钉新
语义（必须说清停手+回滚，且**禁止**出现 background）；`model.rs` 的 `cancelled` 字段文档与
`dispatch.rs` 的取消注释同族修正。

验证：`cargo test -p unlucky-core -p unlucky-presenter` 1480 passed / 0 failed；
i18n 31 / 0；app-iced packui 28 / 0；三 crate clippy 零 warning。
 2026-11-09 05:06:53 +08:00
AskaEth 1441a240fe feat(m195): 导入管线取消令牌与原子回滚（取消不是失败） 
M190 复核 §3 A-2：导入管线没有取消令牌，「取消导入」只改界面状态，后台仍跑完并写盘
（半包 / 覆盖风险，丢数据档）。本轮把取消做成管线级：

- core 新增 `import/cancel.rs`：`ImportCancel` 令牌（可 `from_flag` 接管既有
  `Arc<AtomicBool>`）+ 内部 `Stopped::{Cancelled, Failed}` 两条停止路线；
- 结果类型单列 `ImportStatus::Cancelled`（`error` 恒为 None、退出码 130、文案 key 独立），
  与 `Failed` 是两条路——UI 不弹红、脚本不会把「改主意」记成「装坏了」；
- 七个检查点：入口 → 解析后 → 补全后 → 开暂存目录前 → 提交前 → 合并态逐文件 → 登记前；
  解压 / 远端下载各逐条检查；单条下载在飞不可中断（fetcher 无取消参数）已在文档里说准；
- 取消后不留半包 / 不覆盖已有实例：暂存目录整个删、合并态 journal 逆序回滚（备份改回原名）、
  落盘后取消连内容一起回滚；`files / conflicts / missing / bytes_written` 清零，不留假账；
- presenter：同一个取消标记现在真交给 core（`with_cancel`），取消后不再「后台跑完并登记」；
  CLI 增 `cancelled → 130` 一档与三档人读名。

守门三条各带变异证明（见 mission 报告）：删回滚 → 红、删登记前检查 → 红、把取消并进
`fail()` → 红。

没验：超大整合包的真实 IO 下取消响应延迟（最坏 = 当前一条文件读完/下完 + 一次回滚）、
单条下载在飞不可中断、macOS / Linux 未跑。
 2026-11-09 05:06:52 +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
worker-logplace 5fd5cd47dc feat(m188): launcher.log 早落盘 + 会话日志搬到 logs/game（旧家只读兼容） 
用户投诉原话：「我们的启动日志放在哪？…他找半天没找到崩溃日志」「只有一个安装日志」。

启动器运行日志（.ULL/logs/launcher.log）
- presenter 构造 HostEnv 时就登记日志目录：启动早期缓冲的 200 行（[probe]/[font]/[theme]）
  当场刷盘，不再是「只有开过一局游戏才有日志」。
- app/** 里所有 eprintln! 诊断改走 app::diag::diag!（stderr + 文件双写，行首 [tag] 即 scope），
  含 boot/boot::fallback/state/update 各线。
- boot 那一拍补一行后端事实（request/effective/fallback）。
- 滚动上限（1 MiB → launcher.1.log，只留一份）写进 README 与 docs/logs-location.md。

会话日志搬家：data/agent/sessions → logs
- LauncherLayout: sessions_root()/game_logs() 新增，agent_sessions() 降级为只读兼容。
- host/logs 与 cli/commands/sessions 两个根合并（同 id 新根优先），event_path 回落旧家。
- 不搬不删；日志目录写一份 session-log-location.json 记录（moved=0, policy=read-only-compat）。

入口与文案
- 设置页「通用」新增「日志文件夹」行：路径 + 打开目录 + 复制路径（i18n 中英）。
- 日志页页头的「打开目录」不再是占位：走 M187 的 open_dir，失败文本带路径并送进剪贴板。
- README.md / README.zh-CN.md 新增「日志在哪」章节（含 crash-reports 只在游戏走到那一步才有），
  docs/logs-location.md 给出上限、双写判据、迁移策略与没验的部分。

守门（每条都有变异证明，见报告）
- 旧家会话仍列得出/打不开 ⇒ 只读新根变红；新会话写 logs/game ⇒ 只读旧根、写回旧家都变红。
- launcher.log 滚动 ⇒ 干掉 rename 变红。
- 打开日志文件夹指向真实目录 ⇒ 换成 cache/ 或去掉 create_dir_all 都变红。
- 日志根随三模式变化 ⇒ 把 HostEnv::logs_dir 写死成便携落点变红。
 2026-11-09 00:43:45 +08:00
AskaEth 2b6dcbed40 fix(m187): r2 复审 p2——截断过的文件也必须脱敏（截断 改到文本流里做） 
r2 复审挖到的隐私旁路：上一版在**字节**上切两刀，切在多字节字符中间时
String::from_utf8 失败 ⇒ 整份 entry 走「原样字节」分支，家目录 / 用户名 / 令牌原文
按字节进包，而清单什么也不说。命中的正是最容易超过 4 MiB 的 latest.log 与会话 JSONL；
中文 Windows 用户名（C:\Users\张三）让家目录串本身就是 CJK，切点落在附近必然命中。

修法（比复审给的三条更严一点：先脱敏再截断，避免切点留下半截 secret）：
解码（lossy，任何字节都能进脱敏器）→ 脱敏整份 → 按**字符/行边界**截断 → 插截断标记。
新增 crash_bundle/clip.rs（切点逻辑 + 4 条用例），write_bundle 里只剩一条通路，
「二进制原样」这条分支彻底删除。

守卫：truncated_entries_are_still_redacted —— 造一个 '中' 正好跨在 HEAD_BYTES 上的
4 MiB+ 文件，内含注册过的会话 id 与家目录；断言 ①包里找不到原文 ②<home> 在
③尾部 exit 事件仍在。变异（改回字节级截断 + 仅解码成功才脱敏）⇒ 红在「仍带着家目录原文」。

顺带：
- P3-1 启动日志写两遍（WindowHandle(None) 分支重复调 record_boot_log）→ 删掉重复调用。
- P3-2 清单里的截断字节数改成**实际保留量**（原来报的是常量 HEAD_BYTES）。
- P3-4 truncated>0 时界面那句话补用例（拆出 dialog/tests/export.rs，两个文件都 < 400 行）。
- P3-6 BundleSpec::manifest() 自己也过脱敏，去掉「谁调谁泄漏」的口子。
- P3-5 卡片宽度取官方上限 560 的语义在代码里写清（不改行为，登记为台账）。
 2026-11-08 23:57:49 +08:00
AskaEth 3cd371b537 fix(m187): r1 复审——深色遮罩提亮、点遮罩关闭、包内条目名、截断保尾、启动日志接线 
P1（阻断）：遮罩从 Role::OnSurface@32% 换成组件层的不透明预合成
（feedback::dialog::scrim，黑@0.32 叠画布）。深色档此前是「近白@32%」把整窗提亮，
实测 (9,21,28)→(129,138,145)；现在 (6,14,19)（= 组件文档预测值），且两后端逐字节相同。
顺带按纪律改用 Component::Dialog + DialogGeometry（半径 28 / 宽 560 / 内距 24），
两后端弹窗图差异从 66% 降到 2.65%（浅）/ 2.76%（深），余量全是文字抗锯齿。

P2-1：卡片那层的命中区改回卡片本身（opaque 只包卡片）。此前 mouse_area 包的是整窗居中
容器 ⇒ 点卡片外先被 Swallow 捕获，遮罩永远收不到，「点遮罩关闭」只在注释里成立。
守卫：断言卡片层的 size_hint 任一维都不是 Fill。

P2-2：条目名与清单**同源**（BundleSpec::entry_names），会话 JSONL 钉成 session/session.jsonl。
此前条目名用原始文件名（会话 id 原样进包）而 manifest 过了 redactor ⇒ 清单指向的条目不存在。
（上一轮报告把这条写反了，本轮以 unzip -l 实输出为准。）

P2-3：截断改「头 + 尾」（MAX_ENTRY_BYTES 一半一半，中间插 <truncated N bytes>），
并在弹窗补一句「有 N 个文件太大，已截断」。此前只留头部 ⇒ 长会话 JSONL 的 exit 事件丢失。

P2-4：app 启动那一拍（主题/语言/路由/窗口/实例数/msa 行）真的写进 launcher_log；
目录仍由 presenter 在首次启动时登记，所以这些行先进 core 缓冲、登记时一次刷出。

P3-1/P3-2：关闭与 Esc 立即重画（否则空闲 1Hz 下弹窗再留 1 秒）；导出成败按 write_bundle
真实结果判（不再看 launcher_logs 有没有值）。

用例：新增 5 条（深色遮罩方向、卡片层命中区、条目名与清单一致、截断保尾、启动日志落点），
每条都给了变异证明（只改实现侧，均已还原）。
 2026-11-08 23:21:26 +08:00
AskaEth 414f6ff886 feat(m187): 启动失败弹窗 + 诊断包导出，并接通 DialogQueue 
用户实测「MC 启动失败找不到崩溃日志」的直接修法：失败时弹一个框，把退出码、
一句人话原因、证据形态、四条真实路径与三个按钮摆在同一个地方。

- app-iced：最小一层模态（遮罩 + 卡片 + 主/次按钮 + Esc/点遮罩关闭），
  消费 presenter 的 DialogQueue（此前全仓零引用，所有弹窗都画不出来）；
  队列管弹窗，CrashCard 管这次失败的事实，按 DialogId 绑定。
- 弹窗区分两种失败：游戏自己写了 crash-reports（贴 Description + 栈片段）/
  游戏没来得及写（明说「这次没有生成崩溃报告」并贴出捕获的最后 30 行）/
  什么都没抓到（给最可能原因分类）。绝不对第二种说「找不到日志」。
- 导出诊断包：core 侧新 crash_bundle 写 zip（清单 + 启动器日志 + 会话 JSONL +
  crash-reports/* + hs_err + latest.log + 版本 JSON），落盘即脱敏（家目录 / token /
  会话 id），单文件 4 MiB、总量 48 MiB 上限并在清单记截断。
- 启动器自身日志落盘（core::launch::launcher_log → <.ULL>/logs/launcher.log，
  登记目录前先缓冲），补上「双击启动时诊断行直接蒸发」的缺口。
- i18n：25 条中英文案进 catalog/logs.rs + 金表。
- 取证：ULL_DIALOG_FIXTURE=crash-report|no-logs|export 在临时目录造真文件出图，
  wgpu 与 tiny-skia 各一套，见 DevDocs/artifacts/m187/。

未复现 M190 的「owned 文字在 wgpu 下丢字」：同一串中文两条文字路径、两种后端逐字相同
（ab-wgpu.png / ab-tinyskia.png），因此本轮未改任何渲染路径。
 2026-11-08 22:42:00 +08:00
AskaEth 7b79d5c397 chore(m197): 三处拆文件守 400 行硬线（复审 r1 后新增内容把三个文件顶过线） 
- `core/src/setting/keys.rs` 396（原 400 → 我的 +15 到 415）：`download.proxy_mode` /
  `proxy_url` / `gh_proxy` 三键搬进新 `keys/proxy.rs`（`specs()` + 一句「空串 ≠ 关」的守卫），
  主表留一行 `.with_all(proxy::specs())`——与 `font` / `update` 同一种形状。
- `core/tests/download/engine_mock_test.rs` 407 → 364：404 那条用例整条搬进
  `tests/download/engine_mock/not_found.rs`（`#[path]` 子模块，仍是 `engine_mock` 这个 target）。
- `pages/settings/java/downloads/tests.rs` 423 → 313：gh-proxy 两条守卫搬进
  `downloads/tests/gh_proxy.rs`（`#[path = "tests/gh_proxy.rs"]`）。

纯搬移 + 一条新单测（`keys/proxy.rs` 的「空串 = 跟随内置默认，不是关」）；行为不变。
 2026-11-08 21:42:15 +08:00
AskaEth a14b00aced fix(m197): 复审 r1 的 P1 + 三条 P2（描述对齐行为 / 内部编号下屏 / kind 守卫 / gh-proxy 可覆盖） 
P1（阻断）`java.auto_install` 的描述与行为不一致——那句会进 AI 工具的 JSON Schema
`description`，等于让助手对用户说一件实现刻意不做的事：
- `crates/core/src/setting/keys.rs`：改成「缺 Java 时在 Java 页标出推荐版本并可一键安装；
  不会自动下载」，去掉 `（D13 基准 JDK17）`。
- `SettingsJavaAutoInstallHint` 中英两侧各补一句显式否定（「不会自己开始下载 —— 点「安装」
  才会下」/ "Nothing is downloaded on its own — you press Install."），标签从「自动准备」改成
  「缺 JDK 时推荐一档」；金表同步。
- 新增守卫 `the_auto_install_description_says_it_never_downloads_by_itself`（描述必须含
  「不会自动下载」、不含旧说法与内部编号）。

P2-1 内部决策编号印在界面上：`SettingsJavaDownloadBaseline` 的 `Baseline (D13)` /
`基准版本（D13）` → `Recommended baseline` / `推荐基准版本`（金表同步）。另加两条目录级守卫
（`no_user_visible_string_mentions_an_internal_decision_id` /
`no_user_visible_string_carries_markdown_backticks`）；后者顺带清掉 M168 遗留的
`FontCjkStatusHint` 里的 `ui.font_cdn` 反引号——全仓最后一条。

P2-2 `ProgressEvent::SourceFailed.kind` 没有守卫：`engine_mock_test`
- `reports_progress_events_and_errors_when_all_sources_fail` 的解构补 `kind`，断言
  `ServerError`；
- 新增 `a_404_is_classified_as_not_found_and_never_cools_the_source_down`（404 → `NotFound`，
  与「源坏了」分开）。

P2-3 交付任务书那句「（默认值可改）」：新增 `download.gh_proxy`（空 = 跟随内置默认 /
`off` = 关 / 其它 = 覆盖前缀），`engine_with` 是它的真消费者（改 `RegionProfile`，因为
`gh_proxy_candidates` 读的就是档案里的前缀）；Java 页不画 UI（归 M193）。**内置默认值没动**。
schema minor 1.7.0 → 1.8.0（新键必须推 minor），三处硬编码 minor 的用例同步。

另：真下载用例改成 panic 也清理（复审顺带项 7④）；`downloads/refusal.rs` 的「四档」改「五档」。
 2026-11-08 21:35:13 +08:00
AskaEth ce463cc9b5 feat(app-iced): Java 页「下载一个 JDK」+ 三个设置键（M197） 
用户原话：「我们内置了那么多镜像源 甚至用户不能手动选择指定版本下载。」
「自动下载 jdk17 作为基准版本，后续在设置中提供多版本可供用户下载。」

- core：新增 `game::java::catalog`（8/11/17/21/25 五档 × 能承接的发行版 × 「该装哪档」），
  数据全部来自 `JdkVendor::supports` 与 `vendor::order`，不复制第二份真相。
- progress：`SourceFailed` 补一个结构化的 `kind`（在这之前只有中文 `reason`，双语界面
  要么放弃语言、要么放弃「哪个源为什么退避」这条用户可见信息）。
- app-iced：`downloads` 模块真下（后台线程 + `ProgressEmitter` + 快照），三态（选择列表 /
  下载中 / 失败）都能说出「命中的源 / 退避原因 / 试过哪些源」；成功后重扫并（在
  `java.auto_install` 开着且没有默认 JDK 时）把新装的那份设为默认。
- 三个设置键做成可改 UI：`java.installRoot` / `java.vendorPriority` / `java.auto_install`，
  各自带「现在生效什么、从哪一层来」（数据目录模式 / 地区默认序），改完回读落盘值。
- `State::satisfied` 换成带方向的 `Fit`：1.12.2 + Java 21 不再被说成「低于要求」。
- i18n：删掉 `SettingsJavaEmptyBody` / `SettingsJavaAddHint` 的 markdown 反引号；
  `SettingsJavaNeverScannedBody` 改成不与首屏自动扫矛盾的表述。
- 出图三张（选择列表 / 下载中 / 失败）在 DevDocs/artifacts/m197/。

顺带拆文件守 400 行：`golden/tail.rs` 的 M174 段搬到 `golden/tail_ai.rs`，
`pages/settings/java/{context,prefs,prefs_store,downloads,download_view}` 各自成模块。
 2026-11-08 20:49:56 +08:00
AskaEth ff2f229b80 fix(addon): 复审 r2 —— 下载阶段抽出可测边界并补守门 
- 阻塞项：下载循环从 `install::run` 抽到新文件 `addon/downloads.rs`
  （`download_failure()` + `download_stage()`），假下载器就能驱动它；三条用例分别钉
  ①失败→Unreachable+叶子成因、②第 2 个失败不中断且已装不回滚、③解析完就取消一份都不下。
  实测删掉 `record_failure` 那行会红（failures 0 vs 1），把 `cause` 丢掉也会红；
- nit① 补 core 用例：夹具里 `{"version_id":"vid-only","dependency_type":"required"}` ⇒
  `plan.unresolved_required == [UnresolvedRequired{parent:"MIXED001",…}]`，同版本的
  `project_id` required 仍被跟；删掉收集那段即红（left: [] vs 一条）；
- nit② 取消检查加回解析之后（`download_stage` 入口），并用例钉「解析后取消 ⇒ 不下任何文件」；
- nit③ `fail()` 文档写明去重按**请求键**而非规范 id 的边界（先 slug 后 project_id 仍会两条），
  不消掉但不再让人误以为全覆盖；
- `install.rs` 只留解析 + 收口（275 行），模块表登记 `downloads`。
 2026-11-08 20:23:57 +08:00
AskaEth aa33210bb6 fix(addon): 复审 r1 —— 失败去重、null 载荷、完成态进度、顺序守门、下载失败归并 
- P2-1 失败分支不再「直接 continue」：`fail()` 记一条失败（`record_failure` 按
  `requested_as` 去重）并把请求键写进 `alias`，后续同键走现成的 `fold_parents`
  折父边 ⇒ 同一项目只取一次版本、失败只一条、重试名单不重复；
- P2-2 `RawDependency.dependency_type` 改 `Option<String>`：`#[serde(default)]` 兜不住
  `null`，以前一份 `"dependency_type": null` 就让整份 `/version` 报 Malformed、整个项目装不上；
  现在 null/未知一律 `Unknown`（不递归）；
- P2-3 完成态用 `finish()` 把 `files_done` 对齐 `files_total`（曾写死 `1`，装 3 个停在 1/3）；
  解析前 `files_total` 归 0（未知态），不再假装「已知 1 个文件」；
- P2-4 新增 `tests/order.rs`：跨根的层内顺序 + 多根正序/逆序对照，删 `layer.sort_by` 会红；
  另加 `required_project_ids` 自己的排序去重契约用例（`tests/regressions.rs`）；
- P2-5 下载阶段失败记进同一套两档结构（`Unreachable` + 叶子成因）并继续下一个文件：
  已下好的不回滚、失败项进可重试名单、文案保留「已装入 N 个」的上下文；`retry_request`
  自动覆盖它们；
- nit① 在 `plan.rs` 写清「不兼容」为什么落在 DTO 的 `Unsupported`（不是笔误，是缺档）；
  nit② 新增 `DependencyPlan::unresolved_required`（只有版本 id 的必备前置不再静默忽略）；
  nit③ 补「同 mod 另一个版本在目录里仍要下载」的负向用例。
 2026-11-08 20:23:56 +08:00
AskaEth 011d525e8d feat(addon): Modrinth 前置依赖 BFS 解析与两档失败名单 
- model 纳入 `dependencies`（project_id / version_id / file_name + required /
  optional / incompatible / embedded / unknown 五值），只跟 required 递归；
- 新增 `online::dependency`（请求/计划/跳过的形状）与 `online::resolve`
  （BFS：规范项目 id 去重防环、每项目只解一次版本、同层按项目键字典序、
  默认深度 6 且截断写进计划、父子关系进 `required_by`）；
- 失败从类型上分两档：`Incompatible`（所选版本/加载器没有匹配项）与
  `Unreachable`（并保留叶子成因 NotFound/NotConnected/…），`retry_request()`
  只含失败项，解析永不返回 Err（失败是数据，不连坐）；
- 盘上第二道去重：`present_key` 归一化文件名（小写、砍路径、去 `.disabled`），
  命中即跳过下载，但依赖图仍然展开；
- presenter 装入路径改成「解析计划 → 逐个下载」，文案把两档分开写并列出
  「可只重试这 N 个」；`KNOWN_LOADERS` 补 iris/optifine（光影的加载器）；
- 离线夹具覆盖：嵌套两层、环、扇入、深度截断、两档失败、已存在跳过、光影加载器。
 2026-11-08 20:23:55 +08:00
AskaEth a40b3a5940 fix(msa): 浏览器登录按钮在生产路径真的置位 browser_first（复审 r1 收口） 
复审 r1 的 P1-1：「用浏览器登录」这颗按钮在生产二进制里是哑的——`start_browser_login` 用的是
共享的 `MicrosoftAuth::from_env()`（`browser_first=false`），于是 `browser_then_device_login`
里整段预检 / 回退 / 说明编排不执行，按钮静默退化成设备码，任务③（authcode 可选加速路）
实际未交付。

- P1-1：入口改成 `msa_auth(env, MsaEntry::{DeviceCode,Browser})`，浏览器入口走
  `.with_browser_first(true)`。守卫钉两段：①调用点（按 `LoginJob` 分桶记下生产入口实际请求的
  模式，避开同进程并发用例串台）②模式真的落到 `MicrosoftAuth::browser_first`。变异实测：
  把浏览器入口改回 `DeviceCode` ⇒ 该用例红。核心侧另有报文级证据：浏览器优先路必然对
  `/authorize` 发一次预检（`unregistered_redirect_falls_back_to_the_device_code` 断言 GET 计数 == 1）。
- P2-1：`listeners_opened` 改成**绑定现场**计数——`CallbackServer::bind_counting` 在
  `TcpListener::bind` 前 +1，`login_counting` 把 per-login 的 `AtomicUsize` 传下去；
  删掉「进了授权码分支就记 1」的代理指标。复做变异（预检之前偷绑一个监听口）⇒ 3 条
  msalogin 用例红，包括两条 `listeners_opened == 0`。两处 stale 文档（引用不存在的
  `callback::bind_attempts()`）改成引用 `listeners_opened` / `bind_counting`。
- P2-2：预检加整体 deadline（10s，`PREFLIGHT_TIMEOUT`），超时归 `PreflightUnavailable` 并
  回退设备码；新增「接了连接却不出响应」的假服务器单测（200ms deadline 内必须收场）。
  （下载引擎的 HTTP 客户端只设了 connect_timeout，这条兜住「header 之后停住」。）
- P2-3：client_id 守卫加严到三种拼法（`concat!` / 跨行两段 / `format!` 逐段拼），做法是
  「先收字符串字面量再拼」+「连续纯 hex 字面量累计 ≥32 且 ≥2 段」，并跳过注释（否则本模块
  文档里的示例会自指假红）；每条一个自检向量，且不误杀 `session.rs` 的 profile UUID。
- P2-4：页面级断言补中文（`Lang::ZhCn` 走 `Page::build`），并把回退说明的文案出口收敛成
  视图自己的 `login::browser_note_text`（视图与取样共用，不再测试另写一份映射）。
- P2-5：主按钮文案改成「使用 Microsoft 账户登录」/「Sign in with your Microsoft account」，
  下面补一行「浏览器打不开就用这个：它会给一串用户码，在任何设备上输入即可。」。

门禁：`cargo fmt --check`、`cargo clippy --workspace --all-targets -- -D warnings`、
`cargo test --workspace --all-targets`（51 个 test 目标全绿）通过；`client_id.rs` 的判据拆到
`client_id/tests.rs` 守 400 行红线。截图三张（入口 / 设备码 / 回退）已重出。
 2026-11-08 20:23:44 +08:00
AskaEth f82bd395f8 fix(msa): 微软登录默认走设备码，浏览器流降级为可选加速路 
官方产物上点「微软登录」必失败：GUI 只接了授权码流（随机端口回环回调），而 Azure 应用
注册当初是为 device-code 建的，重定向 URI 一项都没登记，于是授权端点当场回
`invalid_request: ... 'redirect_uri' is not valid`，浏览器里只剩一张 AAD 原始错误页，
启动器干等 5 分钟超时。设备码流本身是好的（CLI `accounts add msa` 一直能用）。

- core：新增 `preflight`（回环重定向 URI 注册预检）与 `login`（浏览器优先 + 自动回退设备码）。
  预检拿「即将使用的 redirect_uri」（端口不参与匹配，微软官方文档 *Localhost exceptions*
  原文已引进模块文档）先问一次授权端点；没登记 / 问不出来就地跳过，**一个监听口都不开**。
  预检通过才真绑端口走授权码；授权码失败（超时/被拒/绑不上）自动回退设备码并带上结构化
  原因码；用户取消（`Canceled`）原样上抛，不偷偷换流。设备码是默认，零监听口。
- presenter：`start_login` = 设备码（默认）；`start_browser_login` = 浏览器优先 + 回退，
  回退原因码写进 `DeviceLoginView.browser_note`（原文只进日志）。
- i18n：三条回退文案（含「怎么修：把 http://localhost/auth 加进重定向 URI，端口不参与匹配」）。
- app-iced：登录面板主按钮改成设备码、浏览器降级为次按钮；重登也走设备码；设备码面板与失败
  面板都能画回退说明。倒计时文案改由视图模型持有（借用渲染），顺带修掉中文倒计时整行不显示。
- 守卫（都能变红）：①授权端点回 invalid_request 时确实回退设备码且原因是结构化码；
  ②未登记回环 / 默认设备码路 `listeners_opened == 0`；③回环登记了仍能走授权码（不焊死加速路）；
  ④用户取消不被偷偷换流；⑤client id 仍只能构建期注入（扫 `auth/microsoft/` 源码无 UUID 字面量）。
 2026-11-08 20:23:42 +08:00
AskaEth df331f6a60 feat(m175): Java 设置页接真运行时（扫描 / 手动路径 / 默认 JDK / 内存 / JVM 参数） 
用户实测四条抱怨逐条对应：
- 「没有自动检测本机 Java」：首屏自动扫一次盘（托管根 + JAVA_HOME + PATH + 标准安装位置 +
  注册表），之后由「立即扫描」手动触发；扫描在后台线程里跑，带 done/total 进度与取消
- 「显示 Temurin 21.0.4 不知道是不是硬编码」：演示行与绊线测试一起删掉，列表来自真读盘
- 「没一个能改」：默认内存（MB，512~65536，范围与 schema 同源）与 JVM 参数可真改、真落盘、读回
- 「不能手动指定 Java 路径 / 不能改默认版本」：手动添加走严格校验（真跑 java -version），
  设为默认写 java.selected_path 并给出「为什么选它」（当前实例的版本门槛 + 每行满足与否）

core：java::manual（严格探测 + 厂商识别 + 名单持久化）、java::staged（候选收集 + 带进度与
取消的扫描）、java::proc（带超时且可打断的子进程执行：卡住的 java -version 会被 kill）。
i18n：catalog/settings/java.rs 55 条中英 + 金表按装配顺序插入。

复审 r1（p2-5items）全修：
- P2-1 「设为默认」不再清脏：只写 java.selected_path，内存/JVM 草稿一个字节都不动
- P2-2 错误文案全部走 i18n（三档「写不进去」/「路径太长」/「名单写不进去」各自一个 key），
  不再把 Rust 枚举名当人话
- P2-3 手动名单落盘有正面断言（加一条 → 从盘上新读一份 → 在）
- P2-4 版本号显示到小版本（17.0.13 / 17.0.9 可区分），解析不出来时给原始版本串
- P2-5 每候选 8 秒超时并 kill、取消打断正在跑的探测、扫描槽挂在 State 上、线程活着期间
  不许起第二个（界面显示「正在取消…」）

复审 r2（p2-2items）全修：
- P2-1 空态不再指向不存在的「Java 页」，改成真实存在的 `ull java install 21` 命令行入口
- P2-2 `auto_scan_due` 增加 `!report.cancelled`：取消过一次之后本进程不再自动扫，
  配置文件再变（存内存 / 改主题）也不会把取消无声撤销；手动「立即扫描」不受影响
- 顺带：proc 的 kill+wait 补「子进程真死了」的回归守卫（标记文件从未出现）、
  core 的 Schema 错误改成页面自己的 key（不再把中文 Display 直出给英文界面）、
  默认态 chip 用新的 `Chip::badge`（不再挂一条永远收不到的消息）
 2026-11-08 19:52:04 +08:00
AskaEth 460da9330d fix(m168): 复审 r3 四项 —— 说准 panic 档、给两条修复补守卫、时限算术补洞 
复审 r3（p2-4items / fix-then-merge）四项 + 顺手五条：

1. **P2-1 `catch_unwind` 在发布档是死代码，三处文档说了不成立的话**：
   `Cargo.toml` 的 `[profile.release]` 是 `panic = "abort"`（只有 `fast` 是 `unwind`），发布走
   `--release`。分两半写清楚：①**闸前移仍安全**——release 档 panic 是进程退出，不存在永久停在
   `Downloading`；`dev`/`test`/`fast` 档 `catch_unwind` 真会写 `Failed`；②但「下载失败不崩」在
   panic 这一支上对发布版**是反的**：注册/`load_font` panic ⇒ 启动器整体 abort，不是降级。
   `install.rs::plan_with_offline` 的文档（新增两档对照表）、`worker.rs` 模块文档与 `run` 注释全部
   按这个说法重写，不再用 `catch_unwind` 给「不崩」背书。

2. **P2-2 「启动不发起下载」这条修复没有守卫**：拆出纯函数
   `fonts::resolve_with_faces(setting, faces)`（`resolve_with` 只是 `system_faces()` 的包装），
   新增 `fonts::tests::resolving_fonts_never_starts_a_download`：给一张只有拉丁族的脸表
   （一定判 `NeedsDownload`），断言调用后 `install::status()` **不是** `Downloading`。
   变异（实跑）：把 `install::after_probe(cjk_report.strategy)` 加回 `resolve_with_faces` ⇒
   `求值字体**不许**发起下载（状态从 Unknown 变成了 Downloading { bytes: 17772300 }）`，红。

3. **P2-3 时限算术有洞 + `is_last` 没守卫**：改 `ATTEMPT_DEADLINE=60 s` / `TOTAL_DEADLINE=420 s`
   （原来 120/360 时，第一个候选吃掉 120 s 后最后一个只剩 240 s ⇒ 门槛 72.3 KiB/s，r1 实测
   67 KiB/s 需要 259 s，仍然必失败）。文档按新数值重算成一张表：第一个候选瞬间失败 ⇒ 420 s ⇒
   42.3 KiB/s；爬满 60 s 被切 ⇒ 360 s ⇒ 49.4 KiB/s，两者都低于实测最慢的 67 KiB/s。
   守卫：把同解的旧用例换成 **单候选 + attempt 300 ms / total 5 s**——有 `is_last` 时跑到总时限
   （≈5 s），没有时 300 ms 就切，两种实现可分辨。变异（实跑）：删掉 `is_last` ⇒
   `the_last_candidate_gets_the_whole_remaining_budget` 红在
   `最后一个候选该拿整个剩余预算（≈5 s）…452.6035ms`。

4. **P2-4(b)(c)**：①`install::tests` 里三处判据用例改用 `plan_with_offline(..., false)`，把进程级
   `OFFLINE` 从判据里摘出去（否则同进程里 `headless(screenshot_options())` 会把它置 true 且从不
   还原 ⇒ 结果依赖执行顺序）；②`fonts.rs` 注释改成真实机制——出图 harness 不经
   `App::with_presenter`、压根没有 `set_offline`，它零流量靠的是「`resolve_with` 不触发」。

顺手：①`sha256_mismatch…` 的 doc 改成「两层校验互备，本用例抓的是两层同时拆」（原来说
「拆任意一层就红」是假的）；②`font.rs` 文档「把 90 s 压成 300 ms」→ 60 s/420 s；③`install.rs` 与
`catalog/font_install.rs` 的「≈17 MB」→ 16.9；④`worker::start` 的裸 `thread::spawn` 换成
`Builder::spawn`，起不来就落 `Failed`（发布档 panic = abort，不能让它 panic）；线程体抽成 `run()`。

验证（`CARGO_TARGET_DIR=C:/Temp/ull-target/wt-168`，取退出码、不截断）：
- `cargo test -p unlucky-app-iced --lib` → **688 passed / 0 failed / 2 ignored / exit 0**
- `cargo test -p unlucky-core --all-targets` → **16 个 target / 1189 passed / 0 failed / exit 0**
- `cargo test -p unlucky-i18n` → 31 passed / 0 failed / exit 0
- `cargo clippy -p unlucky-i18n -p unlucky-core -p unlucky-app-iced --all-targets -- -D warnings` → exit 0
- `cargo fmt --all -- --check` 干净；全仓无文件 >400；本轮改动文件最大 378（`app-iced/src/fonts.rs`）
 2026-11-08 14:38:25 +08:00
AskaEth b9009c0e61 fix(m168): 复审 r2 三项 —— 夹具不再空转、启动不再替英文用户下载、时限不再判慢线下不完 
复审 r2（p2-3 / fix-then-merge）三项：

1. **P2-1 爬行服务端是空转的**（`font/tests/support.rs`，从 `tests.rs` 拆出守 400 行）：
   `seen.windows(4).any(|w| w == b"\n\n")` 拿 4 字节窗口比 2 字节切片 ⇒ `PartialEq` 先比长度 ⇒
   恒 false ⇒ 请求头永远读不完、一个字节不发，用例证明的其实只是「连接挂着被掐断」。上一版
   这里是 Python 生成时把 `\r\n` 落成了真实换行字节。现在两处都是转义写法
   （`b"\r\n\r\n"` + 完整 CRLF 响应头），并且**把「夹具真的在说话」变成断言**：
   `serve_trickle()` 返回 `TrickleProof { header, dripped }`，用例断言「真的发过头」「真的挤过
   字节」——否则夹具再坏一次也会绿。拆成两条用例：`a_trickling_candidate_is_cut_by_the_attempt_deadline`
   （[爬行, 正常]，300 ms 切断第一个后第二个成功，0.38 s）与
   `the_total_deadline_cuts_a_single_crawling_candidate`（单候选 + 400 ms 总预算）。
   变异证明：把服务端改成「一个字节都不发」⇒ 两条用例红在「爬行服务端必须真的发出响应头」。

2. **P2-2 启动替英文用户下 17 MiB（真行为 bug）**：
   - `fonts::resolve_with` **不再触发下载**（启动那一拍只报告判据）。唯一的触发点收在
     `fonts::cjk_for`（`ui/lang.rs::log_cjk`），那一拍的 `setting` 与 `LangChoice` 同源
     （ULL_LANG > 配置 > 系统 locale）= 「界面实际用哪种语言」。
   - `plan` 把 `is_downloading()` / `Ready` 的闸提到**所有策略之前**：上一版只在 `NeedsDownload`
     分支里，"下载中 + Unprobeable" 会把状态改回「无法探测」而线程还在飞，下完又翻回「已就绪」。
     当时那条理由（「否则界面停在正在下载」）只对僵死成立 ⇒ worker 现在用 `catch_unwind`
     兜底「任何 panic 都写终态」，闸才敢前移。
   - 出图通道：新增 `install::set_offline(true)`（`App::with_presenter` 在
     `options.screenshot.is_some()` 时调），`plan_with_offline` 在 offline 下永不 `Start`。
     于是 `pages/harness/app.rs` 与 `--screenshot` 都不会在 zh-locale 无字体机器上真下 17 MiB。
   - 被钉住的旧判据（`Unprobeable + Downloading ⇒ Apply`）改成 `Skip` 并写明旧行为为什么是错的；
     新增 `every_strategy_skips_while_a_download_is_in_flight`（四策略打表）与
     `the_screenshot_channel_never_starts_a_download`。

3. **P2-3 90 s 单次上限把「慢但能下完」变永久失败**：改 `ATTEMPT_DEADLINE=120 s` /
   `TOTAL_DEADLINE=360 s`，并且**最后一个候选拿整个剩余总预算**（前 n-1 个仍 `min(单次, 剩余)`）。
   算账写在常量文档里：17 772 300 B / 360 s ≈ 49 KB/s，比 r1 实测最慢那条 IPv6（67~77 KB/s）
   还低一档 ⇒ 慢而能下完的线路仍有一次成功机会；健康线路（1.1~16.6 s）在第一/第二个候选就结束。
   代价（最坏 6 分钟）也是刻意取舍，写在同一处。

顺手：`i18n::CjkFont::source` 的「尚未钉死」改成指向 `Source::Pinned`；`clock.rs` 与
`general_section.rs` 注释里的 17.0 MB → 16.9 MB。

验证（`CARGO_TARGET_DIR=C:/Temp/ull-target/wt-168`，全量重编；取退出码，不截断）：
- `cargo test -p unlucky-core --all-targets` → **16 个 target / 1189 passed / 0 failed / exit 0**
  （lib 625 + setting 115 + 其余 14 个）
- `cargo test -p unlucky-i18n` → 31 passed / 0 failed / exit 0
- `cargo test -p unlucky-app-iced`（含 `no_hardcoded_tokens` integration）→ **693 passed / 0 failed / exit 0**
- `cargo clippy -p unlucky-i18n -p unlucky-core -p unlucky-app-iced --all-targets -- -D warnings` → exit 0
- `cargo fmt --all -- --check` 干净；全仓受检文件 ≤400（本分支最大 361）
 2026-11-08 14:38:25 +08:00
AskaEth 875b792206 fix(m168): 复审 r1 五项 —— 修红的 integration target、独立失败域、整体时限 
复审 r1（p1-1/fix-then-merge）五项全改：

1. **p1-1 CI 会红的 4 条 integration test**（`crates/core/tests/setting/`，我上一轮只跑了 `--lib`，
   scope 漏掉了覆盖 schema 版本号的目录式 target）：
   - `java_install_keys` / `isolation_keys` / `appearance_keys`：版本断言 1.6.0 → 1.7.0（M168 的
     `ui.font_cdn`），并写明「每加一批键推一次 minor 是纪律」。
   - `update_keys::a_read_only_launcher_config_never_retires_the_legacy_file`：夹具从**写死
     1.7.0** 改成 `launcher_version().minor + 1` 经 `SchemaRef::url()` 生成。写死数字的版本一推
     这条守卫就变成「同版本」⇒ 文件可写 ⇒ 迁移真的执行 ⇒ 旧文件被退役，而断言还绿着（用户数据
     守卫静默失效）。相对推导不会过期。
2. **p2-1 备用镜像不备用**：`cdn` 与 `fastly` 同属 Fastly（都 CNAME 到 jsdelivr.map.fastly.net），
   换掉。现在首选 `gcore.jsdelivr.net`（Cloudflare，独立失败域），二选 `cdn.jsdelivr.net`
   （Fastly）。注释里放了实测表（本机 + 复审机两份数据、字节数、sha256、IPv6 慢路径），
   并写清排序依据（Fastly 侧 IPv6 实测 67 KB/s ⇒ 丢掉 4 分钟；Cloudflare 侧两次都完整下完）。
3. **p2-2 整体时限**：`core::download::font` 新增 `ATTEMPT_DEADLINE = 90 s` /
   `TOTAL_DEADLINE = 180 s`，落在本模块自己的候选循环里（不动引擎全体语义）：每次尝试
   `min(单次上限, 剩余总预算)`，超时归 `Network` 档。新增守卫
   `a_trickling_connection_is_cut_by_the_deadline`（回环服务端每 100 ms 挤 1 字节、预算 300 ms）。
   顺带修掉一个真 bug：`tokio::time::timeout` 在运行时外构造会 panic（5 条既有用例当场抓到），
   现在整段包进 `block_on(async { … })`。UI 文案改成「网络不通或太慢（超时）」，不校验失败混。
4. **p2-3 说 `Source::PendingPin` 的两处**：`fonts/cjk.rs` 的模块文档已改；`ui/lang.rs::log_cjk`
   那句「D28 的下载通道还是 PendingPin」（在下载已发起之后打印，等于当面否定本功能）改成
   「已按 D28 发起下载，见 [font] cjk-download … 与设置页那一行」。全仓再扫，只剩注释里的历史说明。
5. **p2-4 假守卫**：判据抽成纯函数 `install::plan(strategy, current) -> Step`（`Skip` / `Apply` /
   `Start`），`after_probe` 只执行。旧的空转用例换成打真判据的打表用例；变异证明：删掉
   `Skip` 那一臂 ⇒ `a_started_or_finished_install_is_not_restarted` 红（已实跑）。

次要项也一并处理：`from_cache` 改成**本次是否真的命中缓存**（`CdnFetcher::was_cached()`，
`has_cached()` 降级为诊断字段 `cache_present=`）；`FontSpec` 的 URL 口径收紧为「非回环必须
https」（`is_acceptable_url` + 守卫）；`ui.font_cdn` 写进状态行 hint；文档里的 17.0 MB → 16.9 MB。
`download/font.rs` 拆出 `font/spec.rs` 守 400 行。

验证（这台机器上单个 800 MB 测试 exe 链接要 10 分钟，链接期间文件被 Defender 扫描，故耗时很长）：
- `cargo test -p unlucky-core --all-targets` → **1188 passed / 0 failed**（16 个 target，含
  `setting` 那个 115 条、上一轮红 4 条的 integration target）
- `cargo test -p unlucky-i18n` → 31 passed / 0 failed
- `cargo test -p unlucky-app-iced --lib` → 685 passed / 0 failed
- `cargo clippy -p unlucky-i18n -p unlucky-core -p unlucky-app-iced --all-targets -- -D warnings` → 干净
- `cargo fmt --all -- --check` → 干净；全仓受检文件行数最大 388（<400）
 2026-11-08 14:38:23 +08:00
AskaEth 449ded2cb7 feat(m168): 中文字体 CDN 下载真接线（D28 后半） 
M167 调研的结论是「中文字体 CDN 下载至今未实装」：`i18n::font` 只有 `Fetcher` trait 与
假实现，`needs-download` 分支什么也不做。这条把它接成一条真链路。

判据 → 下载 → 注册（一条链，四个 crate 各管一段）：

* `unlucky_i18n::font`（零依赖）：`Source::Pinned { urls, sha256, bytes }` 把「下什么」
  钉死——google/fonts 的 `NotoSansSC[wght].ttf` 钉到 commit `2894aab…`（不是 `@main`），
  17 772 300 B / sha256 `a3041811…`。可变字体一份覆盖 wght 100–900，省掉三份静态子集的 25 MiB。
  `FetchError` 补第三档 `Disk`（网络 / 校验 / 磁盘，UI 按类别选词）。
* `unlucky_core::download::font`（新）：缓存命中 → 共享引擎 `download_bytes` → 复验（sha256 +
  sfnt 魔数 + 32 MiB 上限）→ 原子落盘。**复验在写盘之前**，所以「哈希不符」时盘上什么都没有；
  缓存按 `<sha256 前 16 位>` 命名，pin 一换自动换名。
* `unlucky_app_iced::fonts::{cdn,install}`（新）：`CdnFetcher` 把 pin 接进 core（`ui.font_cdn`
  可覆盖 URL，哈希不换）；`install` 是状态机 + 后台线程，只有 `NeedsDownload` 才起线程
  （英文 / 系统已有 / 探测不出一律零网络）。注册走 `iced_graphics::text::FontSystem::load_font`，
  族名从字体库读回来核对。失败只降级（继续用系统字体），不阻塞、不崩。
* 接入两条路径：`fonts::resolve_with`（启动）与 `fonts::cjk_for`（设置页切语言）都调
  `install::after_probe`；设置页 General 组多一行状态（下载中 / 完成 / 失败 / 无需下载 + 三类失败
  原因），文案进 catalog 金表（链尾追加，既有顺序不动）；`App::advance` 每秒比对状态快照后重建
  视图模型，所以那一行会自己刷新。

配置：新增 `ui.font_cdn`（`keys/font.rs`，schema 1.7.0），空 = 内置 jsDelivr 镜像（含备用边缘）。

守卫（三条都能变红，变异证明见报告）：core 侧 8 条（缓存不联网 / 哈希不符拒落盘 / HTML 不当字体
/ 坏缓存自愈 / 上限 / pin 校验），app 侧 6 条（三种闲置策略零调用、失败不注册、类别不串、幂等、
截图钉子、单行日志），页面侧 1 条（四态 × 两语言无缺译、不写假百分比）。

测试：`cargo test -p unlucky-i18n --lib` 31 绿；`-p unlucky-core --lib` 622 绿；
`-p unlucky-app-iced --lib` 684 绿；`cargo fmt --check` 干净。截图三张见报告。
 2026-11-08 14:38:23 +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 add7f2e672 test(m170): 改对复审点出的两处证据陈述 + 收紧用例前提（零行为改动） 
r1 复审 p2-2items（守卫本身判 clean，四条变异自跑确认有牙）。这一轮**只动注释与测试
前提，产品行为零变化**：`format/write.rs` 一字未改，`probe.rs` 保持上一提交的收窄结果。

p2-1 复审核正的事实：`one_file_over_the_threshold_...` 的 `kind()` **不区分闸的位置**。
它的源是**可读的** 8 KiB 真文件，闸被挪到 `File::open` 之后时写循环第二道闸
`Written::spend`（每块之后 `guard_with`）照样返回 `Limits`——所以它在「闸挪位置」的
变异下仍然绿（我这轮重跑变异 A 也复现：其余 4 条全绿）。原来那句「源文件能读时这里
拿到的是 pack_io」是错的，改成「可读源命中第二道闸」并把顺序的举证责任明确交给
`the_gate_runs_before_any_content_is_opened`。

p2-2 目录长度的实测数字之前钉错了：我早先那条探针用的是**短名**（`f0`..`f39`，7 条
才到 4096、40 条仍 4096），而用例里填的是 `filler-NN`。这轮按用例真实形状重测三组
（`std::fs::metadata`，同一台机器同一 `%TEMP%`）：
  短名 `f0`…`f39`：空 0 ｜ 3 条 0 ｜ 7 条 4096 ｜ 20/32/39/40 条 4096
  `filler-NN`：    空 0 ｜ 3 条 4096 ｜ 7 条 4096 ｜ 20 条 8192 ｜ 32 条 8192 ｜ 39 条 12288 ｜ 40 条 16384
两次独立跑同形状结果一致。所以「第几个条目起非零」没有平台无关答案（NTFS 目录索引按
4 KiB 一档分配，跟条目名长度与条数都有关），三处注释改成区间 + 一张实测表，并注明
「只钉 32 个 `filler-NN` 这个形状（本机 8192）」，不再硬凑一个好看的数字。

顺带做掉复审那条「不计入 p2 但建议收紧」：前提从 `declared > 0` 提到
**`limit > 清单 JSON 长度`**（`limit = declared.saturating_sub(1)`，`json_len` 由
`CURSEFORGE.render(&manifest)` 现算，本用例实测 220 字节）。否则某个对 32 个条目报得很
小的文件系统会让用例因「清单自己越线」而假绿。同时把 `declared - 1` 换成
`saturating_sub`，让长度为 0 时走到清楚的 assert 文案而不是整数下溢 panic。
把 `DIR_LENGTH_FILLERS` 临时改成 0 验证过这条 assert 是活的：红在这句上
（`声明长度 0 − 1 = 0 … 必须大于清单 JSON 自身长度（220）`）。

变异复跑（本机 Windows/NTFS，跑完已还原 write.rs）：
- A：`preflight` 挪到 `File::open(&source)` 之后 → 新用例**红**（left Io / right Limits），
  其余 4 条仍绿（含上面那条可读源用例，正好印证 p2-1 的更正）；
- C：A 之上只留 `expect_err` / `!target.exists()` / `leftovers` → **5 条全绿**，
  结构断言确属同义反复。

门禁：`cargo test -p unlucky-core --lib` 613 passed / 0 failed / 0 ignored；
`cargo fmt --all --check` 干净；`cargo clippy -p unlucky-core --all-targets -- -D warnings`
干净；zip64.rs 345 行（<400）、probe.rs 45 行。
 2026-11-08 10:39:28 +08:00
AskaEth 72767067f3 test(m170): 闸顺序用例在 Windows 上也真跑（声明长度自己造 + 反证） 
M166 r2 复审的两条「合并后收口」观察：

① `zip64::the_gate_runs_before_any_content_is_opened` 原来量夹具目录的
   `metadata().len()`，量到 0 就 `return`——而本机 NTFS 上空目录就是 0（实测：空 0、
   第 7 个条目起 4096），于是这条「行为证明」在 Windows 上一条断言都没执行。
   现在：先把目录填到长度非零（32 个 filler），拿「声明长度减一字节」当总量上限，
   前提不满足就 `assert!`；单条目上限给 `u64::MAX`，不让 `guard_entry` 当替身。
   另加一条**反证**：同一份夹具把限额放到 `u64::MAX`，必须死在 `File::open`/`read`
   上拿到 `pack_io`——于是上面拿到 `pack_limits` 只能解释为「闸在碰内容之前」。
   同时更正 `one_file_over_the_threshold_...` 里那句过头的注释：`leftovers` /
   `!target.exists()` 在任何失败路径上都成立，属结构侧检，不是「没读一个字节」的证明。

② `probe.rs` 的模块级 `#![allow(clippy::missing_const_for_thread_local)]` 收窄到
   `thread_local!` 内那个 `static` 上（A/B 实测：没带的那组只报一条 lint，带了就干净，
   且不判 unused），模块级 allow 不再替未来的真漏 const 打掩护。

变异验证（本机 Windows/NTFS，跑完已还原）：
- 预检挪到 `File::open` 之后 → 本用例红（`left: Io` / `right: Limits`），改前那版全绿；
- 预检改成用 `std::fs::read` 量尺寸 → 同样红；
- 只留结构断言（拆掉 kind/文案/反证）→ 同一变异下**全绿**，证明它们确实区分不了顺序。
 2026-11-08 09:54:31 +08:00
AskaEth 9b23221a62 test(m166): 钉住生产 write() 的限额绑定（复审 r1 p2-1） 
复审 r1 的变异：把 `format.rs` 里 `write()` 传给 `write_with_limits` 的
`WriteLimits::production()` 换成 `WriteLimits::new(u64::MAX, u64::MAX, entries)`，
**606 条全绿**。原因是夹具缩到 KiB 之后，"生产路径 + 真超限内容"那种顺带守住生产
限额的证法没了，而 `the_production_limits_are_the_shared_constants` 只钉了
`production()` 的**返回值**、没钉 `write()` 的**调用点**。

补法（不动生产签名、不进发布构建）：
- 新增 `format/probe.rs`（`#[cfg(test)]`）：线程局部的限额记录钩子；
  `write_with_limits` 进门时 `#[cfg(test)] probe::record(limits);` 记一笔。
- `tests/limits.rs::the_production_write_path_hands_the_shared_constants_to_the_preflight`
  走**生产**的 `CURSEFORGE.write`（KiB 级 payload）后断言记到的就是
  `WriteLimits::production()` 的逐字段值，并再钉一遍统一常量。
- 反向验：上述变异现在恰好 1 条红（`总量限额：生产路径传错了`，2026-11-08 实测
  18446744073709551615 vs 536870912）；只把 entry 换成 u64::MAX 也红（`单条目限额`）。

附带（复审非阻断观察）：
- 观察 2 采纳：新增 `zip64::the_gate_runs_before_any_content_is_opened`，把"闸在读之前"
  从结构证明升级成行为证明——源做成**目录**（`metadata()` 有长度、`File::open` 拒绝访问，
  本机实测 C:\Windows 20480 字节 / crates/core/src 4096 字节），闸若挪到读之后会拿到
  `pack_io` 而不是 `pack_limits`。
- 观察 1 采纳：`tests/limits.rs` 里"改坏常量会在 cargo check 就红"的旧注释改成准确说法
  （E0080 只在测试构建出现，裸 `cargo check` 是绿的）。
- `probe.rs` 里 `#![allow(clippy::missing_const_for_thread_local)]`：clippy 1.99 对已经
  写成 `const { Cell::new(None) }` 的 `thread_local!` 仍报错（最小复现同样红），是误报；
  外挂在宏上的 `#[allow]` 会被判 unused attribute，故用模块级 inner attribute。

cargo test -p unlucky-core --lib：608 passed / 0 failed / 0 ignored（+2 条）；
clippy --all-targets -D warnings、fmt --check 干净；全仓 0 个 >400 行文件。
 2026-11-08 09:30:26 +08:00
AskaEth 49a2fafe51 test(m166): zip64 夹具改用小 limits，去掉 8.5 GiB 真落盘 
`set_len` 造的所谓稀疏文件在 NTFS 上并不稀疏：实测 `SetLength(1 GiB)` 之后
C 盘可用空间正好掉 1024 MiB。于是 `zip64.rs` 那两条用例的声明尺寸
（`u32::MAX + 1` ≈ 4 GiB 加 `3 × 1.5 GiB` = 4.5 GiB）就是 8.5 GiB **真占用**，
再加上 `write/tests.rs` 的 3 GiB 与 `limits.rs` 的三条 64 MiB 级用例，
单次跑的落盘峰值到过 ~12 GiB。

判据本身跟夹具大小无关（吃的是 `metadata().len()`），所以把 limits 做成参数：
`format::write_with_limits` 是 `PackFormat::write` 的实体，生产路径仍只传
`WriteLimits::production()`，测试传 KiB 级小值走**同一条** `preflight` 分支。
`WriteLimits` 的可见性顺势开到 `pub(in crate::addon::pack)`。

GiB 级的**数值判定**搬进 `format/write/tests.rs` 的纯算术用例：>4 GiB（撞 ZIP64
阈值即拒、差一字节放行）与 >2 GiB（M152 那个 2.5 GB 样本现在按统一上限拒），
以及第二道闸 `Written` 在同一批数值上的行为——两道闸吃的都是 u64，不需要落盘。

断言一条没删、用例一条没新加 `#[ignore]`（反而把旧的那条 `#[ignore]` 的
2.5 GB 用例换成会跑的 KiB 级版本，补上 `guard_entry` 分支的端到端覆盖）。

扫描：`grep -rn 稀疏 crates/ packaging/ docs/` 里凡写着"稀疏文件不占磁盘"的
注释一并改成实测口径（含 `addon/temp.rs`），避免下一个人照着再踩一次。
 2026-11-08 09:30:26 +08:00
AskaEth afe169751f fix(m165): forget 之后让自更新也换引擎（复审 P2-1）+ 卡口计数与端到端守卫 
复审 P2-1（采「修法 1」，不是只改措辞）：`shared::forget` 只让登记处不再持有
那一份，换不掉自更新 `Factory` 里常驻的 Arc —— 于是「重新检测地区」对更新路径
不生效，直到重启。现在设置动作会把 Factory 一起重建。

- presenter/update_state: `Runtime::rebuild_factory` + `CoreHost::refresh_update_factory`；
  只换 factory，不动 view/inflight（在飞的 Job 派发时已克隆走装配，重建不打断它）
- presenter/dispatch: `SetSetting` 成功且键是「重新检测地区」时调 refresh
- presenter/engine: `DETECT_REGION_ACTION` 常量（设置页行 id / set 分派 / dispatch
  判断共用）；放这里而不是 settings.rs 是因为后者已到 400 行红线
- core/shared: 文档改准 —— forget 的范围是「登记处不再持有」，长命持有者必须自己重建；
  记账从 `engine_for` 移到 `DownloadEngine::new` 这个卡口（分两把锁，避免自锁），
  于是 `constructions` 连绕过登记处另造引擎的调用点也统得住

守卫（都做了变异实证）：
- update_tests::detect_region_rebuilds_the_update_factory_engine：走真实命令路径
  `AppCommand::SetSetting` → 断言 Factory 换了引擎且指向登记处当前实例；变异（删掉
  dispatch 里那句 refresh）→ 红在 Arc::ptr_eq
- update_tests::rebuilding_the_factory_does_not_touch_a_running_job：重建不清
  inflight、不改快照，在飞 Job 仍能跑完
- addon/http::tests::three_host_request_paths_share_one_engine：连走三条真实宿主路径
  （Modrinth 元数据 GET / CF 带 header GET / Java 页渲染）后 constructions == 1；
  变异（让 get_via_engine 自己造引擎）→ 红，left:2 right:1

顺带修：settings.rs 在上一提交被推到 403 行、engine.rs 401 行，两者都超
guards.yml 的 file-size 红线（>400 直接失败）。现在 settings.rs 400 / engine.rs 399，
全仓 `*.rs` 复跑「>400」扫描无输出。

验证：core lib 608 过、5 个 download 集成 target 42 过、presenter lib 270 过、
clippy --all-targets 干净、fmt 干净。真站点仍未打（见报告「没验的部分」）。
 2026-11-08 09:30:05 +08:00
AskaEth 46389d61fd feat(m165): 下载引擎按数据根跨请求复用（运行时常驻 + 构造次数守卫） 
宿主侧以前每次请求都现建一个 DownloadEngine：连接池、信号量限流、
健康度记忆、内容寻址缓存索引全部清零。现在改成按数据根共享一个实例。

- core: 新增 download::shared（进程级登记处，键 = 缓存根）——
  engine_for / forget / constructions；region/health/cache/mirrors 的装配
  收在这一个 build() 里（持锁构造只做本地 I/O，不联网）
- core: download::blocking 改成进程内唯一常驻运行时。reqwest 的连接池绑在
  驱动连接的运行时上，引擎复用必须配运行时常驻，否则复用的是个装满死连接的池
- presenter: host::engine::engine 返回 Arc<DownloadEngine>（共享实例），
  addon/update/versions/java/authlib 等全部调用点随之改；新增 forget 供
  「重新检测地区」失效（否则进程级引擎下那句话不成立）
- presenter: addon 详情页把「项目 + 版本列表」两次 block_on 收成一次

失败分类 / 镜像回退 / Retry-After 语义未改动（error.rs、http.rs、engine.rs 的
候选循环一字未动）。

守卫（都带变异实证）：
- shared::tests::one_engine_per_cache_root + host::engine::tests::
  host_requests_share_one_engine：断言 constructions(root) == 1（不是只看结果）
- shared::tests::pooled_connection_survives_across_block_on_calls：127.0.0.1
  回环服务统计 accept 次数，两次 block_on 必须只拨号一次

验证：cargo test -p unlucky-core --lib（608 过）、5 个 download 集成 target（42 过）、
cargo test -p unlucky-presenter --lib（267 过）、cargo clippy --all-targets、
cargo fmt --check 全绿。真站点（Modrinth/CurseForge/BMCLAPI）未打，见报告。
 2026-11-08 09:30:05 +08:00
AskaEth 47ed270293 fix(m162-r3): 金表条数与内容同源（堵住「少挂一段仍绿」的假绿）+ 补两条覆盖缺口 
P2-1（r3 抓到的假绿）：`golden::len()` 从「各段 len() 相加」改成 **`rows().count()`**。
r3 实测的变异是：删掉 `rows()` 里的 `chain(tail2::ROWS)` 后 `split_keeps_every_translation`
仍绿——因为条数来自一处手工聚合（仍含 tail2 ⇒ 459 == `Key::ALL.len()`）而内容只遍历
`rows()`（少了 213 行）。现在条数与内容同源，漏挂一段当场对不上。
- 变异复现（删 chain）：`rows().count()=246 len()=246 Key::ALL.len()=459` ⇒ 用例
  **FAILED**（`left: 459 / right: 246`，「key 条数与拆分前不一致」）；
- 恢复后：`rows().count()=459 len()=459 Key::ALL.len()=459` ⇒ **ok**；
- 断言一字未改（没有放宽成「只比条数」或「只比前缀」）。

顺带三条：
1. `golden.rs` 的 `rows()` 文档补上 `tail2`（并写明「加段必须也 chain 上，条数与内容只能从
   这一条序列导出」），与上一条同族。
2. `online/mod.rs` 模块表里 `[complete]` 的职责改成「按摘要认文件（`identity_of`）」，
   与「补全循环已删、生产在 `import::complete`」一致；批量 POST 那段也点明循环位置。
3. 补两条 pack 用例走不到的覆盖（`import/complete.rs` 的 `#[cfg(test)] mod tests`）：
   - `an_entry_without_sha512_is_counted_not_guessed`：有 path、有 downloads、无 sha512 ⇒
     `unfilled += 1` **且一次请求都不发**（mrpack 读者强制 sha512，这条是防御分支）；
   - `an_existing_download_list_is_never_extended`：已有直链时 `downloads` **逐字相等**
     （长度 + 内容），不再用「包含」这种测不出重复追加的断言。
   两条都验过能红：把「缺 sha512 不计数」与「总是追加直链」同时变异 ⇒ 两条 **FAILED**；
   恢复后 **ok**。

登记项（r3 指出的 scan 注记）也顺手收了：`Completion::note` 在 `filled == 0` 时改说
「按 sha512 从 Modrinth 补全 sha1：一条也没补到（补不出 N 条）」，并且不再带
「其余条目照旧按『缺省保留』处置」（那是导入场景的尾缀，预检里没有这回事）。用例
`offline_with_nothing_filled_does_not_say_zero_items_were_filled` 与
`import_online::only_a_real_offline_stops_the_completion_round` 都钉住「真断网 + 一条没补到」
既不说「补全了 0 条」也不说「缺省保留」。

全仓行数（guards.yml::file-size 同口径）：**0 个超限**。
 2026-11-07 17:37:13 +08:00
AskaEth ecd24f0608 fix(m162-r2): 金表沿用主线的拆分边界 + phase/pipeline 回到 400 行内 
金表（rebase 到 M161 后重写这一段）：**采用 main 的拆分边界**——`golden/tail.rs`
（`InstancesLaunchReset` 之后、`PackTargetNew` 之前）+ `golden/tail2.rs`
（`PackInstanceName` 之后），不再保留本分支原来那套 205/221 的切法。
本分支新增的 6 条 key（`ContentOffline{Title,Body}`、`ContentDetail{Fetching,FetchFailed,
VersionCount,VersionLine}`）按 `Key::ALL` 的顺序并入 main 的 `tail.rs`；
`golden.rs` 的 `rows()` 保持 `GOLDEN + tail + tail2` 三段串联。（`len()` 与内容同源的修正
在下一个提交里。）

其余两处（本来就是我推过线的，现在回到红线内）：
- `import/phase.rs` 397 → **400**：只动注释（`Resolved` 的两个摘要字段共用一句、
  `resolve`/`settle` 的文档各并一行），代码语义零改动。
- `import/pipeline.rs` 399 → **400**：把补全注记（14 行）搬到 `import/complete.rs` 的
  `Completion::note(lead)` 旁边，管线只剩一行 `complete_and_note(...)`；
  `scan_pack_online` 也改用同一个 `note("预检前")`——注记文案由两处变一处。

同时删除与 `import/complete.rs` 重复的 `online::complete::{complete_files, CompletionSummary}`
（生产零调用方），只留生产在用的 `identity_of`。
 2026-11-07 17:37:13 +08:00