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

Locate the analyzer rule that emits the quoted ternary feedback and reproduce it with the exercise described in the issue. Determine how the rule evaluates ternary usage across salaryMultiplier, bonusMultiplier, and finalSalary; done means it no longer recommends a less-clear ternary when the existing Math.min cap is appropriate, with regression coverage for the feedback.

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.