[test] Improve the lobby #36

New Issue

2026-05-23T22:04:16Z

owner commented

2026-05-23 22:04:16 +00:00

The lobby could be better — please improve it.

owner added the Kind/Enhancement ready labels 2026-05-23 22:04:16 +00:00

developer was assigned by owner

2026-05-23 22:04:16 +00:00

developer added

claude

working

and removed ready labels 2026-05-23 22:07:29 +00:00

developer commented

2026-05-23 22:09:08 +00:00

@owner — I've claimed this (claude/working) and I'm moving it to claude/blocked pending your steer.

I read the current lobby (ui/frontend/src/lib/screens/lobby-screen.svelte, ui/docs/lobby.md). It's a complete, documented, tested MVP screen: header (greeting, device-session id, logout), a "create new game" entry, and four lists — my games, pending invitations, my applications, and public games (with an inline race-name apply form).

The request ("the lobby could be better — please improve it") has no acceptance criteria, and "improve" spans a wide, mutually-distinct design space. Per the repo's "don't invent requirements" rule I won't guess a direction. Here are the concrete, grounded options I found, each with a trade-off — please pick the direction(s) and a "done" bar, or describe what you have in mind.

Low-risk functional fixes (self-contained, fully testable):

Public-games pagination. The API already returns {page, pageSize, total} (src/api/lobby.ts:127), but the screen requests only the default first page and renders items (≤50), ignoring total — any game past 50 is unreachable. Add a pager / "load more". Trade-off: small and safe; only bites once there are >50 public games.
Manual refresh. The lists load once on mount (refreshAll in onMount, plus a partial refresh after accepting an invite). An approved application, a new invite, or a game that just started only appears after you leave and re-enter the lobby. Add a "Refresh" button. Trade-off: a button is cheap and safe. I'd avoid background auto-polling by default — it's an always-on bandwidth/CPU cost you'd be paying; if you want live updates we should agree an interval + an off switch first.
Localize game status. Application statuses are humanized via i18n (applicationStatusLabel), but game status renders raw snake_case (enrollment_open, ready_to_start, …) on every game card. Add lobby.game_status.* keys (en + ru). Trade-off: pure polish + i18n consistency; touches both locale files.

Visual / UX redesign (subjective):

Restyle the cards, spacing, hierarchy, and empty states against the design system (ui/docs/design-system.md). Trade-off: high subjectivity — without a reference or your taste input this risks churn you don't want; needs a concrete "what good looks like".

If you just want the safe wins, my recommendation is to bundle 1 + 2 (button) + 3 into one PR: all small, low-risk, fully testable, no wire/contract changes. Tell me to proceed with that, pick a subset, or describe the specific improvement you had in mind and I'll continue.

@owner — I've claimed this (`claude/working`) and I'm moving it to `claude/blocked` pending your steer. I read the current lobby (`ui/frontend/src/lib/screens/lobby-screen.svelte`, `ui/docs/lobby.md`). It's a complete, documented, tested MVP screen: header (greeting, device-session id, logout), a "create new game" entry, and four lists — *my games*, *pending invitations*, *my applications*, and *public games* (with an inline race-name apply form). The request ("the lobby could be better — please improve it") has no acceptance criteria, and "improve" spans a wide, mutually-distinct design space. Per the repo's "don't invent requirements" rule I won't guess a direction. Here are the concrete, grounded options I found, each with a trade-off — please pick the direction(s) and a "done" bar, or describe what you have in mind. **Low-risk functional fixes (self-contained, fully testable):** 1. **Public-games pagination.** The API already returns `{page, pageSize, total}` (`src/api/lobby.ts:127`), but the screen requests only the default first page and renders `items` (≤50), ignoring `total` — any game past 50 is unreachable. Add a pager / "load more". *Trade-off: small and safe; only bites once there are >50 public games.* 2. **Manual refresh.** The lists load once on mount (`refreshAll` in `onMount`, plus a partial refresh after accepting an invite). An approved application, a new invite, or a game that just started only appears after you leave and re-enter the lobby. Add a "Refresh" button. *Trade-off: a button is cheap and safe. I'd avoid background auto-polling by default — it's an always-on bandwidth/CPU cost you'd be paying; if you want live updates we should agree an interval + an off switch first.* 3. **Localize game status.** Application statuses are humanized via i18n (`applicationStatusLabel`), but game status renders raw snake_case (`enrollment_open`, `ready_to_start`, …) on every game card. Add `lobby.game_status.*` keys (en + ru). *Trade-off: pure polish + i18n consistency; touches both locale files.* **Visual / UX redesign (subjective):** 4. Restyle the cards, spacing, hierarchy, and empty states against the design system (`ui/docs/design-system.md`). *Trade-off: high subjectivity — without a reference or your taste input this risks churn you don't want; needs a concrete "what good looks like".* If you just want the safe wins, my recommendation is to bundle **1 + 2 (button) + 3** into one PR: all small, low-risk, fully testable, no wire/contract changes. Tell me to proceed with that, pick a subset, or describe the specific improvement you had in mind and I'll continue.

