Incorrect analyzer feedback: finalSalary should not be forced to use a ternary when Math.min is clearer

The Java analyzer is giving this automated feedback:

“As the goal of this exercise is to learn about ternary operators consider using them in finalSalary to solve this exercise.”

However, this feedback appears to be incorrect.
My implementation does use ternary operators where appropriate (e.g., in salaryMultiplier and bonusMultiplier), and the logic inside finalSalary does not naturally lend itself to a ternary expression. Instead, the method concludes by applying a salary cap using:

`return Math.min(salary, MAX_SALARY);`

This is the most idiomatic and intention-revealing way in Java to express “cap a value at a maximum.”
Forcing a ternary here would reduce clarity, for example:

`return salary > MAX_SALARY ? MAX_SALARY : salary;`

Both statements are functionally equivalent, but the Math.min version:
* more clearly communicates the intent,
* avoids nesting logic inside a ternary,
* reflects common Java practice,
* is simpler to read and maintain,
* aligns with standard clean-code guidelines.

The goal of the exercise is to learn ternary operators, not to artificially apply them in places where they decrease readability or duplicate existing standard library functionality.

Since the solution already uses ternaries appropriately and idiomatically in earlier methods, the analyzer's suggestion is misleading and encourages worse code, not better code. The feedback should either:

1. detect that ternaries are used elsewhere and suppress this suggestion, or
2. avoid prescribing the use of a ternary in situations where another construct is objectively clearer.

In short, the feedback should guide learners toward idiomatic, expressive Java—not toward unnecessary or forced use of syntax.

If needed, I can provide a minimal code example illustrating the issue.

找到发出所引用三元反馈的 Analyzer 规则，并使用 issue 中描述的练习重现该反馈。确定该规则如何评估 salaryMultiplier、bonusMultiplier 和 finalSalary 中的三元用法；完成标准是：当现有的 Math.min 上限合适时，它不再建议使用更不清晰的三元表达式，并为该反馈提供回归覆盖。

由索引模型根据 Issue 内容生成。