AskaEth/Unlucky-Launcher
1
0 Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
457 Commits 3 Branches 5 Tags
add7f2e67242aeec7cbd4cda4086cbb55d5d9bce
Commit Graph
25 Commits
Author SHA1 Message Date
AskaEth add7f2e672 test(m170): 改对复审点出的两处证据陈述 + 收紧用例前提（零行为改动） 
r1 复审 p2-2items（守卫本身判 clean，四条变异自跑确认有牙）。这一轮**只动注释与测试
前提，产品行为零变化**：`format/write.rs` 一字未改，`probe.rs` 保持上一提交的收窄结果。

p2-1 复审核正的事实：`one_file_over_the_threshold_...` 的 `kind()` **不区分闸的位置**。
它的源是**可读的** 8 KiB 真文件，闸被挪到 `File::open` 之后时写循环第二道闸
`Written::spend`（每块之后 `guard_with`）照样返回 `Limits`——所以它在「闸挪位置」的
变异下仍然绿（我这轮重跑变异 A 也复现：其余 4 条全绿）。原来那句「源文件能读时这里
拿到的是 pack_io」是错的，改成「可读源命中第二道闸」并把顺序的举证责任明确交给
`the_gate_runs_before_any_content_is_opened`。

p2-2 目录长度的实测数字之前钉错了：我早先那条探针用的是**短名**（`f0`..`f39`，7 条
才到 4096、40 条仍 4096），而用例里填的是 `filler-NN`。这轮按用例真实形状重测三组
（`std::fs::metadata`，同一台机器同一 `%TEMP%`）：
  短名 `f0`…`f39`：空 0 ｜ 3 条 0 ｜ 7 条 4096 ｜ 20/32/39/40 条 4096
  `filler-NN`：    空 0 ｜ 3 条 4096 ｜ 7 条 4096 ｜ 20 条 8192 ｜ 32 条 8192 ｜ 39 条 12288 ｜ 40 条 16384
两次独立跑同形状结果一致。所以「第几个条目起非零」没有平台无关答案（NTFS 目录索引按
4 KiB 一档分配，跟条目名长度与条数都有关），三处注释改成区间 + 一张实测表，并注明
「只钉 32 个 `filler-NN` 这个形状（本机 8192）」，不再硬凑一个好看的数字。

顺带做掉复审那条「不计入 p2 但建议收紧」：前提从 `declared > 0` 提到
**`limit > 清单 JSON 长度`**（`limit = declared.saturating_sub(1)`，`json_len` 由
`CURSEFORGE.render(&manifest)` 现算，本用例实测 220 字节）。否则某个对 32 个条目报得很
小的文件系统会让用例因「清单自己越线」而假绿。同时把 `declared - 1` 换成
`saturating_sub`，让长度为 0 时走到清楚的 assert 文案而不是整数下溢 panic。
把 `DIR_LENGTH_FILLERS` 临时改成 0 验证过这条 assert 是活的：红在这句上
（`声明长度 0 − 1 = 0 … 必须大于清单 JSON 自身长度（220）`）。

变异复跑（本机 Windows/NTFS，跑完已还原 write.rs）：
- A：`preflight` 挪到 `File::open(&source)` 之后 → 新用例**红**（left Io / right Limits），
  其余 4 条仍绿（含上面那条可读源用例，正好印证 p2-1 的更正）；
- C：A 之上只留 `expect_err` / `!target.exists()` / `leftovers` → **5 条全绿**，
  结构断言确属同义反复。

门禁：`cargo test -p unlucky-core --lib` 613 passed / 0 failed / 0 ignored；
`cargo fmt --all --check` 干净；`cargo clippy -p unlucky-core --all-targets -- -D warnings`
干净；zip64.rs 345 行（<400）、probe.rs 45 行。
 2026-11-08 10:39:28 +08:00
AskaEth 72767067f3 test(m170): 闸顺序用例在 Windows 上也真跑（声明长度自己造 + 反证） 
M166 r2 复审的两条「合并后收口」观察：

① `zip64::the_gate_runs_before_any_content_is_opened` 原来量夹具目录的
   `metadata().len()`，量到 0 就 `return`——而本机 NTFS 上空目录就是 0（实测：空 0、
   第 7 个条目起 4096），于是这条「行为证明」在 Windows 上一条断言都没执行。
   现在：先把目录填到长度非零（32 个 filler），拿「声明长度减一字节」当总量上限，
   前提不满足就 `assert!`；单条目上限给 `u64::MAX`，不让 `guard_entry` 当替身。
   另加一条**反证**：同一份夹具把限额放到 `u64::MAX`，必须死在 `File::open`/`read`
   上拿到 `pack_io`——于是上面拿到 `pack_limits` 只能解释为「闸在碰内容之前」。
   同时更正 `one_file_over_the_threshold_...` 里那句过头的注释：`leftovers` /
   `!target.exists()` 在任何失败路径上都成立，属结构侧检，不是「没读一个字节」的证明。

② `probe.rs` 的模块级 `#![allow(clippy::missing_const_for_thread_local)]` 收窄到
   `thread_local!` 内那个 `static` 上（A/B 实测：没带的那组只报一条 lint，带了就干净，
   且不判 unused），模块级 allow 不再替未来的真漏 const 打掩护。

变异验证（本机 Windows/NTFS，跑完已还原）：
- 预检挪到 `File::open` 之后 → 本用例红（`left: Io` / `right: Limits`），改前那版全绿；
- 预检改成用 `std::fs::read` 量尺寸 → 同样红；
- 只留结构断言（拆掉 kind/文案/反证）→ 同一变异下**全绿**，证明它们确实区分不了顺序。
 2026-11-08 09:54:31 +08:00
