JianFeeeee
186cf53804
fix(push): 额度预留**真的**挪到 accessToken 之后（上一版只写了注释）
## 起因：pi 在邮件驱动的一轮里当场抓出来的
pi 收到那封 `[收尾验证]` 邮件后，自己翻代码核对，
在会话文件里写下（原文）：
The code contradicts its own comment (item ②: reserve should be *after* accessToken)
The commit only changed the argument (`len(tokens)` → `1`) and the comment — it
Fix ① (per-batch) is real and tested. Fix ② is claimed but not implemented.
Confirmed — the bug is real.
它甚至自己造了探针（`zz_probe_test.go`，跑完已删）来实证。
**我独立复核确认它是对的**：
`reserveDaily(1)` 在第 212 行，`accessToken` 在第 215 行 ——
预留仍在**之前**。2026-09-26 那次我只改了 ①（`len(tokens)` → `1`），
把 ② 写进了注释，**代码没动**。
## 为什么当时那批判据没接住
`push_test.go` 原有 3 格只验 ①（按批次计），**造不出「accessToken 失败」这条路** ——
`hmsStub` 的 `/token` 永远返回 200 + 令牌。
⇒ 「注释说修了」与「代码真修了」能分家，而没有任何东西会发现。
## 改法
① `hmsStub` 加 `failToken` 开关（`/token` 可返回 400）。
② `reserveDaily(1)` 挪到 `accessToken` 成功**之后**、真正发请求之前。
仍保持**前置预留**语义（不是"发成功后再扣"）—— 那会超发，
并发下多个 goroutine 都能通过检查。宁可少算也不多发。
③ 新增 `TestHMSAccessTokenFailureDoesNotBurnQuota`：三次 accessToken 失败后
断言 `dayCount == 0`、零推送发出、且恢复正常后仍能发（额度没被吃掉）。
## 变异验证（这格判据本该在 2026-09-26 就存在）
把 `reserveDaily` 挪回 `accessToken` 之前（= 还原成 bug）⇒
★ accessToken 失败不该扣额度，实际已扣 3 条
（一次网络抖动静默烧配额就是这么来的）
## 教训（与本仓 python-probe-shadowing / baseline-residue 同族）
**「我写了注释说明怎么修」不等于「我改了代码」。**
审查报告给了两条，我处理了一条，把另一条**誊进了注释**就当做了。
写完注释应当立刻核对行号 —— 那是 5 秒钟的事，而这次是别人替我发现的。
★ 另一层：**别人（或另一个 Agent）独立复核出来的结论，要自己再验一遍再改**。
我逐条查了行号才动手，没有因为"pi 说的"就直接信。
2026-09-28 09:49:22 +08:00
..
2026-09-25 16:29:19 +08:00
2026-09-28 09:49:22 +08:00
2026-09-19 12:30:05 +08:00
2026-09-08 19:16:35 +08:00