31 Commits

Include renames

Author	SHA1	Message	Date
worker-updatee2e	68a1f90828	fix(m169): 复审 r2 —— 守门归属改成「列表项结构判定 + 默认拒绝」，堵掉无名步骤/无名 job/flow 步骤的继承放行 ... r2 复审（reviewer-updatee2e-r2，p2-4items；被抓出一个真洞，mission 翻回 active）逐条落地。 P2-1（本轮核心，真洞）allowlist 的归属原来按「最近一行 `- name:`」切块，于是任何不写成 `- name: <x>` 的步骤都继承上一块的名字；被放行的 `update-e2e` 恰好是 ci.yml 里最后一个 `- name:`，所以追加到文件末尾的一切都落在它的块里。复审三条真实注入（无名 `- run:`、无名步骤的 整个 job、flow 风格步骤）当时全绿。现在： - `split_items()` 按 YAML **列表项**切块（每个 `- ` 起一项；比当前项深的行归当前项；同级或更浅的 非列表行**结束**当前项）。项名 = 该项内**同级**的 `name:` 键（键序无关；`run: |` 块里的 `name: dummy` 不算；`run: echo "name: x"` 也不算）。 - **默认拒绝**：落不到列表项上的行（`jobs:` 之前的孤儿行、job 级 `run:` 这类项外键）带 feature 即红； 没有 `name:` 的项带 feature 即红。不再有「继承上一块」这回事。 - 三条复审注入 + 本轮新增三条（`jobs:` 之前的孤儿行、`run: |` 里夹带并伪造 name、shell 变量拼接） 都进了自测向量；在**真仓库文件**上重跑也是全红。 P2-2（同族误杀）： - 键序无关：允许的那一步把 `run:` 写在 `name:` 之前仍绿（旧实现会报到上一块的名字上）。 - `cargo hack check --all-targets` 不再被误判成 `--all`（正则收紧到 `--all(?![-\w])`）。 - Cargo 的 `update-test-source = [ … ]` **跨行声明**不再被误判成「写进了别的 feature 列表」 （`scan_manifest` 增加 `in_declaration` 状态）。 P2-3 `Fixture::run` 的第二条断言比错对象：原来比夹具字段 `self.dest`，手写 `fx.run(&["apply","--dest","<测试二进制>","--json"])` 两条都过。现在从 `args` 里解析真实 `--dest` 值（含 `--dest=` 形式）再 canonicalize 比较；夹具字段那份作为额外一道保留。 P2-4 `release-guard.yml` 的步骤级注释还停在 r1 的扫描面：改成「含复合 action / packaging 递归 / Makefile 等 + 归属按列表项判 + 唯一允许 ci.yml 的 update-e2e 一步」。 自测数据搬到 `packaging/tests/guard_vectors.json`（基线 8 个文件 + 26 条向量：21 红 / 6 绿）， 脚本本身从 379 行降到 373 行（守门仍 ≤400）；README §14 补上归属规则与「抓不住」清单。 验证（本机，全部 exit 0）： - 守门正式扫描绿；`--self-test` 21 条注入全红 + 6 条基线/放行绿；向量文件缺失时 exit 1（不静默）。 - **真仓注入**（在真 ci.yml / release-build.yml / cli/Cargo.toml 上改完即还原）：复审三条（无名步骤 / 无名 job / flow 步骤）全红；本轮新增三条（孤儿行 / `run: |` 夹带 / shell 拼接）全红； 三条合法写法（键序、`--all-targets`、跨行声明）全绿；还原后基线绿。 - E2E：debug 6 绿、release 6 绿（`running 3 tests` ×2，0.26s / 0.23s，非 0 measured）。 - `cargo clippy -p unlucky-cli --all-targets --features update-test-source -- -D warnings` 干净； `cargo fmt --all -- --check` 干净；全仓 400 行扫描无超限（守门 373 / 向量 194 / ci.yml 317）。 约束遵守：未 push；`PUBLISH_SLOTS` 只列 `windows-x64`（未动）；release 侧仍无该 feature；跨卷 bug 未碰。 ⚠ 仍未验：CI 里 E2E 真跑起来本机验不了（只证明 workflow 写对 + 守门放行，首跑要等推送后看 Actions）。	2026-11-08 11:12:11 +08:00
worker-updatee2e	28bf104041	fix(m169): 复审 r1 五条 p2 —— 守门开一个极窄 allowlist 并把 E2E 真接进 CI ... r1 复审（reviewer-updatee2e-r1，p2-5items，均不挡合并）逐条落地： P2-3（本轮主产出）守门把「E2E 进 CI」这条路堵死了：`scan_enabling_text` 对 workflow 里任何该 feature 字面量判红，于是 `cargo test --release … --features update-test-source --test update_e2e_test` 这种**合法调用**也红，自己登记的 follow-up 无法实现。现在： - `ALLOWED_STEP = {workflow: .github/workflows/ci.yml, name: update-e2e, must_contain: --test update_e2e_test}`；按 `- name:` 把 workflow 切成步骤块再判，文件名 / 步骤名 / 命令行**三者任一不符即红**（job 名不参与判据：改 job 名不该解锁新能力）。 - `ci.yml` **新增一个独立 job** `update-e2e`（windows-latest、timeout 45m、release 档；现有 job 一行未动，纯追加 27 行）。只在 Windows：夹具的「真形状」是裸 `.exe` + `portable-exe`，Linux/macOS 的真实产物是 `.tar.gz` + `portable-zip`（会被 `ensure_self_replaceable` 直接拒），在 ubuntu 上跑绿 是假绿。不降 debug：`debug_assertions`/优化/panic 行为都不同。 - self-test 覆盖 allowlist 六向量（允许 / 换文件 / 换步骤名 / 缺 `--test` / 发布工作流 / ci 内另一步）。 P2-2 守门 8 条绕过：注释剥离改**引号感知**（`echo "#"; cargo …` 不再吃掉真命令）；扫描面扩到 `.github/actions/**`、`packaging/**` 递归子目录、`Makefile|justfile|Taskfile` 第二构建入口； `--all-features` 之外补 `cargo hack --feature-powerset|--each-feature|--all`。大小写/下划线变体按 复审结论写进「抓不住」表（cargo feature 名敏感，写错编不过，不算漏检）。 P2-1 GUI 人工验收命令根本跑不起来：`-p unlucky-launcher-iced` 是 bin 名，改成 package 名 `-p unlucky-app-iced`（app-iced / presenter 两处，并写明 `-p` 只认 package）。 P2-5 夹具缺「不给 --dest 就 panic」的结构性保险：`Fixture::run` 加两条断言——`apply` 必带 `--dest`、`--dest` 不许等于本进程 exe 的 canonical 路径。抓得住「以后有人手写 fx.run(&["apply"])」， 抓不住「绕开 Fixture 直接调 unlucky_cli::run」。 P2-4 夹具「真形状」只在 Windows 成立：写进 `tests/support/update_e2e.rs` 文件头（说明 Linux 上跑绿 是假绿、CI 因此只在 Windows），**不改断言**。另按复审 ⑤ 补一行：失败路径三例抓不住回滚/备份 （摘要失败发生在 install_staged 之前），回滚靠正路备份断言 + install_cases。 跨卷替换 bug 按 tower 指令**未动**（另开 mission）。 验证：守门正式扫描 + self-test 绿（14 红 / 3 绿）；真仓注入 6 组（基线绿、步骤改名红、缺 --test 红、 搬进 release-build 红、改 --all-features 红、还原绿）；E2E debug 6 绿、**release 6 绿**； `cargo clippy -p unlucky-cli --all-targets --features update-test-source -- -D warnings` 干净； `cargo fmt --all -- --check` 干净；全仓 400 行扫描无超限（守门脚本 379 行、ci.yml 317 行）。 ⚠ 未验：CI 里 E2E 真的跑起来这件事本机验不了——只证明 workflow 写对 + 守门放行，首次真实运行要等 推送后看 Actions。	2026-11-08 11:12:11 +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	1d2e84ed61	fix(m163): push tag 默认建稳定版（发布标记语义 + 0.2.3 bump） ... 发布标记：`release.yml` 的 dispatch `prerelease` 默认值 true → false；`release-publish.yml` 的 create 路径不再塞 `--prerelease`（空串 = push tag ⇒ 稳定版），edit 路径行为不变（空串不碰 标记）。三种触发各创建什么改由 `packaging/release_marker.py` 一张表定义，流水线 `--emit-bash` 出来两个数组直接用，自己不再写 case——v0.2.2 至今 `releases/latest` 404 的根因 就是「push 默认 prerelease」这层叠上「dispatch 默认 true」。 守门：新增 `packaging/check_release_semantics.py`（CI 在 `.github/workflows/release-guard.yml`， guards.yml 已 398 行不能再挂 job）：①标记表逐条对（push tag 的 create 不含 --prerelease）； ②把 `--emit-bash` 真灌进 bash 读回两个数组；③publish 的可执行内容里没有 --prerelease 字面量、 必须调用 emit-bash、两个数组各喂 create/edit；④release.yml 的 dispatch 默认值 == false（读 YAML 结构）。`--self-mutation` 注入三项真实回归（默认值改回 true / 塞回字面量 / 表里 push 改成预发布），断言每项都红、基线绿。 版本：0.2.2 → 0.2.3（workspace `[workspace.package]` + 五处 path 依赖 pin + Cargo.lock）。 文档：README 中英两版版本行改 0.2.3，并把本阶段能力补进现有章节（Modrinth 匿名在线内容源、 自更新与稳定通道、整合包导入逐文件决策、实例级启动参数），删掉「没有自动更新通道」「导入只有 两份全局策略」两条过期说法；`release-notes.md` 写 0.2.3 的真实更新摘要（保留 {{VERSION}} / {{SUMS}}）；`packaging/README.md` 与 `docs/build-and-ci.md` 里「push 默认仍 prerelease」的旧口径 全部改掉。	2026-11-07 18:56:01 +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	06fe12d811	chore(release): M154 版本升到 0.2.2（第一个稳定通道版本，D51） ... - 根 Cargo.toml `[workspace.package] version` 0.2.1 → 0.2.2；`crates/{agent,app-iced,cli,palette-extract, presenter}` 里 9 处 intra-workspace path 依赖的 version 约束一并对齐（M137 既定做法）。`crates/app` 是 workspace `exclude` 的 Slint 退役树，manifest 不参与解析，原样保留。 - Cargo.lock 由 cargo 再生成：只有 8 个 `unlucky-*` 成员条目从 0.2.1 变 0.2.2，第三方依赖（含版本号恰好 也是 0.2.1 的 hexf-parse / windows-link / windows-threading / xkeysym / yazi）一字未动。这一步不是可选： CI 与发布流水线全走 `--locked`（ci.yml:236,274 / release-build.yml:135,142 / make_artifacts.py:50）， lock 不跟就是「tag 一打就红」。 - packaging 文档里的**示例 tag** 跟到 v0.2.2：docs/artifacts-and-version.md 两处（命名规则示例 + 「tag 说 X、产物里写 Y」的事故示例）、docs/build-and-ci.md 三处（`--version v…`、两次 `gh workflow run --ref v…`）、 docs/profiles-and-measurements.md 的「同一槽位现在叫 `unlucky-launcher_0.2.2_windows_x64.exe`」、 make_manifest.py 四处（Usage 示例 / `normalize_version` docstring / `--version` 的 argparse help）。 - **历史注记一律不动**：docs/runtime-deps.md 的「v0.2.1 首次真跑即红在工具链体检」（M140 事故记录）、 `.github/workflows/release.yml:71` 同一事故的另一处记录、`crates/core` 更新模块测试里的样本版本串 （`checker_cases.rs` / `version_cases.rs`，是解析器测试夹具，不是发布事实）、`microsoft.rs:224` 的 `21.0.13.0.2.1` 负例。 - README.md / README.zh-CN.md、packaging/release-notes.md 核实后**无需改动**：三份文件里没有任何写死的 版本号——下载表是 `<version>` / `<版本>` 占位符（M153 刚统一的口径，含非发布档位标「暂未发布」的行， 原样保留未回退），release-notes 正文是 `{{VERSION}}` / `{{SUMS}}` 模板占位符。 验证：`cargo check -p unlucky-cli --all-targets --locked` 过（编译日志里 unlucky-core/agent/cli 均报 v0.2.2）、 `cargo test -p unlucky-cli --lib --locked` 42 passed 0 failed、`cargo metadata --locked --offline` 过（全 workspace manifest + lock 一致）、`python3 packaging/make_manifest.py --self-test` ok、 `ull --version` 实跑输出 `ull 0.2.2（unlucky-cli）`。	2026-11-07 08:13:29 +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	54b81cbb7f	chore(release): M137 版本升到 0.2.1，发布只发两个 Windows 槽位 ... 版本：`[workspace.package] version` 0.2.0 → 0.2.1，并把全部 intra-workspace path 依赖的 version 约束一并对齐（`"0.2"` → `"0.2.1"`，M121 的教训）。Cargo.lock 里只有 8 个 unlucky-* 成员条目变化。`crates/app` 是 workspace `exclude` 的 Slint 退役树（manifest 连解析都过不了），不参与解析，故原样保留。 release.yml：新增 `PUBLISH_SLOTS` 白名单（唯一开关）＝ `windows-x64 windows-arm64`。 六槽位一律构建取证，release job 先按白名单裁掉 Linux/macOS 四档产物再重算 SHA256SUMS， 所以 tag 触发的 Release 只有 4 个资产 + SHA256SUMS.txt。release job 改成 `always() && !cancelled()`：未验证槽位构建失败不连坐 Windows 发布，真正的门禁是白名单 齐全性检查。将来某槽位真机验过后把它加进那一行即打开。 顺手修掉一处从未生效的门禁：齐全性检查的 glob 用的是连字符形态 （`dist/$prefix-*-$slot*`），对 D49 之后的下划线资产名永远匹配不上，改成 `dist/${prefix}_*_${stem}*`。资产命名规则 / SHA256SUMS / 合规文本并列资产 / `--version` 与 tag 交叉校验一律未动。 packaging/release-notes.md：清掉 v0.1.0 / Slint 时代的说明，Downloads 与 Support matrix 只描述本版实际发布的 Windows 两个槽位（其余标「built by CI, not published」）。 packaging/README.md §1/§3/§9 同步 gate（矩阵加「本版发布」列、§3 写清白名单与打开办法）。 起手顺带把示例 tag 从 v0.2.0 更到 v0.2.1，并把「winit / femtovg」更正为「winit / wgpu」。	2026-11-05 21:30:13 +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	bf6b0c4126	build(release): workspace 版本 0.1.0 → 0.2.0，README 的 tag 事实改成 v0.2.0 口径 ... - Cargo.toml [workspace.package] version = 0.2.0；Cargo.lock 由 cargo 重新解出一致 （只有 8 个 unlucky-* 成员条目变动，第三方版本一字未动） - 各 crate 的 `unlucky-*` path 依赖 `version = "0.1"` 同步提到 "0.2"，否则工作区 根本解析不出来（cargo metadata 会报 `failed to select a version for unlucky-core = "^0.1"`）；crates/app 虽被 exclude、cargo 不读，也一并跟上避免将来 重新纳入时立刻解析失败 - core::launch::LauncherConfig 兜底的 launcher_version 改成 env!("CARGO_PKG_VERSION")， 不再是把版本写死一份（CLI / presenter 本来就这么写） - README.md / README.zh-CN.md：删掉「v0.1.0 是目前唯一的 tag / the only tagged release」 这类随 v0.2.0 发布即变假的陈述，改写成「v0.1.0 是最后一个 Slint 版 tag，v0.2.0 是 重写后的第一个 tag」；所有讲 v0.1.0 资产 / Slint Royalty-Free 义务的历史记录原样保留 - packaging/README.md：命名与校验示例跟当前 tag 走（v0.2.0）；§7 实测记录里的 0.1.0 输出加一句「属实测记录、不回填」，并把过期的「四个 workspace member」改成「任何一个」	2026-11-05 14:08: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