AskaEth/Unlucky-Launcher
1
0 Fork 0
Code Issues Pull Requests Actions 4 Packages Projects Releases Wiki Activity
442 Commits 3 Branches 4 Tags
47ed270293d8e274791a8a41b4bb105a565f58f5
Commit Graph
274 Commits
Author SHA1 Message Date
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 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
worker-modpackpick d568cc6f37 fix(m160-r1): 预检失败不再静默空转 + 写侧条目数闸 + 判据归一 + 冲突页对齐 
复审 reviewer-modpackpick-r1（p2-1items / fix-then-merge）的返工。

P2-1 预检失败被吞掉（错误呈现回归）
- host::import::spawn_scan 在 `scan.error.is_some()` 时**再发一条 PackEvent::Report**
  （`convert::failed_report_of` 把 core 的 ImportError 含 hint 逐字段搬过去），于是页面回到
  既有的「致命 —— 已回滚」结果块，不再落回入口态。
- convert 里把失败报告的组装收成一处（`failed_report` / `failed_report_of` → `failed_report_with`）。
- 证据：`a_failed_scan_still_reaches_the_screen_as_a_report` 断言**事件序列**
  `["scan-with-error", "report-failed"]` + 报告里 code/message 与预检同源（MultiMC
  `formatVersion: 2`，detect 认得、read 才失败）；`a_clean_scan_does_not_emit_a_report` 是对照。
  变异验证：删掉那条 Report 发送 ⇒ 该用例红。

P3-1 写侧补条目数闸
- `WriteLimits` 增加 `entries`（生产口径 = `PACK_MAX_ENTRIES`）；`preflight` 在**读盘之前**
  按「清单 1 条 + 覆盖文件 N 条」判 `count > limit`。
- 证据：`the_write_side_refuses_a_pack_over_the_unified_entry_count`（20001 条声明只放 1 个
  真文件 ⇒ 报 `pack_limits` 而不是 `pack_io`，即闸在读盘前）、
  `the_entry_count_gate_is_the_same_number_as_the_read_side`（两侧同一个数）。
  变异验证：注释掉 `guard_entries` 调用 ⇒ 前一条红。

P3-2 「内容相同」判据归一
- 删掉 `scan::judge` 里与 `merge::decide` 重复的 `disk.sha1 == pack_sha1` 早退，只留
  `decide().reason?`；两处文档互相指路（`merge.rs` 注明这是唯一判据）。
- 变异验证：把 `decide` 的相同分支改成"冲突" ⇒ **8 条**红（含 4 条 scan 用例与 merge 单测）。

P3-3/P3-4 口径与注释
- `TogglePick` 注释改成与代码一致（保留项留在表里，靠 `decisions()` 过滤）。
- `unknown_remote` 的计数与文案统一：判不了的两种来路（补全前没路径 / 有路径但缺 sha1）都算，
  注记载明两者；新增 `a_remote_entry_with_a_path_but_no_sha1_is_counted_as_unjudgeable`。

视觉（tower 看图给的三条）
- 冲突行两种取值都改成**同几何的 pill**（保留=描边、覆盖=tonal），各自右对齐进同宽度的槽 ⇒
  右边缘同一条线；路径列吃 `Fill` 把槽推到行右缘。
- 列表与动作行之间加 8dp 呼吸；分页行的 Previous/Next 用 `Space::Fill` 顶到右端，
  与内容列对齐（不再是右侧一大片留白）。
- 重新出图：C:/Temp/m160-shots/pick-light.png / pick-dark.png。

顺手
- `format/write.rs` 的单测拆到 `format/write/tests.rs`（纯搬移，守 400 行），并把里面两个
  自己拼 `%TEMP%` 路径的用例改用 `TempRoot`（断言红了也不留垃圾）。
- `import_decisions.rs` 的夹具拆到 `tests/decisions_support.rs`（纯搬移，守 400 行）。

