AskaEth/Unlucky-Launcher
1
0 Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
830 Commits 3 Branches 7 Tags
d584a2c42ec7ae6ecc55e1ce65a2ad8fe7d32453
Commit Graph
166 Commits
Author SHA1 Message Date
AskaEth d584a2c42e feat(download): 把 download.proxy_mode / download.proxy_url 接进代理三态（M295） 
台账 P26：两个键引擎侧零消费者——`http::build_client` 只设 UA / 连接超时 / 重定向 / 默认头，
从不 `.proxy()`。设置页画着三档 chip 与一个地址框，改它对任何一次下载都不生效（`system` 那一
档「碰巧能用」只是因为 reqwest 默认读环境变量，不是这段代码做的）。

- core::download::proxy（新）：`ProxySetting::from_raw` 是**唯一**翻译层，三档落到 client 上：
  `none` ⇒ `.no_proxy()`（真直连，连 `HTTP_PROXY` 也不读）/ `system` ⇒ 不调任何代理 API
  （跟随环境变量 = M295 之前的行为）/ `manual` ⇒ `.proxy(Proxy::all(url))`；未知值 ⇒ `none`。
- 两条决定写进模块头：`proxy_url` 在非 manual 档**忽略**（不校验、不进结构，值原样留在文件
  里）；`manual` + 空地址 ⇒ `system`（设置页那行文案一直这么承诺）。
- 非法地址不穿透：`Proxy::all` 解析失败 ⇒ 有界错误（`InvalidRequest` + 带原串的文案），不
  panic；`DownloadEngine::new` 回落**直连**重建（不用 `reqwest::Client::new()`——那会跟随环境
  变量代理，回落就不确定），原因留在 `proxy_problem()`，CLI 的 `download::engine` 打一行
  stderr；`config().proxy` 不撒谎（仍是用户写的 `manual`）。
- `EngineConfig.proxy` 默认 `System`（=「没读设置」的档：auth 登录 / JDK 下载页 / 地区探测都
  直接用它，保持老行为），`DownloadTuning.proxy` 默认 `Direct`（与 schema 的 `none` 一致）。
- 两键进 `RawTuning`（与 `gh_proxy` 同形），presenter 的 `tuning_of` 与 CLI 的 `tuning` 各加
  两行；两个宿主都是完整字段字面量 ⇒ 「忘了读」是编译错误。`summary()` 加 `代理=…` 一档。
- 判据是「请求真的经过代理」：新夹具 `FakeProxy`（本地 TcpListener）+ 目标 `.invalid`（解析不
  了）⇒ 拿到正文只可能来自代理，且代理记到的请求行是**绝对 URI**。三条用例：manual 真走代理
  / direct 无视环境变量而 system 跟随（同一份 `HTTP_PROXY`）/ 非法地址回落直连不 panic。
  变异 M17-M22 记在 docs/download-settings.md §6。
- 行为变化（doc §5.2 写明）：`none` 从「碰巧跟随环境变量」变成真直连，靠 `HTTP_PROXY` 上网的
  用户要选一次 `system`。发布版 GUI 的「下载 JDK」页仍不读这两个键（finding 已开）。
- 门禁：四 crate `check --all-targets` / 测试（3201 passed, 0 failed）/ `clippy -D warnings` /
  `fmt --check`；另跑了 `check --workspace --all-targets`。判据用 `$?` 与 `test result:` 行验。
 2026-11-13 10:43:09 +08:00
worker-mirrorwire 69e3e198bf fix(download): M294 r1 —— JDK 下载页与 CLI 也接上源选择，文档同步 
复审 p1：发布版 GUI 的「下载 JDK」页是第二处 DownloadEngine::new（要 with_progress
拿走引擎），此前只读了 gh_proxy，region / mirror_preference 到不了那里；报告却把 GUI
写成「已接」。复审 p2：CLI 四条命令同样不认这两个键 —— 同一份 launcher.json 在 GUI 与
CLI 上表现不同，等于把「设置项说假话」挪到 CLI 侧。

- app-iced downloads/engine.rs：新增 SourceSelection（只读键、不翻译）+
  engine_with(.., &SourceSelection)，在 gh-proxy 三态之前叠
  DownloadTuning::with_source_selection(..).apply_source_selection(..)
- Request 加 source_selection 字段，构造点（app/update/settings/java/downloads.rs）
  用 SourceSelection::of_config(&config) 显式传值（不从缓存根反推配置路径：
  反推失败会静默按 auto 收场，正是本 mission 要消灭的形状）
- cli download.rs 的 tuning()：链 .with_source_selection(..)，四条命令共用这一处装配
- core 的 summary()：把「地区 / 镜像偏好」两档印进 CLI 那行生效值（CLI 既然读了，
  少印两项就是新的半真话）
- shared.rs 注释说清「共享引擎」与本文件的第二处装配点；app-iced 模块头补对照表
- 新判据：JDK 下载页与 CLI 各一条断候选源顺序的用例，均配变异验证（换回裸
  EngineConfig::default() / 裸 tuning 即红）；补一条 region=cn + gh_proxy=off 的
  叠加次序守卫（复审 P3-2）
- docs/download-settings.md：§1 表格两行、§5 拆「已接 / 未接」、新增 §3.1.1 覆盖面
  表、§6 补 M14-M16 三条变异、§7 补「镜像可达性没验」

连带（不加就编不过，已报备 tower）：downloads/tests.rs 的 Request 字面量 +1 行、
downloads/tests/gh_proxy.rs 两处 engine_with 调用点补第四参。
 2026-11-13 09:00:00 +08:00
worker-mirrorwire 0f64acbd05 feat(download): 把 download.region / download.mirror_preference 接进源选择（M294） 
两个键此前在引擎侧零消费者：设置页画着三档 chip，改它不影响任何一次下载。
现在它们是 RegionProfile 之上的一层显式覆盖（读时叠加，不落盘，region.json
仍是自动判定的结论）：

  显式 mirror_preference（official/mirror）
    > 显式 region（cn/global）
      > 自动探测（时区+语言+系统信号）与 24h 缓存

- core::download::preference（新）：两个枚举的 from_raw（未知值/空串 ⇒ auto）
  与 apply；两个键都落到 RegionMode 这一个「谁在前」开关上，不造第二套排序
- region::RegionProfile::overridden：在已有判定上叠一层模式（探测逻辑不动）
- DownloadTuning 加 region / mirror_preference 与 apply_source_selection
  （组合顺序 = 优先级），shared::build 改用它；默认 Auto ⇒ 逐值等于今天
- 未进 RawTuning：CLI 的 tuning() 用完整字段字面量构造它，加字段会连累
  crates/cli（不在本 mission scope），改走 with_source_selection 入口
- presenter 的 tuning_of 读这两个键（否则 GUI 侧仍是假行）

判据断具体源名序列：不设/auto/未知 ⇒ ["bmclapi","official"] /
["official","bmclapi"] 逐项不变；official/mirror/cn/global ⇒ 顺序跟着换；
另有一条从设置原文到引擎 plan() 的端到端用例。
 2026-11-13 08:26:30 +08:00
AskaEth 1004af81ca fix(download): 同源换表示时不再沿用上一份的校验器 + 三条 p3 收口（M293 r2） 
复审 r2（p2-1）：r1 的 `same_source` 只挡了「源不同」，没挡「同一 URL、换了一份表示」。
`done` 为空（Restart：`SizeChanged` / `HashChanged` / `ChunkLayout` …）时没有任何字节要接着用，
但 `journal.begin` 仍把上一份表示的 ETag 写进**新一轮**元数据；`record` 又只在缺值时写 ⇒ 本轮
3 段（新内容）配的是旧校验器 ⇒ 重试拿它发 `If-Range` ⇒ 服务器按 RFC 7233 回 200 + 完整正文 ⇒
`RangeUnsupported` ⇒ 丢整份 ⇒ 单连接从头下。实测 113664 字节（2.775×），比「干脆不续传」的
72704（1.775×）还多一整份。

修法：「谁能当校验器」收成一个 `carry`，两个维度缺一不可 ——
  let carry = if done.is_empty() { None } else { same_source };
`if_range`、`etag`、`last_modified` 三处全部走它。清掉之后本轮响应里的真实校验器由
`ChunkJournal::record` 填进来；最坏也只是 `NoValidator` ⇒ 整份重下（1.775× 基线），不会更坏。
文档（`chunk_resume` 模块头的「校验器跟着源与表示走」、`record`、`carry` 处）同步改成两维口径。

判据（新用例 `chunked/resume.rs::stale_validator_from_the_previous_representation_is_not_carried`）：
同一 URL、盘上是上一份表示的元数据（旧总长/旧段区间/旧 ETag `"v1"`/旧摘要）⇒ 本轮因
`HashChanged` 走 Restart、服务器此刻发 `"v2"`。断言：重试的 `If-Range` 只许是 `"v2"`、字节数
41984（1.025×，而不是 113664）、hits 5、resumed_from 30720、终态文件逐字节正确。

变异（两种，均实测红）：
* 只把元数据那两行退回 `same_source`（`if_range` 仍按 `done` 门控）⇒ 复现复审的探针数字：
  PROBE stale_validator if_range=["\"v1\""] hits=6 bytes=113664 resumed_from=0，
  断言红在 `left: ["\"v1\""] right: ["\"v2\""]`；
* 把 `carry` 整体退回 `same_source`（连带首轮也发 `If-Range`）⇒ 红在
  `left: ["\"v1\"","\"v1\"","\"v1\"","\"v1\""]`。

三条 p3：
* p3-1 `Last-Modified` 支路端到端补上了：夹具新增 `last_modified` 字段 / `with_last_modified()`
  / 发出该响应头，`validator_ok` 扩展成「ETag 或 HTTP-date 比得上」（RFC 7233 的弱校验器兜底）。
  新用例 `chunked/last_modified.rs`：服务器**只给** Last-Modified，重试必须带这个日期发
  `If-Range`、只补 1 段（41984 = 1.025×）。变异（`record` 不写 last_modified）⇒ 红在
  「只该在重试那一次发条件请求：[]」（变成 NoValidator 干净重下）。用例同时写明它抓不住真实
  服务器的 HTTP-date 比较语义。
* p3-2 `ChunkJournal::save` 的同步原子写：判断「可以接受」并给了量级 —— 一个作业 ≤17 次
  （16 段 + 建账）、每次 1–3 KiB，SSD ≈ ≤30 ms / 网络盘 ≈ ≤1 s，摊在分钟到小时的作业上占比
  1e-4 量级；且顺序有意义（record-then-trust），挪 `spawn_blocking` 要为几毫秒引入跨 await
  加锁的顺序风险；与单连接路径同口径。退路写在文档里。
* p3-3 `integrity=None` 时末尾摘要空转的一致性边界写进 `chunk_resume` 模块头「已知代价」+
  `verify_part` 文档：只剩旧段自证与 `If-Range` 两道，「同长度换内容」不可察觉；现实入口是
  上游没给合法 sha1 的 `ModFile`（`addon/online/download.rs` 只在 sha1 合法时才设 integrity），
  以及 `Library` 元数据 / `download.bin` 缓存等无摘要调用点；要收紧属于产品决策。

字节判据复测（三条探针形态）：
  healthy    bytes=41984 size=40960 ratio=1.025 hits=5 resumed_from=30720
  nofeature  bytes=72704 size=40960 ratio=1.775 hits=8 resumed_from=0
  staleval   bytes=41984 size=40960 ratio=1.025 hits=5 resumed_from=30720 if_range=["\"v2\""]
即 stale-validator 那条从 2.775× 回到 1.025×，healthy 档未变差。

门禁：lib 903 / engine_mock 17 / chunked 22 / resume 12 / partfile 7 / cache 6 全绿；
clippy -D warnings 0、fmt --check 0。改动的单文件最大 391 行（chunked_test.rs），无超 400。
 2026-11-13 06:59:58 +08:00
AskaEth ffca0f4454 fix(download): 换源后不再沿用旧源校验器 + 三条 p3 收口（M293 r1） 
复审 r1（p2-1）指出的链条：源 A 落 3/4 段失败 ⇒ 元数据 url=A + A 的 ETag；换源 B 时
`decide` 判 UrlChanged、删盘重来，但 `ChunkJournal::begin` 把 A 的校验器原样写进 url=B 的
新元数据，而 `record` 只在 `etag.is_none()` 时写入 ⇒ B 的真实校验器永远盖不上。于是拿 **A 的
ETag** 对 B 发 `If-Range`：按 RFC 7233 §3.2 服务器回 200 + 完整正文 ⇒ `fetch_chunk` 判
RangeUnsupported ⇒ 丢掉整份 ⇒ 单连接从头下 —— 债务以另一条路径复现。