AskaEth 9b23221a62 test(m166): 钉住生产 write() 的限额绑定（复审 r1 p2-1） 
复审 r1 的变异：把 `format.rs` 里 `write()` 传给 `write_with_limits` 的
`WriteLimits::production()` 换成 `WriteLimits::new(u64::MAX, u64::MAX, entries)`，
**606 条全绿**。原因是夹具缩到 KiB 之后，"生产路径 + 真超限内容"那种顺带守住生产
限额的证法没了，而 `the_production_limits_are_the_shared_constants` 只钉了
`production()` 的**返回值**、没钉 `write()` 的**调用点**。

补法（不动生产签名、不进发布构建）：
- 新增 `format/probe.rs`（`#[cfg(test)]`）：线程局部的限额记录钩子；
  `write_with_limits` 进门时 `#[cfg(test)] probe::record(limits);` 记一笔。
- `tests/limits.rs::the_production_write_path_hands_the_shared_constants_to_the_preflight`
  走**生产**的 `CURSEFORGE.write`（KiB 级 payload）后断言记到的就是
  `WriteLimits::production()` 的逐字段值，并再钉一遍统一常量。
- 反向验：上述变异现在恰好 1 条红（`总量限额：生产路径传错了`，2026-11-08 实测
  18446744073709551615 vs 536870912）；只把 entry 换成 u64::MAX 也红（`单条目限额`）。

附带（复审非阻断观察）：
- 观察 2 采纳：新增 `zip64::the_gate_runs_before_any_content_is_opened`，把"闸在读之前"
  从结构证明升级成行为证明——源做成**目录**（`metadata()` 有长度、`File::open` 拒绝访问，
  本机实测 C:\Windows 20480 字节 / crates/core/src 4096 字节），闸若挪到读之后会拿到
  `pack_io` 而不是 `pack_limits`。
- 观察 1 采纳：`tests/limits.rs` 里"改坏常量会在 cargo check 就红"的旧注释改成准确说法
  （E0080 只在测试构建出现，裸 `cargo check` 是绿的）。
- `probe.rs` 里 `#![allow(clippy::missing_const_for_thread_local)]`：clippy 1.99 对已经
  写成 `const { Cell::new(None) }` 的 `thread_local!` 仍报错（最小复现同样红），是误报；
  外挂在宏上的 `#[allow]` 会被判 unused attribute，故用模块级 inner attribute。

cargo test -p unlucky-core --lib：608 passed / 0 failed / 0 ignored（+2 条）；
clippy --all-targets -D warnings、fmt --check 干净；全仓 0 个 >400 行文件。
 2026-11-08 09:30:26 +08:00
AskaEth 49a2fafe51 test(m166): zip64 夹具改用小 limits，去掉 8.5 GiB 真落盘 
`set_len` 造的所谓稀疏文件在 NTFS 上并不稀疏：实测 `SetLength(1 GiB)` 之后
C 盘可用空间正好掉 1024 MiB。于是 `zip64.rs` 那两条用例的声明尺寸
（`u32::MAX + 1` ≈ 4 GiB 加 `3 × 1.5 GiB` = 4.5 GiB）就是 8.5 GiB **真占用**，
再加上 `write/tests.rs` 的 3 GiB 与 `limits.rs` 的三条 64 MiB 级用例，
单次跑的落盘峰值到过 ~12 GiB。

判据本身跟夹具大小无关（吃的是 `metadata().len()`），所以把 limits 做成参数：
`format::write_with_limits` 是 `PackFormat::write` 的实体，生产路径仍只传
`WriteLimits::production()`，测试传 KiB 级小值走**同一条** `preflight` 分支。
`WriteLimits` 的可见性顺势开到 `pub(in crate::addon::pack)`。

GiB 级的**数值判定**搬进 `format/write/tests.rs` 的纯算术用例：>4 GiB（撞 ZIP64
阈值即拒、差一字节放行）与 >2 GiB（M152 那个 2.5 GB 样本现在按统一上限拒），
以及第二道闸 `Written` 在同一批数值上的行为——两道闸吃的都是 u64，不需要落盘。

断言一条没删、用例一条没新加 `#[ignore]`（反而把旧的那条 `#[ignore]` 的
2.5 GB 用例换成会跑的 KiB 级版本，补上 `guard_entry` 分支的端到端覆盖）。

扫描：`grep -rn 稀疏 crates/ packaging/ docs/` 里凡写着"稀疏文件不占磁盘"的
注释一并改成实测口径（含 `addon/temp.rs`），避免下一个人照着再踩一次。
 2026-11-08 09:30:26 +08:00
AskaEth 46389d61fd feat(m165): 下载引擎按数据根跨请求复用（运行时常驻 + 构造次数守卫） 
宿主侧以前每次请求都现建一个 DownloadEngine：连接池、信号量限流、
健康度记忆、内容寻址缓存索引全部清零。现在改成按数据根共享一个实例。

- core: 新增 download::shared（进程级登记处，键 = 缓存根）——
  engine_for / forget / constructions；region/health/cache/mirrors 的装配
  收在这一个 build() 里（持锁构造只做本地 I/O，不联网）
- core: download::blocking 改成进程内唯一常驻运行时。reqwest 的连接池绑在
  驱动连接的运行时上，引擎复用必须配运行时常驻，否则复用的是个装满死连接的池
- presenter: host::engine::engine 返回 Arc<DownloadEngine>（共享实例），
  addon/update/versions/java/authlib 等全部调用点随之改；新增 forget 供
  「重新检测地区」失效（否则进程级引擎下那句话不成立）
- presenter: addon 详情页把「项目 + 版本列表」两次 block_on 收成一次

失败分类 / 镜像回退 / Retry-After 语义未改动（error.rs、http.rs、engine.rs 的
候选循环一字未动）。

