5 Commits

Include renames

Author	SHA1	Message	Date
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	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	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	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