33 Commits

Include renames

Author	SHA1	Message	Date
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	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	b7d9b99e12	feat(m190): 产物署名（PE VERSIONINFO）+ 清单 Ed25519 多签名与更新前验签 ... 两件事：让「这是谁发的」在产物与清单上都留下可验证的痕迹。 ① PE 版本资源（两个 bin）：`packaging/pe_version.rs` 是唯一口径（CompanyName 「Unlucky Launcher Project」/ ProductName、FileDescription「Unlucky Launcher」/ LegalCopyright「© 2026 … · Apache-2.0」/ 四段式版本号与 Cargo.toml 同源），被 `crates/{cli,app-iced}/build.rs` 各 include 一次；非 windows 目标整段不执行。 判据是读产物字节的 `packaging/check_pe_version.py`（CI 的 Windows 槽位）。 ② 清单签名：`manifest.json` 旁边多一份 `manifest.json.sig`（分离签名，签的是清单**原始 字节**），信封是 `{format, signatures:[{alg,key_id,sig,manifest_sha256}]}` —— 多签名数组， 任意一条命中钉住的钥即放行（换钥窗口）。信任锚是 `crates/core/src/update/trust.rs` 里的编译期公钥表（正式表为空 = fail-closed，测试钥只在 cfg(test)/update-test-source 里）。 管线顺序改成「先验签、再解析」：`UpdateSource` 只交原文 + `.sig`，`verified_manifest` 是唯一收口点，`Job::apply` 因此在取包**之前**就拒。新增五类错误分类 （signature_missing / malformed / unknown_key / keyring_empty / invalid ），全部不可重试， CLI 的 hint 单独说人话。 ③ Ed25519 验签自带实现（`update/ed25519/*`，零新依赖）：scope 不含 core 的 Cargo.toml， 用 RFC 8032 §7.1 向量 + 可锻/小阶/非规范编码的拒绝用例钉住；签名侧是 `packaging/sign_manifest.py`（纯 Python 参考实现，零 pip 依赖，`--self-test` 同向量）。 ④ 守门：`release-publish.yml` 加签名步（`set +x`，只回显公钥；没 Secret / 钥没钉 / 签不上 一律红 ⇒ 不出 Release）；`release-build.yml` 加 PE 资源读回；`release-guard.yml` 跑两个 脚本的 `--self-test`。密钥纪律与轮换（旧钥签新钥）写在 `packaging/docs/signing.md`。 Cargo.lock：新增 winresource（build-dependency）与 toml 系；toml_datetime 1.1.2→1.1.3 是 toml 1.2.1 的硬要求（`cargo update --precise 1.1.2` 已实测被拒）。	2026-11-09 01:59:05 +08:00
AskaEth	44a0c87a11	style: cargo fmt --all（合并期整合修复） ... M187/M188 并入后全仓 fmt --check 为红（CI 的 fmt job 会红）。 本次仅 cargo fmt --all 的换行/缩进变化，无语义改动； cargo fmt --check 与 cargo check 均已复验为绿。	2026-11-09 01:43:31 +08:00
worker-logplace	5fd5cd47dc	feat(m188): launcher.log 早落盘 + 会话日志搬到 logs/game（旧家只读兼容） ... 用户投诉原话：「我们的启动日志放在哪？…他找半天没找到崩溃日志」「只有一个安装日志」。 启动器运行日志（.ULL/logs/launcher.log） - presenter 构造 HostEnv 时就登记日志目录：启动早期缓冲的 200 行（[probe]/[font]/[theme]） 当场刷盘，不再是「只有开过一局游戏才有日志」。 - app/** 里所有 eprintln! 诊断改走 app::diag::diag!（stderr + 文件双写，行首 [tag] 即 scope）， 含 boot/boot::fallback/state/update 各线。 - boot 那一拍补一行后端事实（request/effective/fallback）。 - 滚动上限（1 MiB → launcher.1.log，只留一份）写进 README 与 docs/logs-location.md。 会话日志搬家：data/agent/sessions → logs - LauncherLayout: sessions_root()/game_logs() 新增，agent_sessions() 降级为只读兼容。 - host/logs 与 cli/commands/sessions 两个根合并（同 id 新根优先），event_path 回落旧家。 - 不搬不删；日志目录写一份 session-log-location.json 记录（moved=0, policy=read-only-compat）。 入口与文案 - 设置页「通用」新增「日志文件夹」行：路径 + 打开目录 + 复制路径（i18n 中英）。 - 日志页页头的「打开目录」不再是占位：走 M187 的 open_dir，失败文本带路径并送进剪贴板。 - README.md / README.zh-CN.md 新增「日志在哪」章节（含 crash-reports 只在游戏走到那一步才有）， docs/logs-location.md 给出上限、双写判据、迁移策略与没验的部分。 守门（每条都有变异证明，见报告） - 旧家会话仍列得出/打不开 ⇒ 只读新根变红；新会话写 logs/game ⇒ 只读旧根、写回旧家都变红。 - launcher.log 滚动 ⇒ 干掉 rename 变红。 - 打开日志文件夹指向真实目录 ⇒ 换成 cache/ 或去掉 create_dir_all 都变红。 - 日志根随三模式变化 ⇒ 把 HostEnv::logs_dir 写死成便携落点变红。	2026-11-09 00:43:45 +08:00
AskaEth	93d02ab12b	fix(m174): 复审 r1 五项 —— 失败带 target、密钥消息掩码、请求体断言、桥写前重读、结构化分类 ... P2-1（假绿截图）：「测试连接」失败类也带上被请求的 target。`ProbeOutcome` 的五个失败变体 改成 `{ target, detail }`，`ProbeResult::from_outcome` 不再把端点/模型填成空串；view 另加一条 「目标为空就整行不画」的保险。**截图种子改走 `from_outcome`**（新增 `ProbeResult::screenshot_seed`）：种子只伪造「结论是哪一档」，字段形状由产品路径决定——上一版 手填字段，于是「失败态目标为空」只在产品上出现、截图永远看不见。 P2-2（明文进日志）：`Message::EditKey` 的载荷从 `String` 换成 `ai::Secret`（`Debug` 掩码）。 用例 `the_key_message_never_prints_the_key` 同时钉住裸消息与整条 `pages::Message` 漏斗。 P2-3（模型没被证上线）：假服务器按 `Content-Length` 读请求正文，新用例 `the_request_carries_the_configured_model` 断言正文里 `"model":"gpt-test"`。变异实测暴露出 一处真相：`ChatRequest.model` 被 `RigProvider::build_request` 静默忽略，线上模型来自 `ProviderConfig.model`（已另开 finding，并写进 probe 的注释）。 P2-4（数据丢失）：`SettingsBridge::persist` 写前 `store.reload()`。`SettingStore::save` 是整份 文档落盘，不重读就会拿 ≤1 秒前的旧快照盖掉刚写的 `ai.*`。两条回归用例： `presenter::settings_bridge::persist_keeps_keys_another_writer_just_saved` 与 app-iced 侧的 `ai::store::appearance_write_back_keeps_the_ai_keys`（保存 AI → 改主题 → 值还在）。 P2-5（子串匹配）：删掉 `classify()`。分类改由 `brain::rig::map_error` 从 rig 0.45 的结构化 报告（`ErrorReport` 的 `kind` / `http_status` / `code`）翻译成新的 `ProviderFailure` （`brain/provider/failure.rs`），`ProviderError` 因此带上 `kind`。`closed_port_is_unreachable` 不再依赖错误文本：连接被拒恒为 `ErrorKind::Http` ⇒ unreachable。防退化用例 `factory_error_carries_the_structured_classification` 断言「纯文本 401 不许被猜成 auth」。 顺带（400 行硬线）：`provider.rs` / `rig.rs` 的用例各自拆到 `provider/tests.rs` / `rig/tests.rs`（纯搬移）。	2026-11-08 16:20:34 +08:00
AskaEth	9cb605f316	feat(m174): 助手（AI）提供商配置真接线 + 「测试连接」 ... 设置页新增第 6 组「助手」：提供商四态 / 端点 base_url / 模型名 / API 密钥（默认掩码， 点「显示」才明文）+ 保存 + 测试连接，四类失败（鉴权 / 模型不存在 / 不可达 / 超时）各自 一句文案 + 目标与耗时。 取舍三条： 1. 读写走 `core::setting` 的 schema API（`SettingStore::load` 现读 → `set` → `save`）， 不经 `AppCommand::SetSetting`——那条指令是可序列化 DTO，`ai.api_key` 走它等于让明文进 事件流/日志。与 `SettingsBridge::persist` 写外观是同一条做法。 2. 「测试连接」不另写一套 HTTP：`unlucky_cli::commands::agent::probe` 现读设置文件、 交给 `RigProvider`（真 provider）发一次最小补全，带 8 秒时限；分类只看错误文本 （rig 只给 Display），四类各有一条真 TCP 假服务器用例钉住。 3. `ProviderKind` 补 `from_setting` / `setting_value`：serde 的 `rename_all = snake_case` 产出 `open_ai_compatible`，与 schema 的 `openai_compatible` 不是同一个词——这正是 M174 之前「agent 侧一次都没读过设置」的根因。 守卫（都做变异验证，见 mission 报告）：密钥不出 `Debug`/`detail`/DTO；未配置时工厂构造 计数为 0；改完 base_url 后探测打到新地址；空/非法值被 schema 拦下且文件不动。 i18n：49 条中英各一（金表按 `Key::ALL` 位置插入）；presenter 的 ai_group 补上 schema 允许 的 `disabled` 选项与一行「已配置 N 字符」的只读状态（仍然不显示值）。	2026-11-08 15:57:25 +08:00
worker-updatee2e	24826c1a7c	feat(m169): 更新通道端到端验收 —— 本地源改成编译期 feature，补一条可一键跑的 E2E + CI 守门 ... §6 欠账：更新链路的 GUI 端从来没验过，而 M167 发现它根本没法在本机验——`ULL_UPDATE_DIR` 只在 `debug_assertions` 下生效，发布产物却是 release；`apply` 又会替换本进程 exe，于是没人敢跑。 判据换档（tower 定案 B）：`cfg!(debug_assertions)` → 编译期 cargo feature `update-test-source` （core 定义，cli/presenter/app-iced 链式转发，**默认关**）。带 feature 的构建里还要两档环境变量 （`ULL_UPDATE_DIR` + `ULL_UPDATE_TEST_SOURCE=1`），只给路径什么都不会发生。官方发布二进制里那段 分支根本编不进来——README「release builds do not contain that path at all」这句因此继续为真。 - core: `job::default_source` 的本地源分支整段 `#[cfg(feature = "update-test-source")]`；判据抽成 纯函数 `test_source_root_from` 并逐条单测（半开一律关、空路径、承认值只认 `1`）； `the_test_channel_is_a_compile_time_opt_in` 在**两种构建下各断各的**（带 feature ⇒ 换源； 不带 ⇒ 环境变量设满也走 GitHub）。 - cli: `update check/apply` 的 `--json` 增加 `test_source` 字段（判据派生自实际用了哪个源，不是回读 环境变量），人读输出多一行点名；`help.rs` 的 `ULL_UPDATE_DIR` 说明按新判据重写。 - 验收：`crates/cli/tests/update_e2e_test.rs` + `update_e2e_tamper_test.rs` + 共用夹具 `tests/support/update_e2e.rs`。临时数据根 + 本地源 + 真形状清单（与 `manifest.golden.json` 同 字段）+ 真 PE 产物（现场构建的 ull.exe 前 1 MiB，理由写在 `PAYLOAD_LIMIT`）。断言覆盖：发现 新版本（source=file:… / test_source=true / size / notes）、下载 → 双检 → 就位（dest 字节、旧字节 进备份、暂存无残留）、重复 apply 的幂等终态、篡改 sha256（清单撒谎 / 包体被换）与截断都必须 拒绝且不动现有安装、修复后能重装。**永远带 `--dest`**：不带会真的改名换掉测试二进制。 - 守门：`packaging/check_test_source_off.py`（stdlib-only）扫 `.github/workflows/**`、 `packaging/*.py|*.sh` 与各 `Cargo.toml` 的 `default`，任何一处打开 feature（或 `--all-features`） 就红；`--self-test` 注入 5 条真实回归证明每条都会红。CI 挂在 release-guard.yml 两步。 验证（本机）：core update 单测 80 绿 / 带 feature 6 绿；E2E debug 6 绿； `cargo test --release --features update-test-source` 6 绿（tower 要求 release 档验收）； `cargo test -p unlucky-cli -p unlucky-presenter` 全绿；守门 self-test + 正式扫描绿（真注入后红）。 已知没验：真 GitHub Release 下载、GUI 点击与重启替换（人工）；跨卷替换（另开 finding）。	2026-11-08 11:12:10 +08:00
AskaEth	79b796fd58	fix(m161-r1): 崩溃/静默失败不再冒充「启动进程失败」；补三处假绿的守卫 ... 复审 P1-1（用户可见假文案）：`LaunchEnd` 在 `failure == None`（跑起来之后崩的）时 临时造了 `Stage::Spawn + format!("exit {:?}")`，于是磁贴写「启动失败 · 启动游戏进程」、 详情页漏出 `exit Some(1)`、静默失败丢掉「exit 0 却没起来」，而同一时刻 Toast 说「崩溃」。 - 新增 `LaunchFailureCause{Stage|Crashed|SilentFailure}`（dto/launch_failure.rs）， `LaunchFailureCause::of(outcome, failure, exit_code)` 是唯一组装点；`InstanceRuntime::Failed{cause}`。 `LaunchFailureStage` 保持「只装装配阶段」（文档那句「崩溃是结局不是阶段」现在成立）。 - 界面：`InstancesFailed`（框架）+ `InstancesCrashed` + `InstancesSilentFailed`； 删掉 `InstancesFailedStage`。退出码按数字出词，不再有 Debug 文本。 - 用例：presenter 断言**枚举变体**（三种形状逐条）、app 断言**具体句子** （「不许出现 Some(」「进程起来了不许说启动游戏进程」「静默失败要点出没起来」）。 mock 夹具与 launch_state_tests 的期望值同步；launch-error 三张图重拍。 复审 P2-1（`convert::failure_stage` 零覆盖）：新增 `convert/stage_tests.rs` 5 条（三档 + 「既没回滚也没宣称干净」+ 非致命无阶段 + `failed_report_with` ⇒ NotStarted）。 变异实测：改成恒 `RolledBack` ⇒ 3 条红。 复审 P2-2（矮窗口用例的算式三个数全错、`body_height` 零测试）：用例改成直接调 `frame::body_height`，chrome 从 `Ui::metrics` + `WidthClass::gutter` 现取，并把门槛与真实 chrome 绑死（chrome+MIN ⇒ Split、-1px ⇒ ScrollWhole）；新增 `frame` 自己的 `body_height` 用例。 变异实测：`2.0 * gutter` → `gutter` ⇒ 2 条红。 复审 P2-3（源指纹闸门 / `Refused` 零覆盖）：新增两条 core 用例——闸门（原地留着 prefs.json + 预先写好的同源收据 ⇒ Nothing 且收据未被重写，反证：源变了允许重放）、`Refused` （`$schema` 1.7.0 ⇒ ReadOnly ⇒ 不动旧文件、不写收据、理由含「不可写」）。 变异实测：删闸门 ⇒ 1 条红；`can_save` 守卫改 `if false` ⇒ 1 条红。 顺手收： - CLI `pack import` 那句「已整包回滚」也按三档出词（`RollbackStage` + `rollback_line`）， 加 2 条单测。CLI 不依赖 presenter，判定暂与 presenter 各一份 → 已 file finding 建议下沉 core。 - 设置页 `status_text()` 抽出 applying 档，用例断言「正在安装…」且非错误色。 金表：新 key 加在 `golden.rs`（81 行），未动 `golden/tail.rs`（211 行），避免与 M162 的拆分冲突。	2026-11-07 17:01:13 +08:00
AskaEth	03741ecd2d	fix(m161): 收更新键/按钮/矮窗口/启动错误/导入结果五笔债 ... ① update.auto_check / update.channel 登记进 core setting schema（1.6.0） - 新增 setting/keys/update.rs（两键 + UPDATE_CHANNELS，只允许 stable）； SettingSchema 加 with_all 供域键表批量登记。 - 新增 setting/update_prefs.rs：cache/update/prefs.json → launcher.json 的一次性迁移。 四条硬约束：源指纹闸门（幂等）、不丢 false、新值胜出、旧文件改名 .migrated 后不再被读； 主配置不可写时不动旧文件。收据 config/update-prefs-migration.json。 - presenter Runtime 建会话时迁一次并把结局留在 migration()；prefs 字段换成 auto_check + 每次派发从主配置读 channel（不再硬编码 Channel::Stable）。 保留旧字段 auto_check 的真实来源（原有测试 cases 会断言）。 - CLI config get/set/dump 先跑同一次迁移（幂等），输出里给 migration 段与收据路径。 ② presenter/dto/events.rs 的「本次会话不再弹提示条」注释改成真实语义 （记的是版本号：同版本压住、更高版本照弹、手动检查清掉）。 ③ 检查/下载进行中按钮禁用：pages/update/busy.rs 的 busy/can_check/can_apply； 设置页两颗按钮改画禁用（不是消失），app 层 on_update_action 再挡一道 （忙碌时 CheckNow/Apply 不派发）；新增两条用例（含「忙完恢回可点」）。 ④ 内容库低高度：content_layout::MIN_BODY_HEIGHT=460 + BodyMode（按固定件+三整行算出来， 用例守着算式）；frame::body_height 从 Ui::metrics 算正文可用高，pages::Model 带 window_height。 ≥460 列表自己滚；<460 主列整列一个滚动条、列表按自然高度铺开。 ⑤ 启动错误文案本地化：presenter 删掉 launch_summary / 「启动失败：」前缀 / 五条中文阶段前缀， 改发 LaunchFailureView{stage,detail}；LaunchFinished 改带 exit_code/uptime_ms/failure， Toast 由 app 层按 i18n key 现求（与 install_cancelled 同构）。InstancesFailed 拆成 InstancesFailedStage（列表单行）+ LaunchStageFailed（详情/Toast 全文）。 ⑥ 导入结果块：ImportReportView 加 failure_stage（NotStarted/RolledBack/RollbackIncomplete， 由 core 的 rollback 机器位推出）；标题、图标、底色三处分档，预检失败不再说「已回滚」。 顺带：六处注释/文档漂移（update.rs 的分工表与偏好落点、pack 的「已整包回滚」、 build_request 的 Errors、settings/update 的按钮禁用说明等）， 以及为守 400 行把 update/cli-config/core-keys/presenter-dto/presenter-launch/i18n-golden 里贴线或越线的文件按模块拆开（纯搬移，行为不变）。	2026-11-07 15:02:13 +08:00
AskaEth	04ac90911e	fix(m159): r1 复审返工 —— parse.rs 拆出子模块 + 五条 P3 真问题 ... 按独立复审 `reviewer-updategui-r1` 的 p1-1 / fix-then-merge 返工。 P1-1（挡门） - `crates/cli/src/cli/parse.rs` 406 → **382** 行：`fn parse_update` 搬到 `crates/cli/src/cli/parse/update.rs`（与 `parse/{accounts,agent,instances}.rs` 同形状）。 全仓 `crates/**/*.rs` 最大仍是 400（`design/tests/card_neutral.rs` 等三处，未越线）。 上一轮报告里「所有改动文件都在 400 行内」那句是错的，已在 r2 报告里更正。 P3-6 `Job::apply` 不查包形态 - 新增 `self_replaceable(format)`（只有 `PortableExe` 允许）+ `ensure_self_replaceable`， **挡在取包之前**；错误分类 `InvalidManifest`（发布侧挂错，换源/重试无用）。 比复审建议的 `needs_installer()` 更严：`portable-zip`/`appimage` 同样不能原地当 exe。 - 用例：`crates/core/src/update/tests/job_cases.rs`（msi/zip 被拒 + 目标零改动 + 暂存目录 没被建 + 便携 exe 整环成功 + Nothing 不碰目标 + 闸门的源码锚点）。 P3-7 `ULL_UPDATE_DIR` 生产可用 - `default_source` 改走 `local_dir_override()`：`if !cfg!(debug_assertions) { return None }`， 发布构建里整段被常量折叠掉（这条路径在 release 二进制里不存在）。判据与三档取舍写在 `job.rs` 的文档表里（为什么不用 CLI 参数、为什么不用运行期开关）。 P3-1「忽略这个版本」语义 - `UpdateView.dismissed: bool` → `skipped: Option<String>`（记**版本号**）：忽略 0.2.3 之后 同一次运行里冒出 0.2.4 **照常提示**；手动检查清空（`begin_check(manual)`），静默检查不清。 文案保持「忽略这个版本」。presenter / app 侧视图模型 / 两处用例同步。 P3-3 CLI `--json` 失败信封缺结构化分类 - `CliError` 加 `detail`（`Option<Box<Value>>`，装箱避免 `result_large_err`）+ `with_detail`， `to_json` 输出 `error.detail`；`commands/update.rs` 的 failure 填 `{"kind": core 分类 id, "retryable": 可重试位}`。 - 上一轮报告里引的 `{"kind":"digest_mismatch"}` 形状确实不存在（那是 CLI 的 user/internal）， r2 报告换成了实机 dump。 P3-4 update 命令没有解析测试 - `crates/cli/tests/parse_test.rs`：`update_subcommands`（check / apply / `--dest` 两种写法） + `update_usage_errors`（无子命令 / 未知子命令 / 多余位置参数 / 缺少取值 / 未知选项）； `help_text_covers_every_command` 的 topic 列表补 `"update"`。 P3-5 `install.rs` 模块文档与实测矛盾 - 改成「可以改名、不能覆盖/删除」，写明 M159 在 Windows 真机验过运行中的 exe 自替换， 并提醒别再照旧文档去设计「退出自身 → 另一个进程搬运」的双进程方案。 顺手（复审 P3-2/P3-8 里低成本的两条） - 设置页补「下载中」态（`SettingsUpdateApplying` 不再是死 key，下载期间不画「下载并安装」）； 渠道显示改读 `update.channel`（`stable` 走 key，其它原样）；删掉从未使用的 `UpdateBannerRestartLater`（catalog + 金表同步，29 条 key 全部有引用）。 - `adopt` 只让**检查**刷新 `checked_at`（应用回报不再冒充「上次检查」）； `UpdateView::default()` 的 `current_version` 取本进程版本号（mock 下不再空白）。 门禁（`CARGO_TARGET_DIR=C:/Temp/ull-target/wt-159`）：fmt 绿、clippy -D warnings 绿、 `cargo test --workspace --all-targets --no-fail-fast -j 4` **exit 0**（51 个测试二进制全 ok， `core::addon::pack` 未被 skip）。该族用例复现了复审记的泄漏：一次全量在 `/tmp` 留 72 个 `ull-pack-*`（`/tmp` 149M → 8853M），跑完已 `rm -rf` 清回 150M。	2026-11-07 13:03:18 +08:00
AskaEth	1c8f6aa1b3	feat(m159): 自更新 GUI 客户端接线 + CLI update check/apply 同一内核 ... D50 的「检查 → 提示 → 可拒绝 → 下载校验 → 下一次启动生效」整环接线，GUI 与 CLI 共用 core 的一条内核（`update::Job`），并顺带修掉 M157 最后一轮复审的三处 P3。 内核（core::update） - 新增 job.rs：`Job { source, target, staging, dest }` + `check` / `apply`（复查 → 取包 → 长度/SHA256 双检 → 原子替换），`default_source`（GitHub，`ULL_UPDATE_DIR` 可切本地目录夹具）、`process_dest`、`staging_dir`。 - `mod.rs` 导出 job 一族；`source.rs` 为 `Box<dyn UpdateSource>` 补 trait 转发 （壳层要运行期选源，`UpdateChecker` 是泛型的）。 presenter（宿主通道） - `dto/update.rs`：`UpdateView` / `UpdateOutcome`（Idle/Checking/UpToDate/Available/ MissingArtifact/Failed 六态，**失败与最新不折叠**）/ `UpdateBanner` 优先级判据。 - `host/update.rs`：Factory（生产 GitHub / 单测本地目录）+ core 结论 → DTO 的唯一映射 + 更新域偏好（`cache/update/prefs.json`）。 - `host/update_state.rs`：Runtime（会话状态机：begin_check/adopt/begin_apply/dismiss/ set_auto_check）+ `CoreHost` 派发与后台线程。 - `AppCommand::{CheckUpdate, ApplyUpdate, DismissUpdate, SetUpdateAutoCheck}`、 `CoreEvent::Update`、`AppState.update`；`refresh_all` 按开关派发静默检查。 app-iced - 设置页新增第 5 组「更新」（当前版本 / 渠道 / 自动检查开关 / 立即检查 / 上次检查与 结果 / 下载并安装 / 就位后立即重启），走 `settings::view` 的 `update` 形参 + 按下标 分发（与 M106 语言行同一取舍）。 - 顶部提示条（每页可见）：有新版本（版本号 + 体积 + 说明摘要，可安装/可忽略）、下载中、 已就位（立即重启）；静默检查失败**不**弹条（原因进设置页）。 - `pages::Message::Update(UpdateAction)` → `app/update/update_action.rs`；「立即重启」 拉同参数的新进程后退出（截图通道不重启）。 CLI - `ull update check` / `ull update apply [--dest <path>]`：复用同一 `Job`；四种结论分开 报（`--json` 的 `status`），失败退出码 1（`update_check_failed` / `update_apply_failed`）。 i18n - 新增 `catalog/update.rs`（30 条，链尾追加）+ 金表对应 30 行。 M157 复审 P3 三件 - `app/update/instances.rs` 模块文档改成「清脏的唯一时机是回程快照等于表单」。 - `pages/instances/demo.rs` 的 `demo_form` 注释改成现状（两个参数框早已是单行输入）。 - `pages/instances/launch_args.rs`：门限不满足时只灰 `opengl`/`vulkan`，`default` 仍可点 （它是「不下发」的安全档）；判据抽成 `backend_chip_enabled` 并补 3 条用例。浅色 + 灰化 两张图：`C:/Temp/m159-shots/instances-launch-args-{light,gated}.png`。 顺带：harness 支持 `ULL_SETTINGS_GROUP=<下标>`（拍第 5 组的验收图需要它）。 验证：cargo fmt --check 绿；cargo clippy --workspace --all-targets -D warnings 绿； cargo test --workspace --all-targets 51 个测试二进制全绿（唯一例外：core::addon::pack 一族要造 4 GiB 稀疏文件，本机磁盘 99% 满 ⇒ StorageFull，与本次改动无关）；CLI 用本地 目录夹具跑通「发现 9.9.9 → 下载 → 校验 → 替换运行中的 exe → 备份留旧文件」，并验证 摘要不符时拒绝应用、目标文件零改动、暂存目录零残留。	2026-11-07 12:09:42 +08:00
AskaEth	ee67965b9b	fix(m157): r4 修复未收集的周快照用例 + 两处 clippy 红，并补整环回归（复审 p1-2） ... P1-1 crates/core/src/launch/overrides/tests.rs：modded_weekly_snapshot_needs_the_root_version_for_the_gate 原先写在 backend_allowed_combines_capability_and_threshold 函数体内（unnameable_test_items，永不执行）。移到模块层；移动后首次真正执行暴露出用例自身的 EmptyJavaPath（AdapterOptions 默认 java 为空），补 JavaSelection 后绿。--list 现在 10 条 launch::overrides::tests::（含该名字）。 P1-2 clippy -D warnings 两处：cli/commands/instance_launch.rs needless_borrows_for_generic_args（去 &）；presenter/mock_data.rs items_after_test_module（mock_launch 移到 mod tests 之前）。 P3-a 新增整环回归 app/tests/instances_save_loop.rs：真 Message → dispatch → 后端回错误 Toast → pump → refresh_view → sync_launch_form，断言 4g 草稿与脏标记都还在。 P3-b LaunchForm::matches 内存改按数值比（解析失败退文本），补 memory_is_compared_by_value_not_by_text（04096 / +4096 / 清空三档）。 P3-c 门槛文案不再在 catalog 硬编码 26.2：InstancesLaunchBackendGated 改用 {min} 占位符，页面从 LaunchFacts::min_version（← core GRAPHICS_BACKEND_MIN_VERSION）代入；金表同步；灰化态截图重拍。	2026-11-07 11:06:18 +08:00
AskaEth	211e07b470	fix(launch): M157 r3 周快照门限按继承根版本 + 保存失败保留草稿（复审 P2-1/P2-2） ... P2-1 周快照 + 加载器的 --graphicsBackend 静默丢失：presenter host::launch::build_request 与 cli snapshot::prepare 给 SnapshotInput.game_version 传 None，装配按带加载器后缀的 version_id（26w14a-fabric-0.16.5）判门限，GameVersion::is_weekly_snapshot 的 6 字符形态认不出来。两个调用点改为传继承链的 MC 根版本（25 行注释说明「门槛与拼装必须同一口径」）。回归：core launch::overrides 的周快照实际装配用例（正/负两档）、presenter host::launch::tests、cli snapshot::tests 各一条根版本断言。 P2-2 保存失败丢草稿：app/update/instances.rs 的 Save 分支派发前就把 launch_form.dirty 清掉，失败事件后 pump 用旧快照重建视图并覆盖表单。改为派发不清脏；LaunchForm::sync 只在「回程快照已等于表单」（= 落盘确认）时清脏并重播种，否则保留草稿。回归：failed_save_keeps_the_draft / confirmed_save_clears_dirty_and_reseeds / save_dispatch_keeps_the_dirty_flag。 顺带：launch::overrides 测试拆到 overrides/tests.rs（守 400 行）。	2026-11-07 10:36:37 +08:00
AskaEth	e2021645d7	feat(launch): M157 实例级启动参数（五项回落 + graphicsBackend 三态） ... core: 新增 game/launch_overrides（LaunchOverrides 五项 All-Option + 三级回落 + 文本补丁校验）与 launch/overrides（拼装落位：全局 java.extra_args 进 user.jvm、实例 jvmArgs 进 override_jvm、gameArgs 进 user.game、memory 进 -Xmx、backend 进 --graphicsBackend 并复用既有版本门槛告警）；实例 schema 登记 launch.* 五键。 presenter: dto/LaunchArgsView+LaunchArgsPatch，主机侧读/写与门槛判定（backend_allowed），AppCommand::SetInstanceLaunchArgs。 cli: 新命令 instances launch-args（读/写/--clear），launch 装配链消费回落值。 app-iced: 实例详情页「启动参数」区（JVM/游戏参数、内存、Java、三态后端 chips + 灰化提示 + 保存/恢复），表单状态归 App、i18n 中英文案同步。	2026-11-07 10:36:35 +08:00
AskaEth	23c2abebc2	feat(termux): launch 侧同样改写 arm64 natives；真机跑通 MC 1.20.4 ... - Library::linux_arm64_native_name 收敛改写规则，install 与 launch 共用 - presenter/CLI 的 classpath 组装：1.19+ 的独立 natives 条目按 arm64 坐标 找文件并进 classpath；≤1.18 的 natives 表条目仍归 natives::collect - 真机验证：ull install 1.20.4（740MB）→ glibc Temurin 21 + arm64 natives + softpipe GL，MC 主菜单在 termux-x11 中渲染（窗口 854x480） - 已知非致命：narrator flite 缺失、LWJGL JNI 版本告警、oshi cpuVendor NPE	2026-11-07 09:33:23 +08:00
AskaEth	7b971dc75d	fix(java): Termux 幂等安装报「未走网络」，vendors 在 Termux 上展示 termux 行 ... - termux::install 返回 (home, reused)，复用时 downloaded=None， CLI 不再显示「0 字节 / 0 个文件」 - java vendors 在 Termux 上把 termux 插到顺序最前（仅展示，默认回退序不变）	2026-11-07 09:33:20 +08:00
AskaEth	48d1ee6616	feat(java): Termux 上自动安装系统 openjdk（内置镜像 + 隔离 apt 状态） ... - 新增 game::java::termux：内置 SAU/TUNA/USTC/官方四个 termux-main 镜像， 按顺序 apt-get update+install；lists/cache 隔离在 $PREFIX/tmp/ull-java-termux， 不改用户 apt 配置；装完从 $PREFIX/lib/jvm 定位，幂等（已装则不走网络） - JdkVendor 增加 termux（17/21/25），--vendor termux 只走系统包； Termux 上缺省安装先试系统包，失败再走归档链并带出每一跳原因 - standard_roots 已能扫 $PREFIX/lib/jvm（上一条提交），装完即被 java list 发现 - CLI/presenter 的 vendor 展示与帮助文案同步；设置白名单与契约测试同步 - 文档补 Termux 上的 Java 行为	2026-11-07 09:33:19 +08:00
AskaEth	7946e5b804	docs(readme,cli,packaging): M153 清账四条被排忘的文档类 finding ... ① README 两版下载表：linux-x64 / linux-arm64 / macos-arm64 / macos-x64 四行补「not yet published / 暂未发布」标记（与 M143 的 windows-arm64 行同款措辞），表后改成「本版只发布 windows-x64」的口径， 并说明发布 job 只留 PUBLISH_SLOTS 里的槽位（现住 release-publish.yml）；顺带把「produced by the CI matrix」那句改成「矩阵里有、默认发布跑不编、all_slots=true 才编来取证」。 ② packaging/make_artifacts.py 两处 docstring 还写 windows-arm64 是 cross-built：按 M140 后的原生 windows-11-arm 事实改写。（release-notes.md 的同一说法在 M139/M142 已改掉，本次核实无残留，未再动。） ③ cli 缺 id 的 hint：删掉「（id 不进仓库）」并改成与 cli/help.rs 一致的「官方构建已内置、环境变量优先、 自建时构建期注入」；Secret 透传的事实留在同处代码注释。 ④ README 两版文件清单表：release.yml 从「six-slot build / 六槽位构建」改成「两个 Windows 槽位原生 构建 → 只发布 windows-x64；all_slots=true 才整表六槽位取证」。 纯文案，不动任何构建或运行时逻辑。	2026-11-07 07:57:32 +08:00
AskaEth	5597a4cc18	feat(release,docs): M149 发布构建烘入微软登录 id（仓库 Secret），文档改为「官方构建开箱即用」 ... 构建侧：release-build.yml 声明 on.workflow_call.secrets.ULL_MSA_CLIENT_ID（required: false）， cargo build 步以 env 注入它，option_env! 把它烘进二进制；release.yml 的 build job 按名显式透传 （与 PUBLISH_TOKEN 同一模式，不用 inherit）。真值放仓库 Secret，不进任何 git 文件；Secret 未录入 或 Actions 之外求值为空串时，client_id.rs 的 blank_env_value_counts_as_missing 保证「空白=没配」， 不会拿空 id 去联网。 文档：README 两版 / help.rs 的 accounts topic / packaging/release-notes.md / packaging/docs/build-and-ci.md 统一成「官方构建已内置登录所需配置、开箱即用，仍可用环境变量 ULL_MSA_CLIENT_ID 覆盖；自建想自带就构建时注入」的功能性口径 —— 不出现 id 本身，也不出现归属描述。 client_id.rs 的模块注释与测试注释同步（原文写「id 不进仓库（用户定案）」，已随 Secret 方案改写）， 并记下「别把 ULL_MSA_CLIENT_ID 导出到跑 cargo test 的 shell」——presenter 的 M132 入口锚会在 已烘焙 id 的构建里故意红。 实测：ULL_MSA_CLIENT_ID=<id> cargo build --bin ull 后，清空 env 跑 ull accounts add msa 打出 用户码与链接（无「未配置」提示）；同二进制设一个假 env id 则 AADSTS700016 点名该假 id（env 覆盖生效）。 单测：core auth 28、unlucky-cli 全套、i18n 30、presenter 222 全绿；M132 锚在烘焙构建里按设计红、 在不带 id 的构建里绿。cargo fmt --all --check 通过。	2026-11-06 21:08:53 +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	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	9ead4ae892	feat(cli): M124 instances list --json 补 loader 字段，只加不改 ... `ull instances list` 的人读输出历来只逐字打 `version_id`，脚本/agent 要判断 「这是不是 Fabric」只能自己猜 id 形状——正是 M122 收敛掉的第二份真相。本提交只补 输出面： - 每行实例加 `loader: {"kind": <稳定 id>, "version": <版本段>}`，解析一律调 `unlucky_core::game::InstanceLoader::parse`（M122 的全仓唯一入口），CLI 里没有 任何新的 id 匹配；CLI 只做「种类 → 稳定 id」的穷尽翻译。 - 原版恒为 `{"kind":"vanilla","version":""}`：键恒存在、不为 null，脚本不必判空。 - `kind` 是识别口径（7 值，含只能继承不能安装的 optifine/liteloader），不是 `install --loader` 的安装口径（5 值）——这条连同「vanilla 只表示 id 里没有加载器 痕迹」一起写进模块文档与 `ull help instances`（`--json` 是事实对外契约，字段说明 跟着契约走）。 - 向后兼容：`data.instances[]` 原有七个键一个没动，人类可读输出逐字不变。 - 测试（`commands::instances::tests`，走真入口 `crate::run`）：四家自家 id + 原版 + 两家第三方前缀的真值表、原版非 null 的反向锚、人读输出与旧字段不变的兼容锚、 help 里有契约说明的文档锚。	2026-11-05 15:23:37 +08:00
AskaEth	8780f26308	fix(auth): M117 微软登录缺 client id 说「未配置」而不是「未支持」 ... 用户实跑 debug 二进制看到「本期未支持」，误以为功能没做；实际是构建/启动时 没注入 Azure 公共客户端 id（登录三轨已实现、白名单已批、真机验签过）。 - core/auth/microsoft/client_id.rs（新）：id 的来源判定（env > build，空白值不算配）、 `ClientIdStatus`/`log_line()` 那行 `[auth] msa client_id=… source=…`、以及 「未配置 + 怎么配（含可照抄命令）」的共用文案 `MISSING_CLIENT_ID_MESSAGE`。零网络。 - core/auth/error.rs：`AuthError::Unsupported` 不再统一拼「本期未支持：」前缀——该变体 全仓唯一构造点就是缺 client id，硬拼前缀让「没配置」被读成「没实现」。`code()` 仍是 `unsupported`，枚举形状与其它分支不动（tower 批的最小改动）。 - core/auth/microsoft/mod.rs：`from_env()` 走 `resolve_client_id()`，失败措辞取自上面那条 文案，且在网络之前早退（连 HTTP 客户端都不建）；导出 `client_id_status()`。 - cli：`map_auth_error` 的 Unsupported hint 给两条能照抄的命令；`accounts` 帮助说清 「不是功能缺失」与两种注入方式；新增 `msa_client_id_log_line()` 给 GUI 侧出面。 - app-iced：`on_boot` 打一行 `[auth] msa client_id=… source=…`（判据来自 core，不重算）。 - i18n：`LaunchMsaNotConfigured` 中英各一条，golden 按 `Key::ALL` 顺序在 `LaunchFailedWithCode` 之后追加一行。 本地便利路径（gitignored，随报告交付）：`DevDocs/ops/ull-msa-run.sh` 读本地 id 文件 或 `azure-msa-app.md` 注入环境变量再起 GUI，脚本本身不含 id。	2026-11-05 07:31:55 +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	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