守卫（都带变异实证）：
- shared::tests::one_engine_per_cache_root + host::engine::tests::
  host_requests_share_one_engine：断言 constructions(root) == 1（不是只看结果）
- shared::tests::pooled_connection_survives_across_block_on_calls：127.0.0.1
  回环服务统计 accept 次数，两次 block_on 必须只拨号一次

验证：cargo test -p unlucky-core --lib（608 过）、5 个 download 集成 target（42 过）、
cargo test -p unlucky-presenter --lib（267 过）、cargo clippy --all-targets、
cargo fmt --check 全绿。真站点（Modrinth/CurseForge/BMCLAPI）未打，见报告。
 2026-11-08 09:30:05 +08:00
AskaEth 47ed270293 fix(m162-r3): 金表条数与内容同源（堵住「少挂一段仍绿」的假绿）+ 补两条覆盖缺口 
P2-1（r3 抓到的假绿）：`golden::len()` 从「各段 len() 相加」改成 **`rows().count()`**。
r3 实测的变异是：删掉 `rows()` 里的 `chain(tail2::ROWS)` 后 `split_keeps_every_translation`
仍绿——因为条数来自一处手工聚合（仍含 tail2 ⇒ 459 == `Key::ALL.len()`）而内容只遍历
`rows()`（少了 213 行）。现在条数与内容同源，漏挂一段当场对不上。
- 变异复现（删 chain）：`rows().count()=246 len()=246 Key::ALL.len()=459` ⇒ 用例
  **FAILED**（`left: 459 / right: 246`，「key 条数与拆分前不一致」）；
- 恢复后：`rows().count()=459 len()=459 Key::ALL.len()=459` ⇒ **ok**；
- 断言一字未改（没有放宽成「只比条数」或「只比前缀」）。

顺带三条：
1. `golden.rs` 的 `rows()` 文档补上 `tail2`（并写明「加段必须也 chain 上，条数与内容只能从
   这一条序列导出」），与上一条同族。
2. `online/mod.rs` 模块表里 `[complete]` 的职责改成「按摘要认文件（`identity_of`）」，
   与「补全循环已删、生产在 `import::complete`」一致；批量 POST 那段也点明循环位置。
3. 补两条 pack 用例走不到的覆盖（`import/complete.rs` 的 `#[cfg(test)] mod tests`）：
   - `an_entry_without_sha512_is_counted_not_guessed`：有 path、有 downloads、无 sha512 ⇒
     `unfilled += 1` **且一次请求都不发**（mrpack 读者强制 sha512，这条是防御分支）；
   - `an_existing_download_list_is_never_extended`：已有直链时 `downloads` **逐字相等**
     （长度 + 内容），不再用「包含」这种测不出重复追加的断言。
   两条都验过能红：把「缺 sha512 不计数」与「总是追加直链」同时变异 ⇒ 两条 **FAILED**；
   恢复后 **ok**。

登记项（r3 指出的 scan 注记）也顺手收了：`Completion::note` 在 `filled == 0` 时改说
「按 sha512 从 Modrinth 补全 sha1：一条也没补到（补不出 N 条）」，并且不再带
「其余条目照旧按『缺省保留』处置」（那是导入场景的尾缀，预检里没有这回事）。用例
`offline_with_nothing_filled_does_not_say_zero_items_were_filled` 与
`import_online::only_a_real_offline_stops_the_completion_round` 都钉住「真断网 + 一条没补到」
既不说「补全了 0 条」也不说「缺省保留」。

全仓行数（guards.yml::file-size 同口径）：**0 个超限**。
 2026-11-07 17:37:13 +08:00
AskaEth ecd24f0608 fix(m162-r2): 金表沿用主线的拆分边界 + phase/pipeline 回到 400 行内 
金表（rebase 到 M161 后重写这一段）：**采用 main 的拆分边界**——`golden/tail.rs`
（`InstancesLaunchReset` 之后、`PackTargetNew` 之前）+ `golden/tail2.rs`
（`PackInstanceName` 之后），不再保留本分支原来那套 205/221 的切法。
本分支新增的 6 条 key（`ContentOffline{Title,Body}`、`ContentDetail{Fetching,FetchFailed,
VersionCount,VersionLine}`）按 `Key::ALL` 的顺序并入 main 的 `tail.rs`；
`golden.rs` 的 `rows()` 保持 `GOLDEN + tail + tail2` 三段串联。（`len()` 与内容同源的修正
在下一个提交里。）

其余两处（本来就是我推过线的，现在回到红线内）：
- `import/phase.rs` 397 → **400**：只动注释（`Resolved` 的两个摘要字段共用一句、
  `resolve`/`settle` 的文档各并一行），代码语义零改动。
- `import/pipeline.rs` 399 → **400**：把补全注记（14 行）搬到 `import/complete.rs` 的
  `Completion::note(lead)` 旁边，管线只剩一行 `complete_and_note(...)`；
  `scan_pack_online` 也改用同一个 `note("预检前")`——注记文案由两处变一处。

同时删除与 `import/complete.rs` 重复的 `online::complete::{complete_files, CompletionSummary}`
（生产零调用方），只留生产在用的 `identity_of`。
 2026-11-07 17:37:13 +08:00
AskaEth b394316df4 fix(m162-r1): 叶子成因穿出引擎 + 安装路径切 core 在线源 + 详情迟到结果闸门 
P1-1（p1-1items 的根因）：
- download/error.rs：`DownloadError` 增 `leaf: Option<DownloadErrorKind>` 与
  `effective_kind()`；`leaf_of()` 汇总规则只此一处：全 404 ⇒ NotFound、有
  Network/Timeout ⇒ Network、全 5xx ⇒ ServerError、混合按「网络错 > 5xx > 404」
  取最可诊断的那个（**不从 suppressed 文本猜状态码**）。
