# New UI Pattern Pack

These files are local reference examples only.

They must not be added to `GH3.toc`.
They must not be loaded by the addon at runtime.
They exist to document the expected New GUI ownership and art-backed layout model for future edits.

The purpose of this pattern pack is to prove the themed GUI system before a live page is migrated.
If the static reference kit is not visually right, do not patch the live page yet.

## Ownership Model

`Shell` owns:
- window
- title
- tabs
- contentHost

`Page` owns:
- one fixed page rect inside `contentHost`
- only that page's frames and content

`Layout` owns:
- all x/y/w/h numbers
- panel sizes
- gaps
- page rects

`Assets` owns:
- texture paths
- source sizes
- inset metrics

`ArtFrame` owns:
- the outer frame rect
- the art texture
- the computed `Content` frame derived from scaled insets
- any optional decorative strip owned by that same frame, such as a top header strip or footer strip

`Content` owns:
- text
- icons
- rows
- small internal child layout

`Body` owns:
- the scroll/list/value region below an owned header strip when a frame needs one

## Hard Rules

- Page renderers do not anchor text directly to outer art frames when a computed `Content` frame exists.
- Child text and icons should anchor to `frame.Content`.
- If a frame has a decorative header strip, create `frame.Body` below it and anchor rows to `frame.Body`, not to the outer frame.
- Large decorative art should not be reused as unrelated panel fills unless it is explicitly designed for that use.
- One page change must not touch unrelated pages.
- Do not mix shell work, page work, data work, and routing work in the same slice.

## Repeatable WoW GUI Pattern

Blizzard's current shared UI code uses data-defined layout descriptions for scalable framed art instead of hand-tuning each frame. The practical rule for this repo is:

1. `Layout` provides the outer frame rect.
2. `Assets` provide the main art texture, source size, and content insets.
3. The frame builder creates one outer frame and computes `frame.Content` from those insets.
4. If the frame needs a decorative top strip or footer strip, that strip is owned by the same frame and described in data.
5. If a header strip exists, the builder derives `frame.Body` inside `frame.Content` below the strip.

This keeps skins data-driven: changing art metrics or strip assets changes the frame treatment without rewriting page layout code.

## Reference-First Workflow

1. Build one static themed dashboard reference using the real art assets.
2. Validate the visual language there first: cards, panels, rows, highlights, footer, icon framing, spacing, and text scale.
3. Only after that reference looks correct should a live page be migrated.
4. Live page code should connect data into the proven surfaces, not invent new ones.

## Reference Files

- `Pattern_ArtFrame.lua`: art-backed frame helpers for the reusable GUI surfaces: scalable frame, headered panel, and icon-led stat card.
- `Pattern_Page.lua`: a static Home-style dashboard reference using the real GH3 card, panel, badge, row, and footer art.

## Expected Flow

1. Layout defines page and panel rects.
2. Assets define texture path, source size, and inset metrics.
3. Page creates an outer root using the fixed page rect.
4. Page creates art frames from layout rects and asset metrics.
5. Text and icons anchor inside each art frame's `Content` frame.

If a future edit needs to move visible page structure, first inspect shell ownership, page rect ownership, and art-frame ownership before changing random offsets.