AskaEth/Unlucky-Launcher
1
0 Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
584 Commits 3 Branches 5 Tags
994ffda626ca8a113a7c4a1f9fdde491ad1ec190
Commit Graph
11 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
tower-worker 67a03f9402 M205 r1: 修 config.rs 的假话与「最坏 9」的措辞，UA 说明改成事实 
- download/config.rs: KEY_GH_PROXY 的「本文件没有断言把它与 schema 登记绑起来」是 M205 自己造出来的假话，改成指向 proxy.rs 的新用例（纯文字替换，400 行不变）
- addon/online/download.rs: 断言消息与边界段改说「出厂档 3x3 = 9；retry_limit 调到 N 时是 3xN（上限 10 => 30）」，别再让人把出厂值读成事实上限
- presenter/host/addon/http.rs: 「Modrinth 的请求走 get_via_engine」是错的（实际走 core::addon::online::EngineTransport -> download_bytes，带的是引擎 UA；get_via_engine 今天只有单测在用），改成事实
 2026-11-09 11:20:27 +08:00
tower-worker d4aa3b23f4 M205: gh-proxy 键绑定断言、外层重试预算判据、UA 版本号来源、下载设置文档更正 
- setting/keys/proxy: 新增断言把 KEY_GH_PROXY 常量与 schema 登记绑起来（键名 / Text{max_len:256} / 默认空串）
- addon/online/download: RETRY_ATTEMPTS 与引擎每源次数是两件事（层级相乘、管的失败类型不同），写清判据并用两条编译期断言钉住 3 与 3x3=9 的边界
- presenter/host/addon/http: UA 版本号改为从 CARGO_PKG_VERSION 拼出，补断言钉住版本 == CARGO_PKG_VERSION 且联系方式段不丢
- docs/download-settings: §3.1 四条 CLI 命令都吃设置（update 是自更新路径），§6 补 M11-M13 三条 CLI 变异，§1/§7 里 gh_proxy 已合入的事实
 2026-11-09 11:12:59 +08:00
tower-worker 1764301cdf merge: 解 origin/dev 三处冲突（M182 / M184+M190 / README §14），两边都留 
冲突（都来自别人后来改同一批文件）：
- crates/app-iced/src/platform/mod.rs：保留 M182 的 HostOs / host·linux·macos 分册表 /
  plan_corner_for，同时保留 M196 的 `[`win32::console`]` 落点说明；把 M182 措辞里已经不
  成立的「唯一 unsafe 落点 / 只此一处」改成「两处落点（transparency + console）」
  （unsafe-scope 门禁自 M196 起期望集合就是两处，不改这句文档就是错的）。
  注意：`pub mod console;` 属于 `platform/win32/mod.rs`，本次解冲突时一度被误加到
  `platform/mod.rs`（`cargo check` 立刻报 E0583 文件不存在），已修回。
- .github/workflows/release-build.yml：M190 的「PE 版本资源读回」步、M184 的
  linux-x64 xvfb 冒烟步与首帧上传步**全部逐字保留**；M196 的 PE 子系统门禁作为**兄弟步**
  插在导入表门禁之后（两道 PE 门禁互不替代）。按块比对：dev 的 10 个步骤逐字未变，
  合并后 11 个步骤。
- packaging/README.md：保留 M184 的 §11 补充与 §12 行、M190 的 §14 签名段；§12 里
  check_publish_slots 用 dev 的 11 条版本、另加 M196 的 check_pe_subsystem 行；§15 归位在
  §14 之后。

行数：release-build.yml 合并后 413 行会撞 400 行红线（dev 侧本来 393），故把 M196 那一步
压到 6 行 + 1 空行（说明改由步骤名指路 packaging/README.md §15 与脚本 docstring 承载），
最终正好 400 行。

验证见 mission 报告：cargo check/test/fmt 全绿，两个 PE 门禁在同一批产物上都 exit 0
（子系统 GUI=2 / CLI=3，版本资源的 subsystem 读数同为 2 / 3）。
 2026-11-09 05:49:38 +08:00
tower-worker 26ba1579ab docs(m196): r2 复审 —— 给「无控制台宿主」那条下边界声明 
复审指出 README §15 把两个**近似**形态（父进程句柄不继承 / 父子都无句柄）直接叫「服务形状」，
顶层又写「服务 / 计划任务」，读者会把它当成「真服务也测过」。补一段边界：① ② 都是近似，
真 SCM 服务与计划任务（session 0、no window station）、start /b、ConPTY 全部未测，结论靠
「句柄无效时 std 写返回 Ok」这条机制外推；第三方交叉读数（复审 r2 那组）单独标注来源，
不混进我自己的读数。

