The Kubernetes deployment runs the split go-guess-web image, which is a plain
nginx serving static files and never ran an entrypoint. The theme service origin
is therefore never written into runtime-config.js there, so the page would always
read the empty default and theming would be silently inert in the cluster while
working in local runs. The combined root image already did this; the split one
now does too.
The script lives beside the frontend Dockerfile because that image's build
context is ./frontend, which cannot see docker/.
The chart passes THEME_BASE_URL to the web container rather than the API: it is
read by the browser, not by the service. It stays absent when unset, so a
deployment with no theme service renders exactly as before.
The theme selector and the appearance toggle are the custom elements
go-bananas ships, loaded at run time. They are custom elements rather than
components written here because the applications this service feeds are a mix of
React, vanilla JavaScript and server-rendered HTML, and a custom element is the
one shape all three can use with no build step, no import map, and no second copy
of React to break the hooks.
Every token in the stylesheet is now written as var(--bn-*, fallback). That
ordering is the safety property: with no theme service configured the page renders
exactly as it did before, and with one configured the same rules follow the
palette. The navigation rail takes the contract's sunken surface and its paired
foreground rather than a fixed dark navy, because a light appearance wants dark
text there.
THEME_BASE_URL is read from runtime-config.js, which the entrypoint rewrites from
the environment on start, so one image serves every environment rather than
baking a hostname into the bundle at build time.
contract.test.ts fetches the live contract and asserts it defines every --bn-*
variable this application consumes. A token renamed on the service would
otherwise leave every var() resolving to its fallback, and the page would look
correct while never actually following the palette. Verified it fails on a
deliberately wrong token name.
The image also had two USER lines, the second silently replacing the first with a
uid that owns neither /app nor /tmp/nginx. nginx could not create its pid file or
its temp paths, so the container failed to start. Confirmed by building both
variants: the old one cannot write nginx's temp directory, the fixed one serves
the front end, its hashed assets, and the /api proxy.
Signing in now starts at the sign-in screen and one button that hands the
browser to Go Loose, which returns to the welcome page. Nothing redirects to the
identity provider on its own any more: that fired on every anonymous visit and
read as a redirect loop rather than as a choice to sign in. The password form
remains only where the API reports that Go Loose login is not configured for the
host, because otherwise the application is unreachable on a bare localhost.
A person's picture is carried through from the Go Loose identity and rendered in
the account menu and on the profile page, with their initials as the fallback.
Two things make that fallback necessary rather than decorative: Go Loose retires a
picture key when a picture is replaced, so a link cached in a browser can be dead,
and most people have not uploaded one. The URL is deliberately not persisted
locally, since a stored key would keep failing after the picture changed.
The account menu is a disclosure rather than a hover menu: a real button with
aria-expanded, Escape and outside clicks closing it, and focus returning to the
trigger. It is not an ARIA menu, because its actions are a link and a button and
menuitem roles would strip the link semantics from one of them for no gain.
The account URL of the Go Loose identity is resolved on each sign-in and is read
from the live identity provider every time, which is also what makes it correct
after a picture change.
Depends on the Go Loose revision that serves avatar_url through
/connect/userinfo, so the picture URL reaches this application at all.