修法（复审给的选项 A）：校验器与**记下它的 URL** 绑定，`same_source = previous.filter(|m|
m.url == candidate.url)`，`etag` / `last_modified` / `If-Range` 三处全部走它，让「谁能当校验器」
只有一个判定点。不选 B（换源时清空）是因为 B 只是 A 在「URL 变了」这一特例上的写法，条件放在
读取处比散到写入处更难漏；不选 C（多源各记一份）是因为 `ResumeMeta` 本来就有 url，再加一个来源
字段会多一处可与 url 漂移的状态。

夹具此前不解析 `If-Range`，这一跳只能读代码推。现在 `support/` 记录每个请求的 `If-Range` 取值，
并按 RFC 7233 §3.2 处置（对不上就忽略 Range、回 200 + 完整正文），于是「真实服务器上的后果」也
进了用例。

判据（新用例 `chunked/switch.rs`，两个夹具服务器当一个官方源 + 一个镜像源）：
* 源 B 收到的 `If-Range` 只许是它自己的 `"src-b"`（源 A 同源续传照旧带 `"src-a"` 作对照）；
* 源 B 的字节数仍是 3 段 + 卡住的 1KiB + 补 1 段 = 41984（1.025×），换源没把同源续传打回整份重下；
* 最终文件逐字节正确；
* 第二条用例走「新源自己不发 ETag」那一支：`NoValidator` ⇒ 新源重试整份重下（`resumed_from=0`、
  8 个请求、72704 字节），一个条件请求都不许发 —— 这是「无法证明就不复用」的明确取舍。
变异（去掉 URL 过滤）⇒ 两条都红，实测原文：
  assertion `left == right` failed: 源 B 收到了不属于它的校验器
  left: ["\"src-a\""]  right: ["\"src-b\""]
  新源没有任何校验器，就不许发条件请求（带 A 的值更是串源）：["\"src-a\""]
同一变异下还实测到了后果：`b_bytes=113664 b_hits=6 resumed_from=0`（200 白下一份 + 单连接整份
重下 = 2.77×），即复审预测的那一跳确实存在。

三条 p3 一并收口：
* p3-1：`abort_all()` 之前用 `try_join_next` 把「已落完但还没被收走」的段记进账
  （`absorb_completed`，总长判据与正常回收同一道）。这是尽力减少浪费、不是正确性前提，且
  它是「谁先完成」的竞态 ⇒ 没有确定性用例能钉住，已在文档里写明边界。
* p3-2：`verify_chunks` 改为返回 `Option<u64>`（可复用字节数），`AttemptOk.resumed_from`
  直接取它，删掉原来「记录另算一遍」的双份口径。
* p3-3：`chunk_resume` 模块头新增「已知代价」：重读量正比于**复用的字节**（不是整份文件）、
  为什么不能用「相信摘要」来省掉、以及超时后 `spawn_blocking` 线程不可取消在 Windows 上的
  句柄风险。

拆文件守 400 行硬线：`await_chunks` + `absorb_completed` 移到 `transfer_chunk/join.rs`
（逐字节搬移），`MockResponse` 移到 `support/response.rs`（逐字节搬移，只加 `with_etag` /
`without_etag` 两个构造器）。

门禁：lib 903 / engine_mock 17 / chunked 20 / resume 12 / partfile 7 / cache 6 全绿，
clippy -D warnings 0、fmt --check 0；字节判据复测未变差（resume 41984 = 1.025×，
noresume 72704 = 1.775×）。
 2026-11-13 06:45:55 +08:00
AskaEth 3ade2d14a8 feat(download): 分块路径写续传元数据并自证旧字节（M293） 
台账 P21 第 2 条 + P19(b)：分块路径此前进来先 `part.discard()`、失败也 `discard()`，
188MB 的 JDK 任何一次失败都从 0 重下；M289 又给预算耗尽加了「不再重试、不再换源」的
短路，慢链路上一次晚到的失败就变成「这个文件下不来」。

写这一侧：
* `ResumeMeta` 新增 `chunks: Option<Vec<ChunkRecord>>`（段区间 + 该段 SHA-1），
  由新增的 `chunk_resume::ChunkJournal` 每成功回收一段就原子落一次盘；
* `fetch_chunk` 顺带带回段摘要、`Content-Range` 总长与 ETag/Last-Modified，
  所以元数据里同时有 total / 源 URL / 分块清单 / 校验所需信息；
* 分块失败不再丢中间文件，只有 `RangeUnsupported`（单连接接不住这种形状）才丢。

判这一侧：
* `chunk_resume::decide`（纯函数）要求策略允许、URL / 总长 / 摘要 / 校验器全对得上，
  且每条记录精确命中本次分块规划里的一段，否则从头再来；
* `chunk_resume::verify_records` 按记录重读旧段、重算摘要：任何一段对不上就整份丢掉
  （元数据本身已不可信，同批其它记录也不再被信任）；
* 续传的段请求带 `If-Range`，让服务器回答「内容变了没有」；
* 整文件摘要照旧在末尾整份重算，覆盖新下 + 复用的全部字节。

单连接路径零改动：`resume::decide` 的判定一字未动，只新增
「元数据里带分块清单 ⇒ 强行判 Restart 交给分块路径」这一条，避免预分配全长文件被
单连接的 `Complete` 误判成「已下满」。

判据（都是「服务端实际吐了多少字节」，不是「最终 hash 对」）：
* 3/4 处失败后续传完成：41984 字节 / 40960 文件 = 1.025×（断言 < 1.5×）；
* 变异（关掉续传同样夹具）：72704 = 1.775×，`< 1.5×` 必红（已实测）；
* 变异（去掉旧段摘要自证）：坏段被复用 ⇒ 51200 ≠ 40960 必红（已实测）；
* 变异（去掉总长比较）：旧大小的段被复用 ⇒ 61440 ≠ 40960 必红（已实测）。
 2026-11-13 06:26:18 +08:00
AskaEth f6cdbff885 test(download): 补强最后一跳 + 写明「抓得住/抓不住」（M292 r1） 
复审与塔的门禁在本 worktree 报了一条 `left: 120s / right: 300s`
（`changed_settings_reach_the_engine_config_and_the_budget`）。归因结论：**不是源码缺陷**，
是目标目录里跑到了不属于这棵树的 `unlucky_core` 测试二进制。本轮只做两件事：

## 1. 最后一跳补强（presenter）

`the_three_timeout_keys_travel_from_the_file_to_the_engine_config` 此前是自己拼
`tuning.apply_to(EngineConfig::default())`，即「调优 → 引擎」这一跳是**用例自己接的**，
守不住「宿主有没有把调优交给 core」。现在改走 GUI 的生产装配点
`crate::host::engine::engine(&env)`（内部 `apply_tuning` → `shared::set_tuning` → 按数据根重建），
断言读 `engine.config()`。这一步断了（宿主没调 `apply_tuning`、或 `shared` 装配点没用
`apply_to`），三条断言全红。

## 2. 用例文档写清边界（config/tests.rs）

`changed_settings_reach_the_engine_config_and_the_budget` 的文档补上返工取证：

- **抓得住**（三键逐一变异，删掉 `apply_to` 里对应赋值即红）：
  `response_timeout` ⇒ 278 行 `60s/180s`；`chunk_stall_timeout` ⇒ 279 行 `120s/300s`；
  `min_avg_throughput` ⇒ 280 行 `32768/16384`。另抓 `from_raw` 的 KiB→字节换算与
  `chunk_job_budget` 忽略下限。
- **抓不住**：①宿主有没有调用 `tuning`/`apply_to`（前半段归宿主用例）；②跑的是不是这棵树的
  二进制（编译期常量与代码内容都不在它视野里 —— 本轮就栽在这里）。

`config/tests.rs` 因此从 394 → 398 行（仍在 400 硬线内）。
 2026-11-13 04:06:42 +08:00
AskaEth 2ecb33afae feat(download): download.* 三个超时/阈值键接进 schema 与引擎（M292 2/2） 
P21 第 1 条：M289 的四个超时/阈值只挂在 `EngineConfig`，`DownloadTuning::apply_to` 只搬并发与
每源尝试次数 ⇒ 慢链路用户没有任何自救手段。出厂等价于「平均吞吐 ≥32 KiB/s 才活得下来」：
188MB 在 20 KiB/s 上要 160min > 100.3min 预算，必被杀；被杀后不再重试、不再换源，所以是
「下不完」而不是「慢一点」。

## 键（schema 1.9.0，新键推 minor）

| 键 | 默认 | 范围 | 落到 |
|---|---|---|---|
| `download.throughput_floor_kib` | 32 KiB/s | 4~4096 | `EngineConfig::min_avg_throughput`（×1024 → 字节/秒）|
| `download.stall_timeout_secs` | 120s | 30~600 | `EngineConfig::chunk_stall_timeout` |
| `download.response_timeout_secs` | 60s | 10~600 | `EngineConfig::response_timeout` |

三个默认值与 M289 的硬编码**逐值相等** ⇒ 不设 = 当前行为。上界（`MAX_*` 常量）就是「把挂住变成
无界」那道兜底：越界值在写入口被 schema 拒、引擎侧再回落一次出厂值。

## 通路

`RawTuning`（宿主只按 `KEY_*` 常量取裸值）→ `DownloadTuning::from_raw`（默认/区间/回落/KiB→字节
全在 core 一处）→ `apply_to` → `EngineConfig` → `stall::job_budget(total, floor, min_throughput)`。
`job_budget` 内部 `min_throughput.max(1)` 挡除零（设置层已拒 0，这是纵深防御）。

两个宿主都读六个键：`crates/cli/src/download.rs::tuning`、`presenter::host::settings::download::
tuning_of`。CLI 在**非出厂值**时往 stderr 打一行 `DownloadTuning::summary()`（`--dry-run` 也会经过
它；实测 `ull --data-dir … java install 21 --dry-run` 的 stderr 是
「下载调优：并发=8 单源尝试=3 吞吐下限=16KiB/s 无进展窗口=300s 单次请求上界=180s gh_proxy=跟随内置默认」，
出厂/非法值时一行都不打）。

## 文档口径（各只写一处）

- `stall.rs` 模块头：「改这几个数要付的代价」（调低下限换到的是「慢」不是「无界」；两档窗口是
  单次尝试的界，最坏要乘候选数×尝试次数）+「数字从哪来」改成「默认值 / 能不能改」+ 补上 P21
  第 3 条要的「`permit_timeout` 是按一次尝试反推，不是一个作业」。

## 两个纯搬移（为 400 行硬线）

- `config.rs` 423 → 261：`DownloadTuning` / `RawTuning` / `secs_in_range` / `impl` 整段搬到
  `config/tuning.rs`（194 行），`pub use tuning::{DownloadTuning, RawTuning};` 保住原路径；
  搬移块 172 行原样 diff = 0（无归一化）。
- `stall.rs` 440 → 343：测试搬到 `stall/tests.rs`（103 行），唯一变换是整体去 4 格缩进；两个
  未改动的用例函数体与 HEAD 逐字符（去空白）相同。

## 用例

core（`config/tests.rs` + `stall/tests.rs` + `keys/download.rs`）：默认值与 schema/引擎三处同源、
改设置 ⇒ 引擎配置与总期限都变、0 与越界回落且不除零、doc 里的数字、`summary()` 的生效值、键顺序。
cli：生产入口 `build_engine` 拿到三个新值 + `announce` 只在非出厂值时给行 + 非法值回落。
presenter：文件 → `tuning_of` → `EngineConfig` 三段一致 + 键名常量与 schema 登记绑定。
 2026-11-13 03:35:08 +08:00
AskaEth f4b5a73594 refactor(setting): download 四键纯搬移到 setting/keys/download.rs（M292 1/2） 
`keys.rs` 396 行、贴着全仓 400 行硬线，M292 要再加三个键 ⇒ 先纯搬移腾地方。

- 新增 `crates/core/src/setting/keys/download.rs`：并发 / 单源尝试次数 / 地区判定 /
  镜像偏好四条登记项，**逐字搬来**（唯一机械变换是 `.with(` 外壳换成 `vec![` 项、
  `))` 换成 `),` 定界符）。
- `keys.rs` 原地换成一行 `.with_all(download::specs())`，登记顺序不变。

逐字节证明（搬移块 28 行）：
  git show HEAD~1:crates/core/src/setting/keys.rs | sed -n '109,136p' \
    | sed -e 's/^        \.with(/        /' -e 's/^        ))$/        ),/' > old.txt
  sed -n '/^    vec!\[$/,/^    \]$/p' keys/download.rs | sed '1d;$d' > new.txt
  diff -u old.txt new.txt; echo $?   # 0

