feat(daemon): add CC_LOG_MAX_BACKUPS env var support

[chenhg5]

Fixes #1222 (follow-up to #1243)

背景

PR #1243 修了 CC_LOG_MAX_SIZE 的解析,但保留的备份数量仍然是
硬编码的 1(只留 .log.1)。这意味着在最坏情况下,用户只保留一份
rotation 之前的日志,后面那一段还是会丢,问题 #1222 报告的"现场
缺失"并没有真正解决。

这次改动把备份数量做成和 size 一样的可配置项,沿用 flag > env > default 的优先级。

变更

• daemon/logbackups.go (新): ParseLogBackups(s) (int, error),>=1,
  不接受单位后缀,错误回显原输入。和 ParseLogSize 行为保持一致。
• daemon/manager.go: Config 和 Meta 新增 LogMaxBackups int;
  Resolve() 在 < 1 时回退到 DefaultLogMaxBackups = 3。
• daemon/logrotate.go: RotatingWriter 新增 maxBackups 字段,
  链式 rotation 算法:
  1. 删除最旧的 .log.N
  2. 从 N-1 走到 1,把 .log.i 重命名为 .log.(i+1)
  3. 把活动日志重命名为 .log.1
  4. 重新打开新的活动日志
     新增 Rotate() 方法供测试和 SIGHUP 风格的"换新日志"使用。
     maxBackups < 1 时回退到默认值,而不是悄悄关掉备份。
• cmd/cc-connect/main.go: 新增 resolveLogMaxBackups、
  preScanLogMaxBackupsFlag、--log-max-backups flag。启动日志
  现在同时输出 max_size 和 max_backups 以及各自来源。预扫描
  模式保证在 flag.Parse() 之前的 rotating-writer 初始化阶段也
  能拿到 flag 值。
• daemon/launchd.go / daemon/systemd.go / daemon/windows.go:
  服务模板增加 CC_LOG_MAX_BACKUPS env var 的写入,保证全新安装
  时自动带上。

测试

• TestParseLogBackups: 19 个子用例,覆盖有效/空白/非整数/小于 1/
  负数/带单位/3MB 拒绝(数量没有单位)。
• TestParseLogBackups_ErrorMessageEchoesInput: 错误信息包含原
  始输入(便于 systemd 单元里 grep)。
• TestRotatingWriter_BackupRotation: 写入超过 N 次,验证只存在
  .log.1 .. .log.N,最旧的被丢弃。
• TestRotatingWriter_BackupDisabled: maxBackups=1 时只有
  .log.1,和 legacy 行为一致。
• TestRotatingWriter_FallbackForInvalidMaxBackups: 传 < 1 触发
  DefaultLogMaxBackups 兜底。
• TestIssue1222_BackupRetention: 6 次强制 rotation 后只留
  .log.1 .. .log.3,把问题 [Bug] CC_LOG_MAX_SIZE=10MB 环境变量在 v1.3.3-beta.4 不生效 (log 涨到 30M+ 都不分卷) #1222 的"备份保留"语义钉死。
• cmd/cc-connect/logbackups_test.go: flag>env>default 优先级、
  非法值回退、预扫描 7 个子用例。

所有测试:

go test -count=1 -tags no_web ./daemon/ ./cmd/cc-connect/
ok  	github.com/chenhg5/cc-connect/daemon	0.006s
ok  	github.com/chenhg5/cc-connect/cmd/cc-connect	0.025s

与 PR #1243 的关系

完全独立:不动 ParseLogSize,不动 DefaultLogMaxSize,不动
log-max-size flag。沿用同一套 flag > env > default 优先级和
同一组预扫描/启动日志模式,只新增 backups 一条对应的链路。

验收

• CC_LOG_MAX_BACKUPS=3(默认)与现有行为兼容 — daemon package
  默认 3,服务模板写入 3。
• CC_LOG_MAX_BACKUPS=0 或非法值回退到默认(不会把 rotation
  静默关掉)。
• CC_LOG_MAX_BACKUPS=1 复现 legacy 单备份行为。
• --log-max-backups flag 覆盖 env var。
• 启动日志输出 max_backups=N (source: flag|env|default)。
• launchd plist / systemd unit / Windows task 三套模板同步。

[chenhg5]

Conclusion: Request changes

总体判断

PR #1260 代码层面的设计、行为和测试都很好——CC_LOG_MAX_BACKUPS 解析 + chain rotation 实现是 Issue #1222 的合理 follow-up，14 个新测试覆盖了 happy path、边界、fallback、issue 回归。但 CI lint 当前 FAILED、其余 4 项 CI 全部 SKIPPED、mergeStateStatus=UNSTABLE，本 PR 处于不可合并状态。这必须在 owner/maintainer 视角下修掉再 re-review。

