100 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
AskaEth	5a59cb33b2	feat(presenter): adopt 的指令/事件/任务接线 + install 那句假话变真话（M223） ... - AppCommand::Adopt(Box<AdoptCommand>)、CoreEvent::Adopt(Box<AdoptEvent>)、 HostTask::Adopt { event, epoch }：三条穷尽枚举各加一条变体（代次独立于安装与 pack）； - dispatch.rs 一条分支、handle.rs 一条分支、state.rs 的 adopt 字段与一条 apply 分支； - host/install.rs 的「还没有接入安装管线…请先在实例页导入已有版本」改成指向真入口： 那里以前是一句假话（实例页根本没有导入动作），现在向导落地了，它才成立。	2026-11-10 19:37:41 +08:00
AskaEth	26e4fbb91d	feat(presenter): 导入已有版本的 DTO 与三条后台线程（M223） ... core 的能力（M221）接进 presenter 的 IPC 面： - dto/adopt.rs：AdoptCommand / AdoptEvent / 六种视图 / AdoptState + AdoptStage。 全部 Serialize+Deserialize，**不 import 任何 core 类型**（契约 §5.4）； - host/adopt.rs：spawn_scan（adopt::scan）/ spawn_adopt（plan 或 adopt），结果经 HostTask::Adopt 回流；core 的候选/计划/结果/失败逐字段搬进 DTO，problems[] 一条不少； - CoreHost 加 adopt_epoch（每条命令 +1、关面板也 +1），连点与迟到的回程不会点亮面板； - 登记成功后补一次 refresh_instances（新实例这一拍就出现在列表里）。 运行目录只从 plan()/adopt() 的返回值取（缺省档可能带 -2 后缀，只有 core 知道用了哪个）； target_notes() 的原文随 AdoptPlanView::notes 上屏，界面不另写一份后果话术。	2026-11-10 19:37:23 +08:00
AskaEth	9ab909d01c	refactor(presenter): 两处纯搬移腾出 400 行余量（events 用例 / AI 栏事件投递） ... events.rs 399 行、state.rs 400 行（AGENTS §3.1 与 §3.9 的零余量贴线文件）。M223 要往 AppCommand/CoreEvent 各加一条「导入已有版本」的变体、往 AppState 加一份事件态，都得先腾地方。 纯搬移、一行未改： - events.rs 尾部 #[cfg(test)] mod tests（80 行）→ dto/events/tests.rs（399 → 321）； - state.rs 的 apply_agent + agent_rail_visible（28 行）→ state/agent.rs（400 → 376）。 方法路径不变（impl 写在子模块、pub use 无需新增），断言一条未动，搬移 diff 可逐行对。	2026-11-10 19:37:23 +08:00
AskaEth	13a317d35c	Merge branch 'feat/m226-fix-instances-module-doc-stale-clai'	2026-11-10 19:36:47 +08:00
AskaEth	938ce9866b	docs(cli): instances 模块文档的约定二限定到 optifine，注明 liteloader 自 M222 可装 ... 同一句假话（optifine / liteloader 都装不了、--loader 只有五个取值）在 cli/help.rs 的那份 已由 55e2f23 修好，这里是第二份副本。现在把限定收窄到 optifine（要跑外部 Patcher，报 loader_unsupported，只能继承进来），并写明 liteloader 自 M222 起可以 `install --loader liteloader`，取值表指向 `ull help install`（原来指向 crate::cli::model——那份字段文档自己 也是旧口径）。认得出仍是七个，装得了是六个。 纯模块文档改动，不动任何断言。	2026-11-10 19:36:38 +08:00
AskaEth	77f73a307f	Merge branch 'feat/m222-liteloader-install-route-and-suppor'	2026-11-10 19:36:09 +08:00
AskaEth	a16aadd467	docs(app-iced): 按 TailShare::of 的真实分支清扫下载页面板注释（r7 三条 + 全量扫） ... (i) 上轮新引入的错误声明 rescope：错误行「恒为 None / 滚动区只有 head+chips」只在**三栏档 + 带版本列表**这一支成立（has_loader_versions() 要求 problem.is_none()）。**chips 档**（可用宽 < 600，TailShare::of 对 Options/Install 无条件 Shared）里 problem 可以是 Some（静态不兼容 / 列表取不到 / 空表三种），错误行会进滚动区且可能被滚走；show_versions() 为假时钉死区只剩 实例名。install.rs 与 options/view.rs 都按这两支分别写清，并注明该行为域由 M227 重设计。 (ii) install.rs 的「显式给对半分档标志」「对半分：面板吃满自己那一半」改成预算优先口径 （与同文件十行上方「不是早期的对半分」不再矛盾）。 (iii) rows.rs 三处：三栏档「照旧钉死」限定为「**不带版本列表**的选项区」；`content` 的 share 说明改成引用 TailShare::of 的真实两支，不再复述「三栏钉死 / chips 各吃一半」； 「只有对半分那一档才按整行取高」改成「只有 Shared（面板先保预算）那一档」。 全量扫附带修正：tail.rs 的 ROW_PITCH / PANEL_BUDGET 账（760 例改成 176/437、900 改成 569； 预算拆成滚动区 76 + 钉死区 153）；options/model.rs 的 has_loader_versions 文档改成预算口径。 零代码零测试变更。	2026-11-10 19:34:15 +08:00
AskaEth	409c742aa8	docs(app-iced): 扫掉 r6 的三处文档残留（B 结构合入前最后一改） ... (a) install.rs 的 panel/panel_with 文档按当前结构重写：`shared` 不再是「对半分」（现为 面板先保预算 + 列表按整行，见 rows/tail.rs::whole_rows）；滚动区实际只有 head + 六枚 chips （菜单 9358668 进钉死区、说明 a6f7974 进钉死区），钉死区 = 说明或标签 + 菜单 + 实例名； 并写明错误行在 Shared 档恒为 None（静态不兼容时不画版本菜单、走不滚动那条路）。 (b) options/view.rs 里「标签与说明都搬到钉死区」自相矛盾：改成「**说明**搬到钉死区； 『安装选项』标签在 Shared 档**删掉**（八审裁决），Pinned 档保留」。 (c) 同文件 section() 文档里「滚动区溢出时被滚走的是错误行」描述的是不可达情形：改成 「滚动区只有 head + chips，用户可见内容不会被滚走（错误行在 Shared 档恒为 None）」。 零代码零测试变更。	2026-11-10 19:34:15 +08:00
AskaEth	33d05689e8	fix(app-iced): 说明只画一份（删滚动区重复）+ 口径三处改真 ... 八审唯一阻断：中性说明画了两份（滚动区 546–557 与钉死区 576–587 像素级相同、重影）。 删掉滚动区那份，钉死区保留；01/02/05 与 900 的说明墨迹带现在只有一条（576–587 / 716–727）。 口径三处： 1. `section` 文档的滚动区内容改成实际（head + 六枚 chips + 错误行）； 2. 旧的「≈150px / 无需滚动」改成八审实测（可见 96–104px、内容 76px、head 墨迹 462–501、 chips 506–537 四角闭合）； 3. 钉死区注释「标签与说明都搬到钉死区」改成事实：Shared 档的「安装选项」标签是**删掉**的 （设计决定，八审裁决），只有说明是搬下去的；Pinned 档仍保留标签。	2026-11-10 19:34:15 +08:00
AskaEth	e2e3c39f61	docs(app-iced): 扫掉 r5 的五处文档漂移（返工链留下的旧描述） ... 1. install.rs 模块文档：删掉「钉页脚本轮没做」（6f87c8b 已做：钉死区现在是菜单 + 实例名）， 三层滚动的第 3 层改引 `version_menu_height`（VERSION_ROWS 已改），并写明「选项区自己滚」 这层是 M222 之后才有的、`Options` 态不再套外层 scrollable（只有 `Install` 态用）。 2. rows.rs：五个 loader chip → 六枚；「实例名那一格滚一下就到」→ 已钉死；分法描述改成 「面板先保预算 + 列表按整行」（PANEL_BUDGET / whole_rows）。 3. rows/tail.rs 的 TailShare 表：两半各 Fill → 面板先吃预算；补上「带加载器版本列表」这一例外行； 判据注释改成「像素由 window_height 算」（view_sized 已接）。 4. rows/tail.rs 的 M222 分支注释：删「仍欠一项 S1b」（107d619 已修、26ec3f4 已换预算公式）， 写清现在 1180×760 = 176px/4 行、900 = 308px/7 行。 5. options/view.rs 控件树示意：改成当前真实顺序（滚动区 = head + chips；钉死区 = 说明/标签 + 菜单 + 实例名），并补上钉死档另走一条路的说明。	2026-11-10 19:34:15 +08:00
AskaEth	7ea3dbf8f0	fix(app-iced): 方案 B——说明与「安装选项」标签撤出滚动区，滚动区只装控件 ... 六审算术：滚动视口 103px < 内容 130px，说明 0 像素 + chip 底边框被裁 2 行。方案 C（标签并排） 不可行——六枚 chip 已占 404px、正文列 424px，并排必横向溢出裁掉第六枚，等于用一个已完成项 换另一个。按塔授权走 B： - **滚动区**（仅 Shared 档）：head + 六枚 chips，间距 X2→X1； - **钉死区**：说明行（有说明时占「加载器版本」标签那一行，否则显示标签）+ 版本菜单 + 实例名。 钉死区高度不变（两者都是一行），列表仍 4 行； - **钉死档保持旧结构**：把标签撤出会让原版面板矮 26px、列表涨到 302px（6.86 行、切出半行）， 实测把 `04` 从 531 挪到 563 —— 第一版就是这个坑，已按此回退。 实测：01/02/05 分隔线 437、列表 **176px = 4.00 整行**、说明墨迹带 y 576–587（真像素）； 04 **531 未变**；03/06 268 未变；900 档 569 / 308px = 7.00 整行。	2026-11-10 19:34:14 +08:00
AskaEth	cb2cffb3ca	fix(app-iced,i18n): 分高改「面板先保预算」+ 说明压成单行（D30 五审一次性重分配） ... 五审：菜单文字/720 列表/44-97 标定/04 都过，但滚动区被压到 82px（宽）/24px（窄）——宽档切 「安装选项」字身、六枚 chip 0 像素。塔裁决停止逐轮调顺序，一次性重分配： 1. **分高从「对半分」改成「面板先保预算」**：`PANEL_BUDGET = 300`（滚动区 128 + 钉死区 136）， `whole_rows = floor((column − LIST_CHROME − PANEL_BUDGET)/44) × 44`。 1180×760：580−97−300 = 183 ⇒ **176px = 4 整行**（原 5 行），面板 307px ⇒ 滚动区 ≈150px； 1180×900：323 ⇒ **308px = 7 整行**（未变）。720 档走 `None`（Fill），未动。 2. **说明压成单行**（`DownloadOptionsLiteLoaderVanillaOnly`）：两行 28px 是滚动区最大的可压项。 en `Vanilla parent only — Forge goes through the CLI` / zh `只叠原版；叠 Forge 请走命令行`； 完整命令行说法留在 `ull help install`。单测断言随之改成「含该句 + 只有一行」并写明原因。 文档按六审要求改口：滚走的是说明/错误行（非控件）；说明变单行后 760 档滚动区已能装下 head+标签+chips+单行说明，**无需滚动**。	2026-11-10 19:34:14 +08:00
AskaEth	6eb7132ab0	fix(app-iced): 加载器版本菜单搬进钉死区（裁切位置由钉死区高度决定，不是首屏分配） ... 四审点破根因：面板的裁切 y 由**钉死区高度**决定、与窗宽无关（1180 与 720 都切在同一处）， 所以上一轮「把说明挪到菜单之后」只是换了被切的对象——菜单容器 642–706 只露 18px、条目文字 一个都没画，说明整块不可见。 按 tower 裁决改成结构方案： - **滚动区**：head（版本 id + 安装按钮）+ 加载器 chips + 中性说明 + 错误行； - **钉死区**：加载器版本菜单（标签 + 菜单，按条目数占高）+ 实例名输入框。 菜单不再依赖首屏剩余高度分配，可达性由结构保证；溢出时被滚走的是说明/错误行（非控件）。 实测（未变的部分也一并核对）：01/02/05 分隔线 **481**、列表 **220px = 5 整行**；04 对照 **531 未变**； 03/06 窄窗 **268 未变**（本轮结构改动没有挤动列表）；900 高加测 569 ⇒ **308px = 7 整行**。 文档按四审改正：`section` 的文档不再写「首屏能装下菜单/切点不再切字」，改成「裁切位置由钉死区 高度决定」；面板结构写清 head 在滚动区、菜单与实例名在钉死区。	2026-11-10 19:34:14 +08:00
AskaEth	0ca28d24ff	fix(app-iced): 版本行节距/列表 chrome 标定重算（44/97）+ 中性说明挪到版本菜单之后 ... 三审给了独立量测，两处都按它的数字收敛： 1. `ROW_PITCH` 278/6=46.33 → **44.0**（278 里含列表与面板之间的 8px `Space::X2`）； `LIST_CHROME` 93 → **97**（列顶 156 → 列表顶 253）。1180×760 分隔线 492 → **481**、 列表视口 **220px = 5 整行**；1180×900 加测 = 308px = 7 整行，三审报的 900 高残影不复发。 2. S7 钉页脚引入的新问题：面板上半块的滚动切点压在字形上（宽窗切「加载器版本」标签上沿、 窄窗把 chips 切成 4px 条）。把中性说明从菜单**之前**移到**之后**——它两行高，排前面正是把 唯一的加载器专属控件顶出首屏的元凶。 顺带纠正一处文档：面板结构不是「头部 + 可滚上半 + 钉页脚」，head（版本 id + 安装按钮）是上半块 的第一个子项、**安装按钮也在滚动区**，只有实例名是钉死的。	2026-11-10 19:34:14 +08:00
AskaEth	954281d71a	fix(app-iced): 版本列表在三栏对半分档按整行取高（S1b/S9） ... 列表视口高度不再是「Fill 剩下的」：正文列高度由仓里已有的 `frame::body_height` 算出， 经 `view_sized` → `body` → `rails::three_column` → `rows::content` 传下来，Shared 档据此 `floor(((h − LIST_CHROME)/2) / ROW_PITCH) * ROW_PITCH` 取整行。 实测（1180×760）：列表 245px → **239px**（分隔线 498 → 492，腾出的 6px 归面板）， `04` 对照**未变**（531 / 278px），720 窄窗**未变**（本来就是 4.0 整行、底缘 0 墨迹）。 两处修正写在提交里： 1. 第一版给所有三栏场合取整，把 `04` 也缩到 239px ⇒ 收窄为只在 `TailShare::Shared` 取整； 2. `rows.rs` 涨到 419 行撞 400 行门禁 ⇒ `TailShare` 与三个标定量纯搬移到 `rows/tail.rs`， `rows.rs` 回到 355 行（门禁 `components::gate` 与全仓扫描都绿）。 `view` 保留 4 参数（`#[cfg(test)]`，只有单测用），产品路径走 `view_sized`。	2026-11-10 19:34:13 +08:00
AskaEth	f29ca609ec	fix(app-iced,i18n): 实例名钉成面板页脚（S7）+ 中文占位符还原（S8）+ 注释实测值（S6） ... D30 r2 视觉二审四条： 1. **S7（新回归）**：S1 的对半分让面板变矮之后实例名被挤出 1180×760 首屏。按 `install.rs` 早已登记的方案改成**可滚上半块 + 钉死页脚**：`install::panel_with(.., shared)` → `options::section(.., scroll)`；`rows::content` 对 `PanelState::Options` 不再整块套 scrollable（那层既把实例名卷进滚动区，也在窄窗产生第二条并列滚动条）。页脚不参与滚动， 可达性由结构保证，S2 随之关闭。 2. **S8**：`catalog/download.rs` 与金表同一行的中文命令占位符 `<Forge 版本 id>` 照抄不可执行， 还原成 `<forge id>`（两处一起改，金表顺序未动）。 3. **S6**：`rows.rs` 里「两半各 ≈215px / 列表 4.6 行」的估算换成实测（列表 245px = 5.29 行、 面板 237px、分隔线 y=498），并写明 S1b 仍欠一项与其正确落点。 **S1b/S9（列表底缘整行）本轮没修成**：试过 `responsive` 拿「分给列表的高度」再 floor， 实测无效（`Fill` 子项上拿到非确定高度，量测显示列表区最后墨迹行仍在分隔线前一行），已回退， 不留无效代码。正确落点是把列表可用高度从 `pages/download.rs` / `rails.rs`（都在 scope 外） 传进 `rows::content`。 测试：`-p unlucky-app-iced` 862 passed、`-p unlucky-i18n` 36 passed（金表改动后仍绿）。	2026-11-10 19:34:13 +08:00
AskaEth	cd7813f8eb	fix(app-iced): 选项区变高时与版本列表对半分（S1）+ 中英出图注入 + 注释同步 ... D30 r1 视觉驳回的三条里，代码能修的两条： 1. **S1 版面**：带加载器版本列表的选项区在三栏档把版本列表从 6.0 行压到 2.4 行（1180×760 实测 278px→110px，底缘切在第三行图标上）。`rows::TailShare::of` 现在让这类面板在**任何档位** 都与列表对半分（`scrollable` 分支早已存在），另把加载器版本菜单改成**按条目数**占高 （1 条 64px / 2 条 112px，原先只有 1 条也固定撑两行）。实测：列表回到 **245px = 5.3 行**。 2. **注释同步（S6）**：`options/view.rs` 模块头原先写「加载器分成两行」+ 两行示意，实际是 六枚一行（末枚右缘约 404px / 正文列 424）；那条「本轮无看图通道，未出截图」也换成实测值。 顺带（使能中文出图）：`pages/mod.rs::demo_model` 读 `ULL_DL_LANG=zh` 把 `model.lang` 与下载页 目录一起切中文。之前 `LC_ALL=zh_CN.UTF-8` 对出图**完全无效**——页面文案来自 `model.lang`， 而 `Model::new` 写死 `En`、`demo_model` 不碰它（`i18n::detect_env` 不在这条链上）。 测试：`options/s1_tests.rs` 新增两条（菜单只按整行占高；带版本列表的选项区在每个档位都 Shared， 原版/不兼容仍 Pinned），`-p unlucky-app-iced` 862 passed。 未完成：S2 窄窗「滚到底」图——iced 0.14 没有自由函数 `scroll_to`，程序化滚动要手写 `widget::Operation`（约 40 行），本轮不拿半成品充数；面板 `scrollable` 的稳定 Id 已就位。	2026-11-10 19:34:13 +08:00
AskaEth	841c17152a	test(app-iced): 下载页加 options-liteloader 出图取样点（D30 视觉取证） ... M222 的视觉门禁一直缺图：本机没有看图通道，但**出图通道可用**（`--software-renderer` 走 tiny-skia CPU 后端，无桌面也能落盘）。下载页早有专属夹具 `ULL_DL_DEMO`（`demo.rs`，产品路径 不读），M105 就用它出过安装选项区三态，所以这里加第四个取样点，而不是再造一个平行 env： ULL_DL_DEMO=options-liteloader pages_demo --screen=download --width=1180 --height=760 \ --screenshot=out.png --screenshot-theme=light --software-renderer 取样点是「选中 1.12.2 + LiteLoader」（官方版本表只到 1.12.2），走**产品那条真转换** `Download::from_snapshot`：chip 行、中性说明「只叠原版」、确认键状态都是产品行为。 版本列表**只在本次状态里**补一条 1.12.2——不动 `demo_versions()`，因为那是别处基线图的行集 （`tests/view.rs` 钉着 8 行）。 四张图与真假表落在 `DevDocs/artifacts/m222/`（git 忽略区，不入库）：浅色 / 深色 / 720 窄窗 / 原版对照，README 里写明哪张证明什么、哪些是夹具、哪些是产品真转换。图的内容判定未做—— 出图者无图像能力，交给视觉 reviewer。	2026-11-10 19:34:13 +08:00
AskaEth	7d43f1d686	fix(cli): help instances 里把「install 不接受 liteloader」改成只限 optifine ... M222 让 `install --loader liteloader` 可用后，`help instances` 那句「optifine / liteloader 只能由 别的启动器装好后继承进来」的后半句就成了假话，而且与同文件 `help install` 的记载 （`--loader` 取值含 liteloader、optifine 报 loader_unsupported）自相矛盾。 现在这条限定只落在 optifine，并注明 liteloader 自 M222 起可装。`kind` 仍是「认得出」的口径—— 这句话的主体（kind=vanilla 只表示 id 里没痕迹、权威结论要读 libraries[]）没动。 无测试断言过旧措辞：`help_vocabulary_tests::help_lists_every_stable_id` 只按 `LoaderKind::ALL` 遍历「id 出现在文案里」，新文案两个 id 都在，因此不需要同步改期望。	2026-11-10 19:34:12 +08:00
AskaEth	04a123deab	fix(app-iced,presenter): 修 clippy -D warnings 抓到的三处（文档注释位置、manual_range_contains、单元素 for） ... 1. view.rs：我删掉手写 `LOADERS` 常量后，那段文档注释落到了 `VERSION_ROWS` 头上并留了空行 （clippy::empty_line_after_doc_comments）。说明本身是给「chip 顺序为什么委派」用的， 改成普通 `//` 注释，不冒充某个条目的文档。 2. model.rs：LiteLoader 的版本区间判定改成 `((1, 5, 2)..=(1, 12, 2)).contains(&version)` （clippy::manual_range_contains），语义一字未变。 3. install_tests.rs：只剩 OptiFine 一家后，单元素 `for` 改成直调（clippy::single_element_loop）。	2026-11-10 19:34:12 +08:00
AskaEth	3114fa2d4f	fix(core): 首轮编译/测试抓到的四个问题（BTreeMap、测试模块布局、display_loader_version、未用 import） ... 1. liteloader.rs 拆文件后漏了 `use std::collections::BTreeMap`（`loader_library` 里用）。 2. `tests/liteloader.rs` 是 **crate root**，`mod guards;` 会被找去 `tests/guards.rs`； 改成 `tests/liteloader/main.rs`（与 `tests/game/main.rs` 同形），target 名仍是 liteloader。 3. `display_loader_version` 去通配时丢了 NeoForge@1.20.1（forge 布局）去前缀的语义： 既有用例 `neoforge_1201_uses_forge_layout` 当场抓住（1.20.1-47.1.106 → 47.1.106）。 现在按「加载器 + 是否 forge 布局」显式决定，四家原有行为逐字不变。 4. `dto/instances.rs` 的 `pub use super::LaunchArgsView` 在非 test 构建里没人用（-D warnings 会红）， 改由 `dto/instances/tests.rs` 直接 `use crate::dto::LaunchArgsView`。 顺带修两条**我自己写错的测试期望**（不是产品 bug）： - 取消用例里那条 `resolve` 断言用错了父版本表（父版本在内存表里，当然解析成功）； - 新式父链用例误以为 `minecraftArguments` 会是 None，实际会沿链继承祖父层那份 —— 断言改成「继承来的 legacy 串里不许出现 LiteLoaderTweaker」。	2026-11-10 19:34:12 +08:00
AskaEth	51ea32284d	docs(core): inherit::merge 里写清 minecraftArguments（子覆盖父）与 arguments.game（追加）的区别 ... M222 的准入条件就是这条；不给结论留档，下一个人还会以为「叠一层」随便往哪个字段写都行。	2026-11-10 19:34:12 +08:00
AskaEth	c311032080	chore(cli): report_loader 测试里省一行，给 400 行硬线留出余量	2026-11-10 19:34:11 +08:00
AskaEth	0eaefebf3b	fix(core): 同一 loader 版本 id 撞两条父链时具名报错，不覆盖盘上清单（旧实例会静默换父链）	2026-11-10 19:34:11 +08:00
AskaEth	9c6b5eaa9b	chore(core): 去掉 liteloader 集成测试与 versions.rs 里未使用的 import（-D warnings 会红）	2026-11-10 19:34:10 +08:00
AskaEth	c8bf536c37	feat(app-iced): 下载页在选 LiteLoader 时给中性说明（GUI 只叠原版、Forge 组合走 CLI） ... 新增 Key::DownloadOptionsLiteLoaderVanillaOnly（中英各一句，不含花括号占位符）； 金表按 Key::ALL 的真实位置插入（DownloadOptionsNeedsAtLeast 之后、DownloadCancelled 之前）， 只加新键不重排旧键。说明走 OptionsView 的新字段 note，不塞 problem（那是错误色 + 禁用确认）。	2026-11-10 19:34:10 +08:00
AskaEth	7ed954f7fa	fix(core): LiteLoader 快照仓固定为 repo.mumfrey.com/snapshots（1.10.2 的 repo.url 是 /repo/ 形态，照它会 404）	2026-11-10 19:34:10 +08:00
AskaEth	944b1610c8	feat(core): LiteLoader 安装路线（官方版本表 + 从零合成 launchwrapper 清单） ... 按 M218 SURVEY-p1 §4.1 的清单接上 LiteLoader 的安装路线，不动 OptiFine。 - core: 新增 addon::loader::liteloader（官方 versions.json 解析 + 合成清单）与 addon::loader::parent（父版本链读盘定位原版版本）；LoaderKind 加 LiteLoader； LoaderRelease 加 parent_version_id、LoaderPlanInput::vanilla_installed → parent_installed； LoaderInstallPlan::build 改返回 Result（父版本缺失具名报错）；LoaderSource::resolve_on 支持指定父版本（仅 LiteLoader，其它组合具名 unsupported）。 - 继承边界（本 mission 第一步核实）：arguments.game 父在前子在后追加，minecraftArguments 子覆盖父，启动顺序 legacy(24) → arguments.game(25)。所以 tweakClass 只写 arguments.game， 绝不写 minecraftArguments（会顶掉 Forge 1.12.2 的 FMLTweaker）。 - maven/fabric 的 `_ =>` 通配改成穷尽分支：非 maven 族不再静默回落 Forge 的仓库； maven::{metadata_url,installer_url} 改返回 Option<String>。 - presenter: supported() 收 LiteLoader、wizard_choices 六选、dto::instances 按关注点拆成 instances/{loader,runtime,create,tests}.rs（原文件 395 行，动手前先拆）。 - cli: --loader 区分「认不出」(loader_unknown) 与「认得但装不了」(loader_unsupported)； <version> 位写加载器版本 id 时按父版本处理（只有 liteloader 接受）；help 只改 install 段。 - app-iced: 下载页加载器 chip 加 LiteLoader（1.5.2~1.12.2，两头按官方没有构建拒）， chip 清单改为委派 Loader::ALL。 - 测试: 真实响应的裁剪夹具（dl.liteloader.com 与 repo.mumfrey.com 的 maven-metadata） 驱动「解析→计划→落盘→继承→启动参数顺序」全链；Forge 父链有回归（FMLTweaker 必须还在 且排在 LiteLoader 之前）；父版本缺失/组合不支持/取消/坏表各自具名错误。	2026-11-10 19:34:09 +08:00
AskaEth	307d29239a	Merge branch 'feat/m225-fix-liteloader-mirror-404-and-repo'	2026-11-10 14:32:13 +08:00
AskaEth	146eb3d8db	fix(download): LiteLoader 不再套 bmclapi 改写，Central 库接上 bmclapi/maven ... bmclapi-liteloader 改成 enabled=false（规则保留作形状留档）：2026-11-10 实探 `apply()` 的真实产物 https://bmclapi2.bangbang93.com/maven/versions.json 404 / 9 B、 /maven/com/mumfrey/liteloader/1.7.10/liteloader-1.7.10_04.jar 404 / 9 B、 /maven/com/mumfrey/liteloader/{maven-metadata.xml,1.12.2-SNAPSHOT/maven-metadata.xml} 全 404 / 9 B；官方 dl.liteloader.com 的 versions.json 200 / 49129 B、artifact 200 / 533903 B。引擎遇 404 只会白丢一次请求再前进（NotFound 不重试），官方不可达时 更是直接失败，所以镜像优先用户不该再为每个 LiteLoader 文件试一次镜像。 新增 bmclapi-maven-central（repo1.maven.org/maven2 → bmclapi/maven）：bmclapi 的 /maven 不只是 libraries.minecraft.net 的镜像，Central 的路径逐字节一致（asm-all 5.2 247787 B、gson 2.10.1 283367 B、log4j-core 2.17.1 1790452 B，sha1 逐一相同），不存在 的坐标两侧都是 404（镜像回 9 B 纯文本，没有「200 + HTML」假阳性）。 快照仓 repo.mumfrey.com 不加规则：bmclapi /maven、maven.aliyun.com/repository/central、 repo.huaweicloud.com/repository/maven 对 com/mumfrey/liteloader/1.12.2-SNAPSHOT/ maven-metadata.xml 全是 404，只有官方 200 / 358 B，所以只登记探测结果、不铺未验证的规则。 测试：新增 liteloader_urls_stay_official_only（镜像优先模式也只出官方一条，把 enabled 翻回 true 的变异实测会红）；library_urls_expand_to_the_maven_subpath_on_bmclapi 补 Central 用例；形态判据的 EXPECTED 表加 bmclapi-maven-central。不探外网。 version 保持 3 不升 4：download/jdk_sources.rs 与 tests/game/java_vendor_chain.rs 两处 pin 了 version == 3，后者不在本 mission 的 scope（第一轮 workspace test 就是被这条 pin 抓红的），升版留给专门一轮；规则改动与探测记录写进 mirrors.json 的 notes。	2026-11-10 13:56:58 +08:00
AskaEth	54995a4af8	Merge branch 'feat/m221-adoptcore-existing-versions-read-on'	2026-11-10 12:57:03 +08:00
AskaEth	347a3cc90d	fix(game): 复审 r2 三项——Win32 尾点/尾空格别名 + 写面与游戏树重叠 + 更高祖先断链 ... r1 五项里 R4/R5 与 slug/大小写等直接案例已由 r2 复审独立通过；这三条是它补证出的**剩余边界**， 只做限定修复，不推翻重写： r2.1（未存在认领路径的 Win32 尾点/尾空格别名）：比较键新增 `fspaths::comparison_real()`—— 已存在前缀用 `canonicalize`，**尚不存在的尾段按平台语义归一**：Windows 普通路径折叠尾 `.`/空格 （`Foo.` 与 `Foo ` 都是 `Foo`，Win32 建目录时就这么做），**verbatim 路径（`\?\…`）不折叠** （那是另一个物理目录，合法）。原先 `dir_key` 只统一分隔符与大小写，于是一个尚未创建的 `custom` 认领 `Foo.` 与缺省派生 `Foo` 键不相等却被判定「不撞」，两个实例共用一个运行目录。 r2.2（`data`/`.ULL` 整体映射到受保护游戏树时仍静默外写）：新增 `fspaths::ensure_surfaces_clear_of_game_tree()`——默认写盘面（`.ULL`、`config/`、 `config/instances/`、`profiles.json`、`data/`，以及缺省档的运行目录）**解析后不得落进游戏根**； `plan`（dry-run 也报）与 `adopt`（写盘前）各核一次，重叠即 `adopt_write_surface_in_game_tree` 具名拒绝并提示把数据目录挪到游戏树之外。整体迁移到游戏树**之外**照旧允许（判据是落点不是链接）。 配置写面判据同时收窄职责：`ensure_config_write_surface` 只管「在 `.ULL` 内」， 不再带「`.ULL` 在游戏根里」的豁免特例——重叠由上面那条统一负责。 r2.3（游戏根更高祖先断链仍当空列表）：`scan` 的 `NotFound` 分支改为沿祖先找**最近的已存在入口**， 它能 `lstat` 到但 `canonicalize` 不出来（断链的符号链接/目录联接、目标被搬走）⇒ `adopt_versions_unreadable`；一路到盘根都不存在才是「真正的新数据根」，空结果仍允许。 原先只查 `versions` 与游戏根两层，迁移联接在更高层断开时会误报空库。 新错误码：`adopt_write_surface_in_game_tree`（CLI hint 与 help 拒绝清单同步）。 验证（持久日志在 `target/m221-r2/`，git 忽略、不入库；上一轮 `target/m221-r1/` 证据未覆盖）： - `cargo fmt --all --check` 0；`cargo check -p unlucky-core -p unlucky-cli --all-targets` 0； - `cargo test -p unlucky-core --test adopt` **43 passed / 0 failed**（另跑一次 `ULL_ADOPT_TEST_SYMLINK_REQUIRE=1` 同样 43 passed）； - `cargo test -p unlucky-cli --test adopt_test` **13 passed / 0 failed**； - `cargo clippy -p unlucky-core -p unlucky-cli --all-targets -- -D warnings` 0； - 额外：`cargo test -p unlucky-core --lib` **778 passed**、`cargo test -p unlucky-cli` 全部目标通过； - 三次**实现-only 变异**（不折叠 Win32 尾点尾空格 / 不核游戏树重叠 / NotFound 直接当空） 全部以**断言红**收场（1 / 4 / 2 条失败，非编译错误、非环境错误），每次还原后与基线逐文件一致， 收尾再跑 core+cli 双绿。 界限：只覆盖 core+cli 的定向目标（不等于 workspace 全量）；没有启动真实 Minecraft；GUI 未接； 判据是检查那一刻的快照（TOCTOU 看不到）；Win32 8.3 短名与非 junction 重解析点未覆盖。	2026-11-09 23:56:02 +08:00
AskaEth	8110cde3f5	fix(game): 复审 r1 五项——运行目录不许被两实例共用 + 配置写面越界 + versions 断链 + 链接守卫反转 + 快照漏目录 ... 复审 p2-5items 的五项，全部按「先能红的用例，再改实现」： R1（默认目录可被不同实例隐式共用，产品缺陷）：新增 `adopt/run_dir.rs`——登记前读**每个已有实例** 的 `gameDir`（现役设置 + M27 前档案的遗留字段），用「真实路径 + 拼回不存在的尾段 + 大小写归一」 （Windows/macOS）比较；撞上就顺延 `<base>-2/-3…`（上限 32，撞满 `adopt_no_free_run_dir`）并在 `notes` 点名撞的是哪个实例；**非空且无人认领**仍拒绝（那是用户数据，不偷偷换目录）。这样 `Better MC` 与 `Better-MC`（slug 同名）、Windows 上 `Foo` 与 `foo`（同目录）都不会共用一个运行目录。 大小写归一在 macOS 上是**保守**选择：大小写敏感卷上会多一次顺延，换来的是「绝不共用」在任何卷上成立。 R2（配置写面 junction 写穿到外部游戏根，产品缺陷）：`run_dir::ensure_config_write_surface()` 在 `plan`（dry-run 也报）与 `adopt`（写盘前）各核一次——`config/`、`config/instances/`、 `profiles.json` 的真实落点必须在 `<.ULL>` 内，且**不得经链接落进游戏根**（错误按真实归属分类： 「逃出 .ULL」vs「落进游戏根」）。`.ULL` 本身在游戏根内是布局事实，附加判据在该布局下零判别力， 主判据仍然拦下一切跑出 `.ULL` 的落点——这不是给链接开后门。新码 `adopt_config_surface_unsafe`。 R3（dangling versions 被当不存在，产品缺陷）：`scan` 的 `read_dir` `NotFound` 再三分—— `lstat(versions)` 看见入口（断链符号链接/目录联接/目标被移走）或游戏根解析失败（祖先断链）⇒ `adopt_versions_unreadable`；两者都不是才算「真没有」。`inspect` 也补了同族判据（条目存在但 不是可读目录 ⇒ `directory_unreadable`，不再混成「没装」）。 R4（强制链接测试逻辑反转，假绿）：`fixture::link_gate(created, required) -> Run|Skip|Fail` 是纯 真值表，`link_guard_with()` 显式传参（`link_guard()` 只读环境变量）；新增 `link_guard_executes_all_three_branches` 用 `catch_unwind` **执行** Fail/Skip 两个分支。 四处调用点统一走 guard；建链接/联接的夹具收进 `fixture.rs`。 R5（快照遗漏目录节点，假绿）：新增 `tests/adopt/snapshot.rs`——全节点快照（根/目录/文件/链接 各记类型 + 适用 mtime；目录记 mtime、链接只记目标不跟随、Windows 用重解析点属性认 junction、 读盘失败直接 panic）。**CLI 测试用 `#[path]` 复用同一份**，判据只一处；新增 `fixture_cases` 五条工具自测，`plan`/dry-run 的零写盘判据改用 `snapshot_opt`（连空目录都不许出现）。 验证（本轮持久日志，`target/m221-r1/`，git 忽略、不入库）： - `cargo fmt --all --check` 0；`cargo check -p unlucky-core -p unlucky-cli --all-targets` 0； - `cargo test -p unlucky-core --test adopt` **37 passed / 0 failed**（另跑一次 `ULL_ADOPT_TEST_SYMLINK_REQUIRE=1` 同样 37 passed）； - `cargo test -p unlucky-cli --test adopt_test` **11 passed / 0 failed**； - `cargo clippy -p unlucky-core -p unlucky-cli --all-targets -- -D warnings` 0； - 四次**实现-only 变异**（缺省不查认领 / 配置写面不核 / versions 的 NotFound 当空 / 快照不记目录） 全部以**断言红**收场（不是编译错误、不是环境错误），每次还原后与基线清单逐文件一致，收尾再跑绿。 界限：只覆盖 core+cli 的定向目标（不等于 workspace 全量）；没有启动真实 Minecraft；GUI 未接； 判据是检查那一刻的快照，TOCTOU 与非 junction 重解析点仍列边界。	2026-11-09 23:13:57 +08:00
AskaEth	9f5c001387	feat(game): 从其他启动器只读登记已有版本（ull instances scan|adopt）+ 登记可一并定隔离档（M221） ... 盘上已经铺好的版本（多半是 PCL/HMCL 装的）今天在 ULL 里看不见，用户只能重装一遍。这个 commit 把它们登记成实例，**只读外部、只写自己的配置**：不搬文件、不补清单、不改任何外部 文件的 mtime（versions/ libraries/ assets/ 一个字节都不写）。 core（`game::adopt`，新模块）： - `scan` / `inspect`：只读扫描 + 逐项检查，坏 JSON（带行列号）/ 缺 id / id 与目录名不一致 / 缺父 / 成环 / 读不出来 / 越界 / 同名冲突一律**结构化**报错（稳定 `code`），不吞成空列表； `versions/` 不存在才是空结果，读不了就是错误； - 越界判据用 canonicalize 后的前缀比较，同时覆盖**符号链接、Windows 目录联接（junction）与 祖先链接**（junction 不需要管理员权限，是最常见的「把别人版本目录挂进来」）；越界条目在 边界检查就停手，一个字节都不去读； - `plan`（零写盘，喂 dry-run 与后续 GUI 预检）/ `adopt`（plan + 只写自己的配置）： **缺省运行目录落 ULL 数据区 `<data>/instances/<实例目录名>`（custom 档），绝不沿用全局 `isolated`**——那条缺省的运行目录正是 `versions/<versionId>/`，会在他人的版本目录里长出 mods/saves/config；`shared` / `isolated` 必须显式选，且 `target_notes()` 给出后果话术； - 缺省运行目录已存在且非空 ⇒ 拒绝（不覆盖、不猜「合并进已有实例」）；数据区里已有的祖先 若解析到数据根之外（符号链接/联接）⇒ 拒绝，不沿它写盘； - 登记与隔离档一次写清：`install/instance` 拆出 `register` 子模块，新增 `register_with(InstanceSettings)`；写盘顺序改成「先实例设置、后 profiles」（中断只留孤立 设置文件，不会留下按全局档启动的实例），profiles 写失败会撤掉刚写的设置。`register` 签名与行为不变（`register` = `register_with(inherit)`；同版本同名的幂等复用照旧）。 CLI： - `ull instances scan`（只读列出候选与原因）、`ull instances adopt <version-id> [--name N] [--isolation shared|isolated|custom] [--game-dir DIR] [--dry-run]`；`--game-dir` 单独给即 custom，相对路径在解析期就报用法错误； - 人读/`--json`/help 三条出口齐备（`error.detail.problems` 逐条可分流），已有命令未改。 测试（真磁盘夹具，`cargo test -p unlucky-core --test adopt` 22 passed / `cargo test -p unlucky-cli --test adopt_test` 10 passed）： - 一份「别的启动器铺好的」`.minecraft`（versions/libraries/assets/mods/saves/config + launcher_profiles.json），扫描与登记前后做「路径集合 + 字节数 + 内容哈希 + mtime」全等断言； - 正常 / 缺清单 / 坏 JSON / 缺父 / 成环 / id 不匹配 / 非法 id / 符号链接越界 / 根内符号链接 放行 / **junction 越界** / 数据区 junction 写盘边界 / 缺省非 isolated / shared 与 isolated 的话术 / 重名 / 重复 / 非空目录 / 空目录复用 / dry-run 零写盘； - CLI 侧验 `launch --dry-run` 的 `--gameDir` 指向选定运行目录（argv 已脱敏，比尾段； `data.game_dir` 全等）； - 变异核对（只改实现、跑完即回滚）：缺省档改 `VersionDir` ⇒ 红；边界判据摘掉 ⇒ 符号链接与 junction 两条红；写盘边界摘掉 ⇒ 数据区 junction 那条红；缺父当链终点 ⇒ 两条红。 界限：没有启动真实 Minecraft；GUI（presenter/app-iced）接线另派；D20 单游戏根模型未改 （不扫第二个 `.minecraft`）。	2026-11-09 22:21:37 +08:00
AskaEth	0577ee87a3	Merge branch 'feat/m220-javapinnit-m214-java-pin-and-nit-sw'	2026-11-09 21:31:23 +08:00
AskaEth	75aa5ee82c	fix(cli): 启动用的 Java 钉死 D4 校验过的那个 + M214 复审 nit1/nit2/nit3 ... - override_path 五来源统一钉住 D4 选中的运行时：以前只有 managed 钉路径， JAVA_HOME/PATH/system 三种会被 snapshot::prepare 的 selection() 按环境再挑一遍， D4 判过的 Java 根本不是真启动的那个。现在 `plan_java` 只做「选中 → 钉路径」， 人读行写出「版本（来源 · 具体可执行文件）」，--json 的 java 块并排给出 binary（校验过的）/ launch_binary（装配落地的）/ source，两者不一致时当场告警。 实例设置/全局设置里的 javaPath 也并入「谁指定了 Java」，不会被自动挑的结果顶掉。 - nit3：D4 的 Java 不符拦截挪到 identity::resolve 之前（微软轨解析身份会联网刷新 令牌、还会回写凭据），拦下的启动不再先触发一次刷新；不符提示补上「挑中的是哪个 java」，文案只加不减。 - nit1：error.rs / launcher.rs 的人读串里残留的 ** 标记去掉，并补两条回归断言。 - nit2：java_launch.rs 里「只提示不阻断」等旧注释对齐 D4 现状。 - launch.rs（399 行零余量）：D20 的隔离档位派生与切换检测整体搬到新文件 launch_isolation.rs，纯挪函数体（逐行 diff 只多 6 处 pub(super)）， 用 #[path] 挂载以免改 commands/mod.rs。 用例：钉路径纯函数单测 3 条 + 端到端 2 条（JAVA_HOME 置空证明非 managed 来源也钉住； 数据根放两个账户证明 D4 拦在身份解析之前）+ 人读串无 ** 的 2 条回归。 两条变异（①退回只钉 Managed ②退回身份解析之后）各自让新用例变红，已实测。	2026-11-09 21:30:55 +08:00
AskaEth	1f6e15127a	Merge branch 'feat/m217-guardrange-child-spawn-guard-across'	2026-11-09 21:12:24 +08:00
AskaEth	f8acb50156	fix(app-iced): 子进程统一走 platform::child::quiet（消灭启动闪窗）+ 守卫射程扩到整棵 crates/（M217） ... 用户报「CI 构建版启动时底下闪一个控制台」：M213 统一了 crates/core/src 的 20 处 Command::new，但守卫射程只有 core/src，app-iced 的 reg.exe（每次 GUI 启动都跑）漏网。 - crates/core/tests/child_quiet_guard.rs：扫描根 crates/core/src → crates/（1219 个 .rs）， 角色清单改成相对 crates/ 的路径（文件角色钉精确处数，目录角色至少一处）； 「扫不到文件」兜底断言保留，另加角色文件锚点兜底；顺带修掉全树扫描会撞上的 「纯 //! 结论页没有代码行」误判 - app-iced：platform/locale.rs 的 reg.exe、app/update/update_action.rs、 app/boot/fallback.rs、app/boot/termux_window.rs 的 xdpyinfo、 renderer/acceptance/locale.rs 的 defaults 全部改走 quiet（后三处是同一 exe / POSIX 上的 pass-through，为的是规则整体可被守卫钉住） - app/dialog/export.rs 的 explorer / open / xdg-open 保持裸构造并写清「窗口就是产品」， presenter/src/host/opener.rs 同理登记成角色（不在本 mission 改动范围） 门禁：fmt/check --workspace --all-targets/test --workspace -j 4/clippy --workspace --all-targets -D warnings/全仓 400 行 + <2 字节 .rs 扫描，六步退出码全 0，CHAIN_EXIT=0。	2026-11-09 21:12:02 +08:00
AskaEth	7521c47944	Merge branch 'feat/m216-coexistcore-shared-minecraft-no-sil'	2026-11-09 21:10:48 +08:00
AskaEth	aa61565fe7	fix(coexist): r2 返工——帮助写真实例路径 + 加载器安装也说出「原版清单被替换」+ --json 给出绑定成败（M216） ... r2 复审两条 P2 必修 + 一条「能一行接上就接」的 P3。 P2-1（`ull help pack` 的落点少一层 `.ULL/data`） - 「数据根」在这份帮助自己的定义里是「含 `.ULL/` 与 `.minecraft/` 的父目录」（`--data-dir` 那行）， 所以真路径是 `<数据根>/.ULL/data/instances/<实例目录名>`。r1 写成 `<数据根>/instances/<实例名>`， 照读会去一个不存在的位置找包内容。 - help.rs 与 model.rs 的字段文档改成真路径，并点明目录名是归一化后的结果（`Better-MC`）。 - 用例改成 `help_describes_the_new_default_target_with_the_real_path`：先断言真路径整串在、 再断言 `<数据根>/instances/` **不在**（这一条就是抓「少写 .ULL/data」那种错法）。 P2-2（装加载器时原版那一步的「替换了清单」没人说） - `loader.rs`：`plan.vanilla_install_needed` 那条路以前只拿 `vanilla_report` 判 `is_complete()` 就丢掉；现在把它留在 `vanilla_report` 里传给 `report_loader::build`。 - `report_loader.rs`：`build` / `human_lines` 各多一个 `vanilla: Option<&InstallReport>`； 新增 `vanilla_lines`（人读：`告警（原版）: …` + `原版版本清单已替换（旧的那份备份在 …）`）与 `vanilla_json`（`--json` 的 `vanilla` 段：warnings / version_json / manifest{kind,backup}）。 - 用例 `a_replaced_vanilla_manifest_is_said_out_loud_in_the_loader_output`：用真 `LoaderInstallPlan`（最小 Fabric，零网络）调 `human_lines`，断言告警与备份路径都在； 未先装原版时不多说话；`vanilla_json` 的 `kind`/`backup` 结构正确、`None` 时没有该段。 P3（复审「能一行接上就接」）：`--json` 给出导入绑定的**结构化成败** - core `pack_dir::bind_created_instance` 返回 `Option<Result<String, String>>`（None=不需要绑 / Ok=已绑 / Err=绑失败），一句话就能分出成败，不必猜文案。 - CLI：`outcome` 多写一个 `"instance_bound": true|false`（人读行照旧给原因）； GUI：`import.rs` 按 Ok/Err 分别记 `instance_bound` / `instance_binding_failed` 注记。 - 端到端用例里补断言 `data.instance_bound == true`。	2026-11-09 20:43:46 +08:00
AskaEth	4e1323212b	fix(coexist): 复审 r1 返工——帮助文案跟上新落点 + 「替换了清单」进人读通道 + 导入建实例绑到内容目录（M216 P2/P3/§5） ... P2-1 ② 改了缺省落点，CLI 自己的文档还在写旧行为 - `cli/help.rs`「目标目录缺省 = 数据根的共享游戏目录（.minecraft/）」→ 新实例目录 `<数据根>/instances/<实例名>`（并登记实例）； - `cli/model.rs` 的 `PackImportArgs::target` 字段文档同步。 - 用例 `help_describes_the_new_default_target`（断言帮助含新落点、不含旧落点）。 P2-2 ③ 的「显式说明」进不了任何人读通道 - CLI：`human_lines` 原只遍历 `plan.warnings`，而运行期告警（含「已替换版本清单 …旧的那份 备份在 …」）在 `report.warnings` 里 ⇒ `ull install` 人读输出从没说过这句话。现在有 report 就 报 report.warnings（它开头就是 plan 告警的副本），`manifest=Replaced` 再单独打一行备份路径。 - GUI：`install.rs` 新增 `Job::journal_report`（把 `report.warnings` 与 `manifest` 的备份路径写进 安装日志），`install/routes.rs` 两处 `ensure_complete` 之前各加一行调用（tower 批的两行）。 此前 `report.manifest` 全仓零消费者。 - 用例 `a_replaced_manifest_is_said_out_loud_in_the_human_output`（走真 `InstallPlan` 排版）。 P3-1 缺省目录被占的 hint 删掉不成立的 `--overwrite` 那半句（它绕过不了这条预检）。 P3-2 GUI 落点改成委托 core 的 `pack_dir::instance_dir`（此前 presenter 自己拼 `data()/instances/…`）； `convert::dir_name` 缩成 `#[cfg(test)]` 的委托入口（生产侧已无调用点，留着继续钉归一化判据）。 P3-3 补 `the_default_target_is_a_new_instance_dir_and_the_instance_is_bound_to_it`：不带 `--target` 跑通整条 CLI，断言落点、内容、登记、以及实例设置里的 `isolation`/`gameDir`。 §5 导入建出来的实例原先「导入成功但内容永远不会被启动用到」 - 新增 `pack_dir::bind_instance_dir`（`InstanceConfig.isolation = Custom` + `game_dir = 导入目录`） 与 `pack_dir::bind_created_instance`（判据+文案，CLI 与 GUI 同一份）； - CLI 在缺省建实例后、GUI 在 `import.rs::run` 里各调一次；只在「我们新建了实例目录且档案是新建」 时绑（显式 `--target` / `--no-register` / 复用已有档案都不动）； - 运行目录 = 导入目录（saves/mods/logs/config），**versions/libraries/assets 仍按 D20 恒共享**； - 未改 `derive_game_dir`。 - 用例：正向 `binding_an_imported_instance_points_it_at_the_import_dir`、反向 `a_freshly_registered_instance_still_inherits_the_global_mode`。	2026-11-09 19:46:41 +08:00
AskaEth	96f15c79fb	fix(coexist): 多启动器共存——存储模式写回同源 + 整合包缺省落点对齐 GUI + 版本清单不再静默覆盖（M216） ... 三条 M215 判定的共存债，一次修完： ① 存储模式切不回来（high） - 写侧：`host::settings::set` 老实现一律写 `env.store()`（= 解析后数据根那份），而启动解析 只读 `<exe>/.ULL/config/launcher.json` ⇒ Standard 下把模式改成 portable 写进了 `%APPDATA%`， 下次启动看不见，切不回来。 - 现在 `core.*` 四个数据根键一律落便携那份（判据收在 `settings_bridge::setting_path` 一处， 与 CLI `Ctx::setting_path_for` 同一契约），其余键照旧。 - 读侧：`settings_bridge` 删掉自己那份 `request_from_portable`/`DATA_ROOT_KEYS` 拷贝，改用 `host::env` 的那份（presenter 侧两份逐字拷贝合成一处，不新增真相源）。 - 设置页 `core.data_custom_root` 的显示值也读便携那份，否则改完输入看起来凭空消失。 ② `ull pack import` 缺省落点与 GUI 不一致（high） - CLI 老缺省 = `ctx.game().root()`（共享 `.minecraft` 根）；GUI 导入页落在 `<data>/instances/<实例目录名>` 并登记。 - 新增 `core::game::install::pack_dir`（`pack_stem` / `instance_dir_name` / `slug` / `instance_dir` / `import_target`）：命名与落点只有一份实现；CLI 调它，presenter 的 `convert::{dir_name,pack_stem,slug}` 改成一行委托 core（对外签名不变）。 - CLI 缺省现在与 GUI 同源，并复用 GUI 那条「非空目录不复用」预检。 ③ 装同版本静默覆盖 `versions/<id>/<id>.json`（medium） - `write_version_json` 三档：不存在 → `Fresh`；逐字节相同 → `Identical`（一个字节都不写， 重装同版本照旧正常）；不同 → 先 copy 到 `<dest>.ullbak-<pid>` 再原子写 → `Replaced{backup}`。 - `InstallReport` 新增结构化字段 `manifest: Option<ManifestWrite>`，并把「已替换版本清单 + 备份路径」推进 `report.warnings`（进 `--json` 的 `result.warnings`）。 用例（全部零网络，走真的 `execute`）：三档各一条，各写抓得住/抓不住。 三个变异各跑一次（只改实现侧）都红：写回落点改回旧的、缺省改回 `.minecraft` 根、去掉备份只覆盖。	2026-11-09 18:42:41 +08:00
AskaEth	ab5b593708	Merge branch 'feat/m214-javacompat-java-version-distance-la'	2026-11-09 17:27:23 +08:00
AskaEth	ff78fe2cae	fix(core): 老版本 Java 按版本距离选 + 启动看门狗有界等待 + 结束归属（M214 D4/D6/D10） ... D4：`pick` 的排序键从「来源序」改成「版本距离 → 来源序」，全不满足时选最接近要求的那个 （托管 25 与 JAVA_HOME/扫盘 17 之间选 17，而不是按 rank 选托管）。新增 `select::decide`： 不符且**没有人显式指定 Java** 时 `ull launch` 直接报 `java_mismatch` 不 spawn（`--java` / 实例 `javaPath` 是豁免，只告警）——1.12.2 配 Java 17/25 必然起不来，警告没有信息量。 `JavaMismatch` + `check` 拆到 `mismatch.rs` 并加 `advice()`（mapping.rs 408→282 行）。 D6：`LaunchSession::finish` 的等进程改成**有界**。判据在 `startup_watch.rs`（纯逻辑）： ①窗口从未出现且**连续 N 秒没有任何日志**（还在打日志就说明还在加载，慢加载不被判死）； ②日志出现关闭标记后 N 秒仍未退出（实机「关窗后 java.exe 仍存活」的形状）。 到点只**停止等待、绝不杀进程**：写 `session_end(still_running)` + 索引 + `launcher.log`， 返回 `LaunchError::Watchdog`，CLI 翻成 `launch_timeout`。两个时长可配 （默认 300s/60s；`ULL_LAUNCH_STARTUP_TIMEOUT_SECS` / `ULL_LAUNCH_SHUTDOWN_GRACE_SECS`， 生效值每次启动写进 launcher.log 与人读输出）。 D10：把「被终止」与「应用错误」分开。①我们自己杀的：`tree_kill` **送达即登记** `kill_registry`（pid 登记簿，取走语义、上限 64），覆盖 GUI 从别的线程 `kill_tree` 的路径， `finish` 据此判 `killed`；②外部强杀：Windows 上「退出码 1 + 零错误输出 + 无崩溃/JVM 关键字」 判 `killed` 并标 `terminated_externally`（任务管理器与 `taskkill /F` 都是 `TerminateProcess(h, 1)`，应用真崩给的是 NTSTATUS 异常码）。 顺带：`SessionHandle` 拆 `session_handle.rs`（launch_session.rs 422→343 行）、 `NativesReport::to_json` 落 core（cli/launch.rs 腾出空间，仍 399 行）。 用例：select 距离/取舍、startup_watch 状态机、watchdog_cases（4 条真进程）、 exit_cases（外部终止与「我们杀的」区分）、pipeline 跨线程 kill。	2026-11-09 17:07:22 +08:00
AskaEth	5959a27add	fix(core): child_quiet.rs 446 行越 400 红线，按职责拆成两个测试文件 ... M213 r2 把守卫的剥注释+两条新用例都塞进同一个文件，涨到 446 行。tower 的合并门里 400 行扫描算出了 OVER=1，但 push 写在扫描之后没有用它拦住自己，所以 dev 上先红了一次。 - child_quiet.rs(85)：quiet 的**行为**测试（管道/退出码/env/错误语义） - child_quiet_guard.rs(370)：源码扫描型守卫（角色表 + 4 条变异对应的用例 + 解析 helper） 拆分后复验：两文件 5+4=9 条全绿；变异 D（discover.rs:156 改裸构造）仍 exit 101 并点名该行 ——守卫的牙没在拆分中丢掉。	2026-11-09 15:14:23 +08:00
AskaEth	aa8c8f506a	Merge branch 'feat/m213-consolesilence2-quiet-child-process'	2026-11-09 15:08:49 +08:00
AskaEth	6dd88a27a3	fix(core): 守卫的剥注释不再吞文件 + 变异 D 变红（M213 复审 P1-1 / P2-1） ... 复审 P1-1：`code_lines()` 对每一行找 `/*`，找着就当块注释开头。本仓库的文档注释里到处是 glob（`/usr/lib/jvm/*`、`rules.d/*.yaml`、`crash-reports/*.txt`、`.github/workflows/**`）， 字符串里也有（`"mods/*.jar"`），这些 `/*` 没有配对的 `*/`，于是 in_block 一旦为真就再也 不会变假 —— 该文件从那一行到 EOF 全部被吞掉。实测 crates/core/src 里 8/371 个文件中招， 其中一个是 game/java/discover.rs（它自己有一处 reg query），复审判的变异 D 因此全绿。 - code_lines 只在「去掉前导空白后以 /* 开头」的行上进入块注释态，行中/字符串里的 /* 一律 当普通代码。本仓库零处行首块注释，所以结构上不可能再吞代码。 - 新增 code_lines_is_not_fooled_by_glob_slashes_in_strings_or_docs：字符串里的 /* 不许 吞掉后一行、文档 glob 不许吞掉真代码、真块注释仍要被剥。 - 新增 the_scan_reaches_the_end_of_every_file：逐文件核对**最后一行代码的行号**必须出现在 扫面结果里（比数总行数尖锐 —— 文件普遍以 } 结尾，光比内容会被别处的 } 蒙混），外加 全仓可见行占比 ≥60% 的兜底（本机实测 81%）。 - 变异 D（discover.rs:156 改回裸 Command::new）现在 exit 101 并点名该行；A/B/C 复验仍红。 复审 P2-1：原注释说「两个 flag 不能叠加」，按 MSDN 这是错的。改成：两个 flag 在 Win32 层 可任意组合，真正的坑是 std 的 creation_flags 是 setter（后一次静默覆盖前一次）。结论不变 （launch/process.rs 仍零改动），顺带修正 DETACHED_PROCESS 的说明。	2026-11-09 15:07:56 +08:00
AskaEth	40a296471d	fix(core): 所有子进程统一走 platform::child::quiet + 角色守卫（M213） ... GUI 父进程（PE Subsystem = 2）spawn 控制台子进程时，Windows 会为子进程新建一块 控制台——桌面上就是「黑框闪一下」。改前 crates/core/src 有 21 处 Command::new， 只有 tree_kill 那一处带了 CREATE_NO_WINDOW，于是探 N 个 JDK 就闪 N 次 java -version。 - 新增 crates/core/src/platform/child.rs：唯一构造器 quiet(program)，Windows 上统一 .creation_flags(CREATE_NO_WINDOW)，其它平台原样返回。tree_kill 里那份就地合并进来， 不再保留第二份常量。 - 20 处 spawn 全部改走它（region_system / java{discover,manual,probe,proc,termux} / addon exec / platform{linux_caps,macos_version,theme_probe,vk_probe,windows_version, wallpaper/io}）。 - launch/process.rs 零改动：游戏进程要 CREATE_NEW_PROCESS_GROUP 撑 taskkill /T， 带不带控制台窗口是产品决定。 - crates/core/tests/child_quiet.rs：按角色判「有没有绕开构造器」的守卫，外加构造器 本身的 4 条行为用例。三条变异（裸 Command::new / 别名 Spawn::new / 删掉 creation_flags） 都实测变红并已还原。	2026-11-09 15:07:56 +08:00
AskaEth	bb8be87c8f	Merge branch 'feat/m212-agentlog-agent-and-mcp-log-diag-too'	2026-11-09 14:42:10 +08:00
AskaEth	fbb4a79955	fix(agent): MCP 读日志/诊断崩溃改走 session_index::event_file（D2 第三处读取点） ... M212（M211 复审观察 7 确认的真 bug）： - `agent/ports/events.rs::event_path` 仍在 `root.join("game").join(&entry.log_path)`， 而 `log_path` 已经是**相对会话根**的 `game/<id>.jsonl` ⇒ 对每个真实会话解析成 `game/game/<id>.jsonl`。后果是 `ull agent` / MCP 的 read_game_log 与 diagnose_crash 两个工具对真实会话全报「读会话事件流失败」——内置 AI Agent 的看家本领是坏的。 现在解析只走 M211 建立的唯一真相源 `session_index::event_file`（新旧两个根都走它）。 - 夹具：`ports/session.rs`、`ports/diagnose.rs` 的索引夹具此前写裸文件名 `20261029T124501-9f3c2a.jsonl`，与生产差一层 `game/`，所以这个 bug 在测试里永远看不见。 改成 `session_index::log_path_for(id)` + `session_index::event_file` 落盘。 - 用例：`ports/events.rs` 新增三条（解析结果 = 写入侧落盘的那一个 / 文件缺失时指向的仍是 生产形状 / 旧根回落走同一套解析）；`cli/tests/agent_mcp_stdio_test.rs` 新增一条真机 MCP 用例（起 `ull agent serve --stdio`，对一份生产形状的会话调 list_game_sessions → read_game_log → diagnose_crash）。旧实现下两条路径都红，红的是 `...\logs\game\game\20261030T101500-abcdef.jsonl`。	2026-11-09 14:28:42 +08:00
AskaEth	994ffda626	Merge branch 'feat/m211-logreach-session-jsonl-path-double'	2026-11-09 14:14:14 +08:00
AskaEth	a91930e021	test(core): crash_scan 用例改用 slice::from_ref（clippy::cloned_ref_to_slice_refs）	2026-11-09 14:12:23 +08:00
AskaEth	4b30bf07f0	fix(launch): 会话事件流路径只留一个真相源 + crash_found 只认真实证据 + ull launch 也写 launcher.log ... M211（来自 M208 实机 e2e 的 D2/D3/D5）： - D2「game/ 双写」：log_path 的契约原来有两种说法（字段文档写「相对 game/」，写入侧一直 写「相对会话根」的 game/<sid>.jsonl），于是两处读取点各自又多 join 一层 game/， ull logs / ull diag / GUI 日志页对每个真实会话都报「找不到事件流」。现在解析只走 core 的 session_index::event_file（CLI 与 presenter 共用），写入侧只走 session_index::log_path_for。方向选的是「读取侧不再 join」：存量索引里的 log_path 从第一版 起就是 game/<id>.jsonl，改读取侧能把用户盘上已有的旧会话一起救回来（零迁移、零改写）。 - D2 夹具：cli/tests/support 与 presenter/host/logs_tests 的索引夹具改成生产形状 （game/<id>.jsonl）。夹具此前自己说了第三种形状，所以这个 bug 在测试里永远看不见—— 修夹具比修路径更重要。 - D3「crash_found 恒为 true」：logs/latest.log 每局都写，不再被当现场文件（只在已经找到 权威现场时作为补充证据）。崩溃结论改由 crash_scan::has_crash_evidence 判定（权威现场文件 / 非 0 退出 + 错误行），索引旗标由 SessionWriter::mark_crash 写入；crash_found 事件恢复 成纯事实记录。 - D5「ull launch 从不写 launcher.log」：现在与 GUI 共用 launcher_log::record_start / record_end（字段名与顺序只在一个地方定义），写的是同一份 <data>/logs/launcher.log。 测试：core 新增 session_path_tests（写入形状 = 读取解析结果 = 真落点的往返）、crash_scan 的 干净退出用例、launcher_log 的行格式锁；CLI 新增 a_launch_attempt_writes_the_launcher_log。	2026-11-09 14:12:23 +08:00
AskaEth	1748e046f8	fix(cli): progress.rs 测试 helper 的返回类型抽成 Recorder 别名 ... M210 引入 type_complexity（clippy 1.99 -D warnings）。M210 的 brief 里没有 clippy 这一项（五步门禁是它 spawn 之后才补上的），所以第一轮没抓到；新门禁在合并态立刻咬住。	2026-11-09 14:05:52 +08:00
AskaEth	96753c5b38	Merge branch 'feat/m210-mirrorfix-bmclapi-libraries-missing'	2026-11-09 13:59:58 +08:00
AskaEth	d8ca411117	fix(core): bmclapi 库镜像补 /maven；install 进度行改说实话 ... D1（high）：mirrors.json 的 bmclapi-libraries 少了 inject，官方 libraries.minecraft.net/<path> 被重写成镜像根 + <path>（BMCLAPI 的 maven 仓库挂在 /maven 下），实测 70/70 个库全 404、全部回落官方源（单请求 EMA 6.3 s）。本轮实测： guava:32.1.2-jre 无 /maven → 404 / 9 B；带 /maven → 200（2 次 302）/ 3041591 B， sha1 与官方逐字节一致。补法与 bmclapi-assets-objects 的 /assets 同一机制（inject）， 不把 /maven 拼进 to（to 是镜像根）。 守卫两道，抓不同的东西： - 形态：凡 from 指向 maven 仓库的规则，to+inject 必须以 /maven 结尾（并点名覆盖的 5 条规则 id，删/改名都会红）； - 行为：4 个真实官方 maven 根展开后必须逐字等于 /maven/<子路径>。 原有 prefix_rule_preserves_sub_path 的期望值曾把 D1 的 bug 钉成期望，一并改正。 变异（删掉 inject）实测三条同时红，恢复后 mirrors 14 passed。 D11（low）：进度回调只累加「处理到第几个文件」，还打「下载 {done}/{total}」， 重装同版本（全部已就绪）时会连打 3961 行「下载」而一个字节都没下。拆出 install/progress.rs：计数全部来自 FileOutcome.status（Downloaded/Skipped/Failed）， 下载数为 0 时人读行不出现「下载」二字（改说「已就绪 d/t（跳过 N 个）」），--json 的 progress 事件补 downloaded/skipped/failed。用例构造 96 个全 Skipped ⇒ 断言每行都不含 「下载」且末行为「已就绪 96/96（跳过 96 个）」；变异（退回旧文本）实测红。 其它镜像表（assets / jar / version_manifest / 索引 / fabric / forge）的 inject 形状 实测一致，另有 liteloader 目标路径 404、quilt maven 无规则两条【不同类】观察， 不在本轮范围，报告里交回 tower。	2026-11-09 13:57:32 +08:00
AskaEth	391ebf88b7	fix(ci): 修两处 clippy -D warnings 红（needless_lifetimes / drain_collect） ... 两处都来自 M201（5dda9ac），非本轮 mission 引入。tower 合并门此前只跑 fmt+check+test，从未跑 clippy，所以 dev 上 CI 的 clippy job 一直是红的没人发现。 - presenter/host/settings/download_tests.rs: chosen 的显式生命周期可省略 - app-iced/.../download_tests.rs: drain(..).collect() -> mem::take 语义等价，纯 lint。门禁已补上 clippy（见 00-恢复指引 §6）。	2026-11-09 13:56:09 +08:00
AskaEth	413553d3ea	Merge branch 'feat/m207-uasweep-unify-user-agent-contact-in'	2026-11-09 13:15:58 +08:00
AskaEth	e3ae71ac37	M207: UA 收成一份带联系方式 + 两处字符串副本（gh_proxy 键、用例注释） ... 1) UA 只有一份定义：core 的 `download::http::USER_AGENT` （`Unlucky-Launcher/<CARGO_PKG_VERSION> (+仓库 URL)`，不用邮箱）。 - 引擎侧：`EngineConfig::default().user_agent` 直接取它（config.rs 等量替换，仍是 400 行） - 带 header 侧：presenter 不再持有 UA 字面量，`get_with_headers` 发 `engine.config().user_agent` M205 复审核实过的缺口：Modrinth 收到的是引擎那份 `UnluckyLauncher/<ver>`（无连字符、无联系方式）， 带联系方式的那份只发给 CurseForge 搜索 —— Modrinth 的 UA 政策在真正会被限流的路径上没被满足。 断言：core 一条钉形状（版本 == CARGO_PKG_VERSION、联系方式段 == 仓库 URL、不含 `@`）； presenter 一条在回环上抓**发出去的字节**（两条路径的 UA 逐字节相同且 == EngineConfig::default()）。 2) `app-iced/.../java/downloads/engine.rs`：`"download.gh_proxy"` 字面量改成 `KEY_GH_PROXY`。 3) `presenter/src/host/addon/http.rs` 的用例注释改成事实（Modrinth 走 core 的 EngineTransport， `get` 的无 header 分支生产零调用者），模块说明表格同步。 4) `docs/download-settings.md`：§6.1 / §6.1.1 / §7 按 M201（iced 真控件 + 快照通路）之后的现状重写。	2026-11-09 13:13:20 +08:00
AskaEth	a853986283	Merge branch 'feat/m206-badgesel-current-item-marker-contra'	2026-11-09 12:58:50 +08:00
AskaEth	b7a1abb18a	fix(m206): 「当前默认」改用选中的语汇，不再套禁用配色 ... Java 组用 `Chip::badge` 表示「哪个 JDK 是默认」，而 badge 走的是「无消息 ⇒ 禁用」 那条路（`OnSurface`@38% 叠 surface）：M204 实测字/底只有 1.84:1（浅）/ 2.28:1（深）， 成了整页最不可读的一段，而它正是「能不能改默认 Java」这个问题的答案本身。 同一张设置页里相邻的「下载」组表达「选中」用的是 `SecondaryContainer` + `OnSecondaryContainer`（7.21:1）——两个相邻页面对同一个语义用了两套语汇。 改法（不动禁用语义）： 1. 新增 `Chip::current(label)` + `paint::current_item`：**与选中 chip 同一套颜色**， 但没有消息、不吃五态（没有可点性就没有反馈）。它不等于「未选中」，也不等于 「禁用」——第三档，判据表写在 `components/selection/chip.rs` 的模块文档里。 2. `Chip::paint(&self, ui)` 成为「哪个档位 → 什么颜色」的唯一入口，`chip()` 用它求 静息色，断言也用它——档位的判据只有一处，「改回旧配色」的变异会被直接抓住。 3. Java 页的动作位抽成 `view::action_chip`，当前默认走 `Chip::current`，其余仍是可点 的 `Chip::filter(.., false, ..)`。 4. 下载组**不改**：它本来就是参照语汇（M201 已验收），改完两页逐字段同色。 断言（`pages/settings/java/tests/marker.rs`，浅深两档都跑）： 对比度 ≥4.5:1（实测 7.21/7.21）、与下载组选中 chip 逐字段相等、以及反向断言 「禁用态仍走 38% 字 + 12% 容器且与当前项肉眼可分」。两条变异都在报告里复现过： `action_chip` 换回 `Chip::badge` ⇒ 对比度断言红（只有 1.84:1）；`Chip::current` 里 `marker: true` 改 `false` ⇒ 三条全红。 举证图（离屏 `--screenshot`，浅/深 + 改前/改后 + 下载组对照）与实测色值表见 `DevDocs/artifacts/m206/`（gitignore，不入库）。	2026-11-09 12:44:18 +08:00
AskaEth	46559910c9	Merge branch 'feat/m204-javagroup-java-runtime-settings-gro'	2026-11-09 12:11:26 +08:00
AskaEth	8a050c4402	fix(m204): 补「扫描中/还没扫描过/正在取消」三格种子 + try_lock 说明对得上代码 ... 视觉复审 r1 判 p2-1items：六张举证图里「取消」全程是禁用态，「正在扫描… 3/7」 一格都没拍，而 README 却写成「两态」——证据覆盖不到结论（与 M201 同一个坑）。 本提交补种子与拆文件，不出产品行为改动。 - `pages/settings/java/seed.rs`：新增 `scanning` / `unscanned` / `cancelling` 三档。 三档都把快照写进 `ScanSlot`（新增 `ScanSlot::seed_report`）而不只改 `State.scanning`： `clock.advance` 每拍用槽里的快照重算 `scanning`，只改 State 的话第一拍就被推回「没在扫」。 - `pages/settings/java/scan.rs`：`ScanReport` / `Job` / `ScanSlot` / `run_staged` / `rows` 从 `store.rs` 拆出（加 `seed_report` 之后那个文件 408 行，越过 400 行硬线）； `store.rs` 用 `pub use` 再导出 `ScanReport` / `ScanSlot`，既有路径一个都没改。 - `app/view.rs`：`note_screenshot_group` 的锁从 `lock()` 换成 `try_lock()`——代码复审 r1 指出 注释写着「拿不到锁就不打、不能把界面帧卡在锁上」，而实现用的是阻塞 `lock()`，只兜住中毒 不兜住等待。选 try_lock 而不是改注释：注释承诺的保证应由代码提供，不能靠「今天只有一个 调用点、锁里只有一次比较」这种会随改动失效的前提。 - `pages/settings/java/tests/cmdline.rs`：新增 `the_scan_seeds_cover_the_running_states`， 逐档钉 `State.scanning` 与 `scan.report().running`（后者才是「心跳下一拍会不会把它推开」）。	2026-11-09 12:09:02 +08:00
AskaEth	92ab3d4ddf	fix(m204): Java 组写盘成功后请 host 重发设置快照 ... `pages/settings/java/store.rs` 的 `save()` / `set_selected()` / `prefs_store::save()` 是页面自己的一次同步原子落盘（`SettingStore::set` 多个键 + 一次 `save()`）， 不经过 `AppCommand::SetSetting` 的写盘分支；而 `CoreEvent::SettingsChanged` 全仓只有 `dispatch.rs` 的 `SetSetting` 分支与 `host/mod.rs::refresh_all` 两处发出。 于是三键写成功之后，`AppState::settings_groups` 里 java 组那几行会停在旧值， 直到下一次任何别的写入顺手带一份新快照回来。 修法用一条**动作键**（`dto::JAVA_REFRESH_ACTION` = `java.action.refresh`， 与 `download.action.detect_region` 同一族：不写盘、见到就返回 Ok）： 写盘成功后派发它，`SetSetting` 分支照常重发快照。 不用 `RefreshAll`：那个除重发快照之外还会 `versions::spawn_list` 与 `start_update_check`——每点一次「保存内存」打两个网络请求（实测：一次真 host 出图 就在数据根里落了 `cache/meta/version_manifest_v2.json`），代价与动作不相称。 另外给 D30 §2.1 补一行自证身份的日志：`--screenshot` 且身份变化时打 `[shot] settings route=… group=… theme=…`（`view` 每帧都跑，所以只在变化时落一行）， 免得再出现「拿外观页当下载组证据」那种图与结论对不上的事故。 守卫（`tests/java_refresh.rs`，4 条）： - 真 `CoreHost` + 临时数据根跑完整链：写盘 ⇒ 快照里 `java.extra_args` 真的变了； - 被拒的保存不许请求刷新； - 成功之后确实派发了那条动作键（键名写错就红）； - 「立即扫描」在 App 层真的接线（此前没有任何用例驱动 `Message::Scan`）。	2026-11-09 12:09:01 +08:00
AskaEth	a48d055118	Merge branch 'feat/m205-debtsweep2-gh-proxy-assertion-user'	2026-11-09 11:36:57 +08:00
AskaEth	4c29cbac3e	Merge branch 'feat/m202-settingsflow-iced-settings-data-pat'	2026-11-09 10:53:32 +08:00
AskaEth	5dda9ac31d	M201 r2: 修视觉 r1 的两条 P2 + 代码复审的坏值提示 p2 ... 视觉 r1（fix-then-merge）: - P2-1 分隔线贴字：downloaded 组的行间距从 0 改成 `Space::X3`（12dp）。实测 说明末行→分隔线 1–3px → **12–13px**、分隔线→下一标题 4–5px → **12–17px** （同族页 9–18px；同一把尺子量演示回退卡 16–19px）。不动 `frame::divider` / `demo_card`；`spacing` 只作用于子节点之间，卡片首行顶距与末行底距仍是 20。 - P2-2 孤字「效」：`with_note` 把「原值 X 已按出厂 N 生效」从说明段落里挪到 **独立一行**（`\n` 分隔，渲染器按行断）。浅/深/窄三张复验：无 <20px 窄行。 两种措辞（出厂 8 / 已按 1）一字未改，presenter 侧新增 `ends_with("\n原值 …")` 断言把「独占一行」钉住。 代码复审 p2（非整数坏值被静默丢掉）: - `raw_int`（`Value::as_i64`）→ `raw_text`：文件里显式写过的原值转**上屏文本** （字符串取原文不带 serde 引号、数字/布尔 `to_string`、`null` 当没写）。 于是 `"auto"` / `8.5` / `true` / `-4` 都能进那句提示，不再「画着 8 却说不出 用户写的 auto 被忽略」。 - 新用例 `every_bad_value_shape_says_what_the_raw_value_was`：负整数 / 字符串 / 浮点 / 布尔 / null 五种形态。 验证：fmt --all --check / check -p unlucky-app-iced --all-targets / test -p unlucky-app-iced(845+6) / test -p unlucky-presenter(316) / test -p unlucky-i18n(36)，全部 EXIT=0。	2026-11-09 10:51:16 +08:00
AskaEth	ab573838f3	M201: 接通 iced 设置页的数据通路（下载组：真值 + 真控件 + 写回闭环） ... M193 的用户投诉「设置页里改了不生效」的结构性根因是 iced 侧没有设置数据通路： `CoreEvent::SettingsChanged` 在 `crates/app-iced/src` 零命中、`pages::Model` 没有设置快照、 `download::State` 是空 struct。presenter 那套设置组早就是真值来源（`host::settings::groups` 由 `refresh_all` 与 `dispatch` 的 `SetSetting` 分支发成 `SettingsChanged`），只是没有接到 iced。 这条线现在通了： host::settings::groups → SettingsChanged → AppState::settings_groups → pages::Model.settings → settings::States.settings → 下载组控件 → AppCommand::SetSetting → 写盘 + 重新发 SettingsChanged（闭环） 主要改动 - presenter `host/settings/download.rs`：并发/重试两行改成画**引擎生效值**（`DownloadTuning`）， 文件原值与生效值不一致时写明「原值 X 已按出厂 N 生效」（P3-5，两个数都现读）； gh-proxy 行补「当前生效：跟随内置默认/已关闭/覆盖为 X」。 - app-iced `pages/settings/download.rs`：`GROUP.body = Some(body)`，按 `SettingControl` 画 choice（filter chip）/ text（输入框 + 应用）/ action（按钮）/ toggle / readonly；写回走 `app/update/settings/download.rs` → `AppCommand::SetSetting`（不做乐观回显）。 - `pages::Model.settings` + `settings::States.settings`：快照进页面的唯一通道。 - i18n：新增 `SettingsDownloadsApply`（金表锚点追加，`split_keeps_every_translation` 绿）。 - 取证：`ULL_SCREENSHOT_REAL_HOST=1` 让 `--screenshot` 接真 host（截图通道默认强制 mock， 而 mock 不发 `SettingsChanged`，真值屏拍不出来）。 测试（新增 11 条） - presenter `download_tests.rs`：P3-5 的越界回落 / 0→1 / 无差异不出提示 + P3-3 的 gh-proxy 文件→三态端到端链。 - app-iced `app/update/settings/download_tests.rs`：假后端闭环 ×4 + **真 `CoreHost` 端到端** （点 16 ⇒ 磁盘上 `launcher.json` 真的有 16）。 - `pages/settings/tests/download_section.rs`：`body.is_none()` 绊线翻成 `is_some()` + 控件形状 / 空快照不编值。	2026-11-09 10:51:16 +08:00
AskaEth	0cc1a35420	Merge branch 'feat/m203-clituning-cli-download-tuning-from'	2026-11-09 10:24:51 +08:00
AskaEth	7995f62908	fix(m203): 给第 4 条吃设置的路径（ull update）补打点，并清掉 KEY_GH_PROXY 的腐化 doc ... 复审 r1 P2-1（p2-1items / fix-then-merge）：`ull update` 复用 `install::build_engine` 后成了第 4 条 吃设置的路径，但没有任何用例钉它——把 update 换回裸引擎，四条 download::tests 全绿。按 pack 的完全 同形接缝补上： - `commands/update.rs` 新增 `pub(crate) fn engine(ctx)`（`job()` 改调它），doc 写明这条路径上并发 不可观测（自更新只下一个 artifact），随设置变的是每源重试次数与 gh-proxy 前缀； - `download/tests.rs` 新增 `update_engine_takes_the_concurrency_from_the_setting_store`： 写 concurrency=4 ⇒ 断言 `config().max_concurrency` 与 `concurrency_probe()` 都是 4。 顺带收掉复审的三条观察： 1. 新增 `the_gh_proxy_setting_reaches_the_candidate_chain`：镜像优先地区档案下，出厂（空串 = 跟随 内置）确实生成 gh-proxy 候选；手写 `gh_proxy: "off"` 后候选里没有 gh-proxy（读的是 `plan()` 的 候选链，不是配置值；两段式，避免「本来就没有候选」的白绿）。 2. 测试写侧改用 `ctx.setting_path_for(KEY_CONCURRENCY)`（`ull config set` 用的那个表达式），不再与 实现读侧的 `launcher_config()` 共用同一个表达式——实现改读别的文件时用例会红而不是一起漂移。 3. `core/download/config.rs` 的 `KEY_GH_PROXY` doc 已腐化（写「暂未登记、M197 才登记、别删这条弱 断言」，而该键在 main 上就已登记、本文件根本没有针对该常量的断言）：改成事实，并保留「弱在哪」 ——常量值与 schema 登记没被断言绑在一起，改名只会让宿主侧静默退化成 Builtin。 变异验证（只改实现侧，逐次还原）： - update::engine 换回裸 `EngineConfig::default()` ⇒ 只有 update 那条红（left 8 / right 4），另五条绿； - `download::tuning` 不读 `KEY_GH_PROXY`（传 None）⇒ 只有 gh_proxy 那条红（off 档仍有 `https://gh-proxy.com/...` 候选），另五条绿； - `gh_proxy_override("")` 返回 Off ⇒ gh_proxy 那条的「出厂该套内置前缀」与回落用例的 `tuning == default` 同时红（两处都该红）。	2026-11-09 10:07:41 +08:00
AskaEth	b31ca636d1	feat(m203): CLI 三条下载命令改吃 download.* 设置（并发/重试/gh-proxy） ... `ull install` / `ull java` / `ull pack` 此前各自 `DownloadEngine::new(EngineConfig::default(), …)`： 用户在设置里配的 `download.concurrency` / `retry_limit` / `gh_proxy` 一概不生效；M193 把出厂并发 从 64 改成 8 之后，它们还静默跟着降了。现在三处都经 `crates/cli/src/download.rs::engine(ctx)`： - core：`shared/tuned.rs` 新增 `engine_with_tuning(cache_root, tune)` = `set_tuning` + `engine_for`， 由 `shared.rs` 重导出；`engine_for` 的签名与行为一字未改（presenter 的两步语义原样保留）。 放子模块是为了不动 `engine.rs`（那是 400 行零余量），`shared.rs` 仍 398 行。 - CLI：`download::tuning(ctx)` 用 `SettingStore::load(ctx.launcher_config(), launcher_schema())` 读 三个键（与 `ull config set` 同一份文件），默认值/夹取/回落在 `DownloadTuning::from_settings`； 键缺失或坏值静默回落出厂值，`engine()` 没有错误通道，安装不会因此中断。 - 顺带：`ull update` 复用 `install::build_engine`，也随之吃到设置。 - 测试：`crates/cli/src/download/tests.rs` 三条命令各一条（读 `config().max_concurrency` 与 `concurrency_probe()` 的真实值）+ 一条「缺失/越界/负数/类型不对 ⇒ 静默回落出厂值」； `shared/tuned.rs` 两条守住「灌调优与取引擎是一步」。变异实测：pack 换回裸 `EngineConfig::default()` ⇒ 只有 pack 那条红（left 8 / right 2）。	2026-11-09 10:07:41 +08:00
AskaEth	c97630d59e	Merge branch 'feat/m204-cleanupdoc-debt-sweep-four-small-it'	2026-11-09 09:58:56 +08:00
AskaEth	8e37bb9cf9	docs(packaging): §12 文件清单里本文的节号范围补到 §11–§16 ... 复审观察 1：那张表还写「索引 + §11 / §12 / §13」，而本文现在也有 §14/§15/§16（含本次新编的 §16）。是改动前就存在的陈旧，顺手补全。	2026-11-09 09:49:44 +08:00
AskaEth	3b5f95375d	docs(presenter): 「抓不住」那段别再点名 signature_cases.rs 管 manifest_sha256（复审 P2） ... 信封字段与钥表确实在 core/src/update/tests/signature_cases.rs；但 manifest_sha256 那条冗余校验 （signature.rs:161-171，要求「钥已钉住 + 方程验过 + 声明 sha 不同」）全仓没有任何用例覆盖， 现有篡改用例都先死在方程上。原文把这一项也推给那个文件，等于把责任推给了不存在的守卫。 改成如实写「全仓无用例，已立 finding」。只动 doc，用例逻辑与断言未改（394 → 395 行）。	2026-11-09 09:49:41 +08:00
AskaEth	ba96a4fc94	docs(presenter): 更正 ATTEMPTS 注释里「拿不到宿主设置」的假话（复审 P1） ... 原文把「没读设置」写成了物理限制。事实：get_with_headers 手里就有 env，第一句 engine(env) 已经走过 apply_tuning（host/settings/download.rs → core/download/shared.rs），用户当前值就在 engine.config().max_attempts_per_source。这条路径之所以恒为出厂默认，只是因为它没读那个字段。 只改注释，行为不变（仍是编译期 const）。同时把不对称写清：另一条无 header 的路径走引擎， 本来就跟随 download.retry_limit（源冷却中时引擎给 1 次，那是恢复探测）。	2026-11-09 09:49:36 +08:00
AskaEth	133f14ba0b	test(presenter): 坏清单用例按错误分类区分「JSON 坏」与「签名被拒」 ... 台账 §10 第 7 条 / M199 复审 P3-2：原来只断言「结果是 Failed」，而它喂的每一份清单都签对了 ——验签一旦 fail-open 或签名错误被误分类，这条用例照样绿。 现在两组各钉自己的分类： - 内容坏（5 个变体，签名都对）：kind 必须是 invalid_manifest / invalid_version； - 字节好、只有签名对不上（放行就会报「有更新 0.9.0」）：kind 必须是 signature_invalid 且不可重试。 变异证明（只改实现侧，跑完已还原）： - A core::update::signature::verify_manifest fail-open → ② 分支红，实际 Available(0.9.0)； - B core::update::manifest::from_json 把解析失败误分类成 SignatureInvalid → ① 分支红， 「not json：坏内容分类是 signature_invalid」。 两个变异各只打红对应分支，说明两类坏输入确实各走各的分类。 文件仍在 400 行红线内（394 行）。	2026-11-09 09:32:58 +08:00
AskaEth	06fcbb8a51	docs(packaging): 修掉两个 §14 撞号（M190 让位到 §16） ... 台账 §10 第 5 条：packaging/README.md 里 §14 被 M169（更新链路测试通道）与 M190（产物署名与 清单签名）各用了一次。 判据（谁后插进来谁让位）：§14 与 §15 都被仓库里的引用钉着——packaging/check_test_source_off.py 引 §14（M169），.github/workflows/release-build.yml 与 crates/app-iced/src/platform/win32/console.rs 引 §15（M196）；这两处引用都在本 mission 的 scope 外。所以 M169 保持 §14、M196 保持 §15， M190 那一节整段后移到文末编 §16，内容一字未改，只改编号与位置（新增一段「编号来历」说明为什么 它让位）。全文 §11/§12/§13/§14/§15/§16 各一次，无重复。	2026-11-09 09:32:54 +08:00
AskaEth	9163054d46	refactor(presenter): 带 header 的请求重试次数改引 core 的单一来源 ... 台账 §10 第 4 条：http.rs 的 const ATTEMPTS: u32 = 3 是「数字 3 的第二处副本」。 改成引用 unlucky_core::download::config::DEFAULT_MAX_ATTEMPTS_PER_SOURCE（download.retry_limit 的 schema 默认值同源），core 侧一个字未改。 这条带 header 的路径（只有 CurseForge 用）拿不到宿主设置，所以只吃出厂默认——这一点写进了 doc 注释，免得下一个人以为它会跟随用户的 download.retry_limit。	2026-11-09 09:32:51 +08:00
AskaEth	56402d97a1	Merge branch 'feat/m201-cfgkeyring-compile-time-strip-of-th'	2026-11-09 08:37:18 +08:00
AskaEth	50d13d26ab	fix(m201): 测试钥改由 #[cfg] 编译期剔除，无测试档产物里不再留那段字节 ... `keyring()` 原先用 `cfg!(...)` 判断要不要并入测试钥 —— 那是「运行期值为假的分支」， `TEST_ONLY` 的字节照编进产物（实测：无 feature 的 dev / release 两档 core rlib 里， 测试公钥十六进制与 key_id 都能 grep 到）。 * `TEST_ONLY` 拆成两条同名 const：`#[cfg(any(test, feature = "update-test-source", feature = "update-test-key"))]` 的真条目 + `#[cfg(not(any(...)))]` 的空表； `keyring()` 删掉 `cfg!` 判断，改成无条件 `extend_from_slice(TEST_ONLY)`（空表那档等于 什么都没并，`mut` 两档都有用武之地，不需要 `unused_mut` 口子）。 * 文档把 M199 降级掉的那句强断言改回真话，并贴出六行实测读数（dev / release 均 0 命中， 带 `--features update-test-key` 的对照臂 2 命中）。 * 明确划界：读数只到 rlib 为止；最终 exe 经 `lto = "fat"` + `strip = "symbols"` 之后是否 仍有那段字节**未验**。 验收：cargo fmt --all --check → 0；cargo clippy --workspace --all-targets -- -D warnings → 0； cargo test -p unlucky-presenter → 311 passed / 0 failed（1 ignored）； cargo test --workspace --all-targets → 0。	2026-11-09 08:19:04 +08:00
AskaEth	de41e4c3b1	Merge branch 'feat/m200-presenterfix-sign-manifest-fixtures'	2026-11-09 07:56:36 +08:00
AskaEth	540b82e197	fix(m200-r1): 文档降到实测能撑的程度 + 守门收紧 core 声明内容（复审 P2-1 / P3-1） ... 复审 reviewer-presenterfix-r1 的 fix-then-merge 两条，逐条落地。 P2-1(a)「两档」措辞被本次提交自己作废 ⇒ 三处全改成三档： * `crates/core/src/update/trust.rs` 模块文档（读者最先看到的那句，上次漏了） * `crates/core/src/update/tests/support_sign.rs` 模块文档 + `TEST_SIGNING_SEED` 的文档 P2-1(b)「三者都进不了发布产物」被复证实测证伪（`cfg!()` 是运行时假分支，不是 `#[cfg]` 编译期剔除；无 feature 的 dev 与 --release 两档 core rlib 里公钥十六进制与 `test-only-key` 都在） ⇒ 降级到事实能撑的断言：「不会被 `keyring()` 并进信任表，正式构建永远不认这把测试钥」， 并明写「字节仍编在产物里」「字节级不在产物里未证、也未声称」「换 `#[cfg]` 是另一条结构性改动」。 没有换成 `#[cfg]`（那是复审建议另开的 mission）。 P3-1 守门对 core「自己的声明」只认形状 ⇒ 收紧为只许空数组： `DECLARATION` 从 `^\s*update-test-key\s*=\s*\[` 改成 `^\s*update-test-key\s*=\s*\[\s*\]\s*$`， 并加一条自检向量（core 声明里偷偷带子 feature ⇒ 必须红）。`--self-test` 从 6 条变 7 条 （5 红 / 2 绿）+ 基线，`packaging/README.md` 的计数同步。 ⚠ 一个自己踩出来的坑，已被既有守门抓住：收紧时我先在 `check_test_key_off.py` 里把那条更宽的 测试通道 feature 写成**字面量**（自检向量 + 文档表格），`check_test_source_off.py` 立刻红 （`packaging/**` 按字面扫，这次提交前它一直是绿的）。改法照该文件自己的声明办——用 `OTHER_FEATURE = "-".join(("update", "test", "source"))` 拼出来，源码里字面量为 0， 自检向量仍然构造出完整字符串并必须判红。 验证（均在最终树上）：`cargo test --workspace --all-targets` 0、`cargo fmt --all --check` 0、 `check_test_key_off.py --self-test` 0（7 向量）/ 正式扫描 0、`check_test_source_off.py` 0、 `check_workflows_yaml.py` 0。	2026-11-09 07:56:33 +08:00
AskaEth	528f5706a0	docs(m200): 补 update-test-key 的两处文档一致性（cherry-pick 之外） ... `80b291c` 原样落盘（与本提交前一个 commit 逐字节相同），这里只补两处**文档一致性**， 不改任何判据、不改任何 feature 行为： 1. `crates/core/src/update/trust.rs`：`TEST_ONLY` 的文档注释还写着「**只**在 `cfg(test)` 与 `update-test-source` 构建里存在」——同一文件里 `keyring()` 新增的表已经把三档（`cfg(test)` / `update-test-source` / `update-test-key`）讲清了，上面这句变成了自相矛盾的旧口径。改成三档， 指向 `keyring()` 的说明。 2. `packaging/README.md` §12「文件清单」：新守门 `packaging/check_test_key_off.py` 已接进 `release-guard.yml`，但清单表里没有它（同类守门 `check_test_source_off.py` 在表里），补一行。 验证：`cargo test --workspace --all-targets` exit 0（311 passed）、`cargo clippy --workspace --all-targets -- -D warnings` exit 0、`cargo fmt --all --check` exit 0、 `packaging/check_test_key_off.py`（自检 + 正式扫描）exit 0、`packaging/check_workflows_yaml.py` exit 0。	2026-11-09 07:56:33 +08:00
AskaEth	19cc5c7950	fix(m190): presenter 更新链路用例补上清单签名（6 条既有测试回绿）+ 测试公钥守门 ... 背景：M190 把「验签」做成了强制且唯一收口（`source::verified_manifest`，先验签再解析），而 `crates/presenter` 的更新链路用例只写 `manifest.json`、不写 `.sig` —— 它们写在验签之前，所以在 dev 上红成 6 条 `signature_missing`。真发布本来就必须带 `.sig`，所以修的是**夹具**，不是判据： 没有放宽任何断言、没有在测试里关掉验签、没有把 `available=true` 改成「接受 Failed」。 夹具（`crates/presenter/src/host/update_tests.rs`）： * `write_manifest()` 把清单**连签名**成对落盘（`dist/stable.json` + `dist/stable.json.sig`）， `dir_source()` 改走它；三处直接写清单的用例（坏清单 / 空清单 / 缺本平台产物）也改走它。 * 签名用 `TEST_SIGNING_SEED` + `key_id = test-only-key`，信封形状与 core 的 `tests/support_sign.rs` **同源**（文件头写明「改一处要改两处」；presenter 不依赖 core 的 `#[cfg(test)]` 资产，也没把测试资产导出成生产 API）。 为了让这把**公开**测试公钥在 presenter 的测试构建里被认得： * core 新增 feature `update-test-key`（**只**把 `trust::TEST_ONLY` 并进信任表，不开任何数据源开关）； * 只有 `crates/presenter` 的 `[dev-dependencies]` 打开它（库/发布构建拿不到）；锁里只多 `ed25519-dalek` 这一行（presenter 的 dev-dep，包已在锁里，无新包、无版本变动）； * 新守门 `packaging/check_test_key_off.py`（238 行，带 6 条变异自检）接进 `release-guard.yml`： core 的 `Cargo.toml` 只许自己的声明、presenter 只许 `[dev-dependencies]` 段内，其余（workflow / packaging 脚本 / 根 Cargo.toml / cargo 配置）出现即红 —— 这把钥进发布构建就等于「谁都能签出官方更新」。 * 没有用 `debug_assertions`/`cfg(test)` 旁路：那会让「测试构建的信任表和发布构建不同」变成一句注释， 而不是一条门禁。	2026-11-09 07:56:32 +08:00
AskaEth	1f2d89c23e	Merge branch 'feat/m199-javaguard-auto-scan-and-proc-kill-g'	2026-11-09 07:20:18 +08:00
AskaEth	aae9a233ff	fix(m198): JAVAGUARD——首屏自动扫 / 子进程回收 / 参数长度三条守卫 + 设置页正文结构断言 ... - 首屏自动扫：删掉 `cfg!(test)` 分叉，生产入口在测试里真跑；新增 `the_first_hydrate_starts_a_real_scan_by_itself`（删掉那一行、或把实参翻成 `true` 都红）。顺手删掉恒为假的 `seeded && !live`：截图种子档在上方就 return 了，编译器也 报 "assigned but never used"。 - proc：`kill()` + `wait()` 收进 `terminate()`（三个分支共用）；用例先用同一条命令 真跑一次证明子进程起得来（`spawn().ok()?` 的空跑假绿），并新增 Linux/Android 的 僵尸回收用例（只 kill 不 wait ⇒ `/proc/<pid>` 留成僵尸）。 - java.extra_args：`MAX_JVM_ARGS = 1024` 镜像 schema，`Refusal::JvmTooLong` + 中英 文案 + JVM 输入框变红；App 级用例断言回执是具名的「太长」而不是通用的「写不进去」。 - 设置页正文：判据①从「数 `stack = stack.push(` 的出现次数」升级成按角色断言 （唯一来源 section_columns、`push(` 恰一次且实参是循环变量、尾表达式、禁 extend/chain/once/concat/append），单行折叠变异体现在会红。	2026-11-09 06:46:29 +08:00
AskaEth	7f697f5762	Merge branch 'feat/m198-javadown-jdk-version-list-and-mirro'	2026-11-09 06:28:22 +08:00
AskaEth	6e80fd3563	merge: origin/dev（1623f68）合入 M197 分支——解 golden/tail.rs 冲突 ... 基线：合的是 **origin/dev**（`1623f68`）。`origin/main` 是 D41 的孤儿发布快照 （`d616d65` parents 为空），不参与合并。用 merge 而不是 rebase，保住三轮复审 clean 的 tip。 冲突只有一个：`crates/i18n/src/catalog/golden/tail.rs`（热点文件，多条 mission 都往这里加 key）。 解法（不重排别人的行、不改别人的译文）： 1. 以 **dev 侧 398 行**为底稿（含其它 mission 后加的 key）； 2. 把 M197 的 68 行（`SettingsJavaTooNew` … `SettingsJavaReasonInstallRootTooLong`） 整块插在 `SettingsJavaReasonWriteFailed` 之后、M174 助手域（`SettingsGroupAssistant`）之前 —— 即 `settings_java_entries` 那段之后，装配链的正确位置； 3. 两侧合起来 463 行会越过 400 行硬线，于是按既有先例把**M174 助手域起的那半截** （dev 的 260 行）整段纯搬移到 `golden/tail_ai.rs`：`tail.rs` 211 行 / `tail_ai.rs` 274 行， 链序 `golden → tail → tail_ai → tail2` 不变，逐字节不删不改； 4. 解冲突时发现 dev 的 golden 行还是 M197 之前的旧文案（`SettingsJavaEmptyBody` / `SettingsJavaAddHint` 的反引号、`SettingsJavaNeverScannedBody` 的旧说法），已把这三条的 金表行同步回域文件里的现行文案（`split_keeps_every_translation` 逐位置比对当场抓出来的）。 顺带（合并导致的越线）：`crates/core/src/download/engine.rs` 两侧各 400 行、合并后 401 （我 +1 行 `kind: err.kind`，dev +1 行），把模块文档里那三行散文重排成两行（一字未删）→ 400 行。 同一次还把这文件里对 `MirrorTable::set_gh_proxy` 的旧描述改成 M193 的现实（那两个函数已被删）。 验证：fmt 0 · check（app-iced+core+i18n all-targets）0 · i18n 36 · engine_mock 8 · app-iced java 45 · core lib java 71 · setting 116 · app-iced lib 全量 832；全仓 file-size 守门脚本复制执行 → 超限 0。	2026-11-09 06:17:54 +08:00
AskaEth	1623f68483	Merge branch 'feat/m197-shellfix-gui-subsystem-and-cli-stdo'	2026-11-09 06:01:42 +08:00
AskaEth	9bb9855392	Merge branch 'feat/m194-dlmsettings-wire-download-concurren'	2026-11-09 05:36:38 +08:00
AskaEth	98262d3835	Merge branch 'feat/m196-straycard-settings-page-renders-for'	2026-11-09 05:23:49 +08:00
AskaEth	fb0b1a5311	merge(dev): 解 M196 与 dev（M179/M193）在 settings/mod.rs 的冲突 ... `origin/main` 是 D41 的孤儿快照（单提交、与开发史无共同祖先），M179/M193 这些提交在 `origin/dev` 上；按「跟上主线」的意图合的是 `origin/dev`。用 merge 不用 rebase：复审 clean 的 tip `e5a4b9b` 原样保留，本提交只负责解冲突。 唯一冲突：`settings/mod.rs` 里 `form` 的文档注释（M179 与 M195 重写过同一段）。两边都留： - **M179/M193**：`type Body` 带 `Lang`、四条按下标分发（General / Update / Assistant / Java）、 M193 的 download / logs 接线及其文档更新——只有一处措辞随之调整：「四组在下面各有 `else if`」 → 「在 [`section_columns`] 里各有 `else if`」，因为 M195 把那层循环抽成了独立函数； - **M195**：循环之后不再 push 那张「没有逐实例覆盖」的空态卡、`overrides_empty` 不存在、 `section_columns` 与其行为断言（`frame.rs` 两条用例）。 合并后的注释同时说明两件事：`GROUP.body` 从形参拿生效语言（M179）+ 尾部不许再挂东西、 逐实例覆盖的真控件在实例详情页（M195）。 为守住 400 行硬线（冲突态 424 → 399），只压自己的重复叙述：M196 段压到 4 行、 `section_columns` 的文档改为指向 `form`（它原来重复了一遍分发点，且在 M179 之后已不准确）、 模块文档里一段被 M179 实现取代的历史「r3 订正」压成一句可执行的结论。 代码零语义改动（证据见汇报）：`section_columns` 的循环体与 `origin/dev` 归一化后逐字节相同（46 行）， `GROUPS` / `GROUP_LABELS` 三方一致；相对 `origin/dev` 的差异只剩本 mission 的 4 个文件。	2026-11-09 05:18:29 +08:00
AskaEth	0e6d21ba89	Merge branch 'feat/m195-importcancel-import-pipeline-cancel'	2026-11-09 05:07:04 +08:00
AskaEth	59011b2d56	fix(m195): 复审 r3 —— 失败不再被说成「取消太晚」，并给三档补推导用例 ... P2-1（界面撒谎）：`cancel_view` 的 `_ if cancel_requested => TooLate` 把 `Failed` 也吞进去了。 「点取消的同时摘要不符」这类失败（取消置位之后、下一个检查点之前的非容忍失败）会得到 `status=Failed cancel=TooLate rolled_back=true`，于是同一屏上红卡说「已回滚 —— 目标目录零残留」， 下面还有一句「取消来得太晚：这次导入已经跑完，实例会保留，同名文件可能已被覆盖」——后半句是假的， 而且与红卡直接对立。改成**只有** `Success | Partial + cancel_requested` 才判 `TooLate`； `Failed` 一律 `NotRequested`（失败卡自己用 `failure_stage` 分「没写过 / 回滚干净 / 回滚没做完」， 真相已经说全）。 另外 app-iced 的 `cancel_note` 加一道双保险：只有 `status` 是 `Success/Partial` 时才出那句话， 推导万一回归也不会贴到红卡上。 P2-2（推导零覆盖）：此前只有「给定这一档、文案怎么画」的用例，把 `RollbackIncomplete` 的推导 删掉也全绿。现在 `convert/cancel.rs` 带三条推导用例：`Cancelled + !rolled_back ⇒ 回滚没做完` （含对照 `rolled_back ⇒ 已回滚`）、`Failed + 取消 ⇒ NotRequested`（含对照 `Success/Partial ⇒ TooLate`）、 没点过取消 ⇒ `NotRequested`。 变异实测： - P2-1：把 `Failed` 也判 `TooLate` ⇒ `a_failed_run_is_never_dressed_up_as_a_late_cancel` 红 （`left: TooLate / right: NotRequested`，"失败的导入没有「跑完」这一说"）。 - P2-2：删掉「回滚没做完」的推导（`Cancelled` 一律按已回滚）⇒ `an_incomplete_rollback_is_its_own_bucket` 红 （`left: RolledBack / right: RollbackIncomplete`）。 验证：`cargo test -p unlucky-core -p unlucky-presenter -p unlucky-app-iced` = 2188 passed / 0 failed； `-p unlucky-i18n` = 31 / 0；clippy 四 crate = 0 warning / 0 error。	2026-11-09 05:06:56 +08:00
AskaEth	b1524635ba	fix(m195): 复审 r2 —— 取消的真实结局必须到达界面（三档 + 终态穿透代次） ... 复审 r2 P2-1：界面无条件断言「已停手并回滚：没有留下半包，也没有覆盖已有文件」，而两条路径下 这句话是假的——①取消来得太晚（落在最后一个检查点之后）时管线已经跑完，用户的同名文件被覆盖、 实例已登记；②回滚本身没做完（`rolled_back=false`）。core 一直是诚实的，是 presenter 把报告丢了： `cancel.load()` 早退 + `cancel_pack` bump 代次后 `handle` 按代次丢弃。 按"接通真相"做（不是改软话）： - **终态一定发出**：`import::run` 去掉 `cancel` 的无条件早退，收尾抽成 `finish`（清自建空目录 + 无条件 `send(PackEvent::Report)`）；取消标记在管线返回后**再读一次**，作为"太晚"的唯一证据。 - **终态穿透代次**：`HostPackState::terminal_epochs` 记下 `cancel_pack` 作废的那个代次， `handle` 对它**只放行一条 `PackEvent::Report`**（进度事件照旧按代次丢，`fresh_cancel` 起新 一轮时清空）。这是路径 A 的成因与修法。 - **DTO 三档**（tower 批准扩 scope）：`ImportStatusView` 加 `Cancelled`；新增 `ImportCancelView { NotRequested, RolledBack, RollbackIncomplete, TooLate }` 挂在 `ImportReportView::cancel` 上——已回滚 / 回滚没做完 / 取消太晚，三档各自可判。 `PackEvent::Report` 到达时清掉 `ImportState.cancelled`（它现在只是"取消后还没有结果"的占位）。 - **界面按结局分支**：标题 `PackStatusCancelled`（已取消 — 已回滚）/ `PackCancelIncomplete` （已取消 — 回滚没做完）/ 取消太晚时保留真实状态标题并另起一句 `PackCancelTooLate` （实例会保留、同名文件可能已被覆盖）；占位的 `PackCancelled` 改成"正在停手，真实结果随后给出"。 图标：`Close`（描边，页面对填充字形有守门）/ 回滚不完整用 `Warn`，一档都不用 `Role::Error`。 守门与变异： - 新增路径 A 用例 `a_late_cancel_still_delivers_the_real_outcome_to_the_ui`：真管线把取消置在 **最后一条 Commit 进度**上（之后没有检查点）⇒ core 报 `Success`/未回滚、用户的 `mods/a.jar` 确实被覆盖；再 `cancel_pack`（代次 +1 并记终态）→ `finish` → `handle`，断言界面收到 `status == Success` + `rolled_back == false` + `cancel == TooLate`，且同代次的进度事件仍被丢。 - 变异①：`handle` 恢复"代次不符一律丢" ⇒ 该用例红（"取消太晚时，真实结果必须到达界面"）。 - 变异②：`finish` 恢复"取消就早退" ⇒ 该用例红（另带 P2-2 那条也红）。 - app-iced 新增 `model/tests/cancel.rs`：三档标题互不相同 + 「太晚」必须有那句补充说明 + 已回滚不许显示成「部分成功」。 验证（CARGO_TARGET_DIR=C:/Temp/ull-target/wt-194）： `cargo test -p unlucky-core -p unlucky-presenter -p unlucky-app-iced` = 2185 passed / 0 failed； `-p unlucky-i18n` = 31 / 0；clippy 四 crate = 0 warning / 0 error。	2026-11-09 05:06:55 +08:00
AskaEth	db5b08b9ab	fix(m195): 复审 r1 三项 —— 解压检查点真守卫、presenter 接线测试、取消文案改回真话 ... P2-1（解压循环检查点没有真守卫）：那条用例原来的断言（status/target/files/bytes/无残留暂存） 在删掉 `extract_overrides` 的检查点后**依然成立**——提交前检查点⑤会替它停一次，于是几 GB 的包 会一直解到结束而测试全绿。改成数 `ImportStage::Extract` 事件：有检查点 = 1 条、删掉 = 3 条 （两面实测）。模块文档同时如实登记"还没有真守卫"的检查点：②③④⑤、全新导入 commit 的取消 分支、phase.rs 远端下载逐条、complete.rs 补全循环的 break。 P2-2（presenter 的真令牌接线零测试）：新增 `pack/tests/cancel.rs`，直接调 `import::run` 并把 传入的 `Arc<AtomicBool>` **预先置 true**，判据只能是盘上事实（目标目录不存在 + profiles.json 零实例）——"没收到 Report"那种判据两条路都成立，`run` 早退条件里的 `cancel.load()` 会把 "没接线"完全遮住。 P2-3（用户可见文案说反了话）：`PackCancelled` 中英双语从「导入会在后台继续跑完 / Import keeps running in the background…已经写下的文件会留下」改为「导入已取消 —— 后台已停手并回滚：没有留下 半包，也没有覆盖已有文件」；golden 金表同步；`model/tests.rs` 那条把旧文案钉死的用例改成钉新 语义（必须说清停手+回滚，且**禁止**出现 background）；`model.rs` 的 `cancelled` 字段文档与 `dispatch.rs` 的取消注释同族修正。 验证：`cargo test -p unlucky-core -p unlucky-presenter` 1480 passed / 0 failed； i18n 31 / 0；app-iced packui 28 / 0；三 crate clippy 零 warning。	2026-11-09 05:06:53 +08:00
AskaEth	1441a240fe	feat(m195): 导入管线取消令牌与原子回滚（取消不是失败） ... M190 复核 §3 A-2：导入管线没有取消令牌，「取消导入」只改界面状态，后台仍跑完并写盘 （半包 / 覆盖风险，丢数据档）。本轮把取消做成管线级： - core 新增 `import/cancel.rs`：`ImportCancel` 令牌（可 `from_flag` 接管既有 `Arc<AtomicBool>`）+ 内部 `Stopped::{Cancelled, Failed}` 两条停止路线； - 结果类型单列 `ImportStatus::Cancelled`（`error` 恒为 None、退出码 130、文案 key 独立）， 与 `Failed` 是两条路——UI 不弹红、脚本不会把「改主意」记成「装坏了」； - 七个检查点：入口 → 解析后 → 补全后 → 开暂存目录前 → 提交前 → 合并态逐文件 → 登记前； 解压 / 远端下载各逐条检查；单条下载在飞不可中断（fetcher 无取消参数）已在文档里说准； - 取消后不留半包 / 不覆盖已有实例：暂存目录整个删、合并态 journal 逆序回滚（备份改回原名）、 落盘后取消连内容一起回滚；`files / conflicts / missing / bytes_written` 清零，不留假账； - presenter：同一个取消标记现在真交给 core（`with_cancel`），取消后不再「后台跑完并登记」； CLI 增 `cancelled → 130` 一档与三档人读名。 守门三条各带变异证明（见 mission 报告）：删回滚 → 红、删登记前检查 → 红、把取消并进 `fail()` → 红。 没验：超大整合包的真实 IO 下取消响应延迟（最坏 = 当前一条文件读完/下完 + 一次回滚）、 单条下载在飞不可中断、macOS / Linux 未跑。	2026-11-09 05:06:52 +08:00
AskaEth	3116f43c9f	Merge branch 'feat/m192-retryui-surface-dependency-failures'	2026-11-09 05:06:09 +08:00
AskaEth	476bf92f97	test(addon): 给「失败路径取名字」的生产接线与降级补守卫 (M191 r3) ... 复审 r3 p2：那两处都只靠消费层用例撑着，生产接线上删掉/改坏也全绿。补两条能真红的守卫。 **接线层**：`install.rs` 里那次 `names_for_incompatible(..)` 原来不可驱动。现在下载器与 取名字器从 `Ports` 参数进来（生产 = 引擎 + `plan::fetch_title`，用例 = 假实现）， 于是用例能驱动**生产那个 `collect`**：一份「一个文件下成功 + 一个不兼容前置 + 一条 404」的 计划跑完，断言不兼容那条拿到了名字、且**只**给不兼容档问过一次。 变异（把那一行短路成空名单）⇒ `the_failed_install_path_really_fetches_names_for_the_incompatible_items` 红：`left: "P7dR8mSH"` / `right: "Entity Culling (P7dR8mSH)"`。 **降级层**：把「一次查询 → 有名字/没名字」的折叠抽成 `title_from(query, id)` （`fetch_title` 只剩「建客户端 + 调它」）。参数化之后三种「没名字」都能离线钉住： 查询失败 / 空标题 / 全空白 ⇒ `None`，不 panic。 变异 ①`ok` 换 `expect` ⇒ `a_failed_or_blank_lookup_yields_no_name` 红 （panic：`带断网`）；②去掉空串过滤 ⇒ 同一条红（空白档）。 **顺手**：`fetch_title` 真发一次 HTTP 的那一跳没进用例（本轮实测它确实取到了真数据 `P7dR8mSH → "Fabric API"`，但把网络调用放进 `cargo test` 会变脆，所以只把可坏的那一步——折叠—— 参数化测掉，报告里如实写「HTTP 这一跳仍无用例」）。 **行数**：`install.rs` 加到 415、`tests/retry.rs` 到 436，都越过 400 硬线 ⇒ 两步纯搬移： `collect` + `Ports` + `Placement` → `install/collect.rs`（117 行，`install.rs` 321）； r3 用例 → `tests/retry/wire.rs`（115 行，父文件 332）。	2026-11-09 05:06:06 +08:00
AskaEth	26e7b7333e	fix(content): 不兼容档在失败路径上取项目名 + 重试轮不再贴错根的标题 (M191 r2) ... 复审 r2 两条 p2，都修了，并按复审给的口径验过红。 **P2-1（续）：不兼容档不再只有裸 id** `FailureKind::Incompatible` 的项目**确实存在**（站点只是没有匹配目标版本/加载器的条目）， 所以失败路径上值得现取一次名字——`plan::names_for_incompatible` 按失败项去重、一项一次 GET （`Modrinth::project`），`fetch_title` 把任何失败都折成 `None`： **拿名字失败不许影响安装结果**，取不到 / 拿到空标题就退回 id。只有这一档发请求； 「取不到」档 404 那部分项目根本不存在，再发一次只会再吃 404。 **P2-2（新）：重试轮把根的标题贴到了前置头上** 根因是判「这条是不是根项目自己失败」用了 `plan.request.roots.first()`，而重试那一轮的 plan 来自 `retry_request()`，它的 `roots` 就是上一轮的失败名单——第一个是前置。 现在判据改成 **id 比对**（`Root{id,title}`，id 由 `remember` 一起记下来）： `label_of` 只在这条失败的 id 真的等于原始根 id 时才用根的标题。复审给的那个形状 （roots=["P7dR8mSH","1eAoo2KR"] + root_title="Sodium"）现在画 `P7dR8mSH`，不再是 `Sodium (P7dR8mSH)`。 **守门（每条都真跑红过，且在拆完模块的最终代码上复跑）** - 去掉不兼容档的名字来源 ⇒ `an_incompatible_item_shows_the_project_name_once_it_is_known` 红 （`left: "P7dR8mSH"` / `right: "Entity Culling (P7dR8mSH)"`）。 - `label_of` 换回 `roots.first()` ⇒ `the_retry_round_does_not_paste_the_root_title_onto_a_dependency` 红 （`left: ["Sodium (P7dR8mSH)","1eAoo2KR"]`，正是复审实测的那一行）。 - 取名字不降级（`expect`）⇒ `a_failed_name_lookup_falls_back_to_the_id_without_breaking_anything` 红。 **行数**：`plan.rs` 加完这套到 414 行、`install.rs` 到 403 行，都越过 400 硬线 ⇒ 把「名字从哪来」整块（`Root`/`Names`/`names_for_incompatible`/`label_of`/`fetch_title`） 纯搬移到 `plan/labels.rs`（111 行）：`plan.rs` 336、`install.rs` 388。	2026-11-09 05:06:06 +08:00