两条归一化规则都是**行首精确缩进锚定**：块内 `.with(` 只出现在四个项首、`))` 只出现在
四个项尾（各 4 处，与项数一一对应），所以它们不可能顺手改掉块内的真实差异。
 2026-11-13 03:20:00 +08:00
AskaEth 7d16317411 fix(m291): 守卫文档在 400 行内收（⑧ 并入 ⑦ 段，净增 0 行），make_dir_link 可见性收窄到 pub(super)（M291 r1） 2026-11-13 00:48:38 +08:00
AskaEth 375cc4f1fa test(presenter): junction 夹具改成逐段 join（带正斜杠的路径让 mklink 报无效语法，用例一直静默跳过），守卫补记 M291 变异（M291） 2026-11-13 00:31:14 +08:00
AskaEth bde6649aab fix(download): text_bounded 不再信 Content-Length 预分配，补两道内存闸；api/version 第四处裸 send 也上界（M290 r1） 
复审 r1（p2-1 / p3-1 / p3-2 / p3-5）返工，三处既有结论（send_bounded 逐字节未动、三个既有调用方
零改动、阶段只用两档）原样保留。

**p2-1 `http.rs::text_bounded` 的内存**（复审判据成立）：`Content-Length` 是「对面说了算」的数字，
拿它喂 `Vec::with_capacity` 等于让远端决定我们的内存，而分配失败是 abort、进不了 `Result`。
改成三道闸：
1. 头里声明 > `MAX_IN_MEMORY_BYTES`（64 MiB）⇒ 读完头立刻有界失败，**不预分配、不读正文**；
2. 容量只按真实到达增长（`Vec::new()`）；
3. 读循环逐块卡同一道上限（在累加前判，不会先撑过上限一块）。
两道闸的 `message` 分别说「声明的长度」与「内存上限」，`kind` 都是 `InvalidRequest` ⇒ 与超时
（`Timeout` + 阶段）可区分。

**p3-1 第四处裸 `send()`**：`game/java/api/version.rs::fetch_release_page` 原本
`client.get(url).send()` + `response.text()`、整文件 0 处 timeout（生产路径：`source::pinned` →
`api::fetch_version`）。改走 `http::send_bounded` + `http::text_bounded`，界是参数（生产
`http::default_deadlines()`，用例压到 200ms）。

**p3-2 `download/stall.rs` 模块头**：把「`game/java/api.rs`、`game/java/net.rs`、`update/github.rs`
是裸 `send()`——未审」这句假事实换成实测清单（谁已收、谁可以留、为什么留：`auth/http.rs` 自带
`.timeout`、`preflight.rs` 由 `check_with_deadline` 套住、`region.rs` 自带 3s），并给
`http::text_bounded` 补一行「入口/上界/阶段」。

**p3-5 doc**：删掉「与 `Response::text()` 的唯一差别是 charset 解码」这条过度披露——本仓 reqwest
没开 `charset` feature，`text()` 本来就是 `from_utf8_lossy`，解码逐字节等价；改成真实差别
（读空闲 + 内存上限）。

离线用例（全在 `#[cfg(test)]`，夹具 `game::java::net::probe` 新增 `Mode::Declared{declared,sent}`
与 `Mode::Flood(n)`，外加共用的 `bounded()` 护栏助手）：
* `api/version.rs::bounded_probes`：静默 ⇒ 阶段等响应头；正文停顿 ⇒ 阶段等字节；
  声明 `Content-Length: 999999999999` 且不发正文 ⇒ <2s 返回 `InvalidRequest` 且文案含
  「声明的长度」；不声明长度灌 65 MiB ⇒ 读循环在 64 MiB 处拒。
* `net.rs::tests` 的六条（4 条原有 + 2 条正常路径）改用同一个 `bounded()` 助手，断言一条未放宽。

变异实跑（贴红原文见 mission 报告）：
1. 退回 `Vec::with_capacity(declared)` 且删提前拒绝 ⇒ `memory allocation of 999999999999 bytes
   failed` + 进程 abort（0xc0000409），测试二进制消失——不是一条红；
2. 只删提前拒绝（预分配仍是 `Vec::new()`）⇒ 干净红：`left: Timeout / right: InvalidRequest`（0.21s）；
3. 删循环里的上限卡口 ⇒ 干净红：`expect_err` 拿到 `Ok("xxxx…")`（0.54s）；
4. `fetch_release_page` 退回裸 `send()` + `text()` ⇒ 两条 version 用例各在护栏 5s 处 panic（5.01s）。

门禁（真实退出码）：check=0 / lib=896 passed / game=120 passed / launch=91 passed /
engine_mock=17 passed / clippy -D warnings=0 / fmt=0。行数：http 389、stall 378、api 389、
net 390、version 397、github 363（全 ≤400）。
 2026-11-13 00:22:22 +08:00
AskaEth ad99303a95 fix(java/update): 三处模块外的一锤子 GET 也上界，失败时报出卡在哪一段（M290） 
`download_bytes`（M289）修掉之后，core 里还剩三处裸 `send()`，都在「拿上游文本/JSON」的
路径上：`game/java/api.rs::fetch_latest`（Adoptium latest）、`game/java/net.rs::get_text`
（四家发行版的一锤子 GET）、`update/github.rs::get_candidate_text`（更新清单）。上游接了连接
就装死时它们永不返回，与 M289 修掉的是同族形态。

改动（全部复用 M289 的构造点，没有第二套超时包装）：
* `download/http.rs` 新增 `text_bounded`（正文按 `read_step` 的空闲判定读成 `String`，与
  `bytes.rs` 的读循环同口径）与 `default_deadlines()`（取 `EngineConfig::default()` 的两段界，
  不另抄秒数）；`send_bounded` 的签名逐字节未动，`transfer.rs`/`chunked.rs`/`bytes.rs` 三处
  调用方零改动。
* 三处一律 `send_bounded`（等响应头）+ `text_bounded`（等字节）：失败时 `message` 里带
  `StallReport` 的阶段（`await_headers` / `await_bytes`）与已收/预期/无进展三个数。
  这三条路径只用到这两档：没有分块回收、也没有引擎许可等待，所以 `await_chunk_join` /
  `acquire_permit` 不适用。
* `update/github.rs` 的界取 `engine.config().deadlines()`（手里有引擎就不抄默认值）。

正常路径零改变：`fetch_latest` / `get_text` 的公开签名与错误分类一字未动（`fetch_latest` 的
404 文案与 hint 保留），`update` 的 `github_cases` 全部断言未改。

离线用例（`game::java::net::tests`，6 条；夹具 `net::probe::Hanging` 也是 M290 新增）：
silent 服务端 ⇒ 引擎自己在 200ms 上界内返回（外层 5s 护栏没触发），并断言 message 含
「等响应头/await_headers」；正文停住 ⇒ 「等字节/await_bytes」；200 + 真 JSON ⇒ 正文逐字节
原样（含中文）。变异已实跑：`send_bounded` 退回裸 `send()` 三处各自在外层 5s 处挂断；
`text_bounded` 退回 `response.text()` ⇒ 等字节用例 5s 挂断；正文改成空串 ⇒ 正常路径用例红。

门禁：cargo check（core+cli, --all-targets）/ test --lib（892 passed）/ --test game（120）/
--test launch（91）/ --test engine_mock（17）/ clippy -D warnings / fmt --check，退出码全 0。
 2026-11-13 00:22:21 +08:00
AskaEth d6f862a43c fix(download): 补齐 download_bytes 与等许可两处无界 await，预算耗尽不再重试（M289 r1） 
r1 复审 p2-1：`stall.rs` 那句「全仓只有两处无界 await」是假话。真实清单五处，
M289 之前只修了两处；这次补齐：

* `bytes.rs::fetch_bytes` 的 `send()` 改走 `http::send_bounded`（与文件下载同一个构造点）；
  整包 `response.bytes()` 换成 `bytes_stream` + `http::read_step` 的空闲判定，并边读边卡
  `MAX_IN_MEMORY_BYTES`（`Content-Length` 可缺失/可撒谎）。生产调用点：版本清单、
  版本 JSON、Modrinth 元数据。
* `engine::acquire` 的 `acquire_owned()` 加上界（`EngineConfig::permit_timeout`，默认
  120min ≥ 单个作业总期限），到点报新阶段 `StallStage::AcquirePermit`（「等许可」），
  不冒充「服务器不给数据」。这就是「卡死作业攥着许可把队列堵死」的连坐形态。
* `stall.rs` 模块头改成一张「哪些入口有界、谁托管给谁」的表，并写清五处 await 的真实清单。

r1 复审 p2-2：总期限用完是链路级判决，不再按满预算重试/换源：
* `DownloadError::job_budget_exhausted()` + `DownloadError::is_retryable()`（覆盖
  `kind.is_retryable()`），引擎与 `download_bytes` 都改用它；
* 引擎在预算耗尽时直接结束候选循环，不再换源（同一份字节、同一条链路，换源只会再
  烧满一整个预算）。188MB/20 KiB/s 的用户不再从「1.6 小时慢慢下完」变成「几小时反复重下」。
* `stall.rs` 写明「慢链路照样活」的前提 = **平均吞吐 ≥ 32 KiB/s**，以及它挡掉哪类链路；
  `download.*` schema 接线留给另一个 mission（`setting/keys.rs` 不在 scope）。

顺带（复审 p3）：
* `transfer.rs` 的读空闲统一走 `EngineConfig::deadlines()`（不再各读字段）；
* `verify_part` 补一条代价说明：`spawn_blocking` 到点不可取消，可能让同名重建拿到
  `Access is denied`（**该假设未验**，注释里已标）；
* `engine.rs` 因这轮新增又贴到 410 行 ⇒ `finish` / `materialize` / `millis` 逐字节搬到
  `engine/finish.rs`（`engine::millis` 路径用 `pub(crate) use` 保持可用）。

新增用例（全离线、<2s）：`download_bytes` 静默服务端 / 正文中途卡住、等许可超时、
预算耗尽不重试（`max_attempts_per_source = 3` 下仍只发一轮）、预算耗尽不换源
（官方源 `hits == 0`）。
 2026-11-12 23:24:19 +08:00
AskaEth cc0def3415 feat(download): 给每条下载 await 上界并在超时时报出「卡在哪一段」（M289 / P19） 
全仓下载路径此前只有两处无界 await（分块与单连接的 `send()`），reqwest 自己的
`timeout` 又是 `None`：服务器接了连接不回一个字节 ⇒ future 永不结束，
`ull java install` 那条 `silent()` 路径零事件零日志，用户只看到「卡住不动」。

上界选「单次请求 + 读空闲」，**不是**「整作业总预算」：
* `region.rs` 的 3s 是探测极小响应（整作业 = 一次 GET，两者同一件事）；
* `font.rs` 的 ATTEMPT/TOTAL 是几百 KB 的字体（整作业几秒就完）；
* 188MB 的 JDK 两者都不能照抄，所以分三段互不顶替的界，理由与取数**只写在**
  `crates/core/src/download/stall.rs` 模块头一处（含「别改成 reqwest 的 timeout，
  它覆盖整个响应体读取」）。

改动：
* 新增 `download::stall`：`StallStage`（连接 / 等响应头 / 等字节 / 等分块回收 / 校验）+
  `StallReason`（期限用完 / 没有新字节）+ `StallReport`（阶段 + 已收 / 预期字节 +
  无进展时长）+ `job_budget`（总期限按 32 KiB/s 平均吞吐反推）。
* `http::send_bounded` / `http::read_step`：两处 `send()` 与两处读循环的**唯一**构造点；
  超时错误带阶段与三个数，`message` 里也抄一份（整体失败时 `suppressed` 只搬 message）。
* `transfer_chunk::await_chunks`：`JoinSet::join_next` 加总期限与无进度窗口，两者靠
  `StallReason` 分开报；窗口内有新字节就续期（慢但有效不误杀）。
* `verify_part` 挪到 blocking 池并套上界：校验阶段卡住也报得出来（阶段=校验）。
* `engine.rs`：整体失败时把**最后一次**尝试的失速现场带上去，并写进用户可见的那行字。
* 配置：`response_timeout` 60s / `chunk_stall_timeout` 120s / `chunk_job_floor` 10min /
  `verify_timeout` 120s（`EngineConfig`，未动设置 schema）。

测试（全离线、`127.0.0.1`、<2s）：夹具新增 `silent()` / `stalling_after` / `short_body` /
`oversize_body` / `dripping`；用例覆盖静默服务端、中途卡住、短包、超长包、慢但持续
（4 倍于上界也要成功）、超时后引擎仍能下载（RAII 许可自还，不写手动归还）、以及分块
作业的「无进度 vs 总期限」两条。

