Problem
A subscriber with usernameStatus: premium and username: null is entitled to a
custom verified username and is never told so. The only place to claim one is the
username panel inside the account modal, which they have no reason to open.
This matters most for players who acquired a subscription as part of something
else rather than by deliberately subscribing — they don't know they have the
perk, and the subscription is spending down while they don't know.
The verified-name toggle beside the username input already routes them correctly:
if (status === "premium" || status === "indefinite") {
// Subscribed but no usable name yet (never set, or TEMPORARY####):
window.location.hash = "modal=account";
return;
}But it renders in the same dim grey whether the player is ineligible (no
subscription) or eligible-but-unclaimed (one tap from their name), so nothing
signals that it does anything.
Proposed fix
Boot prompt. Main.ts already interrupts boot for a username problem — the
TEMPORARY#### rename — guarded by cleanHomepage so it never hijacks a join
link or a deep link, and already priority-ordered ahead of the rewards popup. The
never-claimed case is a sibling condition on that same branch:
premium && username === null, different copy, same deep-link into the account
modal. No new gate, no onboarding flow.
Pre-fill. Open the username panel pre-filled with the sanitised platform
persona where one exists (see #5088), and show availability before submit. The
friction that stops people claiming is thinking of a name, not tapping accept.
Checking before submit also matters because a successful claim starts a 30-day
rename cooldown, so getting it wrong is expensive. (Failed claims are free — the
transaction throws before usernameChangedAt is written.)
Handle the taken case as a normal path, not an error. Bare names collide
constantly for common handles. Offering base.1234 in the same screen as a
one-tap alternative requires the server-side fallback change tracked separately
in infra; without it a premium claim on a taken name is a 409 dead end.
Decay. The TEMPORARY#### prompt fires every clean boot because it is a broken
state. Never-claimed is not broken — it is a perk not yet taken. Fire once, then
fall back to a standing affordance: render the verified toggle in an "action
needed" state for premium-but-unclaimed players rather than the same dim grey
used for "no subscription".
Also needs deciding: first-boot modal ordering
A player who receives a subscription grant also receives signup-bonus rewards, so
the rewards popup and this prompt both want the screen on the same clean boot.
The existing branch resolves a two-way race with a bare return, deferring
rewards a boot. Adding a third contender to that should be sequenced
deliberately — suggested: username first, rewards immediately after in the same
session, rather than inheriting the return.
Problem
A subscriber with
usernameStatus: premiumandusername: nullis entitled to acustom verified username and is never told so. The only place to claim one is the
username panel inside the account modal, which they have no reason to open.
This matters most for players who acquired a subscription as part of something
else rather than by deliberately subscribing — they don't know they have the
perk, and the subscription is spending down while they don't know.
The verified-name toggle beside the username input already routes them correctly:
But it renders in the same dim grey whether the player is ineligible (no
subscription) or eligible-but-unclaimed (one tap from their name), so nothing
signals that it does anything.
Proposed fix
Boot prompt.
Main.tsalready interrupts boot for a username problem — theTEMPORARY####rename — guarded bycleanHomepageso it never hijacks a joinlink or a deep link, and already priority-ordered ahead of the rewards popup. The
never-claimed case is a sibling condition on that same branch:
premium && username === null, different copy, same deep-link into the accountmodal. No new gate, no onboarding flow.
Pre-fill. Open the username panel pre-filled with the sanitised platform
persona where one exists (see #5088), and show availability before submit. The
friction that stops people claiming is thinking of a name, not tapping accept.
Checking before submit also matters because a successful claim starts a 30-day
rename cooldown, so getting it wrong is expensive. (Failed claims are free — the
transaction throws before
usernameChangedAtis written.)Handle the taken case as a normal path, not an error. Bare names collide
constantly for common handles. Offering
base.1234in the same screen as aone-tap alternative requires the server-side fallback change tracked separately
in
infra; without it a premium claim on a taken name is a 409 dead end.Decay. The
TEMPORARY####prompt fires every clean boot because it is a brokenstate. Never-claimed is not broken — it is a perk not yet taken. Fire once, then
fall back to a standing affordance: render the verified toggle in an "action
needed" state for premium-but-unclaimed players rather than the same dim grey
used for "no subscription".
Also needs deciding: first-boot modal ordering
A player who receives a subscription grant also receives signup-bonus rewards, so
the rewards popup and this prompt both want the screen on the same clean boot.
The existing branch resolves a two-way race with a bare
return, deferringrewards a boot. Adding a third contender to that should be sequenced
deliberately — suggested: username first, rewards immediately after in the same
session, rather than inheriting the
return.