Unlucky-Launcher

0 Fork 0

Files

T

AskaEth 53b27eac45 fix(renderer): M97 r2 —— 退出码透传拆成可测单元（构造 / 执行），4 个变异全抓

上一轮把降级重开的 env 钉住了，但 `respawn` 里还剩一段不可测的接线：`status.code()`
→ `process::exit`。它的失效方式不止「崩溃」，而是**安静地给出一个错结论**——CI 把失败
当成功（或反过来），然后有人基于它做决定。这类和今晚一直在打的东西同类，所以补上。

## 拆法

- `exit_code(Option<i32>) -> i32`：纯函数。`None`（子进程被信号杀死，只有 Unix 会这样）
  走兜底码 2，**不 panic、不当成功**。在 Windows 上也能测（测的正是「拿不到码」那一刻）。
- `fallback_command(program, args, fallback) -> Command`：program / args 是参数而不是
  在函数里读 `std::env`，唯一目的是让测试能喂假命令（`cmd /c exit 7`）验退出码。
  三路 stdio **显式** `inherit()`——`Command` 默认就是继承，但显式写出来，将来有人为了
  「安静」加 `.stderr(Stdio::null())` 时 diff 里看得见；降级那次的子进程日志必须和父进程
  同一路输出，否则验收脚本抓不到。
- `respawn` 只剩 `current_exe()` + 日志 + `exit_code(status.code())`。

## 新增测试（4 条，全部变异验证过）

| 变异 | 结果 |
|---|---|
| X1 `unwrap_or(0)`（拿不到码时当成功） | `signal_death_falls_back_to_a_nonzero_code` FAILED |
| X2 `Some(_)` 一律 0（不透传） | `fallback_command_really_passes_the_child_exit_code` FAILED（真起 `cmd /c exit 7`，父进程拿到 7） |
| X3 重开时丢掉 argv | `fallback_command_passes_program_argv_and_envs` FAILED |
| X4 重开时不传 env | 同上 FAILED |

复原后 `cargo test -p unlucky-app-iced --lib` = 337 passed。

**stdio 继承没法用 getter 断言**（`Command` 在 stable 上没有 stdio getter），所以它的证据是
运行时观察：交互降级那次，父进程的 `[gpu] 降级 → …` 与子进程的 `[probe] 本次是降级重开`
落在**同一个 stderr 文件**里（见报告 §运行时复核）。

## 顺带

- `boot.rs` 超 400 行（492），按仓库既有做法把测试拆到 `src/app/boot/tests.rs`
  （`#[path = "boot/tests.rs"]`，同 `pages/harness/tests.rs`）：boot.rs 311 行、tests.rs 187 行。
- `tests.rs` 模块文档里留了**变异验证的工具纪律**：只在函数体内替换、把测试里的同一字面量
  排除在外——全局 `sed` 会连断言一起改掉，于是「实现和期望被换成同一个错值」，测试照样绿，
  **验证的是变异脚本自己**。M97 r1 第一次跑就这么被骗了三个变异（假绿第十种形态），
  这条写给将来改这套测试的人。

2026-11-03 00:26:56 +08:00

agent

Unlucky Launcher v0.0.1-alpha

2026-10-31 21:54:10 +08:00

app

feat(presenter): 新建 unlucky-presenter，把 host/状态/DTO/设置桥从 app 迁出（M85 第 1 块）

2026-11-02 09:29:31 +08:00

app-iced

fix(renderer): M97 r2 —— 退出码透传拆成可测单元（构造 / 执行），4 个变异全抓

2026-11-03 00:26:56 +08:00

cli

fix(cli): 程序名占位符在构造时渲染，两条出口（人类可读 / --json）不再分叉（M82 r3 复审 P2）