Review 范围

• 看了 daemon/{logbackups.go,logbackups_test.go,logrotate.go,logrotate_test.go,manager.go,launchd.go,systemd.go,windows.go} + cmd/cc-connect/{main.go,logbackups_test.go} 全部 10 个改动文件（共 +570/-40）。
• 重点关注 correctness（rotation chain、fallback 行为）、Issue #1222 回归保护、CI 状态。

🚨 P0: CI 不可合并

• lint step FAILED (2m15s, run 27109765660 / job 80005246383)。
• 错误: daemon/logrotate_test.go:91, 126, 155 的 defer w.Close() 触发了 errcheck 规则。

  ##[error]daemon/logrotate_test.go:91:15: Error return value of `w.Close` is not checked (errcheck)
  ##[error]daemon/logrotate_test.go:126:15: Error return value of `w.Close` is not checked (errcheck)
  ##[error]daemon/logrotate_test.go:155:15: Error return value of `w.Close` is not checked (errcheck)
  3 issues: * errcheck: 3
  

• performance-test / regression-test / smoke-test / unit-test 全部 SKIPPED（lint 失败后短路）。
• mergeStateStatus=UNSTABLE — GitHub 会拒绝合并。

修复路径（机械性，3 行）：

// 3 处把
defer w.Close()
// 改为
defer func() { _ = w.Close() }()

（或者用 defer func() { if err := w.Close(); err != nil { t.Error(err) } }() 更安全——本 PR 的测试是临时文件，defer 路径吞掉 close error 不会影响断言，所以两种写法都可接受；为了和 PR #880 errcheck 修复保持一致建议第一种。）

Dev-claudecode 推一个 commit 触发 CI 复跑，QA 在 CI 全绿后 fast-path re-review。

✅ 做得好的地方

• 设计干净：resolveLogMaxBackups 与 resolveLogMaxSize 保持完全平行的 flag > env > default 优先级，logBackupsSource 也照搬了 logSizeSource 的"可审计来源"思路。#1222 跟进值得点赞。
• Fail-closed 设计兜底：NewRotatingWriter 和 Resolve 都对 maxBackups < 1 强制 fallback 到 DefaultLogMaxBackups（3）。即使运维 typo 或 env 解析失败，也不会把 post-mortem trail 整个丢掉。TestRotatingWriter_FallbackForInvalidMaxBackups 把这个 safety net 钉死。
• Chain rotation 正确：从 N-1 倒序 rename，避免 slot 冲突；IsNotExist 容错让"中间有空位"的部署历史也能正确处理。
• Test 覆盖扎实：14 个新测试包括 happy path、whitespace、unit suffix 拒绝（"3MB"）、hex 拒绝、负数、零、issue #1222 优先级回归、chain 截断、单 backup 兼容、fallback 行为。
• OS service template 同步：launchd.go / systemd.go / windows.go 三处 service 模板都补了 CC_LOG_MAX_BACKUPS env，避免 daemon 装好之后 env 进不去。
• Rotate() + MaxBackups() 暴露：未来想接 SIGHUP 或运维脚本主动 rotate 有 hook，且 MaxBackups() 解决了"我设的值真的生效了吗"的可观测性需求。

🟠 P2 (建议本 PR 修，不阻塞)

1. daemon/logrotate_test.go:696 重新实现 itoa 没必要。strconv.Itoa 已经能覆盖 1..N，写一个 16 行的本地 itoa 只为了"small and local"——但项目其他地方都在用 strconv.Itoa，引入新的本地实现是噪音。建议直接 import "strconv" 用 strconv.Itoa(i)，删掉这个 helper。
2. Meta 字段对齐看起来差一格（diff 中 InstalledAt: NowISO() 比其他字段少 1 个空格）。gofmt 应该会自动修，但既然 lint 没逮到、diff 里能看出，可能是某次手动编辑跳过了 gofmt。本地 gofmt -d daemon/logrotate_test.go 验一下。

🔵 P3 (可选)

• ParseLogBackups 和 ParseLogSize 有重复的"trim + 解析"骨架；可以抽个泛型 parseIntWithMin[T int|int64](s, min, errorPrefix)，但现在两份代码都不长，过度抽象不值。
• 启动日志的 max_backups=%d (source: %s) 在 --log-max-backups flag 解析之前的 prescan 阶段就触发了——如果用户传了 --log-max-backups=0 这种"显式无效"值，启动日志会先打印 "source: env" 然后后面再 warn "must be >= 0"，信息有点割裂。可以延后到 flag.Parse() 之后再打 log，或者把 "0 = use env/default" 的语义明确写在 flag help 里（当前 help 文本没体现 "0" 的含义）。

Testing / Risk