同一处过度概括也出现在 console.rs 的 NoConsole 文档（原文「④ / 服务 / 计划任务」），
按同一口径改成「④ 双击，以及其他没有控制台的宿主」并指向 README §15 的边界段。

只改文档，不动代码。
 2026-11-08 20:22:36 +08:00
tower-worker 3fd33a672f fix(m196): r1 复审 P1（非 Windows dead_code）+ P2 四条 
P1（阻断）：console.rs 的 `INVALID_HANDLE_VALUE` 只被 `#[cfg(target_os = "windows")]`
的 usable() 用到，而这个模块在 Linux/macOS 上也编译（platform/mod.rs 的 pub mod win32;
没有 cfg）⇒ ubuntu 的 `clippy -- -D warnings` 会把它升级成 dead_code error。
按「精确 cfg」修（不用 dwm.rs 那种文件级 allow(dead_code)：那会永久掩掉本文件在非
Windows 上的所有死项）。自证方式是真实文件翻转 cfg 的 rustc probe：修前 exit 1
（`constant INVALID_HANDLE_VALUE is never used`）、修后 exit 0 零告警；同一条命令写进
了注释，下一个人可以照着跑。

P2-1：自测条数按实现改成 8 条（红 6 / 绿 2），三处（脚本 docstring、release-build.yml
注释、README §12）一致。
P2-2：文件头那组句柄读数换成 release 产物的实测值（out 0x0→0x1F0 / err 0x0→0x1F4），
并说明数字随实例变化、单测里的 0xE4/0xE8 是示例。
P2-3：README §15 补这段边角语义——但**按实测改写了复审的结论**：两种「既无控制台也不
重定向」的宿主形态（父有句柄不继承 / 父子都无句柄）× 两条命令，child_exit_code 全是 0，
不是 EXIT_INTERNAL；原因是 Rust std 在 Windows 上对取不到的句柄直接返回 Ok（独立探针
实测 SetStdHandle(out)=0x0 / 0x1234 / (HANDLE)-1 三种取值 write/flush 都是 Ok），
所以 runner.rs 那条「写失败 ⇒ EXIT_INTERNAL」的分支不会被触发。
P2-4：NoParentConsole → NoConsole（这个名字同时覆盖「attach 成功但句柄仍不可用」），
诊断文案与注释同步。
 2026-11-08 20:12:36 +08:00
tower-worker 14f9318e09 fix(m196): GUI 产物 PE Subsystem → WINDOWS_GUI(2)，并用 AttachConsole 保住 CLI 输出 
群友 2026-11-08 实测发布构建「运行时会带一个控制台窗口在底下」。根因：产物 PE 头
Subsystem 仍是 CUI(3)。同一个修复 2026-11-01 做过一次（37d3039），但只改了已被
workspace exclude 的 Slint 树（crates/app），从未到达 iced 产物。

- crates/app-iced/src/main.rs：加 #![cfg_attr(windows, windows_subsystem = "windows")]，
  并写清为什么放 bin 层而不是 build.rs（PE 子系统是每个 bin 目标的属性）。
- crates/app-iced/src/platform/win32/console.rs（新）：AttachConsole(ATTACH_PARENT_PROCESS)
  的落点 + 判据 should_attach（纯函数，可断言）。GUI 子系统进程不继承父控制台，实测
  从 cmd 启动时三个 std 句柄全是 0；附着后 GetStdHandle 立刻给出控制台句柄（0x0→0x208），
  所以不改 std 句柄、不碰用户的重定向（ATTACH_PARENT_PROCESS 只会附到已存在的控制台，
  永不新建窗口）。
- packaging/check_pe_subsystem.py（新）：读产物 PE 头 Subsystem 字段（GUI 必须 2、
  CLI ull 必须 3），非 2 即红；--self-test 注入 5 条合成 PE 回归。
- 接进 release-build.yml（发布侧两槽位）与 ci.yml build job（PR 阶段）。
- guards.yml：unsafe 落点期望集合变成两处（console.rs + transparency.rs），集合相等判据其余不变；
  平台层所有「全仓唯一 unsafe 落点」措辞同步改正。
 2026-11-08 19:33:56 +08:00
