Unlucky-Launcher

564 Commits 3 Branches 5 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
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

Author

SHA1

Message

Date

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