ui-pickerlisted

# ui-picker Before code: map the job to a **template** (shell) and **component semantics**. Appearance follows meaning. ## Steps ### 1. Density + scene Choose density (console-tight vs marketing-loose) and scene class (list / detail / settings / dashboard / editor / agent-admin / …). When a verified `.scratch/<run>/design-baseline/state.json` binds a baseline (`status: ready` from `design_baseline.verify`), read that binding path first (`baseline.path`, usually `DESIGN.md` or `.stitch/DESIGN.md`). It is the project-specific authority for atmosphere, visual roles, density, layout, motion, and component conventions. Preserve it unless the requested change explicitly revises the baseline. When `.scratch/<run>/reference/contract.md` exists (ADR-0011), read its **Visual cues for ui-picker**, Keep/Change, and Do not copy / exclusions. Use them as input for density, scene, region weight, and risks — never as hex tokens or as a license to copy brand chrome. **Done when:** one scene label and one density choice are explicit; a bound baseline is cited by path + SHA-256; if a reference contract exists, the decision report's risks or exclusions surface its Do not copy / brand risks (path citation is enough). ### 2. Template Read [`references/template.md`](references/template.md). Assign main / side / action / status regions. **Done when:** each region maps to a duty from `spec` L2 (or a stated gap in the spec). ### 3. Components Read [`references/components.md`](references/co