• 已看到的验证：本地 go test -count=1 -tags no_web ./daemon/ ./cmd/cc-connect/ 全绿（PM 提供）。GitHub Actions 上当前不能给绿——lint 失败。
• 本次未做的验证：所有 unit/regression/performance/smoke CI 步骤都 SKIPPED，需要修 lint 后复跑。
• 未覆盖风险：
  • slog.Warn 在 rotateLocked 失败路径中只 warn 不 return——极端情况下 rename 链全失败时 active log 被 w.file.Close() 后无法 reopen，Write 会持续返回 os.ErrClosed。这是 pre-existing 行为（PR #1243 就有），不算 regression。
  • os.Remove(oldest) 失败时如果后续 os.Rename 也会失败，oldest 不会被清理——但 os.Rename 不会因为目标存在而失败（POSIX），所以这条路径实际安全。

Next step

1. dev-claudecode 把 daemon/logrotate_test.go:91, 126, 155 三处 defer w.Close() 改成 defer func() { _ = w.Close() }()，推一个 fixup commit。
2. CI 复跑全绿后，本 QA 单条 comment 复审确认。
3. Merge 后 Meta JSON schema 变化（新增 log_max_backups 字段）需要确认旧版 daemon 读新 meta 不会 panic（Go json.Unmarshal 默认忽略未知字段，应该 OK，但建议在 release notes 提一句）。

[chenhg5]

Conclusion: Comment (re-review of lint fix from msg-20260610-g9p9yg)

Overall assessment:
The lint fix in commit 6be9357 wraps all 4 defer w.Close() calls in defer func() { _ = w.Close() }() exactly as my prior review asked. Local verification matches dev-claudecode's report (build OK, daemon tests pass, cmd/cc-connect tests pass). However, two pre-merge blockers remain that have appeared since the original review: (1) CI has not yet re-run for the new commit (status pending, no check runs registered), and (2) the branch has merge conflicts against current main in daemon/launchd.go and daemon/manager.go.

Review scope (delta since prior review id 4450150603 on d408bd7):

• 1 commit: 6be9357 fix(daemon): silence errcheck on logrotate_test.go defer Close
• 1 file modified: daemon/logrotate_test.go (4 defer closures added, 4 defer w.Close() calls retained as inner expressions)
• Total post-prior-review delta: 4 lines changed across the test file.

✅ What looks good:

• Count correction: my prior review mentioned 3 defer closures (lines 91, 126, 155); the PR actually adds 4 (the 4th is in TestIssue1222_BackupRetention at line 175, which was also introduced by the same commit). Dev-claudecode correctly noted that golangci-lint --new-from-rev origin/main would catch all 4 because the entire logrotate_test.go is "new" relative to main, so fixing only the 3 I listed would leave the lint red. Good catch — the 4-line fix is correct and complete.
• Best-effort close semantics preserved: defer func() { _ = w.Close() }() discards the close error, which is appropriate for temp-dir cleanup in test teardown. The on-disk rotation artifacts don't need explicit close-error handling, and the test would only fail on t.Fatalf paths before the deferred close anyway. Pattern matches the existing codebase convention for test cleanup.
• No production code touched: the fix is constrained to the test file. No risk to runtime behavior, no schema/API change.
• Local verification matches dev report:
  • go build -tags no_web ./... OK (after dependency download)
  • go test -tags no_web -count=1 ./daemon/ ok 0.008s
  • go test -tags no_web -count=1 ./cmd/cc-connect/ ok 0.021s
  • Dev confirmed locally: golangci-lint v2.11.4 run --new-from-rev origin/main ./daemon/... → 0 issues
• Note on .golangci.yml _test.go errcheck exclusion: dev-claudecode verified empirically that under v2.11.4 + --new-from-rev mode, errcheck still flags defer Close in _test.go even when the YAML excludes that path. This is a known limitation of --new-from-rev (it runs each linter with a tighter config to catch only newly introduced violations, which can bypass YAML exclusions). Not in scope for this PR, but worth tracking as a separate follow-up to either fix the YAML or use a different errcheck.exclude strategy.