证据：fmt 干净、clippy -D warnings 干净、`cargo test --workspace --all-targets -j 4`
= 2512 passed / 0 failed / **4 ignored**（51 个 test binary）；跑前/跑后 `%TEMP%` 的
`ull-pack-*` 计数 1922→1922、`ull-pack-*-zip64-*` 0→0、`ull-import-*` 1360→1360（增量 0），
df 106G→106G 余量不变。
 2026-11-07 13:52:44 +08:00
worker-modpackpick 4defc41e8d feat(m160): 整合包逐文件覆盖/保留决策 + 导入前冲突清单 + 限额口径统一 
主任务（逐文件覆盖/保留）
- core: 新增 import/scan.rs —— 只读预检产出「冲突清单」（目标已存在且 SHA-1 不同才进），
  逐条给路径/来源/两侧体积与哈希；用户删过的、内容相同的、被叠层遮蔽的一律不打扰。
- core: 新增 import/decision.rs —— ConflictDecisions（整批档 + 逐项表，逐项优先），
  缺省档恒为 KeepUser；ImportRequest.conflict_policy 改由它承载，CLI 调用点不变。
- core: phase.rs 的 settle 按 path 取决策；非冲突路径不受决策影响。
- presenter: ImportScanView / ImportConflictView / ConflictDecisionsView（全部保留 /
  全部覆盖 / 逐项{default,items}）+ PackCommand::Scan / PackEvent::Scan；host 新增只读
  spawn_scan，且新实例路径不再提前建目录（target_of 只算路径，prepare_target 才建）。
- app-iced: 导入前冲突清单页（分页 40 条/页、三入口、计数摘要、确认/取消、两行式行布局）；
  预检干净时直接往下导，不打扰用户。出图见 C:/Temp/m160-shots/{pick-light,pick-dark}.png。
- i18n: 新增 18 条 en/zh 文案 + 更新「两者都留」那条口径说明。

限额口径统一
- pack/archive/limits.rs 成为唯一来源：PACK_MAX_ENTRIES/UNCOMPRESSED_BYTES/ENTRY_BYTES
  （20k / 512 MiB / 64 MiB）；读侧 PackLimits::default 与写侧 WriteLimits::production 同源。
- 写侧不再直接用 zip::ZIP64_BYTES_THR；新增单条目闸，于是「能导出的包一定能导入」。
  不等式在 pack/tests/limits.rs 里用 const 断言钉死。

测试临时物泄漏（塔台追加项）
- addon/temp.rs：TempRoot —— Drop 即删（panic 展开同样删），Deref/AsRef 到落点路径，
  under()/at() 支持"子树落点、删父根"。形状照 core::update::tests::support::TempDir。
- addon::pack 与 addon::tests 两族全部改用 TempRoot（含 fixtures::Fixture 持守卫、
  multimc/fabric_instance 等返回守卫）；4 GiB 稀疏文件的语义一字未改，只改"谁负责删"。
- 自证：pack/tests/mod.rs 三条用例（drop 删 / panic 也删 / 子树删父根）。

测试
- import_decisions.rs（11 例）：预检清单、不打扰、逐项决策后的最终文件集、基线记包内哈希。
- roundtrip_three.rs（2 例）：叠层 + 冲突夹具 import→export→import 三轮文件集逐字节一致，
  以及「选保留就按设计分叉」的反向证据。
- pack/tests/limits.rs（5 例）：单条/总量边界、读侧用同一批常量、写出即可读回。

证据：cargo fmt --check 干净；cargo clippy --workspace --all-targets -D warnings 干净；
cargo test --workspace --all-targets -j 4 → 2507 passed / 0 failed（51 个 test binary）。
 2026-11-07 13:52:43 +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 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 cb3ae8556b docs(core): install.rs 模块文档补上 Termux 分支与平台参数不早退 
拆分后模块文档只描述归档链，读起来像「Termux 也走这条」；补一行说明 Termux 的系统包
分支在链之前，以及 `AdoptiumTarget::host()` 失败已改成每家一条降级原因（不再整体早退）。
 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 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 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 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 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 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 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 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 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 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 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 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 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 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 119b49cf83 test(presenter): M132 烘焙了 client id 的构建里让入口锚直接红（r2 P2-1） 
