100 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
AskaEth	a14b9e17c1	Merge branch 'feat/m170-zip64gate-make-gate-order-test-real'	2026-11-08 10:55:57 +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	5965575210	Merge branch 'feat/m166-zip64fix-shrink-zip64-test-fixture'	2026-11-08 09:30:30 +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	5e1f0868f1	Merge branch 'feat/m165-dlengine-reuse-download-engine-acro'	2026-11-08 09:30:10 +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	b4e6fbf8c1	Merge branch 'feat/m164-windowsarm64-fix-arm64-build-and-pu'	2026-11-08 08:50:21 +08:00
AskaEth	5ff6cdb38b	fix(m164): 复审三条 P2 —— vcvarsall 用 wrapper .bat 真抓到 LIB/INCLUDE、ls 进 arm64 分支、两处数字与一句顺序承诺 ... P2-1（核心：上一轮的 ② 在 git-bash 下是死代码）：`cmd //c "\"${vcvars//\//\}\" arm64 …"` 不行——MSYS 把参数里的 `"` 改写成 `\"` 交给 cmd.exe，cmd 的 `/c` 引号剥离接不住，LIB/INCLUDE 全空，只剩 `set` 的空输出；于是 ③「显式 link.exe」在**没有 LIB** 的状态下生效，正是本步注释里 写的那种会造出 `LNK1181: cannot open input file 'kernel32.lib'` 的组合。改法（复审验过的路线）： 往 `$RUNNER_TEMP` 写一个 **CRLF** 的 wrapper `.bat`（`call "<vcvarsall>" arm64 >/dev/null 2>&1` + `set`）， `cmd //c` 只收**不含引号**的相对文件名（先 cd 进去）——引号留在 .bat 内部由 cmd 解析，路径带空格 也不受影响。同源的 ③ 也补齐：`vswhere -find` 的 `vcvarsall.bat` 与两个 `link.exe` 候选都改成 「反斜杠形态 + 正斜杠形态各试一次」（和同文件 dumpbin 步同规矩），不再赌一种形态。 P2-2：cargo build 步末尾那条 `ls -l` 移到 `if [ "$SLOT" = "windows-arm64" ]` 门内（并加 `|| true`）： x64 是当前唯一在发的槽位，不给它加一个失败面。 P2-3：① `release-publish.yml` 步数改对——主线 7 步、本分支 8 步（`release.yml` 与 `packaging/docs/build-and-ci.md` 两处都改，并列出 8 步是哪几步）；② `check_publish_slots.py` 的 report() 全部改走 **stdout**：注解（`::error::`/`::warning::`）在 stdout 上同样被 Actions 识别， 而分两个流写会让「表格 → 注解」的顺序不可控（原注释承诺的顺序当时并不成立）。顺带在 `build-and-ci.md` 的 arm64 工具链段补一句「`cmd //c` 别收带引号的路径、要 wrapper .bat」， 免得下一个 agent 再把 ② 写回死代码。 本地证据（同一 worktree 复跑）： - P2-1 新证据：把本步 `run:` 块原样抽出，用 `bash --noprofile --norc -eo pipefail`（与 runner 同 语义）、假 vswhere + **路径带空格**的假 `vcvarsall.bat`（真 cmd）跑：新写法 LIB/INCLUDE/linker 三行全部写进 `$GITHUB_ENV`、rc=0；同一套假件跑 e858664 的老写法 ⇒ LIB/INCLUDE 全空、只有 linker （与复审结果一致）。降级路径也复测：vswhere 不存在 ⇒ 只 1 条 warning、rc=0；vswhere 不给 vcvarsall ⇒ ② warning、③ 仍拿到 Hostx64 兜底、rc=0。 - 体检步 5 场景（无 VS / vswhere 全成功 / 报错退出 / 垃圾+非零 / 路径不存在）全部 rc=0、0 条 `::error::`。 - `check_publish_slots.py --self-test` 8 条 + 警告断言全绿；`--dist` 六场景复测（x64-only 绿 / 多一份 arm64 绿+warning / 缺 CLI rc=1 / 空 dist rc=1 / `--slots` 漂移 rc=1 / `--dist` 非目录 rc=1），并且缺产物时输出顺序是「表格 → warning → error → 汇总」，stderr 为空。 - 7 个 workflow `yaml.safe_load` OK；全部 `run:` 块 `bash -n` OK；全仓 400 行扫描 0 个超限 （release-build.yml 316、check_publish_slots.py 345）。 - `check_release_semantics.py`(+`--self-mutation`)、`release_marker.py --self-test`、 `make_manifest.py --self-test`、`cargo metadata --no-deps` 全绿。 边界不变：arm64 产物仍**从未被构建过、也从未在真机跑过**；`PUBLISH_SLOTS` 仍是 `"windows-x64"`， 发布语义与 x64 静态 CRT 门禁未动。下一次 tag 的 arm64 仍可能红，红点大概率换到 C 依赖编译 （aws-lc-sys 的 CMake + aarch64 cl.exe）或链接器（LNK1181）——**不是「arm64 修好了」**。	2026-11-08 08:45:02 +08:00
AskaEth	e858664fca	ci(release): M164 arm64 判定权交回编译器 + 发布名单守卫（不翻牌） ... 根因（拿到的真实证据，不是猜的）：v0.2.2（run 42322062879 / job 128248713926）与 v0.2.3 （run 42429017002 / job 128573547829）两份 check-run 注解逐字一致 —— 失败步骤是第 6 步 `Windows ARM64 工具链体检`，第 7 步 `cargo build` 状态 skipped。也就是说 v0.2.1~v0.2.3 五轮 全红都红在一个**编译前的启发式探针**上，真正的编译器/链接器一次都没说话。该探针的结论还与它 自己打印的快照矛盾：`SDK Lib 版本→um 架构: 10.0.22621.0→um:[arm,arm64,x64,x86,]` 明明在，却 同时报 `kernel32=缺失`（同一个 `find -path` 模式在本地合成目录树上命中）。runner 实况是 Windows 11 Arm64 + Visual Studio 2026 镜像，`VC.Tools.ARM64` 与 `Windows11SDK.22621/26100` 都装好了，M142 的 `setup.exe modify` 反倒返回非 0。 改： - release-build.yml：探针降级为「只取证」——vswhere 组件查询 + 各目录 `.lib` 计数 + arm64 `link.exe` 候选，一条 `::error::` 都不写、永不 exit 1；不再自动补装 VS。红绿只由 cargo/链接/静态 CRT 导入表门禁决定。cargo build 步给 arm64 显式备齐工具链： `rustup target add aarch64-pc-windows-msvc`、`vcvarsall.bat arm64` 取 `LIB`/`INCLUDE`、 vswhere 定位 arm64 `link.exe` 后导出 `CARGO_TARGET_AARCH64_PC_WINDOWS_MSVC_LINKER` （顺序不能反：只给链接器不给 LIB ⇒ LNK1181 kernel32.lib）。 - 新增 packaging/check_publish_slots.py（344 行，零依赖）：名单 ⇄ 产物**两个方向**。 声明了缺 GUI/CLI ⇒ `::error::` + exit 1；有产物没声明 ⇒ `::warning::` 明说未发布（M142 之后 这个方向是静默的，裁剪步只 echo 一行 drop:）。另有源码级断言（名单每项必须存在且 mode=ci、 运行期名单必须等于文件里那行）与 8 条 `--self-test` 注入回归。 - release-publish.yml：裁剪前插一步跑那个守卫，原来内联的齐全性循环搬进脚本（一套判据一处实现）； 重算 SHA256SUMS 的步骤只负责重算。 - release-guard.yml：PR 阶段跑守卫自测 + 源码级断言。 - 文档同步：release.yml / release-publish.yml / release-build.yml 头注释、packaging/README §12、 §1 矩阵、§3 构建与发布、§9 支持矩阵、§7.5 arm64 取证、release-notes.md、README/README.zh-CN 的产物矩阵与说明。口径统一为「arm64 构建取证中、未发布」，不写成已支持。 没做的（按 tower 裁决「方案乙」）：`PUBLISH_SLOTS` 本轮**不加回** arm64。arm64 从未产出过 PE、 本机也证不了，写进名单就等于拿 x64 的发布去赌它（M142 移出名单正是为避免这个事故）。下一 tag 的 CI 真出包后翻一行即可，守卫与 SHA256SUMS 自动跟着扩。 验证：workflow YAML 全部可被 PyYAML 解析；所有 `run:` 块过 `bash -n`；探针步在本机（无 VS/SDK） 实跑 exit 0 并打出实况注解；守卫 `--self-test` 8 条全绿、正反两个方向都在合成 dist 上实测过； check_release_semantics.py（含 --self-mutation）/ release_marker / make_manifest 自检全绿； cargo metadata 正常。**arm64 产物从未被构建过、也从未在真机跑过**——本机 `rustc --target aarch64-pc-windows-msvc` 直接撞上没有 MSVC 链接器（git-bash 的 GNU `link` 被当成 link.exe）， `cargo check --workspace --target aarch64-pc-windows-msvc` 也死在 aws-lc-sys 的 cc-rs 阶段 （GNU host 上没有该 target 的 C 编译器）。真实结论只能等下一 tag 的 CI。	2026-11-08 08:33:44 +08:00
AskaEth	15a19bb375	Merge branch 'feat/m163-releasesem-stable-by-default-publis'	2026-11-07 19:11:10 +08:00
AskaEth	1d2e84ed61	fix(m163): push tag 默认建稳定版（发布标记语义 + 0.2.3 bump） ... 发布标记：`release.yml` 的 dispatch `prerelease` 默认值 true → false；`release-publish.yml` 的 create 路径不再塞 `--prerelease`（空串 = push tag ⇒ 稳定版），edit 路径行为不变（空串不碰 标记）。三种触发各创建什么改由 `packaging/release_marker.py` 一张表定义，流水线 `--emit-bash` 出来两个数组直接用，自己不再写 case——v0.2.2 至今 `releases/latest` 404 的根因 就是「push 默认 prerelease」这层叠上「dispatch 默认 true」。 守门：新增 `packaging/check_release_semantics.py`（CI 在 `.github/workflows/release-guard.yml`， guards.yml 已 398 行不能再挂 job）：①标记表逐条对（push tag 的 create 不含 --prerelease）； ②把 `--emit-bash` 真灌进 bash 读回两个数组；③publish 的可执行内容里没有 --prerelease 字面量、 必须调用 emit-bash、两个数组各喂 create/edit；④release.yml 的 dispatch 默认值 == false（读 YAML 结构）。`--self-mutation` 注入三项真实回归（默认值改回 true / 塞回字面量 / 表里 push 改成预发布），断言每项都红、基线绿。 版本：0.2.2 → 0.2.3（workspace `[workspace.package]` + 五处 path 依赖 pin + Cargo.lock）。 文档：README 中英两版版本行改 0.2.3，并把本阶段能力补进现有章节（Modrinth 匿名在线内容源、 自更新与稳定通道、整合包导入逐文件决策、实例级启动参数），删掉「没有自动更新通道」「导入只有 两份全局策略」两条过期说法；`release-notes.md` 写 0.2.3 的真实更新摘要（保留 {{VERSION}} / {{SUMS}}）；`packaging/README.md` 与 `docs/build-and-ci.md` 里「push 默认仍 prerelease」的旧口径 全部改掉。	2026-11-07 18:56:01 +08:00
AskaEth	5d5fe8aa73	Merge branch 'feat/m162-onlinecontent-modrinth-online-conte'	2026-11-07 17:54:42 +08:00
AskaEth	c319f9dbfd	fix(m162-rebase): M161 合入后三处越线文件回到 400 行内 ... rebase 到 0241f79（M161）之后，两侧各加了几行，这三个文件同时越过 400 行硬线 （guards.yml::file-size 会红）。处理原则：**不删语义、只搬位置**。 - `app-iced/src/pages/content/parts.rs` 410 → **240**：把状态层（loading / empty / failed / offline / centered / status_body）搬到新文件 `pages/content/parts/status.rs`（200 行）。 状态层本来就是「一屏只有一个」的独立东西，拆开后 parts.rs 只剩筛选条、列表、图标与排序文案。 - `presenter/src/dto/events.rs` 402 → **399**：`CoreEvent::ContentDetail` 的文档由 4 行压成 1 行 （字段说明一个不少，`project` 是请求时选中的 id 这句保留）。 - `presenter/src/state.rs` 404 → **400**：把 `ContentFailed` / `ContentDetail` 两个事件的落地 搬进 `state/content.rs`（`apply_content_failure` / `apply_content_detail`），state.rs 只剩 一行投递——与既有的 `apply_content` 同一个形状。 `state/content.rs` 58 → 64（两个新方法），仍在 400 内。语义零改动：只是投递点换文件。	2026-11-07 17:37:13 +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
AskaEth	b394316df4	fix(m162-r1): 叶子成因穿出引擎 + 安装路径切 core 在线源 + 详情迟到结果闸门 ... P1-1（p1-1items 的根因）： - download/error.rs：`DownloadError` 增 `leaf: Option<DownloadErrorKind>` 与 `effective_kind()`；`leaf_of()` 汇总规则只此一处：全 404 ⇒ NotFound、有 Network/Timeout ⇒ Network、全 5xx ⇒ ServerError、混合按「网络错 > 5xx > 404」 取最可诊断的那个（**不从 suppressed 文本猜状态码**）。 - download/bytes.rs：候选源循环收集逐源 kind，收尾时把叶子挂到 AllSourcesFailed 上。 - online/transport.rs：`From<DownloadError>` 改用 `effective_kind()`，于是 NotFound/Server/Integrity 在生产路径可达（项目被删/id 拼错/限速不再画成「未联网」）。 - import/fetch.rs：新增 `FetchErrorKind::Offline`（真正的「没联网」）并与 Network 分开； `From<DownloadError>`/`From<OnlineError>` 都按叶子/大类映射。 - import/complete.rs：补全只在 `Offline` 时早停；404（真实 mrpack 大多托管在 CF CDN， Modrinth 必然 404）与 5xx 只影响那一条，不再掐掉整轮；注记「因未联网提前停止」因此 只会在真断网时出现。 P2-1：presenter 安装路径不再自己拼 Modrinth URL / 自己解析 JSON——改用 `core::addon::online::Modrinth::versions` + `primary_file()` + `VersionFile::sha1/sha512`； `HostTask::InstallDone.result` 改成 `Result<String, ContentFailure>`， `InstallProgressView` 增 `failure_kind`（离线 ≠ 查无此项）。 P2-2：`app/update/content.rs` 把被详情方法抢走的「装入闸门」注释还回 `content_install_request`，详情方法只留自己那一行。 P2-3：`ContentState::apply_detail/fail_detail` 带上 project（事件与 HostTask 都携带请求时的 项目 id），迟到结果一律丢弃；`request_detail` 记下在飞项目，`detail_pending` 不再被迟到 结果清掉。 顺手项：`usable_hash` 让形状非法的那一档摘要被**丢弃**（sha512 仍校验，不再整条跳过； 两档都不可用才拒绝）；`digest_file` 的 IO 失败先删落盘文件再返回。i18n 的 ContentOfflineBody 改成不暗示「有缓存」的措辞（golden 同步）。 用例：download/error.rs 叶子四档 + effective_kind；online/tests/classify.rs 5 条 （AllSourcesFailed+leaf 404 ⇒ NotFound、无叶子 ⇒ NotConnected 保守、叶子一一映射、 单源自身 kind、导入侧 404≠Offline）；import_online 增「404 不停」「真离线才停」 （共 7 条）；download 增「sha1 形状非法仍用 sha512 校验成功」；presenter 增详情迟到闸门。	2026-11-07 17:28:36 +08:00
AskaEth	81278f55af	feat(m162): Modrinth 在线内容源（匿名）+ 远端条目按 sha512 补全 + 离线态 ... core：新增 addon::online —— 按 Modrinth v2 真实形状建模（search facets / project / project versions / version_file by hash），网络出口只有 Transport 一个 trait，生产实现 EngineTransport 走既有 DownloadEngine::download_bytes（零新依赖）；错误分大类，网络类 失败映射成 NotConnected（= 未联网），不再用空列表冒充「没有结果」。 core：online::download::download_verified —— sha1 交给引擎流式校验、sha512 落盘后复核 （download::HashAlgo 没有 Sha512，改它超出 scope，已登记 finding），不符/失败删文件重试， 最多 3 次尝试且不留半截文件。 core：远端条目补全 —— PackFetcher::modrinth_file_by_sha512（默认 Unsupported = 补不出）， import 管线与新增的 scan_pack_online 都会在「有 path 但缺 hashes.sha1」时按 sha512 反查； 补出的 sha1 走 M160 同一套 judge 与合并判定，补不出仍进 unknown_remote 计数（口径未改）。 DownloadEngineFetcher 改用 download_verified，FetchRequest 增 sha512。 presenter：Modrinth 检索/详情改由 core 的 online 客户端提供（不再自己拼 URL、不再读错 date_modified）；ContentFailure{kind} 取代裸字符串，无网 = Offline；新增 ContentDetailRequest/ContentDetail + LoadContentDetail 命令与 CoreEvent::ContentDetail 通道； 预检改走 scan_pack_online；内容库安装也走 download_verified（sha1+sha512）。 app-iced：Status::Offline 独立一态（未联网 ≠ 空列表 ≠ 普通失败），详情面板消费新 DTO 显示可用版本；选中项目即拉详情。i18n 新增 6 个键并同步金表。 测试：online 模块 24 个离线用例（录制 JSON + 假字节：搜索/详情/版本/按摘要反查/校验失败 即删/重试/离线分类/补全），import 侧 6 个（离线计数不变、补全后判冲突、补错摘要 ⇒ Failed）， presenter/app-iced 各补失败分类与详情状态机用例。	2026-11-07 17:28:36 +08:00
AskaEth	0241f793b2	Merge branch 'feat/m161-uipolish-debts-sweep-update-keys-bu'	2026-11-07 17:27:39 +08:00
AskaEth	79b796fd58	fix(m161-r1): 崩溃/静默失败不再冒充「启动进程失败」；补三处假绿的守卫 ... 复审 P1-1（用户可见假文案）：`LaunchEnd` 在 `failure == None`（跑起来之后崩的）时 临时造了 `Stage::Spawn + format!("exit {:?}")`，于是磁贴写「启动失败 · 启动游戏进程」、 详情页漏出 `exit Some(1)`、静默失败丢掉「exit 0 却没起来」，而同一时刻 Toast 说「崩溃」。 - 新增 `LaunchFailureCause{Stage|Crashed|SilentFailure}`（dto/launch_failure.rs）， `LaunchFailureCause::of(outcome, failure, exit_code)` 是唯一组装点；`InstanceRuntime::Failed{cause}`。 `LaunchFailureStage` 保持「只装装配阶段」（文档那句「崩溃是结局不是阶段」现在成立）。 - 界面：`InstancesFailed`（框架）+ `InstancesCrashed` + `InstancesSilentFailed`； 删掉 `InstancesFailedStage`。退出码按数字出词，不再有 Debug 文本。 - 用例：presenter 断言**枚举变体**（三种形状逐条）、app 断言**具体句子** （「不许出现 Some(」「进程起来了不许说启动游戏进程」「静默失败要点出没起来」）。 mock 夹具与 launch_state_tests 的期望值同步；launch-error 三张图重拍。 复审 P2-1（`convert::failure_stage` 零覆盖）：新增 `convert/stage_tests.rs` 5 条（三档 + 「既没回滚也没宣称干净」+ 非致命无阶段 + `failed_report_with` ⇒ NotStarted）。 变异实测：改成恒 `RolledBack` ⇒ 3 条红。 复审 P2-2（矮窗口用例的算式三个数全错、`body_height` 零测试）：用例改成直接调 `frame::body_height`，chrome 从 `Ui::metrics` + `WidthClass::gutter` 现取，并把门槛与真实 chrome 绑死（chrome+MIN ⇒ Split、-1px ⇒ ScrollWhole）；新增 `frame` 自己的 `body_height` 用例。 变异实测：`2.0 * gutter` → `gutter` ⇒ 2 条红。 复审 P2-3（源指纹闸门 / `Refused` 零覆盖）：新增两条 core 用例——闸门（原地留着 prefs.json + 预先写好的同源收据 ⇒ Nothing 且收据未被重写，反证：源变了允许重放）、`Refused` （`$schema` 1.7.0 ⇒ ReadOnly ⇒ 不动旧文件、不写收据、理由含「不可写」）。 变异实测：删闸门 ⇒ 1 条红；`can_save` 守卫改 `if false` ⇒ 1 条红。 顺手收： - CLI `pack import` 那句「已整包回滚」也按三档出词（`RollbackStage` + `rollback_line`）， 加 2 条单测。CLI 不依赖 presenter，判定暂与 presenter 各一份 → 已 file finding 建议下沉 core。 - 设置页 `status_text()` 抽出 applying 档，用例断言「正在安装…」且非错误色。 金表：新 key 加在 `golden.rs`（81 行），未动 `golden/tail.rs`（211 行），避免与 M162 的拆分冲突。	2026-11-07 17:01:13 +08:00
AskaEth	6804b0ad1d	docs(m161): 内容库筛选条「会自动换行」的注释改成如实描述（只改注释，不动行为）	2026-11-07 15:05:31 +08:00
AskaEth	03741ecd2d	fix(m161): 收更新键/按钮/矮窗口/启动错误/导入结果五笔债 ... ① update.auto_check / update.channel 登记进 core setting schema（1.6.0） - 新增 setting/keys/update.rs（两键 + UPDATE_CHANNELS，只允许 stable）； SettingSchema 加 with_all 供域键表批量登记。 - 新增 setting/update_prefs.rs：cache/update/prefs.json → launcher.json 的一次性迁移。 四条硬约束：源指纹闸门（幂等）、不丢 false、新值胜出、旧文件改名 .migrated 后不再被读； 主配置不可写时不动旧文件。收据 config/update-prefs-migration.json。 - presenter Runtime 建会话时迁一次并把结局留在 migration()；prefs 字段换成 auto_check + 每次派发从主配置读 channel（不再硬编码 Channel::Stable）。 保留旧字段 auto_check 的真实来源（原有测试 cases 会断言）。 - CLI config get/set/dump 先跑同一次迁移（幂等），输出里给 migration 段与收据路径。 ② presenter/dto/events.rs 的「本次会话不再弹提示条」注释改成真实语义 （记的是版本号：同版本压住、更高版本照弹、手动检查清掉）。 ③ 检查/下载进行中按钮禁用：pages/update/busy.rs 的 busy/can_check/can_apply； 设置页两颗按钮改画禁用（不是消失），app 层 on_update_action 再挡一道 （忙碌时 CheckNow/Apply 不派发）；新增两条用例（含「忙完恢回可点」）。 ④ 内容库低高度：content_layout::MIN_BODY_HEIGHT=460 + BodyMode（按固定件+三整行算出来， 用例守着算式）；frame::body_height 从 Ui::metrics 算正文可用高，pages::Model 带 window_height。 ≥460 列表自己滚；<460 主列整列一个滚动条、列表按自然高度铺开。 ⑤ 启动错误文案本地化：presenter 删掉 launch_summary / 「启动失败：」前缀 / 五条中文阶段前缀， 改发 LaunchFailureView{stage,detail}；LaunchFinished 改带 exit_code/uptime_ms/failure， Toast 由 app 层按 i18n key 现求（与 install_cancelled 同构）。InstancesFailed 拆成 InstancesFailedStage（列表单行）+ LaunchStageFailed（详情/Toast 全文）。 ⑥ 导入结果块：ImportReportView 加 failure_stage（NotStarted/RolledBack/RollbackIncomplete， 由 core 的 rollback 机器位推出）；标题、图标、底色三处分档，预检失败不再说「已回滚」。 顺带：六处注释/文档漂移（update.rs 的分工表与偏好落点、pack 的「已整包回滚」、 build_request 的 Errors、settings/update 的按钮禁用说明等）， 以及为守 400 行把 update/cli-config/core-keys/presenter-dto/presenter-launch/i18n-golden 里贴线或越线的文件按模块拆开（纯搬移，行为不变）。	2026-11-07 15:02:13 +08:00
AskaEth	b2d9f3927f	Merge branch 'feat/m160-modpackpick-per-file-overwrite-deci'	2026-11-07 13:57:08 +08:00
AskaEth	a4f096eea3	Merge branch 'feat/m159-updategui-auto-update-client-wiring'	2026-11-07 13:35:22 +08:00
AskaEth	04ac90911e	fix(m159): r1 复审返工 —— parse.rs 拆出子模块 + 五条 P3 真问题 ... 按独立复审 `reviewer-updategui-r1` 的 p1-1 / fix-then-merge 返工。 P1-1（挡门） - `crates/cli/src/cli/parse.rs` 406 → **382** 行：`fn parse_update` 搬到 `crates/cli/src/cli/parse/update.rs`（与 `parse/{accounts,agent,instances}.rs` 同形状）。 全仓 `crates/**/*.rs` 最大仍是 400（`design/tests/card_neutral.rs` 等三处，未越线）。 上一轮报告里「所有改动文件都在 400 行内」那句是错的，已在 r2 报告里更正。 P3-6 `Job::apply` 不查包形态 - 新增 `self_replaceable(format)`（只有 `PortableExe` 允许）+ `ensure_self_replaceable`， **挡在取包之前**；错误分类 `InvalidManifest`（发布侧挂错，换源/重试无用）。 比复审建议的 `needs_installer()` 更严：`portable-zip`/`appimage` 同样不能原地当 exe。 - 用例：`crates/core/src/update/tests/job_cases.rs`（msi/zip 被拒 + 目标零改动 + 暂存目录 没被建 + 便携 exe 整环成功 + Nothing 不碰目标 + 闸门的源码锚点）。 P3-7 `ULL_UPDATE_DIR` 生产可用 - `default_source` 改走 `local_dir_override()`：`if !cfg!(debug_assertions) { return None }`， 发布构建里整段被常量折叠掉（这条路径在 release 二进制里不存在）。判据与三档取舍写在 `job.rs` 的文档表里（为什么不用 CLI 参数、为什么不用运行期开关）。 P3-1「忽略这个版本」语义 - `UpdateView.dismissed: bool` → `skipped: Option<String>`（记**版本号**）：忽略 0.2.3 之后 同一次运行里冒出 0.2.4 **照常提示**；手动检查清空（`begin_check(manual)`），静默检查不清。 文案保持「忽略这个版本」。presenter / app 侧视图模型 / 两处用例同步。 P3-3 CLI `--json` 失败信封缺结构化分类 - `CliError` 加 `detail`（`Option<Box<Value>>`，装箱避免 `result_large_err`）+ `with_detail`， `to_json` 输出 `error.detail`；`commands/update.rs` 的 failure 填 `{"kind": core 分类 id, "retryable": 可重试位}`。 - 上一轮报告里引的 `{"kind":"digest_mismatch"}` 形状确实不存在（那是 CLI 的 user/internal）， r2 报告换成了实机 dump。 P3-4 update 命令没有解析测试 - `crates/cli/tests/parse_test.rs`：`update_subcommands`（check / apply / `--dest` 两种写法） + `update_usage_errors`（无子命令 / 未知子命令 / 多余位置参数 / 缺少取值 / 未知选项）； `help_text_covers_every_command` 的 topic 列表补 `"update"`。 P3-5 `install.rs` 模块文档与实测矛盾 - 改成「可以改名、不能覆盖/删除」，写明 M159 在 Windows 真机验过运行中的 exe 自替换， 并提醒别再照旧文档去设计「退出自身 → 另一个进程搬运」的双进程方案。 顺手（复审 P3-2/P3-8 里低成本的两条） - 设置页补「下载中」态（`SettingsUpdateApplying` 不再是死 key，下载期间不画「下载并安装」）； 渠道显示改读 `update.channel`（`stable` 走 key，其它原样）；删掉从未使用的 `UpdateBannerRestartLater`（catalog + 金表同步，29 条 key 全部有引用）。 - `adopt` 只让**检查**刷新 `checked_at`（应用回报不再冒充「上次检查」）； `UpdateView::default()` 的 `current_version` 取本进程版本号（mock 下不再空白）。 门禁（`CARGO_TARGET_DIR=C:/Temp/ull-target/wt-159`）：fmt 绿、clippy -D warnings 绿、 `cargo test --workspace --all-targets --no-fail-fast -j 4` **exit 0**（51 个测试二进制全 ok， `core::addon::pack` 未被 skip）。该族用例复现了复审记的泄漏：一次全量在 `/tmp` 留 72 个 `ull-pack-*`（`/tmp` 149M → 8853M），跑完已 `rm -rf` 清回 150M。	2026-11-07 13:03:18 +08:00
AskaEth	1c8f6aa1b3	feat(m159): 自更新 GUI 客户端接线 + CLI update check/apply 同一内核 ... D50 的「检查 → 提示 → 可拒绝 → 下载校验 → 下一次启动生效」整环接线，GUI 与 CLI 共用 core 的一条内核（`update::Job`），并顺带修掉 M157 最后一轮复审的三处 P3。 内核（core::update） - 新增 job.rs：`Job { source, target, staging, dest }` + `check` / `apply`（复查 → 取包 → 长度/SHA256 双检 → 原子替换），`default_source`（GitHub，`ULL_UPDATE_DIR` 可切本地目录夹具）、`process_dest`、`staging_dir`。 - `mod.rs` 导出 job 一族；`source.rs` 为 `Box<dyn UpdateSource>` 补 trait 转发 （壳层要运行期选源，`UpdateChecker` 是泛型的）。 presenter（宿主通道） - `dto/update.rs`：`UpdateView` / `UpdateOutcome`（Idle/Checking/UpToDate/Available/ MissingArtifact/Failed 六态，**失败与最新不折叠**）/ `UpdateBanner` 优先级判据。 - `host/update.rs`：Factory（生产 GitHub / 单测本地目录）+ core 结论 → DTO 的唯一映射 + 更新域偏好（`cache/update/prefs.json`）。 - `host/update_state.rs`：Runtime（会话状态机：begin_check/adopt/begin_apply/dismiss/ set_auto_check）+ `CoreHost` 派发与后台线程。 - `AppCommand::{CheckUpdate, ApplyUpdate, DismissUpdate, SetUpdateAutoCheck}`、 `CoreEvent::Update`、`AppState.update`；`refresh_all` 按开关派发静默检查。 app-iced - 设置页新增第 5 组「更新」（当前版本 / 渠道 / 自动检查开关 / 立即检查 / 上次检查与 结果 / 下载并安装 / 就位后立即重启），走 `settings::view` 的 `update` 形参 + 按下标 分发（与 M106 语言行同一取舍）。 - 顶部提示条（每页可见）：有新版本（版本号 + 体积 + 说明摘要，可安装/可忽略）、下载中、 已就位（立即重启）；静默检查失败**不**弹条（原因进设置页）。 - `pages::Message::Update(UpdateAction)` → `app/update/update_action.rs`；「立即重启」 拉同参数的新进程后退出（截图通道不重启）。 CLI - `ull update check` / `ull update apply [--dest <path>]`：复用同一 `Job`；四种结论分开 报（`--json` 的 `status`），失败退出码 1（`update_check_failed` / `update_apply_failed`）。 i18n - 新增 `catalog/update.rs`（30 条，链尾追加）+ 金表对应 30 行。 M157 复审 P3 三件 - `app/update/instances.rs` 模块文档改成「清脏的唯一时机是回程快照等于表单」。 - `pages/instances/demo.rs` 的 `demo_form` 注释改成现状（两个参数框早已是单行输入）。 - `pages/instances/launch_args.rs`：门限不满足时只灰 `opengl`/`vulkan`，`default` 仍可点 （它是「不下发」的安全档）；判据抽成 `backend_chip_enabled` 并补 3 条用例。浅色 + 灰化 两张图：`C:/Temp/m159-shots/instances-launch-args-{light,gated}.png`。 顺带：harness 支持 `ULL_SETTINGS_GROUP=<下标>`（拍第 5 组的验收图需要它）。 验证：cargo fmt --check 绿；cargo clippy --workspace --all-targets -D warnings 绿； cargo test --workspace --all-targets 51 个测试二进制全绿（唯一例外：core::addon::pack 一族要造 4 GiB 稀疏文件，本机磁盘 99% 满 ⇒ StorageFull，与本次改动无关）；CLI 用本地 目录夹具跑通「发现 9.9.9 → 下载 → 校验 → 替换运行中的 exe → 备份留旧文件」，并验证 摘要不符时拒绝应用、目标文件零改动、暂存目录零残留。	2026-11-07 12:09:42 +08:00
AskaEth	a80362915a	Merge branch 'feat/m157-instargs-per-instance-launch-args-a'	2026-11-07 11:28:53 +08:00
AskaEth	ee67965b9b	fix(m157): r4 修复未收集的周快照用例 + 两处 clippy 红，并补整环回归（复审 p1-2） ... P1-1 crates/core/src/launch/overrides/tests.rs：modded_weekly_snapshot_needs_the_root_version_for_the_gate 原先写在 backend_allowed_combines_capability_and_threshold 函数体内（unnameable_test_items，永不执行）。移到模块层；移动后首次真正执行暴露出用例自身的 EmptyJavaPath（AdapterOptions 默认 java 为空），补 JavaSelection 后绿。--list 现在 10 条 launch::overrides::tests::（含该名字）。 P1-2 clippy -D warnings 两处：cli/commands/instance_launch.rs needless_borrows_for_generic_args（去 &）；presenter/mock_data.rs items_after_test_module（mock_launch 移到 mod tests 之前）。 P3-a 新增整环回归 app/tests/instances_save_loop.rs：真 Message → dispatch → 后端回错误 Toast → pump → refresh_view → sync_launch_form，断言 4g 草稿与脏标记都还在。 P3-b LaunchForm::matches 内存改按数值比（解析失败退文本），补 memory_is_compared_by_value_not_by_text（04096 / +4096 / 清空三档）。 P3-c 门槛文案不再在 catalog 硬编码 26.2：InstancesLaunchBackendGated 改用 {min} 占位符，页面从 LaunchFacts::min_version（← core GRAPHICS_BACKEND_MIN_VERSION）代入；金表同步；灰化态截图重拍。	2026-11-07 11:06:18 +08:00
AskaEth	211e07b470	fix(launch): M157 r3 周快照门限按继承根版本 + 保存失败保留草稿（复审 P2-1/P2-2） ... P2-1 周快照 + 加载器的 --graphicsBackend 静默丢失：presenter host::launch::build_request 与 cli snapshot::prepare 给 SnapshotInput.game_version 传 None，装配按带加载器后缀的 version_id（26w14a-fabric-0.16.5）判门限，GameVersion::is_weekly_snapshot 的 6 字符形态认不出来。两个调用点改为传继承链的 MC 根版本（25 行注释说明「门槛与拼装必须同一口径」）。回归：core launch::overrides 的周快照实际装配用例（正/负两档）、presenter host::launch::tests、cli snapshot::tests 各一条根版本断言。 P2-2 保存失败丢草稿：app/update/instances.rs 的 Save 分支派发前就把 launch_form.dirty 清掉，失败事件后 pump 用旧快照重建视图并覆盖表单。改为派发不清脏；LaunchForm::sync 只在「回程快照已等于表单」（= 落盘确认）时清脏并重播种，否则保留草稿。回归：failed_save_keeps_the_draft / confirmed_save_clears_dirty_and_reseeds / save_dispatch_keeps_the_dirty_flag。 顺带：launch::overrides 测试拆到 overrides/tests.rs（守 400 行）。	2026-11-07 10:36:37 +08:00
AskaEth	c76a1437e6	fix(app-iced): M157 r2 详情列加滚动区 + 启动参数卡对齐信息卡（D30 复审） ... - 详情列（含卡片与动作行）套 scrollable：1180×1000 下被裁的内容可达、滚动条与左列同一套几何；右侧 X2 内缩，卡片描边不再被滚动条压住 - 启动参数卡改用 frame::card（card_padding 21 + OutlinedCard 描边），标题 LabelMedium 不加粗——与相邻信息卡同款 - 段间距 X3→X2，卡片不再比内容长 - 演示夹具补 Game arguments（--fullscreen） - presenter host 单测临时目录加序号（同一进程并行用例互删导致 flake）	2026-11-07 10:36:35 +08:00
AskaEth	e2021645d7	feat(launch): M157 实例级启动参数（五项回落 + graphicsBackend 三态） ... core: 新增 game/launch_overrides（LaunchOverrides 五项 All-Option + 三级回落 + 文本补丁校验）与 launch/overrides（拼装落位：全局 java.extra_args 进 user.jvm、实例 jvmArgs 进 override_jvm、gameArgs 进 user.game、memory 进 -Xmx、backend 进 --graphicsBackend 并复用既有版本门槛告警）；实例 schema 登记 launch.* 五键。 presenter: dto/LaunchArgsView+LaunchArgsPatch，主机侧读/写与门槛判定（backend_allowed），AppCommand::SetInstanceLaunchArgs。 cli: 新命令 instances launch-args（读/写/--clear），launch 装配链消费回落值。 app-iced: 实例详情页「启动参数」区（JVM/游戏参数、内存、Java、三态后端 chips + 灰化提示 + 保存/恢复），表单状态归 App、i18n 中英文案同步。	2026-11-07 10:36:35 +08:00
AskaEth	d68523b02a	Merge branch 'feat/m156-termxmerge-merge-termux-glibc-into'	2026-11-07 09:38:20 +08:00
AskaEth	3b3430a93e	docs(termux): 对外口径升级——CPU 软渲染 + 自编 Mesa GPU 两条路径各真机验证一次（用户拍板 A，四处同步）	2026-11-07 09:33:24 +08:00
AskaEth	cb3ae8556b	docs(core): install.rs 模块文档补上 Termux 分支与平台参数不早退 ... 拆分后模块文档只描述归档链，读起来像「Termux 也走这条」；补一行说明 Termux 的系统包 分支在链之前，以及 `AdoptiumTarget::host()` 失败已改成每家一条降级原因（不再整体早退）。	2026-11-07 09:33:24 +08:00
AskaEth	88ac9d5aca	docs(termux): 适配文档头部与合并指南对齐实际合并（15 提交 / --no-ff / 两处 PC 侧修复） ... - 头部：`14 个提交，HEAD 38d3024` 是写文档那一刻的自我指涉，永远不可能对——改成 `15 个提交，分叉点 87ab878，合并前 HEAD e987e02`。 - 合并指南第 1 步原来写 `git rebase origin/dev`，实际按用户令走 `--no-ff` 合并 （原 15 个提交一字未改地留在历史里，便于按组 revert），改为记录既成事实与 零文本冲突的交集（Cargo.lock / 两个 README / app-iced 的 Cargo.toml）。 - 新增第 6 条：PC 门禁发现、已就地修掉的两处——cfg(unix) 测试导入未 gate 导致 Windows clippy 判错；两个文件越 400 行红线后的拆分。这两条在 Termux 上跑门禁看不出来， 写进合并指南，免得下一个人以为「本机绿了就等于 PC 绿」。	2026-11-07 09:33:24 +08:00
AskaEth	4dbeb07220	refactor(core): 拆分越 400 行红线的 install.rs 与 install/libraries.rs ... 合并 termux-glibc 后两个文件顶破了「单文件 ≤400 行」（guards.yml 的 file-size）： `game/java/install.rs` 379 → 456、`game/install/libraries.rs` 258 → 409。 按步骤拆，纯搬运、零行为变化： - `install/termux_install.rs`（新）：Termux 系统包那条路。它与归档链不共用任何一步 （不查版本元数据、不下载、不解压、不校验 sha256），原来只能是一段嵌在 install() 中间的 if。返回 `Outcome::Done`/`Skipped` 并用 Box 装 `InstalledJdk`（否则 large_enum_variant： 392 vs 24 字节）。 - `install/one.rs`（新）：回退链里「一家」的机械步骤——下载 → 解压 → 探测 + 幂等复用， 连同 `Prepared` 与 `note()`。 - `install/libraries/arm64_natives.rs`（新）：Linux arm64 的 natives 改写与 Maven 兜底 （两个常量 + 改写/拼址两个函数）。用例仍留在 libraries.rs 的 tests 里，它们从 `plan()` 的出口断言，不碰私有步骤。 拆分后：install.rs 319、one.rs 100、termux_install.rs 104、libraries.rs 348、 arm64_natives.rs 72；全仓受检文件（*.rs/*.md/*.toml/*.yml/*.json/*.py/*.sh）复算 最大 400 行，红线内。	2026-11-07 09:33:24 +08:00
AskaEth	c82e39d0eb	fix(core): Windows 上 clippy 报 discover.rs 两个 cfg(unix) 测试导入未使用 ... 这两个 Termux 扫描用例挂着 `#[cfg(unix)]`，但它们的 `use`（`standard_roots_in`、 `platform::paths::MapEnv`）写在 mod tests 顶部没跟着 gate： - Termux/Linux 上 cfg(unix) 成立 → 有用例 → 导入有使用者 → clippy 干净（作者本机 475 测试 通过是真的）； - Windows 上那两个用例不编译 → 导入无使用者 → `-D warnings` 直接判错 （`unused import` ×2，`could not compile unlucky-core (lib test)`）。 把两个 `use` 同样 gate 成 `#[cfg(unix)]`。代价是这两个用例在 Windows 上不编译不执行， 覆盖由 Linux CI 承担（它们断言的本来就是 Unix 路径）。	2026-11-07 09:33:23 +08:00
AskaEth	161aec52f4	fix(app-iced): 新增的 unlucky-core 依赖版本对齐 0.2.2（合并后语义冲突） ... termux-glibc 分支写这条依赖时 workspace 版本还是 0.2.1；M154 之后其余内部依赖 都已被抬到 0.2.2。caret 约束下 0.2.1 仍能解析到 0.2.2，所以不会构建失败， 但版本对齐是 M154 的既定契约，留一条 0.2.1 会让下一个读到该文件的人以为有例外。	2026-11-07 09:33:23 +08:00
AskaEth	41019d9cae	docs(termux): 根目录新增适配方案与合并指南 ... TERMUX-ADAPTATION.md：方案（平台识别/JDK/字体/横屏/GPU/MC）、逐文件改动表、 兼容性说明（Termux gate、x86_64 不变）、合并步骤与 CI 预期、验证矩阵、 后续路线与按组回滚策略。README.termux 顶部链过去。	2026-11-07 09:33:23 +08:00
AskaEth	fe472e36a5	docs(termux): README 校正——GPU 默认、横屏截图尺寸、数据根说明 ... - 构建描述从 CPU-only 改为 GPU 构建（wgpu + CPU 兜底） - 窗口证据改为横屏 1657x1067、首帧 ~60 ms - 快速开始不再强制 --software-renderer：默认 auto，驱动缺失自动降级 - 补数据根说明（Portable 按 exe 目录，--data-dir 暂忽略）	2026-11-07 09:33:23 +08:00
AskaEth	394faad611	docs(termux): MC 1.20.4 真机跑通结论与剩余项 ... - README：MC 标 ✅（glibc JRE + arm64 natives + softpipe）；后续收敛为 zink/DRI3、剪贴板/IME、narrator/音频 - 构建文档 §4.2 补真机启动命令、窗口尺寸与日志位置、非致命项	2026-11-07 09:33:23 +08:00
AskaEth	23c2abebc2	feat(termux): launch 侧同样改写 arm64 natives；真机跑通 MC 1.20.4 ... - Library::linux_arm64_native_name 收敛改写规则，install 与 launch 共用 - presenter/CLI 的 classpath 组装：1.19+ 的独立 natives 条目按 arm64 坐标 找文件并进 classpath；≤1.18 的 natives 表条目仍归 natives::collect - 真机验证：ull install 1.20.4（740MB）→ glibc Temurin 21 + arm64 natives + softpipe GL，MC 主菜单在 termux-x11 中渲染（窗口 854x480） - 已知非致命：narrator flite 缺失、LWJGL JNI 版本告警、oshi cpuVendor NPE	2026-11-07 09:33:23 +08:00
AskaEth	0e7ae44923	fix(termux): 现代清单的 LWJGL natives 条目也改写为 arm64 ... 1.20.x 把 natives 作为独立库条目（org.lwjgl:lwjgl:3.3.2:natives-linux）， 不走 natives 表。Linux/aarch64 上按坐标改写成 natives-linux-arm64， URL 兜底到阿里云 Maven（Mojang 对 arm64 一律 404）。 真机 1.20.4 的 dry-run：7 个 natives 全部变成 arm64；x86_64 不变。	2026-11-07 09:33:22 +08:00
AskaEth	7eed6c6261	feat(termux): MC 启动接线——Linux arm64 natives + softpipe 子进程环境 ... - Library::native_classifier：Linux/aarch64 上把 LWJGL3 的 natives-linux 改写成 natives-linux-arm64（Mojang 清单只有 x86_64） - install::libraries：arm64 分类器在清单里没有下载信息时，按 Maven 相对路径 兜底到阿里云镜像（实测 Mojang libraries 404、Aliyun 200）； 单测覆盖 arm64 兜底与 x86_64 不变 - launch::defaults：Termux glibc 构建启动 MC 时默认带 MESA_LOADER_DRIVER_OVERRIDE=swrast / LIBGL_ALWAYS_SOFTWARE=1（用户可覆盖） - 文档：JRE patchelf 一次性步骤与接线现状；README 同步 - 验证：patched Temurin java 直接执行；LWJGL arm64+GLFW 探针 gl-ok	2026-11-07 09:33:22 +08:00
AskaEth	02ed09ae49	docs(termux): 补 MC 运行时结论（glibc JRE + LWJGL arm64 + softpipe GL） ... - §4.2：Temurin 21 JRE 在 glibc 下跑通；AWT/X11 正常； LWJGL 3.3.3 arm64 + GLFW + GLX/softpipe 端到端探针通过（GL 3.3） - zink 仍卡 DRI3；softpipe 可用（软件 GL） - README 同步：MC 标 🟡（栈已验证，启动器接线待做），后续改为接线 + DRI3	2026-11-07 09:33:22 +08:00
AskaEth	173a18b842	feat(termux): glibc 构建自动启用自编 Mesa 26 turnip ICD（GPU 打通） ... - app/boot/termux_gpu：glibc 构建 + Termux 且随附 ICD 存在时，在探测前设 VK_ICD_FILENAMES/VK_DRIVER_FILES；用户显式设置不覆盖 - 文档：Mesa 26.2.6 + KGSL 的完整构建/安装/验证步骤（含 shebang、 --wrap-mode=nofallback、C++/链接参数三处坑） - 实测：wgpu 选中 Adreno 840（turnip Mesa 26.2.6），截图首帧 61 ms - README.termux：GPU 标 ✅，MC 标 🟡（glibc JRE+AWT 已验证，GLX 待 GL 构建）	2026-11-07 09:33:21 +08:00
AskaEth	bbb316ca08	docs(termux): GPU 结论落地——glibc 侧被驱动版本挡住 ... 实测结论： - glibc Vulkan loader + 自写 ICD 能加载 - Termux glibc Mesa 24.2.6 不认识 Adreno 840（chip 0x44050A31 unsupported） - Arch vulkan-freedreno 26.2.6 能加载但 Linux/DRM 构建找不到设备（缺 KGSL， /dev/dri 对 untrusted_app 被 SELinux 拒绝） - GPU 变体会打印具名错误并自动降级 tiny-skia README.termux 同步：GPU 标 ⛔、MC 走 glibc JVM 的结论与后续路线	2026-11-07 09:33:21 +08:00
AskaEth	c434dbe335	feat(termux): 横屏自适应窗口、安装后清理 apt 工作区、补分支 README ... - app/boot/termux_window：Termux 上默认窗口按 X 屏幕等比自适应 （横屏铺满、竖屏不溢出，最大 2×；日志 source=termux-screen）， ULL_WINDOW_SIZE 覆盖与 1180×760 验收基准不变；5 条单测 - termux::install 成功后清理 $PREFIX/tmp/ull-java-termux（一次安装约 100 MB） - 构建文档补 clippy/rustfmt 组件、cargo-clippy 目标被带成 android 的坑、 门禁命令、横屏行为与 openjdk-17 实测 - 新增 README.termux.md（分支定位/已验证矩阵/快速开始/边界/路线图）， 两份主 README 的 Termux 条目链过去	2026-11-07 09:33:21 +08:00
AskaEth	7b971dc75d	fix(java): Termux 幂等安装报「未走网络」，vendors 在 Termux 上展示 termux 行 ... - termux::install 返回 (home, reused)，复用时 downloaded=None， CLI 不再显示「0 字节 / 0 个文件」 - java vendors 在 Termux 上把 termux 插到顺序最前（仅展示，默认回退序不变）	2026-11-07 09:33:20 +08:00
AskaEth	48d1ee6616	feat(java): Termux 上自动安装系统 openjdk（内置镜像 + 隔离 apt 状态） ... - 新增 game::java::termux：内置 SAU/TUNA/USTC/官方四个 termux-main 镜像， 按顺序 apt-get update+install；lists/cache 隔离在 $PREFIX/tmp/ull-java-termux， 不改用户 apt 配置；装完从 $PREFIX/lib/jvm 定位，幂等（已装则不走网络） - JdkVendor 增加 termux（17/21/25），--vendor termux 只走系统包； Termux 上缺省安装先试系统包，失败再走归档链并带出每一跳原因 - standard_roots 已能扫 $PREFIX/lib/jvm（上一条提交），装完即被 java list 发现 - CLI/presenter 的 vendor 展示与帮助文案同步；设置白名单与契约测试同步 - 文档补 Termux 上的 Java 行为	2026-11-07 09:33:19 +08:00
AskaEth	1e0fc44fed	docs(packaging): 记录 Termux glibc 构建与 termux-x11 运行配方 ... 新增 packaging/docs/termux-glibc-build.md：glibc 工具链（Rust gnu 组件 + patchelf + clang/lld + Debian libgcc crt）、构建环境（LD_PRELOAD/CA/USTC 镜像）、 termux-x11 运行与截图取证、GPU 现状与已知边界。 支持矩阵四处同步：Termux 行从「GUI 未验证」改为「源码自建、CPU 渲染单机验证过」， 仍标注实验级、不在发布矩阵内。	2026-11-07 09:33:19 +08:00
AskaEth	4582a025db	fix(fonts): Termux 上注册 Android 系统 CJK 字体，消除中文方框 ... glibc 构建跑在 Termux 里时 target_os 仍是 linux，fontdb 只扫 Linux 常规 字体目录，/system/fonts 不在其中，中文实例名与界面文案全渲染成方框。 在字体求值入口按运行时识别 Termux，把 NotoSansCJK 等候选注册进 cosmic-text 的字体库（OnceLock 只加载一次，找不到就静默放过）。 app-iced 直接依赖 unlucky-core 复用平台识别，不再本地复制环境判断。	2026-11-07 09:33:18 +08:00
AskaEth	e090c67297	feat(platform): 识别 Termux 宿主并把 $PREFIX/lib/jvm 纳入 JDK 扫描 ... - 新增 platform::termux：用 TERMUX_VERSION / 默认 PREFIX 识别 Termux， 推导 $PREFIX 与 $PREFIX/lib/jvm，不把路径写死进调用方 - java::discover 的 standard_roots 在 Unix 分支追加 Termux 的 JVM 根， 环境可注入（standard_roots_in），补上「Termux 装了 openjdk 但没设 JAVA_HOME/PATH 就发现不了」的盲点 - 单测覆盖识别、负例与扫描结果	2026-11-07 09:33:18 +08:00
AskaEth	ac2e163eb8	Merge branch 'feat/m156guard-fix-bash-e-silent-kill-in-guar'	2026-11-07 09:20:21 +08:00
AskaEth	aa42496561	fix(ci): M156 修 guards.yml 三处 bash -e 静默自杀（presenter-no-ui 从未绿过） ... M155 钉死：guards.yml 的 `hits=$(… | grep -iE …)` 在 grep 零命中（exit 1）时被 runner 默认的 `bash -e {0}` 拖红整步，且脚本里 `set -uo pipefail` 关不掉 -e， 所以一条 `::error::` 都打不出来 —— presenter-no-ui 自 M89 引入起从未绿过一次。 - presenter 依赖树 step：`hits=` 补 `|| true`（零命中回到绿路，真命中仍红） - core 依赖树 step：裸 `tree=$(cargo tree …)` 改 `if ! tree=$(…)` 守卫， 与 presenter / design 两处对称，cargo tree 失败时打注解而不是静默退出 - unsafe-scope：`actual=$(git grep …)` 末尾补 `|| true`，零匹配不再中止整步 - 文件头加一条警示：「本文件所有 run: 都在 bash -e 下，裸管道/裸赋值会被静默杀死」 验证（M155 方法：step 脚本从 yml 原样切出、`bash -e` 执行）： presenter 零命中 改前 exit1/0 注解 → 改后 exit0 打 OK；真命中仍 exit1/2 注解； core cargo tree 失败 改前 exit101/0 注解 → 改后 exit1/1 注解；unsafe 零匹配 改前 exit1/0 注解 → 改后 exit1/2 注解；两处正常路径均仍绿。pyyaml 可解析，398 行。	2026-11-07 09:15:10 +08:00
AskaEth	4bb1591aca	Merge branch 'feat/m152-packlast-finish-modpack-import-expo'	2026-11-07 08:34:11 +08:00
AskaEth	be280c16a3	fix(core): ZIP64 第二道闸不再重复累计预检总量（复审 P2-1） ... 复审在 tip 54c2d75 上实证的缺陷：`container()` 把 `preflight()` 返回的**全量**声明尺寸 当成写循环累加基数，循环里又对每个文件 `+= bytes.len()`，于是真实总量只要过半阈值 （~2.15 GiB）就被误拒，而且拒在内容读出来之后——"闸在内容进内存之前"的性质同时失效。 两处修： 1. 记账拆成独立类型 `Written`，**从清单 JSON 长度起算**，与预检返回值无关；预检的返回值 现在只给测试与诊断看（`let _ =`，文档写明不许当基数）。 2. 内容改成 1 MiB 缓冲流式写进 zip（`COPY_CHUNK`），不再 `std::fs::read` 整份摊在内存里。 第二道闸看的是"已写字节数"，与内存占用解耦；顺带把"拿预检 total 当基数"这类写法 在内存侧也变成无害的小错而不是几个 GiB 的读。 测试（按塔台资源令，默认套件不再真写 2.5 GB）： - `write.rs` 新增 `the_container_does_not_double_count_the_preflight_total`：把阈值注入成 几十字节（`container`/`preflight`/`Written` 都收 `limit`，生产路径恒为 `zip::ZIP64_BYTES_THR`），构造"正确实现 70 < 90 通过 / 重复累计 110 ≥ 90 被拒"的窗口， **0.01 秒**钉住 P2-1；实测把 bug 写回去即红。 - `write.rs` 新增 `the_second_gate_counts_from_the_manifest_length_not_the_preflight_total`： 直接对 `Written` 断言 2.5 GB 不拒、撞阈值必拒。 - `zip64.rs` 的 2.5 GB 稀疏文件端到端用例保留但 `#[ignore]`（真跑要 ~70 秒 deflate 与一大片 内存/页面文件，C 盘页面文件已被上一轮撑到 34.8G），实测过一次成功：条目声明尺寸原样 2 500 000 000、产物只有几 MB。跑法写在该用例的文档里。 门禁：fmt 0 / clippy -p unlucky-core --all-targets 0 / cargo test -p unlucky-core 1033 passed 0 failed（lib 480 passed + 1 ignored）。	2026-11-07 08:22:47 +08:00
AskaEth	d728ed836f	feat(core): M152 整合包收尾——同路径遮蔽逐文件上报 + ZIP64 拒写预检 ... 导入侧把「同名文件冲突」从整包一个策略推进到逐文件事实：同一实例路径被本包多份声明 命中时（跨侧 overrides/client-overrides，或同侧重复），按叠层顺序（Both → Client）定 胜者，其余标 PlanOverride::shadowed（winner / winner_dir / same_bytes），逐条留 pack.import.note.override_shadowed 注记；phase 只遍历未被遮蔽的条目，不再白读字节， 报告里也不再出现"两条 Installed、前一条的哈希其实没落地"。 不新增 FileAction/ConflictReason 变体：这三个枚举被 crates/presenter 的 convert.rs 穷尽 match，而那个 crate 不在本 purpose 的作用域内，所以走既有的 ImportIssue 通道 （与 server-overrides/ 被跳过同一条）。 导出侧那条 ZIP64 闸原来够不着：先 std::fs::read 整个覆盖文件进内存再累加判断，真要 导出 4 GiB 文件的实例，内存先炸、用户永远看不到那句 pack_limits。改成写前按 metadata().len() 做声明尺寸预检，超阈值在任何字节进内存之前就报；写循环里的增量检查 留作第二道。写 zip 的实现搬到 format/write.rs 以守 400 行。 测试：pack/tests/zip64.rs（稀疏文件真跑到 ZIP64 分支，含累计口径与对照）、 tests/import_layering.rs（同路径不同哈希 / 同哈希不同路径 / 叠层顺序 / 基线记胜者）、 unknown_fields.rs 补第 4 条假边（mrpack files[].extra + 未知哈希算法）。 五条变异各自变红（遮蔽 no-op 6 红、按哈希判重 6 红、翻转叠层 2 红、错误码改 io 3 红、 预检不累计则预检单测红且端到端用例从 0.01s 变成 95s/约 4.5 GiB 内存）。	2026-11-07 08:22:47 +08:00
AskaEth	37de00b07e	Merge branch 'feat/m154-verb022-bump-workspace-version-to-0'	2026-11-07 08:16:39 +08:00
AskaEth	06fe12d811	chore(release): M154 版本升到 0.2.2（第一个稳定通道版本，D51） ... - 根 Cargo.toml `[workspace.package] version` 0.2.1 → 0.2.2；`crates/{agent,app-iced,cli,palette-extract, presenter}` 里 9 处 intra-workspace path 依赖的 version 约束一并对齐（M137 既定做法）。`crates/app` 是 workspace `exclude` 的 Slint 退役树，manifest 不参与解析，原样保留。 - Cargo.lock 由 cargo 再生成：只有 8 个 `unlucky-*` 成员条目从 0.2.1 变 0.2.2，第三方依赖（含版本号恰好 也是 0.2.1 的 hexf-parse / windows-link / windows-threading / xkeysym / yazi）一字未动。这一步不是可选： CI 与发布流水线全走 `--locked`（ci.yml:236,274 / release-build.yml:135,142 / make_artifacts.py:50）， lock 不跟就是「tag 一打就红」。 - packaging 文档里的**示例 tag** 跟到 v0.2.2：docs/artifacts-and-version.md 两处（命名规则示例 + 「tag 说 X、产物里写 Y」的事故示例）、docs/build-and-ci.md 三处（`--version v…`、两次 `gh workflow run --ref v…`）、 docs/profiles-and-measurements.md 的「同一槽位现在叫 `unlucky-launcher_0.2.2_windows_x64.exe`」、 make_manifest.py 四处（Usage 示例 / `normalize_version` docstring / `--version` 的 argparse help）。 - **历史注记一律不动**：docs/runtime-deps.md 的「v0.2.1 首次真跑即红在工具链体检」（M140 事故记录）、 `.github/workflows/release.yml:71` 同一事故的另一处记录、`crates/core` 更新模块测试里的样本版本串 （`checker_cases.rs` / `version_cases.rs`，是解析器测试夹具，不是发布事实）、`microsoft.rs:224` 的 `21.0.13.0.2.1` 负例。 - README.md / README.zh-CN.md、packaging/release-notes.md 核实后**无需改动**：三份文件里没有任何写死的 版本号——下载表是 `<version>` / `<版本>` 占位符（M153 刚统一的口径，含非发布档位标「暂未发布」的行， 原样保留未回退），release-notes 正文是 `{{VERSION}}` / `{{SUMS}}` 模板占位符。 验证：`cargo check -p unlucky-cli --all-targets --locked` 过（编译日志里 unlucky-core/agent/cli 均报 v0.2.2）、 `cargo test -p unlucky-cli --lib --locked` 42 passed 0 failed、`cargo metadata --locked --offline` 过（全 workspace manifest + lock 一致）、`python3 packaging/make_manifest.py --self-test` ok、 `ull --version` 实跑输出 `ull 0.2.2（unlucky-cli）`。	2026-11-07 08:13:29 +08:00
AskaEth	c38fbe4068	Merge branch 'feat/m150-ghrsrc-implement-githubreleasesourc'	2026-11-07 08:06:31 +08:00
AskaEth	f001b93942	feat(core): M150 新增 GitHub Releases 更新源（D50） ... D50 定案 GitHub Releases 为唯一更新源，清单地址固定为 `releases/latest/download/manifest.json`。此前 update 模块只有对拍用的 DirSource，这次把真实源补上。 - `update::github::GitHubReleaseSource` 实现 `UpdateSource`：清单从 `<base>/<owner>/<repo>/releases/latest/download/manifest.json` 取， 产物按 D49 命名规则（文件名）拼到同一条 latest/download 路径下；清单里 已写完整 http(s) 地址的原样使用。 - 网络全走 `core::download`，不新造栈：包体交给引擎 `download()`（镜像展开 → 地区判定 → 健康度排序 → 退避 → 续传 → 原子落盘），清单走引擎的 `plan()` + 共享 client 逐候选取文本（与 `game::java` 的一锤子 GET 同一手法）。 两条路径都吃到 mirrors.json 与地区档案里生效的 gh-proxy 前缀。 - 可配置面只有 owner/repo（默认 AskaEth/Unlucky-Launcher）与 base（默认 https://github.com，测试指向本地假服务）；渠道只有 stable 有清单， beta/alpha/nightly 返回 Ok(None)（D50「先只发 stable」），清单 404 也算 「还没发布」而不是错误。 - `UpdateErrorKind` 新增 `Network`：远端取字节失败（连不上/超时/5xx/候选全挂） 与本地 IO 分开——前者可重试，后者重试无意义。引擎把逐源失败压成 AllSourcesFailed，本源从失败摘要里还原「所有源都 404」为 SourceMissing （产物没上传不该被报成网络抖动）。 - 校验仍只有一处：包体请求只带 expected_size，长度/摘要双检留在 `update::verify`（与 DirSource 同口径）。 - 单测 13 条，全程离线（假 HTTP 服务在 127.0.0.1）：固定清单地址、产物 URL 解析、自定义 base/owner/repo、清单 404/非 JSON/字段非法/渠道不符/5xx 各自 归到白名单分类、产物下载、产物 404 → SourceMissing、镜像优先下 gh-proxy 前缀（清单与产物都验）、与 DirSource 同清单同产物选择结果一致。	2026-11-07 08:06:22 +08:00
AskaEth	afdbc9fd51	Merge branch 'feat/m153-docsweep-close-forgotten-doc-findin'	2026-11-07 08:00:04 +08:00
AskaEth	7946e5b804	docs(readme,cli,packaging): M153 清账四条被排忘的文档类 finding ... ① README 两版下载表：linux-x64 / linux-arm64 / macos-arm64 / macos-x64 四行补「not yet published / 暂未发布」标记（与 M143 的 windows-arm64 行同款措辞），表后改成「本版只发布 windows-x64」的口径， 并说明发布 job 只留 PUBLISH_SLOTS 里的槽位（现住 release-publish.yml）；顺带把「produced by the CI matrix」那句改成「矩阵里有、默认发布跑不编、all_slots=true 才编来取证」。 ② packaging/make_artifacts.py 两处 docstring 还写 windows-arm64 是 cross-built：按 M140 后的原生 windows-11-arm 事实改写。（release-notes.md 的同一说法在 M139/M142 已改掉，本次核实无残留，未再动。） ③ cli 缺 id 的 hint：删掉「（id 不进仓库）」并改成与 cli/help.rs 一致的「官方构建已内置、环境变量优先、 自建时构建期注入」；Secret 透传的事实留在同处代码注释。 ④ README 两版文件清单表：release.yml 从「six-slot build / 六槽位构建」改成「两个 Windows 槽位原生 构建 → 只发布 windows-x64；all_slots=true 才整表六槽位取证」。 纯文案，不动任何构建或运行时逻辑。	2026-11-07 07:57:32 +08:00
AskaEth	5c96227881	Merge branch 'feat/m151-relmanif-generate-update-manifest-i'	2026-11-07 07:55:17 +08:00
AskaEth	f9607c1246	docs(packaging): M151 复审 P2-1 两处未决注释按 D51 定案改写（方案甲/六件套/v0.2.2 起适用）	2026-11-07 07:52:50 +08:00
AskaEth	e3ee20bdcd	feat(packaging): M151 发布流水线生成更新清单 manifest.json（D50） ... 清单挂 GitHub Release 资产，固定文件名 manifest.json（D50）。字段形状的权威是 M146 的 crates/core/src/update/manifest.rs（ReleaseManifest，deny_unknown_fields + 逐字段校验）， 生成器只负责把那套形状填对，不另立 schema。 同源，不双写：packaging/make_manifest.py 的每个 sha256 直接读 Release 自己的 SHA256SUMS.txt，size 取自同一批文件的 stat()；产物名里的版本段必须等于 --version， tag 与 Cargo.toml 漂了就没有产物可对，当场失败。CI 在「裁剪发布白名单后重算 SHA256SUMS」之后调它，所以清单描述的是真正要发的资产，不是构建出来的全部。 make_artifacts.py 只加 --manifest 开关，用子进程调同一份脚本（本地跑也产出 manifest.json），本文件继续是产物命名的唯一真相源。 只放启动器产物：DTO 的 Artifact 没有角色字段，Release::artifact_for() 取第一个 target 命中的产物，把 ull 并列写进去会让「覆盖哪个文件」取决于数组顺序；ull 照旧进 SHA256SUMS.txt 与 Release。 url 两种形态：默认裸文件名（DirSource 口径，本地/内网用）；CI 传 --asset-base-url 拼绝对地址并钉 tag（不是 latest），清单里每条都指向与它自报版本相符的字节。 自验：--self-test 用 packaging/tests/manifest.golden.json 逐字节对拍（覆盖裸 exe 与 tar.gz 两种形态，并钉住「ull 不进清单」），再跑 14 条负例证明严格解析不是摆设； 发布步会先跑它再产文件。真 DTO 对拍已在本机用 M146 的 ReleaseManifest 实测： golden 解析通过（2 个产物、min_supported、force 均正确落位），14 条篡改全部被拒。 未决（报告带利弊，未自行改发布默认值）：releases/latest/download/* 只指向非 prerelease 的最新 Release，而发布默认 prerelease=true。 Refs: D50, M146	2026-11-06 22:15:58 +08:00
AskaEth	87ab8783a3	Merge branch 'feat/m149-msabake-bake-approved-client-id-int'	2026-11-06 21:21:30 +08:00
AskaEth	5597a4cc18	feat(release,docs): M149 发布构建烘入微软登录 id（仓库 Secret），文档改为「官方构建开箱即用」 ... 构建侧：release-build.yml 声明 on.workflow_call.secrets.ULL_MSA_CLIENT_ID（required: false）， cargo build 步以 env 注入它，option_env! 把它烘进二进制；release.yml 的 build job 按名显式透传 （与 PUBLISH_TOKEN 同一模式，不用 inherit）。真值放仓库 Secret，不进任何 git 文件；Secret 未录入 或 Actions 之外求值为空串时，client_id.rs 的 blank_env_value_counts_as_missing 保证「空白=没配」， 不会拿空 id 去联网。 文档：README 两版 / help.rs 的 accounts topic / packaging/release-notes.md / packaging/docs/build-and-ci.md 统一成「官方构建已内置登录所需配置、开箱即用，仍可用环境变量 ULL_MSA_CLIENT_ID 覆盖；自建想自带就构建时注入」的功能性口径 —— 不出现 id 本身，也不出现归属描述。 client_id.rs 的模块注释与测试注释同步（原文写「id 不进仓库（用户定案）」，已随 Secret 方案改写）， 并记下「别把 ULL_MSA_CLIENT_ID 导出到跑 cargo test 的 shell」——presenter 的 M132 入口锚会在 已烘焙 id 的构建里故意红。 实测：ULL_MSA_CLIENT_ID=<id> cargo build --bin ull 后，清空 env 跑 ull accounts add msa 打出 用户码与链接（无「未配置」提示）；同二进制设一个假 env id 则 AADSTS700016 点名该假 id（env 覆盖生效）。 单测：core auth 28、unlucky-cli 全套、i18n 30、presenter 222 全绿；M132 锚在烘焙构建里按设计红、 在不带 id 的构建里绿。cargo fmt --all --check 通过。	2026-11-06 21:08:53 +08:00
AskaEth	1c53c29f76	Merge branch 'feat/m147-cifix-repair-ubuntu-red-checks-and'	2026-11-06 20:30:08 +08:00
AskaEth	166342b021	fix(core,design): M147 修掉 test(ubuntu) 剩下的两条红（M144 被 fail-fast 挡住没看见） ... `cargo test --workspace --all-targets --no-fail-fast` 在 docker 里（Debian 12 / rustc 1.99.1） 第一次跑全：app-iced 那条修好后，还有两个 target 各有一条 **Linux 专有**的确定性失败—— M144 只看到第一条，因为 cargo 默认在第一个失败 target 就停。两条都是「夹具/断言按 Windows 语义写死」，不是产品逻辑错。 1. `unlucky-core`：`platform::wallpaper::windows::tests::current_theme_expands_local_app_data_env_var` （crates/core/src/platform/wallpaper/windows.rs:286，460 passed / 1 failed） 夹具用了**混合分隔符**：`LOCAL_APP_DATA` 写 `C:/Users/u/AppData/Local`，而 `CUSTOM_THEME` 写 `C:\Users\u\AppData\Local\…`。探针把 `%LOCALAPPDATA%` 展开后拼上 `\Microsoft\…`，得到 `C:/Users/u/AppData/Local\Microsoft\…`；`FakeIo` 却按 `CUSTOM_THEME` 建键。Windows 的 `Path` 把 `/` 与 `\` 都当分隔符 ⇒ 两个 PathBuf 相等；Linux 不 ⇒ 查不到文件 ⇒ 0 个候选。 修法：`LOCAL_APP_DATA` 改成反斜杠原样（`r"C:\Users\u\AppData\Local"`），展开结果与 `CUSTOM_THEME` 逐字节相同。测试仍能在 Linux 跑，不丢覆盖（不是加 cfg 门躲开）。 2. `unlucky-design`：`color::palettes::tests::accent_on_fixed_neutral_only_moves_the_neutral_hue` （crates/design/src/color/palettes.rs，162 passed / 1 failed） `assert_eq!(Palettes, Palettes)` 做 f64 位相等，而两侧算中性色相的路径不同：一侧取 `NEUTRAL_HUE_DEG` 字面量，一侧经 `atan2()` 现算——glibc 与 UCRT 差 1 ulp （239.51420577630955 vs …964）。这正是 palettes.rs:361-365 那条注释自己警告过的坑。 修法：把「固定中性色相」喂成**种子色相的实测值**（`per_seed.neutral.hue_deg()`），两侧同源 ⇒ 断言保持**逐位相等**（比放宽容差更紧），零额外行。`NEUTRAL_HUE_DEG` 与种子色相的绑定仍由 隔壁 `neutral_hue_is_the_default_seed_hue` 用 1e-9° 容差钉着。 ⚠️ 这里没有照 tower 建议的「1e-9° 容差逐项比」：那个写法在 rustfmt 下要多 9 行，而本文件正好 400 行、顶在 guards.yml 的红线上。改完 399 行（比改前还少 1 行）。 验证（命令与 ci.yml 逐字一致，容器 ull-linux-check:bookworm）： - `cargo test --workspace --all-targets --no-fail-fast` → **exit 0**（原 exit 101，2 targets failed） - `cargo clippy --workspace --all-targets -- -D warnings` → exit 0 - Windows：`cargo test -p unlucky-core --lib` → 464 passed / 0 failed； `cargo test -p unlucky-design --lib` → 163 passed / 0 failed（不回归）	2026-11-06 20:19:03 +08:00
AskaEth	fdb9ebb014	build(packaging): M147 新增 linux-check-docker.sh，本机复跑 ci.yml 的两条 ubuntu 门禁 ... `linux-smoke-docker.sh` 复刻的是 runtime-smoke（能不能真跑起来），本脚本复刻的是**编译期 门禁**（能不能编过 / 测过）：`cargo clippy --workspace --all-targets -- -D warnings` 与 `cargo test --workspace --all-targets --no-fail-fast`，命令与 ci.yml 逐字一致。 为什么值得单独一条脚本：M144 的两条 ubuntu 红只在「Linux + --all-targets + -D warnings」 三件事凑齐时才炸，Windows 本机永远复现不了（那些 `#[cfg(target_os = "windows")]` 分支在 Windows 上都有使用者）。本脚本是「本机提前挡住它们」的唯一通道。 实现：在现成的 `ull-linux-smoke:bookworm` 上只加一层 `cmake` + `ninja-build`（`aws-lc-sys` 缺 cmake 编不过，M144 实测），缓存卷挂 `registry` 子目录（直接挂 /usr/local/cargo 会盖掉 镜像里的 cargo 本体，M62 踩过），Git Bash 路径用 `cygpath -m` 归一。 - `ULL_CHECK_STAGES`（默认 `clippy test`）：两阶段各自跑完再汇总退出码，一处红不掩盖另一处； `ULL_CHECK_FAIL_FAST=1` 恢复首错即停。 - `ULL_CHECK_TEST_ARGS`（默认照抄 ci.yml）：快查用 `-p unlucky-app-iced --lib`。 - 每阶段打印 `<命令> → exit=<code>`，便于与 CI 注解里的码对照。 诚实边界写在脚本头：基础镜像 Debian 12 / runner Ubuntu 24.04，只对齐编译期判定，不覆盖 发行版差异面；也不跑 fmt / build / runtime-smoke。 M147 实测（本机 Docker / ull-linux-check:bookworm / 2026-11-06）： - `ULL_CHECK_STAGES=clippy` → exit=0（1m27s，原 14 条错） - `ULL_CHECK_STAGES=test ULL_CHECK_TEST_ARGS='-p unlucky-app-iced --lib'` → 623 passed / exit=0	2026-11-06 20:07:04 +08:00
AskaEth	ae1410f342	ci: M147 给两个平台的 test 步加取证能力（--no-fail-fast + 注解 + 退出码回显） ... 三条红里 `test (windows)` 至今只有一个「Process completed with exit code 1」——而 cargo 自己的失败码是 101，那个 1 的来源不明（pwsh 包装层洗码 / 进程被杀，两说都未排除）。job log 要登录才能读（匿名 403），但**注解匿名可读**（GET /check-runs/<id>/annotations → 200）。 所以把一条 `cargo test --workspace --all-targets` 拆成两个平台的取证版本，各做三件事： 1. `--no-fail-fast`：cargo 默认第一个失败的 target 就停（M144 实测 Linux 只跑了 7 个 test binary 就退），后面还有没有第二条失败完全看不到； 2. 失败时把 `error` / `failures:` / `test result: FAILED` / panicked 行升成 `::error::` 注解（`%` 转 `%25`，那是 workflow command 的保留字符）——拿不到 job log 时注解是匿名 侧唯一能取到的失败正文； 3. 显式 `echo "cargo exit=<code>"`，把「包装层把码洗成 1」「cargo 真失败（101）」「进程被杀 只给码、零诊断」三种情形分开。 两平台的码从哪来（不能混用）： - Linux 走 bash（默认 shell 带 `-e` + `pipefail`）：先 `set +e` 再自己取 `${PIPESTATUS[0]}` ——那是 cargo 的码，不是 `tee` 的码；不关 `-e` 的话管道一失败就在 tee 之后退出，后面三行 永远跑不到。 - Windows 走 pwsh：`PIPESTATUS` 是 bash 语法，改用 `$LASTEXITCODE`（`Tee-Object` 是 cmdlet， 不会改它）。注解的正则不锚 `error:` 那一支，因为 pwsh 把原生 stderr 折成 ErrorRecord 后 行首可能多一截前缀，锚死会漏行。 两条都以 `exit <code>` 结尾，退出码不再经过管道传递。	2026-11-06 20:07:00 +08:00
AskaEth	8bfabafe8a	fix(app-iced): M147 修掉 Linux 侧 clippy 的 14 条错与写死平台的 α 断言 ... 两条红的成因都是「Windows-only 的东西没有平台门」：Linux + `--all-targets` + `-D warnings` 三件事凑齐时，Windows 专有的 DWM/穿透代码在 Linux 上变成未用导入 + 死代码。 clippy（14 条错，docker 内 exit 101 → 0）： - dwm.rs `set_preference` 的 `#[cfg(not(windows))]` 分支以 `return` 结尾 ⇒ needless_return； 那个块本来就是该 cfg 下函数体的尾巴，去掉 `return`。 - dwm.rs 三常量 + 四读函数在非 Windows 上没有使用者（唯一调用方 `probe::run_one` 的 Windows 版被门着，`transparency.rs` 只 re-export 三项）⇒ dead_code。用**模块级** `#![cfg_attr(not(target_os = "windows"), allow(dead_code))]`： · 逐项 `cfg(target_os = "windows")` 会把它们从 Linux 构建里删掉，本文件那几条与平台 无关的单测（属性号照 Win32 头文件、无效句柄不许表现成成功）就连编译都过不了； · 逐项 `cfg_attr` 要多 7 行，本文件 394 行 → 会顶破 guards.yml 的 400 行红线（现 398 行）。 代价写明在文件头：非 Windows 上本模块的 dead_code 不再报。 - exstyle.rs `use super::raw_ex_style`：唯一使用者 `click_through` 自己按平台门着 ⇒ 补 cfg。 - probe.rs 的 `use super::dwm::{…}`：`CornerOutcome` 与平台无关（`ProbeRow` 字段 + 非 Windows 的 `empty_row`），其余九个符号只服务于 Windows 的 `run_one` ⇒ 拆成两条 use。 - window_alpha.rs `use …RawWindowHandle`：只有 `RawWindowHandle::Win32` 那条臂用它 ⇒ 补 cfg。 test（docker 内 622 passed / 1 failed → 623 passed / 0 failed）： `opaque_or_refused_alpha_never_touches_the_window_style` 里「无效句柄 ⇒ Failed」是按 Windows 语义写死的；非 Windows 走 `transparency::set_layered` 的空实现，如实返回 `Unsupported`。 按平台拆成两条断言（Windows 断 `Failed`，其它断 `Unsupported`），两边都不许表现成 `Applied`/`Opaque`。顺带说明：`dispatch` 的 `layered=false` 那半条断言与平台无关，保留在 两条之外照跑。 验证（本机 Windows + Docker Debian 12，命令与 ci.yml 逐字一致）： - docker `cargo clippy --workspace --all-targets -- -D warnings` → exit 0 - docker `cargo test -p unlucky-app-iced --lib` → 623 passed / 0 failed - Windows `cargo check -p unlucky-app-iced --all-targets` → 无 error/warning - Windows `cargo test -p unlucky-app-iced --lib` → 624 passed / 0 failed / 2 ignored	2026-11-06 20:06:56 +08:00
AskaEth	2e16df0191	Merge branch 'feat/m145-pkgsplit-split-release-workflow-and'	2026-11-06 19:32:47 +08:00
AskaEth	f4cab82c65	ci(release): M145 复审 P2-2 修正过时上下文名（不可达分支的报错文案）	2026-11-06 19:30:10 +08:00
AskaEth	374e168334	docs(packaging): M145 按主题拆分 README（索引 + docs/，节号不变） ... packaging/README.md 也是 400 行整，且安装包与自动更新马上要动发布线。按主题分成 「索引 + 5 份承载文件」，每份 ≤124 行： - README.md 只留真相源声明、§1–§12 的索引表、§11、§12 - docs/artifacts-and-version.md：§1 产物矩阵 + §2 版本来源 - docs/build-and-ci.md：§3 怎么构建 - docs/runtime-deps.md：§4 运行时依赖 + §5 软渲染兜底 - docs/profiles-and-measurements.md：§6 构建档位 + §7 实测 - docs/compliance-support-boundaries.md：§8 合规 + §9 支持矩阵 + §10 已知边界 节号沿用原编号，所以全仓「packaging/README.md §N」式引用（根 README / README.zh-CN / make_artifacts.py / release-notes.md / ci-runtime-smoke.md / release*.yml 注释）都不用改。 搬家由脚本按原文件切片生成，逐行可查：旧 README 400 行全部出现在新位置，唯一改写的 旧行是 §12 清单里那两行（文件清单必须反映拆分后实况）。新增行 15 条：索引段、§3 的 M145 说明、§12 的 5 份新文件行。	2026-11-06 19:29:47 +08:00
AskaEth	e3ee404bd5	ci(release): M145 把 release.yml 拆成编排 + 两个可复用工作流 ... release.yml 已是 400 行整，下一处改动必撞全仓行数红线（guards.yml 的 file-size）。 拆成「触发 + 槽位表 + 编排」的主工作流与两份 `workflow_call`： - release-build.yml：原 build job 的 11 个步骤逐字搬过去，只有四个矩阵键换成同名 inputs（slot / os / build_dir / rustflags）；矩阵仍由调用方 plan 生成并展开。 - release-publish.yml：原 release job 的 6 个步骤逐字搬过去（PUBLISH_SLOTS 白名单、 裁剪、重算 SHA256SUMS、渲染说明、create/edit 幂等）；调用方只留 needs / tag 门禁 / contents: write 的授予，token 走显式透传的 secret，pre-release 三态改读 github.event.inputs.prerelease（dispatch 的 boolean 输入无法表达「空值」）。 on / env / 顶层 permissions / concurrency 与 plan 的槽位表一字未动。 校验：YAML 可解析、actionlint 全仓零告警、12 段 run 脚本全部 bash -n 通过、 逐步骤比对（归一化后）与拆分前完全相同；120 / 233 / 151 行。	2026-11-06 19:29:47 +08:00
AskaEth	57082219ea	Merge branch 'feat/m146-updcore-update-core-without-binding'	2026-11-06 19:27:03 +08:00
AskaEth	2e718af711	feat(core): 新增 update 模块，做与更新源无关的自更新内核 ... 更新源还没拍板，所以先把与源无关的那半边做掉：语义化版本比较、发布清单模型、 渠道准入、下载校验、原子替换 + 回滚。源抽象成 UpdateSource trait（清单 + 包体两个 方法），core 里没有任何 CDN 常量；内置的 DirSource 吃本地目录或 file://，既是测试 实现也是将来 HTTP 源的对照物。 取舍： - 版本比较严格按 semver 2.0 §11：数值比（0.9 < 0.10）、预发布 < 同号正式版、 预发布标识逐段比（alpha < beta < rc 是 ASCII 序的自然结果，不另立阶段权重表）、 构建元数据不参与排序与相等。 - 渠道准入两道判据：清单自报渠道的阶梯比较 + 版本号里的预发布阶段。清单可能写错， 版本号不会，所以正式版渠道即使拿到一份自称 stable 的 rc 也不会提示更新。 - 校验两道判据且顺序有意：先比长度（抓截断，不必读全文件）再比摘要（抓内容错）， 长度要求**恰好**相等；失败即删暂存文件。StagedPackage 只能由 stage() 产出， 于是「未校验的包」在类型上就进不了安装路径。 - 替换跨平台统一成「旧文件改名挪开 → 新文件搬进来 → 失败把备份搬回去」：Windows 上 覆盖运行中的 exe 不存在，改名是唯一可用动作，而改名也可能被不共享删除的句柄拒绝， 所以失败必须能回滚。Unix 也照这个顺序跑，避免回滚路径只有 Windows 被真正跑过。 - core 零 UI 依赖不变：只有 serde/serde_json + 复用的 sha1/sha2，无新依赖， Cargo.toml 未改；不接 presenter、不接 UI。 单测 62 条（crates/core/src/update/tests/）：版本边界、清单校验、渠道准入、 摘要不符、包体截断（短了/多了）、无权限写目标目录、Windows 占用文件、回滚与备份清理。	2026-11-06 19:16:15 +08:00
AskaEth	156abfe38b	Merge branch 'feat/m143-readmearm-mark-windows-arm64-as-not'	2026-11-06 12:35:48 +08:00
AskaEth	152e677b15	docs(readme): M143 下载表把 windows-arm64 标为暂未发布 ... 依据 `.github/workflows/release.yml:291` 的 `PUBLISH_SLOTS: "windows-x64"`：arm64 槽位仍在 矩阵里构建取证，但不进 Release（同文件 300-313 行还会把白名单外的产物裁掉）。用户照旧表去下 `..._windows_arm64.exe` 会 404。 - 两版 README 的 Shape 列加「暂未发布 / not yet published」，行不删（架构支持意图仍在） - 表后补一段可核的理由：CI 的 ARM64 runner 缺 Windows SDK 的 ARM64 导入库，已定位、在修； 并点明 PUBLISH_SLOTS 才是「进不进 Release」的开关，windows-x64 是当前唯一可下载的 Windows 资产 - 不写日期/版本承诺；windows-x64 命名规则与体量描述未动；packaging/README.md 与 release-notes.md 未碰	2026-11-06 12:35:11 +08:00
AskaEth	e4d8b75723	Merge branch 'feat/m142-xi64only-unblock-release-ship-x64-a'	2026-11-06 12:33:51 +08:00
AskaEth	a70e901bea	ci(release): M142 发布白名单只留 windows-x64 + 修掉诊断脚本在 -e 下先退出 ... 1) PUBLISH_SLOTS 去掉 windows-arm64：白名单齐全性检查是「名单内少一档就 fail」， arm64 连试四轮未成 ⇒ Release 永远 fail、x64 编成功也发不出去。arm64 仍留在矩阵里 照跑取证（诊断注解保留），红不挡发布；修好后把键加回这一行即可（一行可逆）。 2) 修 M141 自毁 bug：`shell: bash` 是 `bash -eo pipefail`，脚本里的 `set -uo pipefail` 关不掉 -e，于是 `vc_lib=$(find 不存在的根 | head -n1)` 被 pipefail 判非零后 errexit 当场退出，一条注解都没打（上一轮只剩 exit code 1）。现在显式 `set +e`、每处探测 `|| true`、问题记进 ERRORS、4 行实况快照无论齐不齐都先打完，再由显式 exit 定红绿； 齐全时快照降级为 notice（绿跑也留「探测没坏」的证据）。 3) 新增 arm64 失败收尾注解步骤（`if: failure()`），红在其他步骤时也能说清红在哪、不影响 x64。 4) packaging/README.md §1/§3/§4/§7.5/§9 与 release-notes.md 的 Downloads/Support matrix/ Install 同步为「当前只发布 windows-x64，arm64 待修」。	2026-11-06 12:30:07 +08:00
AskaEth	cc2ecd61e6	Merge branch 'feat/m141-arm64sdk-diagnose-and-fix-missing-a'	2026-11-06 12:18:57 +08:00
AskaEth	241a258e45	Merge branch 'feat/m140-arm64ci-make-windows-arm64-buildabl'	2026-11-06 12:00:01 +08:00
AskaEth	5678683561	fix(release): M140 r1 复审三条 p2 —— vswhere -find 单值、根因措辞、SDK 双根 ... P2-1（真缺陷）：`-find` 是单值参数，老写法 `... "${find_args[@]}"` 一次传 4 个 `-find`，官方定位器只认其中一个（复现：last-wins 下取到 Hostx64）， 所以 round-1 新加的「ARM64 优先 → Hostarm64」在 vswhere 分支上从未执行。 改成每个 pattern 各起一次定位器，不赌取值规则；注释同步为真话。 P2-2（措辞）：README §4 不再声称 v0.2.1 那次是「x64 镜像缺库」——windows-2025 镜像清单里 VC.Tools.ARM64 与 SDK 26100 都在，根因未定论，更像自检的路径探测； §7.4 的 dumpbin 门禁补一句覆盖 windows-latest 与 windows-11-arm 两个镜像。 P2-3（放宽）：arm64 库体检的 SDK 侧也改成两个安装根（Program Files (x86) 与 Program Files），把「路径猜错 → fail-closed 误报」这个正是本次事故的形态再降一档。 行数：release.yml 400 / README 400（均 ≤400）；PUBLISH_SLOTS 未动。	2026-11-06 11:59:31 +08:00
AskaEth	b27e86c65b	ci(release): M140 windows-arm64 改用原生 windows-11-arm runner ... 交叉编译路线在 CI 上从未成功过一次：v0.2.1 首次真跑即红在 「Windows ARM64 交叉工具链体检」（windows-latest 上探不到 VC/SDK 的 ARM64 库），故按文档标准 runner 表把 arm64 槽位改成原生 windows-11-arm（公开仓免费，4C/16G），产物回到 target/release。 - 槽位表：windows-arm64 os=windows-11-arm、build_dir=target/release； 无交叉槽位后 target 键与 rustup target add / cargo --target 一并删掉 - 体检步骤重写为「Windows ARM64 工具链体检」：失败时打印实际探测到的 VS 根、VC arm64 lib 目录、SDK 的 um/arm64 目录；SDK 不再只认 tail -n1 挑出的单一版本（全版本里找） - dumpbin 定位链补 Hostarm64/arm64 分支，按 RUNNER_ARCH 选宿主工具族 （x64 上绝不挑 arm64 二进制），vswhere/find/PATH 三级与硬门禁不变 - packaging/README.md §1/§3/§4/§7.5 同步原生化与冒烟真跑的说法	2026-11-06 11:51:01 +08:00
AskaEth	1a290a15a3	Merge branch 'feat/m139-ciwin-trim-release-ci-to-two-window'	2026-11-06 11:39:14 +08:00
AskaEth	9de51e16af	ci(release): M139 发布 CI 只跑两个 Windows 槽位，整表六槽位改为手动取证 ... build 矩阵从六个槽位裁到 windows-x64 / windows-arm64 两个： - 矩阵改由新增的 `plan` job 生成（`fromJSON(needs.plan.outputs.matrix)`），槽位表只在该 job 里有一份，`mode: ci` 默认编、`mode: probe` 只有 `all_slots=true` 才编； - `workflow_dispatch` 新增 `all_slots` 布尔输入（默认 false = 只跑 Windows）， Linux/macOS 四档保留完整定义与打开办法（改 mode 一行），取证能力没删； - `PUBLISH_SLOTS` 不变（两个 Windows 槽位）；齐全性检查仍按下载下来的产物判， 白名单槽位没编/编挂就 fail，不会因矩阵变小而永远过； - packaging/README.md §1/§3/§4/§9 与 release-notes.md 的 Downloads / Support matrix 同步成「四档默认不构建」，不留「六槽位都构建」的旧说法。	2026-11-06 11:33:52 +08:00
AskaEth	f617f60134	Merge branch 'feat/m137-rel021-bump-to-0-2-1-and-ship-windo'	2026-11-05 21:30:34 +08:00
AskaEth	54b81cbb7f	chore(release): M137 版本升到 0.2.1，发布只发两个 Windows 槽位 ... 版本：`[workspace.package] version` 0.2.0 → 0.2.1，并把全部 intra-workspace path 依赖的 version 约束一并对齐（`"0.2"` → `"0.2.1"`，M121 的教训）。Cargo.lock 里只有 8 个 unlucky-* 成员条目变化。`crates/app` 是 workspace `exclude` 的 Slint 退役树（manifest 连解析都过不了），不参与解析，故原样保留。 release.yml：新增 `PUBLISH_SLOTS` 白名单（唯一开关）＝ `windows-x64 windows-arm64`。 六槽位一律构建取证，release job 先按白名单裁掉 Linux/macOS 四档产物再重算 SHA256SUMS， 所以 tag 触发的 Release 只有 4 个资产 + SHA256SUMS.txt。release job 改成 `always() && !cancelled()`：未验证槽位构建失败不连坐 Windows 发布，真正的门禁是白名单 齐全性检查。将来某槽位真机验过后把它加进那一行即打开。 顺手修掉一处从未生效的门禁：齐全性检查的 glob 用的是连字符形态 （`dist/$prefix-*-$slot*`），对 D49 之后的下划线资产名永远匹配不上，改成 `dist/${prefix}_*_${stem}*`。资产命名规则 / SHA256SUMS / 合规文本并列资产 / `--version` 与 tag 交叉校验一律未动。 packaging/release-notes.md：清掉 v0.1.0 / Slint 时代的说明，Downloads 与 Support matrix 只描述本版实际发布的 Windows 两个槽位（其余标「built by CI, not published」）。 packaging/README.md §1/§3/§9 同步 gate（矩阵加「本版发布」列、§3 写清白名单与打开办法）。 起手顺带把示例 tag 从 v0.2.0 更到 v0.2.1，并把「winit / femtovg」更正为「winit / wgpu」。	2026-11-05 21:30:13 +08:00
AskaEth	a03e90fc1a	Merge branch 'feat/m138-readmepub-reshape-readme-for-the-pu'	2026-11-05 20:59:39 +08:00
AskaEth	a3f26d424b	docs(readme): r1 复审 P2 两条措辞修正（dry-run 口径、导入取消的真实含义） ... P2-1：`--dry-run` 原来写成「file list, total size, source per file」，比实现强。人类 可读输出是按角色的文件数与字节数 + 合计 + 每类一个源链样本 （crates/cli/src/commands/install/report.rs:161-201），逐文件列源是被刻意否决的设计 （crates/core/src/game/install/plan_view.rs:46-49：「只取每类的首个文件做样本……逐文件 列源选择既没用也没法读」）。整份逐文件清单只在 --json 的 data["files"] 里。 P2-2：「安装是真取消」原来挂在整合包条目下，读者会读成「整合包导入也能真停」。实际 导入取消是界面级的：面板收回 + 结果作废，后台导入跑到底（crates/presenter/src/host/ addon/pack.rs:28-42 模块文档原话「取消是界面级的……core 的 ImportRequest 没有取消 令牌」）。真取消是版本安装那条路（crates/presenter/src/host/dispatch.rs:61-88：在飞 文件就地掐断、段边界收手、不登记实例），已移到「版本管理」条目。 中英两版同步改，未动结构。	2026-11-05 20:59:16 +08:00
AskaEth	8ad9792abd	docs(readme): 重排成面向第一次打开的人的次序，并补一张真截图 ... 发布前把两份 README 的次序改成：一句话定位 → 截图 → 现在能用什么（含「还没做」） → 下载与运行 → 从源码构建 → 架构/模块地图 → 许可与致谢。原来的边界说明没删， 拉到对应功能旁边；「还没做」独立成节并写实。 同时按用户令清掉所有 v0.1.0 / Slint 时代的内容（版本考古段、历史 bin 行、Slint Royalty-Free 义务段、crates/app 的模块地图行与构建说明、「翻牌还欠 bin 改名」）。 NOTICE 未动。 内容上纠正了几处「写得比实现强」： - 启动器内的助手没有接真实模型（transport 是脚本化的），原句「chat 在启动器里」 会让读者以为能用；现在明说占位，并把真的那部分（MCP server）单独讲清。 - 「界面文案统一走一份目录」改成本地化边界：守门只扫实例页，且外观面板老控件 仍是硬编码英文。 - 实例页的 新建/导入/复制/打开文件夹/删除、日志页的 打开文件夹、设置帧的 保存/重置/加覆盖 都是没有后端的占位按钮（pages/mod.rs 偏离 #8），写进「还没做」。 - Java 回退链按地区不同，补上 java.vendorPriority 与区间差异。 - 补 ULL_CF_API_KEY（CurseForge 检索的前置，此前全仓文档都没提）。 截图：docs/images/instances-en-light.png（DevDocs/artifacts/m120/03-instances-en-light.png， 1180×760、浅色、英文界面；实例名与档案名均为测试数据，无路径/令牌）。	2026-11-05 20:53:30 +08:00
AskaEth	9cc3260644	Merge branch 'feat/m136-msadoc-update-docs-now-that-missing'	2026-11-05 20:13:33 +08:00
AskaEth	3bc6d76b84	docs(readme,release-notes): M136 缺 client id 的对外文案改成现行行为 ... M132 之后界面已经直接说「微软登录未配置 + 要设 ULL_MSA_CLIENT_ID」并刻意不给重试按钮， 而 README / README.zh-CN / release-notes 还写着「只会弹通用登录失败 + Code: other」—— 那是修前行为。三处改成：标题/正文/Code: msa_not_configured/无重试，并保留「其余失败 仍只给分类文案 + 码，原文只进日志」这半句（那是真的，也是有意的）。	2026-11-05 20:10:10 +08:00
AskaEth	9dedaa6098	Merge branch 'feat/m132-msanotcfg-surface-missing-client-id'	2026-11-05 20:08:55 +08:00