- download/bytes.rs：候选源循环收集逐源 kind，收尾时把叶子挂到 AllSourcesFailed 上。
- online/transport.rs：`From<DownloadError>` 改用 `effective_kind()`，于是
  NotFound/Server/Integrity 在生产路径可达（项目被删/id 拼错/限速不再画成「未联网」）。
- import/fetch.rs：新增 `FetchErrorKind::Offline`（真正的「没联网」）并与 Network 分开；
  `From<DownloadError>`/`From<OnlineError>` 都按叶子/大类映射。
- import/complete.rs：补全只在 `Offline` 时早停；404（真实 mrpack 大多托管在 CF CDN，
  Modrinth 必然 404）与 5xx 只影响那一条，不再掐掉整轮；注记「因未联网提前停止」因此
  只会在真断网时出现。

P2-1：presenter 安装路径不再自己拼 Modrinth URL / 自己解析 JSON——改用
`core::addon::online::Modrinth::versions` + `primary_file()` + `VersionFile::sha1/sha512`；
`HostTask::InstallDone.result` 改成 `Result<String, ContentFailure>`，
`InstallProgressView` 增 `failure_kind`（离线 ≠ 查无此项）。

P2-2：`app/update/content.rs` 把被详情方法抢走的「装入闸门」注释还回
`content_install_request`，详情方法只留自己那一行。

P2-3：`ContentState::apply_detail/fail_detail` 带上 project（事件与 HostTask 都携带请求时的
项目 id），迟到结果一律丢弃；`request_detail` 记下在飞项目，`detail_pending` 不再被迟到
结果清掉。

顺手项：`usable_hash` 让形状非法的那一档摘要被**丢弃**（sha512 仍校验，不再整条跳过；
两档都不可用才拒绝）；`digest_file` 的 IO 失败先删落盘文件再返回。i18n 的
ContentOfflineBody 改成不暗示「有缓存」的措辞（golden 同步）。

用例：download/error.rs 叶子四档 + effective_kind；online/tests/classify.rs 5 条
（AllSourcesFailed+leaf 404 ⇒ NotFound、无叶子 ⇒ NotConnected 保守、叶子一一映射、
单源自身 kind、导入侧 404≠Offline）；import_online 增「404 不停」「真离线才停」
（共 7 条）；download 增「sha1 形状非法仍用 sha512 校验成功」；presenter 增详情迟到闸门。
 2026-11-07 17:28:36 +08:00
AskaEth 81278f55af feat(m162): Modrinth 在线内容源（匿名）+ 远端条目按 sha512 补全 + 离线态 
core：新增 addon::online —— 按 Modrinth v2 真实形状建模（search facets / project /
project versions / version_file by hash），网络出口只有 Transport 一个 trait，生产实现
EngineTransport 走既有 DownloadEngine::download_bytes（零新依赖）；错误分大类，网络类
失败映射成 NotConnected（= 未联网），不再用空列表冒充「没有结果」。

core：online::download::download_verified —— sha1 交给引擎流式校验、sha512 落盘后复核
（download::HashAlgo 没有 Sha512，改它超出 scope，已登记 finding），不符/失败删文件重试，
最多 3 次尝试且不留半截文件。

core：远端条目补全 —— PackFetcher::modrinth_file_by_sha512（默认 Unsupported = 补不出），
import 管线与新增的 scan_pack_online 都会在「有 path 但缺 hashes.sha1」时按 sha512 反查；
补出的 sha1 走 M160 同一套 judge 与合并判定，补不出仍进 unknown_remote 计数（口径未改）。
DownloadEngineFetcher 改用 download_verified，FetchRequest 增 sha512。

presenter：Modrinth 检索/详情改由 core 的 online 客户端提供（不再自己拼 URL、不再读错
date_modified）；ContentFailure{kind} 取代裸字符串，无网 = Offline；新增
ContentDetailRequest/ContentDetail + LoadContentDetail 命令与 CoreEvent::ContentDetail 通道；
预检改走 scan_pack_online；内容库安装也走 download_verified（sha1+sha512）。

app-iced：Status::Offline 独立一态（未联网 ≠ 空列表 ≠ 普通失败），详情面板消费新 DTO
显示可用版本；选中项目即拉详情。i18n 新增 6 个键并同步金表。

测试：online 模块 24 个离线用例（录制 JSON + 假字节：搜索/详情/版本/按摘要反查/校验失败
即删/重试/离线分类/补全），import 侧 6 个（离线计数不变、补全后判冲突、补错摘要 ⇒ Failed），
presenter/app-iced 各补失败分类与详情状态机用例。
 2026-11-07 17:28:36 +08:00
worker-modpackpick d568cc6f37 fix(m160-r1): 预检失败不再静默空转 + 写侧条目数闸 + 判据归一 + 冲突页对齐 
复审 reviewer-modpackpick-r1（p2-1items / fix-then-merge）的返工。

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

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

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

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

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

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

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

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

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

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

证据：cargo fmt --check 干净；cargo clippy --workspace --all-targets -D warnings 干净；
cargo test --workspace --all-targets -j 4 → 2507 passed / 0 failed（51 个 test binary）。
 2026-11-07 13:52:43 +08:00
AskaEth be280c16a3 fix(core): ZIP64 第二道闸不再重复累计预检总量（复审 P2-1） 
复审在 tip 54c2d75 上实证的缺陷：`container()` 把 `preflight()` 返回的**全量**声明尺寸
当成写循环累加基数，循环里又对每个文件 `+= bytes.len()`，于是真实总量只要过半阈值
（~2.15 GiB）就被误拒，而且拒在内容读出来之后——"闸在内容进内存之前"的性质同时失效。

