10 Commits

Include renames

Author	SHA1	Message	Date
AskaEth	f217d83680	feat(saves): 实例存档 / 截图的只读列表与打开文件夹（M235 STOREMVP） ... 用户诉求是 PCL 差距四项里的「存档截图 / 导入」，M230 审计确认三层全缺。塔裁决 U3 把这一版钉成「只读列表 + 打开文件夹」，不做缩略图墙（缩略图要引图片解码依赖，而 AGENTS §2 只允许 palette-extract 引 image 类依赖；截图/导入产物形态也没定型）。 core - `game::saves`（新）：只读列 `<run_dir>/saves`（世界目录）与 `<run_dir>/screenshots` （图片文件）。只调 symlink_metadata / read_dir / metadata，不建目录、不写文件、不读 文件内容（`icon.png` 只判存在）。目录不存在 ⇒ 空列表不是错误；存在但不可用（符号 链接 / 不是目录 / 读不了）⇒ 具名错误。条目级异常逐条登记原因，不静默丢。 - `platform::opener`（新）：`open_dir` 是**目录**打开器的唯一收敛点（explorer / open / xdg-open），内部复用 `child::quiet`，cfg 分支只此一处。塔明确要求按 AGENTS §6 放 platform 而不是业务模块，并要一条可执行判据防退化 （`the_launcher_literals_live_here_only` 扫 `crates/core/src`：除本文件外不许出现 `"explorer"` / `"xdg-open"` 字面量）。 presenter - `dto::saves`：SavesCommand（List / OpenFolder）、SavesListView、SavesFailureView （结构 + OS 原文，不拼中文）、`SavesListView` 的计数助手。 - `host::saves`：走 `job::spawn`，UI 只收快照；运行目录仍是 `isolation::derive_game_dir` 的同一个答案（与启动 / mod 列表同源，**不写盘**）。 「打开文件夹」打开哪个目录由 host 定：`saves/` → `screenshots/` → 运行目录。 失败分三类（InstanceUnavailable / DirUnusable / OpenFailed），可重试。 - `state::saves`：快照整体替换、迟到结果丢弃、失败保留绑定（重试才有意义）。 - 接线：CoreEvent::Saves / AppCommand::Saves / HostTask::Saves。 app-iced - `pages::instances::saves`：详情页 SAVES 卡片（MODS 之后、启动参数之前；**不套第二层 滚动条**，整列那一条是唯一入口）。世界行带 UTC 时间与「有图标」，截图行带大小与时间； 第一行固定画「这一版只读」（U3 边界让用户看得见）。读盘失败画一条红字 + 「重试」； 打开文件夹失败**不画**重试（那个动作的重试就是再点一次按钮）。 - 接线：Message::{ReloadSaves, OpenSavesFolder}、`sync_saves`（与 `sync_mods` 同一判据）、 Model::saves、`saves_shot` 出图夹具（ULL_SAVES_FIXTURE=1）。 i18n - `InstancesSaves*` 20 条中英成对，catalog 与金表在**同一条锚点**后追加、逐字节一致。 证据 - core 只读判据：`game::saves::tests` 在真盘建世界/截图，调用前后各拍一次 （相对路径, 是否目录, 字节数, mtime）指纹并逐条比对；另有用例钉「目录缺失不建目录」。 - presenter：`host::saves::tests` 真盘端到端（custom 档位派生运行目录 → 快照）。 - GUI：`--software-renderer` 1180×760 浅/深各一张 + 1180×1280 两张「整块卡片可见」 （1180×760 下 SAVES 卡片位于折叠线附近，只能看到卡头；第二对用 ULL_WINDOW_SIZE 把窗口拉高，口径与 M98 的矩阵一致），落 `DevDocs/artifacts/M235/`。 没做的（U3 边界内，见 handoff）：缩略图墙、导入、删除/重命名、`level.dat` 的 LevelName 解析（世界名暂时就是目录名）。	2026-11-11 06:00:27 +08:00
AskaEth	6dd88a27a3	fix(core): 守卫的剥注释不再吞文件 + 变异 D 变红（M213 复审 P1-1 / P2-1） ... 复审 P1-1：`code_lines()` 对每一行找 `/*`，找着就当块注释开头。本仓库的文档注释里到处是 glob（`/usr/lib/jvm/*`、`rules.d/*.yaml`、`crash-reports/*.txt`、`.github/workflows/**`）， 字符串里也有（`"mods/*.jar"`），这些 `/*` 没有配对的 `*/`，于是 in_block 一旦为真就再也 不会变假 —— 该文件从那一行到 EOF 全部被吞掉。实测 crates/core/src 里 8/371 个文件中招， 其中一个是 game/java/discover.rs（它自己有一处 reg query），复审判的变异 D 因此全绿。 - code_lines 只在「去掉前导空白后以 /* 开头」的行上进入块注释态，行中/字符串里的 /* 一律 当普通代码。本仓库零处行首块注释，所以结构上不可能再吞代码。 - 新增 code_lines_is_not_fooled_by_glob_slashes_in_strings_or_docs：字符串里的 /* 不许 吞掉后一行、文档 glob 不许吞掉真代码、真块注释仍要被剥。 - 新增 the_scan_reaches_the_end_of_every_file：逐文件核对**最后一行代码的行号**必须出现在 扫面结果里（比数总行数尖锐 —— 文件普遍以 } 结尾，光比内容会被别处的 } 蒙混），外加 全仓可见行占比 ≥60% 的兜底（本机实测 81%）。 - 变异 D（discover.rs:156 改回裸 Command::new）现在 exit 101 并点名该行；A/B/C 复验仍红。 复审 P2-1：原注释说「两个 flag 不能叠加」，按 MSDN 这是错的。改成：两个 flag 在 Win32 层 可任意组合，真正的坑是 std 的 creation_flags 是 setter（后一次静默覆盖前一次）。结论不变 （launch/process.rs 仍零改动），顺带修正 DETACHED_PROCESS 的说明。	2026-11-09 15:07:56 +08:00
AskaEth	40a296471d	fix(core): 所有子进程统一走 platform::child::quiet + 角色守卫（M213） ... GUI 父进程（PE Subsystem = 2）spawn 控制台子进程时，Windows 会为子进程新建一块 控制台——桌面上就是「黑框闪一下」。改前 crates/core/src 有 21 处 Command::new， 只有 tree_kill 那一处带了 CREATE_NO_WINDOW，于是探 N 个 JDK 就闪 N 次 java -version。 - 新增 crates/core/src/platform/child.rs：唯一构造器 quiet(program)，Windows 上统一 .creation_flags(CREATE_NO_WINDOW)，其它平台原样返回。tree_kill 里那份就地合并进来， 不再保留第二份常量。 - 20 处 spawn 全部改走它（region_system / java{discover,manual,probe,proc,termux} / addon exec / platform{linux_caps,macos_version,theme_probe,vk_probe,windows_version, wallpaper/io}）。 - launch/process.rs 零改动：游戏进程要 CREATE_NEW_PROCESS_GROUP 撑 taskkill /T， 带不带控制台窗口是产品决定。 - crates/core/tests/child_quiet.rs：按角色判「有没有绕开构造器」的守卫，外加构造器 本身的 4 条行为用例。三条变异（裸 Command::new / 别名 Spawn::new / 删掉 creation_flags） 都实测变红并已还原。	2026-11-09 15:07:56 +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	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	e090c67297	feat(platform): 识别 Termux 宿主并把 $PREFIX/lib/jvm 纳入 JDK 扫描 ... - 新增 platform::termux：用 TERMUX_VERSION / 默认 PREFIX 识别 Termux， 推导 $PREFIX 与 $PREFIX/lib/jvm，不把路径写死进调用方 - java::discover 的 standard_roots 在 Unix 分支追加 Termux 的 JVM 根， 环境可注入（standard_roots_in），补上「Termux 装了 openjdk 但没设 JAVA_HOME/PATH 就发现不了」的盲点 - 单测覆盖识别、负例与扫描结果	2026-11-07 09:33:18 +08:00
AskaEth	166342b021	fix(core,design): M147 修掉 test(ubuntu) 剩下的两条红（M144 被 fail-fast 挡住没看见） ... `cargo test --workspace --all-targets --no-fail-fast` 在 docker 里（Debian 12 / rustc 1.99.1） 第一次跑全：app-iced 那条修好后，还有两个 target 各有一条 **Linux 专有**的确定性失败—— M144 只看到第一条，因为 cargo 默认在第一个失败 target 就停。两条都是「夹具/断言按 Windows 语义写死」，不是产品逻辑错。 1. `unlucky-core`：`platform::wallpaper::windows::tests::current_theme_expands_local_app_data_env_var` （crates/core/src/platform/wallpaper/windows.rs:286，460 passed / 1 failed） 夹具用了**混合分隔符**：`LOCAL_APP_DATA` 写 `C:/Users/u/AppData/Local`，而 `CUSTOM_THEME` 写 `C:\Users\u\AppData\Local\…`。探针把 `%LOCALAPPDATA%` 展开后拼上 `\Microsoft\…`，得到 `C:/Users/u/AppData/Local\Microsoft\…`；`FakeIo` 却按 `CUSTOM_THEME` 建键。Windows 的 `Path` 把 `/` 与 `\` 都当分隔符 ⇒ 两个 PathBuf 相等；Linux 不 ⇒ 查不到文件 ⇒ 0 个候选。 修法：`LOCAL_APP_DATA` 改成反斜杠原样（`r"C:\Users\u\AppData\Local"`），展开结果与 `CUSTOM_THEME` 逐字节相同。测试仍能在 Linux 跑，不丢覆盖（不是加 cfg 门躲开）。 2. `unlucky-design`：`color::palettes::tests::accent_on_fixed_neutral_only_moves_the_neutral_hue` （crates/design/src/color/palettes.rs，162 passed / 1 failed） `assert_eq!(Palettes, Palettes)` 做 f64 位相等，而两侧算中性色相的路径不同：一侧取 `NEUTRAL_HUE_DEG` 字面量，一侧经 `atan2()` 现算——glibc 与 UCRT 差 1 ulp （239.51420577630955 vs …964）。这正是 palettes.rs:361-365 那条注释自己警告过的坑。 修法：把「固定中性色相」喂成**种子色相的实测值**（`per_seed.neutral.hue_deg()`），两侧同源 ⇒ 断言保持**逐位相等**（比放宽容差更紧），零额外行。`NEUTRAL_HUE_DEG` 与种子色相的绑定仍由 隔壁 `neutral_hue_is_the_default_seed_hue` 用 1e-9° 容差钉着。 ⚠️ 这里没有照 tower 建议的「1e-9° 容差逐项比」：那个写法在 rustfmt 下要多 9 行，而本文件正好 400 行、顶在 guards.yml 的红线上。改完 399 行（比改前还少 1 行）。 验证（命令与 ci.yml 逐字一致，容器 ull-linux-check:bookworm）： - `cargo test --workspace --all-targets --no-fail-fast` → **exit 0**（原 exit 101，2 targets failed） - `cargo clippy --workspace --all-targets -- -D warnings` → exit 0 - Windows：`cargo test -p unlucky-core --lib` → 464 passed / 0 failed； `cargo test -p unlucky-design --lib` → 163 passed / 0 failed（不回归）	2026-11-06 20:19:03 +08:00
AskaEth	69d0025d09	fix(core): M73 r1 —— Windows 壁纸来源改为「当前主题优先」，通配主题包降为末档 ... 复审 p2-1（medium）：Win10+ 上 `%APPDATA%\Microsoft\Windows\Themes\` 通常只有 `TranscodedWallpaper`，一个 `.theme` 都没有；当前生效的主题记在 `HKCU\Software\Microsoft\Windows\CurrentVersion\Themes` 的 `CurrentTheme` 值里， 指向 `%LOCALAPPDATA%\Microsoft\Windows\Themes\Custom.theme`。 - 新增第二步 `windows-current-theme`：`reg.exe query ... /v CurrentTheme` → 归一化（含 `%LOCALAPPDATA%` 展开）→ 读该 `.theme` 的 `Wallpaper=`； - `%APPDATA%\...\Themes\*.theme` 通配扫描从「第二步」降为第四步兜底， evidence 如实标注「用户另存的主题包，可能未启用」； - 新顺序：TranscodedWallpaper → CurrentTheme → 注册表 WallPaper → 另存主题包； - `HostRoots` 增加 `local_app_data`（`%LOCALAPPDATA%`，退 `~/AppData/Local`）。 复审 p2-2（low）：`transcoded_wallpaper_hit_comes_first` 补一条字面量路径断言， 防止夹具与生产代码用同一构造函数一起拼错。 复审 p2-3（low）：`HostIo::run` 现在检查退出码（`!output.status.success()` 也返回 `None`），与四处「非零退出 → 失败」的文案对齐；`io.rs` 补一条夹具用例 （有 stdout 但退出码非零）证明旧行为会被挡掉。 行长：`windows.rs` 371 → 拆出纯解析到 `wallpaper/windows/parse.rs`（100 行）， 全部 7 个文件 ≤400 行。真机复跑 `detect()`：第 1 条 transcoded、第 2 条 `windows-current-theme` → `C:\Windows\web\wallpaper\Windows\img0.jpg`（与注册表同源， 去重后只剩一条），`%APPDATA%` 下无主题包的 note 照旧。	2026-11-01 21:17:55 +08:00
AskaEth	d3e9a62b21	feat(core): M73 桌面壁纸路径探测（D38 第②级输入） ... 新增 platform::wallpaper：只做「桌面壁纸可能是哪个文件」的路径探测， 不解码图片、不取色（莫奈取色与三级降级留给 crates/design 的后续 mission）。 - 唯一入口 detect() / 注入式 detect_with(io, env, platform)：返回有序候选列表 + 各步失败原因，全部找不到时是空列表而不是错误； - Windows 三步：TranscodedWallpaper（无扩展名，靠魔数认）→ *.theme 的 Wallpaper= → reg.exe query HKCU\Control Panel\Desktop /v WallPaper； - Linux 四步：gsettings picture-uri(-dark) → KDE Image= → hyprpaper/sway 配置 → XFCE xfce4-desktop.xml，每步失败不影响下一步； - macOS 两步：com.apple.wallpaper/Store/Index.plist 字符串扫描（不引 plist 依赖，兼容 bplist00）→ defaults read com.apple.desktop Background； 代码与文档明确标注「未在真机验证」； - 零 unsafe / 零 FFI（core 是 #![forbid(unsafe_code)]），文件读取与子进程 全部经 ProbeIo 注入，环境变量表经 EnvSource 注入；三平台采集逻辑不带 cfg， CI 的 Linux 上也能跑 Windows / macOS 夹具用例； - 不新增第三方依赖；6 个文件均 ≤400 行，32 条单测覆盖三平台的 正常命中 / 多候选 / 全部失败。	2026-11-01 21:17:52 +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