563 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
AskaEth	3cd371b537	fix(m187): r1 复审——深色遮罩提亮、点遮罩关闭、包内条目名、截断保尾、启动日志接线 ... P1（阻断）：遮罩从 Role::OnSurface@32% 换成组件层的不透明预合成 （feedback::dialog::scrim，黑@0.32 叠画布）。深色档此前是「近白@32%」把整窗提亮， 实测 (9,21,28)→(129,138,145)；现在 (6,14,19)（= 组件文档预测值），且两后端逐字节相同。 顺带按纪律改用 Component::Dialog + DialogGeometry（半径 28 / 宽 560 / 内距 24）， 两后端弹窗图差异从 66% 降到 2.65%（浅）/ 2.76%（深），余量全是文字抗锯齿。 P2-1：卡片那层的命中区改回卡片本身（opaque 只包卡片）。此前 mouse_area 包的是整窗居中 容器 ⇒ 点卡片外先被 Swallow 捕获，遮罩永远收不到，「点遮罩关闭」只在注释里成立。 守卫：断言卡片层的 size_hint 任一维都不是 Fill。 P2-2：条目名与清单**同源**（BundleSpec::entry_names），会话 JSONL 钉成 session/session.jsonl。 此前条目名用原始文件名（会话 id 原样进包）而 manifest 过了 redactor ⇒ 清单指向的条目不存在。 （上一轮报告把这条写反了，本轮以 unzip -l 实输出为准。） P2-3：截断改「头 + 尾」（MAX_ENTRY_BYTES 一半一半，中间插 <truncated N bytes>）， 并在弹窗补一句「有 N 个文件太大，已截断」。此前只留头部 ⇒ 长会话 JSONL 的 exit 事件丢失。 P2-4：app 启动那一拍（主题/语言/路由/窗口/实例数/msa 行）真的写进 launcher_log； 目录仍由 presenter 在首次启动时登记，所以这些行先进 core 缓冲、登记时一次刷出。 P3-1/P3-2：关闭与 Esc 立即重画（否则空闲 1Hz 下弹窗再留 1 秒）；导出成败按 write_bundle 真实结果判（不再看 launcher_logs 有没有值）。 用例：新增 5 条（深色遮罩方向、卡片层命中区、条目名与清单一致、截断保尾、启动日志落点）， 每条都给了变异证明（只改实现侧，均已还原）。	2026-11-08 23:21:26 +08:00
AskaEth	414f6ff886	feat(m187): 启动失败弹窗 + 诊断包导出，并接通 DialogQueue ... 用户实测「MC 启动失败找不到崩溃日志」的直接修法：失败时弹一个框，把退出码、 一句人话原因、证据形态、四条真实路径与三个按钮摆在同一个地方。 - app-iced：最小一层模态（遮罩 + 卡片 + 主/次按钮 + Esc/点遮罩关闭）， 消费 presenter 的 DialogQueue（此前全仓零引用，所有弹窗都画不出来）； 队列管弹窗，CrashCard 管这次失败的事实，按 DialogId 绑定。 - 弹窗区分两种失败：游戏自己写了 crash-reports（贴 Description + 栈片段）/ 游戏没来得及写（明说「这次没有生成崩溃报告」并贴出捕获的最后 30 行）/ 什么都没抓到（给最可能原因分类）。绝不对第二种说「找不到日志」。 - 导出诊断包：core 侧新 crash_bundle 写 zip（清单 + 启动器日志 + 会话 JSONL + crash-reports/* + hs_err + latest.log + 版本 JSON），落盘即脱敏（家目录 / token / 会话 id），单文件 4 MiB、总量 48 MiB 上限并在清单记截断。 - 启动器自身日志落盘（core::launch::launcher_log → <.ULL>/logs/launcher.log， 登记目录前先缓冲），补上「双击启动时诊断行直接蒸发」的缺口。 - i18n：25 条中英文案进 catalog/logs.rs + 金表。 - 取证：ULL_DIALOG_FIXTURE=crash-report|no-logs|export 在临时目录造真文件出图， wgpu 与 tiny-skia 各一套，见 DevDocs/artifacts/m187/。 未复现 M190 的「owned 文字在 wgpu 下丢字」：同一串中文两条文字路径、两种后端逐字相同 （ab-wgpu.png / ab-tinyskia.png），因此本轮未改任何渲染路径。	2026-11-08 22:42:00 +08:00
AskaEth	7b79d5c397	chore(m197): 三处拆文件守 400 行硬线（复审 r1 后新增内容把三个文件顶过线） ... - `core/src/setting/keys.rs` 396（原 400 → 我的 +15 到 415）：`download.proxy_mode` / `proxy_url` / `gh_proxy` 三键搬进新 `keys/proxy.rs`（`specs()` + 一句「空串 ≠ 关」的守卫）， 主表留一行 `.with_all(proxy::specs())`——与 `font` / `update` 同一种形状。 - `core/tests/download/engine_mock_test.rs` 407 → 364：404 那条用例整条搬进 `tests/download/engine_mock/not_found.rs`（`#[path]` 子模块，仍是 `engine_mock` 这个 target）。 - `pages/settings/java/downloads/tests.rs` 423 → 313：gh-proxy 两条守卫搬进 `downloads/tests/gh_proxy.rs`（`#[path = "tests/gh_proxy.rs"]`）。 纯搬移 + 一条新单测（`keys/proxy.rs` 的「空串 = 跟随内置默认，不是关」）；行为不变。	2026-11-08 21:42:15 +08:00
AskaEth	29da7e2e47	Merge branch 'feat/m180-i18nappear-localize-appearance-page'	2026-11-08 21:42:14 +08:00
AskaEth	1d240ff1f2	fix(i18n): 复审 r1 —— 两句近义软件渲染说明合一，生效层级码翻成译文（M180） ... P2-1（一屏两句重复）： - 留面板那一句（就在被禁用的滑块旁边，正好回答「为什么拖不动」），措辞同时点名面板与玻璃 - 删 `SettingsAppearanceSoftwareRendererNote`（catalog 一条 + 金表一行，两边同时删） - 删 `bg_image.rs` 的 `backend_note` 渲染块与 `State::backend_note()`；state.rs 391 → 382 行 P2-2（配色：preset 的机器码）： - `palette::level_key(code)` 把 `preset`/`wallpaper`/其余 映射到已有的三条档位 key，不新增平行词表 - `bg_image.rs` 用 `tr(PaletteLevel, {level})` 传译文，中文界面显示「配色：内置色卡」 - 补 `every_level_code_maps_to_its_own_sentence`：三个码值一一对应 + 三条译文互不相同 顺手（复审 L-1/L-2/L-4，全在本 scope 内）： - `appearance_texts` 加「渲染后不许残留 `{`」断言（参数名写错当场红） - `section/mod.rs` 文档：取词口 t/tr、填充措辞、清掉孤立 `//!`、把「没有一句英文」改成 写明两处例外（`{reason}` 原文串、专名）	2026-11-08 21:42:12 +08:00
AskaEth	c4c3c15285	feat(i18n): 外观页 40 条文案进词表（M180 I18NAPPEAR） ... - 卡片内 22 处硬编码英文（整窗/面板透明度、背景图开关+路径、填充、暗化、配色来源）全部改走 Key - 运行时诊断改成 key + 参数：`background::Note`（读盘/解码/过大/小图平铺）、`state::backend_note`、 `palette::note` 全部返回 Key；`state.rs` 只留 key、不放文案表（390 → 391 行） - 上限/下限常量走占位符 `{floor}` / `{max}` / `{limit}` / `{requested}`；`{:.2}` 在 Rust 侧格式化好 再套模板（`Catalog::render` 只认 `{name}`） - 新增 40 条 key（中英各一条），按装配链锚点插在 `SettingsAppearanceCornerSuspended` 之后， 金表 `golden/tail.rs` 同位置插入 40 行（`rows() == len() == Key::ALL.len()`） - 守卫三条：中文渲染全非 ASCII、卡片 key 全覆盖（改回写死英文即红）、外观 key 逐条真翻过 - probe 加第二条取证路（`record_rendered`），`take()` 签名不动（M179 的守卫在 scope 外）	2026-11-08 21:42:11 +08:00
AskaEth	65e7ccc3bf	Merge branch 'feat/m184-linuxci-promote-linux-slots-into-re'	2026-11-08 21:35:30 +08:00
AskaEth	7e8b8740c4	fix(m184): r1 —— 证据账不再把「机制会跑」写成「已有运行时证据」，并收 5 条文档漂移 ... P2-1（唯一阻塞）：`packaging/docs/linux-evidence.md` 里 `ull --version` 冒烟那条被写成 「两个槽位都有一份 CLI 运行时证据」——`make_artifacts.py::smoke_version` 只保证**机制** （`slot == host_slot()` 时真跑），而仓库里找不到任何一次 linux-arm64 成功出包的记录 （`git grep -rn all_slots DevDocs/` 零命中），所以 arm64 侧运行时证据为零。§1 表格与 §5 改成「机制上会真跑 / 截至本分支没有那一次记录」，§6 解锁条件同步补一句。 P3 漂移： 1. `release-publish.yml` 注释 8 条 → 11 条自测回归（与脚本/其它三处一致）。 2. `packaging/docs/profiles-and-measurements.md` 同上 8 → 11。 3. `check_publish_slots.py` 注释示例 `PUBLISH_SLOTS: "windows-x64"` → 两档现值。 4. `release-build.yml` 注释「x64（当前唯一在发的槽位）」→ 两档已发布，并点名 linux-x64 的证据在自己的 xvfb 冒烟步。 5. `linux-evidence.md` 「20 倍以上余量」→ **8~37 倍**，并点明最紧的是亮度 σ （24.06/3.0≈8×，与 check_screenshot.py 自述的 1/5~1/8 一致）。 自查（复审点名的五处之外）：`只发 windows-x64` / `Windows only` / `暂未发布` / `once published` / `8 条` 全仓再扫一遍，release-notes / README ×2 / artifacts-and-version 剩下的都是准确表述（如「the only Windows asset」指 windows_x64.exe）。 验证：check_publish_slots --self-test EXIT=0、check_test_source_off EXIT=0，另 check_publish_slots(source) / check_release_semantics(+--self-mutation) / make_manifest --self-test 均 EXIT=0。本轮无 cargo 构建，未创建 CARGO_TARGET_DIR。	2026-11-08 21:35:26 +08:00
AskaEth	2813e2984c	ci(m184): linux-x64 进发布名单，两档 Linux 转 mode=ci，arm64 只构建不发布 ... 发布流水线默认从 2 个槽位变 4 个：`linux-x64`（ubuntu-22.04）与 `linux-arm64` （ubuntu-22.04-arm）的 mode 由 probe 改 ci，tag 推送默认就编。 构建 ≠ 发布仍由 `PUBLISH_SLOTS` 决定，本轮只加 `linux-x64`： - `linux-x64` 有运行时证据 —— release 产物在 Linux 真机（Ubuntu 22.04 + WSLg 真窗口） 渲出一帧、[theme]/[backend] final 日志齐全、像素判定通过，真窗口 1180x760 从 Windows 侧截屏可见；`release-build.yml` 另加一条**同槽位**的 xvfb 运行时门禁（只在 `inputs.slot == 'linux-x64'` 上跑，不给没验过的 arm64 造红）。 - `linux-arm64` 只有构建证据、运行时零证据，产物照出 artifact 取证但不发布；解锁条件 （真机渲出一帧 + 主题日志）写进 release-notes 与 §9。 守卫跟着扩（`packaging/check_publish_slots.py`）： - 自测从 8 条扩到 11 条，新增「声明的 linux-x64 构建红了 ⇒ 必须红（挡住发布）」、 「linux-arm64 有产物但没声明 ⇒ 只警告」、「提前把 linux-arm64 写进名单 ⇒ 缺产物必红」； - probe 档样例从 linux-x64 换成仍是 probe 的 macos-arm64（否则该用例会从「必须红」 变成「本来该绿」）； - 新增「mode=ci 却本次没产物 ⇒ ::warning::」：红一档不能只表现为表里少一行。 文档矩阵同步（release-notes §Downloads/§Support matrix、compliance §9/§10、 artifacts §1、build-and-ci §3、README ×2），两份文档都把 Linux 写成 「已构建并发布（x64）/ 已构建未发布（arm64）」，并把新发现写实：Linux 上整窗透明 与圆角没有代码路径（hwnd=none / corner=policy=system），不是「未验」；Linux 上 `ull update apply` 会拒绝 portable-zip（清单里现在有 linux-x64 产物）。 证据账（含实测输出、CI 增量估算、未验清单）：packaging/docs/linux-evidence.md。	2026-11-08 21:35:26 +08:00
AskaEth	a14b00aced	fix(m197): 复审 r1 的 P1 + 三条 P2（描述对齐行为 / 内部编号下屏 / kind 守卫 / gh-proxy 可覆盖） ... P1（阻断）`java.auto_install` 的描述与行为不一致——那句会进 AI 工具的 JSON Schema `description`，等于让助手对用户说一件实现刻意不做的事： - `crates/core/src/setting/keys.rs`：改成「缺 Java 时在 Java 页标出推荐版本并可一键安装； 不会自动下载」，去掉 `（D13 基准 JDK17）`。 - `SettingsJavaAutoInstallHint` 中英两侧各补一句显式否定（「不会自己开始下载 —— 点「安装」 才会下」/ "Nothing is downloaded on its own — you press Install."），标签从「自动准备」改成 「缺 JDK 时推荐一档」；金表同步。 - 新增守卫 `the_auto_install_description_says_it_never_downloads_by_itself`（描述必须含 「不会自动下载」、不含旧说法与内部编号）。 P2-1 内部决策编号印在界面上：`SettingsJavaDownloadBaseline` 的 `Baseline (D13)` / `基准版本（D13）` → `Recommended baseline` / `推荐基准版本`（金表同步）。另加两条目录级守卫 （`no_user_visible_string_mentions_an_internal_decision_id` / `no_user_visible_string_carries_markdown_backticks`）；后者顺带清掉 M168 遗留的 `FontCjkStatusHint` 里的 `ui.font_cdn` 反引号——全仓最后一条。 P2-2 `ProgressEvent::SourceFailed.kind` 没有守卫：`engine_mock_test` - `reports_progress_events_and_errors_when_all_sources_fail` 的解构补 `kind`，断言 `ServerError`； - 新增 `a_404_is_classified_as_not_found_and_never_cools_the_source_down`（404 → `NotFound`， 与「源坏了」分开）。 P2-3 交付任务书那句「（默认值可改）」：新增 `download.gh_proxy`（空 = 跟随内置默认 / `off` = 关 / 其它 = 覆盖前缀），`engine_with` 是它的真消费者（改 `RegionProfile`，因为 `gh_proxy_candidates` 读的就是档案里的前缀）；Java 页不画 UI（归 M193）。**内置默认值没动**。 schema minor 1.7.0 → 1.8.0（新键必须推 minor），三处硬编码 minor 的用例同步。 另：真下载用例改成 panic 也清理（复审顺带项 7④）；`downloads/refusal.rs` 的「四档」改「五档」。	2026-11-08 21:35:13 +08:00
AskaEth	dc3fa2be87	Merge branch 'feat/m182-maccorners-follow-compositor-rounde'	2026-11-08 21:34:42 +08:00
AskaEth	c198a3c995	Merge branch 'main' into feat/m182-maccorners-follow-compositor-rounde ... 冲突只有一个 hunk：`crates/app-iced/src/platform/mod.rs` 的模块声明表。 - 我方（M182）：`pub mod host;` / `pub mod linux;` / `pub mod macos;` + `pub use host::HostOs;` + `plan_corner_for` 重导出； - 主线（M168 `449ded2`）：`pub mod data;`（字体缓存数据根派生）。 两边都要，全部保留并按字母序排：`data, host, linux, locale, macos, win32`。 另把模块分册表补一行 `data`（M168 的产品在表里原本缺位），首段「四件事」随之改成「五件事」。 `pub use win32::corner::{…}` 取我方超集（main 的四个名字 + `plan_corner_for`），逐个名字比对无丢失。 非冲突文件零改动：我方 11 个文件（host.rs / linux/ / macos/ / win32/ / boot/diagnostics.rs / design/shape.rs）合并后与 tip 28762ec 逐字相同；`decorations: false` 仍在 `app/boot/diagnostics.rs:43`（裁决 B 未被越过）。	2026-11-08 21:13:20 +08:00
AskaEth	124e474656	Merge branch 'feat/m179-i18nseam-thread-lang-into-page-bodi'	2026-11-08 21:02:18 +08:00
AskaEth	ca92014b81	fix(m179): 复审 r2 —— 订正「Body 带 Lang 之后」残留的六处文档漂移 ... P2-1：`settings/mod.rs:273`（`AI_GROUP`）还写着「`Group.body` 的签名里没有 `Lang`」， 而同一次提交在同一个文件把槽位改成了 `fn(&Ui, States, Lang)` 并在上方 `GENERAL_GROUP` 按新事实重写 —— 一个文件里两段互相矛盾的说明。本条按新事实重写（行数不变，仍是 389 行）。 一并订正 finding 里剩下的外域漂移（tower 已扩 scope）： - `settings/ai_about.rs:8`（同一句假话的表格行，finding 没列到）与 `:14-16` - `settings/general.rs:7-11`（槽位现在带 `Lang`，装不下的只剩**档位** `LangChoice`） - `settings/general.rs:287`、`settings/update.rs:5`、`pages/mod.rs:271`、 `settings/language_appearance.rs:20` 的 `pages/appearance/section.rs` 路径 措辞与复审建议的一处偏离（已在提交与报告里说明）：复审建议写「槽位给不了『测试连接』的 结论」，与实现不符——该结论在 `States.groups.ai_about` 里，槽位拿得到；AI 组仍按下标分发 的真实原因是**尚未迁移**（槽位要 `Option<Element>`，`ai::view::body` 返回 `Element`）。 零代码改动：本提交所有变更行都是以 `//!` / `///` 开头的文档行 （`git diff -U0 | grep '^[+-]' | grep -vE '^[+-]+\s*//[/!]'` 为空）。 按 tower 要求**不动** `crates/i18n/src/catalog/settings/appearance.rs:8`（M180 正在改）。 验证：cargo fmt --all --check → 0；cargo check -p unlucky-app-iced --all-targets → 0； cargo clippy -p unlucky-app-iced --all-targets -D warnings → 0； cargo test -p unlucky-app-iced --lib appearance → 0（37 passed）。	2026-11-08 21:01:25 +08:00
AskaEth	9a7b138d08	chore(m197): 清掉 clippy 的三处拒绝 + 一处 2018 idioms 警告 ... CI 的门禁是 `cargo clippy --workspace --all-targets -- -D warnings`： 冗余闭包 / 用例表的类型复杂度 / Default 之后逐字段赋值 / elided lifetime 四处都会红。 纯实现侧改动，行为不变（757 + 31 全绿）。	2026-11-08 20:57:23 +08:00
AskaEth	ce463cc9b5	feat(app-iced): Java 页「下载一个 JDK」+ 三个设置键（M197） ... 用户原话：「我们内置了那么多镜像源 甚至用户不能手动选择指定版本下载。」 「自动下载 jdk17 作为基准版本，后续在设置中提供多版本可供用户下载。」 - core：新增 `game::java::catalog`（8/11/17/21/25 五档 × 能承接的发行版 × 「该装哪档」）， 数据全部来自 `JdkVendor::supports` 与 `vendor::order`，不复制第二份真相。 - progress：`SourceFailed` 补一个结构化的 `kind`（在这之前只有中文 `reason`，双语界面 要么放弃语言、要么放弃「哪个源为什么退避」这条用户可见信息）。 - app-iced：`downloads` 模块真下（后台线程 + `ProgressEmitter` + 快照），三态（选择列表 / 下载中 / 失败）都能说出「命中的源 / 退避原因 / 试过哪些源」；成功后重扫并（在 `java.auto_install` 开着且没有默认 JDK 时）把新装的那份设为默认。 - 三个设置键做成可改 UI：`java.installRoot` / `java.vendorPriority` / `java.auto_install`， 各自带「现在生效什么、从哪一层来」（数据目录模式 / 地区默认序），改完回读落盘值。 - `State::satisfied` 换成带方向的 `Fit`：1.12.2 + Java 21 不再被说成「低于要求」。 - i18n：删掉 `SettingsJavaEmptyBody` / `SettingsJavaAddHint` 的 markdown 反引号； `SettingsJavaNeverScannedBody` 改成不与首屏自动扫矛盾的表述。 - 出图三张（选择列表 / 下载中 / 失败）在 DevDocs/artifacts/m197/。 顺带拆文件守 400 行：`golden/tail.rs` 的 M174 段搬到 `golden/tail_ai.rs`， `pages/settings/java/{context,prefs,prefs_store,downloads,download_view}` 各自成模块。	2026-11-08 20:49:56 +08:00
AskaEth	b457f0acc8	feat(m179): 外观分组接真语言并拆成五段文件（只接管子，不补文案） ... M172 审计：`pages/appearance/**` 中文界面下真正本地化 0/27，两个根因各断一刀。 ① 拆文件（纯搬移）：`section.rs` 395 行 → `section/` 五个文件，行数守卫只剩 5 行余量， 不拆就加不了任何东西。 - `section/mod.rs`（壳：section() + card() + 五个行控件 + 取词口 t） - `section/window.rs`（① 整窗 α + ② 圆角，含 notice/说明段） - `section/panel.rs`（③ 面板 α）、`section/bg_image.rs`（④⑤⑥⑦⑧）、 `section/colour_source.rs`（⑨） 取证：每段与原文件做「去空白/去尾逗号」diff，4/4 相同；只有五处机械改写 （`rows = rows.push(…)`→`rows.push(…)`、`t(Key::X)`→`t(Key::X, lang)`、 `super::notice`→`super::super::notice`、一处 `.into()`、rustfmt 换行）。 ② 语言接到渲染层：`settings::Body` 从 `fn(&Ui, States)` 变成 `fn(&Ui, States, Lang)`， `form` 传 `language.effective`，`settings/appearance.rs` 收 `lang` 转给 `pages::appearance::section(ui, state, lang)`，`section::t(key, lang)` 取词。 选「接进唯一那个槽位」而不是再给 `form` 加一条按下标分发的 `else if`：`settings/mod.rs` 贴着 400 行硬顶（M195 还要在此落地），这条路净增 0 行且不可能与分发表漂开。 验收点：`pages/appearance/**` 里已经搜不到 `Lang::En`。 ③ 能变红的守卫：`the_appearance_group_speaks_chinese_when_the_interface_does` —— 走 `settings::view` 真分发渲染一帧，断言取词记录里含汉字、英文那帧不含汉字且同一 key 中英译文不同。取证口是 `appearance::probe`（`#[cfg(test)]` thread_local）：iced 0.14 没有可遍历控件树的公开接口（`Widget::children()` 返回状态 Tree；`operate` 要 Renderer）， 所以取证点退到「字进树之前」的唯一取词口。变异证明：把 `t()` 改回 `Lang::En.catalog()` ⇒ 该用例红（失败信息逐条列出四条英文）；还原 ⇒ 绿。 只接语言管子，不补文案：本组其余英文仍是字面量（行号见 M179 报告）。真实窗口截图、 macOS/Linux 字体差异未验。	2026-11-08 20:42:28 +08:00
AskaEth	e386cfbeee	Merge branch 'feat/m186-addondep-modrinth-dependency-resolu'	2026-11-08 20:24:00 +08:00
AskaEth	ff2f229b80	fix(addon): 复审 r2 —— 下载阶段抽出可测边界并补守门 ... - 阻塞项：下载循环从 `install::run` 抽到新文件 `addon/downloads.rs` （`download_failure()` + `download_stage()`），假下载器就能驱动它；三条用例分别钉 ①失败→Unreachable+叶子成因、②第 2 个失败不中断且已装不回滚、③解析完就取消一份都不下。 实测删掉 `record_failure` 那行会红（failures 0 vs 1），把 `cause` 丢掉也会红； - nit① 补 core 用例：夹具里 `{"version_id":"vid-only","dependency_type":"required"}` ⇒ `plan.unresolved_required == [UnresolvedRequired{parent:"MIXED001",…}]`，同版本的 `project_id` required 仍被跟；删掉收集那段即红（left: [] vs 一条）； - nit② 取消检查加回解析之后（`download_stage` 入口），并用例钉「解析后取消 ⇒ 不下任何文件」； - nit③ `fail()` 文档写明去重按**请求键**而非规范 id 的边界（先 slug 后 project_id 仍会两条）， 不消掉但不再让人误以为全覆盖； - `install.rs` 只留解析 + 收口（275 行），模块表登记 `downloads`。	2026-11-08 20:23:57 +08:00
AskaEth	aa33210bb6	fix(addon): 复审 r1 —— 失败去重、null 载荷、完成态进度、顺序守门、下载失败归并 ... - P2-1 失败分支不再「直接 continue」：`fail()` 记一条失败（`record_failure` 按 `requested_as` 去重）并把请求键写进 `alias`，后续同键走现成的 `fold_parents` 折父边 ⇒ 同一项目只取一次版本、失败只一条、重试名单不重复； - P2-2 `RawDependency.dependency_type` 改 `Option<String>`：`#[serde(default)]` 兜不住 `null`，以前一份 `"dependency_type": null` 就让整份 `/version` 报 Malformed、整个项目装不上； 现在 null/未知一律 `Unknown`（不递归）； - P2-3 完成态用 `finish()` 把 `files_done` 对齐 `files_total`（曾写死 `1`，装 3 个停在 1/3）； 解析前 `files_total` 归 0（未知态），不再假装「已知 1 个文件」； - P2-4 新增 `tests/order.rs`：跨根的层内顺序 + 多根正序/逆序对照，删 `layer.sort_by` 会红； 另加 `required_project_ids` 自己的排序去重契约用例（`tests/regressions.rs`）； - P2-5 下载阶段失败记进同一套两档结构（`Unreachable` + 叶子成因）并继续下一个文件： 已下好的不回滚、失败项进可重试名单、文案保留「已装入 N 个」的上下文；`retry_request` 自动覆盖它们； - nit① 在 `plan.rs` 写清「不兼容」为什么落在 DTO 的 `Unsupported`（不是笔误，是缺档）； nit② 新增 `DependencyPlan::unresolved_required`（只有版本 id 的必备前置不再静默忽略）； nit③ 补「同 mod 另一个版本在目录里仍要下载」的负向用例。	2026-11-08 20:23:56 +08:00
AskaEth	011d525e8d	feat(addon): Modrinth 前置依赖 BFS 解析与两档失败名单 ... - model 纳入 `dependencies`（project_id / version_id / file_name + required / optional / incompatible / embedded / unknown 五值），只跟 required 递归； - 新增 `online::dependency`（请求/计划/跳过的形状）与 `online::resolve` （BFS：规范项目 id 去重防环、每项目只解一次版本、同层按项目键字典序、 默认深度 6 且截断写进计划、父子关系进 `required_by`）； - 失败从类型上分两档：`Incompatible`（所选版本/加载器没有匹配项）与 `Unreachable`（并保留叶子成因 NotFound/NotConnected/…），`retry_request()` 只含失败项，解析永不返回 Err（失败是数据，不连坐）； - 盘上第二道去重：`present_key` 归一化文件名（小写、砍路径、去 `.disabled`）， 命中即跳过下载，但依赖图仍然展开； - presenter 装入路径改成「解析计划 → 逐个下载」，文案把两档分开写并列出 「可只重试这 N 个」；`KNOWN_LOADERS` 补 iris/optifine（光影的加载器）； - 离线夹具覆盖：嵌套两层、环、扇入、深度截断、两档失败、已存在跳过、光影加载器。	2026-11-08 20:23:55 +08:00
AskaEth	94f792e978	Merge branch 'feat/m178-msalogin-fix-microsoft-login-redire'	2026-11-08 20:23:49 +08:00
AskaEth	a40b3a5940	fix(msa): 浏览器登录按钮在生产路径真的置位 browser_first（复审 r1 收口） ... 复审 r1 的 P1-1：「用浏览器登录」这颗按钮在生产二进制里是哑的——`start_browser_login` 用的是 共享的 `MicrosoftAuth::from_env()`（`browser_first=false`），于是 `browser_then_device_login` 里整段预检 / 回退 / 说明编排不执行，按钮静默退化成设备码，任务③（authcode 可选加速路） 实际未交付。 - P1-1：入口改成 `msa_auth(env, MsaEntry::{DeviceCode,Browser})`，浏览器入口走 `.with_browser_first(true)`。守卫钉两段：①调用点（按 `LoginJob` 分桶记下生产入口实际请求的 模式，避开同进程并发用例串台）②模式真的落到 `MicrosoftAuth::browser_first`。变异实测： 把浏览器入口改回 `DeviceCode` ⇒ 该用例红。核心侧另有报文级证据：浏览器优先路必然对 `/authorize` 发一次预检（`unregistered_redirect_falls_back_to_the_device_code` 断言 GET 计数 == 1）。 - P2-1：`listeners_opened` 改成**绑定现场**计数——`CallbackServer::bind_counting` 在 `TcpListener::bind` 前 +1，`login_counting` 把 per-login 的 `AtomicUsize` 传下去； 删掉「进了授权码分支就记 1」的代理指标。复做变异（预检之前偷绑一个监听口）⇒ 3 条 msalogin 用例红，包括两条 `listeners_opened == 0`。两处 stale 文档（引用不存在的 `callback::bind_attempts()`）改成引用 `listeners_opened` / `bind_counting`。 - P2-2：预检加整体 deadline（10s，`PREFLIGHT_TIMEOUT`），超时归 `PreflightUnavailable` 并 回退设备码；新增「接了连接却不出响应」的假服务器单测（200ms deadline 内必须收场）。 （下载引擎的 HTTP 客户端只设了 connect_timeout，这条兜住「header 之后停住」。） - P2-3：client_id 守卫加严到三种拼法（`concat!` / 跨行两段 / `format!` 逐段拼），做法是 「先收字符串字面量再拼」+「连续纯 hex 字面量累计 ≥32 且 ≥2 段」，并跳过注释（否则本模块 文档里的示例会自指假红）；每条一个自检向量，且不误杀 `session.rs` 的 profile UUID。 - P2-4：页面级断言补中文（`Lang::ZhCn` 走 `Page::build`），并把回退说明的文案出口收敛成 视图自己的 `login::browser_note_text`（视图与取样共用，不再测试另写一份映射）。 - P2-5：主按钮文案改成「使用 Microsoft 账户登录」/「Sign in with your Microsoft account」， 下面补一行「浏览器打不开就用这个：它会给一串用户码，在任何设备上输入即可。」。 门禁：`cargo fmt --check`、`cargo clippy --workspace --all-targets -- -D warnings`、 `cargo test --workspace --all-targets`（51 个 test 目标全绿）通过；`client_id.rs` 的判据拆到 `client_id/tests.rs` 守 400 行红线。截图三张（入口 / 设备码 / 回退）已重出。	2026-11-08 20:23:44 +08:00
AskaEth	f82bd395f8	fix(msa): 微软登录默认走设备码，浏览器流降级为可选加速路 ... 官方产物上点「微软登录」必失败：GUI 只接了授权码流（随机端口回环回调），而 Azure 应用 注册当初是为 device-code 建的，重定向 URI 一项都没登记，于是授权端点当场回 `invalid_request: ... 'redirect_uri' is not valid`，浏览器里只剩一张 AAD 原始错误页， 启动器干等 5 分钟超时。设备码流本身是好的（CLI `accounts add msa` 一直能用）。 - core：新增 `preflight`（回环重定向 URI 注册预检）与 `login`（浏览器优先 + 自动回退设备码）。 预检拿「即将使用的 redirect_uri」（端口不参与匹配，微软官方文档 *Localhost exceptions* 原文已引进模块文档）先问一次授权端点；没登记 / 问不出来就地跳过，**一个监听口都不开**。 预检通过才真绑端口走授权码；授权码失败（超时/被拒/绑不上）自动回退设备码并带上结构化 原因码；用户取消（`Canceled`）原样上抛，不偷偷换流。设备码是默认，零监听口。 - presenter：`start_login` = 设备码（默认）；`start_browser_login` = 浏览器优先 + 回退， 回退原因码写进 `DeviceLoginView.browser_note`（原文只进日志）。 - i18n：三条回退文案（含「怎么修：把 http://localhost/auth 加进重定向 URI，端口不参与匹配」）。 - app-iced：登录面板主按钮改成设备码、浏览器降级为次按钮；重登也走设备码；设备码面板与失败 面板都能画回退说明。倒计时文案改由视图模型持有（借用渲染），顺带修掉中文倒计时整行不显示。 - 守卫（都能变红）：①授权端点回 invalid_request 时确实回退设备码且原因是结构化码； ②未登记回环 / 默认设备码路 `listeners_opened == 0`；③回环登记了仍能走授权码（不焊死加速路）； ④用户取消不被偷偷换流；⑤client id 仍只能构建期注入（扫 `auth/microsoft/` 源码无 UUID 字面量）。	2026-11-08 20:23:42 +08:00
tower-worker	26ba1579ab	docs(m196): r2 复审 —— 给「无控制台宿主」那条下边界声明 ... 复审指出 README §15 把两个**近似**形态（父进程句柄不继承 / 父子都无句柄）直接叫「服务形状」， 顶层又写「服务 / 计划任务」，读者会把它当成「真服务也测过」。补一段边界：① ② 都是近似， 真 SCM 服务与计划任务（session 0、no window station）、start /b、ConPTY 全部未测，结论靠 「句柄无效时 std 写返回 Ok」这条机制外推；第三方交叉读数（复审 r2 那组）单独标注来源， 不混进我自己的读数。 同一处过度概括也出现在 console.rs 的 NoConsole 文档（原文「④ / 服务 / 计划任务」）， 按同一口径改成「④ 双击，以及其他没有控制台的宿主」并指向 README §15 的边界段。 只改文档，不动代码。	2026-11-08 20:22:36 +08:00
tower-worker	3fd33a672f	fix(m196): r1 复审 P1（非 Windows dead_code）+ P2 四条 ... P1（阻断）：console.rs 的 `INVALID_HANDLE_VALUE` 只被 `#[cfg(target_os = "windows")]` 的 usable() 用到，而这个模块在 Linux/macOS 上也编译（platform/mod.rs 的 pub mod win32; 没有 cfg）⇒ ubuntu 的 `clippy -- -D warnings` 会把它升级成 dead_code error。 按「精确 cfg」修（不用 dwm.rs 那种文件级 allow(dead_code)：那会永久掩掉本文件在非 Windows 上的所有死项）。自证方式是真实文件翻转 cfg 的 rustc probe：修前 exit 1 （`constant INVALID_HANDLE_VALUE is never used`）、修后 exit 0 零告警；同一条命令写进 了注释，下一个人可以照着跑。 P2-1：自测条数按实现改成 8 条（红 6 / 绿 2），三处（脚本 docstring、release-build.yml 注释、README §12）一致。 P2-2：文件头那组句柄读数换成 release 产物的实测值（out 0x0→0x1F0 / err 0x0→0x1F4）， 并说明数字随实例变化、单测里的 0xE4/0xE8 是示例。 P2-3：README §15 补这段边角语义——但**按实测改写了复审的结论**：两种「既无控制台也不 重定向」的宿主形态（父有句柄不继承 / 父子都无句柄）× 两条命令，child_exit_code 全是 0， 不是 EXIT_INTERNAL；原因是 Rust std 在 Windows 上对取不到的句柄直接返回 Ok（独立探针 实测 SetStdHandle(out)=0x0 / 0x1234 / (HANDLE)-1 三种取值 write/flush 都是 Ok）， 所以 runner.rs 那条「写失败 ⇒ EXIT_INTERNAL」的分支不会被触发。 P2-4：NoParentConsole → NoConsole（这个名字同时覆盖「attach 成功但句柄仍不可用」）， 诊断文案与注释同步。	2026-11-08 20:12:36 +08:00
AskaEth	329c529bea	Merge branch 'feat/m175-javapage-wire-java-settings-to-real'	2026-11-08 20:09:04 +08:00
AskaEth	e5a4b9bbd1	fix(settings): 改口逐实例覆盖的事实陈述，并把第三条守卫换成行为断言 ... 复审 r1 的两条 P2： P2-1（`settings/mod.rs` 的 `form` 文档）：原先写「『逐实例覆盖』既没有数据源也没有 消息落点」——这是错的。逐条核过：真控件在实例详情页的「启动参数」区（M157 `pages/instances/launch_args.rs`，由 `pages/instances/detail.rs` 渲染），落盘走 `app/update/instances.rs` 的 `AppCommand::set_launch_args` → presenter `host/launch_args.rs` 的 `resolved`/`apply`（写回 `config/instances/<id>.json`）， 回落与落位在 core 的 `game/launch_overrides.rs` / `launch/overrides.rs`。真正无人产出 的只有 UI 变体 `Action::AddOverride`。改口后的事实：它是**放错了地方**，不是没接。 P2-2（守卫）：删掉按名字扫源码的两条（`empty_state`/`overrides` 子串、`instance` 子串）—— 前者的假警报会挡住「某组确实需要自己的空态」，后者抓的根本不是它声明的不变量（真正让实例 选择进不来的是 `settings::view` 的签名），且日后一句正当英文注释就能把它弄红。换成： - 判据 ①（保留）守**收尾**：`form()` 里 `stack = stack.push(` 恰好一处、且以 `frame::scroll(ui, stack)` 收尾（整段重写让计数变 0 也红）； - 判据 ②（新增，行为断言）守**生产**：把每组一列的循环抽成 `section_columns()`， 测试真调它数返回值——窄窗 == `GROUPS.len()`，单选各组 == 1，换任何名字都躲不掉。 文档里的「抓不住」段也不再指向静态图（静态图只能证明「现在没有」）。 `form` 的拼装形状没变（循环 + `frame::scroll` 收尾），分组表、分发顺序、正文内容一字未动。	2026-11-08 19:54:38 +08:00
AskaEth	df331f6a60	feat(m175): Java 设置页接真运行时（扫描 / 手动路径 / 默认 JDK / 内存 / JVM 参数） ... 用户实测四条抱怨逐条对应： - 「没有自动检测本机 Java」：首屏自动扫一次盘（托管根 + JAVA_HOME + PATH + 标准安装位置 + 注册表），之后由「立即扫描」手动触发；扫描在后台线程里跑，带 done/total 进度与取消 - 「显示 Temurin 21.0.4 不知道是不是硬编码」：演示行与绊线测试一起删掉，列表来自真读盘 - 「没一个能改」：默认内存（MB，512~65536，范围与 schema 同源）与 JVM 参数可真改、真落盘、读回 - 「不能手动指定 Java 路径 / 不能改默认版本」：手动添加走严格校验（真跑 java -version）， 设为默认写 java.selected_path 并给出「为什么选它」（当前实例的版本门槛 + 每行满足与否） core：java::manual（严格探测 + 厂商识别 + 名单持久化）、java::staged（候选收集 + 带进度与 取消的扫描）、java::proc（带超时且可打断的子进程执行：卡住的 java -version 会被 kill）。 i18n：catalog/settings/java.rs 55 条中英 + 金表按装配顺序插入。 复审 r1（p2-5items）全修： - P2-1 「设为默认」不再清脏：只写 java.selected_path，内存/JVM 草稿一个字节都不动 - P2-2 错误文案全部走 i18n（三档「写不进去」/「路径太长」/「名单写不进去」各自一个 key）， 不再把 Rust 枚举名当人话 - P2-3 手动名单落盘有正面断言（加一条 → 从盘上新读一份 → 在） - P2-4 版本号显示到小版本（17.0.13 / 17.0.9 可区分），解析不出来时给原始版本串 - P2-5 每候选 8 秒超时并 kill、取消打断正在跑的探测、扫描槽挂在 State 上、线程活着期间 不许起第二个（界面显示「正在取消…」） 复审 r2（p2-2items）全修： - P2-1 空态不再指向不存在的「Java 页」，改成真实存在的 `ull java install 21` 命令行入口 - P2-2 `auto_scan_due` 增加 `!report.cancelled`：取消过一次之后本进程不再自动扫， 配置文件再变（存内存 / 改主题）也不会把取消无声撤销；手动「立即扫描」不受影响 - 顺带：proc 的 kill+wait 补「子进程真死了」的回归守卫（标记文件从未出现）、 core 的 Schema 错误改成页面自己的 key（不再把中文 Display 直出给英文界面）、 默认态 chip 用新的 `Chip::badge`（不再挂一条永远收不到的消息）	2026-11-08 19:52:04 +08:00
tower-worker	14f9318e09	fix(m196): GUI 产物 PE Subsystem → WINDOWS_GUI(2)，并用 AttachConsole 保住 CLI 输出 ... 群友 2026-11-08 实测发布构建「运行时会带一个控制台窗口在底下」。根因：产物 PE 头 Subsystem 仍是 CUI(3)。同一个修复 2026-11-01 做过一次（37d3039），但只改了已被 workspace exclude 的 Slint 树（crates/app），从未到达 iced 产物。 - crates/app-iced/src/main.rs：加 #![cfg_attr(windows, windows_subsystem = "windows")]， 并写清为什么放 bin 层而不是 build.rs（PE 子系统是每个 bin 目标的属性）。 - crates/app-iced/src/platform/win32/console.rs（新）：AttachConsole(ATTACH_PARENT_PROCESS) 的落点 + 判据 should_attach（纯函数，可断言）。GUI 子系统进程不继承父控制台，实测 从 cmd 启动时三个 std 句柄全是 0；附着后 GetStdHandle 立刻给出控制台句柄（0x0→0x208）， 所以不改 std 句柄、不碰用户的重定向（ATTACH_PARENT_PROCESS 只会附到已存在的控制台， 永不新建窗口）。 - packaging/check_pe_subsystem.py（新）：读产物 PE 头 Subsystem 字段（GUI 必须 2、 CLI ull 必须 3），非 2 即红；--self-test 注入 5 条合成 PE 回归。 - 接进 release-build.yml（发布侧两槽位）与 ci.yml build job（PR 阶段）。 - guards.yml：unsafe 落点期望集合变成两处（console.rs + transparency.rs），集合相等判据其余不变； 平台层所有「全仓唯一 unsafe 落点」措辞同步改正。	2026-11-08 19:33:56 +08:00
AskaEth	7fdebba961	fix(settings): 设置页尾部不再渲染不属于本页的空态卡 ... 用户 2026-11-08 在 M174 的助手页与 M175 的 Java 页截图里看到同一张卡（四格图标 + 「没有逐实例覆盖」+ 说明被窗口下沿截断）：两张图 1180×1100、卡片位置完全一致、 独立居中在内容下方。 根因是 `pages/settings/mod.rs` 的 `form()` 在分组循环之后**无条件** push 了 `pages/settings/frame.rs` 的 `overrides_empty()`（M84 骨架期的占位，M99 纯搬移时原样 留下，固定 320dp 高）：于是六个分组下面都长出同一张卡，与实例选中态无关。 修法：删掉该空态位及其唯一的三个 i18n key（`SettingsOverrides*`，金表同步删三行）。 设置页永远有内容（总有一组被选中），12b §15 的空态件是给实例/下载/日志页的； 「逐实例覆盖」全仓既无数据源也无消息落点，所以不挪给任何一组，直接不渲染。 守门（`settings/frame.rs` 的 `no_stray_empty_state` 三条，变异实测会红）： 尾部不许再出现额外 push、`form()` 不认任何空态件名、设置页不读实例选择。	2026-11-08 19:13:37 +08:00
AskaEth	30b61e2684	fix(m174): 恢复被截断的 ai/outcome.rs —— dev 不编译 ... fd4a5f8（截图种子按档给各自自洽的 detail）把 outcome.rs 从 197 行截成 1 行， 而 ai/mod.rs 仍然 `pub mod outcome;` + `pub use outcome::ProbeResult;`， dev 上 unlucky-app-iced 直接编不过。第三轮复审判 clean 时漏了这一点（它没真编译）。 先恢复 93d02ab 的完整实现让树能编（cargo check -p unlucky-app-iced --all-targets 退出码 0 已验）。fd4a5f8 想做的「种子按档给自洽 detail」没有生效，作为 follow-up 重做 ——出图自洽是次要，树不许红是底线。	2026-11-08 17:46:47 +08:00
AskaEth	c72bf10690	Merge branch 'feat/m174-agentcfg-ai-provider-base-url-model'	2026-11-08 17:26:14 +08:00
AskaEth	fd4a5f87d9	fix(m174): 截图种子的每档详情各写一句（证据自相矛盾） ... r3 出图时实测：`ULL_AI_STATE=failed-model` 那一张的分类是「端点通了，但没有这个模型」， 而详情行写着 `status 401 Unauthorized / Incorrect API key`——种子把 Auth 的详情复用给了 ModelNotFound/Failed。证据自相矛盾比没有证据更糟。 改：`ProbeResult::screenshot_seed` 按档给各自自洽的 detail（401 invalid_api_key / 404 model_not_found / Http client error / 8 s / 503）。种子仍然只伪造「结论是哪一档」，字段形状 照旧由 `from_outcome` 决定（r1 修的那条不动）。	2026-11-08 17:16:51 +08:00
AskaEth	6f78e0cf7e	fix(m174): 复审 r2 —— 写入口收敛成一个（语言入口同缺陷）+ 只读文件上保存不再谎报成功 ... P2-1（同一类缺陷的第三个入口）：`persist_ui_language` 与 `persist` 共用同一份长生命 store、`save()` 同样整份落盘，但语言入口没先 `reload()` ⇒ 保存 AI 配置后 1 秒内切界面语言， `ai.*` 连密钥一起被 1 秒前的旧快照盖掉，而且函数返回 true。 修法选「收敛成唯一写入口」而不是「再补一次 reload()」： - 新文件 `presenter/src/settings_bridge/write.rs` 提供 `SettingsBridge::write_with(|store| Edit)` ——现读 → 改 → 落盘 → 刷 mtime，`Edit::{Changed,Unchanged,Rejected}` 表达闭包的结果， `WriteOutcome::{NoStorage,Unchanged,Saved,Skipped(reason),Failed}` 表达写的结果（只有 `Saved` 算成功）。两个入口都改成传闭包，**入口自己再也拿不到「不重读的 save」**——下一个写入口不会 再靠「记得」。r1 就是「补一次 reload」的做法，隔一个文件又漏了一次。 第二条（用户可见谎话）：`ai::store::save` 注释写着「落盘后再读一遍才算数」，实际返回的是内存 doc；`SettingStore::save` 还有 `Skipped(ReadOnly/Unreadable/NotDirty)` 一档（`Ok`，不是 `Err`）， 旧代码 `.is_ok()` 会把它当成功 ⇒ 在「配置文件被更新版本启动器写过」的机器上什么都没写，界面报 「已保存」，重启回旧值。现在按 `SaveOutcome` 分支（只有 `Saved` 算成功，`Skipped` 给具名原因）， 并且真的 `SettingStore::load` 一次从磁盘回读。 回归用例（都做了变异验证）： - `settings_bridge_lang::tests::persisting_the_language_keeps_keys_another_writer_just_saved` （去掉 `write_with` 的 `reload()` ⇒ 红，输出即「语言写回把刚保存的密钥盖掉了」+ 被覆盖的文件） - `settings_bridge_lang::tests::persisting_the_language_reports_false_when_the_file_is_read_only` （`persist_ui_language` 恒返回 true ⇒ 红） - `ai::store::tests::read_only_config_is_reported_as_a_failure`（`save()` 恒返回 Ok ⇒ 红） - `ai::store::tests::skip_reasons_are_named`	2026-11-08 17:03:13 +08:00
AskaEth	93d02ab12b	fix(m174): 复审 r1 五项 —— 失败带 target、密钥消息掩码、请求体断言、桥写前重读、结构化分类 ... P2-1（假绿截图）：「测试连接」失败类也带上被请求的 target。`ProbeOutcome` 的五个失败变体 改成 `{ target, detail }`，`ProbeResult::from_outcome` 不再把端点/模型填成空串；view 另加一条 「目标为空就整行不画」的保险。**截图种子改走 `from_outcome`**（新增 `ProbeResult::screenshot_seed`）：种子只伪造「结论是哪一档」，字段形状由产品路径决定——上一版 手填字段，于是「失败态目标为空」只在产品上出现、截图永远看不见。 P2-2（明文进日志）：`Message::EditKey` 的载荷从 `String` 换成 `ai::Secret`（`Debug` 掩码）。 用例 `the_key_message_never_prints_the_key` 同时钉住裸消息与整条 `pages::Message` 漏斗。 P2-3（模型没被证上线）：假服务器按 `Content-Length` 读请求正文，新用例 `the_request_carries_the_configured_model` 断言正文里 `"model":"gpt-test"`。变异实测暴露出 一处真相：`ChatRequest.model` 被 `RigProvider::build_request` 静默忽略，线上模型来自 `ProviderConfig.model`（已另开 finding，并写进 probe 的注释）。 P2-4（数据丢失）：`SettingsBridge::persist` 写前 `store.reload()`。`SettingStore::save` 是整份 文档落盘，不重读就会拿 ≤1 秒前的旧快照盖掉刚写的 `ai.*`。两条回归用例： `presenter::settings_bridge::persist_keeps_keys_another_writer_just_saved` 与 app-iced 侧的 `ai::store::appearance_write_back_keeps_the_ai_keys`（保存 AI → 改主题 → 值还在）。 P2-5（子串匹配）：删掉 `classify()`。分类改由 `brain::rig::map_error` 从 rig 0.45 的结构化 报告（`ErrorReport` 的 `kind` / `http_status` / `code`）翻译成新的 `ProviderFailure` （`brain/provider/failure.rs`），`ProviderError` 因此带上 `kind`。`closed_port_is_unreachable` 不再依赖错误文本：连接被拒恒为 `ErrorKind::Http` ⇒ unreachable。防退化用例 `factory_error_carries_the_structured_classification` 断言「纯文本 401 不许被猜成 auth」。 顺带（400 行硬线）：`provider.rs` / `rig.rs` 的用例各自拆到 `provider/tests.rs` / `rig/tests.rs`（纯搬移）。	2026-11-08 16:20:34 +08:00
AskaEth	9cb605f316	feat(m174): 助手（AI）提供商配置真接线 + 「测试连接」 ... 设置页新增第 6 组「助手」：提供商四态 / 端点 base_url / 模型名 / API 密钥（默认掩码， 点「显示」才明文）+ 保存 + 测试连接，四类失败（鉴权 / 模型不存在 / 不可达 / 超时）各自 一句文案 + 目标与耗时。 取舍三条： 1. 读写走 `core::setting` 的 schema API（`SettingStore::load` 现读 → `set` → `save`）， 不经 `AppCommand::SetSetting`——那条指令是可序列化 DTO，`ai.api_key` 走它等于让明文进 事件流/日志。与 `SettingsBridge::persist` 写外观是同一条做法。 2. 「测试连接」不另写一套 HTTP：`unlucky_cli::commands::agent::probe` 现读设置文件、 交给 `RigProvider`（真 provider）发一次最小补全，带 8 秒时限；分类只看错误文本 （rig 只给 Display），四类各有一条真 TCP 假服务器用例钉住。 3. `ProviderKind` 补 `from_setting` / `setting_value`：serde 的 `rename_all = snake_case` 产出 `open_ai_compatible`，与 schema 的 `openai_compatible` 不是同一个词——这正是 M174 之前「agent 侧一次都没读过设置」的根因。 守卫（都做变异验证，见 mission 报告）：密钥不出 `Debug`/`detail`/DTO；未配置时工厂构造 计数为 0；改完 base_url 后探测打到新地址；空/非法值被 schema 拦下且文件不动。 i18n：49 条中英各一（金表按 `Key::ALL` 位置插入）；presenter 的 ai_group 补上 schema 允许 的 `disabled` 选项与一行「已配置 N 字符」的只读状态（仍然不显示值）。	2026-11-08 15:57:25 +08:00
AskaEth	82f3bbbff6	Merge branch 'feat/m173-scrollfit-settings-scrollbar-beside'	2026-11-08 15:28:14 +08:00
AskaEth	28762ec268	fix(m182): 判据断言一律显式传 HostOs，ubuntu 门禁在容器里前后对照为绿（复审 P1-1 / P2-1） ... 复审 P1-1 实测：`corner/tests.rs` 里三条用例走宿主绑定的 `plan_corner()` 却断言 Windows 的结果——本机（Windows）绿，合进 main 后 `ubuntu-latest` 的 test job 会当场红。已修： - 三条改为 `on_windows(...)` → `plan_corner_for(policy, HostOs::Windows, …)`： `the_win11_boundary_is_inclusive`、`the_log_line_carries_every_field`、 `the_log_line_shape_is_pinned_with_the_measured_readings`； 去重那条（`the_same_policy_is_dispatched_only_once`）也一并显式传 Windows。 - 宿主绑定的 `plan_corner()` 现在只剩**产品路径**（`app/update/appearance.rs:51`）与 **一条**用例 `the_production_entry_forwards_to_the_pure_judgement`——后者两边都用同一个 `HostOs::current()`，所以任何宿主都成立，它证明的是「入口确实转发」，不是某个平台的结果。 - m116 探针（`cfg(windows)` + `#[ignore]`）也改成显式 `HostOs::Windows`：那是真窗口实验， 不该让「这台机器是 Windows」成为隐式前提。产物那一行逐字不变。 复审 P2-1：`unknown-os` 此前没有任何断言。新增表测试 `every_exclusion_code_is_a_stable_non_empty_string`，把七个原因码逐个钉住（含 `unknown-os`）， 并断言非空、无空白、两两不重复、总数 7。另在 `the_log_line_carries_every_field` 里补 `host=windows` + `os=unknown` + `excluded_reason=unknown-os` 同现。 证据（`packaging/linux-check-docker.sh`，容器内 ubuntu 真实复跑，非推理）： - 修前（把 tests.rs 回退到 0451b3f）：`test -p unlucky-app-iced --lib` → **3 failed** （正好是复审点名的三条），exit=1； - 修后同一命令：**685 passed / 0 failed**，exit=0； - 最终树跑完整两条 CI 门禁：`cargo clippy --workspace --all-targets -- -D warnings` exit=0、 `cargo test --workspace --all-targets --no-fail-fast` exit=0（53 个测试二进制，合计 passed=2672 / failed=0）。 本机（Windows）同树：clippy exit=0、`test -p unlucky-app-iced --lib` 686 passed、fmt exit=0。 `decorations` 取值未动（分支 vs 基点仅新增注释行）；非 Windows 的 `os=` 仍为 `n/a`， Windows 上「真的读不到版本」仍叫 `os=unknown`，但同一行有 `host=windows` + `excluded_reason=unknown-os` 自解释。	2026-11-08 15:18:23 +08:00
AskaEth	037c68d0e6	fix(m173): 设置页滚动条并排在内容右侧（右侧恒留 10dp 槽） ... 根因（读 iced 0.14 源码，不是猜）：`scrollable` 的竖直滚动条是浮层—— `iced_widget-0.14.2/src/scrollable.rs:1970-1980` 把轨道定位在 `bounds.right - (width.max(scroller_width) + 2*margin)`，而同文件 `:437` 给内容的横向 约束是整个视口宽（`Scrollbar::spacing` 默认 None ⇒ 右内边距恒 0）。本仓 6 轨 + 2×2 内缩 = 10dp，于是这 10dp 整条压在表单列内容上（1180 与 880 宽窗口都一样）。 改法：`components::scroll::vertical()` 在内容右侧恒留一条 `轨宽 + 2×margin` 的槽，轨道画在 槽里；`pages/settings/frame.rs::scroll` 改成一行转发。不采用 iced 的 `Scrollbar::spacing`， 因为它只在滑块可见时才预留（`scrollable.rs:478-500`），长/短页面切换内容会横跳 10dp。 数值（1180×760、100% DPI、tiny-skia、实测像素）： - 卡片右缘 799 → 789（内容可用宽 424 → 414 = 424 − 10）； - 滑块仍是 792..797（没有移动），与内容之间隔 2px 页面底色（= SCROLLBAR_MARGIN）； - 长页面（外观组）与短页面（Java 组，无滑块）左边界 376、宽 414 **逐项相同**； - 150% 缩放下 621px = 414×1.5、滑块 9px = 6×1.5、槽 15px = 10×1.5，同比例不重叠。 守卫（两条都是数值，不看图）：`components/scroll.rs` 与 `pages/settings/tests/scroll_fit.rs` 用 `Renderer = ()` 真跑 iced 的 `layout()`，断言「内容宽 == 容器宽 − 槽宽」且长/短两态一致； 把 `beside` 的 padding 改回 `Padding::ZERO`，4 条断言立刻红（424 vs 414）。	2026-11-08 15:11:54 +08:00
AskaEth	0451b3f972	fix(m182): 非 Windows 圆角判据回答「由谁负责」，并给 macOS 直角三条源码级证据 ... 用户第三轮 Mac 验收看到四角直角 + `source=square os=unknown`。原来非 Windows 一律 落到 `UnknownOs`，把「Windows 版本读不出来」与「这台根本不是 Windows」糊成同一格。 - `platform/host.rs`：新增 `HostOs`——平台族是一个**值**而不是散落的 `cfg`。 这样三行真值表能在本机（只有 Windows）一次验完，`cfg` 只留在真要 FFI 的地方。 - `plan_corner` 拆成 `plan_corner_for(policy, host, os, backend)` + 保持原签名的薄包装 （`app/update/appearance.rs` 在 scope 外，调用点一字未改）。 - `CornerSource` 加第三档 `Compositor`（跟随合成器，我们既不下发也不自绘）； `CornerExclusion` 加 `borderless`（macOS）、`client-side`（Linux）、`unsupported`。 - 日志加 `host=`，非 Windows 的 `os=` 由 `unknown` 改 `n/a`（那栏是 Windows 版本， 在 macOS/Linux 上不是「没读到」而是「跟本机无关」）。 - `platform/macos/mod.rs`：macOS 为什么是直角的**三环证据**（我们的 `decorations: false` → winit `Borderless`（无 `Titled`）→ 窗口服务器只裁 titled 窗；winit macOS 后端 `cornerRadius` 命中 0），以及「迁移原生标题栏」的未实现配方与阻塞点（iced 0.14 未转发 winit 的 `titlebar_buttons_hidden`，缩放键按不掉）。 - `platform/linux/mod.rs`：xdg-shell 无圆角概念、wl_surface 区域只能是矩形、XShape 只能 切硬边 ⇒ CSD 窗没人替我们裁，D46 排除自绘 ⇒ 直角。没把 DWM 判据搬过去（单测钉着 「非 Windows 不许出现 dwm」）。 - `design/shape.rs`：删掉「macOS 走 `layer.cornerRadius`」这句过期描述（D46 不许自绘裁切）。 - `dwm.rs` 的内联测试挪到 `dwm/tests.rs`（原文件 398 行，加第三档映射会顶破 400 行红线）。 验证：cargo fmt --check / clippy -D warnings / `cargo test -p unlucky-app-iced --lib` 684 passed；三次定向变异各自变红（macOS 行改回 Square/UnknownOs → 4 红；非 Windows `os=` 改回 unknown → 1 红；Linux 原因码复制成 borderless → 4 红）。 Windows 侧无语义改动；`cargo test --lib m116 -- --ignored --nocapture` 复跑读回仍是 `pref=2 readback=? read_hr=0x80070057`（写入被接受、回读不可用），**不作为「圆角已生效」的证据**。	2026-11-08 14:50:15 +08:00
AskaEth	da5b837c7c	Merge branch 'feat/m168-fontfetch-cjk-font-cdn-download-wir'	2026-11-08 14:38:33 +08:00
AskaEth	460da9330d	fix(m168): 复审 r3 四项 —— 说准 panic 档、给两条修复补守卫、时限算术补洞 ... 复审 r3（p2-4items / fix-then-merge）四项 + 顺手五条： 1. **P2-1 `catch_unwind` 在发布档是死代码，三处文档说了不成立的话**： `Cargo.toml` 的 `[profile.release]` 是 `panic = "abort"`（只有 `fast` 是 `unwind`），发布走 `--release`。分两半写清楚：①**闸前移仍安全**——release 档 panic 是进程退出，不存在永久停在 `Downloading`；`dev`/`test`/`fast` 档 `catch_unwind` 真会写 `Failed`；②但「下载失败不崩」在 panic 这一支上对发布版**是反的**：注册/`load_font` panic ⇒ 启动器整体 abort，不是降级。 `install.rs::plan_with_offline` 的文档（新增两档对照表）、`worker.rs` 模块文档与 `run` 注释全部 按这个说法重写，不再用 `catch_unwind` 给「不崩」背书。 2. **P2-2 「启动不发起下载」这条修复没有守卫**：拆出纯函数 `fonts::resolve_with_faces(setting, faces)`（`resolve_with` 只是 `system_faces()` 的包装）， 新增 `fonts::tests::resolving_fonts_never_starts_a_download`：给一张只有拉丁族的脸表 （一定判 `NeedsDownload`），断言调用后 `install::status()` **不是** `Downloading`。 变异（实跑）：把 `install::after_probe(cjk_report.strategy)` 加回 `resolve_with_faces` ⇒ `求值字体**不许**发起下载（状态从 Unknown 变成了 Downloading { bytes: 17772300 }）`，红。 3. **P2-3 时限算术有洞 + `is_last` 没守卫**：改 `ATTEMPT_DEADLINE=60 s` / `TOTAL_DEADLINE=420 s` （原来 120/360 时，第一个候选吃掉 120 s 后最后一个只剩 240 s ⇒ 门槛 72.3 KiB/s，r1 实测 67 KiB/s 需要 259 s，仍然必失败）。文档按新数值重算成一张表：第一个候选瞬间失败 ⇒ 420 s ⇒ 42.3 KiB/s；爬满 60 s 被切 ⇒ 360 s ⇒ 49.4 KiB/s，两者都低于实测最慢的 67 KiB/s。 守卫：把同解的旧用例换成 **单候选 + attempt 300 ms / total 5 s**——有 `is_last` 时跑到总时限 （≈5 s），没有时 300 ms 就切，两种实现可分辨。变异（实跑）：删掉 `is_last` ⇒ `the_last_candidate_gets_the_whole_remaining_budget` 红在 `最后一个候选该拿整个剩余预算（≈5 s）…452.6035ms`。 4. **P2-4(b)(c)**：①`install::tests` 里三处判据用例改用 `plan_with_offline(..., false)`，把进程级 `OFFLINE` 从判据里摘出去（否则同进程里 `headless(screenshot_options())` 会把它置 true 且从不 还原 ⇒ 结果依赖执行顺序）；②`fonts.rs` 注释改成真实机制——出图 harness 不经 `App::with_presenter`、压根没有 `set_offline`，它零流量靠的是「`resolve_with` 不触发」。 顺手：①`sha256_mismatch…` 的 doc 改成「两层校验互备，本用例抓的是两层同时拆」（原来说 「拆任意一层就红」是假的）；②`font.rs` 文档「把 90 s 压成 300 ms」→ 60 s/420 s；③`install.rs` 与 `catalog/font_install.rs` 的「≈17 MB」→ 16.9；④`worker::start` 的裸 `thread::spawn` 换成 `Builder::spawn`，起不来就落 `Failed`（发布档 panic = abort，不能让它 panic）；线程体抽成 `run()`。 验证（`CARGO_TARGET_DIR=C:/Temp/ull-target/wt-168`，取退出码、不截断）： - `cargo test -p unlucky-app-iced --lib` → **688 passed / 0 failed / 2 ignored / exit 0** - `cargo test -p unlucky-core --all-targets` → **16 个 target / 1189 passed / 0 failed / exit 0** - `cargo test -p unlucky-i18n` → 31 passed / 0 failed / exit 0 - `cargo clippy -p unlucky-i18n -p unlucky-core -p unlucky-app-iced --all-targets -- -D warnings` → exit 0 - `cargo fmt --all -- --check` 干净；全仓无文件 >400；本轮改动文件最大 378（`app-iced/src/fonts.rs`）	2026-11-08 14:38:25 +08:00
AskaEth	b9009c0e61	fix(m168): 复审 r2 三项 —— 夹具不再空转、启动不再替英文用户下载、时限不再判慢线下不完 ... 复审 r2（p2-3 / fix-then-merge）三项： 1. **P2-1 爬行服务端是空转的**（`font/tests/support.rs`，从 `tests.rs` 拆出守 400 行）： `seen.windows(4).any(|w| w == b"\n\n")` 拿 4 字节窗口比 2 字节切片 ⇒ `PartialEq` 先比长度 ⇒ 恒 false ⇒ 请求头永远读不完、一个字节不发，用例证明的其实只是「连接挂着被掐断」。上一版 这里是 Python 生成时把 `\r\n` 落成了真实换行字节。现在两处都是转义写法 （`b"\r\n\r\n"` + 完整 CRLF 响应头），并且**把「夹具真的在说话」变成断言**： `serve_trickle()` 返回 `TrickleProof { header, dripped }`，用例断言「真的发过头」「真的挤过 字节」——否则夹具再坏一次也会绿。拆成两条用例：`a_trickling_candidate_is_cut_by_the_attempt_deadline` （[爬行, 正常]，300 ms 切断第一个后第二个成功，0.38 s）与 `the_total_deadline_cuts_a_single_crawling_candidate`（单候选 + 400 ms 总预算）。 变异证明：把服务端改成「一个字节都不发」⇒ 两条用例红在「爬行服务端必须真的发出响应头」。 2. **P2-2 启动替英文用户下 17 MiB（真行为 bug）**： - `fonts::resolve_with` **不再触发下载**（启动那一拍只报告判据）。唯一的触发点收在 `fonts::cjk_for`（`ui/lang.rs::log_cjk`），那一拍的 `setting` 与 `LangChoice` 同源 （ULL_LANG > 配置 > 系统 locale）= 「界面实际用哪种语言」。 - `plan` 把 `is_downloading()` / `Ready` 的闸提到**所有策略之前**：上一版只在 `NeedsDownload` 分支里，"下载中 + Unprobeable" 会把状态改回「无法探测」而线程还在飞，下完又翻回「已就绪」。 当时那条理由（「否则界面停在正在下载」）只对僵死成立 ⇒ worker 现在用 `catch_unwind` 兜底「任何 panic 都写终态」，闸才敢前移。 - 出图通道：新增 `install::set_offline(true)`（`App::with_presenter` 在 `options.screenshot.is_some()` 时调），`plan_with_offline` 在 offline 下永不 `Start`。 于是 `pages/harness/app.rs` 与 `--screenshot` 都不会在 zh-locale 无字体机器上真下 17 MiB。 - 被钉住的旧判据（`Unprobeable + Downloading ⇒ Apply`）改成 `Skip` 并写明旧行为为什么是错的； 新增 `every_strategy_skips_while_a_download_is_in_flight`（四策略打表）与 `the_screenshot_channel_never_starts_a_download`。 3. **P2-3 90 s 单次上限把「慢但能下完」变永久失败**：改 `ATTEMPT_DEADLINE=120 s` / `TOTAL_DEADLINE=360 s`，并且**最后一个候选拿整个剩余总预算**（前 n-1 个仍 `min(单次, 剩余)`）。 算账写在常量文档里：17 772 300 B / 360 s ≈ 49 KB/s，比 r1 实测最慢那条 IPv6（67~77 KB/s） 还低一档 ⇒ 慢而能下完的线路仍有一次成功机会；健康线路（1.1~16.6 s）在第一/第二个候选就结束。 代价（最坏 6 分钟）也是刻意取舍，写在同一处。 顺手：`i18n::CjkFont::source` 的「尚未钉死」改成指向 `Source::Pinned`；`clock.rs` 与 `general_section.rs` 注释里的 17.0 MB → 16.9 MB。 验证（`CARGO_TARGET_DIR=C:/Temp/ull-target/wt-168`，全量重编；取退出码，不截断）： - `cargo test -p unlucky-core --all-targets` → **16 个 target / 1189 passed / 0 failed / exit 0** （lib 625 + setting 115 + 其余 14 个） - `cargo test -p unlucky-i18n` → 31 passed / 0 failed / exit 0 - `cargo test -p unlucky-app-iced`（含 `no_hardcoded_tokens` integration）→ **693 passed / 0 failed / exit 0** - `cargo clippy -p unlucky-i18n -p unlucky-core -p unlucky-app-iced --all-targets -- -D warnings` → exit 0 - `cargo fmt --all -- --check` 干净；全仓受检文件 ≤400（本分支最大 361）	2026-11-08 14:38:25 +08:00
AskaEth	875b792206	fix(m168): 复审 r1 五项 —— 修红的 integration target、独立失败域、整体时限 ... 复审 r1（p1-1/fix-then-merge）五项全改： 1. **p1-1 CI 会红的 4 条 integration test**（`crates/core/tests/setting/`，我上一轮只跑了 `--lib`， scope 漏掉了覆盖 schema 版本号的目录式 target）： - `java_install_keys` / `isolation_keys` / `appearance_keys`：版本断言 1.6.0 → 1.7.0（M168 的 `ui.font_cdn`），并写明「每加一批键推一次 minor 是纪律」。 - `update_keys::a_read_only_launcher_config_never_retires_the_legacy_file`：夹具从**写死 1.7.0** 改成 `launcher_version().minor + 1` 经 `SchemaRef::url()` 生成。写死数字的版本一推 这条守卫就变成「同版本」⇒ 文件可写 ⇒ 迁移真的执行 ⇒ 旧文件被退役，而断言还绿着（用户数据 守卫静默失效）。相对推导不会过期。 2. **p2-1 备用镜像不备用**：`cdn` 与 `fastly` 同属 Fastly（都 CNAME 到 jsdelivr.map.fastly.net）， 换掉。现在首选 `gcore.jsdelivr.net`（Cloudflare，独立失败域），二选 `cdn.jsdelivr.net` （Fastly）。注释里放了实测表（本机 + 复审机两份数据、字节数、sha256、IPv6 慢路径）， 并写清排序依据（Fastly 侧 IPv6 实测 67 KB/s ⇒ 丢掉 4 分钟；Cloudflare 侧两次都完整下完）。 3. **p2-2 整体时限**：`core::download::font` 新增 `ATTEMPT_DEADLINE = 90 s` / `TOTAL_DEADLINE = 180 s`，落在本模块自己的候选循环里（不动引擎全体语义）：每次尝试 `min(单次上限, 剩余总预算)`，超时归 `Network` 档。新增守卫 `a_trickling_connection_is_cut_by_the_deadline`（回环服务端每 100 ms 挤 1 字节、预算 300 ms）。 顺带修掉一个真 bug：`tokio::time::timeout` 在运行时外构造会 panic（5 条既有用例当场抓到）， 现在整段包进 `block_on(async { … })`。UI 文案改成「网络不通或太慢（超时）」，不校验失败混。 4. **p2-3 说 `Source::PendingPin` 的两处**：`fonts/cjk.rs` 的模块文档已改；`ui/lang.rs::log_cjk` 那句「D28 的下载通道还是 PendingPin」（在下载已发起之后打印，等于当面否定本功能）改成 「已按 D28 发起下载，见 [font] cjk-download … 与设置页那一行」。全仓再扫，只剩注释里的历史说明。 5. **p2-4 假守卫**：判据抽成纯函数 `install::plan(strategy, current) -> Step`（`Skip` / `Apply` / `Start`），`after_probe` 只执行。旧的空转用例换成打真判据的打表用例；变异证明：删掉 `Skip` 那一臂 ⇒ `a_started_or_finished_install_is_not_restarted` 红（已实跑）。 次要项也一并处理：`from_cache` 改成**本次是否真的命中缓存**（`CdnFetcher::was_cached()`， `has_cached()` 降级为诊断字段 `cache_present=`）；`FontSpec` 的 URL 口径收紧为「非回环必须 https」（`is_acceptable_url` + 守卫）；`ui.font_cdn` 写进状态行 hint；文档里的 17.0 MB → 16.9 MB。 `download/font.rs` 拆出 `font/spec.rs` 守 400 行。 验证（这台机器上单个 800 MB 测试 exe 链接要 10 分钟，链接期间文件被 Defender 扫描，故耗时很长）： - `cargo test -p unlucky-core --all-targets` → **1188 passed / 0 failed**（16 个 target，含 `setting` 那个 115 条、上一轮红 4 条的 integration target） - `cargo test -p unlucky-i18n` → 31 passed / 0 failed - `cargo test -p unlucky-app-iced --lib` → 685 passed / 0 failed - `cargo clippy -p unlucky-i18n -p unlucky-core -p unlucky-app-iced --all-targets -- -D warnings` → 干净 - `cargo fmt --all -- --check` → 干净；全仓受检文件行数最大 388（<400）	2026-11-08 14:38:23 +08:00
AskaEth	449ded2cb7	feat(m168): 中文字体 CDN 下载真接线（D28 后半） ... M167 调研的结论是「中文字体 CDN 下载至今未实装」：`i18n::font` 只有 `Fetcher` trait 与 假实现，`needs-download` 分支什么也不做。这条把它接成一条真链路。 判据 → 下载 → 注册（一条链，四个 crate 各管一段）： * `unlucky_i18n::font`（零依赖）：`Source::Pinned { urls, sha256, bytes }` 把「下什么」 钉死——google/fonts 的 `NotoSansSC[wght].ttf` 钉到 commit `2894aab…`（不是 `@main`）， 17 772 300 B / sha256 `a3041811…`。可变字体一份覆盖 wght 100–900，省掉三份静态子集的 25 MiB。 `FetchError` 补第三档 `Disk`（网络 / 校验 / 磁盘，UI 按类别选词）。 * `unlucky_core::download::font`（新）：缓存命中 → 共享引擎 `download_bytes` → 复验（sha256 + sfnt 魔数 + 32 MiB 上限）→ 原子落盘。**复验在写盘之前**，所以「哈希不符」时盘上什么都没有； 缓存按 `<sha256 前 16 位>` 命名，pin 一换自动换名。 * `unlucky_app_iced::fonts::{cdn,install}`（新）：`CdnFetcher` 把 pin 接进 core（`ui.font_cdn` 可覆盖 URL，哈希不换）；`install` 是状态机 + 后台线程，只有 `NeedsDownload` 才起线程 （英文 / 系统已有 / 探测不出一律零网络）。注册走 `iced_graphics::text::FontSystem::load_font`， 族名从字体库读回来核对。失败只降级（继续用系统字体），不阻塞、不崩。 * 接入两条路径：`fonts::resolve_with`（启动）与 `fonts::cjk_for`（设置页切语言）都调 `install::after_probe`；设置页 General 组多一行状态（下载中 / 完成 / 失败 / 无需下载 + 三类失败 原因），文案进 catalog 金表（链尾追加，既有顺序不动）；`App::advance` 每秒比对状态快照后重建 视图模型，所以那一行会自己刷新。 配置：新增 `ui.font_cdn`（`keys/font.rs`，schema 1.7.0），空 = 内置 jsDelivr 镜像（含备用边缘）。 守卫（三条都能变红，变异证明见报告）：core 侧 8 条（缓存不联网 / 哈希不符拒落盘 / HTML 不当字体 / 坏缓存自愈 / 上限 / pin 校验），app 侧 6 条（三种闲置策略零调用、失败不注册、类别不串、幂等、 截图钉子、单行日志），页面侧 1 条（四态 × 两语言无缺译、不写假百分比）。 测试：`cargo test -p unlucky-i18n --lib` 31 绿；`-p unlucky-core --lib` 622 绿； `-p unlucky-app-iced --lib` 684 绿；`cargo fmt --check` 干净。截图三张见报告。	2026-11-08 14:38:23 +08:00
AskaEth	2a004a5754	ci(m171): 两个 windows 作业显式豁免跨卷守卫 ... M171 合并后，跨卷守卫在只有一块系统卷的 runner 上会判红（这是设计： 跳过必须是响的）。runner 是否有第二块可写卷没有核实手段，因此不赌， 显式给 ULL_XDEV_TEST_WAIVE=1；该豁免是惰性的，探到第二块卷时不参与 判断。补丁位置属 M171 scope 之外，由 tower 在合并窗口内一并落地。	2026-11-08 13:52:35 +08:00
AskaEth	9700de1bd4	Merge branch 'feat/m171-xdevreplace-fix-cross-volume-update'	2026-11-08 13:51:03 +08:00
AskaEth	ef77c67d3c	fix(m171): r2 —— 跨卷守卫不许静默跳过，崩溃现场不删唯一旧副本 ... 按首轮复审 p2-1items 的三条就地修。 P2-1（唯一阻塞项）跨卷守卫在只有一块卷的机器上静默变 ok：探不到第二块卷时 是 `eprintln! + return`，libtest 默认捕获 stdout/stderr，于是默认输出只有 `... ok`，跳过的记录只有 `--nocapture` 才看得见（复审 M3 变异实测）。 按复审给的方案 (b) 把裁决收成一条常跑用例（本仓口径同 `options_shot/feed.rs::not_fed`：跳过必须是响的）： 探到第二块卷 → 绿（真跨卷用例真跑） 探不到 + ULL_XDEV_TEST_WAIVE=1 → 绿（显式、记录在案的降级，打印一行） 探不到 + 没豁免 → 红（默认判红，失败正文给出三条出路） 另有 ULL_XDEV_TEST_REQUIRE=1：声明「必须有」，与豁免同给时以它为准（不许自相矛盾） 裁决是纯函数 `xdev_guard(found, waiver, require)`：逐条用例走同一个入口 （`cross_volume_scene`），没人能靠 `return` 静静跳过；core 与 CLI e2e 两处政策一致 （源头在 `install_xdev_cases`，CLI 侧 `support::cross_volume_waived` 照抄并注明）。 CI 选择：**windows 作业显式声明豁免**（不挂 VHD）。理由：VHD 要多一步 diskpart、 要管盘符、易碎；豁免是一行 env、写在 ci.yml 里可见，且只在探测失败时被咨询—— 将来 runner 真有第二块盘，真跨卷用例照样真跑。ubuntu 侧不豁免：`/tmp` 与 `/dev/shm` 是不同设备（本机 docker debian:bookworm-slim 实测设备号 119 / 158）， 真跨卷守卫在 Linux 上应当是真跑的。ci.yml 不在本 mission 的改动范围，已用 TowerFinding 登记那一行补丁。 P3-1 `update_e2e_test.rs` 里 `install::prune_stale_backups` → `prune_stale_artifacts`。 P3-2 `prune_stale_artifacts(None, dest)` 会删掉崩溃现场唯一幸存的旧 exe：上一次装到 「dest → .ullold-*」之后被杀时，dest 空着、旧字节只剩备份那一份；下次成功安装时 `symlink_metadata(dest)` 失败 ⇒ keep=None ⇒ 连它一起删，用户失去手工恢复的可能 （修前不会删）。改成 keep=None 时**只清 `.ullnew-*`、一个 `.ullold-*` 都不动**， 模块文档补上这条例外与其来由。 验证（本机，CARGO_TARGET_DIR=C:/Temp/ull-target/wt-171）： * `cargo test -p unlucky-core --lib update::tests` → 90 passed / 0 failed * `cargo test -p unlucky-core` → 623 passed（+ 各集成目标全绿），exit 0 * `cargo clippy -p unlucky-core --all-targets` / `-p unlucky-cli --all-targets --features update-test-source` → exit 0 * `cargo test -p unlucky-cli --features update-test-source --test update_e2e_test --test update_e2e_tamper_test` → 3 + 4 passed，含 `installs_across_volumes_from_the_cli` * fmt clean 变异实测（都验完再还原）： M3 让 probe 恒 None ⇒ 默认 `cargo test` 输出 2 failed（无须 --nocapture）， 正文「没有第二块可写卷，也没有显式豁免：跨卷守卫在这台机器上是空跑。」 M3 + WAIVE=1 ⇒ 3 passed；M3 + REQUIRE=1 ⇒ 2 failed 去掉 keep.is_some() 那一半 ⇒ `a_crashed_install_keeps_the_only_surviving_old_copy` 红	2026-11-08 13:34:29 +08:00
AskaEth	36ff193609	fix(m171): 跨卷替换改成「目标同目录中转名 + 同卷原子改名」 ... 已发布版本上的真 bug：暂存包在 <数据根>/cache/update/staging，目标 exe 在安装目录， 两者不同卷（便携版放 U 盘 / 数据根在 D 盘而程序在 C 盘 / 部分 macOS 配置）时 `rename(staged → dest)` 直接报 EXDEV / ERROR_NOT_SAME_DEVICE（io::ErrorKind::CrossesDevices）， 更新必然失败，而 is_transient 不含 CrossesDevices，也没有任何降级路径。 复现（本机真跨卷：C:/Temp NVMe ↔ D:/Temp 机械盘，原实现）： InstallFailure { error: UpdateError { kind: Io, message: "系统无法将文件移到不同的磁盘驱动器。 (os error 17)", path: Some("D:/Temp\ull-xdev-…\app\ull.exe") }, rolled_back: true } 失败点就是 `rename(暂存包 → dest)`；唯一调用方是 core::update::job::Job::apply（CLI/GUI 共用）。 修法（不把原子替换退化成可能留半截的复制）： 0. 新包 → <目标同目录>/.<文件名>.ullnew-<pid>-<seq> 同卷 rename；跨卷才 copy 到该中转名， 并核对写出字节数（少了直接判失败） 1. dest → <同目录 .ullold-…> 旧版本先安全落地 2. rename(中转名 → dest) 同卷，原子 3a. 成功 → InstallReceipt；3b. 失败 → 回滚 + 清中转名 目标路径上的新字节只来自一次原子命名，任何时刻都不是半截文件；同卷路径一个字节都不多搬 （注入用例断言 copies == 0，rename 恰好 3 次）。 备份清理策略一并定死：成功后只留最近一份 .ullold-*（更早的与残留的 .ullnew-* 删掉， 别的程序名的备份不碰）。旧行为是每次 apply 留一份、全仓无人调 remove_backup ⇒ 无限堆积。 顺手把文件动作抽成 replace_io::ReplaceFs（真实现 = std::fs），让「跨卷被拒」「复制到一半 失败」「改名失败」成为确定性输入；判据与顺序仍在 install 里，注入改不了。 守卫（都做过变异实测，均能变红）： * install_xdev_cases：真跨卷安装成功且目标字节完整（去掉降级 → 红，报 os error 17） * install_io_cases：跨卷降级只复制一次 / 半截复制后目标仍是旧字节且无 .ullnew- 残留 / 短复制被字节数判据拒掉 / 最后一步改名失败回滚并清中转名 / 同卷 copies == 0 * cli update_e2e_test::installs_across_volumes_from_the_cli：数据根一卷、安装目录另一卷， 整环从 CLI 入口跑通（去掉降级 → 红，输出 update_apply_failed + os error 17）	2026-11-08 13:06:57 +08:00