另：`config/tests.rs` 的一处表达式在去缩进后行宽变化，随本 commit 由 rustfmt 合成一行
（纯搬移 commit 提交时它仍是逐字节原文）。
 2026-11-12 23:24:19 +08:00
AskaEth 61c8a4eff9 refactor(download): 纯搬移为 M289 腾出行数余量（config 单测 / engine 只读查询面） 
两个文件都是 400 行零余量的硬线，本 mission 要加超时字段与失速诊断，先纯搬移：

* `config.rs` 的 `#[cfg(test)] mod tests`（174 行）→ `config/tests.rs`，
  原文件用 `#[cfg(test)] #[path = "config/tests.rs"] mod tests;` 声明；
* `engine.rs` 的七个只读 getter（`config` / `concurrency_probe` / `client` /
  `region` / `mirrors` / `health` / `cache`，44 行）→ `engine/inspect.rs`。

逐字节未改：搬移块去缩进后与 HEAD 原文 `diff` 均为 exit 0。

行为零变化（同一批测试仍全绿）；新文件都在 `crates/core/src/download/**` 内，
外部路径（`download::config::EngineConfig` 等）不变。
 2026-11-12 23:24:18 +08:00
worker-javapin a0aeccf303 fix(java): 把「这一页不存在」与「这一页读不懂」分开，解析失败不再被当成翻到尾巴（M280 r3） 
r3 复审 p2-1items：r2 的吞判据按 `JavaErrorKind` 判，而 `Metadata` 这个桶里除了
404/410 与 200+空体，还装着**解析失败**（`parse_release_list`）⇒ 第二页起上游回
「看得懂的状态码 + 读不懂的内容」时，清单被静默截断且标成 `Complete`，用户看到的是
「这个 major 没有版本 X（可用：…）」，而 X 其实在上游。

## 修法：语义信号代替错误种类（复审判据里没选字面方案，选了改动面最小的等价实现）
`fetch_page` 的返回类型变成 `Result<Option<Vec<String>>, JavaError>`，`None` 只由
**新的纯函数 `page_outcome(status, body)`** 产生：404/410 或 200+空体。判据是状态码 +
体形状，**不匹配任何错误文案**。

- `page > 0` 的 `None` ⇒ 翻到尾巴：交回已取到的全部，`truncated = false`（r2 已做对，保留）；
- `page == 0` 的 `None` ⇒ 这个大版本真没有 GA 清单：仍然 `Err`（与 r2 之前同口径，
  只是判据从「错误种类」换成「哪一页不存在」）；
- **任何页的解析失败 / 非 2xx 非 404 / 网络错误 ⇒ 一律 `Err`**（不再有「读不懂 ⇒ 没有更多」）；
- 错误落在最后一页也是 `Err`，不可能再报 `Complete`。

`api/version.rs` 里新增 `page_outcome`（纯）+ `fetch_release_page`（HTTP 那一跳，判定全交给前者），
`fetch_version` 的闭包改调 `fetch_release_page`。只动本 mission scope 内的两个文件，
没有改 `net.rs`，也没有给跨 crate 匹配的 `JavaErrorKind` 加变体（cli / app-iced 的 match 不变）。

## 用例（离线；每条都有能变红的变异）
- `a_missing_page_after_a_full_page_ends_the_tail_cleanly`（判据 1）：page0=20 条、page1=None
  ⇒ `Ok((20, false))`，逐条相等、`calls == 2`；
- `a_missing_page_is_404_410_or_an_empty_body_and_nothing_else`：404/410/200+空白 ⇒ `None`；
  正常 JSON ⇒ `Some(names)`；`<html>502</html>` ⇒ `Err(Metadata)`；500/403/429/502 ⇒ `Err(Network)`；
- `a_parse_failure_on_a_later_page_is_an_error_not_the_end_of_the_list`（判据 2）：夹具用**真的**
  `parse_release_list("<html>502</html>").unwrap_err()` ⇒ 必须 `Err`，且报的是解析失败本身；
  `Err` 分支在签名上就带不出部分结果；
- `an_error_on_the_last_allowed_page_is_never_reported_as_complete`（判据 3）：错误落在
  `page == MAX_PAGES-1` ⇒ 必须 `Err`，不许 `Ok((_, false))`；
- `a_missing_first_page_is_still_an_error`：第一页就不存在 ⇒ `Err`；
- `a_network_error_on_a_later_page_is_not_swallowed`：网络错误照抛。

变异（做完都还原，`git status` 干净）：R3-A 把 page>0 的 None 当失败 ⇒ 判据 1 那条红；
R3-B 把 Metadata 重新并进吞掉的分支 ⇒ 判据 2/3 两条红（panic 原文就是 `(…20 条…, false)`，
即复审实测的那个 bug）；R3-C 把 `page_outcome` 的解析失败并成 `None` ⇒ 底座那条红。

## 顺带两条（复审 P3）
- P3-1：报告里「钉住上游越界页就是 404」那句改成正确表述（夹具手写，钉的是「收到『这一页
  不存在』要把已取到的交出去」）；`--lib` 数字按 tip 重数（`aac0eef` 上是 880，本轮 +3 ⇒ 883）。
- P3-2：删掉 `catalog/tests.rs` 里冗余的否定式断言（紧邻的正向断言已蕴含它），
  保留两条正向断言（`Adoptium 里可用` / `Oracle 镜像目录里可用`）。

门禁（CARGO_TARGET_DIR=C:/Temp/ull-target/wt-280）：core --lib 883 / --test game 120 /
--test launch 91、cli --all-targets、fmt --check、clippy -D warnings 全部 EXIT=0。
 2026-11-12 22:34:07 +08:00
worker-javapin aac0eef1b8 fix(java): 越界页 404 不许作废已取到的清单 + 三处文档/文案（M280 r2） 
r2 复审 p2-1items / fix-then-merge，只做指定的四项。

## P2-1 满页收尾会多打一页 404，把前几页一起丢掉
`collect_releases` 原来靠「本页不满 PAGE_SIZE」收尾；某条 GA 线的条数恰好是 20 的倍数时
最后一页是满页 ⇒ 会多要一页 ⇒ Adoptium 对越界页回 **HTTP 404 + 空体**（实测，不是空数组）
⇒ 那一页的 Metadata 错误把**已经取到的前几页**一起作废，整条 `--version` 路径失败。

- `page > 0` 的 Metadata（404 / 空响应）视为「翻到尾巴」：返回已取到的全部 + `truncated=false`；
- `page == 0` 的 404 仍然报错（那才是「这个 major 没有 GA 清单」）；
- **网络错误**（`JavaErrorKind::Network`）在任何一页都不被吞，照样冒泡。

用例（全离线，注入夹具）：
- `a_404_on_the_page_after_a_full_page_ends_the_tail_cleanly`：page0=Ok(20 条)、
  page1=Err(Metadata 404) ⇒ 断言 `Ok((20 条, false))` 且 `calls == 2`（把「今天上游越界页就是 404」钉住）；
- `a_404_on_the_first_page_is_still_an_error`：page0 就 404 ⇒ 必须 `Err`；
- `a_network_error_on_a_later_page_is_not_swallowed`：page1 网络错误 ⇒ 必须 `Err`。

## P3-1 `install/plan.rs` 文档与事实矛盾
改成如实描述：搬移的直接原因（400 行硬线）+ **三处语义变化**（签名接 `&InstallRequest`、
函数体改走 `chain_fetch` 与 `install` 共用同一份判据、`request.priority` 现在参与选择顺序）。

## P3-2 `api.rs` 头注释
补一句：latest 那条走本模块，「指定版本」走子模块 `version`（`feature_releases` 翻页枚举 →
`assets/release_name`），两者共用同一套响应结构。

## P3-3 Oracle 拒绝文案多一个空格
`source` 自带连接词（`Adoptium 里` / `Oracle 镜像目录里`），模板改成 `（{source}可用：…）`。
真机：`（Oracle 镜像目录里可用：21.0.2 / 21.0.1 / 21）`、`（Adoptium 里可用：… 等 26 个）`。
用例补三条断言钉住这两种拼法，并断言 Oracle 那句不许出现「镜像目录 里」。

门禁（CARGO_TARGET_DIR=C:/Temp/ull-target/wt-280）：core --lib 873 / --test game 120 /
--test launch 91、cli --all-targets、fmt --check、clippy -D warnings 全部 EXIT=0。
 2026-11-12 22:05:19 +08:00
worker-javapin 1353c044c3 fix(java): Temurin 指定版本要翻页 + 三层「不静默回落」补上守卫（M280 r1） 
复审 r1 判 p2-2items / fix-then-merge。两条都在这轮修掉。

## P2-1 Temurin 只读第一页 ⇒ 上游有的版本被报「没有」
`page_size` 上限 20 是上游硬约束，但 8/11/17 线各有 26 条 GA（实测 17/ga page=0 回
20 条、page=1 回 6 条）。原来只读第一页，`17.0.4` 这种「上游有、第一页没有」的版本
被报成「没有这个版本」，而且「等 20 个」是我们的窗口而不是上游总数。

- `releases_url(major, target, page)` 带页码；`collect_releases(fetch_page)` 是**纯**骨架
  （分页由闭包注入），翻到「本页不满一页」为止，上限 `MAX_PAGES = 5`；
- `fetch_version` 用 `pick_release(&releases, wanted)` 挑（不取最新、不取第一条）；
- 文案：`catalog::VersionListScope::{Complete, Truncated}` +
  `available_versions_text(.., scope)`。完整时说「等 N 个」（= 上游总数），
  到上限时才说「只查了前 N 条，后面可能还有」——不再把窗口当全集。
- 真机复现（复审给的命令）：`17 --version 17.0.4` 现在命中 `17.0.4+8`；
  `17 --version 17` 命中第二页最后一条 `17+35`；`17 --version 17.0.99` 报「等 26 个」。

## P2-2 三层保证一条守卫都没有（复审的变异 A/B/C）
现在每条都有能变红的用例：

| 守卫 | 位置 | 用例 |
| --- | --- | --- |
| Temurin 命中而非取最新 | `api/version.rs::pick_release` | `the_pinned_version_wins_over_the_newest_entry` + 两页用例 |
| 兜底闸（版本必须对上） | `catalog::version_mismatch` | `catalog/tests.rs::the_version_gate_rejects_...` |
| 装配层的「记失败继续走链」 | `install/chain.rs::resolve_one` / `chain_fetch` | `a_release_that_is_not_...`、`a_mismatch_records_a_failure_and_the_chain_moves_on`、`nothing_matching_...` |
| 钉死一家不换家 | `install()` 全链（`--vendor zulu --version`） | `a_pinned_vendor_that_cannot_pin_is_tried_alone`（断言「试过 1」+ `latest=true` + 一个字节没落盘） |

`install` 的循环与 `--dry-run` 的 `plan` 现在**共用同一份判据**（`resolve_one`）：
`install` 逐家调它，`plan` 用 `chain_fetch` 驱动整条链。

## 拆分（守 400 行硬线）
- `catalog.rs` 400 → `catalog.rs` 278 + `catalog/tests.rs` 229（既有 7 条用例搬走，
  唯一差异是新 API 的 `VersionListScope::Complete` 参数）
- `install.rs` → `install/plan.rs`（`plan` 段落；文档与签名原样，函数体改成走
  `chain_fetch`，这正是「同一份判据」的要求）+ `install/chain.rs`（新骨架与守卫，
  `install.rs` 361 行）
- `api/version.rs` 417 → `api/version.rs` 214 + `api/version/tests.rs` 207

## 门禁（CARGO_TARGET_DIR=C:/Temp/ull-target/wt-280）
core --lib 870 / --test game 120 / --test launch 91、cli --all-targets、fmt --check、
clippy -D warnings 全部 EXIT=0。
 2026-11-12 22:05:19 +08:00
worker-javapin 9fded45d9e feat(java): --version 指定 JDK 版本（Temurin/Oracle 能，MS 只认快照，Zulu 报错）+ --dry-run（M280） 
用户原话：「我们内置了那么多镜像源 甚至用户不能手动选择指定版本下载。」这条之前
`InstallRequest` 根本没有版本字段，四家全是「该 major 最新 GA」。

core：
- `InstallRequest.version: Option<String>` + `with_version`；`None` 时仍走 `source::fetch`
  的老路径（`latest_url` / `parse_latest` / `fetch_latest` 一个字节未动）。