两处修：
1. 记账拆成独立类型 `Written`，**从清单 JSON 长度起算**，与预检返回值无关；预检的返回值
   现在只给测试与诊断看（`let _ =`，文档写明不许当基数）。
2. 内容改成 1 MiB 缓冲流式写进 zip（`COPY_CHUNK`），不再 `std::fs::read` 整份摊在内存里。
   第二道闸看的是"已写字节数"，与内存占用解耦；顺带把"拿预检 total 当基数"这类写法
   在内存侧也变成无害的小错而不是几个 GiB 的读。

测试（按塔台资源令，默认套件不再真写 2.5 GB）：
- `write.rs` 新增 `the_container_does_not_double_count_the_preflight_total`：把阈值注入成
  几十字节（`container`/`preflight`/`Written` 都收 `limit`，生产路径恒为
  `zip::ZIP64_BYTES_THR`），构造"正确实现 70 < 90 通过 / 重复累计 110 ≥ 90 被拒"的窗口，
  **0.01 秒**钉住 P2-1；实测把 bug 写回去即红。
- `write.rs` 新增 `the_second_gate_counts_from_the_manifest_length_not_the_preflight_total`：
  直接对 `Written` 断言 2.5 GB 不拒、撞阈值必拒。
- `zip64.rs` 的 2.5 GB 稀疏文件端到端用例保留但 `#[ignore]`（真跑要 ~70 秒 deflate 与一大片
  内存/页面文件，C 盘页面文件已被上一轮撑到 34.8G），实测过一次成功：条目声明尺寸原样
  2 500 000 000、产物只有几 MB。跑法写在该用例的文档里。

门禁：fmt 0 / clippy -p unlucky-core --all-targets 0 / cargo test -p unlucky-core 1033 passed
0 failed（lib 480 passed + 1 ignored）。
 2026-11-07 08:22:47 +08:00
AskaEth d728ed836f feat(core): M152 整合包收尾——同路径遮蔽逐文件上报 + ZIP64 拒写预检 
导入侧把「同名文件冲突」从整包一个策略推进到逐文件事实：同一实例路径被本包多份声明
命中时（跨侧 overrides/client-overrides，或同侧重复），按叠层顺序（Both → Client）定
胜者，其余标 PlanOverride::shadowed（winner / winner_dir / same_bytes），逐条留
pack.import.note.override_shadowed 注记；phase 只遍历未被遮蔽的条目，不再白读字节，
报告里也不再出现"两条 Installed、前一条的哈希其实没落地"。

不新增 FileAction/ConflictReason 变体：这三个枚举被 crates/presenter 的 convert.rs
穷尽 match，而那个 crate 不在本 purpose 的作用域内，所以走既有的 ImportIssue 通道
（与 server-overrides/ 被跳过同一条）。

导出侧那条 ZIP64 闸原来够不着：先 std::fs::read 整个覆盖文件进内存再累加判断，真要
导出 4 GiB 文件的实例，内存先炸、用户永远看不到那句 pack_limits。改成写前按
metadata().len() 做声明尺寸预检，超阈值在任何字节进内存之前就报；写循环里的增量检查
留作第二道。写 zip 的实现搬到 format/write.rs 以守 400 行。

测试：pack/tests/zip64.rs（稀疏文件真跑到 ZIP64 分支，含累计口径与对照）、
tests/import_layering.rs（同路径不同哈希 / 同哈希不同路径 / 叠层顺序 / 基线记胜者）、
unknown_fields.rs 补第 4 条假边（mrpack files[].extra + 未知哈希算法）。
五条变异各自变红（遮蔽 no-op 6 红、按哈希判重 6 红、翻转叠层 2 红、错误码改 io 3 红、
预检不累计则预检单测红且端到端用例从 0.01s 变成 95s/约 4.5 GiB 内存）。
 2026-11-07 08:22:47 +08:00
AskaEth f6b7759aa8 docs(m126 r3): 收窄「唯一一份」的说法，并把 ③ 的承诺改成真话 
纯文档，零逻辑改动（`git diff` 里每一行都是 `//!` / `///`）。

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

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

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

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

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

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

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

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

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

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

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

file 行数：core/game/loader.rs 337→399（≤400 硬约束，文档按密度重排、事实未丢）。
 2026-11-05 18:08:56 +08:00
AskaEth 90b233088f feat(core): M112 整合包导出（mrpack 优先 + CF 清单，逐文件远程判定与内联兜底） 
新增 addon::export（实例目录 → .mrpack / CF manifest.json）：
- 逐文件三分：远程引用 / 内联进 overrides/ / 跳过（读不了、符号链接、路径不安全）。
  「能否被远程替代」= 目录能证明身份（Modrinth SHA-1、CF 指纹）**且**目标格式表达得了；
  证明不了的一律内联，绝不丢、绝不编，逐条进结构化报告（ExportReport）。
- game / dependencies 来自实例快照：versions/<id>/<id>.json 的继承链「叶子」+ 库坐标推加载器，
  不解析 <mc>-<loader>-<ver> 字符串（社区实例名不统一，那是猜）。
- .disabled 走路径后缀（不是 env.client=optional：后者装回来默认启用，跨启动器不保真）。
- CF files[] 只写能确定 projectID/fileID 的项；禁用文件 CF 表达不了，内联并记原因。
  CF modLoaders[].id 按官方写法：NeoForge 在 1.20.1 上写 neoforge-1.20.1-<ver>。
- 尺寸护栏：fileSize 超 u32 报 pack_limits；整包撞 ZIP64 阈值由 format::write 拒绝。

