feat: New UI

[disconsented]

I've been faffing with Claude design because I've found the UI hideous and I can't design things to save my life.

[disconsented]

[disconsented]

[disconsented]

[disconsented]

High — every app's tag list goes empty on deploy, and long-tail tags never come back.

migrations/1789088642905_hide_tags.surql sets known_members = 0 on every existing tag, and all three queries here now drop anything at or below 100. Immediately after the migration /api/app/:id returns tags: [], so the tag chips in search.svelte disappear and +page.ts can no longer resolve default_tags (they are matched against app.v.tags).

Counts only return when TagsActor sees a tag it does not already have cached, which only happens when ItemUpdateActor upserts an item carrying it — and steam_download_actor only pulls items updated in the last 12 h. A declared-but-quiet tag (Scenario, Translation, an older version tag) may hold thousands of items and still sit at known_members = 0 indefinitely, permanently invisible.

A backfill pass at startup (enumerate tags where known_members = 0 and queue UpdateCount) would close the gap. The threshold is also hard-coded in three places.

[disconsented]

Medium — a failed Steam call leaves known_members at 0 forever.

The response status is never checked. A 429, a 403 on a bad key, or a 5xx returns an HTML or JSON error body, .json::<SteamRoot<GetTagCountResponse>>() fails, the error is logged and the message is dropped. There is no retry, and the tag is not re-queued until the 24 h Clear happens to coincide with an item that carries it.

Combined with apps_repository's known_members > 100 filter, one transient rate-limit during a crawl burst hides that tag from the UI for at least a day. Add .error_for_status() and requeue UpdateCount (with backoff) on failure.

[disconsented]

Medium — this runs a write transaction for every item, which is what the doc comment says it avoids.

The type doc claims a deliberate trade-off to "sometimes upsert redundantly instead of adding an extra query for every item", but update_tags is called unconditionally, including when new_tags is empty — which is the common case once the cache is warm. upsert_tags then opens BEGIN/UPDATE apps:<id> SET tags = tags.union([])/COMMIT, so a full crawl issues one transaction per item, all serialised on the same apps record.

