half of the primitive kiosk needs. the manifest field and its validator are in;
the mounting is documented and not wired, so nothing serves anything publicly
today.
paths are relative to the plugin's own mount and refused rather than corrected:
no leading-slash-missing, no .., no //, no query or fragment, wildcard only as a
trailing /*, and never the bare / or /*. the plugin is trusted with what those
paths DO, never with which paths.
the mounting was measured rather than reasoned about, and two obvious designs
are wrong:
mounting the public router at the plugin prefix gives correct fall-through but
lets the router serve any route it defines - the manifest becomes documentation
rather than enforcement.
adding a use('*') guard blocks that leak and BREAKS the plugin's authenticated
api: a use('*') middleware always matches, so the parent never continues.
measured - an authenticated route 404'd with a valid token.
what works is registering only the declared patterns, delegating into a
pre-mounted app. undeclared paths never register a handler, so they fall through
naturally. enforcement by registration rather than by checking, which is why a
plugin cannot widen it.
docs/plugin-unauthenticated-paths.md has the probe results and the six
remaining steps.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
a sweep for remnants after 2026-08-18. nothing was broken - no dangling
import, symbol, route or permission key anywhere in src/ - but the platform
was still speaking the plugin's vocabulary in a dozen places.
the one that mattered is live code rather than prose: ChatPanelWrapper
hardcodes workspace.id === 'email' to send context: 'email', which is the
frontend half of the pair whose backend half (resolveEmailCwd) carries a
fifteen-line justification. the two ends now both say so, including that
adding a SECOND id there is the signal the platform needs a real way for a
plugin to declare a chat context.
the rest: two dead imports left by removing the settings section, an empty
'Email' type-section header, a protocol.ts section header with no members
naming the plugin's SSE design, and a queue comment pointing at
sidecar/email/sync-runner.ts - a path in another repository now.
CLAUDE.md, AGENTS.md and working-on-officer.md described email as a platform
feature, an app permission and a pm2 process. those are the files a fresh
agent reads first, so they were the highest-risk staleness in the tree.
TODO.md's whole Email section moved to the plugin's own repository. it held
OPEN items pointing at sidecar/email/store.ts, which is exactly how a leftover
list sends someone to edit files that do not exist.
the delete-account dialog promised it would remove email accounts and
playlists. both tables belong to plugins now, so that cascade only happens
where the plugin is installed - it now says 'anything an installed plugin
keeps for them' instead of naming two it cannot guarantee.
imapflow and mailparser STAY in package.json. the plugin has no package.json
of its own and resolves from the platform's node_modules, so removing them
would break the installed plugin's sidecar. the fix is giving plugins their
own dependency manifest, not deleting these.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
the sidecar, the router, the table, the screens and the account manager are
gone from src/ entirely - deleted, not commented, because a commented mount is
what assertPermissionTotality cannot see.
three reverse imports had to go first, and they are what decided the boundary.
core may not import a plugin's queries, and one of these had already proved
why: getEmailAccounts was awaited at the top level of the agent sidecar, so
when the table went away on 2026-08-13 the rejection took officer-agent into a
pm2 restart loop with every live chat session inside it (fbb6d6c7).
both survivors now read the DISK instead. findEmailAccountName() in
data-path.ts picks the newest emails.db under an account's email_accounts/
directory - no import, no query, and nothing to throw when the plugin is not
installed. the layout was already the platform's, so this costs no coupling.
the agent keeps its email_db tool and an email-context chat still opens in the
right mailbox.
the google oauth callback no longer appends /email to the dock: a plugin's
route is the plugin's business.
app-store/catalogue.ts entry deleted, and that is the whole point rather than
tidying. permissionAvailability derives from sidecar_installs and a plugin only
ever gets a plugin_installs row, so a leftover entry makes the permission
permanently unavailable - denied route, no dock tile - on a machine where the
plugin is installed and healthy. it has bitten headscale and nearly music.
two app-store tests used email as their config-only fixture; repointed at
notify, which is the same shape.
google-auth stays in core and the plugin imports it via @@/. that direction is
allowed and google-auth knows nothing about mail.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
the owner has no time to test any of it, so the checklist has to work for
someone with none of today's context: eleven ordered tests, what each should
show, and what its failure looks like.
test 4 is called out as the one most likely to be wrong - approving
ExitPlanMode drops the harness into default rather than back into
bypassPermissions, which is the finding that changed the design and therefore
the thing the implementation is most likely to have got wrong.
also separates what was verified from what was not: the probe runs against a
real claude, the turn-stream unit tests, and then everything end to end, which
is nothing.
the inline 'what to watch' list in chat-plan-mode.md is replaced by a pointer
so there is one source of truth, and TODO.md now says live-but-unexercised
rather than built-not-run - the restarts are done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
the owner confirmed the additional accounts are test rows - none has ever
signed in, no member has opened a shell or a chat. so the proxy secret was
readable by accounts that do not exist in practice, and there is nothing to
rotate.
the mode fix stands: it is about the install that gets used, not this one.
dropping the TODO and recording the reasoning instead, because a rotation item
left sitting there reads as outstanding work forever, and the next person to
find a world-readable secret should ask who uses the box before reaching for
the alarm.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
data/sidecar/claude-state.json holds proxySecret, and that string IS the
owner's Claude Max subscription: officer-anthropic-proxy accepts it as
x-api-key, swaps it for the owner's OAuth bearer and forwards to
api.anthropic.com. it listens on 127.0.0.1, which every local account can
reach.
it was 664 in a 775 directory. nothing had ever set a mode - mkdirSync and
Bun.write at ubuntu's default umask of 002. confirmed by reading the live
secret as 'nobody', an account with no relationship to the platform, and by
confirming the proxy 401s without the key so the secret is the only control.
this does NOT mean members shared the subscription. spawnClaudeAsMember runs
their claude through setpriv --reset-env with a six-name allowlist, so
ANTHROPIC_BASE_URL and ANTHROPIC_API_KEY cannot cross into it and their turns
go straight to anthropic on their own OAuth. that design is intact - it could
just be walked around by anyone with a shell.
fixed twice on purpose. state.ts sets 0600/0700 on every write, which is the
authoritative fix, and on every write rather than at creation because
writeFileSync leaves an existing file's mode alone. secureRuntimeSecrets()
sweeps at boot because officer-anthropic-proxy is a separate pm2 process that
can recreate the file hours after officer started, and because every existing
install has the old mode until something repairs it.
it repairs rather than refusing to boot, unlike assertSecretsClosed beside it.
the line is who wrote the file: .env is the installer's and we must not guess
at it; this is our own output at the machine's umask, so refusing to start
would punish the user for our bug.
the per-account copies are swept too. no live secret in them today, but they
map session keys to transcript uuids for named accounts.
tests verified to bite: removing the chmod while still reporting success fails
four of them.
a chmod does not undo exposure - the secret still needs rotating on the
production host. TODO.md has the sequence, including that officer-claude-code
caches it and must be restarted alongside the proxy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
opusplan has been in the picker since 57bbcca9 and did nothing: it means
'Opus while planning, Sonnet at rest', and claude-manager hardcoded
permissionMode: 'bypassPermissions', so a session never entered plan mode
and opusplan rested forever on Sonnet.
verified against a real claude first (SDK 0.3.233), and one finding changed
the design: approving ExitPlanMode drops the harness into 'default', NOT back
into bypassPermissions, and the agent carries on inside the same turn. so the
restore is fired the moment approval is given rather than at turn end, and
canUseTool allows everything that is not ExitPlanMode - for a few hundred ms
it is the only thing between the agent and its tools, and a default-deny there
would jail an agent the platform deliberately does not jail.
canUseTool is passed always. under bypassPermissions the SDK shadows it
entirely (CLAUDE_SDK_CAN_USE_TOOL_SHADOWED) so it costs a log line, and since
it is a query() option read once, passing it unconditionally is what makes the
mode toggleable on a live conversation instead of only at session start.
sticky per session on chat_session_models.plan_mode, beside the model because
they are one decision about what a turn costs. boolean rather than the
PermissionMode string: officer exposes two of the five, and a text column would
accept three the sidecar cannot handle.
plan approval is the only place the agent blocks on officer - a canUseTool
promise held in the sidecar while the plan round-trips to a browser. every path
that ends a session or a turn settles it as refused, plus a 20m timeout, because
a leaked entry is a hung turn rather than a stale value.
not auto-entered for opusplan: the CLI does not either. the toggle says so
instead - 'opusplan rests on Sonnet, turn on Plan for Opus'.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
opusplan is in the picker and does nothing on this install: it is a per-MODE model switch (Opus while in
plan mode, Sonnet at rest — the CLI's own strings call them the upgrade and resting models), and
claude-manager hardcodes permissionMode: 'bypassPermissions', so plan mode is never entered. Not
orchestration, which is what the name suggests and what we both assumed.
Making the mode reachable is the fix. setPermissionMode is a control request on the live query, same channel
as the setModel that landed in 4c24df93, so the mechanism is proven. The hard part is ExitPlanMode: it is a
permission decision, and bypassPermissions auto-approves it, so a naive toggle produces a planner that
instantly approves its own plan. canUseTool is the hook, and whether it can be supplied after session
creation is the one thing to verify before designing any UI.
Records the landmines too — bypassPermissions is deliberate per CLAUDE.md and must be restored on exit, and
a canUseTool promise that never resolves wedges the turn.
The rows sat flush against their own heading and against the next directory, so an expanded node ran into
its neighbours as one undifferentiated column — the tree stopped reading as a hierarchy at exactly the
moment it had one.
pl-8 lines the rows up under the heading's TEXT rather than under its chevron, which is what makes "these
belong to that" legible without drawing a guide line, and py-2 separates the group from the headings above
and below it.
The selected model went blank after a turn: visible only by opening the dropdown.
`officerModel` was coming back as `claude-code` — the bare harness. That is `DEFAULT_MODEL`, used when the
client sends no model and the user has no default. It ROUTES fine (isClaudeModel is a prefix test, and
split('/')[1] is undefined so the CLI picks its own), but it names no catalogue entry, so Radix's
`SelectValue` matched no item and rendered nothing.
It fed itself. A blank picker sends no model, so the next turn fell back to the bare harness again and
overwrote the real value — it destroyed a correctly backfilled `claude-code/opus` within one turn. My own
write path did that, added this afternoon.
Two changes. The server refuses to record a model with no tier: a bare harness means "no explicit choice",
and the honest response is to leave the previous answer alone rather than overwrite it with a non-answer.
And the trigger no longer trusts that its value names an item — an unmatchable value renders as its own
string instead of as an empty control, which also covers a retired model or a vanished OpenCode provider.
Repaired the one corrupted row in place by deleting it, so the transcript family fallback answers for that
session until its next real turn; it now reports claude-code/opus again.
Four things, three you asked for and one the screenshot gave away.
The separator under the tabs now borrows the panel header's own tokens — --panel-header-bg and
--panel-header-border — rather than bg-muted/30 + border-border. Two rules a few pixels apart that do not
match read as a mistake, and border-border was faint enough here to look like no separator at all.
The active tab was bg-background sitting on a bg-background/60 track: a few percent of opacity was the only
thing distinguishing it. The track is gone, each tab is its own control with a gap between them, and the
active one carries a border, a solid fill and a shadow so it reads as raised.
Directory headings are sticky and heavier. An expanded directory can be taller than the panel, so the
heading scrolled away with its contents and halfway down a long list nothing on screen said which directory
you were reading. Opaque bg-muted, not a tint — a translucent sticky header shows the rows sliding under it.
And the paths were rendering backwards: dir="rtl" keeps a long path's tail visible but reorders the whole
string, so ~/officer-dev/platform displayed as officer-dev/platform/~ with the home marker at the end. Plain
truncate now, full path on the title.
The /chat sidebar was two panels in a vertical 25/75 split — Live above, Sessions below — plus a directory
dropdown in the list header. Three problems that compounded: the Live panel was empty almost always, so a
quarter of the sidebar was permanently blank; the two panels had entirely disjoint indicators, so a
conversation with a turn running looked ordinary in the history; and the dropdown showed one directory at a
time, which turned "where was I working on that" into a search.
Now one panel, three tabs. Tree answers "what have I got, by project". Latest answers "what was I just
doing". Live answers "what is running". Same rows, same indicators, one place.
Tree is an accordion over /chat/pwds, each header carrying the full path from ~, the session count, and a
live count — plus New Chat here, since the tree only lists directories that already have history. A
COLLAPSED NODE ISSUES NO REQUEST: sessions are read by scanning transcripts off disk, and eager mounting
would be one scan per directory for rows nobody asked to see. `useClaudeSessions(cwd, {enabled})` is the
whole mechanism. The per-directory live count comes from the poll's own `cwd`, never from
`liveSessionTitle`, which reads a whole transcript and whose own comment warns against calling it from
anywhere hotter than a ten-second poll.
Latest needs a new server mode, `GET /chat/sessions?all=1` → `listAllClaudeSessions`. It loops directories
rather than scanning flat, because /clear chains are merged per group and a flat scan would let two
unrelated chains in different directories collapse into each other. Fetched only while the tab is showing.
Rows now carry the model, from the batched `getChatSessionModels` — one query per page, which is what that
query was added for.
THE MIGRATION IS THE DANGEROUS PART AND IT IS INVERTED. Every persisted layout still names `chat-live`, an
appType that no longer exists; `normalizeLayout` would collapse it onto the fallback and WRITE THAT BACK,
which is what made /offscale render three server pickers this morning (ed3806f9). The existing guard adopted
layouts LACKING the panel, so it had to flip to adopting layouts that HAVE it. defaultLayout.test.ts pins
both halves: the replacement must not contain the appType the guard tests for, or the effect fires on its
own output forever.
Deletes LiveSessions.tsx and PwdSelector.tsx — both replaced. Fixes the inherited bug in passing: the
"generating" Loader2 never had `animate-spin`, so the one indicator meaning "work is happening right now"
was a static icon.
View and expanded-node state go in localStorage, not the URL (a tab is a preference, and every session link
would carry it), not usePanelConfig (a NO-OP setter in a locked workspace, and /chat is locked), and not
useDashboardState (its PATCH only accepts layout-shaped objects). /chat/g/<path> still works and opens that
directory in the tree.
Untested against a running server: officer has not been restarted since these changes, and I am not
restarting it mid-conversation. `?all=1` and the model field are verified only by typecheck.
`createMessageHandler` is built per turn, so `transcriptId` started null on every one — and
`applyModelChange` runs before the turn emits anything, so the `model:switched` it produces arrived while
there was nothing to key the row on. A resumed conversation therefore recorded its model only on the closing
`result`, and a turn that died took the switch with it.
Observed rather than reasoned: the sidecar log said `claude-code/fable -> claude-code/opus[1m]` while the
stored row still said `claude-code/opus`.
Seeded from the resume id, which the Claude path already has in scope for the spawn. A brand-new
conversation still waits for `session:claude` — it has no id yet by definition — but resumed is the case
where switching actually happens.
Also lands docs/chat-sessions-list.md: the plan of record for the sessions-list revamp, agreed with the owner
today. Six numbered targets, four decisions with their reasoning, and the landmines — chiefly that merging
the two left-column panels strands `chat-live` in every persisted layout, which is the same stale-appType
shape that made /offscale render three server pickers this morning (ed3806f9). Written down because the shape
came out of a conversation, not out of the code.
resume a conversation and the model picker showed the first entry in the catalogue instead of the model the
session was actually on. that was invisible for as long as the first entry was `opus`, and became obvious
the day `fable` went above it — so this is a pre-existing bug my model-list change exposed, not one it
introduced.
two defects, stacked.
the value did not survive a refresh: `initialModel` came from `props.model ?? locationState?.model`, and
both are volatile — a panel channel and react-router location state. on a hard load neither exists, the
settings default is skipped (it only runs for NEW chats), and ModelSelector's fallback effect fired
`onModelChange(providerModels[0].id)`.
and even when it did arrive it could not match. a transcript records the API model; the picker offers CLI
aliases. `claude-opus-5` is in a different id space from `claude-code/opus[1m]`, and the mapping is one-way:
opus and opus[1m] both serve claude-opus-5, opusplan serves whichever model answered. read out of a real
59MB transcript, the distinct values were claude-opus-5, <synthetic>, claude-sonnet-5,
claude-haiku-4-5-20251001, claude-fable-5 — note the synthetic marker and the inconsistent date suffix.
so the transcript cannot answer "what should the picker show", and a new table does:
chat_session_models (session_id pk, model, updated_at)
officer's own id space, so opus[1m] and opusplan round-trip. keyed on the TRANSCRIPT uuid rather than
officer's session id, because that is what the session list joins on — which is why the write waits for the
harness to announce the id rather than firing at turn start. records the EFFECTIVE model, so a refused
switch stores what answered.
not derived from chat_session_events, which does now hold model:switched: right data, wrong index. that
table holds every assistant message and is unbounded, and "latest model for these 200 sessions" would scan
far more than the question deserves. not a chat_sessions table either — a session IS its transcript, and a
row holding title and cwd would be a second source of truth for two fields that already have one.
BACKFILL RUNS FROM postdb:push, so every server picks it up on its next schema push. bun does fire pre/post
hooks for colon-named scripts — verified on 1.3.14 before building on it, because a post hook that silently
never runs is the worst outcome here. insert-only, exits 0 on every failure path (the push has already
applied; a cosmetic backfill must not make it look failed). seeded 11 of 12 transcripts on this machine.
it reads the FIRST model, which sounds wrong for a table storing the current one — but switching only
became possible today, so no older transcript can hold two, and first costs a bounded head read instead of
reading 59MB.
also: the family map returns null for mythos rather than a neighbouring family (Project Glasswing only — a
picker entry that 401s is worse than none), and ModelSelector no longer picks a default once a conversation
has started. an unset picker is the honest state when the server cannot say.
tests: the alias map against the five real transcript values, and the selector's default gated on
hasStarted. re-broke the guard to confirm it bites.
still to do: `model` on the session LIST rows, which the sessions-list revamp wants. the storage and the
batched read (getChatSessionModels) are in place for it.
the claude tier list had three entries — opus, sonnet, haiku — and the CLI accepts nine. `--help` says
`--model` takes either an alias for the latest model in a family or a full name, and the aliases the
INSTALLED cli accepts came out of its own binary with `strings` rather than from memory: default, opus,
sonnet, haiku, fable, mythos, opusplan, and a [1m] suffix on the families with a 1M-context variant.
verified against 2.1.233.
aliases rather than full ids (claude-opus-5) so a new model in a family needs no edit here. the cost is
that what `opus` resolves to moves under you — right for a picker, wrong for a reproducible eval.
mythos is deliberately left out: claude-mythos-5 is Project Glasswing only, and a picker entry that 401s
is worse than a missing one. the comment says how to add it.
opusplan is the one entry that is a MODE rather than a model — opus plans, sonnet executes.
NOT derived from the harness, though it could be: Query.supportedModels() returns the real list with
display names and effort levels, but it is a control request and needs a live session, and this endpoint
is what the composer calls before there is one. noted as open in the file.
the test pins the alias set and the property everything else rests on: claude-manager derives what it
hands the SDK with `split('/')[1]`, so a bracketed alias only works while the id has exactly one slash and
the brackets are unencoded. tidying an id into claude-code/opus/1m would fail as the harness quietly
running the wrong model, not as an error.
the selector locked on `hasStarted`, so the tier was fixed for the life of a conversation. nothing
justified it — the commit that added the flag says only "default model" — and the hazard it resembles is
narrower than what it blocked: crossing HARNESS hands an opencode `ses_…` id to `claude --resume`, which
reads as a dead agent rather than a wrong dispatch. changing TIER was always safe.
so tier is free, harness is pinned, and the server refuses a crossing rather than relying on the UI to.
the claude side does it the way the CLI's /model does: `Query.setModel()`, a control request that needs
streaming input mode, which is the only mode this file uses. nothing is torn down and nothing is
re-resumed — cwd, permission mode and transcript all continue and only the next response changes. an
earlier plan here was to kill the session and re-create it with the stored resume id; that would have
worked and was unnecessary.
opencode already switched per turn (serve-runner POSTs the model to the live session), so only the UI was
in its way.
FIXES A SILENT MISMATCH while it is here. model reached the SDK once, in createSession's query() options,
and every later turn was pushed onto that same call — so a changed model was dropped while session:init,
the cost fold and the durable log all reported the new tier. reachable today by leaving a chat idle past
the 30-minute GC: the UI said sonnet, opus answered, nothing logged it. the fold now tracks what the
harness actually did rather than what the client asked for, and a refused switch reverts the picker.
the switch is a durable `model:switched` event and a centred marker in the transcript, because the useful
question is the BOUNDARY — which half of this conversation is opus. per-message model was already stamped
server-side and shown nowhere, and claude-sessions.ts reads the FIRST model in a transcript, so a switch
was invisible in history.
tests: turn-stream proves the marker is durable and lands after the previous model's last words; the
selector tests pull in opposite directions, so unlocking everything fails one and restoring the blanket
lock fails the other. verified by re-breaking both.
not done: opencode's `steer` path (a send mid-turn) returns before the model POST, so a switch there
applies on the next full turn. session.model also stays stale for opencode tier changes — harness routing
is unaffected.
a layout stores appType STRINGS. rename a panel key between versions and every saved layout still names
the old one; normalizeLayout swaps each unknown appType for allowed[0] — whichever panel the plugin lists
first — and WorkspaceView persists the repair.
so renaming headscale-* to offscale-* rewrote the owner's layout into three copies of the server picker
and saved it. ServersView never mounted, there was no register form on the page at all, and it survived a
server restart, a sidecar restart and a plugin reinstall because nothing on disk was wrong. found by
counting elements in a real browser: 3 links, 0 buttons.
install is the only place that knows a plugin's panels may have just changed shape, so that is where the
stale row dies — for every user, since the damage is not per-user and install is owner-only. nothing is
lost: a plugin screen is locked, so the layout is the author's design rather than someone's arrangement,
and useDashboardState re-seeds from defaultLayout on the next load.
does NOT fix the underlying trap: renaming a panel key is still a silent data migration for any screen
that is not a plugin. see TODO.
`platform/themes/<id>/` — untracked, same rule as `plugins/`, only the instructions
tracked. Drop a directory in and the theme appears in the picker on the next page load.
themes/my-theme/theme.css required — `[data-theme='my-theme'] { … }`
themes/my-theme/theme.json required — { name, family, dark }
themes/my-theme/assets/ optional — wallpaper, logo
── Why this is cheaper than installing a plugin ──
A plugin is code: it needs a manifest module, mounting, and a frontend rebuild to reach
the bundler. A theme is a block of CSS custom properties, so it needs none of that. The
server reads the directory at request time and the client adds a `<link>`. No install
step, no rebuild, no restart — which is the whole reason this is eighty lines of
discovery rather than four hundred.
The id is the DIRECTORY NAME, not a manifest field, for the same reason a plugin's
`appName` is not one: an id that can disagree with where its files sit eventually will.
Discovery checks that the CSS actually targets its own directory name, because the
failure is otherwise silent — the theme appears, is selected, and nothing changes.
── Problems are reported, not swallowed ──
A malformed theme returns a reason rather than vanishing:
broken-probe: theme.css does not target [data-theme='broken-probe']
The client logs those, so an author has somewhere to look instead of wondering why
their theme never appeared.
── Boundaries kept ──
The `theme` package still performs no IO. It gained an `extraThemes` prop; Officer
fetches and injects, exactly as it supplies the panel registry to `workspaces`. A
failure to fetch is not an error — no server, no session, no directory all mean "you get
the built-in themes", which is a complete product.
`/api/themes` is a `core` capability: read-only, and not deniable, because an account
that cannot read the theme list renders unstyled. Installing remains a directory on
disk; an upload endpoint would be a way to write arbitrary CSS into the page from a
request.
Verified in-process: listing, the problem report, CSS served as text/css, and a
traversal attempt answered 404.
── Needs a restart ──
Server-side change. Until then the client's fetch 404s and silently keeps the built-ins,
so nothing breaks in the meantime.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`ctrl+shift+h`/`l` are gone. The arrows do that job, and two spellings for one action is
what invited the reasonable guess that `ctrl+shift+j` moved down — which opens the
browser console.
Worth recording that the reported conflict was not one we had: nothing bound
`ctrl+shift+j`. The global letters were `h` and `l` only, and the `j`/`k` keys live
inside the list with NO modifier. But an interface that makes someone guess a wrong key
is the interface's fault, not the guess's.
Inside the list the vim keys stay, unmodified: `j`/`k`/`l`/`h` beside `↓`/`↑`/`→`/`←`.
Nothing there can collide with a browser shortcut, and this is a vim person's
application.
Verified: `ctrl+shift+l` no longer cycles, `ctrl+shift+→` does, and `j` then `l` still
browses inside the list.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Standardised on `ctrl+shift` for all three global bindings, and added arrows everywhere
the vim keys work — `h`/`←`, `l`/`→`, `j`/`↓`, `k`/`↑` are now interchangeable.
ctrl+shift+→ or ctrl+shift+l next theme
ctrl+shift+← or ctrl+shift+h previous theme
ctrl+shift+space the list
── Why ctrl+shift and not the alternatives ──
Checked GNOME's actual defaults rather than reasoning from convention:
<Control><Alt>Left/Right switch workspace
<Control><Shift><Alt>Left/Right move window to workspace
<Super><Alt>Left/Right switch workspace
So ctrl+alt is unusable — those arrows change your workspace, and `ctrl+alt+l` locks the
screen, which is presumably why the original bindings put the letters on ctrl+shift in
the first place. `shift+alt` is free on Linux but is the keyboard-layout switcher on
Windows and `alt+space` opens the window menu.
`ctrl+shift` has no OS binding at all. Its one collision is select-by-word inside a text
field — which is now explicitly protected.
── The guard moved earlier ──
Typing was only checked once the list was OPEN. With arrows on the global cycle that was
no longer enough: `ctrl+shift+←/→` is select-by-word in every text field, and stealing it
mid-sentence to change a colour scheme would be indefensible. The check now runs before
the global cycle too.
Verified against a focused textarea: theme unchanged, and the word selection still
happened. The first run of that test reported a hijack, and the test was wrong — it
clicked a selector that matched nothing, swallowed the failure, and read body-focus as
a text field.
`ctrl+alt+space` still opens the list. It shipped an hour ago and fingers learn faster
than they unlearn.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fourteen themes was too many to keep under an avatar next to "Sign out" — that is where
a preference goes when nobody has decided it matters. It now has its own button in the
header, between the controls and the avatar, grouped by family.
── The keys, ported from the owner's vimazing ──
ctrl+shift+l / ctrl+shift+h cycle forward / back, from anywhere, no UI
ctrl+alt+space open the list
j / k move the focus
l or space apply the focused theme to the app BEHIND the list
h back to where you started
enter keep what you are looking at
escape restore and close
The browse is the point, and it is why the overlay is a portal over a 55% backdrop
rather than a modal: you are not reading names, you are watching the application change.
The theme you started on is captured when the list opens, so `h` and `escape` undo a
whole browse however many previews happened inside it.
Typing is still typing: the list ignores j/k/l/h while focus is in an input, textarea,
select or anything contenteditable.
── Where it lives ──
The key handling is in the theme package — it is behaviour that belongs to themes, and
it needs no UI. The list and the button are Officer's, because a dialog would drag a
component library into a package that currently has none.
Verified by driving the real keyboard in a browser:
start duck-dark · ctrl+shift+l -> plain · ctrl+alt+space -> overlay
j, l -> tokyo-night (previewed) · escape -> plain, closed
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Remote images were broken in the web chat and the failure looked like a network
fault. It was a rewrite. injectImages scans a turn for absolute file paths ending
in an image extension and points them at the file browser — good behaviour, since
an agent that writes /tmp/shot.png should show it rather than make you go and open
it. But 'https://host/images/duck.png' CONTAINS '/images/duck.png', so a perfectly
good markdown image became
scheme stripped, host read as a directory. Every remote image failed.
injectImages now skips regions that are already links — !?[..](..) alongside the
code fences it already skipped — and refuses any match preceded by ':' or '/', or
starting with '//', since those are the tail or the whole of a URL somebody wrote
deliberately. Moved to chat-images.ts with tests, because a regex with three
exceptions is exactly the thing that regresses silently.
Rendering added with it: markdown images now go through ChatImage, capped at
14rem HIGH — not wide, so a wide screenshot and a tall phone capture take
comparable room — and open full size in a dialog on click. A failure names the
alt text and the URL, because the useful question is always which host did not
answer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reported as "the ellipsis doesn't show in the streaming bubble". It was the visible
corner of something much larger: every Tailwind semantic utility was broken under all
eleven ported palettes.
`@theme` mapped `--color-muted-foreground: hsl(var(--muted-foreground))`, which needs an
unwrapped triplet. A ported palette publishes `#6e6a86`, so the mapping produced
`hsl(#6e6a86)` — invalid — and the utility fell back to white or transparent:
duck-dark text-muted-foreground=rgb(148,163,184) bg-muted=rgb(30,41,59)
rose-pine text-muted-foreground=rgb(255,255,255) bg-muted=rgba(0,0,0,0)
The themes looked convincing because panels, the page and the header read their
variables DIRECTLY rather than through a utility class. Everything that went through
Tailwind was quietly wrong, and the thinking dots — `bg-muted-foreground/60` — were
simply invisible.
So: 123 HSL triplets converted to hex across the three hand-written themes, and 37
`hsl(var(--x))` mappings unwrapped. One format everywhere, which is also the format
every published palette ships in.
The triplets only ever existed so `bg-card/50` could get opacity. That was tested
earlier tonight and turned out unnecessary — Tailwind v4 emits
`color-mix(in oklab, var(--card) 50%, transparent)` for any colour format. Having proved
it, I then left the mappings wrapped, which is what broke the palettes.
Verified across six themes: `bg-muted` and `bg-muted-foreground/60` resolve in every one
of them, and Duck's values are unchanged through the conversion — `bg-muted` is
`rgb(30,41,59)` before and after.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reported against a dark theme: the panel header's title, zoom readout and controls were
hardcoded `text-black`, `text-black/60`, `hover:bg-black/10` and `border-black/10`.
Legible on Duck's pale glass, invisible on every palette theme — which is the whole
class of bug the theme work exists to remove, sitting in the one component I moved
between packages and did not re-read.
Three derived tokens, so no theme has to think about them:
--panel-header-fg-dim the header's ink at 60% (the zoom readout)
--panel-header-border the header's ink at 15% (the rule under it)
--panel-control-hover the header's ink at 12% (control hover)
The swap, drop-target and app-picker chrome used `duck-teal` and `text-white` directly.
Those now use `--panel-accent` and a new `--panel-accent-fg`, so a chip on the accent
stays readable whatever the accent is.
Verified across five themes rather than by reading:
duck-dark ink=rgb(248,250,252)
duck-light ink=rgb(2,8,23)
rose-pine ink=rgb(224,222,244)
gruvbox ink=rgb(235,219,178)
catppuccin-latte ink=rgb(76,79,105)
Two comments corrected while there: both asserted the chrome "is black throughout",
which was true when written and is now the opposite of true.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The logo is now stated by each of the fourteen themes rather than supplied by a default
none of them mentions. The base default stays empty, which is the right answer for a
theme written by a stranger — showing nothing beats showing someone else's brand.
Explicit costs one line and buys two things: a theme that ships a brand says so, and a
white-labelled build replaces a line it can see instead of hunting for the default that
was quietly doing the work.
Verified in the browser across four themes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer now ships fourteen themes. Eleven of them were written by other people, ported
unchanged, and none of them knows that panels, docks, glass, grids or scrollbars exist.
── What changed ──
`base.css` derives every surface from the standard tokens: a panel is `card` at 92%, the
header is `card` at 85%, grid lines are `border` faded, scrollbars are `muted-foreground`.
Those defaults sit on `:root`; a theme sits on `[data-theme='x']` and both land on
<html>, so a theme's own declaration simply outranks them. No machinery.
State tones are defaulted too — shadcn's vocabulary has `destructive` and nothing else,
and green-means-good is a convention rather than a palette decision. That is what drops
the required contract from 29 to 20: exactly the tokens every published shadcn palette
already ships.
So there are now three tiers, and an author picks one:
palette 20 tokens Tokyo Night, Gruvbox, Nord — surfaces derived
textured + a few surfaces glass, blur, radius, a wallpaper of its own
white-label + assets its own logo and background
Duck is tier three and is untouched — verified by probe: it still reports
`panel=#ffffff1f`, `blur=24px` and its own grid, because its declarations outrank the
new defaults.
── Verified before committing, not assumed ──
The whole HSL-triplet design existed to make `bg-card/50` work. Tested it: Tailwind v4
emits `color-mix(in oklab, var(--card) 50%, transparent)` for a HEX token, with a
`@supports` fallback. The unwrapped triplets were never necessary, and the ported
palettes are plain hex.
Six themes probed in the browser: each derives panels from its own card colour,
including the light one (Catppuccin Latte).
── Credit ──
The eleven palettes and the idea of a small standard contract come from the owner's
`vimazing` repository, which solved this more simply than we had. What Officer adds is
the surface layer underneath, so a palette gets a textured app for free.
── One open decision ──
`--logo-src` defaults to empty, so a palette theme shows no mark at all. Correct for a
third-party theme; probably wrong for Officer, where the alternative is defaulting to
the officer.dev logo and letting a white-label theme replace it. One line either way.
tsgo clean, suite unchanged, builds.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Merging the workspaces branch replaced `plugins/{example,music,offscale}` — real git
clones — with symlinks pointing at themselves. The build then failed with
`SymLinkLoop`, which is a confusing way to be told your plugins are gone.
My fault, in a way worth writing down. I symlinked the plugins into a git worktree so
it could build against them, then committed with `git add -A`. The links were untracked
rather than ignored, so they went in. On master, checking out a symlink where a
directory stands removes the directory — and since the clone contents were untracked,
git did it without complaint.
Recovered by re-cloning all three from gitea. Nothing was lost that was not already
pushed there; uncommitted work inside those clones would have been, which is the part
that could have been expensive.
`plugins/*` is now gitignored with `!plugins/*.md`, so the convention that plugin
clones are not this repository's content is enforced rather than remembered. A worktree
symlink cannot be committed again.
Verified after recovery: tsgo clean, frontend rebuilds, the live app serves, and
`/api/plugins` answers 200.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two dependency problems, and only one of them was real.
── Real: two majors of the same library ──
The root asked for `react-resizable-panels@^4.0.15` (4.6.5) while
`src/workspaces/components` asked for `^2.1.7` (2.1.9). The workspace code targets 2.x,
whose API differs — v4 has no `PanelGroup` export, no `order` prop and no `ref` on
`Panel` — so a file that resolved the root's copy failed to typecheck in a way that
read like a broken extraction.
Nothing imported the root's version. It was vestigial, and removing it collapses the
repository to one: every importer now resolves 2.1.9 and the lockfile has zero v4
entries.
── Not real: the second React ──
Declaring react/react-dom in the package created
`src/workspaces/workspaces/node_modules/react`, which looks exactly like the
duplicate-instance bug that silently breaks hooks. It is not one. Both locations resolve
to the SAME file in bun's store — the local entry is a symlink — which I established by
resolving the specifier from each place instead of reading directory names, having
already reported it as a hazard on the strength of an `ls`.
Declared as optional peers regardless: that is the right metadata for a consumer, and it
stops bun installing peers it does not need to.
Notes corrected to match, since the wrong version of that story was written down.
tsgo clean, package 114/114, full suite 950 pass / 7 fail unchanged, frontend builds.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Phase 1: the Workspace/Panel system is `src/workspaces/workspaces`, and it no longer
knows Officer exists.
The proof is its test suite. 114 tests mount `WorkspaceView` under a BARE React tree —
no react-query provider, no router, no Officer hook — which is only possible because
the host now supplies everything: a registry mapping `appType` to a component, and a
layout with a way to change it.
Officer is untouched. All 24 `WorkspaceView` sites and 8 `WorkspaceLayout` sites call
exactly what they called before; `Workspace/index.ts` became an adapter that adds back
the three things that are genuinely ours — the app registry, fullscreen persistence in
sessionStorage, and the handshake that stands the nav header down for a fullscreen
panel.
── The shape, and why it is this shape ──
`core/` is the tree and every operation on it: pure, no dependencies, no React. `react/`
is one renderer. That split is phase 2's whole cost saving — a second renderer reuses
`splitPanel`, `movePanel`, `normalizeLayout` and the rest untouched, and what will not
port is the resize INTERACTION rather than the layout engine.
It was already half done: `layout-utils.ts` imported only `./types`, and `WorkspaceView`
already received `{ key, value, setValue, isLoaded }` as a prop and always wrote through
an updater. The real coupling was the registry, fullscreen, and four UI imports.
Also deleted ~175 lines of dead code — `DragOverlay`, `LayoutEditor`, `WorkspaceHeader`
— referenced by nothing.
── Two dependency traps ──
**A second React.** Declaring react/react-dom in the package produced a second copy
under its own node_modules. Two React instances break hooks at runtime and are invisible
until something renders. The package now declares almost nothing while it lives here.
**Two versions of react-resizable-panels.** The root asks ^4.0.15 (4.6.5),
`src/workspaces/components` asks ^2.1.7 (2.1.9), and this code targets 2.x — v4 has no
`PanelGroup`, no `order`, no `ref` on Panel. Inheriting the root resolution produced a
screenful of type errors that read like a broken extraction and were a version
mismatch. Pinned; the duplication itself is worth fixing one day.
── Verified ──
tsgo clean. Package suite 114/114. Full suite 950 pass / 7 fail, unchanged. Frontend
builds, and the running app was screenshotted against the pre-extraction baseline: 9 of
16 byte-identical, the rest live data and the rotating wallpaper. Panel chrome, headers,
splitters and the grid all render as before.
Docs written as part of the work: the package README is the contract, and
WORKSPACES-NOTES.md carries the open items — panel-to-panel channels, the theme
classes the package still assumes, and phase 2.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Every failed frontend build has reported `Bundle failed` and nothing else, for as long
as anyone remembers. The cause is one line that was never there:
`Bun.build` THROWS on failure by default. It throws an `AggregateError` whose own
message is the string "Bundle failed" and whose `errors` array holds the real
diagnostics. So the carefully written `result.success` branch — with its comment about
what a failed build must not do — was unreachable, and the catch dutifully reported
`err.message`.
`throw: false` makes the returned result carry `logs`, which is what the code below it
always assumed. The catch keeps a fallback that unpacks `AggregateError.errors`
anyway: the build should no longer throw, and the failure mode this hides is exactly
the one that has been wasting people's evenings.
Truncation went 500 -> 1000 characters. A single bundler diagnostic with a file, a line
and a code frame routinely exceeds 500, and cutting mid-path leaves it unactionable.
Proven by breaking the app on purpose:
before: Bundle failed
after: ResolveMessage: Could not resolve: "./this-module-does-not-exist"
── The first attempt at that proof was worthless ──
An UNUSED import reported `ok: true`, which briefly looked like a much worse bug —
a broken app building clean. It is not: an unused import is elided by the TypeScript
transform before anything tries to resolve it, so there was no error to report. The
break only becomes a break once the import is used. Worth recording because "I broke it
and the build passed" is an alarming sentence to arrive at by accident.
Also verified that a failed build leaves `build/` alone — the staging swap does what
its comment claims, so a bad build cannot take the running app down with it.
This one shows up in the UI too: the Rebuild button in Settings -> System already
displays `error`, so it stops saying "Rebuild failed" and starts naming the file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Your theme now follows the account instead of living in one browser's localStorage.
Choosing Plain on a laptop reaches the phone.
`appearance.colorMode` is superseded by `appearance.theme`. Along the way this
resolves a mismatch that had been sitting there: the server's default was
`appearance: { theme: 'light' }` while the client read `appearance.colorMode`, so that
default had never once been read by anything. Both sides say `theme` now.
The Light/Dark item is gone from the user menu. Light and dark are two themes, both
already in the list above it, and that toggle was the last writer of the legacy key.
── Two bugs found by testing this, both mine, both silent ──
**A default that looked like a choice.** `useSettings` returns `DEFAULT_SETTINGS`
until the request lands — `settings` is never null, it is a complete valid object. So
"wait for settings" fired on the first render against the defaults, marked itself
done, applied the default theme and never saw the real one. Then the persist side
wrote that default over the account's actual preference. It overwrote the owner's own
`dark` while I was testing it; restored by hand from the `colorMode` it had not yet
destroyed. `useSettings` now exposes `settingsLoaded` so the difference is expressible.
**Defaults masking a migration.** With that fixed, an account holding only
`colorMode: 'dark'` STILL came up light. The client merges `DEFAULT_SETTINGS` over
whatever arrives, so a missing `theme` is filled in with the default before any
consumer sees it — and a default is indistinguishable from a choice. The migration
therefore belongs on the SERVER, which sees the stored object before anything is
merged over it. It is read-only: a GET that rewrites the row on every call is a
surprise, and the client persists on its next change anyway.
Verified by putting the account into the pre-themes shape and asking the new handler
directly, rather than by restarting to find out:
stored: {"colorMode":"dark"} -> returned: {"colorMode":"dark","theme":"duck-dark"}
── Needs a restart ──
The first server-side change in this work. Everything until now was frontend and a
rebuild was enough.
950 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Built and shipped from somewhere else now, so this copy was dead weight that still
carried its own third copy of the palette — `duck-teal` had three different definitions
across three apps, and this was one of them.
Removed: `src/apps/landing`, `scripts/build/landing.ts`, the `build:landing` script,
and the tree entry in CLAUDE.md.
`/landing-page-data` STAYS and is unrelated despite the name — it is the API the
sign-in screen asks whether registration is open. Worth saying because a grep for
"landing" hits both and only one of them was meant.
Nothing imported from the app. tsgo clean, frontend builds, the live app serves.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The cornerstone of the layout was the least themeable thing in it. Measured before
touching anything, which is the only reason this is the right fix:
duck-dark radius=8px bg=rgba(255,255,255,0.12) border=rgba(0,0,0,0.25) blur=24px
plain radius=0px bg=rgba(255,255,255,0.12) border=rgba(0,0,0,0.25) blur=24px
So the RADIUS was already following `--radius` and I had been telling the owner
otherwise — the rounding in the Plain screenshot was something else. What did not
follow anything was the surface: three literal rgba pairs and a fixed `backdrop-blur-xl`
in the component.
Now:
plain radius=0px bg=rgb(255,255,255) border=rgb(0,0,0) blur=0px
Two distinctions the old code drew in literals are kept as tokens rather than
flattened, because both are real and a theme should be able to revisit them.
`--panel-raised-*` is the fullscreen surface: DENSER glass, not darker, because panel
chrome is dark text and a heavy dark fill hid every icon. `--panel-border-bare` is for a
panel with no header, which has nothing else separating it from what it sits on.
`--panel-blur` earns its place beyond theming: a flat theme was paying for a 24px
backdrop blur it did not want, and on a solid panel the compositor does that work for
nothing.
── A near miss worth recording ──
The first attempt silently changed nothing. The patch matched on four spaces of
indentation where the file has two, `str.replace` reported no error, the build
succeeded, and `panel-blur` DID apply — so the class landed while the surface did not.
It looked like a partial success and would have shipped as one. Caught by measuring
computed styles again rather than trusting the edit; the fix now asserts the
replacement changed the file.
950 pass / 7 fail unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The five core apps — FileBrowser, FileViewer, SystemMonitor, Chat, Plugins — now
contain ZERO raw Tailwind palette classes. Every colour in them names a state or a
surface, so all of it follows the theme.
── Busy ──
The 38 ambers were the blocker, and the answer was not to pick between two wrong
mappings. They mean RUNNING — Chat's own comment says "the amber a RUNNING task chip
wears" — and the vocabulary had no word for it. `warning` would have made a working
job look like a failing one, and `--status-in-progress` is blue.
So `tone.ts` has six tones instead of five. It was always written as a closed set that
could grow when a genuine sixth state appeared; this is that.
`--busy-ink` comes with it, and generalises: a fill bright enough to carry black text
is far too light to BE text. The other five tones are dark enough to do both jobs,
which is why the problem had not surfaced. `text-amber-950` — ink ON the fill — became
`text-busy-foreground`, which is what it always was.
── On fidelity, which stopped being the constraint ──
Duck's exact colours were preserved up to this point because an extraction has to be
provably invisible. The owner has since said the palette is not precious: the
wallpaper, the graph-paper grid and the mark are what matter, and everything else can
move. So shades collapse — one busy, one red, one green — rather than being
approximated to keep old pixels.
The verification built for the old constraint keeps its value: it proves the token
layer resolves, which is a different claim from "the colours did not change".
Verified: the utilities compile (`text-busy-ink`, `bg-busy`, `border-busy`,
`text-busy-foreground`) and resolve in the browser.
950 pass / 7 fail unchanged. tsgo clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
82 raw palette classes in FileBrowser, FileViewer, SystemMonitor, Chat and Plugins now
name a state instead of a colour. `docs/design-language-interface.md` has said to do
this for a long time and `tone.ts` implements it; eight files were following it.
Only the families whose semantic token IS the colour already in use:
destructive #ef4444 == text-red-500 exact
success #16a34a == text-green-600 exact
So `red-500` and `green-600` are byte-identical renames, and the neighbouring shades
(`red-400`, `red-600`, `green-500`, `emerald-500`) shift by a little on purpose —
having one red is the point. Verified on screen, not just typechecked.
Three greys became `muted-foreground`, which is what "quieter than the text" means
here.
── Amber is deliberately untouched, and needs a decision ──
38 amber classes remain and a regex must not have them. They are not warnings.
Chat's own comment says it plainly: "the amber a RUNNING task chip wears". It is a
BUSY tone, and the token set has no such thing — `--status-in-progress` exists and is
blue.
Mapping them to `warning` would change both meaning and colour: Duck's `--warning` is
#fbbd23 (amber-400) while the code uses amber-600 #d97706 as text and amber-950 as
ink on a fill. Text at that lightness on white is not readable, and "running" would
start looking like "something is wrong".
Two ways out, both the owner's call: add a sixth tone for busy/queued, or accept
warning's colour and meaning for it.
── Deliberately out of scope ──
The plugin candidates — Soulseek 308, Invoices 95, Wallet 68, Jellyfin 48, Photos 47,
Transmission 41 — are two thirds of the debt and are leaving this repository. Their
colours belong to their extraction, when the rules exist and their imports are being
rewritten anyway.
White and black are also untouched: they are media overlays in the file viewer and
photo surfaces, correct in every theme because they sit on someone's photograph rather
than on a themed surface.
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>
Asked whether these could follow the theme too. They are the three most visible things
on screen and were the three least reachable: `Background.tsx` hardcoded
`url('/landscape1.webp')`, the header carried `rgba(255,255,255,0.25)` and `#1d2724`
in an inline style, and the logo was an `<img src>`.
Between them that is most of what "the app looks like Officer" actually meant. The
Plain theme turned every panel white and all three stayed exactly as they were, which
is how they were found — the leak detector doing its job on its first outing.
Verified across all three themes:
duck-dark wallpaper=landscape1.webp header=rgba(255,255,255,0.25)
duck-light wallpaper=landscape1.webp header=rgba(255,255,255,0.25)
plain wallpaper=none header=rgb(255,255,255)
── Images could not be done the obvious way ──
`--logo-image: url('/officer-logo.svg')` fails the build. Bun's CSS bundler resolves
`url()` at BUILD time and these files are served from `public/` at RUNTIME, so it goes
looking for a module that does not exist. Colours apply themselves; images cannot.
So a theme publishes a quoted PATH — an ordinary string token the bundler ignores —
and `useThemeAsset` reads it and wraps it in `url()`. One hook rather than the read
inline in two components, because the quote-stripping is the kind of detail that gets
forgotten the second time.
The logo is a `<div role="img">` with a background image rather than an `<img>`, since
CSS cannot set a `src` and a white-labelled build has to replace the mark from its
theme rather than by editing the header.
The header's title colour goes through a `.header-ink` class: `EditableTitle` accepts
a className and not a style, and the token stays the source of truth either way.
Panel radius and the ~985 raw palette usages are still outstanding — see
THEMES-NOTES.md.
tsgo clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhas
