feat(invites): ADR-0011 Phase 2B — claim resolution + athlete routes + auth

[theianjones]

Summary

Stacked on top of #418 (Phase 2A). Adds the athlete-facing claim flow: token resolution, identity-match, the three routes the email link points at, and ?invite=<token>&email=<email> support on sign-in / sign-up.

Flow (mike@wodsmith.com seeded pending invite)

1. Athlete clicks /compete/2026-wodsmith-invitational/claim/<token>.
2. Loader calls getInviteByTokenFn — hashes the token, looks up the row on claim_token_hash, verifies championship slug matches, checks claimability, resolves the target division label + whether a WODsmith account exists for the invited email.
3. Loader runs identityMatch(context.session, invite, { accountExistsForInviteEmail }) and branches:
   • Signed in as the invite email → render pre-attached registration CTA (hands off to existing /compete/$slug/register flow; sub-arc C wires the inviteToken param end-to-end through Stripe).
   • Signed in as a different email → render "this invite is for a different account" page, link to sign out + sign in as the invited email.
   • Signed out, account exists → redirect to /sign-in?redirect=<claim-url>&email=<invite.email>&invite=<token>.
   • Signed out, no account → redirect to /sign-up?redirect=<claim-url>&email=<invite.email>&invite=<token>.
4. After sign-in/sign-up, the redirect param lands the user back on the claim URL; the loader re-runs against the new session cookie and resolves to the happy path.

What changed

• src/server/competition-invites/claim.ts — resolveInviteByToken, assertInviteClaimable (distinct reason per terminal state), identityMatch (pure, case-insensitive).
• src/server/competition-invites/decline.ts — atomic pending → declined transition. Nulls activeMarker + claimTokenHash so the link dies immediately and a re-invite is unblocked.
• src/server-fns/competition-invite-fns.ts:
  • getInviteByTokenFn — public (session-free) server fn used by the claim loader. Returns a discriminated union so the loader branches once.
  • declineInviteFn — authenticated. Re-runs resolve + identity-match on the server so a forged POST can't bypass the email-lock.
• Routes:
  • /compete/$slug/claim/$token.tsx — claim landing.
  • /compete/$slug/claim/$token/decline.tsx — decline confirmation.
  • /compete/$slug/invite-pending.tsx — wrong-account recovery landing.
• /sign-in + /sign-up — ?email=&invite= search params; when invite is present the email field is pre-filled and locked.
• 14 new unit tests covering claimability reasons, identity-match cases, and case-insensitive email comparison (64 total Phase 2 tests).
• lat.md/competition-invites.md — Claim resolution, Claim routes, Auth route extensions sections.

Design notes

• Why ?invite=<token> and not ?claim=<token>? The existing claim param is wired to validateClaimTokenFn, which reads a plaintext KV entry (claim-token:{token}) pointing at an existing placeholder users row. Invite tokens are hashed at DB and the user account may not exist yet. Overloading claim would muddy both flows; a fresh param keeps the two lookup mechanisms cleanly separate.
• Email verification: Sub-arc B does not auto-verify email on an invite-flow sign-up. If Ryan signs up via an invite link, he still gets the "check your email" step. Reasonable extension for a follow-up PR: pass inviteToken to signUpFn and auto-verify when a valid hash resolves — similar to the KV-backed placeholder path.
• No status transition on claim click. Per ADR-0011, the invite stays pending through the Stripe-in-flight window. The actual flip to accepted_paid lands in sub-arc C when the Stripe workflow reads inviteId from purchase metadata.

Test plan

• pnpm test -- test/server/competition-invites test/lib/competition-invites — 64 green
• pnpm type-check clean
• pnpm dev with seeded DB — click /compete/2026-wodsmith-invitational/claim/seed-invite-mike-pending-men-rx-phase2:
  • Signed in as mike@wodsmith.com → claim CTA page
  • Signed in as another account → wrong-account page
  • Signed out → redirects to /sign-in?email=mike@wodsmith.com&invite=…; email field pre-filled and disabled
• Click decline on the claim page → confirmation → row flips to declined, activeMarker = NULL, claim_token_hash = NULL; subsequent clicks of the original URL show "invite declined"
• Token for a different competition (mispaste) → generic "invalid link" page, no leak

🤖 Generated with Claude Code