r2 复审实测：`ULL_MSA_CLIENT_ID=fake-0000-test-id` 构建 + 同一处变异 → `ok. 22 passed`。
原因是我上一条写成了 `if is_configured() { assert!(CLIENT_ID_BUILD.is_some_and(..)); return; }`
——`remove_var` 之后 `is_configured()` 等价于 `CLIENT_ID_BUILD` 非空，随后的 `assert!` 判的是
同一条件的反面，恒真、无失败路径，于是锚在那种构建里**绿着失效**。这正是本 mission 要防的
「守门空跑」形态，而我报告里还把它写成了「只允许是这个原因」，与代码不符。

改成 `if let Some(source) = client_id_status().source() { panic!(..) }`：环境变量摘掉后仍
报告已配置，就带着 `source=` 和两条出路（不带 id 构建 / 给 `resolve_client_id` 加接缝）直接
红，逼人做决定。没有 `#[ignore]`、没有开关；正常的「两处都没有 id」构建照旧跑两条真登录流。

验证（贴原生输出）：
- 注入 id + 变异 → FAILED（panic，`source=Build`），旧代码此处是 `ok. 22 passed`；
- 注入 id + 无变异 → 也 FAILED（这才是重点：不是靠变异才红，而是拒绝空跑）；
- 无 id + 变异 → `220 passed; 1 failed`，红的正是这条锚；
- 无 id 正常 → `221 passed; 1 ignored`。
 2026-11-05 20:08:52 +08:00
AskaEth f2149048fb test(presenter): M132 把「缺 client id → 原因码」那行钉进测试（r1 P2-1） 
复审 r1 实测：把 `start_login` / `start_browser_login` 里的 `auth_failure(&error)` 改回
`LoginFailure::Other`，编译通过、884 条测试全绿——也就是说「缺 id 会变成 MsaNotConfigured」
这件事此前只有代码可读。这条正是本 mission 要防的回退，补一条能抓它的锚。

新锚 `a_missing_client_id_reaches_the_login_panel_as_a_config_gap` 不只测 `auth_failure`，
而是**真的起两条登录流**（设备码 + 授权码），从 `JobSender` 收到的第一条 `HostTask::Login`
上断言 `failure == MsaNotConfigured`，并断言原文（含 `ULL_MSA_CLIENT_ID`）仍只在 `message`
里、页面画不出来。零网络：`from_env` 在 id 判定处就地早退，事件立刻到，不需要任何桩。

环境变量是进程级的，所以照 core 的做法串行 + panic 也还原；构建期注入过 id 的构建里
（本仓库 CI/本地都不注入）显式断言「只能是这个原因」后返回，不是 ignore/开关。

测试模块从 `accounts.rs` 拆成 `host/accounts/tests.rs`（`#[cfg(test)] mod tests;`，先例
`dto/accounts.rs`、`host/install.rs`）：`accounts.rs` 400 → 299 行，拆完两边都远离 400 行硬线。
scope 已由塔台批准扩到 `crates/presenter/src/host/accounts/**`。

变异验证（最终代码上重跑）：
- 两处 `auth_failure(&error)` → `LoginFailure::Other`：`221 → 220 passed / 1 failed`（只有新锚红）；
- 还原：222 全绿。

顺手把 fn 指针数组换成一个 `assert_config_gap(name, start)` 辅助函数，
`cargo clippy -D warnings` 的 `type_complexity` 不放过它。
 2026-11-05 20:08:52 +08:00
AskaEth af39efd23b fix(presenter,app-iced,i18n): M132 缺 MSA client id 上屏成「未配置 + 怎么补」 
缺 client id 原来整条链路只给 `LoginFailure::Other`：界面画「Sign-in failed /
完整原因在启动器日志里 / Code: other」，用户得翻日志才知道要设 `ULL_MSA_CLIENT_ID`。

落点定在**账户页登录面板**，不是启动流程：这个失败只发生在 `microsoft_auth()`（两条
登录流的入口）；没配 id 的发布版建不出微软账户，`identity::resolve` 那条启动路径用户
撞不到（只有「有 id 的构建里登录过、之后 id 被摘掉」才可达）。

