---
id: components/map-every-custom-component-and-centralise-it
title: "Map every custom component, centralise it, and let a theme override it"
theme: components
status: open
created: 2026-08-21
date_source: stated
order: 1
---

**Map every custom component, centralise it, and let a theme override it.** Wanted 2026-08-21. Two
halves, in order: first the survey — every custom component used around the app that ought to live in
the `officerdev` workspace instead of where it sits now — then a mechanism for a **theme** to override
a centralised component rather than being limited to recolouring it.

**The owner knows the design he wants and recorded this only so it is not forgotten.** Do not invent an
approach here; ask him for it when the item comes up.

Scale of the survey, counted 2026-08-21: `src/workspaces/components/` holds 26 entries including 51 `ui`
primitives, while `src/apps/officer-web` has 105 `.tsx` files and `src/workspaces/officerdev/src` has
118. Most of those are screens and panels rather than reusable pieces, so the map is the work — the
number is only the haystack.

One fact the override half runs into: **a theme is CSS today, and nothing else.** The 25 files under
`src/workspaces/theme/css/themes/` are generated variable blocks (`[data-theme='…'] { --background: … }`)
built from Omarchy palettes by `scripts/generate-themes.ts`, and they carry no component information at
all. Their header says not to edit them by hand, because the previous port drifted exactly that way —
so a per-theme component override needs somewhere new to live, and it cannot be a hand-edit in a
generated file.