[iiamlewis]

Resolves #5725

Description:

The client half of player levels: a level badge across the UI, and the XP each game earns revealed on the end-of-game screen. The API half (XP ingest, /users/@me progress, GET /users/@me/xp/:gameId) is being built in the infra repo. Until it is switched on, this renders nothing: every view checks that the API returned progress first.

Level badge

• Shape: a badge for every level, drawn in SVG, with a shape per band of ten levels.
• Prestige: the emblem grows with prestige: ring, double ring, sunburst, then radiant at P10. Rank gems and a "P#" tab show the prestige number.
• Legend: P10 level 100 gets a crown.
• Where it shows: the account menu (with an XP bar), player profiles and the game stats modal.

End-of-game XP reveal (WinModal)

• States: the panel shows "sign in to earn XP", "calculating…" (it polls until the game is scored), an ineligible reason (not spawned, too short and so on) or the result.
• Sources: the result is revealed a source at a time. A caption rolls in over a segmented bar ("TIME PLAYED +200 XP"), the bar climbs, a counter counts up, and that source's card lands below.
• Levels: the bar runs from the current level (left) to the next (right).
  • Level-up: each level-up pauses: the bar flashes, "LEVEL 23!" slams in, and the next-level badge pops with a burst before both badges move on.
  • Milestones: milestones (10, 25, 50, 75) get their own card, which slides in when reached. An ordinary level-up gets no card.
  • Legend: becoming a Legend is its own longer moment.
