What's changed

Adds a focused recipe that simplifies literal-first AssertJ size assertions — where the meaningful expression sits on the isEqualTo(...) side rather than inside assertThat(...):

// before
assertThat(4).isEqualTo(predecessors.size());
assertThat(1).isEqualTo(g.getIndependentNodes().size());
assertThat(2).isEqualTo(s.length());
// after
assertThat(predecessors).hasSize(4);
assertThat(g.getIndependentNodes()).hasSize(1);
assertThat(s).hasSize(2);

This is the always-safe Case A from the issue. The underlying comparison is on a primitive int (Iterable.size(), Map.size(), CharSequence.length(), or array .length), so reversing the assertion into hasSize(...) is unconditionally behavior-preserving.

Case B (arbitrary object equality, e.g. assertThat("1").isEqualTo(list.get(0))) is intentionally left untouched, since reversing it would change which equals() is invoked and is unsafe for asymmetric/broken equals implementations.

Guards

• Only fires when assertThat(...) holds a non-negative int literal (negative hasSize throws at runtime, so reversal there would change behavior).
• Only matches structural size/length calls on the isEqualTo argument; other int-returning methods (e.g. indexOf) are left alone.

The recipe is wired into the AssertJ best practices composite next to SimplifyHasSizeAssertion, and recipes.csv was regenerated via ./gradlew recipeCsvGenerate.

• Fixes SimplifyChainedAssertJAssertion: also simplify "literal-first" assertions where the expression is in isEqualTo(...) #1031