developer commented

2026-05-23 22:09:12 +00:00

Working log (issue-agent) — click to expand

State: blocked
Updated: 2026-05-23T22:08:51Z
Branch / PR: —
Confirmed:

Lobby is a complete, documented, tested MVP screen: ui/frontend/src/lib/screens/lobby-screen.svelte, ui/docs/lobby.md. Sections: create, my games, pending invitations, my applications, public games (inline apply form) + a dev-only synthetic-report loader.
No "improve lobby" item in ui/ROADMAP.md; the finalize pass (PLAN-finalize F1–F7) already shipped.
Concrete, grounded gaps found: (1) public-games pagination unused — API returns {page,pageSize,total} (src/api/lobby.ts:127) but UI renders only the default first page; (2) no manual refresh — refreshAll runs only in onMount (+ partial after accept-invite); (3) game status rendered raw while application status is i18n-localized (lobby.application.status.*).
Open question: Posted to the owner — "improve the lobby" has no acceptance criteria. Which direction(s): pagination / refresh button / localize game status / visual redesign, and what is the "done" bar? Recommended bundling 1+2+3.
Decisions: Will not guess/invent scope on a [test], criteria-free enhancement against an already-complete screen. Default against background polling (owner pays bandwidth/CPU); a manual refresh button is preferred unless the owner sets an interval + off switch.
Next: When the owner replies, branch feature/lobby-improvements off freshly-fetched origin/development, implement the chosen subset with tests + docs (ui/docs/lobby.md, i18n en/ru, and docs/FUNCTIONAL.md + FUNCTIONAL_ru.md mirror only if user-visible behaviour changes), push to gitea, open a PR into development, watch CI to green, then set claude/in-review.

<details> <summary>Working log (issue-agent) — click to expand</summary> **State:** blocked **Updated:** 2026-05-23T22:08:51Z **Branch / PR:** — **Confirmed:** - Lobby is a complete, documented, tested MVP screen: `ui/frontend/src/lib/screens/lobby-screen.svelte`, `ui/docs/lobby.md`. Sections: create, my games, pending invitations, my applications, public games (inline apply form) + a dev-only synthetic-report loader. - No "improve lobby" item in `ui/ROADMAP.md`; the finalize pass (PLAN-finalize F1–F7) already shipped. - Concrete, grounded gaps found: (1) public-games pagination unused — API returns `{page,pageSize,total}` (`src/api/lobby.ts:127`) but UI renders only the default first page; (2) no manual refresh — `refreshAll` runs only in `onMount` (+ partial after accept-invite); (3) game status rendered raw while application status is i18n-localized (`lobby.application.status.*`). **Open question:** Posted to the owner — "improve the lobby" has no acceptance criteria. Which direction(s): pagination / refresh button / localize game status / visual redesign, and what is the "done" bar? Recommended bundling 1+2+3. **Decisions:** Will not guess/invent scope on a `[test]`, criteria-free enhancement against an already-complete screen. Default against background polling (owner pays bandwidth/CPU); a manual refresh button is preferred unless the owner sets an interval + off switch. **Next:** When the owner replies, branch `feature/lobby-improvements` off freshly-fetched `origin/development`, implement the chosen subset with tests + docs (`ui/docs/lobby.md`, i18n en/ru, and `docs/FUNCTIONAL.md` + `FUNCTIONAL_ru.md` mirror only if user-visible behaviour changes), push to `gitea`, open a PR into `development`, watch CI to green, then set `claude/in-review`. </details>

developer added

and removed

labels 2026-05-23 22:09:12 +00:00

owner closed this issue

2026-05-24 00:03:33 +00:00

developer added

claude

skipped