API & Naming Conventions — refactor-chain · backend lane · step 07/09

Bundle: refactor-chain (self-diagnosing, self-healing fix-it pipeline). Phase: do-the-work · Prerequisite: refactor-backend-06-dependency-guard · Next: refactor-backend-08-common-extract. Adaptivity / conditional: repo-agnostic — works on any layered backend project in any registry-detected stack. Spring/Jakarta idioms appear below as examples, not requirements; adapt the patterns to whatever web framework the repo uses.

Purpose

This step audits a Java codebase against API and naming conventions and then repairs the subset of findings that can be fixed without touching any external contract. It runs six severity-ranked checks — endpoint path structure, class naming, property naming, request-parameter conventions, response-wrapper conventions, and bean-name conflicts — and sorts every finding into fixable (safe internal rename or annotation change) or constrained (would alter a published URL, JSON shape, or parameter name, so it is reported but never auto-changed). Fixes are deterministic and idempotent: the same input always produces the same plan, and a second run over clean code changes nothing.

When to use

• Right after the dependency guard (step 06) has passed, and before shared-code extraction (step 08) — renames must land before files start moving between modules.
• When the user says "API naming check", "naming convention check/fix", "standardize endpoint paths", "fix class suffixes", or "resolve bean name conflicts".
• When a review found classes like OrderCtrl or UserSvc, duplicate bean names, or endpoints with inconsistent verbs and casing.