Julius here. Before you spend review time on the mockups taxonomy PRs, here is the whole picture: what the project is, what each PR touches, how it was built and verified, and previews for everything. At the end, a short feedback form (five calls + an open field) so we set the review up right. Nothing assumed, everything linked.
Mockups get a real taxonomy: categories → use-cases → sub-use-cases (Apparel → T-Shirt, or Apparel → Hat → Cap), maintained by the content team in the CMS. This project brings it to both places people browse mockups, on one shared data layer:
Dashboard: the /mockups page moves from group-only navigation to the taxonomy: category chips → use-case lanes → drill-in grid with sub-use-case filter tags, search from anywhere. Ships first to the team for the dogfooding round.
Editor: the Mockups panel is rebuilt to match the Textures/Illustrations panel UX on the same taxonomy: one tab per category, expand-in-place lanes per use-case, sub-use-case filter, sort and search. Fully behind the mockups-taxonomy-panel feature flag; with the flag off everything behaves exactly as production today.
Already merged: the CMS taxonomy API (github.com/Kittl/cms/pull/1749, GET /api/mockups/taxonomy + /by-use-case) and the swimlane abstraction (github.com/Kittl/mono/pull/12582). Staging CMS is fully seeded (9 categories, 69 use-cases); production gets the endpoint with the next CMS release. That release gates the dashboard merge, not the flag-gated editor PRs.
@repo/mockups (one taxonomy client both surfaces use: query options, keys, types matching the CMS payload, plus a pagination fix) and the swimlane shell in @repo/elements-panel (a carried-over-lane guard and an opt-in persistentScrollbar, both regression-tested), plus the editor's data plumbing (panel store, query keys, feature flag). No user-visible change on its own.@repo/mockups; the types match the CMS payload exactly (verified against the live endpoint). Includes a pagination fix: infinite feeds stop at the server total instead of firing a trailing empty request.Pick an answer per question, notes optional. Then Copy answers at the bottom and paste it in Slack.
Four PRs total instead of one giant review per surface. If you would cut it differently (coarser, finer, different boundaries, different order), say so before we go deep.
The editor work and the dashboard work each grew their own taxonomy fetch code; the foundation PR unifies them into one client in @repo/mockups before either merges, so there is a single contract and a single set of types. Each surface keeps its own UI state on top.
The panel store keeps the fetched tree and revalidates selections on refresh, following templatePanelStore / elementsPanelStore. The alternative is ids-only in the store with objects derived from React Query. If you prefer ids-only, the ask is to take it as a follow-up rather than rebuild before launch.
// as built (matches templatePanelStore precedent)
store = { taxonomy: {...full tree...},
filter: { expandedUseCase: {...object...} } }
// alternative (ids-only, artboard-creator shape)
store = { filter: { expandedUseCaseId: 201 } }
// objects derived from the React Query cache at render time
One deliberate wrinkle either way: a use-case opened from a mockup's tag can live outside the panel taxonomy and must survive refresh (its feed is fetched by id). Both cases have store tests.
The foundation PR adds a carried-over-lane guard and an opt-in persistentScrollbar to the shared swimlane components (Illustrations/Textures behavior unchanged, regression-tested). The dashboard deliberately does not reuse those components: its lane is a simple carousel with a View-all drill-in, so it has a small presenter of its own. Unifying the lane implementations is a follow-up candidate, not part of this stack.
Two deliberate short-term choices: (a) the mockup popover takes a legacy callback (tag click = text search, exactly production) and a new one (navigate to the use-case), the legacy one winning when present, collapsing to one after rollout. (b) ?mockups-taxonomy-panel=1 force-enables the panel even in production bundles because flags cannot be configured on ephemeral previews (same pattern as the monetisation override); until launch, anyone with the param can see the read-only panel.
Order preferences, missing context, things that look over- or under-engineered, anything else.