1.6 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| components/map-every-custom-component-and-centralise-it | Map every custom component, centralise it, and let a theme override it | components | open | 2026-08-21 | stated | 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.