lifecycle：被逼停的關機走 BeginFailure；修好 kit/logging 會過期的測試

[hoshimoe]

兩件事，都與「日誌在什麼層級才看得到」有關。

1. lifecycle.BeginFailure

BeginShutdown 的 announce 一律 info，而採用它的服務把「是什麼逼停了我」
當成那一行的欄位傳進去。結果是：跑在 log.level: warn 的部署——也就是最需要
這筆紀錄的那些——listener 起不來時，那個 error 不存在於任何一筆 error 紀錄裡，
行程就這麼消失，什麼都沒留下。

新增 BeginFailure(log, reason, err, attrs...)：

• 觸發的 error 走 Error，帶著是什麼掛了；
• Done() 之後不會說 stopped cleanly，而是 stopped after a failure
  ——即使每個拆解步驟都成功。收拾得乾淨不等於停得乾淨，而在 warn 底下
  那行總結本來會是唯一活下來的一行；
• err 傳 nil ＝ 沒有東西逼停它 ＝ 等同 BeginShutdown，
  讓只有一條程式路徑的呼叫端不會意外變吵。

BeginShutdown 一個位元組都沒動：有秩序的停止維持 info，跑在 warn 的
部署看不到它是刻意的——例行重啟不該每次都喊。成功的拆解步驟也維持 debug。

2. kit/logging 的測試從 2026-08-14 起單向轉紅

newRotator 建構時就 prune() 一次，而測試是在它回傳之後才裝 r.now
——那次 prune 用的是真實時鐘。「保留窗內」那個檔固定寫在 2026-07-31，
真實 cutoff（now−14d）越過它的那一天起就被刪掉了。不是 flaky，是單向過期。

把時鐘改成 newRotator 的參數（nil ＝ time.Now），在 prune 之前就位。
順帶讓那支測試真的涵蓋到啟動時那次 prune——它先前完全沒被測到，
因為斷言前又呼叫了一次 prune()，看起來像是那一次的功勞。

驗證

gofmt -l . 無輸出、go build ./...、go vet ./...、go test -race ./... 全綠；
js/ 的 npm test 33 passed / 0 failed（本次沒有動到 JS，那裡沒有 lifecycle）。

測試斷言的是某個層級的部署實際看得到什麼——建一個 Level: warn 的 logger、
寫進暫存檔、讀回來比對。這個差別在 debug 底下驗不出來，所以任何在預設
層級跑的測試都會是綠的。四支：warn 底下失敗關機聽得到（且成功步驟不會漏出來）、
warn 底下正常關機完全靜默、失敗的 step 即使在正常關機裡也是 error、
nil cause 等同 BeginShutdown。

實測反向對照：把原因行退回 info，第一支轉紅；還原後回綠。

---

Generated by Claude Code