- presenter：新增 `LoginFailure::MsaNotConfigured`（`msa_not_configured`）。`microsoft_auth`
  改为回 `AuthResult`，`AuthError::Unsupported`（`from_env` 唯一的产出点，零网络）单独成码，
  其余失败照旧走 `classify`。诊断原文仍只进日志。
- i18n：账户域新增 `AccountLoginNotConfigured`（标题）/ `AccountFailureMsaNotConfigured`
  （正文：设 `ULL_MSA_CLIENT_ID=<id>` 或构建时注入，改完重启），golden 同步。
- app-iced：`failure_title_key` 给这一类专属标题；正文按码查表；这一类**不给「重试」**
  （进程内的环境变量改不了，重试必然是同一个错）。
- 测试：`a_missing_client_id_tells_the_user_what_to_configure` 断言 UI 模型里出现「未配置」
  + 变量名 + `<id>` 占位 + `msa_not_configured`，且没有那句「去翻日志」；反向锚
  `a_network_failure_does_not_look_like_a_missing_config` 与
  `only_a_missing_client_id_becomes_the_config_gap_code` 钉住别的失败不许跟着变。

为什么这一类可以上屏：上屏的是 catalog 固定文案（无凭据、无 token、无内部细节），
`DevicePanel::Failed` 里没有 `message`/`detail` 字段，原文在类型上就画不出来；
理由是它的原因本身就是用户的下一步。M117/M119 的「诊断不上屏」约定不动。
 2026-11-05 20:08:52 +08:00
AskaEth 321617861a chore(m135): 删掉死代码 launch::loader_label，修 M134 之后变假话的三处文档 
M134 复审点名、且都在它 scope 外的收尾。

- `presenter/src/host/launch.rs::loader_label` 删除：全仓零调用点（唯一提及是
  i18n 的一条注释），函数体逐字重复 `dto::LoaderKind::label()` 并硬编码「原版」——
  它既是第二份显示词表，又绕过 i18n；留着等于给下一个人示范「照这样写就行」。
  随之无用的 `LoaderKind` import 一并收掉。
- `presenter/src/lib.rs` 的 dead_code 豁免说明不再点名已删函数（否则那行注释指向
  一个不存在的符号）。
- `i18n/src/bridge.rs:65` 注释改指向唯一那份显示词表（`dto::LoaderKind::label()`）。
- `core/src/game/loader.rs` 与 `presenter/src/dto/instances.rs` 两处「显示路径
  没有守卫（已知缺口）」改成 M134 之后的真形态：显示路径是委派（拿 core 的稳定 id
  反查 DTO 词表，没有手写 match 可糊），新种类先在 `dto::LoaderKind::from_core` 编
  不过，糊错的后果由 `loader_kind_ids_are_the_released_contract` 与按 `ALL` 遍历的
  `every_core_loader_kind_reaches_the_tile_as_itself` 钉住。
- `presenter/src/host/game.rs` 无需改动：M134 当时已把它的文档改成新形态，读下来是
  真话（`dto_kind` 的 doc 与两个测试的 doc 都对得上现在的代码）。

验证：fmt --all --check 通过；`cargo test -p unlucky-presenter -p unlucky-i18n`
= i18n 29 passed / presenter 220 passed（1 ignored）；clippy 两 crate --all-targets
`-D warnings` 零告警。删后全仓（含 workspace 外的 crates/app）已无
`launch::loader_label` 引用。
 2026-11-05 19:09:53 +08:00
AskaEth c14543a112 fix(m134): 显示路径的 core→DTO 种类改成委派，不再留手写映射臂 
M126 r3 复审实测：core 加第八家加载器、对外契约与 help 都补齐、只在
host::game::dto_kind 那一支写 `=> Vanilla`，三个 crate 全绿（402/220/42）
而磁贴静默显示「原版」——M122 修掉的用户可见 bug 复活。

- dto_kind 不再是自己一张七支手写 match：种类由 core 的稳定 id 反查 DTO 词表
  （LoaderKind::parse → dto::LoaderKind::from_core，全仓唯一那份映射）。落笔处没了：
  想糊 `=> Vanilla` 的人到这儿没有 match 可写，新种类必须先过 from_core。
