AskaEth/Unlucky-Launcher
1
0 Fork 0
Code Issues Pull Requests Actions 7 Packages Projects Releases Wiki Activity
681 Commits 3 Branches 6 Tags
66929786c0b363a870f227a29591fe477a8cf7fd
Commit Graph
133 Commits
Author SHA1 Message Date
AskaEth 66929786c0 docs(core): M240 复审 P2-1/P2-2/P2-3 —— 口径收窄、大写判据钉住、找回丢掉的负例 
P2-1：「抹除能力没有下降」是绝对承诺，已改成准确口径——收窄的就是三类形状
（`=` 边界、填充不计段长、全小写点分串），每条都在 shape 模块文档里写明，并用
`known_narrowings_old_masked_new_keeps` 把「旧行为抹、新行为留」钉住。三条的旧行为
是用 M240 之前的真实代码（`git show 74be510:…` + rustc 探针）实测的，不是推断。

P2-2：「必须含大写」原先没有任何测试钉住（复审实测：删掉它 13 条仍全绿）。
查明原因：DNS 形状的全小写点分串早就被"首段是主机名"那条豁免救下，大写判据
只对**非 DNS 形状**的全小写点分串承担区分作用（标签带 `_`、标签超 63 字符、
`/` 前只有一段主机名）。选择保留（复审的 (b)），并补
`the_uppercase_requirement_is_load_bearing`（`sophisticated_backpacks.upgrades.reference`
等两条）——删掉判据 → 该测试与 `lowercase_dotted_names_are_spared` 红、其余 15 条绿。
同时改正事实错误：不是"第三段必为大写"，而是头的 base64url **第三个字符**恒为
`ey` + `I/J/K/L`（`7B 22 xx` 的第三组 6 位 = `b1` 低 4 位 ++ `b2` 高 2 位 → 索引 8..11）。

P2-3：找回重构时丢掉的老负例 `dotted_token_rule_does_not_eat_normal_text`
（4 条用例 + 直接断言 `!has_dotted_token(...)`，含 `eyJhbGciOiJIUzI1NiJ9.short.abc`）；
语料测试的 doc 注明它**只守一个方向**，不得当"正例仍被抹"的背书。

判据与阈值一个字没动（40 / 3×8 / 64），扫描器代码零改动，纯文档 + 测试。
 2026-11-11 10:15:49 +08:00
AskaEth 43f77d8865 fix(core): 收窄日志脱敏的三类误杀（品牌串 / CDN 主机名 / 长路径） 
M239 实测两条形状规则会误杀三类正常文本，被抹掉的正是用户要复制的面
（`--dry-run` 的 argv、`cmd_built.argv`、诊断规则引擎的输入）。修法不是抬阈值
（40 / 3×8 / 64 一个字没动），而是给每条规则加**必要条件**：

- `-D<key>=<品牌>` 被当三段式 token：`=` 是赋值边界、退出 dotted 字符集
  （JWT 的 `=` 只可能是末尾填充），键里的点号不再把值拖进段数统计。
