The three previous attempts at this job died of endlessness, not difficulty. Nothing
stopped the next component arriving with its own `text-emerald-400` while an old one
was being fixed, so the number never fell for long.
`bun run check:theme` counts palette classes per directory against a committed
baseline. It does not care what the number is, only which way it moves. 942 across 21
directories today. Every directory can be paid down independently and none can quietly
regrow — which turns an infinite job into a finite one.
A baseline rather than a ban, deliberately: a rule forbidding palette classes outright
fails on its first run, and a check nobody can make pass is a check everybody turns
off.
Proven by adding one `text-emerald-400` and watching it fail with the directory, the
delta, and what to use instead.
── Documentation, which is part of the work rather than after it ──
`src/workspaces/theme/README.md` is new and is the contract: how to write a theme, all
84 declarations by family, why colours are unwrapped HSL triplets while surfaces are
complete CSS values, why assets are quoted paths, and the rules for components. Start
from Plain, not from Duck — every value you change is then one you decided about.
`plugins/EXTRACTING-A-PLUGIN.md` gains a rule beside the others: a plugin never
hardcodes a colour, and pays its debt down DURING the extraction. The counts are named
there — Soulseek 313, Invoices 95, Wallet 68 — because "some colours" does not convey
that it is two thirds of the platform's total. The kickoff prompt says the same thing
in the form a fresh agent will meet it.
That is what makes the plugin exemption safe rather than a way of losing the work: the
ratchet stops covering a directory the moment it leaves, so the rule has to travel with
it.
`THEMES-NOTES.md` rewritten to match reality — it still listed done things as open.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A theme references its wallpaper and logo by path because the CSS bundler cannot
resolve a runtime `public/` file at build time. That is fine for themes we ship and
says nothing about where a third party's assets live. The owner's intent is a
convention under `public/` — recorded so the workaround is not mistaken for a design.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The screenshots said seven dark screens differed and could not say why. Comparing
COMPUTED theme variables between the old build and the new one, in the same colour
mode, answered it in a single run: 47 of 53 matched exactly, and the six that did not
were the `--duck-*` variables — EMPTY in the new build.
The utilities were remapped to `--brand-primary`, `--ink` and friends, which is
correct. What that missed is code reading the VARIABLE rather than using the utility.
`prose.css` does exactly that eleven times — chat markdown links, blockquotes, inline
code, checkboxes — and `landing/styles.css` does it six more. All silently resolved to
nothing.
Fixed by keeping the legacy names as aliases in every theme, pointing at the new
source of truth rather than duplicating values. That also covers any plugin or inline
style doing the same thing, which I have not enumerated. They retire when the utility
rename lands.
Every variable now matches.
── What the screenshots are actually worth here ──
Less than I assumed. The wallpaper rotates per page load, so a control capture of the
same build against itself had 4 of 16 screens differ — and a different 4 each time.
Between 5 and 6 come out byte-identical to the baseline on any run; the rest is noise
I mistook for signal for two rounds, including one where I removed a `color-scheme`
line to test a theory it turned out not to explain.
The variable diff is the instrument that settles it, and it is cheap. Added as
`scripts/theme-vardiff.ts`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The application no longer knows what it looks like. It imports one stylesheet and
mounts one provider; every colour, surface and radius lives in `src/workspaces/theme`.
Proven both directions, because either alone would be worthless:
Duck renders IDENTICALLY to before — checked against screenshots taken before
anything was touched, not asserted.
Plain renders as white with black ink, no component edits — panels turn white, the
teal avatar turns black, the grid fills vanish.
── What moved ──
`globals.css` held three unrelated things: Tailwind wiring, the token contract, and
the Duck brand's hex values. Split along those seams. `base.css` is structure and
names no colour; a theme file is values and nothing else, scoped to
`[data-theme='<id>']`. Adding a theme is a CSS file plus one registry line.
Light and dark are separate themes rather than a mode — the owner's call, and it
removes a concept from the app. Each is written out in full: a theme that only makes
sense as a diff against another cannot be authored by a stranger or sold to a
customer. `.dark` survives only as a per-theme flag, because 396 `dark:` utilities in
33 components resolve against it; retiring those retires the flag.
The `duck-*` utility names are kept for now and pointed at neutral variables, so a
non-Duck theme can define them sensibly. Renaming 1,470 occurrences in the same commit
as the extraction would make any visual difference impossible to attribute. Worth
recording that `duck-dark` was never a brand colour — `#14532d` in light, near-white
in dark, used by 946 components to mean "text". It is `--ink` now.
Surfaces are complete CSS values rather than HSL triplets: `--panel-bg` has to be able
to be a gradient or an image, or the glass the app already has would be unthemeable.
The old provider is a re-export, so its six call sites are untouched and the
extraction stays one variable.
── Bug found by the Plain theme ──
`useThemeSync` stamped the server's `appearance.colorMode` over the local theme on
every load, so choosing Plain and reloading silently reverted it. Diagnosed by asking
the page what it was wearing rather than reasoning: `stored` said `duck-dark` when the
script had written `plain`. The server value is now a starting point for a browser
that has never chosen, not a continuous instruction.
── Tools ──
Two, both of which lied to me before they worked. The snapshot script photographed
light twice and called it a clean run (one browser context, accumulated init scripts);
it now warns when a light/dark pair is identical. The preview server returned the
shell for missing assets, so the logo and wallpaper vanished and read as regressions
in the comparison — it falls through to upstream now.
Dead Tailwind v3 residue deleted: `components/ui/tailwind.{config.ts,css}`, referenced
by nothing, with content globs pointing at a directory that does not exist.
── Not done, deliberately ──
`THEMES-NOTES.md` has the full list. The headlines: the reference repo has not been
read, so the switching mechanism is deliberately the dumbest thing that works; the
wallpaper, panel radius and logo are still component-owned and Plain proves it; and
~985 raw Tailwind palette usages remain, worst in Soulseek.
tsgo clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhasandClaude Opus 5