- 反查不到（core 的 as_str 与 parse 自相矛盾，物理上做不到）就 panic，不退回「原版」。
- 测试从手抄七支清单换成按 core 的 ALL 遍历：加一家自动进圈，不用记得补一行。
 2026-11-05 19:02:15 +08:00
AskaEth f6b7759aa8 docs(m126 r3): 收窄「唯一一份」的说法，并把 ③ 的承诺改成真话 
纯文档，零逻辑改动（`git diff` 里每一行都是 `//!` / `///`）。

P2-1「唯一一份」不成立：`cli/src/cli/help.rs` 里 `ull help instances` 的词表行是
**会打印给用户看的第二份逐字副本**。四处说法收窄为「源头表在 core + 另一处逐字副本在
help.rs，由 `help_lists_every_stable_id` 按 `ALL` 遍历守着」：`game/loader.rs` 的模块
文档（原「生产代码里这七个串只有一处」）与 `as_str` doc（原「生产代码里唯一一份 id
字面量」）、`cli/commands/instances.rs` 的模块文档（原「全仓唯一一份 id 字面量」）与
`loader_json` doc（原「两样都只该有一份」）、`presenter/dto/instances.rs` 的 as_str doc
与契约测试 doc、`addon/loader/mod.rs` 的两处「唯一真相源」。

P2-2「③ 拦得住静默变原版」对显示路径不成立：`presenter/src/host/game.rs::dto_kind` 里
糊一支 `=> Vanilla`、同时把契约与 help 补齐，三个 crate 全绿而磁贴静默显示「原版」。
现在写的是「③ 拦的是**对外词表**（加种类、改词表都红），但**拦不住显示路径**，那处目前
没有守卫（已知缺口，另行记账）」。

顺带只做排版级的行数回收：loader.rs 400 → 397（≤400，仍留余量）。
门禁：cargo fmt --all --check → FMT_OK（本轮按要求只跑 fmt）。
 2026-11-05 18:09:00 +08:00
AskaEth 14ac0dc248 test(m126 r2): 加一支枚举不更新对外契约现在必然红（集合断言 + help 守卫） 
r2 复审指出「加一家加载器会被逼着表态」只做到一半：编译期只拦「漏 match」，三处消费方
用最省事的 `=> Vanilla` 糊过去既编得过、测试也全绿——新加载器会静默显示成原版，正是本
mission 要消灭的形态（r1 里「Rift 会红」是负样本名字撞上的巧合，不是守卫）。

- presenter 的 `loader_kind_ids_are_the_released_contract` 增加**第 ② 段**：把 core 的
  `LoaderKind::ALL.map(as_str)` 与独立手写的七个 id 做**集合相等**比较。加一支而不更新
  契约 → 红；改词表 → 红。（r1 删掉 `assert!(ALL.len()==7)` 后缺的正是这一环：数组宽度
  只保证「表里那一行写成 7 个」，不保证枚举没多一支。）
- 新增 `cli::commands::instances::help_vocabulary_tests::help_lists_every_stable_id`：
  按 `LoaderKind::ALL` 遍历 `ull help instances` 的词表行，漏写一个新 id 必红（此前
  `help.rs:67` 那段词表没有任何测试，而旧的 `help_documents_the_loader_field_contract`
  只查关键词，加一家新加载器时它照样绿）。
- `addon::loader::tests::vocabulary` 补 `installable_list_matches_the_from_core_mapping`：
  把唯一还手写的 `LoaderKind::all()` 与 `from_core` 认可的集合对齐（不重抄字面量）。
- 模块文档第 ③ 步改成真话：契约测试会拦「改词表」与「加新种类」；但 `=> Vanilla` 这种
  糊法**编得过**，拦住它的是那条集合断言，不是编译器（改名同理，只有契约测试会红）。
- 一并修掉 presenter 那条测试 doc 里指向已被删除的 `MARKERS` /
  `markers_cover_every_kind_that_has_one` 的引用，改指向现在真实存在的守卫。