• main
  • feat(invites): ADR-0011 Phase 2A — schema, tokens, issue + bespoke helpers #418
    • feat(invites): ADR-0011 Phase 2B — claim resolution + athlete routes + auth 👈
      • feat(invites): ADR-0011 Phase 2C — send pipeline + Stripe workflow + queue #420
        • feat(invites): ADR-0011 Phase 2D — organizer UI, claim→register, expiry sweep #421

---

Summary by cubic

Adds the athlete-facing invite claim and decline flow with secure token resolution and email-locked identity. Also forwards the invited division to registration and tightens token handling for safer links.

• New Features

  • Routes: /compete/$slug/claim/$token, /compete/$slug/claim/$token/decline, /compete/$slug/invite-pending.
  • Server fns: getInviteByTokenFn (slug-checked token resolve) and declineInviteFn (revalidates identity; transitions pending → declined and deactivates link).
  • Auth: /sign-in and /sign-up accept ?invite and ?email; the email field is prefilled and locked only when both are present.
  • Registration handoff: claim CTA now forwards divisionId; /compete/$slug/register accepts ?invite and ?divisionId for preselecting the invited division (Phase 2D will wire invite through payment).
  • 14 new unit tests; docs updated for claim resolution, routes, and auth params.

• Bug Fixes

  • Split pure helpers into src/server/competition-invites/identity.ts (re-exported from claim.ts) so client routes don’t pull getDb; fixes Vite bundling crash.
  • resolveInviteByToken now also requires activeMarker = "active" (defense-in-depth against stale tokens).

^{Written for commit dd5fa64. Summary will update on new commits.}

[coderabbitai]

Warning

Rate limit exceeded

@theianjones has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 21 minutes and 29 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 21 minutes and 29 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 9c238fb3-69a6-4aa1-aaa1-6ae36bb985c8

📥 Commits

Reviewing files that changed from the base of the PR and between 90c4381 and dd5fa64.

📒 Files selected for processing (13)

• apps/wodsmith-start/src/routeTree.gen.ts
• apps/wodsmith-start/src/routes/_auth/sign-in.tsx
• apps/wodsmith-start/src/routes/_auth/sign-up.tsx
• apps/wodsmith-start/src/routes/compete/$slug/claim/$token.tsx
• apps/wodsmith-start/src/routes/compete/$slug/claim/$token/decline.tsx
• apps/wodsmith-start/src/routes/compete/$slug/invite-pending.tsx
• apps/wodsmith-start/src/routes/compete/$slug/register.tsx
• apps/wodsmith-start/src/server-fns/competition-invite-fns.ts
• apps/wodsmith-start/src/server/competition-invites/claim.ts
• apps/wodsmith-start/src/server/competition-invites/decline.ts
• apps/wodsmith-start/src/server/competition-invites/identity.ts
• apps/wodsmith-start/test/server/competition-invites/claim.test.ts
• lat.md/competition-invites.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/competition-invites-phase-2-claim

---

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

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

[cubic-dev-ai]

4 issues found across 11 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/wodsmith-start/src/routes/_auth/sign-in.tsx">

<violation number="1" location="apps/wodsmith-start/src/routes/_auth/sign-in.tsx:78">
P2: Don’t lock invite flow when the invite email is missing; it can disable the email field while leaving it empty, blocking sign-in.</violation>
</file>

<file name="apps/wodsmith-start/src/routes/_auth/sign-up.tsx">

<violation number="1" location="apps/wodsmith-start/src/routes/_auth/sign-up.tsx:121">
P1: Invite mode is activated without requiring an invite email, which can lock the email field empty and make sign-up impossible.</violation>
</file>

<file name="apps/wodsmith-start/src/server/competition-invites/claim.ts">

<violation number="1" location="apps/wodsmith-start/src/server/competition-invites/claim.ts:97">
P2: `resolveInviteByToken` is missing the `activeMarker = active` predicate, so stale terminal rows with a leftover token hash can still resolve.</violation>
</file>

<file name="apps/wodsmith-start/src/routes/compete/$slug/claim/$token.tsx">

<violation number="1" location="apps/wodsmith-start/src/routes/compete/$slug/claim/$token.tsx:158">
P1: The claim CTA drops the resolved invite `divisionId`, so the registration step is no longer tied to the invited division.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}