Build with native UI elements

Use native controls and artwork when they match the requested appearance. Start with client targets: resolve each selected client and pin its branch before choosing templates. A template in the source tree may belong to another game family, depend on another addon, or have client-specific overrides.

For new visible UI, follow the design and mock-up choice before production implementation, honoring an already accepted design or choice.

Apply controller support to every UI element: distinguish decorative regions from interactive controls and plan focus, activation, back navigation, scrolling/text entry and action hints as applicable. Template inheritance alone does not certify controller navigation. Preserve the chosen native input paths and record any explicit user exclusion or target limitation.

1. Identify the component and ownership: an addon-owned window, ordinary control, reusable list row, or protected action control. Use element selection for the practical choices. Reskinning an existing CharacterFrame, spellbook, or other Blizzard window belongs in UI skinning.
2. Find the native example, its XML declaration and Lua mixins, then trace the owning TOC, includes, client selectors, dependencies and initialization. Record the resolved template, expected parent keys, required scripts, asset identifiers and verified client/build. The source map supplies dated starting points, not a universal template catalog.
3. Preserve the chosen template's behavior. Reuse its child references, normal/highlight/pushed/disabled state handling, resizing and layout lifecycle. Do not replace inherited setup scripts or alter shared fonts/layout tables to style one frame. Add your own children or use an addon-owned wrapper when composition is sufficient.
4. Choose a fallback separately for each target. A verified primitive composition may replace an unavailable convenience template; otherwise report the component unsupported for that target. Function presence does not prove matching arguments, template loading or addon permission.
5. Test the visible states and interactions listed in the element guide, using the existing UI design and testing choices and visual fidelity guide. Honor an accepted custom design; a stock button or border is not automatically a visual match. Reuse the user's established testing choice.

For exact native methods and script contracts, query widget APIs. For mixins, pools and load ownership, use FrameXML; for XML inheritance and script composition use XML schema. These references complement this construction workflow rather than replace client verification.

Keep ordinary decoration separate from protected gameplay behavior. Native artwork does not grant permission to move protected frames, set restricted attributes, perform actions in combat, or inspect secret values. Apply the selected client's verified restrictions. Report source verification, simulator results and in-game results separately; disclose stale evidence when current sources cannot be checked.