43 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
AskaEth	3fcdc3d3e1	Merge branch 'feat/p4-design-token-extensions-component-met'	2026-11-01 17:10:04 +08:00
AskaEth	16bdad1b98	fix(design): M69 r1 —— SEARCH_BAR 内边距语义收口 + ComponentRadius 取值口上闸 ... P2-1（语义缝隙）：`SEARCH_BAR` 的 pad_start / pad_end 原为 16，与 icon_offset = 4 按字面相加得 20，比官方图标可视边 16 多 4px（越过 rubric ±2px 容差）；而被加数的 12 不在 CM 里，消费方只能自己写 12.0 —— 正是 G10 要消灭的字面量。改为 12（文本框内容内边距，Space::X3）+ 4，两侧同式： 图标可视边 = pad + icon_offset = 16。字段文档写明求和公式；测试钉死 pad + offset == 16 且 pad != 16（防有人把 16 写回 pad 再叠加）。 顺带给 SEARCH_BAR.gap 补 [估] 出处（官方无图标↔文字 token）。 P2-2（绕过路径）：ComponentRadius::dp() 收成 pub(crate)。它不看尺寸、 无条件返回 2.0，公开等于把 D32 的尺寸闸交给自觉。对外唯一取值口是 radius_px(size) -> Option<f32>；ALL 只暴露变体名、不暴露数值。 tokext_pins 原用 dp()，改为紧邻的 radius_px(20.0) == Some(2.0)，覆盖不丢。 顺手：修掉本轮新引入的 rustdoc warning（component_map 文档链到私有模块 metrics，改指 ComponentMetrics）；Divider 行标注 motion/duration 为占位， 并在 ComponentSpec 的 text / motion 字段文档写明「无文字 / 无动效的组件 这里是占位值，消费方不得据此排版 / 排动效」。 门禁：test 165 全绿、fmt --check、clippy -D warnings、check --workspace --all-targets、doc（warning 2 → 1，只剩既有的 typography→emphasized 一条）。	2026-11-01 17:05:19 +08:00
AskaEth	141e9b12c7	feat(design): M69 令牌补齐 —— 圆角分层 / 组件微度量 / 骨架值与一像素线 ... G13（D32 分层）：新增 shape::ComponentRadius（白名单只有 Micro=2）、 MICRO_CONTROL_MAX_SIZE=24 与纯函数 radius_layer_for()；微半径走 radius_px(size) -> Option<f32>，尺寸 >24dp 一律 None，靠签名而不是自觉拦。 ShapeScale 与 rank() 一个字未动，2 不进刻度。 G11：LayoutMetrics 加 search_bar_height=56 / nav_rail_width=88 / nav_drawer_width=240 / divider_thickness=1；删除语义相反的 nav_expanded_width=88 / nav_collapsed_width=48（D33：展开 drawer 240 / 折叠 rail 88；值 88 的后继是新名字 nav_rail_width，48 无后继）。 G10：新增 component_map::ComponentMetrics（12 字段 + 4 个命名常量 + indicator_width），入口 Component::metrics()；框内几何与 LayoutMetrics 的 骨架值分工写进模块文档，骨架级尺寸在 CM 里留 0 不许重复。 G9：Component 末尾追加 Checkbox / Radio / Search / NavigationDrawer / Divider（20 -> 25），同步 table.rs 槽位、ALL 与 name()；ComponentSpec 新增 micro_radius（Some 时 shape 必须是占位 None，由构造器 + 测试钉死）。 G12：新增 spacing::stroke::HAIRLINE = 1.0（crate 根再导出为 unlucky_design::stroke），divider_thickness 直接引用它。 其余：lib.rs 的「OKLCh 近似」文案改回真实口径（真 HCT / ColorSpec2021）； component_map 单测拆到 tests.rs 以免 mod.rs 超 400 行；测试 145 -> 165。	2026-11-01 16:53:30 +08:00
AskaEth	b89cc91b78	Merge branch 'feat/p4-design-exact-hct-color-scheme-hctcolo'	2026-11-01 16:40:38 +08:00
AskaEth	a4d86e9b19	docs(design): M65 r1 收口 —— 修正覆盖数量口径（290 项 / 8 个种子） ... 复审 P2-1：两处「验证覆盖数量」还停留在扩种子之前的旧值，只改文档文本。 - NOTICE：「242 项」→「合计 290 项」，并写出分项口径 （baseline 49 角色 × 2 模式 = 98；强调色 8 种子 × 12 角色 × 2 模式 = 192）。 这是 Apache-2.0 归属声明，覆盖范围写错比普通注释更该修。 - crates/design/src/color/mod.rs:51：「6 个种子」→「8 个种子 × 12 个强调族角色 × 2 模式 = 192 项」。 顺带核对了 242 的来历：242 = 98 + 6×12×2 = 98 + 144，是扩到 8 个种子之前的旧值，过期而非算错。 配色相关的 HCT 彩度措辞（#E8DEF8 是 16.096 而非 11.9）此前只出现在我的完成报告里，代码/文档/测试 均未写入 11.9（已 grep 确认），故无第三处改动。 不动代码、不动测试、不动阈值。	2026-11-01 16:40:36 +08:00
AskaEth	29f65b8e6f	feat(design): M65 真 HCT 色彩 —— CAM16 + ColorSpec2021 + 官方逐角色对齐 ... 把 M61 的「OKLCh 近似 CAM16 + gamut 硬裁」换成官方的 HCT 算法，与 material-color-utilities（Apache-2.0）逐角色对上：baseline 49 角色 × light/dark、8 个种子 × 12 个强调族角色 × 2 模式，**实测每通道误差 0** （判据写入测试：≤1）。 实现（逐函数对照官方 Java 重写为 Rust，f64 内部精度）： - color/cam16.rs + viewing_conditions.rs：CAM16 色相/彩度（D65、200 lux、 背景 L* 50），默认观察条件的中间量与 Java 实测逐位对齐 - color/hct_solver.rs + critical_planes.rs：官方 gamut 映射（Newton 迭代 + 色调平面上的色相二分，255 项关键平面表原样搬运），只压彩度不硬裁 - color/hct.rs：HCT 坐标（hue/chroma/tone），公开给工具与测试 - color/space.rs：官方 ColorUtils 的 sRGB↔线性↔XYZ↔L* 换算（矩阵、阈值、 取整口径一致） - color/palettes.rs：Tonal Spot 官方彩度常数 36/16/24/6/8，error 25°/84 - color/scheme.rs：tone 表换 ColorSpec2021（on-*container 10→30、 background 99/10→98/6） 两个旧缺陷关门： - primary-container 与 secondary-container 不再撞色（彩度 36 vs 16， tone 90 装得下，无需「共享基准压彩度」补丁）；reference_chroma / tone_scaled 随之删除 - 强调色色相不再被 gamut 硬裁（只压彩度，实测偏移 <1°） 对齐证据：tests/official_baseline.rs（98 项 + 12 个 HCT 探针）、 tests/official_accent.rs（192 项）。期望值是把官方 Java 实现本机编译运行 的输出抄本，并用 Flutter 的 ColorScheme.fromSeed 用例交叉验证 （#00FF00 → #406836、#000000 → #8C4A60、#FFFFFF → #006874 一致）。 诚实口径：只做 Tonal Spot 变体 + contrastLevel 0；对比度三档、其他变体、 壁纸多色取色、非默认观察条件都在模块文档的 gap 表里登记。 注：token_pins 的 tone 值变化来自官方算法（ColorSpec2021），不是为过测试而改。 NOTICE 增「Google Material Color Utilities」归属（Apache-2.0 要求， 含逐文件映射与对齐方法）。	2026-11-01 16:40:36 +08:00
AskaEth	958ced2d7e	Merge branch 'feat/p3-guards-file-size-cover-py-sh-guardsiz'	2026-11-01 16:22:54 +08:00
AskaEth	95e8a5ca42	fix(ci): M67 文件行数守门补上 *.py / *.sh —— 脚本不再漏网 ... file-size job 原先只扫 *.rs/*.md/*.slint/*.yml/*.yaml/*.toml/*.json， packaging/ 下的构建辅助脚本（make_artifacts.py、check_screenshot.py、 linux-smoke-docker.sh）完全没有任何行数保护。 - 在 git ls-files 的 pathspec 末尾加 '*.py' '*.sh'，语义不变（>400 行即硬失败） - 保留 LICENSE*/CHANGELOG* 排除；Cargo.lock 等机器生成文件刻意不入列 - 阈值、失败方式（::error + exit 1）均未改动	2026-11-01 16:22:51 +08:00
AskaEth	0aac307d92	Merge branch 'feat/p3-ci-headless-render-smoke-xvfb-xplatci'	2026-11-01 16:15:49 +08:00
AskaEth	7e08e0ccc9	fix(docs): M62 r1 —— 修正「缺字体→空图+exit 0」的错误论据，拆出运行时冒烟细节文档 ... review r1（p2-1items/fix-then-merge）只要求改文档与注释，门禁逻辑一行未动。 - P2-1（唯一阻塞项）：原稿称「字体库缺失 → 合法 PNG + 退出码 0」，这是错的。review 实测两条失效都是 **硬失败**：完全没有字体 → fontique panic（退出码 101，不产生 PNG）；非软渲染（默认 femtovg）→ `take_snapshot is not supported by this FemtoVG backend`（退出码 1）。改正口径：`--screenshot` 的 PNG 是进程自己编码写出的，只要走到 `take_snapshot` 就是「合法 PNG + 退出码 0」，像素断言是**纵深防御**， 守的是「进程活着、PNG 合法、但场景几乎没画」这一档；其余情形本机暂无样本，属防御性设计、不宣称已复现。 落点：packaging/ci-runtime-smoke.md §1 与 packaging/check_screenshot.py 模块 docstring。 - P3-1：ci.yml 的 runtime-smoke job 头补一行 —— 本 job 绑死 Slint `Window::take_snapshot`，迁 iced 后必须 提供等价离屏截图通道，否则静默退化成「能起进程」。 - P3-2：阈值余量写明量级（342/64=5.3×、19.45/3.0=6.5×、0.00761/0.001=7.6×，改「5~8 倍」）；并写明 闸门下限 ≈「至少画出一条标题栏」（review 实测切片 174/35.10/0.02623 与右下 400×300 切片仍 pass）， 即只证明「场景被真实渲染过」，不证明元素齐全、更不证明视觉正确。 - P3-3：README 398/400 已贴红线 —— 借 review 给的逃生口**提前拆**：细节搬进 packaging/ci-runtime-smoke.md （78 行），README §11 收缩为 12 行索引（374 行），并写明「再增长继续往细节文档写，两文件都 ≤400」。 - P3-4：本地复跑示例改 Windows 安全路径 `D:/tmp/ull-smoke`；脚本对 repo_root/out_dir 统一 `cygpath -m` 归一并回显真实路径（Git Bash 下 `/tmp` 会静默落进 Docker VM，宿主什么都收不到 —— review 实测踩到）。 - P3-5：两个 `run:` 里的 `set -o pipefail` 保留但加注释说明「当前无管道，为将来加管道先有失败传播」； `cargo clean -p unlucky-app || true` 加内联注释（N7 兜底，CI 里没有对应行，别误抄进 ci.yml）。 验证：`--selftest` 三组仍全部 fail（判红能力未被改坏）；真实截图仍 pass（1180x760 / 342 / 19.45 / 0.00761）； 0 字节与非 PNG 路径 exit 1；`yaml.safe_load` 通过（6 job，Linux 槽位无 continue-on-error，artifact 步 `if: always()`）；`cargo fmt --all --check` 退出 0；cygpath 修复后重跑 Docker 冒烟，宿主机 D:/tmp/ull-m62-rev2 拿到 PNG，md5 `156c382a…` 与前两次 run 及 review 的 artifact 完全一致。	2026-11-01 16:15:47 +08:00
AskaEth	ea5f66cf92	feat(ci): M62 —— Linux runtime-smoke（xvfb 真渲染一帧）+ 像素非空白门禁 ... 「编得过」不等于「跑得起来」：CI 里 Linux/macOS 此前只 build + test，从未创建过真实图形窗口。 本 commit 补第一份 Linux 真实图形环境运行证据，并把它做成不可伪造的门禁。 - ci.yml 新增 runtime-smoke（ubuntu-latest）：装 xvfb + 软渲染/字体依赖，用 xvfb-run 起 GUI 进程， 走既有 `--software-renderer --screenshot` 通道渲出一帧 PNG，再断言 ①退出码 0 ②PNG 宽高 > 0 ③非空白（唯一色数 / 亮度σ / 强边缘占比三项过阈值），并把截图作为 artifact `runtime-smoke-screenshot` 上传。 既有 fmt/clippy/test/build 四个 job 与触发器语义零改动（纯追加）。 - ci.yml 新增 runtime-smoke-macos 探针：只在 workflow_dispatch 触发且 continue-on-error。官方 macOS runner 处于 LaunchDaemon 上下文、无 WindowServer 会话，大概率建不了窗口；本机无 macOS 且 worker 禁 push，这条路径尚无实测证据，故不拿它卡 PR 门禁（首跑结论决定升常驻或按 D26 归入 iced 重写）。 - packaging/check_screenshot.py：零第三方依赖的 PNG 解码（zlib + 反过滤 0~4）与三项指标判定， `--selftest` 打印阈值依据（人为纯色帧 1/0.0/0.0 必红，真实帧 342/19.45/0.00761 全过线）。 - packaging/linux-smoke-docker.sh：在 Docker 里复刻同一 job（TUNA apt/rustup 源），便于无 Linux 桌面的本地复跑。 - packaging/README.md §11：覆盖平台、阈值依据数值、本地复跑、已知跳过项、迁 iced 后需重新验证。 本机实测（Debian 12 容器 + xvfb + 软渲染）：退出码 0，PNG 1180x760，唯一色 342 / σ 19.45 / 强边缘 0.00761。 CI（Ubuntu 24.04 runner）首跑仍未验证——本 job 证明「能出图」，不证明视觉正确。	2026-11-01 16:15:47 +08:00
AskaEth	a681ccb526	Merge branch 'feat/p4-design-system-tokens-typography-icons'	2026-11-01 16:06:40 +08:00
AskaEth	83e19e58f0	fix(design): M61 r1 收口 —— 官方 emphasized/弹簧/高程 + 冻结测试 ... reviewer r1 判 p2-2items（fix-then-merge），本轮按条目收口： P2-1 冻结测试补全（变异实测证明原来可静默漂移）： - tests/type_scale_pins.rs：baseline 15 档 (size,line_height,weight,tracking,family) 与 Expressive 强调 15 档逐值对拍，期望值独立于实现重写 - tests/token_pins.rs：49 条 tone（light+dark 全表）、7 条 easing 曲线参数、 16 档时长、9 组弹簧、28 个 IconKind 下标、形状阶梯 - 自证：TitleMedium 16→17 与 EmphasizedDecelerate 换曲线两次变异均 FAILED P2-2 emphasized 口径事实错误（用户点名）： - 取回 A 级官方值（androidx TypeScaleTokens v0_103 的 *Emphasized* 四元组）： label-*/title-medium/title-small 强调是 700（此前给 600）、body-large 0.5→0.15、 title-medium 0.2→0.15、body-medium 0.2→0.25、display-large -0.2→0 - TypeRole::emphasized() 改为官方表（typography/emphasized.rs）； 原「只加一档字重」规则改名 emphasized_simplified() 并标注非官方 - 顺带按官方订正 baseline tracking（display-large -0.2、body-medium 0.2、 title-medium 0.2）与 TitleLarge 的 Brand 族归属 - crate 文档新增「baseline MD3 vs M3 Expressive 差异清单」+ 未支持能力 gap 弹簧改为两套 token 结构（用户追加令）： - motion::spring(scheme × category × speed) 二维表 12 格： standard spatial ζ=0.9 (k 1400/700/300)、expressive spatial ζ=0.6~0.8 (k 800/380/200)、 effects 两套同值 ζ=1.0 (k 3800/1600/800)，均取 A 级 MotionTokens 原值 - Spring 改存阻尼比（与 Compose 令牌同口径），9 个具名常量 中文字重覆盖（用户追加令）： - FontFace 带 WeightCoverage（可变区间/静态表），Platform::resolve_weight 给 Native/Nearest/Synthetic 三档结论；雅黑无 500、苹方无 700 两处 gap 显式登记 component_map 高程按官方回调（P2 并入 finding）： - FilledCard L2→L0、OutlinedCard L1→L0、Menu L4→L2、Dialog L5→L3（Menu 圆角同时 按 MenuTokens 改 4dp）；新增官方值 pin 测试 + R4「全屏都在飘」守门断言 P3 四条： - 同族容器撞色：彩度按共享基准等比压缩（Palettes.reference_chroma）， primary/secondary-container 不再同值，且强调色覆盖时表面逐像素不变 - femtovg 引用改函数名（行号已漂）；删掉 contrast_aa 的死代码后门 - 骨架数值跟 M63：nav 56→44、titlebar 40→48，control 40/touch 48 换算依据入文档 - 图标折算口径订正为「居中描边，视觉外扩 <1px」	2026-11-01 15:58:19 +08:00
AskaEth	65ca0ed29a	feat(design): 加 unlucky-design 令牌 crate（M3 色彩/排版/形状/动效/图标） ... D26 把视觉基线锁到 Material 3 Expressive，本 crate 是「UI 整体性」的地基： 令牌唯一真源，后续 iced 页面只消费不新增。零第三方依赖、零 UI 框架依赖 （cargo tree -p unlucky-design --edges normal 只有它自己一行）。 - 色彩：49 个 M3 语义角色 × light/dark，种子色派生 6 条 tone 调色板； tone 轴严格用 CIELAB L*（偏差 ≤1），色相/彩度用 OKLCh 近似 CAM16 并在 模块文档里写明口径与已知偏差（不宣称是标准 HCT 动态取色） - 对比度：26 组文字对 × 6 组种子 × 2 模式全部 ≥4.5:1；3 条例外显式登记 （Outline 非文字 3:1、OutlineVariant 装饰、SurfaceVariant 是容器色） - 排版：M3 type scale 15 档 + 三平台字体族回退栈（只写族名，不内嵌受限字体） - 形状/高程/动效：Expressive 形状刻度 + shape morph 数据、elevation 级别与 surface container 映射、时长/缓动/弹簧（纯函数可采样） - 图标：24 个从 Slint 版迁移的 SVG path + 4 个新增，IconKind 冻结只可末尾追加； 写明 Slint 的 stroke-width 是绝对像素、SVG 是 viewBox 用户单位的语义差异， 换算封装成 Icon::stroke_width - 组件档位表：20 个组件的形状/高程/字体/动效一次取全 TODO(M63)：elevation shadow 的 blur/offset/alpha 与四组弹簧参数是占位值， 接口先定、数值待玻璃视觉规格表（tower 已通告边界）。	2026-11-01 15:34:04 +08:00
AskaEth	fef0922073	Merge branch 'feat/p3-release-linux-arm64-slot-linuxarm'	2026-11-01 14:21:12 +08:00
AskaEth	4c1a6c54e5	fix(release): M51 r1 —— linux-arm64 改用 ubuntu-22.04-arm（与 x64 同 glibc 2.35 地板） ... P2-1：24.04-arm 会给出 2.39 地板，把 Debian 12 / Raspberry Pi OS Bookworm （2.36）挡在门外，且「arm64 只有 24.04 档」这句前提是错的（同段注释自己就承认 ubuntu-22.04-arm 有效）。改 os 为 ubuntu-22.04-arm，注释改成「与 x64 同地板 （2.35），覆盖 Debian 12 / Ubuntu 22.04 arm64 / RPi OS Bookworm」； README §3/§4/§7.5/§9 与 release-notes 的 Downloads/Support matrix 全量订正 2.39 → 2.35+，删掉「arm64 地板高于 x64」的对比措辞。槽位名、产物名、六槽位 齐全性检查与打包脚本均未变。 P2-2：rustup target add 步骤改 env TARGET + `rustup target add "$TARGET"`， 并补 shell: bash（此前是全文件唯一没显式 shell 的 run，在 Windows 槽位会落进 pwsh）；Linux 图形栈依赖那步也补了 shell: bash，现在所有 run 都显式 bash、 run 块内零 `${{ }}` 直插。 顺带 nit：host_slot() 报错改回原始 arch token（`riscv64` 不再显示成 None）， README §7.5 宣传的那个用例现在诊断可读。 验证：yaml 结构断言（六槽位 / linux-arm64=ubuntu-22.04-arm / 齐全性循环 6 / run 块 ${{ }} 零泄漏 / run 步骤全带 shell）、全部 run 块 bash -n、grep 2.39 零残留、host_slot 7 组合注入 + freebsd/riscv64 报错含原名、image_arch 真 exe、 windows-arm64 stub 全流程、架构守卫拦截、linux-arm64 归档两次 sha256 一致 （f949d0f5… 与上一轮相同）、windows-x64 原生回归（冒烟 + sha256sum -c）。	2026-11-01 14:16:29 +08:00
AskaEth	15caa1b61f	feat(release): M51 —— 发布矩阵补 Linux arm64 与 Windows arm64 两槽位（六槽位） ... - release.yml：加 linux-arm64（原生 ubuntu-24.04-arm runner）与 windows-arm64 （windows-latest 上交叉编译到 aarch64-pc-windows-msvc）；产物根改由 matrix.build_dir 参数化，dumpbin 自检与打包都吃矩阵路径而非硬编码 target/release； 交叉槽位多两步（rustup target add + ARM64 库体检），release job 的槽位齐全性 检查从四扩到六。 - make_artifacts.py：--slot / --build-dir 参数化 + 六槽位映射；打包前回读可执行文件头 （PE 机器码 / ELF e_machine / Mach-O cputype）校验架构，跨槽位构建自动跳过 ull --version 冒烟并打印原因（不在 x64 上假装跑得动 arm64 二进制）。 - packaging/README.md + release-notes.md：两张支持矩阵同步加 Windows 11 ARM64 与 Linux arm64 行；arm64 glibc 地板如实写 2.39（高于 x64 的 2.35），并说明与 Termux 实验级的区别（这两个是正式发布槽位）。 本地验证：宿主判定注入（七个组合 + 非法宿主 exit 1）、文件头架构识别（真 x64 exe + 合成 PE/ELF/Mach-O 头）、windows-arm64 stub 全流程、架构守卫真拦、linux-arm64 归档 两次 sha256 一致、windows-x64 原生回归（冒烟 + sha256sum -c）。arm64 真机构建由 CI 补。	2026-11-01 13:48:37 +08:00
AskaEth	0bfe22aa6f	Merge branch 'feat/p3-release-windows-dumpbin-locator-fix-d' v0.1.0	2026-11-01 13:06:12 +08:00
AskaEth	a6013c7d22	fix(ci/release): M50 —— Windows 槽位 dumpbin 定位链改三级（vswhere → find → PATH） ... v0.1.0 首跑（run 41273841717）windows-x64 在「Windows 单文件自检」挂 `找不到 dumpbin，无法校验导入表（静态 CRT 门禁不降级）`。两个独立根因： - `command -v dumpbin` 在 windows-latest 上不成立：VS 环境未预置进 PATH。 - 兜底 glob 深度错了一级：写的是 `<VS 根>/<年>/VC/Tools/...`，真实布局是 `<VS 根>/<年>/<版次>/VC/Tools/...`（2022/Enterprise、2022/BuildTools）， 所以即便 PATH 失守、glob 也不可能命中。 - 且只扫了 64 位 `Program Files` 根，Build Tools 落在 `Program Files (x86)` 根。 改成三级定位链，全不命中才 fail（门禁语义一字未动：工具缺失仍 exit 1、 导入表出现 VCRUNTIME/MSVCP/MSVCR/ucrtbase 仍 exit 1，文案不变）： 1. vswhere —— VS 官方定位器，安装器自身路径固定，与 VS 版本/版次/布局无关： `.../Installer/vswhere.exe -latest -products '*' -find <pattern>`。 模式先试反斜杠（官方文档形式）、再试正斜杠，输出统一折成正斜杠后再执行。 2. find 兜底 —— 两个 VS 根（64 位 + x86）按路径模式扫，`-maxdepth 11` 留一级余量，不再依赖固定层数的 glob。 3. PATH —— 最后才试，PATH 最不可控。 另加一行 `dumpbin: <路径>（定位自 <层级>）`，下次真机挂掉能直接看出命中哪一级。 同文件其余步骤不依赖 VS 环境（已逐条核对），无需收敛。 验证（本机无 VS）： - 抽出 run 块 `bash -n` 通过；13 条 stub 用例全绿：无工具→fail 文案不变且不写 dependents.txt、vswhere 反斜杠/正斜杠两个模式、两处 VS 根 find 兜底、PATH 兜底、 动态 CRT 仍 fail-closed、vswhere 优先于 PATH、vswhere 输出的反斜杠路径归一化后可执行。 - 未改写的原始 run 块在本机实跑：干净 exit 1 + 原文案，不误命中、不崩。 - yaml 解析 + 23 条结构断言全过（矩阵四槽位、触发条件、门禁 grep/文案/exit 原样）； 文件 276 行 ≤ 400。 - git-bash 行为实证：`.exe` 的 `-x` 为真、非可执行文件为假、`find` 接受含空格的 `C:/Program Files` 根。 真机验证由 merge 后 retag 重跑流水线完成。	2026-11-01 12:58:40 +08:00
AskaEth	37ccaaf23f	Merge branch 'feat/p3-fix-game-java-discover-cfg-gating-jav'	2026-11-01 11:00:32 +08:00
AskaEth	dc4fac8391	fix(core/game): M49 —— Java 去重键平台无关归一化（Linux CI 三红） ... `game::java::discover::path_key` 只在 `cfg!(windows)` 分支折分隔符，POSIX 上 把 `C:\a\b\java.exe` 原样留成带反斜杠的键，与 `C:/a/b/java.exe` 不同键 → `dedupe` 不去重。三条用例（Windows 语义无 cfg 门）因此在 `test (ubuntu-latest)` 挂：`path_key_normalises_separators`、 `dedupe_keeps_the_higher_priority_source`、 `java_discover::dedupe_collapses_one_install_found_twice`。 - `path_key`：`\?\` 前缀剥离与分隔符折成 `/` 改为**与平台无关**（同一个 `bin/java[.exe]` 用哪种拼法都是同一个文件，键必须相同）；大小写折叠仍只有 Windows 做——POSIX 上 `Java` 与 `java` 是两个目录，折了会把两份真实安装误并。 已知取舍写进文档：POSIX 上文件名里的字面反斜杠会一并被当分隔符。 - 三条用例：不靠 `#[cfg(windows)]` 跳过。`path_key` 单测改成平台无关断言 + 大小写折叠的双侧断言（Windows 折 / POSIX 不折，两侧都钉住）；集成用例的 「同一路径第二种写法」按平台给（Windows 用大小写+分隔符，POSIX 用分隔符）。 - 回归钉子：新增 `one_install_normalises_to_one_key_whatever_the_spelling` （普通写法 / 反斜杠写法 / `\?\` 前缀写法 / 混合写法 四种拼法同键）与 `path_key_folds_case_only_where_the_filesystem_does`。 验证：Linux（rust:1-bookworm 容器，ull-linux-target 热缓存） `cargo test -p unlucky-core --lib --test game` → 224 + 120 passed / 0 failed （基线是 lib 220/2 failed、game 119/1 failed）； `cargo test --workspace --all-targets --no-fail-fast` → 34 个测试块 1137 passed / 0 failed（该次跑在 M48 launch 修复叠加的临时副本上，因为 M48 尚未合入 main，见报告）。Windows 本机 `cargo fmt --check`、 `cargo clippy -p unlucky-core --all-targets -D warnings`、 `cargo test -p unlucky-core` 全绿（17 个测试块 0 failed）。	2026-11-01 11:00:25 +08:00
AskaEth	38832df095	Merge branch 'feat/p3-fix-posix-tree-kill-ci-red-posixkill'	2026-11-01 10:48:15 +08:00
AskaEth	6ce825db8d	fix(launch): M48 —— POSIX 组杀假成功导致 stop() 空等超时 ... CI test (ubuntu-latest) 自 M43 起红的根因不是「组杀打到自身进程组」， 而是 procps-ng 的 kill 把裸 `-<pgid>` 当成又一个信号选项吞掉：退出码 0、 什么都没发。旧实现据此提前 return，单 pid 兜底永远不执行，于是 process_smoke::stop_kills_process_tree 与 pipeline_cases::pipeline_stop_records_killed_exit 只能干等 graceful+5s 预算后报「强制结束后进程仍在运行」。 - process.rs：Unix 分支用 CommandExt::process_group(0)（std 1.64+ 安全 API，无需 pre_exec/unsafe）让子进程自成一个进程组，与 Windows 的 CREATE_NEW_PROCESS_GROUP 对称；这也让「树」回收真正覆盖后代。 - tree_kill.rs：组杀改用 `kill -TERM -- -<pgid>`（`--` 不可省），并且 先过 group_kill_target 三重验证——目标必须是自己的进程组组长、必须 读得到我们自己的组、目标组不能就是我们所在的组；单 pid 兜底改为 「永远执行」，kill 缺失（NotFound）返回明确错误而不是静默失败。 pid==0 守卫从 kill_tree 提到 terminate/force_kill 共用入口。 - 测试钉子（Linux 门住）：spawn 后子进程 pgid == 自己的 pid 且 != 测试进程 pgid；组杀只接受验证过的独立组；组杀覆盖孙进程且不碰我们 自己的组；同组子进程靠单 pid 兜底仍能被干掉；pid 0 一律拒绝。 验证：rust:1-bookworm 容器（ull-linux-target 热缓存）cargo fmt --check、 cargo clippy --workspace --all-targets -D warnings、cargo test -p unlucky-core --test launch（82 passed，两条原红灯转绿）、cargo test --workspace --all-targets --no-fail-fast 不再被 SIGTERM 打断；Windows 本机 fmt/clippy/cargo test -p unlucky-core 全绿。	2026-11-01 10:32:18 +08:00
AskaEth	eaa1414847	Merge branch 'feat/p3-packaging-chore-six-p3-findings-packc'	2026-11-01 09:40:59 +08:00
AskaEth	62019a29cd	fix(packaging): M47 r1 P2 —— 重跑不再断言 pre-release 标记 ... reviewer 指出：edit 分支此前每次默认重跑都重传 --prerelease，会把用户按 README 建议手动提升为 stable 的 Release 静默翻回 pre-release，文档承诺"重跑 不翻转标记"不成立。按首选修法让代码匹配文档： - release.yml：create/edit 两套标记分开算。create 保持老契约（空输入 → 首建 pre-release）；edit 只在 inputs.prerelease 显式给出时断言 （true → --prerelease，false → --prerelease=false），空值（push 或其 Re-run） 不传任何标记。非法取值直接 ::error + exit 1。 - README §3：重跑语义与实现逐字一致，并把"改标记"的两条等价路径 （gh workflow run -f prerelease=false / 手动 gh release edit）与 dispatch 语义写顺；yml 头注释同步一句。	2026-11-01 09:37:55 +08:00
AskaEth	ea6016716e	chore(packaging): 收 M46 r1 六条 P3（dumpbin 门禁/ref 注入面/重跑幂等/文档口径） ... - O1 release.yml 找不到 dumpbin 从 ::warning+exit 0 改为 ::error+exit 1（门禁不降级）， README §7.4 同步为"两侧都 fail、没有降级分支" - O2 打包 step 改用 env REF_TYPE/TAG 传参，bash 里不再出现 ${{ }} 直插； release job 的 TAG/PRERELEASE 已是 env 写法，全文件复核无同类风险点 - O3 gh release create 改为 view 命中则 upload --clobber + edit，同 tag 重跑幂等； README §3 补重跑语义与 pre-release 标记以首次创建为准 - O4 yml 头注释与 README §3 点明 inputs.prerelease 只在 tag ref 上 dispatch 可达 （UI 只能选分支，需 gh workflow run --ref v<tag>），不与"dispatch 只构建不发布"冲突 - O5 release-notes 模板补 Termux 试验级行，README §9 同口径，标题改为"逐行一致" - O6 README §6 补 ci.yml 每次 push/PR 的 release build 吃 fat LTO 链接时间； 订正"fat 是全局单线程 LTO"为 codegen-units=1 导致单线程（§6/§7.1 两处）； §7.3 写入 reviewer 补测的 tar 可复现证据 a99d6e9e…92f8	2026-11-01 09:30:27 +08:00
AskaEth	92d8a705e8	Merge branch 'feat/p3-forge-neoforge-gui-install-via-proces'	2026-11-01 09:14:07 +08:00
AskaEth	d95c9664c6	fix(app): M45 r1 两条 P2（向导拒装文案 + 处理器段进度满格） ... P2-1：wizard.slint 的 Forge/NeoForge 提示还写着「需要 installer processors：本轮请用 ull install」， 改成「需要 installer processors（首装会外调 java，约 1–3 分钟）」；全仓再扫一遍 「ull install / 显式拒装 / 终端跑」等措辞，user-facing 文案已无残留（余下命中全是 OptiFine/LiteLoader 的正确说明与测试注释）。 P2-2：进度条在处理器依赖库下完那一刻就满格（36/36），随后加载器库的 29 个文件才被计入 → 100% 回落再涨回，且 bytes_total 用 .max() 与文件数对不上。 - Meter 新增 expect(files, bytes)：文件数与字节都 saturating_add； - install_loader 在处理器段之前就把加载器库的文件/字节一次预记账（两段之和）， 加载器库阶段只剩切阶段文案，不再记账； - Reporter::expect 改为委托 Meter::expect，处理器依赖库沿用同一条曲线； - 回归测试钉住：预记账后 files_total=95、bytes_total=17MB、ratio 不再满格， 处理器库下完仍是中间态，加载器库下完才到 100%。 真机重截 + 识图：D:/tmp/ull-m45-shots/forge-mid-fixed-25s.png —— 同一时刻面板 36/65 文件、3.4 MB/15.3 MB、进度条只填了约一半（旧图 36/36 + 满格）。	2026-11-01 09:14:02 +08:00
AskaEth	3d9372029e	refactor(app): 处理器测试夹具用 StepView 别名，过 clippy::type_complexity ... clippy --all-targets -D warnings 报 very complex type（RefCell<Vec<(usize, String, Vec<String>, usize)>>）， 抽 pub(super) type StepView 别名，语义不变。	2026-11-01 09:14:01 +08:00
AskaEth	b0f747074f	feat(app): GUI 接上 Forge/NeoForge installer processors（M45） ... - host/install_processors：GUI 与 CLI 同序跑 processors（计划 → 依赖库 → 选 Java → 串行 java -cp）， 进度经 HostTask::Install 回流（阶段文案 + 每步处理器名 + 文件/字节/速度/ETA），取消在阶段边界生效； - host/install_journal：安装过程追加到 .ULL/logs/install.log，失败文案带日志路径，不再静默失败； - host/install.rs：supported() 扩到原版 + Fabric/Quilt/Forge/NeoForge，删除 Forge/NeoForge 拒装路径 （仅剩 OptiFine/LiteLoader 两家 core 侧无管线者），spawn_install 统一持 Job 上下文； - 失败诊断：缺 Java / processor 非零退出（保留 processor_* 大类码与脱敏 stderr 尾部）/ 依赖库下漏 / 元数据缺失，均为结构化文案 + Toast + 装日志； - dto::InstallStage::Installing 文案改「生成版本」（同时覆盖写版本 JSON 与跑 installer 两段）； - screenshot：新增 --screenshot-loader，Forge/NeoForge 中间态可离屏取图； - 测试 +14（138 全绿）：supported() 语义、处理器阶段注入 fake 后端覆盖跳过/缺 Java/非零退出/ 依赖库失败/命令行构造/进度文案，另修旧用例（Forge 不再被门禁拒装）。	2026-11-01 09:14:01 +08:00
AskaEth	858c227900	Merge branch 'feat/p3-packaging-release-artifacts-matrix-pa'	2026-11-01 08:33:18 +08:00
AskaEth	76d83148ff	feat(packaging): 单文件产物矩阵 + tag 触发的 Release 流水线（M46） ... - packaging/make_artifacts.py：本地与 CI 共用的打包脚本 —— 版本取自 cargo metadata （tag 交叉校验，不一致即失败）、按宿主判定槽位、Windows 裸 exe / UNIX tar.gz （内含 LICENSE/NOTICE/README.md）、SHA256SUMS.txt；打包前跑 `ull --version` 断言版本； tar 内 mtime/uid 归零 + gzip header mtime=0 → 同源构建 sha256 可复现 - packaging/README.md：产物矩阵与命名约定、版本唯一真相源、各平台运行时依赖、 软渲染兜底、release profile 取舍、**本机实测**体积与冒烟证据、合规与支持矩阵 - packaging/release-notes.md：GitHub Release 说明模板（{{VERSION}}/{{SUMS}}， 写清 Win10+ / macOS 12+ / Linux x64 支持矩阵） - .github/workflows/release.yml：tag v* 触发四槽位矩阵 → 产物 + 重算 SHA256SUMS → gh release create（pre-release 默认开，workflow_dispatch 只构建）；Windows 用 +crt-static 并以 dumpbin 导入表把"单文件"做成硬门禁；归档内容自检 LICENSE/NOTICE/README - Cargo.toml：release profile lto thin → fat（实测 GUI 16,366,080 → 14,595,584 B = −10.8%，ull 7,572,992 → 6,157,824 B = −18.7%） 验证：cargo build --release 通过；GUI `--software-renderer --screenshot` 出 1180×760 PNG、 `ull --version` = 0.1.0；PE 导入表 33 个 DLL 全为系统库（无 VCRUNTIME/libwinpthread）； cargo deny licenses/bans/sources ok；workflow 用 python yaml 解析自检。	2026-11-01 08:33:17 +08:00
AskaEth	f9079f8ab0	Merge branch 'feat/p3-msa-authorization-code-flow-browser-l'	2026-11-01 08:33:13 +08:00
AskaEth	07fd6113a7	fix(core): 回调先校验 state 再处理 error，堵掉伪造取消失效登录 ... reviewer P2（crates/core/src/auth/microsoft/callback.rs）：handle() 先处理 error 参数、 之后才校验 state，于是任意一次 `GET http://localhost:{port}/auth?error=access_denied` （state 随便给甚至不给）都会让 wait_for_code 直接返回 Canceled，登录被静默中止、账户不入库 —— 不需要知道随机 state、不需要 code、不需要任何凭据。违反 RFC 6749 §4.1.2.1 / RFC 9207 （错误响应同样要校验 state），也与本模块「与本次登录无关的请求一律继续等待」的声明矛盾。 - state 校验提到 error 之前：state 不匹配的请求（无论带不带 error）一律 400 后继续等； 只有带**本机 state** 的 access_denied 才判 Canceled。模块文档第 4 条同步改写。 - 顺带采纳 reviewer 的两条非计数观察： * 读头预算改为 accept 之后按 deadline 重算（原来复用 accept 前的 remaining， 总时长可超发 ≤5s）；预算归零直接超时。 * state 由 64 位升到 128 位（两个独立随机种子的 SipHash 输出拼接），对齐 RFC 6749 §10.10 的熵建议；新增单测断言 32 位 hex 且每次不同。 - 新增回归用例（crates/core/tests/auth/microsoft_authcode.rs）： `foreign_state_cannot_cancel_the_login` —— 先发 `?error=access_denied`（无 state） 再发 `?error=access_denied&state=not-our-state`，两次都必须 400 且服务器继续等待， 随后真回调拿到 code；`access_denied_with_our_state_is_still_canceled` 钉住另一半语义。 既有的「陈旧 state 回 400 后继续等」用例保持通过。 门禁：cargo fmt --all --check OK；cargo clippy --workspace --all-targets -- -D warnings exit 0 无告警；cargo test -p unlucky-core -p unlucky-app 18 个 suite 全绿（auth 59 例）。 AskaEth <i@yeij.top>	2026-11-01 08:33:11 +08:00
AskaEth	8194e38bcf	feat(core): 加 MSA 授权码流（本地回调服务器）并接到账户页 ... research/08 方案 A：GUI 的微软登录改走授权码流（HMCL 主流做法），设备码流保留给 CLI/无浏览器场景。两条流只差「怎么拿到 MS access_token」，拿到之后共用 chain::complete_chain 与 MicrosoftSession，落盘/刷新语义没有第二套。 core（crates/core/src/auth/microsoft/） - endpoints：新增 authorize（…/consumers/oauth2/v2.0/authorize），与 token 同租户。 - authcode：RedirectUri 是 http://localhost:{port}/auth 的唯一来源（授权 URL、 token 请求体、实际监听三处共用，坑 5）；AuthCodePolicy（回调超时 300s / 绑定重试 3 次 / 固定端口 / 固定 state）；authorization_url（response_type=code + prompt=select_account + scope=XboxLive.signin%20offline_access）；exchange_code 复用 flow 的 oauth_error/tokens_from。 - callback：本地 HTTP/1.1 回调服务器。内核分配端口（占用按次数退避重试）；非 /auth 路径 （favicon、预连）404 后继续等；state 不匹配 400 后继续等；error=access_denied 归 Canceled； 单条连接读头超时 5s，半开连接拖不垮时间预算。 - MicrosoftAuth::authcode_login(present)：绑端口 → present（宿主开浏览器）→ 等回调 → 换 token → 整链；失败与设备码流一样落 M38 失败日志。 app（crates/app） - AppCommand::StartBrowserLogin + host::accounts::start_browser_login；设备码/授权码共用 LoginJob 取消槽位、收尾入库（store_session）与面板 DTO。 - host::opener 用系统默认浏览器打开授权 URL（Windows rundll32 url.dll,FileProtocolHandler）。 - 账户页：主按钮「微软登录」走授权码流，「设备码登录」作备用；DeviceLoginView::browser_waiting 在面板里给出可复制的授权链接（user_code 留空）。 测试 - crates/core/tests/auth/microsoft_authcode.rs：授权 URL 向量（租户/编码/prompt）、 URI 一致性（授权 URL 与 token 表单同字面量）、mock 全链、favicon+陈旧 state 后仍拿到 code、 端口占用重试文案、超时、access_denied→Canceled、login_with_xbox 403 的 M38 诊断 （detail_code=login_with_xbox_403，真机白名单未批时验收止步于此）。 - 单测：authcode 编码/向量、callback query 解码与错误分流、DTO browser_waiting、conv 面板。 未做/未验证：真机完整登录需 Azure 公共客户端 id（ULL_MSA_CLIENT_ID）与 Minecraft API 许可， 本机只能到「授权页 302 到 login.live.com 且 redirect_uri/scope/prompt 原样保留」这一步。 AskaEth <i@yeij.top>	2026-11-01 08:33:11 +08:00
AskaEth	f62bb00494	docs(readme): add official GitHub project home line	2026-10-31 22:19:47 +08:00
AskaEth	daadc9170f	Merge branch 'feat/p3-gui-full-wiring-all-pages-consume-cor'	2026-10-31 22:16:35 +08:00
AskaEth	50b321ec64	fix(app): LaunchEnd 也清 pending 并记失败原因，补早失败回归测试（M43 r3 两条 P2） ... P2-1（本轮新引入的回归）：`pending` 只在 LaunchStarted 清除，但 `launch::start` 的两条早失败出口（build_request 失败 / spawn 失败——没装 Java、版本 JSON 坏就是 这两条）只发 LaunchEnd → pending 永久残留 → `in_flight` 恒真 → 该实例本会话再也 启动不了，磁贴锁在「启动中」。修：LaunchEnd 分支先 `pending.remove`，早失败与 正常收尾都释放。 P2-2（failed 零 insert）：上一轮只在 note 里声称「失败原因进 failed 表」，代码没 落地（唯一 insert 缺失，refresh 的 Failed 分支是死代码，test 6 还靠手动塞表绕过）。 修：LaunchEnd 非 Ok 时 `failed.insert(id, summary)`、Ok 时 remove；refresh_instances 的 Failed 分支从此由真实路径喂数据。 测试（123 → 124，全部走真实入口）： - 新增 `launch_end_before_launch_started_still_releases_the_instance`：mark_pending → handle(LaunchEnd Crashed) → pending 空、in_flight 假、refresh 后磁贴是 Failed{reason}（同时钉住 P2-1 与 P2-2）。 - test 6 重写：Busy 断言改走 `mark_pending`（start_launch 用的同一入口），Failed 断言改走 `handle(LaunchEnd Crashed)`，不再手动塞 failed 表。 - 所有测试的数据根加 `TempRoot` Drop 守卫，跑完不留临时目录。	2026-10-31 22:14:24 +08:00
AskaEth	7b2ff62ddc	fix(app): 运行时状态回归真实来源 + 启动状态机补回归测试（M43 r2 两条 P2） ... P2-1（修复零测试）：新增 host/launch_state_tests.rs，6 条单测钉住启动状态机： - running_pid 按实例 id 取 pid（并发 A/B 后停 A 不会拿到 B 的 pid，A 收尾不动 B）； - 重复启动守卫：launches 已落盘时 start_launch不发 Busy、只给 warn（不起第二个进程）； - pending 窗口守卫：后台线程还没回报 LaunchStarted 时同样挡住重复启动； - LaunchStarted 清 pending 并登记 pid；LaunchEnd 清启动表与失败记录； - refresh 后在跑实例仍是 Running{pid}；pending 是 Busy；失败记录是 Failed（保住 磁贴的停止键/运行条/重试外观）。 P2-2（运行时状态未派生）：refresh_instances 重建快照后按 host 的启动表覆写运行时 （Running{pid} / Busy / Failed），不再被 game::instances 的硬编码 Idle 打回原形—— 装版本成功、加删账户、别的实例收尾等任意刷新都不再让「在跑的实例」丢掉停止入口。 顺带加固（reviewer 建议的 pending 窗口）：单槽守卫改为 pending ∪ launches 并集， launch::start 到 LaunchStarted 之间的重复 dispatch 不会起第二个进程；失败原因也 记进 failed 表，避免收尾后的刷新把「失败/重试」覆盖成 Idle。	2026-10-31 22:09:47 +08:00
AskaEth	ecded9bef0	fix(app): 停止实例按实例 id 找 pid，并发启动不再杀错进程树 ... reviewer-guiwire r1 的 P2-1：`running_pid` 只记「最近一次启动」的单槽 pid， 并发启动 A、B 后点 A 的停止键会 tree_kill 掉 B；且实时尾随在 B 启动时被抢占， A 的日志再也没人跟。兜底分支也永远不命中（`game::instances` 每次重建都把 runtime 置 Idle）。 改法： - 单槽 `launch_pid` → `launches: Vec<LiveLaunch{instance, session, pid}>`， 停止/收尾/尾随判定都按实例 id 或会话 id 精确匹配； - 同一实例重复点启动直接拒绝（「已经在启动/运行中」），不再起第二个进程； - 收尾只拆自己那场的尾随，并发时另一实例的实时日志不被掐断； - 实时尾随仍是单窗口（一次只跟一场，另一场收尾后可从 JSONL 回放）——这是 有意的 UI 取舍，不是漏判。	2026-10-31 21:55:59 +08:00
AskaEth	359a5a4325	chore: gitignore 截图验收产物目录（.screens/.tmp-screens）	2026-10-31 21:55:59 +08:00
AskaEth	ddc0577f83	feat(app): GUI 全量接线，五页改吃 core 真实数据（M43） ... app 从「mock 骨架」切到「真实 core host」：新增 src/host 装配层（env/job/ game/launch/identity/versions/install/meter/java/accounts/logs/settings/engine/ dispatch），是 app 里除 settings_bridge 外唯一 use unlucky_core 的地方，出口只有 crate::dto 的 DTO/事件（三通道纪律，AGENTS §6）。 页面接线： - 实例页：profiles+版本 JSON 继承链+会话索引 → 磁贴（真实版本/加载器徽标/最后启动/ 隔离档位/载荷缺失）；启动按钮走 LaunchRequest 装配 → Launcher::spawn → JSONL 尾随 → 运行/失败回写；M30 ModeChangeWarning 进横幅通知条。 - 新建实例向导：版本 → 加载器 → 名字 → 确认 → 真实安装进度；Fabric/Quilt 可装， Forge/NeoForge 因需要 installer processors（仅 CLI 有）显式拒装并给出 CLI 命令。 - 下载页：远端 manifest（12h 缓存）+ 内嵌 unlisted → 分类（正式/预览/远古四子类）； 安装进度（文件数/字节/速度/ETA，速度由相邻采样差分）+ 阶段边界可取消； Java 分组：四家发行版 + 回退链可视化（计划链/真实 ChainLog）+ 本地运行时。 - 账户页：三轨账户列表（只读公开字段）+ 离线新增 + 删除/切换 + 微软设备码登录 （用户码/链接/轮询状态；取消后丢弃结果）。凭据只在 host/identity 与 host/accounts 出现，DTO 无 token 字段（单测钉住）。 - 设置页：新增 download/java/data/ai/mcp 五组，行由 core::setting schema 键生成， 写回走 SettingStore::set（与 ull config set / AI set_config 同源 launcher.json）。 - 日志页：会话索引 → 列表；事件 JSONL → 日志行（等级高亮）+ D8 规则引擎诊断卡片； 启动中实时尾随（600ms/拍，只读新增字节）；崩溃日志导入分析（hs_err/crash/latest）。 架构与守线： - 新页面状态走 ui/page_state.slint 的 PageState global（main.slint 再导出）， Rust 侧 page_sync.rs 灌入、callbacks_pages.rs 接线；避免属性逐层转发顶破 400 行。 - DTO 全部 Serialize+Deserialize（IPC 契约），新增 accounts/java/settings/install/ notices 五个子模块；事件扩展 LogAppended/LaunchFinished/AccountsChanged/ DeviceLoginChanged/JavaChanged/InstallProgress/SettingsChanged/NoticesChanged。 - 截图通道扩展：--data-dir（钉数据根且 settings 同源）/--mock/--screenshot-page/ --screenshot-wizard/--screenshot-session/--screenshot-install/--screenshot-launch （真实中间态，取图后自动 stop 防孤儿进程）。 已知边界：GUI 账户「当前启动账户」仅内存态（core schema 无 auth.* 键，app 不自建键）； Forge/NeoForge GUI 安装待 processors 执行器上移。	2026-10-31 21:55:58 +08:00
AskaEth	bc41dfcf7d	Unlucky Launcher v0.0.1-alpha ... Rust 原生单文件 Minecraft 启动器：CLI 完整可用（install/launch/accounts/java/diagnose/agent）， MCP server 接入外部 Agent 工具，GUI 开发中。 v0.0.1-alpha	2026-10-31 21:54:10 +08:00