# UI/UX inbox - raw material parked for on-demand extraction

**The rule (Frank, 2026-07-03):** we do NOT bulk-digest link collections into the rules. Material parks here with provenance and a one-line note, untouched. Extraction happens **on demand, pull not push**: when a concrete need arises ("we need icon sources", "stock photo options", "a chart library"), an agent mines THIS inbox for that specific need and brings back only what answers it. The rules (README three layers) stays small and sourced; the inbox can be as big as it wants.

## Parked 2026-07-03 - generic web-design resource mega-lists

Three links, almost certainly the SAME "WebDesignResources.md" list (zero-to-mastery lineage) in three forks - treat as one source:

1. https://github.com/bhatanil/resources/blob/0558a9a62885c5c152e7690342d4cb561f773dd9/WebDesignResources.md
2. https://github.com/RichardBatka/zero-to-mastery-resources/blob/master/WebDesignResources.md
3. https://raw.githubusercontent.com/Shubhamkg7/resources/master/WebDesignResources.md

**What it likely holds** (typical awesome-list): color tools, font pairings, icon sets, stock photo/illustration sources, CSS frameworks, inspiration galleries. **Why parked, not digested:** hundreds of undifferentiated links; zero rules value in bulk; useful only as a quarry when a specific need names what to dig for.

**First candidate needs that would justify a dig:** icon set for the towers/taller · stock illustration policy · chart/dataviz tooling beyond Kennedy's color picker.

## Screen-mockup vocabulary (candidate block, 2026-07-19)
The leaflets (`2 - eR services/countries/Lesotho/services/register-a-business/leaflets/*-consolidated.html`) render eR form screens as hand-built clean mockups that read far better than scaled iframes of the bpa-visual-generator output (Frank flagged the difference 2026-07-19). Vocabulary worth promoting into documentation-kit.css as a `.screen` block: `.screen` (card) + `.screen-bar`/`.screen-dot`/`.screen-tab` (window header) + `.screen-body`; fields `.ff-label`/`.ff-box`; options `.rrow`/`.ropt`/`.ropt.sel`; `.snote` (info line); `.newbox`/`.newtag` (a highlighted new block); `.reg-list`/`.reg-row` (summary register). Reference use: `bo-registrar-note.html`, and the change document's BO section.

- 2026-07-21: new format registered: formats/proposal-note (the decision-ready proposal note: problem, options with pro/cons, one recommendation, implementation note, real-chrome mockup cards). Exemplar inside; visual-concept-expert now points to it.

## Board/dashboard card anatomy (Frank's verdict, 2026-07-29, BO execution view)
Frank prefers `bo-implementation-plan-dashboard.html` over a prose-row dashboard. Why, distilled: (1) numbers first — a four-metric strip tells the whole story before any sentence; (2) one card per phase, identical anatomy: name · state with score · date · collapsible Purpose/Done/Next · evidence links — the eye learns the card once; (3) state = card edge colour, the rail reads left to right; filter chips (All · Proven · Needs proof); (4) "Next:" lives on each card, so "what remains" needs no separate section; (5) one doctrine sentence, once ("Green means rows were read in the database"). Prose rows in panels = a report dressed as a board; rejected. This anatomy is the standard for service execution boards.

## Parked 06-08-2026 - GPT Image 2 prompt library (awesome-gpt-image-2)

https://github.com/freestylefly/awesome-gpt-image-2 - 520+ reverse-engineered prompt cases for GPT Image 2 (the engine our Higgsfield skill already defaults to for image/design/text), structured as reusable protocols, EN prompts + ZH translations, MIT. 12 categories; the ones that matter to us: UI interfaces, charts/infographics, posters, illustrations, brand identity.

**What it is for us:** a quarry of PROMPT PATTERNS for generated base-layer illustrations (scenery, people, light) under real HTML/SVG text - never for rasterized Spanish labels. **First candidate needs that would justify a dig:** the Sistema ABC nota conceptual main visual (one of the 3 options = generated illustrated base + SVG text overlay) · UI direction moodboards for the ABC prototype · style patterns for the future house concept-diagrams skill.

## Comparison grid anatomy, tools × criteria (candidate, 16-09-2026, tester bench)
Frank on the bench results table (16-09-2026): *"find a categorization that is recognizable in each line and allows you to compare at a glance one line with the other."* The paragraph-per-cell table failed; the rebuilt page is `3 - Projects/er-e2e-tester/consolidation-2026-09-16/bench/bench-results.html` (awaiting his word). Anatomy: (1) one mark per cell from five states, shape first and colour second so grayscale still reads: measured (filled circle, ink) · after patches (half circle, amber) · stopped (cross, accent red) · not run yet (empty circle, grey) · cannot run (struck circle, grey); the mark says the state of the measurement, never a score; (2) one bold headline figure beside the mark, one muted qualifier line under it, nothing else in the cell; (3) a legend line above the grid, the grid fits one screen at 1440 px with a sticky tool column and header; (4) the full text of every cell lives below in "Every cell in full", one `<dl>` per tool, each headline in the grid links to its cell and each block links back; (5) the md stays the source of the text, a sidecar `bench-cells.json` holds state + headline per cell, `build-bench-results.py` joins them (a hand-made html without the md-twin marker, so md-twin.py leaves it alone); (6) the run log as a two-column grid, time stamp left, event right. Candidate for the formats library once Frank confirms.