Perf/bound review latency

[MingsingGo]

Description

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Refactoring (no functional changes)
• Documentation update
• CI / Build / Tooling

How Has This Been Tested?

• make test passes locally
• Manual testing (describe below)

Checklist

• My code follows the project's coding style (go fmt, go vet)
• I have performed a self-review of my code
• I have added tests that prove my fix is effective or my feature works
• New and existing unit tests pass locally with my changes
• I have updated the documentation accordingly (if applicable)
• I have signed the CLA

Related Issues

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

🔍 OpenCodeReview found 2 issue(s) in this PR.

• ✅ Successfully posted inline: 2 comment(s)

[github-actions]

[bug · high]
Bug: When maxTools is 0 (the default), the template's MaxToolRequestTimes is never overridden. However, the template validation in loadCommonContext checks if t.MaxToolRequestTimes <= 0 and returns an error. If the embedded template has MaxToolRequestTimes = 0, this will fail validation even though the user didn't explicitly set the flag. The old logic (if maxTools > tpl.MaxToolRequestTimes) would only override when the user explicitly set a higher value, preserving the template's default. The new logic breaks this by treating 0 as "use template default" but the template might have 0, causing validation to fail.

[github-actions]

[bug · high]
Bug: Scan command behavior changed. The change from maxTools > tpl.MaxToolRequestTimes to maxTools > 0 breaks the scan command's documented behavior.

In scan_cmd.go:111, the scan command still uses the old "only raise" logic:

if opts.maxTools > scanTpl.MaxToolRequestTimes {
    scanTpl.MaxToolRequestTimes = opts.maxTools
}

But now loadCommonContext will override the review template's MaxToolRequestTimes whenever maxTools > 0, even if it's lower than the template default. This contradicts the scan flag's help text at line 177: "max tool call rounds per file; only takes effect when greater than template default".

The review command should also only raise the limit, not lower it, to match user expectations and the documented behavior.

Suggestion:

Suggested change

	if maxTools > 0 {
	tpl.MaxToolRequestTimes = maxTools
	}
	if maxTools > tpl.MaxToolRequestTimes {
	tpl.MaxToolRequestTimes = maxTools
	}