AskaEth
119b49cf83
test(presenter): M132 烘焙了 client id 的构建里让入口锚直接红（r2 P2-1）
r2 复审实测：`ULL_MSA_CLIENT_ID=fake-0000-test-id` 构建 + 同一处变异 → `ok. 22 passed`。
原因是我上一条写成了 `if is_configured() { assert!(CLIENT_ID_BUILD.is_some_and(..)); return; }`
——`remove_var` 之后 `is_configured()` 等价于 `CLIENT_ID_BUILD` 非空，随后的 `assert!` 判的是
同一条件的反面，恒真、无失败路径，于是锚在那种构建里**绿着失效**。这正是本 mission 要防的
「守门空跑」形态，而我报告里还把它写成了「只允许是这个原因」，与代码不符。
改成 `if let Some(source) = client_id_status().source() { panic!(..) }`：环境变量摘掉后仍
报告已配置，就带着 `source=` 和两条出路（不带 id 构建 / 给 `resolve_client_id` 加接缝）直接
红，逼人做决定。没有 `#[ignore]`、没有开关；正常的「两处都没有 id」构建照旧跑两条真登录流。
验证（贴原生输出）：
- 注入 id + 变异 → FAILED（panic，`source=Build`），旧代码此处是 `ok. 22 passed`；
- 注入 id + 无变异 → 也 FAILED（这才是重点：不是靠变异才红，而是拒绝空跑）；
- 无 id + 变异 → `220 passed; 1 failed`，红的正是这条锚；
- 无 id 正常 → `221 passed; 1 ignored`。
2026-11-05 20:08:52 +08:00
..
2026-11-05 14:08:37 +08:00
2026-11-05 14:08:37 +08:00
2026-11-05 20:08:52 +08:00
2026-11-05 18:09:00 +08:00
2026-11-05 19:09:53 +08:00
2026-11-05 06:35:03 +08:00
2026-11-05 20:08:52 +08:00
2026-11-05 14:08:37 +08:00
2026-11-05 20:08:52 +08:00