🔴 Must resolve before merge (NOT a comment on the lint fix itself, but blockers on the PR's merge state):

• Merge conflicts against current main: mergeable: CONFLICTING, mergeStateStatus: DIRTY. Conflicts in daemon/launchd.go (the new LogMaxBackups line conflicts with the EnvExtra changes from PR #1034) and daemon/manager.go (the new LogMaxBackups int field in Meta conflicts with downstream main changes). The branch was created 2026-06-08 from main at d408bd7; since then, PRs #963, #1012, #1034, #1285, #1289 have all merged into main and modified overlapping files. Dev action required: git rebase origin/main to bring the branch into sync, then re-test and re-trigger CI.
• CI re-run pending: gh api repos/chenhg5/cc-connect/commits/6be93571.../status returns state: pending, statuses: []. No check runs have been registered for the new commit yet (the only completed run is id 27109765660 from 2026-06-08 on d408bd7 which is the old failing run). Dev action required: if GitHub Actions doesn't auto-trigger after the rebase, manually trigger via the Actions UI or gh workflow run.

Testing / Risk:

• Verified evidence: build OK, tests pass, lint clean locally. The lint fix itself has zero functional risk.
• The merge conflict resolution is the real work remaining — it's a mechanical rebase, but the conflict in launchd.go requires care because both PRs add new fields to the EnvironmentVariables block. After rebase, re-verify the launchd plist still emits both CC_LOG_MAX_SIZE and CC_LOG_MAX_BACKUPS (and the new EnvExtra proxy vars from #1034).

Next step:

1. Dev-claudecode: rebase onto current main (git fetch origin main && git rebase origin/main), resolve the daemon/launchd.go and daemon/manager.go conflicts (likely trivial — keep both LogMaxBackups and the new EnvExtra/NoCaptureSecrets fields), force-push, wait for CI to re-run.
2. QA (next cycle): re-verify after CI re-runs green that lint passes and the launchd/systemd/windows templates still thread CC_LOG_MAX_BACKUPS correctly alongside the env-capture hardening from #1034.

Cannot approve yet because of the unresolved merge conflict + pending CI, even though the lint fix itself is exactly what was asked.

[chenhg5]

结论: Approve (rebase 复审 — 之前两个 pre-merge blocker 都已解决)

总体判断: Lint 修复 + rebase 冲突解决都已落地,CI 5/5 全绿,mergeable=CLEAN,可以直接合并。

Review 范围:

• 看了 daemon/launchd.go、daemon/manager.go、daemon/systemd.go、daemon/windows.go、daemon/logrotate.go、daemon/logbackups.go、cmd/cc-connect/main.go 的 rebase 解析。
• 重点关注 conflict resolution 正确性 + #1034 字段集是否保留。

✅ 做得好的地方:

• Rebase 解析干净:launchd.go 保留 main 的 xmlEscape(envPATH) + envExtra 实现,只新增 CC_LOG_MAX_BACKUPS 字段和 format arg;manager.go 把 LogMaxBackups 和 EnvPATH/EnvExtra/NoCaptureSecrets 完整拼起来,gofmt 对齐正确。
• systemd.go + windows.go 也都正确把 CC_LOG_MAX_BACKUPS 接在 CC_LOG_MAX_SIZE 之后、EnvPATH 之前,顺序合理。
• CI run 27300145281 五个 job 全绿(lint + unit + smoke + regression + performance),pre-merge 路径都通过。

🟢 已解决(t-20260610-3m6vr5 标记的 pre-merge blocker):

• ✅ Lint 修复:commit 6be9357 改名为 baf8322(同 commit,force-push 后 SHA 变)后 4 处 defer 全部用 defer func() { _ = w.Close() }() 包好,lint job 19:17-19:19 success。
• ✅ Merge conflict:rebase 到 origin/main c53f545 后,launchd.go + manager.go 冲突点已解析,两边的字段都保留。
• ✅ CI re-run:workflow run 27300145281 在新 head 上完整跑过,5/5 success。

🟠 P2(非阻塞,留作后续):

1. 重构机会:ParseLogBackups 和 ParseLogSize 结构几乎一致(trim+unit+负数+hex),但 generic helper 收益有限,等第三个类似 helper 出现再抽象。
2. daemon/logrotate_test.go 里的 itoa 重复实现(16 行)还在,等下次顺手清理。
3. 启动日志说 "source: env" 即使用户显式 --log-max-backups=0 也会走 fallback 到 default 3,help 文案可以更明确说明 "0 的语义"。

🔵 P3(可选):

• .golangci.yml _test.go errcheck exclusion 在 v2.11.4 + --new-from-rev 模式下不生效的问题依然存在,但 CI 端默认配置就能 catch 到 defer Close,不影响实际使用。值得开个独立 issue 跟踪。

Testing / Risk:

• 验证证据:本地 go build -tags no_web OK,go test ./daemon ./cmd/cc-connect 全 PASS,go vet clean;CI run 27300145281 5/5 success。
• 剩余风险:无新引入,纯增量修复(#1222 复现测试 + chain rotation 行为由 14 个新测试覆盖)。

Next step:

• 可以合并。合并后:1) 验证 issue #1222 自动关闭(PR body 已 reference);2) release-codex 准备 changelog 时把 #1243 + #1260 合并描述为 "log rotation: size + backup count";3) 后续可考虑给 Rotate() 和 MaxBackups() 加 SIGHUP hook(已暴露的公共方法)。