• Bonuses: each multiplier wipes across the cards, turning each value over to its multiplied share. The cards always add up to the award. The multiplier then lands as a line under the counter, Overwatch style: "+100% XP (SOVEREIGN BONUS)".
  • Tiers: subscription tiers show in their Discord role colours: Sovereign gold (+100%, 2x), Warlord cyan (+50%) and Vanguard green (+25%). These match the tier values infra seeds (openfrontio/infra#895).
  • How the tier is known: the client recognises the tier from the multiplier the API sends (SUBSCRIBER_TIERS in Progression.ts). The infra PR seeds those values.
  • Other values: any other boost shows as a plain "Subscriber bonus", and a cut shows in blue.
• Layout: nothing moves or resizes while the numbers change. Anything that might not appear (a milestone, a bonus) takes no space until it does, so the layout never gives it away.
• Skip and accessibility: tapping skips to the end, and reduced motion shows the final state straight away.
• Buttons: the modal's buttons get the store's texture and a hover (lift, glow and a light sweep). Exit Game is on the left and Keep Playing on the right. The XP panel doesn't change the promo box under it.

Media

1. Level-up (22 → 23) with a Sovereign subscriber bonus. Played over a real local game. A caption per source, the bar climbing, the level-up pause, then the +50% bonus wiping across the cards in gold. The panel starts tight: no card for an ordinary level-up.

xp-reveal-sovereign.webm

2. Milestone (24 → 25) with a Vanguard bonus, and the buttons. The milestone card slides in when the bar reaches 25. At the end the mouse hovers Exit Game, Keep Playing and Exit again (the cursor itself does not show in the recording).

milestone-vanguard-bonus-buttons.webm

3. Becoming a Legend (P10, 99 → 100).

legend.webm

The three tier bonuses, each in its Discord role colours. The screenshots below show the earlier 1.5x / 1.3x / 1.2x values; the tiers are now +100% / +50% / +25%:

The XP numbers are sample results fed to the modal; the API that computes them is not deployed yet.

Testing

• New tests cover:
  • the badge (every band and prestige tier);
  • the progression helpers, including splitting a multiplied award across cards and recognising tiers;
  • the API schemas;
  • the account menu, the profile and stats modals, and the rewards panel;
  • the reveal: order, level-up pauses, the milestone and Legend cards, bonuses and tiers, skipping, and the button order and actions.
• Full suite: 7,070 passed.
  • The only failures are the two UpdateRegister tests, which shell out to update.sh and fail the same way on Windows without this change.
• Checks: tsc, oxlint, eslint and prettier are clean.

Added: XP on past games

Opening one of your own past games from your account or profile now shows what that game earned, in a card under the game summary. It replaces the compact XP panel this PR first added to the stats popup.

• What it shows:
  • the total;
  • "Level 46 → 47" with badges when the game caused a level-up, or your level and progress when it didn't;
  • a "Milestone" chip and a glow at 10, 25, 50, 75 and 100;
  • the sources, in three columns that become one on phones;
  • the subscriber boost on its own line.
• Boost amounts: with only the subscriber boost, its line shows the exact amount, so the lines add up to the total. When a game-type multiplier also applies, the API rounds the two together, so the split can't be known. Each line then shows its percentage without an amount, rather than a number that might be wrong.
• Other states:
  • "Calculating XP…" with a spinner;
  • didn't earn XP, using the existing reason lines;
  • played before levels existed, from the new before_progression reason (openfrontio/infra#909).
• When it shows:
  • The lookup only ever returns the signed-in player's own record, so any answer is shown, including ineligible ones.
  • A "not found" answer shows "Calculating" and keeps checking only for your own game (from your account history, or your own profile) that ended in the last 10 minutes. Otherwise it shows nothing.
  • Signed out: nothing.
• Code:
  • PastGameXpCard.ts is new.
  • GameInfoView gains a slot under the summary card and an event carrying the loaded game.
  • The XP labels and the bonus-line text are shared with the reveal.
  • The reveal's unused compact mode is removed.
• New en.json keys: progression.level_change, milestone_chip, xp_before_levels, xp_plus, xp_minus.

Screenshots from this branch at 2x. The XP results are sample data given to the card.

A level-up, and a milestone:

No level-up, Calculating, didn't earn XP, and played before levels existed:

Phone:

Fixed: the reveal's counter and level progress on phones

At 390px wide, "+1,150 XP" ran into "444 / 2,41…" under the bar. When the bar's column is narrower than 16rem, the two now stack, centred. Their heights are fixed, so nothing moves during the reveal. Desktop is unchanged.

Before and after, at 390px:

Testing for these additions:

• PastGameXpCard.test.ts: every state, base values, the boost amount, a lone cut, both multipliers giving no amounts, the milestone chip, before_progression, and left-early.
• ProgressionModals.test.ts: the rules for when a "not found" answer shows Calculating.
• All 3,421 client tests pass. tsc and lint are clean.

Please complete the following:

• I have added screenshots for all UI updates
• I process any text displayed to the user through translateText() and I've added it to the en.json file
• I have added relevant tests to the test directory

Please put your Discord username so you can be contacted if a bug or regression is found:

Iamlewis

🤖 Generated with Claude Code

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 71822181-ff61-4f5b-9efe-e25e0182bdd2

📥 Commits

Reviewing files that changed from the base of the PR and between 23be312 and b899cb0.

📒 Files selected for processing (16)

• resources/lang/en.json
• src/client/LangSelector.ts
• src/client/PlayerProfileModal.ts
• src/client/Progression.ts
• src/client/ProgressionApi.ts
• src/client/components/GameXpPanel.ts
• src/client/components/NavAccountMenu.ts
• src/client/components/XpBar.ts
• src/client/hud/layers/WinModal.ts
• src/core/ApiSchemas.ts
• tests/client/LevelBadge.test.ts
• tests/client/NavAccountMenuLevel.test.ts
• tests/client/ProgressionApi.test.ts
• tests/client/ProgressionModals.test.ts
• tests/client/ProgressionSchemas.test.ts
• tests/client/graphics/layers/WinModalXp.test.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• resources/lang/en.json

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.

---

Walkthrough

The client adds progression schemas and API helpers, level and XP components, and progression displays in account, profile, game-stats, and end-of-game views. It also adds English translations and tests for progression data and display behavior.

Changes

Player progression and game XP

Layer / File(s)	Summary
Progression data and display rules src/core/ApiSchemas.ts, src/client/Progression.ts, resources/lang/en.json, tests/client/ProgressionSchemas.test.ts, tests/client/LevelBadge.test.ts	Adds progression and game XP schemas, level and XP helpers, English translations, and tests for schema parsing and helper results.
Progression API access src/client/ProgressionAccount.ts, src/client/ProgressionApi.ts, tests/client/ProgressionApi.test.ts	Adds account-state resolution, game XP fetching and polling, public-player progress fetching, and cached progression configuration fetching.
Shared level views src/client/components/LevelBadge.ts, src/client/components/XpBar.ts, src/client/components/NavAccountMenu.ts, src/client/PlayerProfileModal.ts, src/client/LangSelector.ts, tests/client/NavAccountMenuLevel.test.ts, tests/client/ProgressionModals.test.ts	Adds level badges and XP progress to account and profile views. The navigation menu refreshes after translations are applied.
Game XP result panel src/client/components/GameXpPanel.ts, resources/lang/en.json, tests/client/graphics/layers/WinModalXp.test.ts	Adds status and result views for game XP. Eligible results can show an animated, skippable reveal or a compact summary.
Game modal XP integration and reward labels src/client/GameStatsModal.ts, src/client/hud/layers/WinModal.ts, src/client/components/RewardsPanel.ts, tests/client/ProgressionModals.test.ts, tests/client/graphics/layers/WinModalTick.test.ts, tests/client/graphics/layers/WinModalXp.test.ts, tests/client/RewardsPanel.test.ts	Connects the XP panel to game-stats and end-of-game flows. Recognized progression reward reasons use translated labels. The modals check progression availability and handle pending results, stale lookups, and request cancellation.

Priority: ➖ Normal

Estimated code review effort: 4 (Complex) | ~60 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant WinModal
  participant ProgressionAccount
  participant ProgressionApi
  participant GameXpService
  participant GameXpPanel
  WinModal->>ProgressionAccount: resolveXpAccount()
  WinModal->>ProgressionApi: fetchProgressionConfig() and pollGameXp(gameId)
  ProgressionApi->>GameXpService: request game XP
  GameXpService-->>ProgressionApi: return XP response
  ProgressionApi-->>WinModal: return result or null
  WinModal->>GameXpPanel: set XP view state

Loading

Suggested reviewers: celant

Merge Risk: ⚪ Minimal · up to b899c

The two reported issues do not block merging: XP bars receive valid percentages, and transient XP request failures are retried during polling.

Security Architecture Review

Security architecture risk: 🔵 Low · up to b899c

The feature displays server-calculated XP without granting new gameplay authority. Account-specific XP can outlive a background session change within the same page, although normal logout reloads the page and limits exposure. Server-side ownership enforcement remains unverified.

Retained concerns

• Low · security · inferred: The new account-owned XP views are not invalidated by background session changes. WinModal can apply an earlier session's asynchronous result without rechecking ownership, while GameStatsModal checks only modal generation and game identity. Already displayed results can also remain after session cleanup. This creates a limited stale-account display or attribution risk within a still-mounted page; normal logout reload and component teardown substantially constrain exposure.

Security review details

Security Blast Radius

• inferred — The supported concern is limited to account-specific XP retained or assigned within one still-mounted browser document after a background session transition. It does not establish remote access to another account, credential theft, gameplay authority, or modification of stored XP. Normal logout reloads the document.

Security Findings and Attack Paths

• inferred — A request can begin under account A, followed by background session cleanup or replacement while the view remains mounted. Its eventual successful result can still be assigned without checking that A owns the current session; an existing result is also not cleared by the inspected session event path. This is an inferred stale-data path, not a verified server authorization finding.

Trust Boundaries and Controls

• observed — Caller-supplied game identifiers are encoded into a fixed /users/@me/xp route and sent with the existing Bearer header. Client sign-in and progression checks restrict presentation but cannot enforce record ownership: GameStatsModal can open another player's game. The server must select XP using the authenticated subject and requested game; its implementation is outside the supplied repository evidence.

Resilience and Maintainability Implications

• observed — Unauthorized responses terminate polling, WinModal disconnection aborts its poll, and GameStatsModal closure invalidates pending display work. The existing authentication layer provides a session-subject check, but the new XP result paths do not use it. Presentation cleanup therefore has stronger generation controls than account ownership cleanup.

Hardening Proposals

• proposed — Bind account-specific XP requests and retained views to an explicit session generation or authenticated owner. Clear those views and cancel pending work on session changes, and reject stale completions even when the component remains mounted.

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Out of Scope Changes check	⚠️ Warning	WinModal.ts replaces the existing o-button controls with a new actionButton implementation and extensive custom gradient, hover, focus, active, and motion CSS. The XP panel changes in the same f…	Remove the unrelated button replacement and custom button styling, or link that work to a separate issue.
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 54 functions across 21 files. (1 skipped:…	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Issue #5725 coding requirements are met. LevelBadge and XpBar support the account menu, profiles, and game stats. GameXpPanel covers signed-out, calculating, ineligible, hidden, and result state…
Title check	✅ Passed	The title clearly summarizes the main changes: showing player levels and game-earned XP.
Description check	✅ Passed	The description covers the progression UI, end-of-game XP reveal, past-game XP card, and related tests. It is directly related to the changeset.

Full details: Out of Scope Changes check

Explanation

WinModal.ts replaces the existing o-button controls with a new actionButton implementation and extensive custom gradient, hover, focus, active, and motion CSS. The XP panel changes in the same file support issue #5725, but the button replacement has no demonstrated connection to that issue.

Full details: Docstring Coverage

Explanation

Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 54 functions across 21 files. (1 skipped: 1 unsupported.)

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Levels rise as numbers glow
XP lines trace the points they earn
Badges frame each player’s rank
A crown marks Legend at the top
Game results reveal their gains
Quiet bars settle into place}

_{Comment @coderabbitai help to get the list of available commands.}

[evanpelle]

Reviewed at 23be312 and cross-checked against the backend on infra progression-phase1. Nothing blocking in the client. There is one rollout issue that sits mostly in infra but shows up here.

What checks out

• Contract matches field for field for /users/@me progress, /users/@me/xp/:gameId, /public/player/:publicId/progress and /public/progression/config.
  • lifetimeXp is sent as a number, so there's no bigint-as-string issue.
  • levelsReached is always present.
  • The XP route uses bearer auth, and the public routes need none.
• Level values come from the server. The client only reads xpInLevel/xpForNext and never recomputes the curve.
• Constants match: MAX_LEVEL 100, MAX_PRESTIGE 10 and the 1500/1300/1200 subscriber tiers all match ProgressionConfig and the seed migration.
• No XSS: there's no unsafeHTML/innerHTML, and usernames still go through usernameText.
• i18n: every key is in en.json, including the progression.multiplier_* keys built at runtime.
• Async handling: the death and win updateXp calls can't double-poll. GameStatsModal and PlayerProfileModal drop stale responses, and every void async call catches its errors.
• Checks: the full suite passes (7,410 tests, 1 skipped). tsc --noEmit and eslint on the changed files are clean.

Should fix before progression is enabled in production

1. Some games get no XP record, so the panel shows "Calculating XP…" for 60 s and then disappears.
   • When infra requires agreed stats, awardGameXp returns without writing anything unless record.info.statsAgreed === true (infra ProgressionIngest.ts:90).
   • Singleplayer never qualifies: archive_singleplayer_game/POST.ts:104 deletes info.statsAgreed, so singleplayer XP never gets a record. The daily cap and the 0.25× rule can't apply.
   • Multiplayer may not either: I couldn't find a game-server change that writes statsAgreed into the archived record. GameServer.ts only logs the agreement.
   • What the client does: WinModal polls a 404 every 3 s for 60 s, then silently removes the panel.
   • Suggested fix: infra writes an ineligible xp_events row in this case (for example reason: "unverified", which this client already shows as the generic line), or the client skips polling for singleplayer. Either way, statsAgreed needs to reach the archive before that mode is turned on.

Nits
2. The reveal can play unseen. If the player dismisses the modal while it's still calculating, the panel stays in the DOM, hidden by CSS (WinModal.ts:81). The reveal then plays where nobody sees it, and there's no way back to the modal after Keep Playing or Spectate. Start the reveal only while the modal is visible, or show the final state on the next show().
3. The panel can get stuck half-revealed. GameXpPanel.disconnectedCallback clears its timers but leaves reveal set. A panel that is removed and re-added would then stay half-revealed with aria-busy=true. Nothing removes it today, but this.reveal = null is a cheap guard.
4. pollGameXp ignores its abort signal (ProgressionApi.ts:82). It doesn't pass the signal to the fetch, so a request already in flight runs for up to 10 s after the abort. Combining the signals with AbortSignal.any fixes that.
5. Possible: older XP rows won't parse. played was added in XP config v2. If any xp_events rows were written under v1 (staging?), XpBreakdownSchema (ApiSchemas.ts:135) rejects them and the panel or past-game summary stays hidden. Either .default(0) on the line fields or purging v1 rows would handle it.
6. Your own profile can be out of date. PlayerProfileModal.ts:272 uses the /users/@me cache from page load, so it falls behind after games played in the same session. (Dropping xpInLevel/xpForNext from PublicProgressSchema is fine here, since #5734 adds them.)
7. Dead code and scope:

• xpBar's animate and durationMs options (XpBar.ts:28-30) are never used.
• The MILESTONE_LEVELS comment (Progression.ts:43) mentions a share button that doesn't exist.
• Both WinModal and GameXpPanel inject large <style> blocks on every render. GameXpPanel's are about 300 lines of keyframes, and moving them to a stylesheet would cut that file by roughly a third.
• The WinModal button restyle is outside this PR's scope. It also swaps o-button's translationKey for a one-off translateText call.

8. a11y: the nav level badge sits inside the account button, whose aria-label overrides it, so screen readers never hear the level.

---

Generated by Claude Code

[Celant]

Coordinated review

Part of a batch for @Celant, reviewed against the backend side of the XP system. This PR's CI review was stale by 8 days — it predated the current head by a wide margin — so it has been re-run; this is an independent second pass.

Client/server XP rules are consistent, and notably this PR doesn't reimplement the formula at all — it renders what GET /users/@me/xp/:gameId returns and recomputes nothing. I checked field-for-field against the backend:

Rule	Match
Breakdown keys (leftEarly, played, time, placement, win, firstGame, feats, subtotal, gamePermille, subscriberPermille, total)	exact
Ineligible reasons (incl. before_progression)	exact; unknown → generic
Rounding (one step, one round)	correct
Tier multipliers (Sovereign 2000 / Warlord 1500 / Vanguard 1250)	exact
Reward reasons (level_up, level_milestone, prestige)	exact
progress shape incl. canPrestige	exact

The breakdown-key rename is correctly coordinated — nothing refers to a "first win" concept; the key is firstGame and the label reads "First game of the day".

The formula gate is N/A here — there's no provisional figure in this PR to gate. I confirmed the gate, the computeXp copy and the reference-case fixture all land in the follow-up provisional-xp branch, so nothing is missing at this layer. But finding 3 is a primitive introduced here that the follow-up inherits, and it's cheapest to fix at the root.

Division-by-zero, NaN and over-full-bar cases are all covered: levelFraction clamps (tested at levelFraction(500, 200) === 1) and xpProgressText returns "Max level" rather than dividing by zero. The backend also clamps xpInLevel to xpForNext now, so an over-full bar can't reach the client from these endpoints in the first place.

The renderStyles/renderActionStyles CSS blocks are a large share of the diff and were reviewed only for the reduced-motion fallbacks, which are present and complete. No generated data files.

8 finding(s): 1 high, 5 low, 2 medium

[github-actions]

🤖 Claude Code Review

Verdict: No issues found. 0 findings (0 high, 0 medium, 0 low).

Checked for bugs and CLAUDE.md compliance:

• Bugs: polling and abort handling, stale results, reveal timers, the progression maths and the schemas.
• CLAUDE.md: i18n and en.json keys, the homepage import chain and lazy modals, and layer boundaries.