Semantic Module Rename — refactor-chain · backend lane · step 02/09

Bundle: refactor-chain (self-diagnosing, self-healing fix-it pipeline). Phase: do-the-work · Prerequisite: refactor-backend-01-architecture · Next: refactor-backend-03-dao-model. Adaptivity / conditional: repo-agnostic — the rename mapping itself is project-chosen; the skill supplies the safe propagation machinery.

Purpose

After step 01 the tree is layered, but module names may still carry legacy or template suffixes that hide their role. This skill applies a small, explicit rename mapping — for example {module}-server → {module}-controller (the HTTP edge) and {module}-server-com → {module}-service (the business implementation) — and then updates everything that refers to the old names: directories, each module's own artifactId, the parent container's <modules> list, the root dependencyManagement, every cross-module <dependency>, and affected Java package/import lines with the matching physical source relocation. The mapping is an example convention; the project picks its own pairs, and the propagation rules stay identical.

When to use

• The project completed step 01 and module names still don't state their layer role ("module rename", "naming pass on the modules").
• A house convention exists (or is being adopted) that certain suffixes map to clearer ones ("rename server to controller", "rename server-com to service").
• Precondition: the modules named in the mapping actually exist under their capability container. If a module was already renamed, the skill notes it and skips — safe to re-run.