- `source::fetch` 在唯一分派点按 `Option<&str>` 分两路：`latest` 与 `pinned`，后者绝不换家。
- Temurin（新 `api/version.rs`）：先 `assets/feature_releases/{major}/ga` 枚举（`page_size`
  上限 20），把用户给的公共版本号翻成 release 名，再打 `assets/release_name/eclipse/{name}`
  取归档——不走 `latest`。实测 `/v3/assets/version/{v}` 在线上回 404，故不用它（见报告）。
- Oracle：`versions_for` 接进选择路径（`select_version`），`None` 仍是 `pick_version`。
- Microsoft：只认写死快照里那一个版本号，别的版本明确报错并说清「这家不能自选版本」。
- Zulu / Termux：上游只有 latest / 版本由系统包定 → 明确报错，不回落、不换家。
- `catalog.rs` 收策略：`matches_version`（唯一相等判据，不做前缀近似）、
  `version_pin_error`（四家文案互不相同且各自说清原因 + 下一步）、`version_mismatch`
  （兜底闸：装到的版本必须真是用户要的那一版）。
- `plan()` 改成接 `&InstallRequest`，`--dry-run` 与真装走同一条选择路径。

cli：
- `java install <major> [--version V] [--dry-run] [--vendor X]`；`--json` 增 `requested_version`。
- 全局 `--version` 只在子命令之前成立，否则 `java install 21 --version 21.0.13+9` 会被
  当成「打印启动器版本」吞掉。

拆分（守 400 行硬线，均为纯搬移 + 逐字节核对）：
- `api.rs` → `api/version.rs`、`oracle.rs` → `oracle/listing.rs`（纯的那一半）、
  `cli/parse.rs` → `cli/parse/java.rs`、`commands/java.rs` → `commands/java_install.rs`。

门禁（CARGO_TARGET_DIR=C:/Temp/ull-target/wt-280）：core --lib / --test game / --test launch、
cli --all-targets、fmt --check、clippy -D warnings 全部 EXIT=0。
 2026-11-12 22:05:17 +08:00
AskaEth 23e98635dd feat(core): JDK 发现补 Microsoft 注册表支（HKLM\SOFTWARE\Microsoft\JDK\*\MSI\Path）（M281） 
`registry_homes()` 原来只读 `HKLM\SOFTWARE\JavaSoft\JDK`，而 MS JDK 的 MSI 把安装路径
登记在 `HKLM\SOFTWARE\Microsoft\JDK\<ver>\<flavor>\MSI` 的 `Path`（本机 21/25 两条，
JavaSoft 那个键在本机根本不存在）。装在自定义目录（不在 Program Files 下）的 MS JDK
因此漏扫——Program Files 那支兜住的只是默认位置。

- 新增 `parse_msi_paths()`：判据是「当前键尾段叫 MSI」（不数层数），多一层/空层都认；
  同键里的 `JavaHome REG_DWORD`、非 MSI 键下的 `Path`、值名不是整段 `Path` 的都不认。
- 注册表读取改为可注入：`RegSource` trait + `ProcessReg`（真 `reg.exe`），
  `registry_homes_from(&dyn RegSource)` 让单测喂真实 `reg query` 输出样本，不依赖本机。
- 两个键 × 64/32 两个视图各查一遍，与 JavaSoft 那支同口径；键不存在照旧静默跳过。
- `scan_java_binaries()` 拆出 `java_binaries_in(roots, homes)`：注入式验收可以屏蔽
  Program Files / PATH / JAVA_HOME，只走注册表；去重改用仓库既有的 `path_key` 口径
  （末尾反斜杠、`\?\` 前缀、大小写都不会重复列）。
- 注册表这支整体搬进 `discover/registry.rs`（`mod registry;` + `pub use`，
  `discover::registry_homes` / `parse_java_home` 公开路径不变，`mod.rs` 一行未动）。
 2026-11-12 20:19:23 +08:00
AskaEth 686dd9335a test(core): mtime 探针改用显式 set_modified，update-e2e 失败升注解（M275） 
tree_snapshot_sees_new_nodes_and_mtime_changes 的「同内容重写」时间维度断言在
Windows/NTFS 上不可靠：同一系统时钟 tick 内的两次写、或时间戳只在句柄关闭时按
粗粒度落盘，都会让 mtime 与写之前逐字节相同 —— main 上 test (windows-latest)
偶发红在这行 assert_ne!（check-run 130965734990）。改成显式时间戳：
File::options().write(true).open + set_modified(基线 + 5s)，值由测试指定、
与 tick/落盘粒度无关；不用 sleep、不用重试。用例原本的目的（快照必须看得见
mtime 变化）保持不变，另附 4s 下界断言把「我们推的那一下」与 stat 抖动分开。

ci.yml 的 update-e2e 步骤原本是裸 cargo test，失败只留一句 exit code 1、
check-run 上零注解，匿名侧等于信息为零。改成与 test 作业同款：pwsh +
Tee-Object 存 $RUNNER_TEMP 日志、失败把 panicked at / error / test result:
FAILED / failures: 行以 ::error:: 输出（% → %25）、打印并 exit $LASTEXITCODE
（cargo 真码，不是 Tee 的码）。步骤名 update-e2e 与 --test update_e2e_test
逐字保留（check_test_source_off.py 的 ALLOWED_STEP 钉死这两点）。

行数不变（ci.yml 397 → 398，≤400）：注释块等价压缩腾出的行给运行时逻辑。
 2026-11-12 18:44:51 +08:00
AskaEth 150243e0b6 fix(core): listing() 与唯一调用点同 gate #[cfg(windows)]，消掉 Linux 上的 dead_code 
CI 的 clippy (ubuntu-latest) 退出码 101 的唯一首因：
  error: function `listing` is never used
   --> crates/core/tests/adopt/surface_cases.rs:147:4
  note: `-D dead-code` implied by `-D warnings`

`listing()` 的 4 处调用（43/65/69/73 行）全部落在 `#[cfg(windows)]` 的
`a_junction_on_the_instances_dir_must_not_write_into_the_game_root` 里，helper 本身没 gate
⇒ Linux 上调用点整块编掉，helper 变死代码；Windows 上跑不出来（本地一直绿的原因）。

最小改法：只给 helper 加 `#[cfg(windows)]`，与调用点对齐（同仓既有写法见
tests/launch/watchdog_cases.rs 的 `chatty_lines()`）。不删用例、不改断言、不给整个 mod 加
cfg、不用 #[allow(dead_code)] 静音。

验证：Linux 容器 ull-linux-check:bookworm 上 cargo clippy --workspace --all-targets
-- -D warnings；Windows 上 cargo clippy -p unlucky-core --all-targets -- -D warnings
且 adopt 测试清单仍有那条 junction 用例（4 处调用仍在编）。
 2026-11-11 22:57:43 +08:00
AskaEth d4959fd3d3 test(m262): 三条平台/时序依赖的测试改成确定性判据 
① prefs.rs：custom 落点不再写死 D:/JDKs（Linux 上它是相对路径，会被拼到数据根后，
   同一条断言在两个平台上验的是两件事）。改由临时目录给绝对路径；另加一条相对路径
   必须按数据根解析的断言，把上一版抓不住的那一半补上。
② fonts/tests.rs：install::status() 读的是进程级静态槽，同 binary 的 page_messages
   用例切 zh_cn 会真的发起下载并把它写成 Downloading ⇒ 前后快照比较与谁并行谁赢。
   改成用 current_exe() 在**只有本用例的进程**里量，并断言前后逐值相等（任何写槽都算越界）。
③ fixture_cases.rs：目录 mtime 不再赌「写文件恰好落在另一个 tick」，改为显式钉 mtime
   （t0/t1 整秒，对任何 filetime 粒度无余数）并逐 ns 比对。

三条都补了「抓得住什么 / 抓不住什么」。
 2026-11-11 22:41:06 +08:00
AskaEth 00965e19d2 fix(core): trust.rs 的 PinnedKey 交回 rustfmt 排版（多行字段）+ 自测锁住多行解析 
v0.2.4 推 main 后 CI 的 fmt job 红：cargo fmt --all --check 退出码 1，唯一 diff 在
crates/core/src/update/trust.rs:60 —— PRODUCTION 里那条 PinnedKey 被写成单行。

* trust.rs：由 `cargo fmt --all` 直接生成（不是手写对齐）。git diff 只有这一处；
  两个 PINNED-KEYS 标记行的字形与行位置未动；public_key_hex 与 HEAD 逐字比对 identical。
* sign_manifest.py --self-test：补一条多行（rustfmt）形态样例的解析断言。解析器本身无需改
  （KID_RE 字段之间是 \s*，本来就跨行），但旧自测只喂单行样例 —— 变异重放（换成单行整行正则）
  时旧自测全绿、新断言红，正是这次事故的形状。

验证（真实退出码）：cargo fmt --all --check = 0；python packaging/sign_manifest.py
--check-pinned-keyring --key <私钥路径> = 0；signing_ready_selftest.py = 0；
signing_ready_wiring_selftest.py = 0；sign_manifest.py --self-test = 0；
cargo test -p unlucky-core --lib update = 0（114 passed / 0 failed）。
 2026-11-11 22:01:26 +08:00
AskaEth 68362e5408 feat(core): 钉入生产签名公钥（key_id ull-release）+ .gitignore 防私钥入库
Guards / 依赖许可与来源（cargo-deny） (push) Canceled after 0s
Details
Guards / 文件行数 ≤400 守门 (push) Canceled after 0s
Details
Guards / unsafe 落点守门（集合必须恰好等于期望） (push) Canceled after 0s
Details
Guards / design 零第三方依赖守门 (push) Canceled after 0s
Details
Guards / presenter 零 UI 守门 (push) Canceled after 0s
Details
Guards / core 零 UI 守门 (push) Canceled after 0s
Details
Dev Guards / 架构与合规守门（同 main 口径） (push) Canceled after 0s
Details
GPU evidence / GPU 证据 — 真实产物判据 (push) Canceled after 0s
Details
GPU evidence / GPU 证据 — 探测可用产物与硬件适配器 (push) Canceled after 0s
Details
GPU evidence / GPU 判据自测（不需 GPU；跳过 ≠ 已验证） (push) Canceled after 0s
Details
Dev Guards / GPU 证据门禁（同 main 口径；无 GPU 只跑自测） (push) Canceled after 0s
Details
Dev Guards / fmt (rustfmt --check) (push) Canceled after 0s
Details
Dev Guards / clippy (ubuntu) (push) Canceled after 0s
Details
2026-11-11 21:35:10 +08:00
AskaEth e6b2200360 feat(app-iced): 强调色接线落地（M250 ACCENTWIRE） 
appearance.accent_color 此前是死线：配置键、presenter 往返、预设色板都在，但造 tokens 的
唯一入口恒走 DesignTokens::brand(board)，用户填了色界面不变。

- theme.rs：Ui::with_accent + accent_scheme（唯一调用 DesignTokens::with_accent 的地方）
- app/state/theme.rs：rebuild_ui 三选一（显式强调色 > D38 取色方案 > 出厂板），diag 一行说清是谁生效
- pages/appearance：新增 accent 状态（原文/解析结果/方案/结构化错误）+ 设置页输入行与预设色块；
  非法值保持上一次合法值并给出 Short/Long/Digit 三档原因，不静默回退出厂色
- presenter::prefs：AccentChoice::parse 成为唯一解析点，set_accent_checked 交回结构化原因
- app/appearance.rs：persist_appearance 带上 accent_color（此前写不进去），只写上一次合法值
- pages/harness/app.rs：gallery 也能吃 ULL_APPEARANCE_ACCENT，供出图矩阵
- core keys.rs：订正「空 = 出厂 #0078D4；accent 令牌全域生效」这句半真半假的说明
- i18n：强调色 7 条文案（链尾新域，金表只追加）

判据：同一组件（进度条 Primary）在空配置与 #006A5C 下色值不同（App 级 + 令牌级两条）；
非法值拿到结构化错误、生效色不回退、不写盘、tokens 仍可构造。
 2026-11-11 14:56:26 +08:00
AskaEth c921b9c185 feat(core,presenter,app-iced): 存档三个写操作（重命名 / 删除 / 备份）+ 行操作区（M247 SAVESOPS） 
core::game::saves 新增 write 模块，三个入口的第一句都是 boundary::guard：

- rename_world：saves/<old> → saves/<new>，撞名/同名/非法名字各自具名拒绝
- delete_world：递归删（不跟随符号链接、层级上限 64），先过边界校验
- backup_world：流式 zip（限额预检 → 临时文件 → 原子改名），
  <世界名>-YYYYMMDD-HHMMSS.zip，撞名顺延，绝不覆盖上一份