- loader.rs 从 398 压到 395（≤400，留 5 行余量；拆测试到子模块需要 scope 放宽到
  `crates/core/src/game/loader/**`，超出本任务文件清单，已按规矩记账）。

验收实测（临时加 `Abyss` + 三处 `=> Vanilla` 糊过去，已还原）：presenter 契约测试红
（left 8 项 / right 7 项），CLI help 测试红（漏了 `abyss`）；core 往返测试与安装侧清单
守卫、CLI 的 `json_rows_*` 仍绿（它们本就管别的事）。
 2026-11-05 18:08:59 +08:00
AskaEth a322cfcbfe refactor(core): M126 r1 返工：词表改由宏单表生成，安装侧解析收口 
复审 r1 的三条：

P1（CI 会红）：`const MARKERS: [(LoaderKind, &'static str); 6]` 触发
clippy::redundant_static_lifetimes（`error: constants have by default a 'static
lifetime`）。返工直接**删掉 MARKERS**：标记串就取 `LoaderKind::as_str()`，候选顺序取
`LoaderKind::ALL`，认不认标记看 `has_marker()`——解析表既没有独立字面量，也没有独立清单。

P2-1：「漏加 ALL 不会被任何东西拦住」是真话，之前的 doc 覆盖声明是假的。返工用
`loader_kind_vocab!` 宏从**一张表**一次生成枚举 / `ALL` / `as_str` / `has_marker`：
「加了一支却忘了进清单」在物理上不可能（没有第二份清单可写）。尺寸锚随之删除（`[Self; N]`
的宽度本来就由表决定），`parse` 留在宏外的独立 impl 里。

P2-2：「全仓唯一一份 id 字面量」原先不成立——安装侧 `LoaderKind::parse` 还手写了一份反向
匹配表，并带一个只进不出的 `neo-forge` 别名。返工让 install 侧 `parse` **委派**
`core::game::LoaderKind::parse`，只额外收 `neo-forge`（Modrinth 拼法）这一个输入别名，
并新增 `addon::loader::tests::vocabulary` 覆盖「委派没接错 + 别名只进不出 + 装不了的几家
返回 None」。

测试：core 的 `markers_cover_every_kind_that_has_one` 换成
`every_stable_id_parses_back_to_its_kind`（往返 + 顺序优先级），仍是「改名不可见、只有契约
测试能抓」的分工，doc 里写明。

门禁：fmt OK；clippy -p unlucky-core -p unlucky-presenter -p unlucky-cli --all-targets
-- -D warnings 干净；三 crate 测试 core lib 401 / presenter 220 / cli 41 全 ok。
文件行数：loader.rs 397（≤400）。
 2026-11-05 18:08:57 +08:00
AskaEth be37c17962 refactor(core): M126 加载器稳定 id 词表收敛到 game::LoaderKind::as_str 
M122 把「id → 加载器」的解析收到 core::game::loader::InstanceLoader::parse，但
「种类 → 对外稳定 id」的命名词表还散在多处，其中 install 侧那一份只靠一句「不要改名」
的注释约束，MARKERS 更是第四张无守卫字面量表。

- core::game::LoaderKind 新增 as_str（**全仓唯一一份 id 字面量**）、has_marker
  （穷尽 match：新种类必须表态认不认 id 标记）、parse（as_str 的反查）与 ALL（清单，
  顺序即标记优先级）；MARKERS 的标记串改为取自 as_str，不再是独立字面量。
- addon::loader::LoaderKind::as_str 改成委派（结构映射，无字面量）：安装侧拼出的
  <mc>-<kind>-<loader> 与解析侧从此同源。
- presenter::dto::instances::LoaderKind 的 as_str/parse 委派给 core（to_core/from_core
  是结构映射），删掉第四份词表；CLI 删掉 loader_kind_id 翻译层，直接调 core。
- 测试：core 新增 markers_cover_every_kind_that_has_one（MARKERS↔ALL↔has_marker↔as_str
  逐格对齐 + 按标记串 round-trip + neoforge 先于 forge）；presenter 新增
  loader_kind_ids_are_the_released_contract（七个 id 逐字钉住 + 反查 + 别名隔离）。
