An audit of the README and the site against the implementation found 38 places the docs were missing, stale, or wrong about daemon mode. Two were outright false: the community page still answered "want a queue that outlives the command?" with "slskd has that", and the home page promised "no daemon, no API to stand up" fifty lines before the section that describes both. The download-box walkthrough now tells the truth about its sharp edges: a pushed folder or share list is live-only on a remote daemon, whose own config.toml wins at restart; `shares add` validates the path on the machine you type it on; and a `get` that reaches its `--timeout` cancels the daemon-side transfer. Its shell example also runs as written now — the old block put a second command after a foreground daemon that never returns. The reference material catches up with the feature: `daemon` and its subcommands join the command list, the config table gains the daemon/daemon_token/--no-daemon rows, nine settings become eleven, `daemon status` and `daemon token` get documented record shapes, exit 3 covers daemons, `queued` joins the serve statuses, the credential-free count goes 13 to 19, and the action-command count 4 to 6. And the surprises are written down rather than discovered: the daemon does not sweep the wishlist on its own; Windows has no socket and so no auto-attach; the attached TUI's settings form edits the daemon's folders and rewrites this machine's config.toml; `serve` monitors a daemon's uploads instead of starting a second server; `whoami` reports the daemon's world, with --no-daemon as the way out. The OpenRPC section names the six event methods and the session-wide download.set_dir rule. Site typechecks, lints, and builds through prerender; every claim was verified against the cited code before it was written.
website
The soulseek-rs project site. Vite + React + TypeScript + Tailwind v4,
deployed to GitHub Pages by .github/workflows/pages.yml.
bun install
bun run dev # http://localhost:5173/soulseek-rs/
bun run build # client build, SSR build, then prerender
bun run typecheck
bun run lint
How the static site is produced
bun run build runs three steps:
vite build— the client bundle, plusdist/index.htmlas the template.vite build --ssr src/entry-server.tsx— the same app compiled for Node.bun scripts/prerender.ts— renders every route insrc/lib/routes.tsto its own file (dist/install/index.html, and so on) with that route's title and description substituted in, plus a404.html.
Without step 3 GitHub Pages has no file at /install and answers a direct link
with a 404. With it, every URL returns 200 with fully rendered markup, and the
client hydrates that markup rather than replacing it.
Adding a page means: a component in src/pages/, a <Route> in src/App.tsx,
and an entry in src/lib/routes.ts. The last one is what the prerenderer walks.
Design system
Tokens live in src/index.css, ported from the Claude Design project's
tokens/colors.css. They are the same values that back the TUI in
soulseek-rs/src/ui/styles.rs — change one, change both.
Dark is the native theme; light re-cuts the semantic hues roughly 10% darker,
because phosphor and tape are legible on vinyl but wash out on manila. Theme
selection is [data-theme] on <html>, defaulting to the OS setting, with an
inline script in index.html applying it before first paint so the page never
flashes the wrong background.
Notes
baseinvite.config.tsis/soulseek-rs/because this is a project site. Pointing a custom domain at it means setting that to/(the router readsimport.meta.env.BASE_URL, so it follows automatically).- Copy in
src/pages/follows the project's tone of voice: plainspoken, precise, honest about limits first. No copyrighted artist or album names anywhere, including the TUI demo data insrc/components/tui/data.ts.