guard 三道判据（每次写前重做，不信任调用方）：名字必须是单段裸名字；
saves/ 必须是运行目录的真实直属子目录；世界目录必须是 saves/ 下的真目录
（解析后比父级，不比字符串前缀）。落点目录要求绝对路径（相对路径会落到进程 CWD，
实测过一次）。

presenter：SavesCommand 增 RenameWorld/DeleteWorld/BackupWorld，host 三个后台入口
写成功后重新列一遍目录并把「回执」挂在快照上（SavesOped：改名两端 / 被删的名字 /
备份落点+字节数+跳过的链接数）。SavesFailureView 增 file 与 op，写失败八类一一对应。
SavesState 增 draft / pending / confirm 三样交互态（草稿是行内输入缓冲，
pending 与 ModsState::pending 同一条先例，confirm 是删除确认框在等谁）。

app-iced：世界行右侧重命名/备份/删除；行内输入框改名（现成模态队列没有「输入变了」
这一条消息，用输入模态等于重写一套）；删除走现成 modal 的 Confirm，主按钮落点接在
app/update/dialog.rs。回执行画在卡片里（备份落点看不见就是静默失败）。

i18n：新增 25 条中英成对 key + 金表同步；删掉 M235 的「这一版只读」那条（写操作接上
之后它是假的）。出图夹具 ULL_SAVES_FIXTURE=rename|confirm|backed-up 三种形态。
 2026-11-11 13:29:56 +08:00
AskaEth c97ec293c3 test(core): 「哪些键真的交给日志」补自动化证据（M244 r2 P2-1） 
复审 P2-1：旧用例只断言 `collect_fresh`（纯函数）与 `unknown_keys()`（表级清单），
没人断言 `report` **真的**只把「新键」交给 sink；把 `for key in fresh` 改成
`for key in unknown`（每次渲染重复写日志）当时 6 条用例全绿，而「同键只报一次」正是判据 ③。

- `report_with(&self, unknown, sink: impl FnMut(&str))`：`report` 变成
  `report_with(unknown, emit)`，`emit` 仍是 `cfg(test)` 空实现（不碰进程级单例，flake 不回潮）；
- 新用例 `report_emits_only_fresh_keys`：假 sink 收集，断言一次渲染内重复只交一次、
  跨渲染只有新键才交、顺序与 `collect_fresh` 一致；
- 顺手收掉自己列的边角：`unknown_log_line` 先把键名里的 `\r`/`\n` 换成空格
  （`launcher.log` 是行导向的，恶意清单塞换行能把一个键变成两行假日志），
  新用例 `log_lines_never_break_into_two_lines`。

变异自证（各自 exit 101，均已还原、文件 sha256 复原）：
- `for key in &fresh` → `for key in unknown` ⇒ `report_emits_only_fresh_keys` 红，
  `left: ["a", "a"] right: ["a"]`；
- 删掉 `key.replace(['\r','\n'], " ")` 那一行 ⇒ `log_lines_never_break_into_two_lines` 红，
  `left: 2 right: 1`。

门禁：fmt / check -p unlucky-core --all-targets / test -p unlucky-core -p unlucky-cli
（1678 passed / 0 failed）/ clippy --workspace --all-targets -- -D warnings 全绿。
 2026-11-11 11:32:27 +08:00
AskaEth 60607ae7b3 feat(core): 未登记占位符不再静默（M244 PLACEHOLDERWARN） 
`PlaceholderMap::render` 一直把未登记的 `${key}` 原样写回 argv，运行期零校验零告警：
第三方 version JSON 里一个拼错的占位符会原样进 `cmd_built.argv` / `--dry-run`，
用户只看到一个 `${xxx}` 和零解释（M239 REDACTAUDIT §5.2 的机制风险）。

- `render_tracked` 返回 `RenderOutcome { text, unknown_keys }`，未登记键去重保序；
  `unknown_keys()` 交表级全量清单，供后续接 `AssemblyWarning` / `--dry-run`。
- `render` 在此之上把每个**新**见到的键写一行 `launcher.log`（进程级去重，一个键一次启动
  只报一次）；未登记键仍原样保留，argv 逐字节不变（第三方清单兼容性优先）。
- 大小写/首尾空白变体按**不同的键**处理（替换本来就是精确匹配），日志行对近似已登记键的
  附「疑似 ${known} 的笔误」提示。
- 测试构建里 `emit` 是空实现：`launcher_log` 是进程级单例，lib 用例并行跑时会把它自己的
  `buffer_is_bounded_before_the_dir_is_known` 顶红（实测 205 行）；行文本与「哪些键该记」
  分别由 `unknown_log_line` / `collect_fresh` 的用例覆盖，落盘用一次性探针手工验过。

变异自证：把 `note_unknown` 改成空实现 ⇒ 5 条新用例红（exit 101），还原后绿。
门禁：fmt / check -p unlucky-core --all-targets / test -p unlucky-core -p unlucky-cli /
clippy --workspace --all-targets -- -D warnings 全绿。
 2026-11-11 11:12:23 +08:00
AskaEth 0b40e1dfe2 test(core,presenter): 夹具口径跟随 M240 收窄（长类名不再被抹）
Guards / 依赖许可与来源（cargo-deny） (push) Canceled after 0s
Details
Guards / 文件行数 ≤400 守门 (push) Canceled after 0s
Details
Guards / unsafe 落点守门（集合必须恰好等于期望） (push) Canceled after 0s
Details
Guards / design 零第三方依赖守门 (push) Canceled after 0s
Details
Guards / presenter 零 UI 守门 (push) Canceled after 0s
Details
Guards / core 零 UI 守门 (push) Canceled after 0s
Details
Dev Guards / 架构与合规守门（同 main 口径） (push) Canceled after 0s
Details
Dev Guards / fmt (rustfmt --check) (push) Canceled after 0s
Details
Dev Guards / clippy (ubuntu) (push) Canceled after 0s
Details 
M240 让词形长路径不再被当成不透明串，而 M241 的两份夹具仍断言「必须被抹成
<redacted:opaque>」——两条各自的 pre-rebase 门禁都绿，合并 tip 上才互相矛盾，
维护主线短暂变红。

- core：raw_evidence_hits_... 改成断言「脱敏文本也保留类名、两边都能命中」，
  并改名 ..._and_m240_keeps_it_visible_after_scrubbing；保留一条守卫：若将来
  又把词形长路径抹掉，这条会红并提示改用 raw 窗口的用例说明其必要性。
- presenter：展示面与盘上的断言从「不许出现类名」翻成「应保留类名、且不许
  出现凭据」——类名不是凭据，留着才看得懂崩溃原因。
 2026-11-11 10:48:16 +08:00
AskaEth cc90c64b84 fix(core): 行尾句读不再让真 token 整串落盘（M243 BEARERDOT） 
`Bearer <JWT>.`（行尾一个英文句点）整串原样落盘：句点自己属于 dotted 字符集，
扫描器把它算进 run 后 `split('.')` 多切出一个空段，「每段 ≥8」当场不成立。
M240 实测 old == new == 原文，影响 core 的全部落盘/展示面。

修法不是抬阈值：`shape::split_trailing_punct` 在判定前把末尾句读（`.` `,` `;` `)`）
切出去，`push_dotted` 再把句读原位写回——占位符只吃 token 本体，句子标点一个不丢。
只有 `.` 会进入字符集，其余三个本来就在外面，列全是为了「句读不参与判定」只有一处出处。
`has_dotted_token` 的闸门同步改成看同一份切分结果，否则闸门关着就静默不抹。

判据：`tests/bearerdot.rs` 三组——四种形状（`Bearer <JWT>.` / `… <JWT>. then` /
`<JWT>,` / `(<JWT>)`）必须抹且标点保留；句点结尾的普通文本（`Service.Unavailable.today.`）
必须逐字原样；两个入口在带句读的输入上必须一致。语料 68 文件 / 243 行仍 0 行被改，
JWT/sha256/base64 正例仍被抹。变异自证：把 trim 改回旧行为 → 主判据红（EXIT=101）。

外层两个既有红（diagnose::session / presenter m241 夹具）是 M240 收窄后的口径冲突，
stash 回 main HEAD 可复现，已各 file 一条 finding，不在本轮修。
 2026-11-11 10:48:04 +08:00
AskaEth a07482f828 docs(core): M240 r2 复审 —— 两处注释口径（= 边界代价写清、DNS 形归属改正） 
纯注释，判据/阈值/测试断言/扫描器零改动。

① `is_dotted_token_char` 的 doc 原写「JWT 自己的 `=` 只可能是末尾填充，拆出去不损伤
覆盖面」——作为无条件说法不成立。改成有范围的措辞，并把这条例外并入模块文档
「旧行为抹、新行为留」第 1 条（不新开章节）：`-DaccessToken=abcdefgh.ijklmnop.qrstuvwx`
（整段 40 字符、三段各 ≥8，旧规则抹）现在 `=` 切段后值只剩 26 < 40 → 原样留下。
旧/新两侧都实测过（`git show 74be510` + rustc 探针 / 当前代码探针）。

② `cdn_and_mirror_urls_survive` 里 `resources.download.minecraft.example-cdn` 的注释
原写「全靠必须含大写这条必要条件挡住」——不成立：它是 DNS 形状，由 `is_url_authority`
→ `is_dns_host` 豁免（删掉大写判据该测试仍绿）。改成正确归属，与
`lowercase_dotted_names_are_spared` / `the_uppercase_requirement_is_load_bearing` 的
doc 口径对齐（DNS 形靠主机名豁免、非 DNS 形靠必须含大写）。
 2026-11-11 10:15:49 +08:00
AskaEth 66929786c0 docs(core): M240 复审 P2-1/P2-2/P2-3 —— 口径收窄、大写判据钉住、找回丢掉的负例 
P2-1：「抹除能力没有下降」是绝对承诺，已改成准确口径——收窄的就是三类形状
（`=` 边界、填充不计段长、全小写点分串），每条都在 shape 模块文档里写明，并用
`known_narrowings_old_masked_new_keeps` 把「旧行为抹、新行为留」钉住。三条的旧行为
是用 M240 之前的真实代码（`git show 74be510:…` + rustc 探针）实测的，不是推断。

P2-2：「必须含大写」原先没有任何测试钉住（复审实测：删掉它 13 条仍全绿）。
查明原因：DNS 形状的全小写点分串早就被"首段是主机名"那条豁免救下，大写判据
只对**非 DNS 形状**的全小写点分串承担区分作用（标签带 `_`、标签超 63 字符、
`/` 前只有一段主机名）。选择保留（复审的 (b)），并补
`the_uppercase_requirement_is_load_bearing`（`sophisticated_backpacks.upgrades.reference`
等两条）——删掉判据 → 该测试与 `lowercase_dotted_names_are_spared` 红、其余 15 条绿。
同时改正事实错误：不是"第三段必为大写"，而是头的 base64url **第三个字符**恒为
`ey` + `I/J/K/L`（`7B 22 xx` 的第三组 6 位 = `b1` 低 4 位 ++ `b2` 高 2 位 → 索引 8..11）。

P2-3：找回重构时丢掉的老负例 `dotted_token_rule_does_not_eat_normal_text`
（4 条用例 + 直接断言 `!has_dotted_token(...)`，含 `eyJhbGciOiJIUzI1NiJ9.short.abc`）；
语料测试的 doc 注明它**只守一个方向**，不得当"正例仍被抹"的背书。

判据与阈值一个字没动（40 / 3×8 / 64），扫描器代码零改动，纯文档 + 测试。
 2026-11-11 10:15:49 +08:00
AskaEth 43f77d8865 fix(core): 收窄日志脱敏的三类误杀（品牌串 / CDN 主机名 / 长路径） 
M239 实测两条形状规则会误杀三类正常文本，被抹掉的正是用户要复制的面
（`--dry-run` 的 argv、`cmd_built.argv`、诊断规则引擎的输入）。修法不是抬阈值
（40 / 3×8 / 64 一个字没动），而是给每条规则加**必要条件**：

- `-D<key>=<品牌>` 被当三段式 token：`=` 是赋值边界、退出 dotted 字符集
  （JWT 的 `=` 只可能是末尾填充），键里的点号不再把值拖进段数统计。