配套改动：
- pack/curseforge/fingerprint：MurmurHash2-32 + 0x09/0x0A/0x0D/0x20 过滤、seed=1、
  长度用过滤后长度、哨兵 811513880 短路；金标准由一份独立 Java 实现算出（双向验证）。
- pack/format/payload：PackPayload 加 with_sources（包内条目名 → 实例源文件），
  让「实例里的 mods/x.jar → 包里的 overrides/mods/x.jar」不用拼路径。
- pack/format：写盘时按未压缩总量守 ZIP64 阈值。
- pack/modrinth：禁用位改写路径后缀；fileSize 按 u32 校验。
- pack/manifest：PackLoader::curse_id_for 处理 NeoForge 的 MC 前缀特例。

测试：导出管线 10 条 + 往返保真 4 条（三种格式夹具；允许的差异逐条在测试文件头登记，
并在报告 notes 里给出）。M111 未合并，故本轮「导入」用 M110 的 read + 同形实例目录，
真 import_pack → export → import_pack 端到端留作欠账。
 2026-11-04 21:32:37 +08:00
AskaEth 29f531db23 fix(addon): M111 r6 —— 失败文案按 rolled_back 分叉，补「回滚不完整」报告级用例 
复审 r6 的两条（都在同两个文件里十来行）：

1. 文案位自相矛盾
- 改前：`pipeline::failed()` **无条件**推「目标目录保持导入前的样子」，`record_rollback()`
  随后可能再推「有 N 项未能回滚（目标目录可能与导入前不同）」——同一份 warnings 自相矛盾；
  CLI `status_label` 也恒写「失败（已回滚）」。
- 改后：`failed()` 只落错误、**不宣称目标目录状态**；口径拆成两个具名入口——
  `abandoned()`（失败发生在碰目标目录之前，才说「目标目录未被写入」）与
  `record_rollback()`（完整 ⇒ `rolled_back=true` + 「恢复为导入前的样子」；不完整 ⇒
  `rolled_back=false` + 逐项列失败项）。CLI `status_label` 按 `rolled_back` 分叉成
  「失败（已回滚）」/「失败（回滚不完整）」；`keys.rs` 的状态文档与 pipeline 模块文档表
  同步改口径。

2. 新接线零测试（这是 fix-then-merge 的理由）
- 新增 `pipeline::tests` 三条报告级用例：
  `incomplete_rollback_never_claims_the_target_is_untouched`（`rolled_back=false` + warnings
  逐项列出 + **不含**任何「保持导入前的样子 / 未被写入 / 恢复为导入前」）、
  `complete_rollback_claims_consistency_exactly_once`、
  `pre_commit_failure_claims_untouched_only_via_abandoned`。

变异自证（本轮实测，均已还原）：
- A：把 `record_rollback` 的分叉整体跳过（no-op）→ 2 条红（`失败项要逐条列出：[]`、
  `assertion failed: report.rolled_back`）。
- B：把 `failed()` 恢复成无条件推「保持导入前的样子」→ 2 条红，报错原文即自相矛盾现场：
  `["…目标目录保持导入前的样子…", "有 1 项未能回滚（目标目录可能与导入前不同）…"]`。
 2026-11-04 21:19:58 +08:00
AskaEth 7f657d225c fix(addon): M111 r5 —— 基线读写同源（.ull）、plan.rs 拆回 400 内、中间产物/回滚/包身份 
复审 r5 两条 P1 + 三条 P2。

P1-1 基线读、写走了两条路径（ext4 上是两个文件，Windows/macOS 上假绿）
- 写侧 pipeline 用 `LAUNCHER_HOME_DIR`（`.ULL`，启动器**数据根**的名字），读侧
  `PackBaseline::path()` 用 `GameLayout::ull_root()`（`.ull`，实例**游戏根**内的私有目录）。
- 现在读写都从 `ull_root()` 派生：`PackBaseline::path()`（绝对）+ 新增
  `PackBaseline::relative_path()`（相对，空根求 `ull_root()`），pipeline 的
  `baseline_relative()` 只做 `/` 分隔，不再出现第二份目录名字符串；`LAUNCHER_HOME_DIR`
  的引用从导入链路里删掉。
- 新断言 `baseline_read_and_write_paths_are_the_same_file`：`path(root) ==
  root.join(relative_path())`、`read.parent() == ull_root()`、写侧字符串不含 `.ULL`
  （路径比较是大小写敏感的，所以在大小写不敏感的系统上也抓得住）。
- 选 `.ull` 的理由：基线住在**实例的游戏根**里，那是 `GameLayout` 的地盘（且
  `crates/core/tests/game/layout.rs:45` 早已钉死 `.ull`）；`.ULL` 是 portable 模式下
  exe 旁边的启动器数据根（`config/ data/ cache/ logs/`），层级不同，不能混用。
- 同时清掉 4 个测试里手抄的 `.ULL/pack-baseline.json`，改用 `baseline_rel()`。

P1-2 `import/plan.rs` 401 行撞穿 file-size 守门
- 把 `suffix_note()`（后缀注记）连同它的单测搬进 `plan/paths.rs`（那里本来就有
  `suffix_variant`），plan.rs 401 → 373；paths.rs 119 → 157。没有压注释换行数。

P2-1 引擎中间产物会被当成内容提交
- `Staging::purge_engine_artifacts()`：提交前递归剔除 `.ullpart-*` 与 `.ullmeta.json`
  （判据 `is_engine_artifact`，后缀取自 `core::download::atomic`），删掉的个数进报告注记。
- 测试：`StubFetcher::with_engine_artifacts()` 像真引擎那样在每次"下载"后留下残片，
  断言实例目录里没有任何 `.ullpart` / `.ullmeta`。

