[business-logic] breaking_change_check truncation always reports 0 more changes — agent misses unreported breaking changes

[topcheer]

Bug: breaking_change_check.go truncation always shows "...and 0 more"

File

internal/agent/breaking_change_check.go lines 92-96

Problem

The truncation logic for breaking change warnings always reports "0 more" breaking changes regardless of how many were actually truncated:

if len(warnings) > 2 {
    warnings = warnings[:2]  // ← len(warnings) is now 2
    warnings = append(warnings, fmt.Sprintf("...and %d more breaking change(s)", len(warnings)-2))
    //                                                                  ^^^^^^^^^^^^^^^^ = 2-2 = 0, ALWAYS
}

Root Cause

warnings = warnings[:2] truncates the slice to length 2 BEFORE computing len(warnings)-2. So the count is always 2-2=0.

Impact

When 3+ exported symbols are modified simultaneously (common in refactoring), the agent sees only 2 warnings and is told there are "0 more" — misleading it into thinking all breaking changes are covered. This causes the agent to miss updating callers of the remaining changed symbols.

Comparison with correct pattern

close_error_check.go (lines 82-86) implements the same truncation correctly:

if len(warnings) > maxCloseErrWarnings {
    truncMsg := fmt.Sprintf("... and %d more ignored Close() error warning(s)", len(warnings)-maxCloseErrWarnings)
    warnings = warnings[:maxCloseErrWarnings]
    warnings = append(warnings, truncMsg)
}

Here the count is computed BEFORE truncation, which is correct.

Fix

if len(warnings) > 2 {
    moreCount := len(warnings) - 2  // compute before truncation
    warnings = warnings[:2]
    warnings = append(warnings, fmt.Sprintf("...and %d more breaking change(s)", moreCount))
}

Severity

Medium — functional but misleading. No crash, but causes the agent to miss breaking changes during refactoring.

Verification

Independently verified by sub-agent with a constructed test case showing 5 warnings produce "...and 0 more" instead of "...and 3 more".

[topcheer]

已修复 — commit b3f9dbe

问题根因：截断逻辑先执行 warnings = warnings[:2]，再计算 len(warnings)-2。由于切片已被截断为长度 2，结果永远是 2-2=0。

修复内容：在截断之前先计算 moreCount := len(warnings) - 2，然后用 moreCount 生成截断提示。与 close_error_check.go 中的正确模式一致。

验证：go build -tags goolm 通过，9 个 breaking change 测试全部通过，pre-commit hooks 全部通过。