- CDN/镜像 URL 变成 `https:<redacted:token>`：加"必须含大写"与"首段不是 DNS
  主机名"两条必要条件（JWT 头是 JSON，base64url(`{"`) = `eyJ` 必含大写；
  base64url 不含 `/`）。扫描器先切主机名，路径那半继续判——JWT 放进 URL
  路径里照样抹。
- ≥64 无点号长串吞掉整条路径：路径形状（被 `/` 切开且每段是词形名字）整条
  保留，但**段本身**≥64 的照抹（`/…/objects/<64 位 hex>` 只抹那一段）。

真凭据的抹除能力不变：登记过明文值的替换路径没碰；正例（本仓 JWT / MSA JWT /
`-DaccessToken=` 粘着 / URL 路径里的 JWT / 标准 base64 三段式 / sha256 hex /
base64 ≥64 / `A`×64）全部仍被抹。回归语料（M239 的 68 文件 / 243 行）修前被改
1 行 → 修后 0 行。判据与扫描器拆成 redact.rs + redact/{shape,tests}.rs。
 2026-11-11 10:15:48 +08:00
AskaEth edd6402fd5 fix(core): 规则结论改在脱敏前算，会话路上 fabric.loader_0_12 能命中（M241） 
会话 JSONL 是写前脱敏的，而脱敏的「≥64 无点号不透明串」是有损的：
fabric.loader_0_12 唯一的证据行（Sponge mixin 类路径 66 字符）被抹成
<redacted:opaque>，规则在会话路上永不命中。

修法不动脱敏策略、也不往盘上多写一份原文：
1. SessionWriter 在内存里留一个 2000 行的原始尾窗（不落盘）；
2. 收尾时把这些**原始**事实交给新的 diagnose::session::conclude 跑规则，
   产出契约形状的 diagnosis payload —— 它落盘前仍过 Redactor::scrub_json；
3. 日志页优先读这条落盘结论，老会话才回落到「在脱敏文本上重跑规则」。

为什么不是「原文与脱敏文本并存」：会话 JSONL 里存原文会踩
core/tests/launch/pipeline_cases.rs 早已钉死的「事件流不得含凭据明文」。

顺带把 EventKind 纯搬移到 launch/session/event_kind.rs 守 400 行上限。
 2026-11-11 09:19:42 +08:00
AskaEth f217d83680 feat(saves): 实例存档 / 截图的只读列表与打开文件夹（M235 STOREMVP） 
用户诉求是 PCL 差距四项里的「存档截图 / 导入」，M230 审计确认三层全缺。塔裁决 U3
把这一版钉成「只读列表 + 打开文件夹」，不做缩略图墙（缩略图要引图片解码依赖，而
AGENTS §2 只允许 palette-extract 引 image 类依赖；截图/导入产物形态也没定型）。

core
- `game::saves`（新）：只读列 `<run_dir>/saves`（世界目录）与 `<run_dir>/screenshots`
  （图片文件）。只调 symlink_metadata / read_dir / metadata，不建目录、不写文件、不读
  文件内容（`icon.png` 只判存在）。目录不存在 ⇒ 空列表不是错误；存在但不可用（符号
  链接 / 不是目录 / 读不了）⇒ 具名错误。条目级异常逐条登记原因，不静默丢。
- `platform::opener`（新）：`open_dir` 是**目录**打开器的唯一收敛点（explorer / open /
  xdg-open），内部复用 `child::quiet`，cfg 分支只此一处。塔明确要求按 AGENTS §6 放
  platform 而不是业务模块，并要一条可执行判据防退化
  （`the_launcher_literals_live_here_only` 扫 `crates/core/src`：除本文件外不许出现
  `"explorer"` / `"xdg-open"` 字面量）。

presenter
- `dto::saves`：SavesCommand（List / OpenFolder）、SavesListView、SavesFailureView
  （结构 + OS 原文，不拼中文）、`SavesListView` 的计数助手。
- `host::saves`：走 `job::spawn`，UI 只收快照；运行目录仍是
  `isolation::derive_game_dir` 的同一个答案（与启动 / mod 列表同源，**不写盘**）。
  「打开文件夹」打开哪个目录由 host 定：`saves/` → `screenshots/` → 运行目录。
  失败分三类（InstanceUnavailable / DirUnusable / OpenFailed），可重试。
- `state::saves`：快照整体替换、迟到结果丢弃、失败保留绑定（重试才有意义）。
- 接线：CoreEvent::Saves / AppCommand::Saves / HostTask::Saves。

app-iced
- `pages::instances::saves`：详情页 SAVES 卡片（MODS 之后、启动参数之前；**不套第二层
  滚动条**，整列那一条是唯一入口）。世界行带 UTC 时间与「有图标」，截图行带大小与时间；
  第一行固定画「这一版只读」（U3 边界让用户看得见）。读盘失败画一条红字 + 「重试」；
  打开文件夹失败**不画**重试（那个动作的重试就是再点一次按钮）。
- 接线：Message::{ReloadSaves, OpenSavesFolder}、`sync_saves`（与 `sync_mods` 同一判据）、
  Model::saves、`saves_shot` 出图夹具（ULL_SAVES_FIXTURE=1）。

i18n
- `InstancesSaves*` 20 条中英成对，catalog 与金表在**同一条锚点**后追加、逐字节一致。

证据
- core 只读判据：`game::saves::tests` 在真盘建世界/截图，调用前后各拍一次
  （相对路径, 是否目录, 字节数, mtime）指纹并逐条比对；另有用例钉「目录缺失不建目录」。
- presenter：`host::saves::tests` 真盘端到端（custom 档位派生运行目录 → 快照）。
- GUI：`--software-renderer` 1180×760 浅/深各一张 + 1180×1280 两张「整块卡片可见」
  （1180×760 下 SAVES 卡片位于折叠线附近，只能看到卡头；第二对用 ULL_WINDOW_SIZE
  把窗口拉高，口径与 M98 的矩阵一致），落 `DevDocs/artifacts/M235/`。

没做的（U3 边界内，见 handoff）：缩略图墙、导入、删除/重命名、`level.dat` 的
LevelName 解析（世界名暂时就是目录名）。
 2026-11-11 06:00:27 +08:00
AskaEth c917bfa18f fix(core,cli): M231 复审三条 P2 —— 恢复误删用例 / 收窄 --dry-run 文案 / 判定链去重 
P2-1：`natives_cases.rs` 里 `missing_native_jar_becomes_missing_component` 是上一轮
批量截断时**误伤**掉的（我把「tree_snapshot 之后的所有内容」整段砍掉，连带这条与
dry-run 无关的用例），不是有意删。现已从 main 原样贴回，`MissingNativeJar` /
natives 组件缺失这条用户可见失败路径恢复覆盖。

P2-2：help 的「也不写盘」是过度承诺 —— `commands/launch.rs` 的 `launcher_log::set_dir`
/`record_start`/`record` 都在 `if args.dry_run` 之前，dry-run 仍会 append
`<数据根>/logs/launcher.log`（连父目录 create_dir_all）。文案收窄成「不碰版本树
（不解压 natives、不建 natives 目录）；启动器自身的运行日志照记」。core 的 `DryRun`
文档同步加了「本层承诺 / 调用方日志另算」的边界。

P2-3：`extract` 与 `preview` 的「无 jar / 戳记命中 / 重解」判定链合成 `inspect()` 一份，
返回 `DirStatus`（NoJars / Ready(files) / Stale）+ 源 jar 指纹；两个入口只在这里分叉。

另：`tree_snapshot_notices_a_transient_directory` 在全量并行跑时偶发红（本轮门禁抓到 1 次，
单跑 3 次全绿）——「建了立刻删」对父目录 mtime 的影响会被 NTFS 合并。换成确定性自检
`tree_snapshot_sees_new_nodes_and_mtime_changes`（新节点 + 同内容重写的 mtime 变化），
并把这条能力边界写进 `tree_snapshot` 的「抓不住」。
 2026-11-11 05:18:56 +08:00
AskaEth 1fa30c4885 fix(core): launch --dry-run 不再落盘（natives 只预览，零建目录/零写文件） 
`ull launch --dry-run` 在「环境准备」段走的是真解压：即使只打印命令行，也会在
`versions/<id>/natives/` 下建目录、解 dll、写戳记，把别人的版本树改脏（父目录
mtime 也变）。失败路径（缺 jar 报 missing_components）照样留下这些副作用。

- natives 新增 `preview()`：与 `extract()` 共用条目筛选与戳记口径，但零落盘
  （无 create_dir_all / clear_natives / write_stamp），只清点「将写下几个原生库」；
  jar 打不开照样报错，预览不藏坏包。
- `NativesReport` 增 `planned` / `dir_exists`：预览报告自报家门，人读行与 JSON
  说清「未落盘」「目录尚不存在」。
- `Launcher::dry_run` 改走 `preview_environment`，`spawn` 仍走 `prepare_environment`。
- 报告类型拆到 `natives/report.rs`（mod.rs 曾破 400 行红线）。
- 回归测试（natives_dry_run_cases.rs）：有 jar / 无 jar / 空 jar / 已解压过四条
  零落盘判据，用「节点类型 + 纳秒 mtime」快照逐字比较版本树，并带一条判据自检
  （瞬时建删目录必须被快照看见，防假绿）。
- help：`--dry-run` 的承诺补成「不写盘、不解压 natives、不建目录」。

证据（外部版本树 versions/1.16.5 + 真 natives jar）：
修复前 dry-run 后 versions/1.16.5 mtime 1794342830.6861426 → 1794342832.4544542，
新增 natives/ + lwjgl.dll + OpenAL.dll + .ull-natives.json；修复后同一场景快照逐字
不变（mtime 1794343730.6618167），JSON natives.planned=true / dir_exists=false。
 2026-11-11 05:18:54 +08:00
AskaEth 38d1f3c20f docs: DOCFIX-2 收口三处旧口径注释（M232） 
- cli/cli/model.rs:147 `InstallArgs::loader` 文档补 `liteloader`（第六个可装取值），
  并点明 `optifine` 是「认得出但装不了」→ `loader_unsupported`；
- commands/instances/tests.rs:103 删掉「只在认得出但装不了的那两家会红」的旧口径，
  改成真实理由（第三方前缀形状、没有 `<mc>-<kind>-<ver>` 段）；:231 同句副本改成
  「optifine 装不了 / liteloader 自 M222 起能装」；
- addon/loader/liteloader.rs:44 `DEFAULT_REPO` 文档由「BMCLAPI 有 bmclapi-liteloader
  改写规则」改为「直连官方」：该规则自 M225 起 mirrors.json 里是 enabled=false
  （镜像侧实测 404），并按 M225 finding 的方向补上「库走 CENTRAL_REPO」。

纯文档，零行为变化。
 2026-11-11 04:38:53 +08:00
tower-worker a0f61d8bb5 feat(mods): 本地 Mod 列表与启停（M224 MODTOGGLE） 
三层一次做完：core 读写目录 → presenter DTO/host → 实例详情页 MODS 区。
r1 复审后 rebase 到 main 71144df（M223 已合入），并修掉四条文档疵。

core（crates/core/src/addon/mods/）
- suffix：`.disabled` / `.old` 的**唯一判据**（四态枚举 + 展示名 + 双向改名目标名），
  收敛原先两份同构实现——`export/scan.rs::is_disabled_path` 与 `import/plan/paths.rs::suffix_variant`
  改为委派/再导出，签名与行为不变。
- list：单根语义（入口是 derive_game_dir 派生出的运行目录）列 `<run>/mods/`，不按扩展名过滤，
  符号链接/目录/怪名字逐条登记原因；`mods/` 本身是符号链接时拒（不跟随）。
- toggle：启停 = 在 `mods/` 里改名。五条守卫（裸文件名 / 目录可用 / 普通文件 / 不覆盖 / 不做
  copy+delete 兜底）+ 幂等；`.disabled` 只插在 `.old` 之前。

presenter
- dto/mods：ModsCommand / ModListView / ModFailureView（不拼文案，只给结构 + OS 原文）。
- host/mods：后台线程列目录与启停，运行目录走与启动同一份 D20 派生、不写任何设置；
  游戏在跑时 host 侧直接挡。
- state/mods：快照整体替换、迟到结果丢弃、在飞标记；`AppState::mods`。

app-iced（实例详情页）
- MODS 区（`pages/instances/mods.rs`）：名字 + 大小 + `.old` 徽标 + Switch；运行中/在飞只读。
- 进入详情页即后台列一次（不走 3 s 观察窗，避免打红 M192 的「空闲不烧帧」守卫）。
- MODS 卡排在启动参数**之前**（详情列是滚动区，排在后面 1180×1000 下永远看不见）。
- i18n：19 条中英文案（`catalog/instances.rs` + 金表）。

rebase 冲突解法（三个文件，全是"两侧同段新增"，都保留）：
- `i18n/catalog/instances.rs` + `i18n/catalog/golden.rs`：M223 的 Adopt* 段在前、M224 的
  InstancesMods* 段在后（= `Key::ALL` 顺序 = 金表顺序）。
- `presenter/src/state.rs`：`adopt` 与 `mods` 字段/初始化/apply_core 分支都留；`tiles()` 归
  `state/tiles.rs`（本分支搬的），`apply_agent`/`agent_rail_visible` 归 `state/agent.rs`
  （M223 搬的）——两处搬移不重叠，state.rs 里都不再出现。

r1 四条文档疵：
1. `pages/instances/mods.rs` 模块文档：挂载位置写反（"启动参数卡之后"→实际之前），并补上为什么；
2. `state/mods.rs`：引用不存在的 `CoreEvent::ModsChanged/ModsFailed` → 改成 `CoreEvent::Mods`
   + 文字说明 Ok 落快照 / Err 落具名失败；
3. `app/state/mods_shot.rs`：文档说"目录串取真实派生结果"但代码留空 → 改成"故意留空"；
4. `app/state/refresh.rs::note_mods_failure`：文档说"连点两次看见两次红字"与去重机制不符 →
   改成按 `(实例, 文件, 大类)` 三元组去重（防刷屏），换文件/换实例/换大类仍会再弹。

顺带（r1 已确认的 main 红）：`pages/download/options/view.rs:88-89` 两条
`clippy::doc_lazy_continuation` 只缩进修掉，文字未动。
 2026-11-10 21:09:37 +08:00
AskaEth 9ca5ee8ae7 docs(core): adopt 的两条文档小疵（r4 复审留的，M223 顺手修） 
- plan.rs 第 11-12 行：一个悬空半句（「…必须落在」后面断掉）补完，并把 fspaths 的引用接上；
- run_dir.rs 第 16 行：删掉「配置写面看 <.ULL>、并额外排除游戏根」这条**已移交**
  fspaths::ensure_surfaces_clear_of_game_tree 的职责描述，明说本模块只负责数据写面这一条。

纯文档，零行为变化。
 2026-11-10 19:37:43 +08:00
AskaEth 3114fa2d4f fix(core): 首轮编译/测试抓到的四个问题（BTreeMap、测试模块布局、display_loader_version、未用 import） 
1. liteloader.rs 拆文件后漏了 `use std::collections::BTreeMap`（`loader_library` 里用）。
2. `tests/liteloader.rs` 是 **crate root**，`mod guards;` 会被找去 `tests/guards.rs`；
   改成 `tests/liteloader/main.rs`（与 `tests/game/main.rs` 同形），target 名仍是 liteloader。
3. `display_loader_version` 去通配时丢了 NeoForge@1.20.1（forge 布局）去前缀的语义：
   既有用例 `neoforge_1201_uses_forge_layout` 当场抓住（1.20.1-47.1.106 → 47.1.106）。
   现在按「加载器 + 是否 forge 布局」显式决定，四家原有行为逐字不变。
4. `dto/instances.rs` 的 `pub use super::LaunchArgsView` 在非 test 构建里没人用（-D warnings 会红），
   改由 `dto/instances/tests.rs` 直接 `use crate::dto::LaunchArgsView`。

顺带修两条**我自己写错的测试期望**（不是产品 bug）：
- 取消用例里那条 `resolve` 断言用错了父版本表（父版本在内存表里，当然解析成功）；
- 新式父链用例误以为 `minecraftArguments` 会是 None，实际会沿链继承祖父层那份
  —— 断言改成「继承来的 legacy 串里不许出现 LiteLoaderTweaker」。
 2026-11-10 19:34:12 +08:00
AskaEth 51ea32284d docs(core): inherit::merge 里写清 minecraftArguments（子覆盖父）与 arguments.game（追加）的区别 
M222 的准入条件就是这条；不给结论留档，下一个人还会以为「叠一层」随便往哪个字段写都行。
 2026-11-10 19:34:12 +08:00
AskaEth 0eaefebf3b fix(core): 同一 loader 版本 id 撞两条父链时具名报错，不覆盖盘上清单（旧实例会静默换父链） 2026-11-10 19:34:11 +08:00
AskaEth 9c6b5eaa9b chore(core): 去掉 liteloader 集成测试与 versions.rs 里未使用的 import（-D warnings 会红） 2026-11-10 19:34:10 +08:00
AskaEth 7ed954f7fa fix(core): LiteLoader 快照仓固定为 repo.mumfrey.com/snapshots（1.10.2 的 repo.url 是 /repo/ 形态，照它会 404） 2026-11-10 19:34:10 +08:00
AskaEth 944b1610c8 feat(core): LiteLoader 安装路线（官方版本表 + 从零合成 launchwrapper 清单） 
按 M218 SURVEY-p1 §4.1 的清单接上 LiteLoader 的安装路线，不动 OptiFine。

- core: 新增 addon::loader::liteloader（官方 versions.json 解析 + 合成清单）与
  addon::loader::parent（父版本链读盘定位原版版本）；LoaderKind 加 LiteLoader；
  LoaderRelease 加 parent_version_id、LoaderPlanInput::vanilla_installed → parent_installed；
  LoaderInstallPlan::build 改返回 Result（父版本缺失具名报错）；LoaderSource::resolve_on
  支持指定父版本（仅 LiteLoader，其它组合具名 unsupported）。
- 继承边界（本 mission 第一步核实）：arguments.game 父在前子在后追加，minecraftArguments
  子覆盖父，启动顺序 legacy(24) → arguments.game(25)。所以 tweakClass 只写 arguments.game，
  绝不写 minecraftArguments（会顶掉 Forge 1.12.2 的 FMLTweaker）。
- maven/fabric 的 `_ =>` 通配改成穷尽分支：非 maven 族不再静默回落 Forge 的仓库；
  maven::{metadata_url,installer_url} 改返回 Option<String>。
- presenter: supported() 收 LiteLoader、wizard_choices 六选、dto::instances 按关注点拆成
  instances/{loader,runtime,create,tests}.rs（原文件 395 行，动手前先拆）。
- cli: --loader 区分「认不出」(loader_unknown) 与「认得但装不了」(loader_unsupported)；
  <version> 位写加载器版本 id 时按父版本处理（只有 liteloader 接受）；help 只改 install 段。
- app-iced: 下载页加载器 chip 加 LiteLoader（1.5.2~1.12.2，两头按官方没有构建拒），
  chip 清单改为委派 Loader::ALL。
- 测试: 真实响应的裁剪夹具（dl.liteloader.com 与 repo.mumfrey.com 的 maven-metadata）
  驱动「解析→计划→落盘→继承→启动参数顺序」全链；Forge 父链有回归（FMLTweaker 必须还在
  且排在 LiteLoader 之前）；父版本缺失/组合不支持/取消/坏表各自具名错误。
 2026-11-10 19:34:09 +08:00
AskaEth 146eb3d8db fix(download): LiteLoader 不再套 bmclapi 改写，Central 库接上 bmclapi/maven 
bmclapi-liteloader 改成 enabled=false（规则保留作形状留档）：2026-11-10 实探
`apply()` 的真实产物 https://bmclapi2.bangbang93.com/maven/versions.json 404 / 9 B、
/maven/com/mumfrey/liteloader/1.7.10/liteloader-1.7.10_04.jar 404 / 9 B、
/maven/com/mumfrey/liteloader/{maven-metadata.xml,1.12.2-SNAPSHOT/maven-metadata.xml}
全 404 / 9 B；官方 dl.liteloader.com 的 versions.json 200 / 49129 B、artifact
200 / 533903 B。引擎遇 404 只会白丢一次请求再前进（NotFound 不重试），官方不可达时
更是直接失败，所以镜像优先用户不该再为每个 LiteLoader 文件试一次镜像。

新增 bmclapi-maven-central（repo1.maven.org/maven2 → bmclapi/maven）：bmclapi 的
/maven 不只是 libraries.minecraft.net 的镜像，Central 的路径逐字节一致（asm-all 5.2
247787 B、gson 2.10.1 283367 B、log4j-core 2.17.1 1790452 B，sha1 逐一相同），不存在
的坐标两侧都是 404（镜像回 9 B 纯文本，没有「200 + HTML」假阳性）。

快照仓 repo.mumfrey.com 不加规则：bmclapi /maven、maven.aliyun.com/repository/central、
repo.huaweicloud.com/repository/maven 对 com/mumfrey/liteloader/1.12.2-SNAPSHOT/
maven-metadata.xml 全是 404，只有官方 200 / 358 B，所以只登记探测结果、不铺未验证的规则。

测试：新增 liteloader_urls_stay_official_only（镜像优先模式也只出官方一条，把 enabled
翻回 true 的变异实测会红）；library_urls_expand_to_the_maven_subpath_on_bmclapi 补
Central 用例；形态判据的 EXPECTED 表加 bmclapi-maven-central。不探外网。

version 保持 3 不升 4：download/jdk_sources.rs 与 tests/game/java_vendor_chain.rs 两处
pin 了 version == 3，后者不在本 mission 的 scope（第一轮 workspace test 就是被这条 pin
抓红的），升版留给专门一轮；规则改动与探测记录写进 mirrors.json 的 notes。
 2026-11-10 13:56:58 +08:00
AskaEth 347a3cc90d fix(game): 复审 r2 三项——Win32 尾点/尾空格别名 + 写面与游戏树重叠 + 更高祖先断链 
r1 五项里 R4/R5 与 slug/大小写等直接案例已由 r2 复审独立通过；这三条是它补证出的**剩余边界**，
只做限定修复，不推翻重写：

r2.1（未存在认领路径的 Win32 尾点/尾空格别名）：比较键新增 `fspaths::comparison_real()`——
已存在前缀用 `canonicalize`，**尚不存在的尾段按平台语义归一**：Windows 普通路径折叠尾 `.`/空格
（`Foo.` 与 `Foo ` 都是 `Foo`，Win32 建目录时就这么做），**verbatim 路径（`\?\…`）不折叠**
（那是另一个物理目录，合法）。原先 `dir_key` 只统一分隔符与大小写，于是一个尚未创建的
`custom` 认领 `Foo.` 与缺省派生 `Foo` 键不相等却被判定「不撞」，两个实例共用一个运行目录。

r2.2（`data`/`.ULL` 整体映射到受保护游戏树时仍静默外写）：新增
`fspaths::ensure_surfaces_clear_of_game_tree()`——默认写盘面（`.ULL`、`config/`、
`config/instances/`、`profiles.json`、`data/`，以及缺省档的运行目录）**解析后不得落进游戏根**；
`plan`（dry-run 也报）与 `adopt`（写盘前）各核一次，重叠即 `adopt_write_surface_in_game_tree`
具名拒绝并提示把数据目录挪到游戏树之外。整体迁移到游戏树**之外**照旧允许（判据是落点不是链接）。
配置写面判据同时收窄职责：`ensure_config_write_surface` 只管「在 `.ULL` 内」，
不再带「`.ULL` 在游戏根里」的豁免特例——重叠由上面那条统一负责。

r2.3（游戏根更高祖先断链仍当空列表）：`scan` 的 `NotFound` 分支改为沿祖先找**最近的已存在入口**，
它能 `lstat` 到但 `canonicalize` 不出来（断链的符号链接/目录联接、目标被搬走）⇒
`adopt_versions_unreadable`；一路到盘根都不存在才是「真正的新数据根」，空结果仍允许。
原先只查 `versions` 与游戏根两层，迁移联接在更高层断开时会误报空库。

新错误码：`adopt_write_surface_in_game_tree`（CLI hint 与 help 拒绝清单同步）。

验证（持久日志在 `target/m221-r2/`，git 忽略、不入库；上一轮 `target/m221-r1/` 证据未覆盖）：
- `cargo fmt --all --check` 0；`cargo check -p unlucky-core -p unlucky-cli --all-targets` 0；
- `cargo test -p unlucky-core --test adopt` **43 passed / 0 failed**（另跑一次
  `ULL_ADOPT_TEST_SYMLINK_REQUIRE=1` 同样 43 passed）；
- `cargo test -p unlucky-cli --test adopt_test` **13 passed / 0 failed**；
- `cargo clippy -p unlucky-core -p unlucky-cli --all-targets -- -D warnings` 0；
- 额外：`cargo test -p unlucky-core --lib` **778 passed**、`cargo test -p unlucky-cli` 全部目标通过；
- 三次**实现-only 变异**（不折叠 Win32 尾点尾空格 / 不核游戏树重叠 / NotFound 直接当空）
  全部以**断言红**收场（1 / 4 / 2 条失败，非编译错误、非环境错误），每次还原后与基线逐文件一致，
  收尾再跑 core+cli 双绿。

界限：只覆盖 core+cli 的定向目标（不等于 workspace 全量）；没有启动真实 Minecraft；GUI 未接；
判据是检查那一刻的快照（TOCTOU 看不到）；Win32 8.3 短名与非 junction 重解析点未覆盖。
 2026-11-09 23:56:02 +08:00