note that theme asset packaging is deferred, not solved

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>
This commit is contained in:
2026-08-16 22:57:00 +00:00
co-authored by Claude Opus 5
parent e9cb244818
commit a0013e4f28
+8 -1
View File
@@ -97,7 +97,14 @@ Left alone.
**5. `rebuildFrontend()` reports `"Bundle failed"` and discards the bundler's actual errors.** Cost twenty
minutes tonight. Same shape as the agent bugs from earlier — a failure that refuses to say why.
**6. Landing and marketplace are untouched.** They have their own copies of the palette; `duck-teal` has
**6. Theme ASSETS have no packaging story yet — deferred deliberately.** A theme publishes an asset as a
quoted path (`--logo-src: '/officer-logo.svg'`) and `useThemeAsset` wraps it, because Bun's CSS bundler
resolves `url()` at build time while these files are served from `public/` at runtime. That works for
themes we ship. It does not answer where a THIRD PARTY's wallpaper and logo live. The owner's intent is a
convention under `public/` — something like `public/themes/<name>/` — so an author drops files in a known
structure and references them by path. Not designed yet; the token shape above already fits it.
**7. Landing and marketplace are untouched.** They have their own copies of the palette; `duck-teal` has
three different definitions across the three apps. Folding them into this layer is a natural follow-up and
was not in tonight's scope.