7 Commits

Include renames

Author	SHA1	Message	Date
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	8ca1e1e965	fix(cli): 程序名占位符在构造时渲染，两条出口（人类可读 / --json）不再分叉（M82 r3 复审 P2） ... r2 只在人类可读通道渲染 `%prog%`，JSON 两条出口（错误信封的 message/hint、Report 的 warnings）直接序列化未渲染文本，于是 `--json lst` 吐出 `"hint":"%prog% --help 查看命令列表"` ——连 `ull` 自己的 JSON 都被这轮改动弄坏了。 改成**构造时渲染**，一个入口管住所有出口： - `CliError::usage/user/internal/with_hint` 统一过 `render()`（错误只有这一处成形）； - `Report::new` 渲染 human 行，`Outcome::with_warnings` 渲染 warnings； - `print_report` / `print_error` 不再各自渲染（渲染点只有一个，不会再有第三条出口漏掉）。 回归测试三条：`json_error_envelope_never_leaks_the_placeholder`、 `json_warnings_never_leak_the_placeholder`、`human_lines_render_the_placeholder_too` （后者同时断言「账户名恰好叫 ull」这种用户数据不被改）。	2026-11-02 08:08:16 +08:00
AskaEth	2f8bbd1746	fix(cli): 程序名只替换模板占位符，不再改写用户数据（M82 r2 复审 P2） ... r1 把 `rename` 套在**插值后的整条文本**上，于是用户数据被改坏：账户名恰好是 `ull` 会变成 `unlucky-launcher`，路径 `D:/tmp/ull/.ULL/...` 会变成 `D:/tmp/unlucky-launcher/.ULL/...`， 回显的子命令 `ull` 也会被改名。 改成模板占位符：文案里写 `%prog%`，**只在渲染时**（print_report / print_error / 帮助）替换成 argv[0] 的 basename。占位符只存在于静态模板里，插值进来的账户名 / 路径 / 子命令碰不到它。 用 `%prog%` 而不是 `{prog}`：这些模板要活在 `format!` 里，`{prog}` 会被 format! 当成参数名 编译失败。 同时补上 r1 漏的反方向：**stdout 的正常输出**（Report.human 与 warnings）现在也做替换， 以前只有 stderr 的错误做了，两边不一致。 回归测试：`user_data_that_says_ull_is_never_rewritten` 断言「账户名 `ull`」「路径 `\ull\`」 「未知命令 `ull`」在 fill 之后逐字不变。 占位符替换覆盖 21 个文件的 63 处文案；测试夹具里形如 `ull-mcp-diagnose-<pid>` 的临时目录名 已回滚为字面量（那不是文案）。	2026-11-02 08:08:13 +08:00
AskaEth	c9e6236a87	refactor(cli): 判据收敛到 unlucky_cli::cli，banner 按被调用的二进制名自称（M82 复审） ... 去重：`looks_like_cli(args) -> bool` 落在 `unlucky_cli::cli`，两个 GUI 的 main.rs 只调用它， 判据从两份变一份。cli crate 里**不**出现 GUI 的 flag 表——语义仍是「首个 token 是裸词就接管； 首个 token 是 flag 时只有解析出真命令才接管，解析失败不接管」。原来两个 main.rs 里的 5+5 条 单测合并成 cli crate 的一份（用例集按复审要求原样搬，含 --screenshot/--renderer/--diff/ --mock/--force-state/--scale-factor、--help/-h/--version/-V、10 个已知子命令、--json 前置、 未知子命令），两个 main.rs 的旧测试已删除。 banner：新增 cli::program 模块，从 argv[0] 的 basename 取程序名（剥目录、剥 .exe、空值回落 ull），把帮助/版本/错误提示里独立出现的 `ull` 换成它——`unlucky-launcher --version` 不再自称 `ull`，也不会把人指去敲 `ull --help`。`run()` 签名未改；`ull` 自己跑时输出逐字不变（替换是 恒等），打包脚本的 `ull --version` 冒烟不受影响。	2026-11-02 08:08:12 +08:00
AskaEth	bc41dfcf7d	Unlucky Launcher v0.0.1-alpha ... Rust 原生单文件 Minecraft 启动器：CLI 完整可用（install/launch/accounts/java/diagnose/agent）， MCP server 接入外部 Agent 工具，GUI 开发中。	2026-10-31 21:54:10 +08:00