P2-2 回滚失败被 `let _ =` 吞掉
- 新增 `RollbackOutcome { attempted, failed }`：`rollback_merge` 逐项记账，
  `CommitGuard::rollback()` 返回它，提交阶段失败时 `CommitFailure { error, rollback }`
  把两者一起交回调用方；`ImportReport` 新增 `rollback` 字段，`rolled_back` 改成
  "回滚完整 / 从未写过目标目录"才为 true，不完整时 `false` 并在 warnings 里列失败项。
- CLI 人读输出相应分叉（`回滚未完整：N 项没回去`），不再无条件宣称一致。
- `Drop` 那条兜底路径仍拿不到调用方（文档写明是"防漏"不是"承诺"）。
- 单测：`complete_rollback_has_no_failures` 与 `rollback_failures_are_reported_not_swallowed`
  （用非空目录占住目标位置，让 remove/rename 都失败，跨平台确定）。

P2-3 基线不校验包身份
- `PackBaseline::matches_pack(format, name)`：同一目录先后导入两个包时，别人的基线一律
  不拿来当 base（否则"用户改过"会被误判成"整合包升级"而静默覆盖），降级为"无基线"并
  记 `pack.import.note.baseline_pack_mismatch`。
- 测试 `baseline_of_another_pack_is_not_used_as_base`：断言告警 key + 冲突降级为
  pre_existing + 用户内容保留。

门禁（落盘读 $?）：fmt 0 / clippy(workspace,all-targets,-D warnings) 0 /
test -p unlucky-core 0（363 lib）/ test --workspace --exclude unlucky-app 0（1993 passed）。
改动文件最大 373 行。core 依赖表未动（core-no-ui 不受影响）。
 2026-11-04 20:54:05 +08:00
AskaEth 4760714743 feat(addon): M111 整合包导入管线（CF / mrpack / MultiMC）+ ull pack import 
接 M110 的 pack 模型与安全闸，做导入：三格式 → 实例目录，落 D10 §2 三条硬要求。

core（`addon::import`）：
- 三方合并：`merge::decide` 判据表（磁盘 × 基线 × 包内），base 侧落在
  `<实例根>/.ULL/pack-baseline.json`；无基线时磁盘同名文件算用户已有内容 ⇒ 不覆盖。
  冲突逐条进报告（user_modified / user_deleted / pre_existing + 可选处置）。
- 两阶段：先 overrides 再补远端；失败分级只有一条判据（是不是"某个文件搞不到"）：
  缺文件 ⇒ Partial；穿越/符号链接/限额/清单坏/摘要不符/IO ⇒ Failed 且整包回滚。
- 事务：`Staging` 临时目录 + `CommitGuard`（全新导入 rename 整目录、合并态 journal 逆序
  回滚、Drop 即回滚），基线作为最后一个暂存文件同生共死。
- 三格式语义：mrpack `client-overrides` 胜 `overrides`、`server-overrides` 不解压；
  `.disabled`/`.old` 按路径后缀识别并原样保留；MultiMC `formatVersion != 1` 整份拒绝、
  非加载器 component 逐项进报告；CF `classId` 认不出就不猜。
- 加载器只做翻译（`LoaderTarget`：kind + 原版 + 加载器版本 + 版本 id，含 CF NeoForge
  `1.20.1-47.1.106` 的 MC 前缀剥离），网络全部经注入的 `PackFetcher`
  （生产实现 `DownloadEngineFetcher` 只走 core::download，无第二个 reqwest client）。
- 报告：三态 + 逐项原因 + 稳定文案 key 表（`report::keys`，含 ALL 守门表）。

CLI（`ull pack import <file> [--target] [--name] [--overwrite] [--no-register]`）：
- 退出码三态 0 / 3 / 1（`Outcome::exit_code` + runner 透传，其它命令仍 0）；
- `--json` 恒有信封（`data.status` / `data.error.code` / `data.stages`），Failed 不抛栈。

测试：29 条 core（三格式端到端、合并 6 条、必须先失败 8 条含双检互补样本与确定性
提交失败回滚、报告契约 5 条）+ 5 条 CLI（三态退出码、JSON 契约、既有命令回归、help）。
fmt / clippy(core+cli, -D warnings) 绿；文件全部 ≤400 行。
 2026-11-04 20:54:04 +08:00
AskaEth 34f3db359a fix(core): M110 r2 —— duplicate_override_paths 两种冲突同时报，补 mrpack 同侧分支用例 
- p2-2：`duplicate_override_paths` 改成「先按 path 分组，再在组内报 (侧集合, 条目份数)」，
  判据 `侧数 > 1 || 份数 > 侧数`。r1 修好了跨侧（Both×Client）但按侧去重把「同侧两个组
  撞同一路径」这条旧能力换掉了（实测返回 []）；现在两种冲突同时报得出来，返回值升为
  `Vec<(String, Vec<PackSide>, usize)>`（M111 注意：这是最后一次改形状的窗口）。
- p3-a：mrpack `check_overrides` 的「每侧只能有一个覆盖目录」分支补用例（此前零测试，
  删掉它 54 条全绿；现在删掉即红）。
- p3-b：把 ReadBudget 的「每次调用一份额度，不是整包一份」写进 `override_files` /
  `ReadBudget` 文档（mrpack 连调三次 ⇒ 理论上限 3×；要整包共用额度就走
  `override_files_with`；`open` 阶段的声明总量仍是整包一次）。
- 顺带（复审点名、各一行）：mrpack 非表达目录的 hint 里 21 个连续空格；
  curseforge 文档里 `.minecraft/.minecraft/…` 的说法按 CF 语义订正（overrides 是 zip 内前缀，
  内容铺开不丢；要不要多拷一层取决于导入器）。
 2026-11-04 00:20:25 +08:00
