refactor-ui

Refactor UI

Use when the next step is to edit UI code.

Rule

Remove or consolidate before adding. Preserve behavior unless the user explicitly asks to change product scope.

Inventory the visible surface.
- List titles, paragraphs, helper panels, badges, buttons, duplicated labels, empty states, and repeated suggestions.
- Mark implementation-detail copy for deletion or replacement.
Pick the minimum target.
- One title per screen area.
- One primary action per decision area.
- One path for each task unless distinct paths have clear user value.

Edit copy.
- Replace internal language with user action language.
- Delete copy that explains obvious controls.
- Keep labels short and concrete.
Edit structure.
- Remove nested cards and extra panels.
- Merge duplicate controls.
- Move secondary actions into icon buttons, menus, or quieter rows when appropriate.
- Keep repeated item cards consistent and compact.
Preserve app state.
- Do not break existing props, handlers, queries, routes, auth, or data contracts.
- Do not change backend, schema, or API behavior for presentation cleanup.
Verify in browser.
- Check mobile first.
- Inspect actual on-screen text, not only code.
- Confirm no duplicate primary CTAs or implementation words remain.

Read references/refactor-patterns.md when rewriting common leaky copy or simplifying repeated structures.

Read ../../references/modern-ios-app-design.md when the refactor also needs mobile or iOS taste calibration.

Use $design-frontend first if the flow itself is unclear, not merely cluttered.

The UI should look like a product, not a status report from the implementation.