AskaEth/Unlucky-Launcher
1
0 Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
831 Commits 3 Branches 7 Tags
c182d8d5c9d824b23f7a62dd9c40cc58c825b541
Commit Graph
14 Commits
Author SHA1 Message Date
AskaEth c182d8d5c9 fix(download): M295 r1 —— 代理口令脱敏、回落可见、socks5 与错因有话说 
复审 r1（p2-2items / fix-then-merge）两条 p2 都是本轮新开的「用户被骗」面，三条 p3 一并收。

p2-1（凭据泄漏面）：`proxy_url` 允许 userinfo，而这个键在本仓就是凭据（schema 是
`AiPolicy::sensitive()`、`config get` 打 `<redacted>`、`config_secret_test.rs` 专门守它）。第一版把
manual 的原串整条写进 `summary()`（→ CLI stderr → CI 日志 / 截图）与解析失败文案，**不需要用户犯错**。

- `redact_proxy_url` 是唯一实现：`user:password@` → `user:***@`（用户名保留、口令打掉；只有用户名
  没有口令 ⇒ 原样；路径/查询里的 `@` `:` 一律不碰，也不做任何 URL 归一）。
- 四个出口全过它：`describe()`（`summary()`/stderr）、`apply()` 的错误文案（`proxy_problem()`/
  GUI 提示）、手写的 `Debug`（配置与引擎被打进日志时）、`problem()`。
- 刻意例外（写进 docs §5.3）：设置页那个输入框仍显示文件原值——它是编辑面，回填掩码会在用户点
  「应用」时把真口令冲掉。

p2-2（GUI 对「非法地址 ⇒ 回落直连」完全静默）：`proxy_problem()` 的消费者只有 CLI。

- `ProxySetting::problem()` 是新增的**纯判定**（与 `apply` 共用 `manual_proxy`）：宿主用它给提示，
  不必造 client。两个宿主都调它，优先级写清：GUI 常驻（设置页「HTTP 代理」行第二段
  `\n已回落到直连：<原因>`）、CLI 每次装配引擎一行 stderr。
- 取舍写进 docs §5.3：回落直连（而不是拒绝下载）不挡用户，代价是「以为走代理」，所以回落**必须**
  可见；fail-closed 是产品决定，不在本轮。

p3-1：`socks5://` 在 `Proxy::all` 里返回 `Ok`，但本构建没开 socks feature ⇒ 以前静默变成「所有候选
源都失败了」。现在 `manual_proxy` 先自己 `Url::parse` 拿 scheme 做白名单，不支持的直接有界错误
（「本构建不支持 socks5 代理（只支持 http / https）」）⇒ 走已有的回落 + 告知路径。
p3-3：错因不再只有 `builder error`：`reason()` 沿 `source()` 链拼一句；宽口径只补到「少写 scheme」
为止（已带 `://` 不再套一层 `http://`，否则真错因会被掩盖成「解析成功」）。实测文案：
`代理地址无法解析（http://127.0.0.1:99999）：invalid port number`。
p3-2：两个测试文件已在 scope 里登记，本轮未动。

判据（都落在最终字符串 / 真正可见面上）：
- `a_password_in_the_proxy_url_never_reaches_a_user_visible_string`：生效值行 / 错误文案 / `Debug`
  四处都不含口令子串且保留 `user:***@`；`a_proxy_url_without_a_password_is_left_byte_identical`
  守「没口令的地址逐字不变」。
- `a_broken_proxy_url_is_shown_as_falling_back_to_direct`（presenter）：设置页那一行含
  `\n已回落到直连：`、带（脱敏后的）地址、不含口令，且与 `engine.proxy_problem()` 是同一串；
  合规地址没有这条提示。
- `the_console_line_never_carries_the_proxy_password`（CLI）：`announce` 那一行与回落提示都不含口令。
- `unsupported_schemes_and_bad_ports_explain_themselves`（core）+ `an_unsupported_proxy_scheme_is_
  refused_with_a_readable_reason`（engine）。
- 变异 M23-M26 记在 docs §6（redact 返回原文 ⇒ 3 条红；删 `proxy_note` ⇒ GUI 提示红；白名单写
  `if false` ⇒ socks 红；错因换回 `builder error` ⇒ 红）。
- 端到端（真二进制 `ull install 1.20.1 --dry-run`，`CARGO_TARGET_DIR` 同前）：口令样本
  `PWMUSTNOTLEAK` 在 stdout+stderr 里 **0 次**，两行都是 `user:***@`；socks5 那档打出
  「本构建不支持 socks5 代理（只支持 http / https）」。
- 门禁：四 crate `--all-targets` check / 测试（3206 passed, 0 failed, 45 binaries）/
  `clippy --all-targets -- -D warnings` / `fmt --all --check`，另 `check --workspace --all-targets`。
 2026-11-13 11:10:30 +08:00
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
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 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 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 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 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 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 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 bc41dfcf7d Unlucky Launcher v0.0.1-alpha
CI / fmt (rustfmt --check) (push) Canceled after 0s
Details
CI / clippy (ubuntu-latest) (push) Canceled after 0s
Details
CI / clippy (windows-latest) (push) Canceled after 0s
Details
CI / test (ubuntu-latest) (push) Canceled after 0s
Details
CI / test (windows-latest) (push) Canceled after 0s
Details
CI / build release (ubuntu-latest) (push) Canceled after 0s
Details
CI / build release (windows-latest) (push) Canceled after 0s
Details
Guards / core 零 UI 守门 (push) Canceled after 0s
Details
Guards / 文件行数 ≤400 守门 (push) Canceled after 0s
Details
Guards / 依赖许可与来源（cargo-deny） (push) Canceled after 0s
Details 
Rust 原生单文件 Minecraft 启动器：CLI 完整可用（install/launch/accounts/java/diagnose/agent），
MCP server 接入外部 Agent 工具，GUI 开发中。
 2026-10-31 21:54:10 +08:00