AskaEth 6dd652aced fix(core): M110 r1 复审修复：导出安全闸、跨侧重名、第二检用例、半包与失败分级 
按 tower 裁定清单逐条改，不扩战场（模型与扩展点未动）。

- p2-1 跨格式导出不再静默丢内容：`PackFormat::check_overrides` 在默认 `write` 写第一个
  字节前判定"这份模型的覆盖目录集合能否被本格式表达"。mrpack 要求目录名由 side 决定
  （overrides / client-overrides / server-overrides）、CF 只接受单一 Both 侧组；表达不了
  即 `pack_unsupported` + hint。`format.rs` 模块文档写死"默认 write 只保证同格式往返"，
  并列出 M112 必须补的四件事（目录映射、side 合并、加载器 id 规范化、extra 分桶）。
- p2-2 `duplicate_override_paths` 改为按 `path` 跨侧计数，返回 `(路径, 侧集合)`；
  Both×Client 同路径这条 mrpack 真实冲突现在查得出来。
- p2-3 补 `#[cfg(windows)]` 第二检用例（CON / NUL / COM1.txt / `a.` / 尾空格 / 通配符），
  并订正 `archive.rs` 文档里"保留设备名这里不拦"的自相矛盾（实际由 enclosed_name 在
  Windows 宿主上拦，第一检放行）。
- p3-1 导出改临时文件 + rename，失败清理临时文件：目标路径不再留半个 zip。
- p3-2 三个 `detect` 不再 `.ok().flatten()` 吞错误：清单在但读不出来 = `pack_metadata`；
  注册表汇总时"命中优先于失败"，一个都不命中才报，最后才退化成 `pack_unsupported`。
- p3-3 `env_extra`、CF `files[].extra`、`PackLoader::extra` 各补一条读→render→写→再读用例。
- p3-4 新增 `ReadBudget`（Cell<u64>）：`override_files` 持有累计预算，按实际读出字节
  逐条扣减，声明大小撒谎的包不能靠"很多条各自合规"绕过 `max_uncompressed_bytes`。
- CF 读侧始终产出一个 Both 侧 overrides 组（字段缺省 `overrides`），与 render 对称。

每处修复都有变异证据（改坏 → 对应用例红）：p2-1/p2-2/p2-3/p3-1/p3-2/p3-3a-c/p3-4 共 9 条。
门禁：fmt 0 / clippy --workspace --all-targets -D warnings 0 / cargo test --workspace -j 4
exit 0（58 个 test binary，passed 1930，failed 0）；全部改动文件 ≤400 行（最大 389）。
 2026-11-04 00:20:24 +08:00
AskaEth b34e86bba5 feat(core): 整合包格式无关模型与格式扩展点（M110） 
从零建 `core::addon::pack`：格式无关中间模型 + 格式扩展点 + 安全读取层，
不碰网络、不碰 UI（core-no-ui 依赖表未变）。

- `PackManifest` 无损表达 CF / mrpack / MultiMC 三方字段：包名/版本/作者/简介/
  格式版本/游戏版本/加载器依赖/文件条目/覆盖目录；`files[].hashes` 保留整张摘要表
  （mrpack 允许 sha1+sha256+sha512+md5 共存），`disabled` 记语义（导出按 D10 映射成
  env.client=optional，CF 落 required=false）。
- 未知字段按条目用 serde flatten 接住（清单顶层 / CF `minecraft` 对象 / 文件条目 /
  env / 加载器条目），导出时并回且已知字段优先；两格式各有一条「读→写→再读相等」测试。
- `trait PackFormat`（id / label / metadata_entry / detect -> Option<证据> /
  read / render / 默认 write）+ `PackRegistry`：注册表顺序即优先级，写死
  CurseForge → Modrinth → MultiMC；同一份包命中多格式时 `also_matched` 暴露歧义。
  测试里用一个 toy 格式（单文件、一行注册）证明扩展点真的可扩展。
- `PackArchive` 把目录与 zip 统一成规整条目表：路径穿越双检（自研七条规则 +
  zip crate 的 enclosed_name）、符号链接条目拒绝、条目数/解压体积/单条目上限、
  规整后重名拒绝、篡改载荷不当场吞掉；每条都有恶意样本测试。
- 格式实现：CF 可读写（缺路径如实记 None）、mrpack 可读写（强制 sha512 形状、
  env 三态、三个覆盖目录成三侧）、MultiMC 只读（.minecraft 当覆盖目录，
  组件顺序与非加载器组件全保留）。
- 三种格式各一个手造夹具（含截断 TOML / 半截 jar / 零字节 jar），来源在
  `tests/fixtures.rs` 里声明为手造，不冒充真实导出。
 2026-11-04 00:20:24 +08:00
AskaEth bc41dfcf7d Unlucky Launcher v0.0.1-alpha
CI / fmt (rustfmt --check) (push) Canceled after 0s
Details
CI / clippy (ubuntu-latest) (push) Canceled after 0s
Details
CI / clippy (windows-latest) (push) Canceled after 0s
Details
CI / test (ubuntu-latest) (push) Canceled after 0s
Details
CI / test (windows-latest) (push) Canceled after 0s
Details
CI / build release (ubuntu-latest) (push) Canceled after 0s
Details
CI / build release (windows-latest) (push) Canceled after 0s
Details
Guards / core 零 UI 守门 (push) Canceled after 0s
Details
Guards / 文件行数 ≤400 守门 (push) Canceled after 0s
Details
Guards / 依赖许可与来源（cargo-deny） (push) Canceled after 0s
Details 
Rust 原生单文件 Minecraft 启动器：CLI 完整可用（install/launch/accounts/java/diagnose/agent），
MCP server 接入外部 Agent 工具，GUI 开发中。
 2026-10-31 21:54:10 +08:00