The theme handoff encoded as CSS custom properties rather than a Tailwind
config, since there is no Tailwind here. Palette, spacing, radii, shadows and
motion follow it as written; docs/theme.md lists what differs and why.
- Oswald vendored as a 21KB variable woff2, latin subset, no CDN. Its phantom
weight 900 resolved to 700 — loading a weight you don't have is what made
the brand render differently per platform
- color-scheme: dark makes the native audio element fit the palette, which
was the handoff's complaint about it
- Songs are text cards rather than artwork tiles, because there is no
artwork. The unreviewed state keeps its red-brown border and gains a badge,
so it is never carried by colour alone
- Nav is the three-column grid; the mobile menu is <details>, no JS
- Flash messages became bottom-right toasts
Favicon carried over from the Nuxt project.
Steps 3 and 4 of the build order. A member can now upload a song, watch it
convert, publish it, and review what everyone else has published.
Pipeline:
- ffprobe reads tags synchronously at submit so prefill never races typing;
ffmpeg converts to Opus in the background, two at a time
- ffmpeg succeeding is the validation — no container sniffing
- publish moves the file inside the transaction, so a song row and its .ogg
appear together or neither does
- five submissions per rolling 24h, failures excluded
Reviews and the reveal rule:
- the queue is unreviewed songs only, oldest first, never your own
- other people's reviews and the average are withheld in the query, not the
template — a hidden average is never sent
- 30 minutes to edit or delete your own review, enforced in the WHERE clause
- deleting the last review unlocks the song for its submitter again
The waiting page has one button: the metadata form autosaves after a pause in
typing, and Julkaise submits it and publishes in the same request, so nothing
is lost without JS.
Genres store an English code and render a Finnish label.
Step 2 of the build order. The admin mints an invite link, the recipient
registers with it, and from then on has a session.
- The invite is spent in the same transaction that creates the account, so a
failed signup leaves the code usable
- Sessions are idle timeouts, 24h or 30 days with remember me, read from a
cookie or a bearer header, extended at most once a minute
- Ban is a reversible toggle that drops the member's live sessions
- No password minimum; login is rate limited instead, 10 failures per email
in 15 minutes, cleared by a correct password
- Invite codes render as links carrying ?code=, which the register form
prefills; PUBLIC_URL makes them pasteable from the loopback admin panel
Tests cover invite spending, the idle timeout, ban, and the rate limiter.
Esa Kataja