- CDN/镜像 URL 变成 `https:<redacted:token>`：加"必须含大写"与"首段不是 DNS
  主机名"两条必要条件（JWT 头是 JSON，base64url(`{"`) = `eyJ` 必含大写；
  base64url 不含 `/`）。扫描器先切主机名，路径那半继续判——JWT 放进 URL
  路径里照样抹。
- ≥64 无点号长串吞掉整条路径：路径形状（被 `/` 切开且每段是词形名字）整条
  保留，但**段本身**≥64 的照抹（`/…/objects/<64 位 hex>` 只抹那一段）。

真凭据的抹除能力不变：登记过明文值的替换路径没碰；正例（本仓 JWT / MSA JWT /
`-DaccessToken=` 粘着 / URL 路径里的 JWT / 标准 base64 三段式 / sha256 hex /
base64 ≥64 / `A`×64）全部仍被抹。回归语料（M239 的 68 文件 / 243 行）修前被改
1 行 → 修后 0 行。判据与扫描器拆成 redact.rs + redact/{shape,tests}.rs。
 2026-11-11 10:15:48 +08:00
AskaEth edd6402fd5 fix(core): 规则结论改在脱敏前算，会话路上 fabric.loader_0_12 能命中（M241） 
会话 JSONL 是写前脱敏的，而脱敏的「≥64 无点号不透明串」是有损的：
fabric.loader_0_12 唯一的证据行（Sponge mixin 类路径 66 字符）被抹成
<redacted:opaque>，规则在会话路上永不命中。

修法不动脱敏策略、也不往盘上多写一份原文：
1. SessionWriter 在内存里留一个 2000 行的原始尾窗（不落盘）；
2. 收尾时把这些**原始**事实交给新的 diagnose::session::conclude 跑规则，
   产出契约形状的 diagnosis payload —— 它落盘前仍过 Redactor::scrub_json；
3. 日志页优先读这条落盘结论，老会话才回落到「在脱敏文本上重跑规则」。

为什么不是「原文与脱敏文本并存」：会话 JSONL 里存原文会踩
core/tests/launch/pipeline_cases.rs 早已钉死的「事件流不得含凭据明文」。

顺带把 EventKind 纯搬移到 launch/session/event_kind.rs 守 400 行上限。
 2026-11-11 09:19:42 +08:00
AskaEth f217d83680 feat(saves): 实例存档 / 截图的只读列表与打开文件夹（M235 STOREMVP） 
用户诉求是 PCL 差距四项里的「存档截图 / 导入」，M230 审计确认三层全缺。塔裁决 U3
把这一版钉成「只读列表 + 打开文件夹」，不做缩略图墙（缩略图要引图片解码依赖，而
AGENTS §2 只允许 palette-extract 引 image 类依赖；截图/导入产物形态也没定型）。

core
- `game::saves`（新）：只读列 `<run_dir>/saves`（世界目录）与 `<run_dir>/screenshots`
  （图片文件）。只调 symlink_metadata / read_dir / metadata，不建目录、不写文件、不读
  文件内容（`icon.png` 只判存在）。目录不存在 ⇒ 空列表不是错误；存在但不可用（符号
  链接 / 不是目录 / 读不了）⇒ 具名错误。条目级异常逐条登记原因，不静默丢。
- `platform::opener`（新）：`open_dir` 是**目录**打开器的唯一收敛点（explorer / open /
  xdg-open），内部复用 `child::quiet`，cfg 分支只此一处。塔明确要求按 AGENTS §6 放
  platform 而不是业务模块，并要一条可执行判据防退化
  （`the_launcher_literals_live_here_only` 扫 `crates/core/src`：除本文件外不许出现
  `"explorer"` / `"xdg-open"` 字面量）。

presenter
- `dto::saves`：SavesCommand（List / OpenFolder）、SavesListView、SavesFailureView
  （结构 + OS 原文，不拼中文）、`SavesListView` 的计数助手。
- `host::saves`：走 `job::spawn`，UI 只收快照；运行目录仍是
  `isolation::derive_game_dir` 的同一个答案（与启动 / mod 列表同源，**不写盘**）。
  「打开文件夹」打开哪个目录由 host 定：`saves/` → `screenshots/` → 运行目录。
  失败分三类（InstanceUnavailable / DirUnusable / OpenFailed），可重试。
- `state::saves`：快照整体替换、迟到结果丢弃、失败保留绑定（重试才有意义）。
- 接线：CoreEvent::Saves / AppCommand::Saves / HostTask::Saves。

app-iced
- `pages::instances::saves`：详情页 SAVES 卡片（MODS 之后、启动参数之前；**不套第二层
  滚动条**，整列那一条是唯一入口）。世界行带 UTC 时间与「有图标」，截图行带大小与时间；
  第一行固定画「这一版只读」（U3 边界让用户看得见）。读盘失败画一条红字 + 「重试」；
  打开文件夹失败**不画**重试（那个动作的重试就是再点一次按钮）。
- 接线：Message::{ReloadSaves, OpenSavesFolder}、`sync_saves`（与 `sync_mods` 同一判据）、
  Model::saves、`saves_shot` 出图夹具（ULL_SAVES_FIXTURE=1）。

i18n
- `InstancesSaves*` 20 条中英成对，catalog 与金表在**同一条锚点**后追加、逐字节一致。

证据
- core 只读判据：`game::saves::tests` 在真盘建世界/截图，调用前后各拍一次
  （相对路径, 是否目录, 字节数, mtime）指纹并逐条比对；另有用例钉「目录缺失不建目录」。
- presenter：`host::saves::tests` 真盘端到端（custom 档位派生运行目录 → 快照）。
- GUI：`--software-renderer` 1180×760 浅/深各一张 + 1180×1280 两张「整块卡片可见」
  （1180×760 下 SAVES 卡片位于折叠线附近，只能看到卡头；第二对用 ULL_WINDOW_SIZE
  把窗口拉高，口径与 M98 的矩阵一致），落 `DevDocs/artifacts/M235/`。

没做的（U3 边界内，见 handoff）：缩略图墙、导入、删除/重命名、`level.dat` 的
LevelName 解析（世界名暂时就是目录名）。
 2026-11-11 06:00:27 +08:00
AskaEth c917bfa18f fix(core,cli): M231 复审三条 P2 —— 恢复误删用例 / 收窄 --dry-run 文案 / 判定链去重 
P2-1：`natives_cases.rs` 里 `missing_native_jar_becomes_missing_component` 是上一轮
批量截断时**误伤**掉的（我把「tree_snapshot 之后的所有内容」整段砍掉，连带这条与
dry-run 无关的用例），不是有意删。现已从 main 原样贴回，`MissingNativeJar` /
natives 组件缺失这条用户可见失败路径恢复覆盖。

P2-2：help 的「也不写盘」是过度承诺 —— `commands/launch.rs` 的 `launcher_log::set_dir`
/`record_start`/`record` 都在 `if args.dry_run` 之前，dry-run 仍会 append
`<数据根>/logs/launcher.log`（连父目录 create_dir_all）。文案收窄成「不碰版本树
（不解压 natives、不建 natives 目录）；启动器自身的运行日志照记」。core 的 `DryRun`
文档同步加了「本层承诺 / 调用方日志另算」的边界。

P2-3：`extract` 与 `preview` 的「无 jar / 戳记命中 / 重解」判定链合成 `inspect()` 一份，
返回 `DirStatus`（NoJars / Ready(files) / Stale）+ 源 jar 指纹；两个入口只在这里分叉。

另：`tree_snapshot_notices_a_transient_directory` 在全量并行跑时偶发红（本轮门禁抓到 1 次，
单跑 3 次全绿）——「建了立刻删」对父目录 mtime 的影响会被 NTFS 合并。换成确定性自检
`tree_snapshot_sees_new_nodes_and_mtime_changes`（新节点 + 同内容重写的 mtime 变化），
并把这条能力边界写进 `tree_snapshot` 的「抓不住」。
 2026-11-11 05:18:56 +08:00
AskaEth 1fa30c4885 fix(core): launch --dry-run 不再落盘（natives 只预览，零建目录/零写文件） 
`ull launch --dry-run` 在「环境准备」段走的是真解压：即使只打印命令行，也会在
`versions/<id>/natives/` 下建目录、解 dll、写戳记，把别人的版本树改脏（父目录
mtime 也变）。失败路径（缺 jar 报 missing_components）照样留下这些副作用。

- natives 新增 `preview()`：与 `extract()` 共用条目筛选与戳记口径，但零落盘
  （无 create_dir_all / clear_natives / write_stamp），只清点「将写下几个原生库」；
  jar 打不开照样报错，预览不藏坏包。
- `NativesReport` 增 `planned` / `dir_exists`：预览报告自报家门，人读行与 JSON
  说清「未落盘」「目录尚不存在」。
- `Launcher::dry_run` 改走 `preview_environment`，`spawn` 仍走 `prepare_environment`。
- 报告类型拆到 `natives/report.rs`（mod.rs 曾破 400 行红线）。
- 回归测试（natives_dry_run_cases.rs）：有 jar / 无 jar / 空 jar / 已解压过四条
  零落盘判据，用「节点类型 + 纳秒 mtime」快照逐字比较版本树，并带一条判据自检
  （瞬时建删目录必须被快照看见，防假绿）。
- help：`--dry-run` 的承诺补成「不写盘、不解压 natives、不建目录」。

证据（外部版本树 versions/1.16.5 + 真 natives jar）：
修复前 dry-run 后 versions/1.16.5 mtime 1794342830.6861426 → 1794342832.4544542，
新增 natives/ + lwjgl.dll + OpenAL.dll + .ull-natives.json；修复后同一场景快照逐字
不变（mtime 1794343730.6618167），JSON natives.planned=true / dir_exists=false。
 2026-11-11 05:18:54 +08:00
AskaEth 38d1f3c20f docs: DOCFIX-2 收口三处旧口径注释（M232） 
- cli/cli/model.rs:147 `InstallArgs::loader` 文档补 `liteloader`（第六个可装取值），
  并点明 `optifine` 是「认得出但装不了」→ `loader_unsupported`；
- commands/instances/tests.rs:103 删掉「只在认得出但装不了的那两家会红」的旧口径，
  改成真实理由（第三方前缀形状、没有 `<mc>-<kind>-<ver>` 段）；:231 同句副本改成
  「optifine 装不了 / liteloader 自 M222 起能装」；
- addon/loader/liteloader.rs:44 `DEFAULT_REPO` 文档由「BMCLAPI 有 bmclapi-liteloader
  改写规则」改为「直连官方」：该规则自 M225 起 mirrors.json 里是 enabled=false
  （镜像侧实测 404），并按 M225 finding 的方向补上「库走 CENTRAL_REPO」。

纯文档，零行为变化。
 2026-11-11 04:38:53 +08:00
tower-worker a0f61d8bb5 feat(mods): 本地 Mod 列表与启停（M224 MODTOGGLE） 
三层一次做完：core 读写目录 → presenter DTO/host → 实例详情页 MODS 区。
r1 复审后 rebase 到 main 71144df（M223 已合入），并修掉四条文档疵。

core（crates/core/src/addon/mods/）
- suffix：`.disabled` / `.old` 的**唯一判据**（四态枚举 + 展示名 + 双向改名目标名），
  收敛原先两份同构实现——`export/scan.rs::is_disabled_path` 与 `import/plan/paths.rs::suffix_variant`
  改为委派/再导出，签名与行为不变。
- list：单根语义（入口是 derive_game_dir 派生出的运行目录）列 `<run>/mods/`，不按扩展名过滤，
  符号链接/目录/怪名字逐条登记原因；`mods/` 本身是符号链接时拒（不跟随）。
- toggle：启停 = 在 `mods/` 里改名。五条守卫（裸文件名 / 目录可用 / 普通文件 / 不覆盖 / 不做
  copy+delete 兜底）+ 幂等；`.disabled` 只插在 `.old` 之前。

presenter
- dto/mods：ModsCommand / ModListView / ModFailureView（不拼文案，只给结构 + OS 原文）。
- host/mods：后台线程列目录与启停，运行目录走与启动同一份 D20 派生、不写任何设置；
  游戏在跑时 host 侧直接挡。
- state/mods：快照整体替换、迟到结果丢弃、在飞标记；`AppState::mods`。

app-iced（实例详情页）
- MODS 区（`pages/instances/mods.rs`）：名字 + 大小 + `.old` 徽标 + Switch；运行中/在飞只读。
- 进入详情页即后台列一次（不走 3 s 观察窗，避免打红 M192 的「空闲不烧帧」守卫）。
- MODS 卡排在启动参数**之前**（详情列是滚动区，排在后面 1180×1000 下永远看不见）。
- i18n：19 条中英文案（`catalog/instances.rs` + 金表）。

rebase 冲突解法（三个文件，全是"两侧同段新增"，都保留）：
- `i18n/catalog/instances.rs` + `i18n/catalog/golden.rs`：M223 的 Adopt* 段在前、M224 的
  InstancesMods* 段在后（= `Key::ALL` 顺序 = 金表顺序）。
- `presenter/src/state.rs`：`adopt` 与 `mods` 字段/初始化/apply_core 分支都留；`tiles()` 归
  `state/tiles.rs`（本分支搬的），`apply_agent`/`agent_rail_visible` 归 `state/agent.rs`
  （M223 搬的）——两处搬移不重叠，state.rs 里都不再出现。

r1 四条文档疵：
1. `pages/instances/mods.rs` 模块文档：挂载位置写反（"启动参数卡之后"→实际之前），并补上为什么；
2. `state/mods.rs`：引用不存在的 `CoreEvent::ModsChanged/ModsFailed` → 改成 `CoreEvent::Mods`
   + 文字说明 Ok 落快照 / Err 落具名失败；
3. `app/state/mods_shot.rs`：文档说"目录串取真实派生结果"但代码留空 → 改成"故意留空"；
4. `app/state/refresh.rs::note_mods_failure`：文档说"连点两次看见两次红字"与去重机制不符 →
   改成按 `(实例, 文件, 大类)` 三元组去重（防刷屏），换文件/换实例/换大类仍会再弹。

顺带（r1 已确认的 main 红）：`pages/download/options/view.rs:88-89` 两条
`clippy::doc_lazy_continuation` 只缩进修掉，文字未动。
 2026-11-10 21:09:37 +08:00
AskaEth 9ca5ee8ae7 docs(core): adopt 的两条文档小疵（r4 复审留的，M223 顺手修） 
- plan.rs 第 11-12 行：一个悬空半句（「…必须落在」后面断掉）补完，并把 fspaths 的引用接上；
- run_dir.rs 第 16 行：删掉「配置写面看 <.ULL>、并额外排除游戏根」这条**已移交**
  fspaths::ensure_surfaces_clear_of_game_tree 的职责描述，明说本模块只负责数据写面这一条。

纯文档，零行为变化。
 2026-11-10 19:37:43 +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 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 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 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 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 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 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 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 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 红线，按职责拆成两个测试文件
Guards / 依赖许可与来源（cargo-deny） (push) Canceled after 0s
Details
Guards / 文件行数 ≤400 守门 (push) Canceled after 0s
Details
Guards / unsafe 落点守门（集合必须恰好等于期望） (push) Canceled after 0s
Details
Guards / design 零第三方依赖守门 (push) Canceled after 0s
Details
Guards / presenter 零 UI 守门 (push) Canceled after 0s
Details
Guards / core 零 UI 守门 (push) Canceled after 0s
Details
Dev Guards / 架构与合规守门（同 main 口径） (push) Canceled after 0s
Details
Dev Guards / fmt (rustfmt --check) (push) Canceled after 0s
Details
Dev Guards / clippy (ubuntu) (push) Canceled after 0s
Details 
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 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 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 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 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
tower-worker 67a03f9402 M205 r1: 修 config.rs 的假话与「最坏 9」的措辞，UA 说明改成事实 
- download/config.rs: KEY_GH_PROXY 的「本文件没有断言把它与 schema 登记绑起来」是 M205 自己造出来的假话，改成指向 proxy.rs 的新用例（纯文字替换，400 行不变）
- addon/online/download.rs: 断言消息与边界段改说「出厂档 3x3 = 9；retry_limit 调到 N 时是 3xN（上限 10 => 30）」，别再让人把出厂值读成事实上限
- presenter/host/addon/http.rs: 「Modrinth 的请求走 get_via_engine」是错的（实际走 core::addon::online::EngineTransport -> download_bytes，带的是引擎 UA；get_via_engine 今天只有单测在用），改成事实
 2026-11-09 11:20:27 +08:00
tower-worker d4aa3b23f4 M205: gh-proxy 键绑定断言、外层重试预算判据、UA 版本号来源、下载设置文档更正 
- setting/keys/proxy: 新增断言把 KEY_GH_PROXY 常量与 schema 登记绑起来（键名 / Text{max_len:256} / 默认空串）
- addon/online/download: RETRY_ATTEMPTS 与引擎每源次数是两件事（层级相乘、管的失败类型不同），写清判据并用两条编译期断言钉住 3 与 3x3=9 的边界
- presenter/host/addon/http: UA 版本号改为从 CARGO_PKG_VERSION 拼出，补断言钉住版本 == CARGO_PKG_VERSION 且联系方式段不丢
- docs/download-settings: §3.1 四条 CLI 命令都吃设置（update 是自更新路径），§6 补 M11-M13 三条 CLI 变异，§1/§7 里 gh_proxy 已合入的事实
 2026-11-09 11:12:59 +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 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 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 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 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
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 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 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