tower 5d5011f66c ci(release): M141 arm64 体检改成逐行注解 + 缺 ARM64 SDK 时就地补装组件 
- 诊断全部走 ::error:: 注解（job 日志要 token，注解不要），快照固定 4 行：
  探测根存在性 / 每个 SDK Lib 版本目录的 um 架构 / MSVC lib 架构 / 两个关键库路径。
- SDK 根放宽到 4 个（(x86)、Program Files、Microsoft SDKs、VS 自带的 SDK in VS），
  kernel32.lib 探测深度 4→6；MSVC find 兜底深度 7 覆盖 lib 目录。
- 缺库时先就地补装（vs_installer modify --wait），组件 ID 按已装 SDK build 反推，
  优先补一个尚未安装的 SDK 版本（同版本重装是 no-op，补不出 um/arm64）；补不上才 fail。
- 门禁不降级：PUBLISH_SLOTS 与槽位表原样（windows-arm64 仍在）。
- 为守住 400 行上限，压缩了其余纯注释块与两处等价写法，逻辑未变。
 2026-11-06 12:15:10 +08:00
tower 5340908882 refactor(download): rebase 到 M93 之后 app/update.rs 破 400 → 下载页四支拆到 update/download.rs 
M93（外观三件套接线）合入后 `app/update.rs` 从 348 涨到 410 行，再加上下载页的四个 arm
会顶破 ≤400 硬线。把下载页那几支（SelectVersion / InstallVersion / CancelInstall /
SetCategory / Action::RefreshSources）挪到 `app/update/download.rs`（`app/update/**` 在本
mission scope 内），`on_page` 入口只留一句 `if self.on_download(&message) { return; }`，
match 末尾补一条 `_ => {}` 做穷尽性。

行为零变化：指令、视图模型写法、`refresh_view` 顺序都照搬；M93 的 `Appearance` arm /
`env_start_route` / `on_appearance` 一行没动。

行数：update.rs 410 → 397，download.rs 57。
 2026-11-02 21:45:40 +08:00
tower 6453c76750 fix(download): M94 r2 —— 安装终态出口 + 分类真机过滤（复审 P1-1 / P2-1） 
P1-1 安装一旦收尾就再也装不了第二个版本（终态面板没有出口）
- 页面侧：`Download::from_snapshot` 把 **Done / Cancelled** 当结束（`InstallView::finished`），
  面板让回列表 —— 装完一个版本可以直接选下一个继续装（图：r2-done / r2-done-next）。
  不清 `Failed`：失败态带着用户要的东西（停在哪个文件 + 去日志页）。
- 面板加真出口：失败态「Open logs」（实心）+「Dismiss」（文本 → `Message::CancelInstall`，
  host 侧对没在跑的任务是安全 no-op），修掉「失败后连重试都不可达」。
- 决策抽成纯函数 `install::panel_state()`（Hint / Ready / Install），`panel()` 只是它的画法，
  于是「能不能再装」可以被单测钉死，不用开图形环境。
- 两条新测试**不走 MockBackend**（它从不发 `InstallProgress`，终态永远跑不到 ⇒ 假绿）：
  直接构造 `AppState` + `apply(CoreEvent::InstallProgress(..))`。

P2-1 分类 chip 在真 host 上是空控件
- `from_snapshot(state, category, catalog)` 收分类并按 `Category::matches` **本地过滤**
  （真 host 的 `ListVersions(_)` 丢掉分类参数、回全量清单）；
- 分类不再从列表反推（`Category::of` 只留给演示首帧），`app/view.rs::model` 收分类、
  `refresh_view` 把上一份视图模型的分类带回去 ⇒ 事件回来 chip 不会跳回「全部」；
- `update.rs` 的 `SetCategory` 写分类后**立刻重建**（chip 与列表同一个谓词），再派真指令。

p3（顺带）
- 失败态与占位态共存：列表空/加载中时若安装还在跑，面板照样出现在底部（r2-installing-empty）；
- 修 `install.rs` 的坏 rustdoc 链接；`install.rs` / `model.rs` 的测试模块外置到子文件守住 400 行。

测试文件：`pages/download/{model,install}/tests.rs`（新），`pages/download/tests.rs` 里的
`from_snapshot` 调用补分类参数。

实证（回退法）：删掉 `.filter(|view| !view.finished())` → 两条终态测试红并点名
「Done 之后不许再占着安装面板」；删掉 `.filter(|category.matches(..))` → 两条分类测试红
（「只剩正式版」left=3 right=1）。放回修复 → 全绿。