Suggested change

	if let Err(error) = state.service.update_tags(appid.clone(), new_tags).await {
	if !new_tags.is_empty()
	&& let Err(error) = state.service.update_tags(appid.clone(), new_tags).await
	{
	error!(?error, ?appid, "Failed to update tags");
	}

Separately, each new tag also blocks this actor on a synchronous Steam round trip via UpdateCount, so AddTagToApp messages queue behind HTTP latency during ingestion.

[disconsented]

Medium — query_type is fed a value from the wrong enum.

query_type takes an EPublishedFileQueryType; EPublishedFileInfoMatchingFileType is what the separate filetype parameter takes. MatchingFileType_Items is 0, which lands on EPublishedFileQueryType::RankedByVote — and TagsActor's own doc comment says to use query_type=1. RankedByVote is the one query type Steam windows by days, so the total you read back can be a subset rather than the tag's real item count, which then feeds the known_members > 100 cut in apps_repository.

Suggested change

	"query_type",
	"query_type",
	&(EPublishedFileQueryType::RankedByPublicationDate as i64).to_string(),

[disconsented]

Medium — swapping CONTAINS for @@ drops partial-word title search, and fails silently without the index.

Verified against surreal 3.2 with the analyzer and index from the two new migrations: title @@ 'Van' returns nothing for 'Vanilla Expanded Framework' — @@ matches whole analyzer tokens, so the search box no longer does prefix or substring matching. Typing into it now returns nothing until a complete word is entered. It also became OR-across-terms rather than a single substring.

Worse, on a database where 1789087854843_title_full_text_index.surql has not run, @@ does not error — it just returns zero rows for every query, so title search looks like "no results" rather than a broken deployment.

If prefix matching is wanted, an ngram/edgengram filter on title_analyzer restores it.

[disconsented]

High — unguarded item.author crashes the whole item page, and /id/ is the wrong profile path.

FullWorkshopItem.author is Option<ExternalUsername> with no skip_serializing_if, so the API sends "author": null whenever the usernames record has not been resolved yet. item.author.id then throws and, because this is rendered inside the {:then} of +page.svelte, the entire item page renders blank. The page this replaced guarded it: {#if item.author}.

Second issue on the same line: UsernameID is an i64 SteamID64 (define_id!("usernames", IUsernameID, UsernameID, i64)), and steamcommunity.com/id/<steamid64> is the vanity URL path — it 404s. The removed titleCard used /profiles/.

Wrap the author block in {#if item.author} and use /profiles/.

[disconsented]

Medium — same null-author crash on dependency cards.

Dependencies and dependants are ExternalFullWorkshopItem, whose author is Option<ExternalUsername> serialised as null. One dependency with an unresolved author throws here and takes the whole tab down.

Suggested change

	>{item.author.name}</span
	>{item.author?.name ?? 'Unknown'}</span

[disconsented]

Medium — wrong Steam profile path.

item.author.id is a SteamID64 (define_id!("usernames", IUsernameID, UsernameID, i64)). steamcommunity.com/id/<n> looks up a vanity URL and 404s for a numeric id; the numeric form needs /profiles/. Every author link in table view is dead.

Suggested change

	href="https://steamcommunity.com/id/{item.author.id}"
	href="https://steamcommunity.com/profiles/{item.author.id}"

(itemCard.svelte:59 carries the same pre-existing bug.)

[disconsented]

Medium — the page reset on filter change was lost in the split.

The old +page.svelte had $effect(() => { selectedTags; selectedLangs; page = 1; }); it did not survive the move into this component. Now: open an item with 40 dependants, page to 3, then tick a tag in the filter. filtered drops to 8 entries, page is still 3, and filtered.slice(30, 45) renders an empty grid with no obvious way back other than clicking page 1.

Suggested change

	let page = $state(1);
	let page = $state(1);
	$effect(() => {
	selectedTags;
	selectedLangs;
	page = 1;
	});

[disconsented]

Medium — page is never reset after a search.

search.svelte navigates with goto('?' + params), which reruns load but keeps this component instance, so page survives. Page to 6 of a 200-result set, then add a tag that narrows it to 12: count becomes 12 but page stays 6, slicedSource returns value.slice(75, 90), and the grid renders empty while the header reads "12 results".

Reset it when the result set changes, e.g. $effect(() => { data.searchRequest; page = 1; }), or clamp page against Math.ceil(value.length / pageSize).

[disconsented]

Medium — the URL does not round-trip an empty tag selection.

loadParams sets tags.v = [] when the URL carries no tags, and then this branch puts the app's default_tags back. Within one session firstRun is already false so it does not bite — but deselect every tag, copy the resulting URL (which correctly has no tags param), and open it in a new tab: firstRun is true again, the defaults are silently reapplied, and the chips in search.svelte show as selected while the URL says otherwise. Same on a plain refresh.

Distinguish "no tags param" from "tags explicitly empty" — e.g. have search.svelte emit a sentinel, or only apply defaults when the URL has no search params at all.

[disconsented]

Low — renders "[object Object]".

Here tag is { id, display_name } (from all_tags), not a string. The equivalent block in search.svelte interpolates a plain string tag, which is where this was copied from. Every tag tooltip in the filter shows "[object Object]".

Suggested change

	<span>"{tag}"</span>
	<span>"{tag.display_name}"</span>

[disconsented]

Low — {@debug} ships a debugger statement to production.

Svelte compiles {@debug x} to console.log(x); debugger; unconditionally — it is not dev-gated (svelte/src/compiler/phases/3-transform/client/visitors/DebugTag.js). This component renders once per item card, so with devtools open the browser breaks on every card in the grid and on the item page.

PropertyPrompt.svelte:59 has the same {@debug value}; Body.svelte has a leftover $inspect, and +page.svelte (both routes) console.log(data).

Suggested change

{@debug first_props}

[disconsented]

Low — the placeholder chart ships ~5,200 lines of AAPL prices to every item page.

PopularityChart.svelte is a static 2007 Apple stock series in module scope, and its tooltip formats the values with format(data.value, 'currency') — so the "Popularity" panel shows dollar amounts from 2007 on every item, and the whole array is bundled into the item route chunk.

"(Placeholder)" in the label helps, but it is still fabricated data presented as a chart. Worth gating behind a flag, or dropping the series and rendering an empty state until the real data exists.

[disconsented]

Low — "Show All" freezes pageSize at the count it had when clicked.

pageSize is set to value.length at selection time, not tracked. Pick "Show All" on a 12-result search, then broaden the filter to 300 results: the select still reads "Show All" but only the first 12 render. When value.length is 0 it also sets pageSize = 0, and when it happens to equal 5/10/15/30 you get a duplicate <option> value.

Use a sentinel (value={-1}) and resolve it at slice time instead.