- 对外输出未变：真二进制对同一组 7 类实例的 `instances list --json` 输出逐字节相同
  （md5 0341752658ca28e020ba48c31a51a124），人读输出同样逐字节相同。

file 行数：core/game/loader.rs 337→399（≤400 硬约束，文档按密度重排、事实未丢）。
 2026-11-05 18:08:56 +08:00
AskaEth 02c7910ad5 ci(app-iced): M127 把下载页四条像素守门接进 CI（仅 Windows），缺图在 CI 里从 SKIP 改成失败 
- 新增 tests/options_shot/feed.rs：四条断言共用一条「喂图」策略
  · CI（CI 已设置）且 Windows 上缺 ULL_DL_*_SHOT ⇒ 失败并提示「守门未喂图」
  · 非 Windows 上喂了图 ⇒ CI 里也失败（断言按 Segoe UI 标定的行高/墨迹宽度）
  · 本机缺图仍可跳过，但每次都留一句提示
- ci.yml 的 test 作业（Windows 槽）：pages_demo 现出 ready700/chips700/compact736/wide1180
  四张图 → 写进 $GITHUB_ENV → cargo test -p unlucky-app-iced --lib options_shot
  出图与断言两步都带 if: runner.os == 'Windows'；失败时上传四张图便于复盘
- 顺带订正五处文档数字：main 7 整行 / r1 4 整行 / r2 7 整行，并写清第 8 条墨迹是 hint
  （rows.rs ×3、options_shot/ready.rs、tests/view.rs），不动任何断言期望值
 2026-11-05 17:17:43 +08:00
AskaEth 0f26ed3753 fix(app-iced): M125 r2 —— chips 档「还没选版本」不再对半切；宽度表换成实测值 
r1 复审 p2-1：`TailShare::of` 只判档位，于是 chips 档「刚进页面」（面板只有一行
提示）也被五五分——700×760 下列表 8 个版本只显示 4 个、下半块 ≈160px 空画布，
而修前（main）这一态是 7 整行。修法：判据加**面板形态**，`Hint` 在任何档位都钉死，
`Chips` + `Options`/`Install` 才共享。实测回到 7 整行（与 main 同一水位）。

守门：新增 `options_shot/ready.rs`（`ULL_DL_READY_SHOT`，不设 `ULL_DL_DEMO` 出的
700×760 图）：列表区至少读出 6 个版本号。它在 r1 的图上**红**（4 个，原生输出见
mission 报告），在修后图上绿（7 个）。三条旧守门照旧（chips / compact / wide），
chips 与 compact 换修前图仍红。

r1 复审 p2-2：宽度表的实测值改正（同一张 736 图逐项量）：
`1.21` 26（余 6）、`1.20` 28（余 4）、`24w` **29**（余 3）、`All versions` 墨迹画到
x=247（裁切边 248，只差 1px）⇒ 桶标签余量是 **3~6px** 而不是 6；「短标签『全部』= 32
零余量」这条论证的对比强度随之写准（比桶标签的 3~6px 更薄）。
`rails/major.rs` 的表格、`options_shot/compact.rs` 的测试文档一并改成实测值；
「墨迹右边界」那条反例也从 216..244 改成实测 216..247。

r1 复审 p3-1：第二级「全部版本」的图标从网格（与第一级同字形同药丸、像素级同形）
换成文档/清单字形 `IconKind::Logs`，理由与「图标集里没有版本/历史字形」写进
`major_shape` 文档。

r1 复审 p3-2：chips 档最多三层滚动（列表 / 面板 / loader 菜单）作为**已知风险**
登记在 `install.rs` 文档里，并写明为什么「把实例名移出滚动区」本轮不做（要拆
`options::section`，动三个文件，而且改完仍无法验证滚轮冒泡——没有通道）。
 2026-11-05 16:43:35 +08:00
AskaEth 9c623a6fd3 style(app-iced): M125 拆文件时留下的孤儿文档片段（clippy 的 empty_line_after_doc_comments） 2026-11-05 16:03:10 +08:00