门禁：fmt --check 干净、clippy -D warnings 干净、app-iced 280 + 集成 6 + i18n 23 全绿（-j 4）。
 2026-11-02 21:36:28 +08:00
tower 9d6ee70301 fix(download): M94 r1 —— 五条复审（P2-1/2/3/4/6） 
P2-1 占位规则统一：加载态原先贴顶、空态居中 → 两态都走同一套「内容在可用区居中」
  （依据：components::feedback::empty_state 的既有口径 12b §15.4；两态互切不再纵向跳）。
  实测两个状态的内容中心线 y=449 / y=445（差 4px）。

P2-2 文案只说真能做到的事：
  - 删「The list appears after the first successful fetch; this page never goes blank.」
    （工程话术 + 承诺了 UI 做不到的「永空白」）→「如果一直停在这里，点右上角的刷新。」
    （对应页头那个真的 Refresh 按钮）
  - 空态「Switch the category or clear the filter」删掉「清筛选」（页面没有筛选控件）
    →「换一个分类，或刷新一次列表。」
  - 副标题「Version list from the official manifest」去掉 manifest 这种工程词 →「可以安装的版本」

P2-3 去掉静止的 indeterminate 进度条：页面没有帧订阅，indeterminate 只会拿到一个固定相位
  （看起来像 17% 卡住）。加载态改成纯文字；安装面板只在进度已知时画 determinate。
  两帧证据：215/512 → 条填 177px(42%)，409/512 → 338px(80%)，条随事件走而不是动画。

P2-4 失败态与安装中彻底不同构：失败不再画进度条，改成整块 ErrorContainer 面板
  （ErrorContainer 底 + Error 图标 + Error 色标题 + 停在哪个文件 + 说明 + 实心「打开日志」）。
  实测底色：浅色 (255,218,214) / 深色 (147,0,10)，安装中面板底色仍是页面底色。

P2-6 死 key 与假守卫：
  - 删掉没用的 DownloadSelected；
  - 用真的守卫替换原来那条「前缀遍历 + 条数下限」：every_download_key_is_referenced_by_the_page
    用 include_str! 把页面源码编进来，目录里每个 Download* key 必须在源码里出现 Key::Xxx。
    实证：把 DownloadSelected 放回去 → 该测试红并点名 key；删掉 → 绿。
    注释里也写清抓不住的三种情况（反向是编译错误 / 译文完整性归 i18n 自己的测试 / 宏拼 key 能骗过它）。

门禁：fmt --check 干净、clippy -D warnings 干净、app-iced 276 + i18n 23 全绿；
tests.rs 384→383 行（不再贴顶），其余文件均 ≤400。
 2026-11-02 21:36:26 +08:00
tower 57e8380b24 feat(download): M94 下载页换成真组件 + 真快照 + 真指令（PAGEDL） 
页面（crates/app-iced/src/pages/download*）：
- Tabs（分类）/ ListItem（版本行）/ filled 安装按钮 / progress / EmptyState / divider
  全部取自 components/ 的真组件；页头动作换成 buttons::text
- 数据只吃 pages::download::Download（app/view.rs 由 AppState 快照转，installed_only 与
  download_query 照用）；页面自己不留业务状态，交互只发意图
- 状态：加载（不确定进度 + 文案）/ 空（EmptyState + 刷新 CTA）/ 有数据 / 安装中 / 安装失败
  （失败给可读文案 + 「打开日志」出口）

接线（追加式）：
- pages::Message 加 SelectVersion / InstallVersion / CancelInstall / SetCategory
- app/update.rs 翻成 AppCommand::{InstallVersion, CancelInstall, ListVersions}
  （SelectVersion 只改视图模型；「刷新」= 当前分类重新拉，全部走 RefreshAll）
- pages::Model 加 download 字段

文案：28 个 Download* key 进中英两套 catalog（一行一个 key 的全语言）；页面零中文字面量，
  core 的中文阶段串（InstallStage::label / message）一律不进界面

i18n 结构：catalog.rs 的既有测试模块原样外置到 catalog/tests.rs（392 行 → 282 行，
  逐字未改），新 key 才装得下 400 行硬上限

测试：app-iced 276 + i18n 23 全绿；clippy -D warnings 与 fmt --check 干净
 2026-11-02 21:36:22 +08:00