548 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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
tower-worker	1764301cdf	merge: 解 origin/dev 三处冲突（M182 / M184+M190 / README §14），两边都留 ... 冲突（都来自别人后来改同一批文件）： - crates/app-iced/src/platform/mod.rs：保留 M182 的 HostOs / host·linux·macos 分册表 / plan_corner_for，同时保留 M196 的 `[`win32::console`]` 落点说明；把 M182 措辞里已经不 成立的「唯一 unsafe 落点 / 只此一处」改成「两处落点（transparency + console）」 （unsafe-scope 门禁自 M196 起期望集合就是两处，不改这句文档就是错的）。 注意：`pub mod console;` 属于 `platform/win32/mod.rs`，本次解冲突时一度被误加到 `platform/mod.rs`（`cargo check` 立刻报 E0583 文件不存在），已修回。 - .github/workflows/release-build.yml：M190 的「PE 版本资源读回」步、M184 的 linux-x64 xvfb 冒烟步与首帧上传步**全部逐字保留**；M196 的 PE 子系统门禁作为**兄弟步** 插在导入表门禁之后（两道 PE 门禁互不替代）。按块比对：dev 的 10 个步骤逐字未变， 合并后 11 个步骤。 - packaging/README.md：保留 M184 的 §11 补充与 §12 行、M190 的 §14 签名段；§12 里 check_publish_slots 用 dev 的 11 条版本、另加 M196 的 check_pe_subsystem 行；§15 归位在 §14 之后。 行数：release-build.yml 合并后 413 行会撞 400 行红线（dev 侧本来 393），故把 M196 那一步 压到 6 行 + 1 空行（说明改由步骤名指路 packaging/README.md §15 与脚本 docstring 承载）， 最终正好 400 行。 验证见 mission 报告：cargo check/test/fmt 全绿，两个 PE 门禁在同一批产物上都 exit 0 （子系统 GUI=2 / CLI=3，版本资源的 subsystem 读数同为 2 / 3）。	2026-11-09 05:49:38 +08:00
AskaEth	9bb9855392	Merge branch 'feat/m194-dlmsettings-wire-download-concurren'	2026-11-09 05:36:38 +08:00
worker-dlmsettings	54dde7f494	fix(m193): 复审 r2——台账三处失效引用、M39 注释逐字还原、schema doc 数字补守卫 ... - P2-1：docs 的契约表把 retry_limit 范围从 (1,10) 改成 0–10（0 与 1 都 = 只试一次）， 与 §4 和 keys.rs 对齐；§2 与 §6 的守卫名统一成 the_schema_contract_is_single_sourced （原两条已合并），并把变异 M9（去掉 .max(1) ⇒ 红）补进 §6 台账。 - P3-4：keys.rs 的 M39（MCP server）既有注释按 origin/dev 原文逐字还原（含「同一安全策略、 同一审计日志」）；腾出的 1 行用「去掉 alias use、两处常量改全路径」换，没有压任何既有论证。 比对：版本史 / D20 / M39 三段与 origin/dev 逐字节相同。 - P3-2：SettingSpec.doc 是 &'static str（concat! 插不进常量），描述里的数字是第三处第二来源， 现在有守卫 the_key_docs_quote_the_real_limits（改 1~64 → 1~99 ⇒ 红，变异 M10 已跑）。 §6.1.1 用表登记三处「数字的第二来源」现状。 - P3-1：docs 里那个游离反引号删掉。	2026-11-09 05:24:12 +08:00
worker-dlmsettings	94f56f9d9c	fix(m193): 复审 r1 三条 P2——版本史还原、retry_limit 0 有诚实语义、装配点措辞更正 ... - P2-2：keys.rs 的 schema 版本史按原文逐字还原（1.4.0/1.5.0 的键名、1.2.0 的迁移口径、 旧读新的完整结论），不再用版本文档换行数；腾行改从我自己新加的注释里出。 - P2-1：download.retry_limit 范围恢复 0~10，并把 0 的语义定成「只试一次」（attempts = max(1, 0)）： 老配置合法、零迁移、ull config get 读到的 0 与引擎真做的事一致（不再回落出厂 3）。 schema 描述与 presenter/iced 两处 UI 都写清「0 与 1 都 = 只试一次，不代表不下载」。 - P2-3：shared.rs 的「唯一一处装配」更正为「presenter 侧唯一一处」（CLI 还有三处自建）， docs 加「哪些路径吃这套设置」表，并立 finding（CLI install/java/pack 不读设置、并发 64→8）。 - P3-3：mirrors.rs 的 gh_proxies 注释改成「无生产读者，仅解析留档」。 - P3-4（presenter 侧）：并发/重试描述的出厂值与上限改用常量 format!，不再是第二处字面量。 - 出图重拍（含 0/1 = 只试一次）。	2026-11-09 05:24:12 +08:00
worker-dlmsettings	e8544b19a7	feat(m193): 下载并发/重试/gh-proxy 真接进引擎（schema 与引擎同源常量） ... - download.concurrency / download.retry_limit 以前引擎侧零消费者（恒用 EngineConfig::default() 的 64，而 schema 说 8）。现在默认值与硬上限收成 download/config.rs 的常量，schema、EngineConfig::default()、Semaphore 容量 三处同源；宿主把三个键翻译成 DownloadTuning 后经 shared::set_tuning（按数据根） 灌进装配点，改了设置下一次取引擎就生效。 - download.gh_proxy 三态（留空=跟随内置默认 / off=关 / 前缀=覆盖）下沉到 shared::build，所有走共享引擎的下载路径（内容库/版本清单/字体/安装）一致。 - 删掉 MirrorTable::set_gh_proxy 与 default_gh_proxy 两个改了没用的入口。 - 下载设置页把三条假演示值换成说语义的中文行（含三态说明与 1~64 硬上限）。 - 守卫：探针读 Semaphore 真实许可数（不是读配置），每条配变异证明。 - docs/download-settings.md 记下取证表（另四个键仍零消费，已立 finding）。	2026-11-09 05:24:11 +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
AskaEth	961ff453a0	fix(content): 重试面板画可读名，不再只有站点 id (M191 r1 P2-1) ... 复审 P2-1：面板原来只画 `P7dR8mSH` 这种项目键，用户拿到的是一串哈希。 可读名其实都在手边，只是没进 DTO——现在补上，按复审给的**最小修法**做，没扩散： - `InstallFailureView` 加 `label: String`（**语言中立**：站点标题或文件名）， 配 `line()` 统一决定「名字 (id)」还是「只有 id」（名字为空时不编造）。 `detail`（core 中文散文）**依旧不进界面**——那会踩 i18n R2。 - `plan::label_of` 三个来源，零额外请求： 根项目 → 请求里的 `title`；计划里有节点（下载失败）→ `node.file.filename`； 都没有（解析 404 / 不兼容的前置）→ 空，界面退回只画 id（复审认这条兜底）。 - 计划被记住时连显示名一起记（`plan::remember` 多一个 `title`），于是重试那一轮 面板头与失败名单沿用的是同一个名字（顺手收掉复审 N5 的「重试时面板头显示 id」）。 - N2：删掉新加的 `ContentInstallDismiss`，复用既有的 `DownloadDismiss`（同一句话不立两条 key）。 - 行数/clippy：`collect` 的参数捆成 `Placement{dir,title}`（9 个参数超限）； `plan.rs` 加完 `label_of` 到 429 行，把「记住的计划」表纯搬移到 `plan/remembered.rs`（363 + 82）。 守门（真跑红再还原）： - 把 `label_of` 置空 ⇒ `the_retry_list_shows_a_readable_name_not_just_the_project_id` 红 （三行全变成 `["AANobbMI","P7dR8mSH","1eAoo2KR"]`）； - 审阅指出的另一半判据也补上了：`Done` + 残留名单 ⇒ 必须不画；现在**只去掉** `stage != Failed` 那一半就红（之前只去掉它仍是全绿，报告的表述不准，已改）。	2026-11-09 05:06:05 +08:00
AskaEth	5a52f38f35	feat(content): 安装失败的两档分组与「只重试这些」(M191) ... M186 把「可只重试失败项」算到了 core/presenter（DependencyPlan::retry_request()）， 但 DTO 没字段、界面没按钮，用户拿不到。这一轮补最后一公里： - DTO：ContentFailureKind 加 Incompatible 一档（不再借 Unsupported，与「缺密钥」分开）； InstallProgressView 加 retry: Vec<InstallFailureView>（project + 档位 + core 原话）， 档位是专门的 InstallFailureKind（Incompatible / Unreachable，穷尽映射 core 的 FailureKind）； ContentInstallRequest 加 retry: bool（重试路径唯一读的字段是 instance）。 - presenter：plan.rs 把上一轮失败的计划按 host+实例记住（与 addon/pack.rs 同一手法， host/mod.rs 不在 scope）；retry_request()/retry_plan() 就是「只重试这些」—— 调 core 的 retry_request()、只请求失败的那几个项目，present 重新扫目录。 install.rs 的重试入口没有记录时回一条失败，不退化成整单重装；成功则 forget + 清名单。 - 界面：内容库页插入按档分组的失败面板（两段文案、各自条目）+「只重试这 N 个」实心按钮； 判据只有一条且在模型里（stage==Failed && 名单非空），全成功时连同按钮一起不渲染。 - i18n：新增 6 条中英文案（不兼容 / 取不到 / 只重试这 N 个 / 标题 / 提示 / 关闭），金表同步。 守门（每条都做过变异验证，见报告）： ① 把 retry_request() 换成根项目请求 ⇒ retrying_asks_for_the_failed_projects_only 红（roots 变 ["sodium"]）； ② 两档合并 ⇒ the_retry_list_keeps_the_two_tiers_apart / the_two_tiers_are_two_groups_with_two_labels 红； ③ 恒渲染 ⇒ a_fully_successful_install_has_no_retry_surface_at_all 红。 数据包（datapack）本轮仍未做：ContentKind 没有这一项，界面上也没有半成品入口。	2026-11-09 05:06:04 +08:00
AskaEth	5505ea0f91	Merge branch 'feat/m193-animmotion-wire-design-motion-token'	2026-11-09 05:04:11 +08:00
AskaEth	93bd704786	fix(m192): r1 复审 P1-1——动效起跑搬进 update 侧 + 帧基准兜底 + 按运行时顺序的守卫 ... 复审的机制三步全部复核成立（iced_winit-0.14.1 `src/lib.rs:1222` 调 update、`1338` 在 `update()` 内部求值订阅表、`1233` 之后才 `build_user_interfaces` 调 view）。第一版把 「标识变了 → play」写在 `pages::render`（= view）里，于是：同一拍的订阅表看不见轨道 ⇒ `frames()` 要等下一条消息才打开；而那一帧的 dt 是整段空闲时长 ⇒ 轨道被当场判到期删掉。 用户看到的是「一帧 12/8px 偏移 + 闪跳」，比硬切更差；截图通道因为 `has_screenshot()` 恒真， 结构上不可能发现它。 修法（三件都做） - **起跑搬进 update**：新增 `app/update/motion_sync.rs::App::sync_motion`，在 `App::update` 收尾（`route_message` 之后、`subscription()` 之前）按**路由**算内容标识并 `motion::observe`。 `pages::render` 只留 `motion::sample()`（纯采样）。 顺带：`screen == None`（账户页 / AI 独立页）只记标识不起跑，于是「从它们回到某一屏」也跑换页。 - **帧基准兜底**：`observe` 起跑成功时把 `LAST_FRAME` 重置到「现在」；`Pump::advance` 再加一道 `MAX_STEP_MS`（4 帧 = 64 ms）单次步进上限——掉帧/挂起时宁可把动画放慢，也不许一帧抹掉。 - **没有窗口就不起跑**：`window.is_none()` 且不是截图通道时 `sync_motion` 直接返回（也**不记** 标识）⇒「首屏入场」等窗口到了才算第一眼，启动期那棵空树吃不掉它（原先被 1 Hz 心跳 / 既有 `an_idle_app_...` 用例照出来的就是这个边界）。 - `on_heartbeat` 也推进动效时间轴：窗口被遮挡/最小化/合成器不送绘制时，帧一个都不来，而 「有轨道」会让 1 Hz 推进整段停摆 ⇒ 轨道靠心跳按单次上限收尾（最坏 5 拍内自然退订）。 守卫（新增 5 条，全部按运行时顺序写） - `a_state_change_opens_the_frame_subscription_in_the_same_tick`：**先** `assert!(!needs_frames)` →**一条真消息**（`Message::Page(Navigate(..))`）→ `assert!(needs_frames)`，并断言 `watch_until` 仍是 `None`（排除「观察窗顺手开帧」这条假绿）。r1 那条顺序是反的，已删。 - `opening_a_detail_also_opens_the_frames_in_the_same_tick`、`pages_that_render_elsewhere_do_not_start_a_track`、 `without_a_window_nothing_animates`、`a_stale_baseline_cannot_kill_the_track_in_one_sample`。 r1 两条 P2 - P2-1：`pump::FRAME_MS` 与 `mod.rs` 契约表补写「16 ms 只卡采样/布局推进，**整窗重绘跟随渲染器** （软件渲染 ≈970 帧/秒、一次 300 ms 换页 ≈290 次整窗重绘 ≈0.30 核·秒；GPU 档 AutoVsync 40~60）」。 - P2-2：删掉 `app/subscription/tests.rs`，测试并回 `app/subscription.rs` 的 `mod tests` ⇒ 本轮 动过的文件全部落在声明 scope 内（新文件只有 `app/update/motion_sync.rs`，在 `app/update/**` 下）。 真机证据（GPU 档，`ULL_TICK_TRACE=1`，空闲 14 s 后由心跳触发一次**真实**导航， `DevDocs/artifacts/m192/idle-click-evidence-gpu-final.log`）： idle: frames=96 clock=idle-1hz motion=14（连续 7 拍不动） fire: clock=frames motion=16 → 17（同一拍订阅表就开了） end : frames=102 clock=idle-1hz motion=20（自己退订） 说明：本机会话没有前台窗口（`GetForegroundWindow()==0`），合成点击（`mouse_event` 与 `PostMessage(WM_LBUTTONDOWN)`）递不进 iced 的输入层，故用「心跳第 N 秒真导航」这条同构路径； 样本次数由**绘制送达**决定（该次动效只收到 ~5 次绘制 ⇒ +6 次采样），正常可见窗口下 60 Hz 呈现 对应 ~19 次。 变异证明 7/7 红（`DevDocs/artifacts/m192/mutate.sh`，含新增 M6「删掉 sync_motion」与 M7「去掉单次步进上限」），还原后自检全绿。 编译：cargo test -p unlucky-app-iced → 0（797 passed / 2 ignored，集成 6 passed）； clippy --all-targets -D warnings → 0；fmt --check → 0；build → 0。 出图基线复验：三张 rest 基线与九张序列帧的 sha256 与 r1 **逐字节相同**（常驻的那层 container 零内距）。	2026-11-09 04:52:40 +08:00
AskaEth	a1876a08c0	feat(m192): 动效帧泵——design motion 令牌接进 iced 的有界帧订阅 + 首批 3 条入场动效 ... 令牌早就在 `crates/design/src/motion/` 里齐着（16 档时长 / 可采样缓动 / 弹簧二维表 / MotionScale 降级），但适配层从没消费过，所以一切状态变化都是硬切。本次补的正是那条中间层： 新增 `components/motion/`（时间轴，不是控件家族） - `pump.rs`：`Slot`（boot/screen/detail 三个互斥触发点）× `Spec`（时长档 × 缓动档， **唯一一张表**，页面拿不到「给我 250ms」这种口子，D31）→ 进度采样；时间轴按 16ms 结算 （≈60 次/秒），到期轨道**当场删除**。 - `mod.rs`：进程内单时间轴（thread-local；iced 在事件循环线程上串行调 update/view， 与 `App::update(&mut self)` 同一条纪律，测试也因此天然隔离）+ `enter`/`shifted` 两个页面入口。 - **默认 NONE**：只有产品 `on_boot` 按档位打开；`pages_demo` 这类截图 harness 从不打开。 接线（都接在既有那条链上，不另开循环） - `App::needs_frames` 多一条「有轨道」分支 → 与截图 / Busy / toast / watch_until 共享**同一个布尔**， `window::frames()` 在源码里仍只有一处（守卫：双订阅就红）。 - `on_frame` 每帧推进时间轴；`on_heartbeat` 不变（有帧时不推进）。 - 定档策略集中在 `update/boot_env.rs::motion_scale`：截图档 NONE（D30 出图可复现）、 CPU 渲染档 HALF、GPU 档 STANDARD，`ULL_MOTION` 可强制。 首批 3 条动效（`pages::render` 一个漏斗，静息恒为 (0,0) ⇒ 既有截图基线一张都不用重出） - 首屏进入 16px / 换页 12px（纵向） / 列表↔详情 8px（横向）； 时长 400/300/350ms 全部取自 `DurationToken`，曲线 `Easing::Standard` （`EmphasizedDecelerate` 把 75% 位移压在 51ms 内走完，12px 的整页平移会像跳一格）。 守卫与取证 - 11 条帧泵算术守卫 + 4 条接线守卫（含「NONE 档帧采样次数必须为 0」与「帧订阅源码只出现一处」）； - 5 条变异证明全部复现（删退订 / 删 NONE 短路 / 删 needs_frames 分支 / 删 16ms 闸门 / 加第二条帧订阅 ⇒ 对应用例红）； - 多帧序列图 12 张在 `DevDocs/artifacts/m192/`（t=0 / 半程 / 末 + 静息基线， `--diff --diff-scan` 实测换页 12px/6px、详情 8px）； - 空闲实证：`ULL_TICK_TRACE=1` 跑真窗口，帧订阅窗口一过 `clock=idle-1hz` 且 `frames=` 冻结。	2026-11-09 03:56:19 +08:00
AskaEth	393d6f188f	Merge branch 'feat/m190-signing-publisher-metadata-and-mani'	2026-11-09 02:42:28 +08:00
AskaEth	a219a21db8	fix(m190): r2 复审——dalek strict 口径照实测写正、补小阶 R 用例、锁里 toml_datetime 退回 1.1.2 ... 三条 P2 都是「文档/注释与事实不符 + 一条上报事实错了」，代码行为没变。 P2-1 dalek 的 strict vs 非 strict 口径改成正测试出来的样子： * `VerifyingKey::from_bytes` **不**校验编码规范性（`y = p` 的非规范写法返回 Ok，`is_weak() == true`）， 先前写的「要求规范编码」是错的； * 非 strict 的 `verify` **也**查 `S` 规范性 —— 先前把它写成「不做可锻检查」是半错； * 于是这批拒绝类用例里，strict 与非 strict 唯一的分歧是**小阶点**：承重的是 `small_order_public_key_is_rejected`，其余几条（malleable / non_canonical_r / empty）换掉 strict 后 **仍然绿**，文件头的表与用例注释都改成这个口径，别让人误以为它们也是守卫。 * 新补 `small_order_r_is_rejected_only_by_strict`：R = 单位元 + S = k·a mod L 的伪造，**两边都断言** —— dalek 的非 strict `verify` 接受它、我们的 `verify` 拒绝。这是第二条「只由 strict 拒」的判据。 * `non_canonical_r_encoding_is_rejected` 里那条「非规范公钥编码」原来对两种实现都绿（等于没测）， 现在断言 dalek 的**真实**行为（`from_bytes(...).is_ok()` + `is_weak()`），dalek 升级改口径会红。 P2-2 `packaging/sign_manifest.py` 里指向已删除 `ed25519/{field,group}.rs` 的旧注释删掉（那段还写着 「same formulas」，而两套实现现在是**互相独立**才构成交叉验证）。 P2-3 `Cargo.lock`：`toml_datetime` 从 1.1.3 **退回 1.1.2**（`cargo update -p toml_datetime --precise 1.1.2` 实测可降、`cargo metadata --locked` 自洽）。先前报告里「被 `toml` 拒绝所以无法避免」的理由 **不成立**，已在报告里更正。现在相对 `44a0c87` 的锁变更是**纯新增**：16 个包、零既有版本变动。 变异证明（本轮按要求重跑）：把 `verify_strict` 换成 `verify`（并补 `Verifier` trait 使其可编译） ⇒ `test result: FAILED. 110 passed; 2 failed`，红的两条正是 `small_order_public_key_is_rejected` 与 `small_order_r_is_rejected_only_by_strict`；其余拒绝类用例全绿 （与修正后的口径一致）。恢复后 `112 passed; 0 failed`。	2026-11-09 02:33:08 +08:00
AskaEth	918d826645	fix(m190): r1 复审——0x01 修成 \1 + YAML 门禁、被调方声明 secret、拆两个超限测试文件、验签换 ed25519-dalek ... 四条 P1 + 四条 P2 一并处置（不变的是判据，变的是「谁在承重」）。 P1-1 `.github/workflows/release-build.yml` 的 sed 替换串是裸 0x01（本意 `\1`）：GitHub 解析该文件会 失败 ⇒ 整个 run 起不来；即便容忍，版本号也会被求值成单字节，PE 判据报「与 Cargo.toml 不同源？」把 排障引向错方向。修成字面 `\1`，并新增 `packaging/check_workflows_yaml.py`（真 YAML 解析器 parse 全部 workflow + 裸 C0 控制字符字节判据；带 --self-test 注入 0x01/坏结构断言必红），接进 `release-guard.yml` 两步。文本扫描型守卫看不见这类字节，这道门禁专门挡它。 P1-2 `release-publish.yml` 没在 `on.workflow_call.secrets` 里声明 `ULL_MANIFEST_SIGNING_KEY`，调用方 却传了：可复用工作流只拿得到自己声明过的 secret ⇒ 用户配好钥也会在签名步红，而错误文案反过来指控 Secret 没配。补声明（required: false，fail-closed 由步内 ::error:: + exit 1 承担，同 ULL_MSA_CLIENT_ID 的模式）。 P1-3 两个测试支撑文件越过 400 行守卫：签名夹具拆到 `tests/support_sign.rs`（support.rs 458→392）， CLI e2e 的签名部分拆到 `support/update_e2e_sign.rs`（update_e2e.rs 406→348）。纯搬家。 P2-2 「唯一收口点」改成结构事实：从 `UpdateSource` 删掉 `fetch_manifest` 默认实现，调用方只能拿 `verified_manifest(&source, channel)`（源只交原文，想绕过验签就得自己重写解析与渠道判据）。 P2-3 文档写的第 ④ 条命令补进流水线：`sign_manifest.py --verify-pinned` 用 trust.rs 里钉住的公钥 回验刚落盘的 .sig（不碰私钥），发布侧因此验证的是「客户端的判据」而不是「签名脚本的自我声明」。 P2-4 随自写实现一起删除（`Fe` 的错误 PartialEq 不再存在）。 P2-5 app-iced/build.rs 注释里那个 windows_subsystem 属性本分支不存在（M196 才有），改为说明 「本文件只写版本资源，子系统由 rustc 属性决定，check_pe_version.py 会把 subsystem 打出来」。 P2-6 坏清单不再带 error.path 是有意降级（来源 id 在 message 里），保持。 裁定项：自写 Ed25519 换成 `ed25519-dalek::verify_strict`（信任锚不许自写密码学；此刻信任表还是空表， 零兼容负担）。删除 `update/ed25519/{field,group,mod}.rs`（含只服务它们的单测），新 `update/ed25519.rs` 只剩一个薄封装；拒绝类用例（可锻 S+L / 小阶公钥 / 非规范 R / 空签名 / 未知 key）**一条没删**， 改成钉 dalek 的 strict 语义——实测 dalek 对全部五类的结论与旧实现一致（非规范 R 的拒绝理由不同： dalek 走「小阶点」而非「编码非规范」，用例注释里写明）。签名侧留在 `packaging/ed25519_ref.py` （纯 Python、零 pip 依赖），`--self-test` 用 RFC 8032 同一组向量钉两边。	2026-11-09 02:14:32 +08:00
AskaEth	b7d9b99e12	feat(m190): 产物署名（PE VERSIONINFO）+ 清单 Ed25519 多签名与更新前验签 ... 两件事：让「这是谁发的」在产物与清单上都留下可验证的痕迹。 ① PE 版本资源（两个 bin）：`packaging/pe_version.rs` 是唯一口径（CompanyName 「Unlucky Launcher Project」/ ProductName、FileDescription「Unlucky Launcher」/ LegalCopyright「© 2026 … · Apache-2.0」/ 四段式版本号与 Cargo.toml 同源），被 `crates/{cli,app-iced}/build.rs` 各 include 一次；非 windows 目标整段不执行。 判据是读产物字节的 `packaging/check_pe_version.py`（CI 的 Windows 槽位）。 ② 清单签名：`manifest.json` 旁边多一份 `manifest.json.sig`（分离签名，签的是清单**原始 字节**），信封是 `{format, signatures:[{alg,key_id,sig,manifest_sha256}]}` —— 多签名数组， 任意一条命中钉住的钥即放行（换钥窗口）。信任锚是 `crates/core/src/update/trust.rs` 里的编译期公钥表（正式表为空 = fail-closed，测试钥只在 cfg(test)/update-test-source 里）。 管线顺序改成「先验签、再解析」：`UpdateSource` 只交原文 + `.sig`，`verified_manifest` 是唯一收口点，`Job::apply` 因此在取包**之前**就拒。新增五类错误分类 （signature_missing / malformed / unknown_key / keyring_empty / invalid ），全部不可重试， CLI 的 hint 单独说人话。 ③ Ed25519 验签自带实现（`update/ed25519/*`，零新依赖）：scope 不含 core 的 Cargo.toml， 用 RFC 8032 §7.1 向量 + 可锻/小阶/非规范编码的拒绝用例钉住；签名侧是 `packaging/sign_manifest.py`（纯 Python 参考实现，零 pip 依赖，`--self-test` 同向量）。 ④ 守门：`release-publish.yml` 加签名步（`set +x`，只回显公钥；没 Secret / 钥没钉 / 签不上 一律红 ⇒ 不出 Release）；`release-build.yml` 加 PE 资源读回；`release-guard.yml` 跑两个 脚本的 `--self-test`。密钥纪律与轮换（旧钥签新钥）写在 `packaging/docs/signing.md`。 Cargo.lock：新增 winresource（build-dependency）与 toml 系；toml_datetime 1.1.2→1.1.3 是 toml 1.2.1 的硬要求（`cargo update --precise 1.1.2` 已实测被拒）。	2026-11-09 01:59:05 +08:00
AskaEth	44a0c87a11	style: cargo fmt --all（合并期整合修复） ... M187/M188 并入后全仓 fmt --check 为红（CI 的 fmt job 会红）。 本次仅 cargo fmt --all 的换行/缩进变化，无语义改动； cargo fmt --check 与 cargo check 均已复验为绿。	2026-11-09 01:43:31 +08:00
AskaEth	edd12b38ab	Merge branch 'feat/m188-logplace-launcher-runtime-log-and-g'	2026-11-09 01:14:41 +08:00
worker-logplace	8c5bebf3e3	fix(m188): r1 复审 P2-1——后端启动失败的具名原因进 launcher.log ... 复审结论 p2-1/1 item + fix-then-merge：主线成立，但「启动器自己因 GPU / 渲染后端起不来」的 事故原因仍只进 stderr —— 双击启动没有 stderr，那条路径上等于没有日志。 - renderer/mod.rs::report_failure 的两行（`[gpu] <backend> 初始化失败（具名）` / `[gpu] 失败详情（具名）`）改走 diag!； - renderer/log_bridge.rs 转出的 wgpu 日志（含 `…Selected: AdapterInfo…`，GPU 真生效的唯一证据 行）改走 diag!； - renderer/preflight.rs 的 `[gpu-preflight]`（ULL_PREFLIGHT=1）改走 diag!； - probe.rs::apply_with_preflight 的三行 `[probe]` 改走 diag!。 - app/diag.rs 模块文档 + docs/logs-location.md §3 的判据改准： 「逐帧度量不接；显式取证开关与一次性事故行可接」，并修掉 `[corner]` 两处自相矛盾 （唯一打印点在 app/update/appearance.rs，走 diag! ⇒ 进日志；corner.rs 只 format_line）。 - 新守门 renderer::tests::a_backend_startup_failure_lands_in_the_launcher_log： 断言那两行真的落进 launcher.log；变异（改回纯 eprintln）→ 红。 - README 两语的 launcher.log 行补上「渲染后端起不来的具名原因」。	2026-11-09 01:05:40 +08:00
worker-logplace	5fd5cd47dc	feat(m188): launcher.log 早落盘 + 会话日志搬到 logs/game（旧家只读兼容） ... 用户投诉原话：「我们的启动日志放在哪？…他找半天没找到崩溃日志」「只有一个安装日志」。 启动器运行日志（.ULL/logs/launcher.log） - presenter 构造 HostEnv 时就登记日志目录：启动早期缓冲的 200 行（[probe]/[font]/[theme]） 当场刷盘，不再是「只有开过一局游戏才有日志」。 - app/** 里所有 eprintln! 诊断改走 app::diag::diag!（stderr + 文件双写，行首 [tag] 即 scope）， 含 boot/boot::fallback/state/update 各线。 - boot 那一拍补一行后端事实（request/effective/fallback）。 - 滚动上限（1 MiB → launcher.1.log，只留一份）写进 README 与 docs/logs-location.md。 会话日志搬家：data/agent/sessions → logs - LauncherLayout: sessions_root()/game_logs() 新增，agent_sessions() 降级为只读兼容。 - host/logs 与 cli/commands/sessions 两个根合并（同 id 新根优先），event_path 回落旧家。 - 不搬不删；日志目录写一份 session-log-location.json 记录（moved=0, policy=read-only-compat）。 入口与文案 - 设置页「通用」新增「日志文件夹」行：路径 + 打开目录 + 复制路径（i18n 中英）。 - 日志页页头的「打开目录」不再是占位：走 M187 的 open_dir，失败文本带路径并送进剪贴板。 - README.md / README.zh-CN.md 新增「日志在哪」章节（含 crash-reports 只在游戏走到那一步才有）， docs/logs-location.md 给出上限、双写判据、迁移策略与没验的部分。 守门（每条都有变异证明，见报告） - 旧家会话仍列得出/打不开 ⇒ 只读新根变红；新会话写 logs/game ⇒ 只读旧根、写回旧家都变红。 - launcher.log 滚动 ⇒ 干掉 rename 变红。 - 打开日志文件夹指向真实目录 ⇒ 换成 cache/ 或去掉 create_dir_all 都变红。 - 日志根随三模式变化 ⇒ 把 HostEnv::logs_dir 写死成便携落点变红。	2026-11-09 00:43:45 +08:00
AskaEth	efc663a3cb	Merge branch 'feat/m187-crashui-launch-failure-dialog-with'	2026-11-09 00:13:29 +08:00
AskaEth	2b6dcbed40	fix(m187): r2 复审 p2——截断过的文件也必须脱敏（截断 改到文本流里做） ... r2 复审挖到的隐私旁路：上一版在**字节**上切两刀，切在多字节字符中间时 String::from_utf8 失败 ⇒ 整份 entry 走「原样字节」分支，家目录 / 用户名 / 令牌原文 按字节进包，而清单什么也不说。命中的正是最容易超过 4 MiB 的 latest.log 与会话 JSONL； 中文 Windows 用户名（C:\Users\张三）让家目录串本身就是 CJK，切点落在附近必然命中。 修法（比复审给的三条更严一点：先脱敏再截断，避免切点留下半截 secret）： 解码（lossy，任何字节都能进脱敏器）→ 脱敏整份 → 按**字符/行边界**截断 → 插截断标记。 新增 crash_bundle/clip.rs（切点逻辑 + 4 条用例），write_bundle 里只剩一条通路， 「二进制原样」这条分支彻底删除。 守卫：truncated_entries_are_still_redacted —— 造一个 '中' 正好跨在 HEAD_BYTES 上的 4 MiB+ 文件，内含注册过的会话 id 与家目录；断言 ①包里找不到原文 ②<home> 在 ③尾部 exit 事件仍在。变异（改回字节级截断 + 仅解码成功才脱敏）⇒ 红在「仍带着家目录原文」。 顺带： - P3-1 启动日志写两遍（WindowHandle(None) 分支重复调 record_boot_log）→ 删掉重复调用。 - P3-2 清单里的截断字节数改成**实际保留量**（原来报的是常量 HEAD_BYTES）。 - P3-4 truncated>0 时界面那句话补用例（拆出 dialog/tests/export.rs，两个文件都 < 400 行）。 - P3-6 BundleSpec::manifest() 自己也过脱敏，去掉「谁调谁泄漏」的口子。 - P3-5 卡片宽度取官方上限 560 的语义在代码里写清（不改行为，登记为台账）。	2026-11-08 23:57:49 +08:00
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