OpenRally

☐ ISC-01: User can sign up and sign in via Supabase Auth email + magic link

☐ ISC-02: Successful auth creates or updates a local `User` row keyed by Supabase `auth.uid`

☐ ISC-03: On first login, user sees a profile completion form (display name, playing hand, preferred side) and data is stored in `User` table

☐ ISC-04: User signs out cleanly; subsequent requests return 401 until re-authenticated

☐ ISC-05: `User.roles` defaults to `['player']` for every new user

☐ ISC-08: `/organizer/apply` page is accessible to any authenticated user and presents the TO application form

☐ ISC-09: Application form requires LINE ID, logo upload, and ToS agreement checkbox before submission

☐ ISC-10: Logo upload enforces 500×500 pixel output via a client-side square-aspect-ratio cropper

☐ ISC-11: Logo upload accepts PNG or JPG, rejects other formats, and caps upload size at 2 MB

☐ ISC-12: Uploaded logos land in the Supabase Storage `organizer-logos` bucket with RLS restricting writes to the uploading user

☐ ISC-13: Submitting an application creates an `OrganizerApplication` row with `status = 'submitted'` and stores optional fields (phone, WhatsApp, Instagram, website, Facebook, other social, reference) in `form_data` jsonb

☐ ISC-14: On submission, a "Application received" email is sent to the applicant via Resend in their active locale (TH or EN)

☐ ISC-15: `/admin/organizer-applications` is accessible only to users with the `admin` role

☐ ISC-16: Admin review page lists applications in a paginated list, newest first, with name + submitted date + status

☐ ISC-17: Admin can open an application detail view and see all form responses

☐ ISC-18: Admin Approve action transactionally adds `organizer` to `User.roles` and sets application status to `approved`

☐ ISC-19: Admin Approve action triggers the "Application approved" email via Resend with a link to create a first tournament

☐ ISC-20: Admin Reject action requires a non-empty reason text and sets application status to `rejected`

☐ ISC-21: Admin Reject action triggers the "Application rejected" email via Resend including the admin's reason

☐ ISC-22: Every Approve or Reject action writes an audit log row with user, timestamp, and the action taken

☐ ISC-23: A rejected applicant can reapply immediately (no cooldown in v1)

☐ ISC-24: Users with the `organizer` role see the "Create Tournament" CTA on their dashboard; users without it do not

☐ ISC-25: TO can create a new venue inline during tournament creation (name, city, court count, court names, address)

☐ ISC-26: Venues are reusable — TO can select a previously created venue when creating a new tournament

☐ ISC-27: OpenRally user search is called with a 300 ms debounce from the partner search UI

☐ ISC-28: User search is rate-limited to 30 requests per minute per user

☐ ISC-31: Organizer creates a tournament with fields: name, dates, venue, draw size, match format (best-of-1 / best-of-3), last-set scoring rule (full set / tiebreak / super tiebreak), 3rd-place match toggle, free-text level band, free-text entry info

☐ ISC-31a: New tournaments are created in `draft` status and are visible ONLY to the creating TO and OpenRally admins

☐ ISC-31b: Draft tournaments do NOT appear in the public tournament list or in any player's registration flow

☐ ISC-31c: TO transitions a tournament from `draft` to `registration_open` via an explicit "Publish tournament" action on the management hub or the dashboard draft card

☐ ISC-31d: Draw size input is a hybrid button group (`4 / 8 / 16 / 32 / 64`) plus a "Custom" option that reveals a numeric input

☐ ISC-32: Tournament format is `single_elim` only in v1 (no format picker needed — hardcoded)

☐ ISC-33: Organizer opens and closes the registration window via explicit actions

☐ ISC-34: Player browses the tournament list showing date, venue, format, and registration status

☐ ISC-35: Player registers solo with one click; registration auto-accepts until draw capacity is reached

☐ ISC-36: Player registers for doubles by searching OpenRally users and selecting a partner

☐ ISC-37: Partner receives an invite email via Resend with a magic-link confirmation URL

☐ ISC-38: Partner clicks the link, signs in via Supabase Auth (account auto-provisioned if needed), and sees an accept/decline prompt

☐ ISC-39: Partner accept transitions the doubles registration to confirmed; partner decline rolls back the solo half

☐ ISC-40: Registrations beyond draw capacity auto-transition to `waitlist` status

☐ ISC-41: Organizer can manually remove a registration or promote a waitlisted registration

☐ ISC-42: Solo registrants and confirmed doubles pairs receive a registration confirmation email via Resend

☐ ISC-42b: Waitlisted player receives an email notification when promoted to confirmed

☐ ISC-42c: Tournament pages have OpenGraph meta tags for rich link previews when shared on LINE/WhatsApp

☐ ISC-43: Organizer manually seeds single-elim players via drag-and-drop into seed slots

☐ ISC-44: Single-elim generator produces a bracket with correct bye placement — top seeds automatically receive first-round byes for non-power-of-2 draw sizes

☐ ISC-45: (Removed)

☐ ISC-46: Bracket view renders via `@g-loot/react-tournament-brackets` or an equivalent off-the-shelf library (not hand-rolled)

☐ ISC-47: (Removed)

☐ ISC-48: Organizer schedules each match to a specific court + time window

☐ ISC-49: Organizer regenerates the draw before publish without a permanent record of the discarded version

☐ ISC-50: Organizer publishes the draw via an explicit action; the draw becomes visible to registered players

☐ ISC-50b: "Draw published" email is sent to all registered players when the TO publishes the draw

☐ ISC-51: Post-publish edits (player swaps, withdrawals, schedule changes) are permitted until the tournament start date

☐ ISC-52: Every post-publish edit writes an audit log row with user, timestamp, and before/after snapshot

☐ ISC-53: TO can start a tournament, transitioning it to `live` state

☐ ISC-53b: Match status transitions: `upcoming` → `in_progress` → `completed`

☐ ISC-53c: TO can enter per-set scores for any match (e.g. 6-4, 7-5, 10-8)

☐ ISC-53d: Last set scoring follows the tournament's configured rule (full set / tiebreak / super tiebreak)

☐ ISC-53e: Score validation enforces valid padel/tennis scoring rules

☐ ISC-53f: On match completion, winner auto-advances to the next bracket slot via Edge Function

☐ ISC-53g: Supabase Realtime broadcasts bracket updates on channel `tournament:{id}:bracket`

☐ ISC-53h: All connected clients see bracket updates within 1s p95 under 100 concurrent viewers

☐ ISC-53i: TO can mark a walkover (no scores, opponent advances) or retirement (partial scores recorded, opponent advances)

☐ ISC-53j: Tournament auto-completes when the final match is scored

☐ ISC-53k: Every score entry/edit writes an audit log row

☐ ISC-54: Placements auto-derived from bracket (1st = winner, 2nd = finalist, 3rd/4th = semi-finalists)

☐ ISC-55: TO can manually override auto-derived placements (audit-logged)

☐ ISC-56: Players see final placements on the public tournament page after the event

☐ ISC-57: Spectator mode (`?spectator=true`) hides navigation, enlarges bracket, auto-refreshes via Realtime

☐ ISC-58: "My next match" card is visible on the player's tournament page showing court, time, opponent, round

☐ ISC-59: "My next match" updates when bracket progresses (previous-round opponent decided)

☐ ISC-60: TO can cancel a tournament — all registered players receive cancellation email, registrations voided

☐ ISC-62: Adding a new locale requires only a new JSON bundle + a locale registration row, zero code changes elsewhere

☐ ISC-63: Every user-scoped DB table has RLS policies enforced and covered by at least one integration test

☐ ISC-64: Next.js lint and `tsc --noEmit` report zero warnings in CI

☐ ISC-65: Deno lint reports zero warnings on Edge Functions in CI

☐ ISC-66: Bracket view renders in <300 ms p95 on a mid-range phone browser

☐ ISC-67: Web LCP is <2.5 s p95 on 4G

☐ ISC-68: Realtime bracket updates propagate to all subscribed clients within 1s p95 under 100 concurrent viewers

☐ ISC-69: WCAG 2.1 AA accessibility smoke test passes on the registration flow, bracket view, admin review page, and TO application form

☐ ISC-70: Full end-to-end simulation (sign up → TO apply → admin approve → create tournament → register solo + doubles → draw → start → TO scores all matches → bracket completes → placements visible → spectator mode verified) passes in staging with zero blocker defects before v1 launch

☐ AR-01: Do NOT build OpenRally's own rating algorithm, ever (we integrate with an external provider — in v3)

☐ AR-02: Do NOT build any rating UX in v1 — no rating display, no rating-based seeding, no rating leaderboard, no rating history. All rating work is v3.

☐ AR-03: Do NOT build a Flutter mobile app — OpenRally is a responsive web product. TPS is the mobile surface for players.

☐ AR-04: Do NOT build entry fee payment collection in v1 — no Stripe integration, no Omise integration, no checkout flow. TOs collect fees offline.

☐ AR-05: Do NOT build player-mode or referee-mode scoring in v1 — only TO can enter scores. Player scoring + dispute flow arrives in v2. Referee mode arrives in v7.

☐ AR-06: Supabase Realtime in v1 is scoped to the bracket update channel only (`tournament:{id}:bracket`). Do NOT add other Realtime channels in v1.

☐ AR-06b: Do NOT build any tournament format other than single-elimination in v1.

☐ AR-07: Do NOT build referee or official features in v1

☐ AR-08: Do NOT build federation sanctioning UI in v1

☐ AR-09: Do NOT support tournament formats other than single elimination in v1. Double elim is v2; round robin + groups+KO is v4.

☐ AR-10: Do NOT support sports other than padel

☐ AR-11: Do NOT build court reservation (TPS owns this domain)

☐ AR-12: Do NOT build coach/lesson booking (TPS owns this domain)

☐ AR-13: Do NOT merge the OpenRally codebase into the TPS codebase

☐ AR-14: Do NOT bypass Supabase RLS from any client

☐ AR-15: (Removed — OpenRally has no Flutter code)

☐ AR-16: Do NOT build livestream video in v1 or v2

☐ AR-17: Do NOT commit secrets, `.env` files, or service role keys

☐ AR-18: Do NOT skip pre-commit linter runs

☐ AR-19: Do NOT merge a PR without both Lead Engineer and Security Engineer approval

☐ AR-20: DO ship the full entity schema from §9.1 in v1 — including empty tables for Payment, Score, RatingPush, Sanctioning

☐ AR-21: DO define the `RatingProvider` and `PaymentProvider` interfaces as TypeScript types in v1, even though no concrete adapters exist

☐ AR-22: DO ship a `Sport` table with padel as the first row, not a constant enum — v2 sports are data, not code changes

☐ AR-23: DO model user roles as data, not constants — v2 referee/federation/admin roles are role-rows, not schema changes

☐ AR-24: DO use the `{amount_minor, currency_code}` Money shape on any fee-related column from v1, even though no money flows in v1

☐ AR-25: DO emit domain events (`tournament.published`, `registration.confirmed`) from v1 even if no subscriber exists yet — v2 features subscribe without touching the emitter

☐ AR-26: DO NOT use `if country == X` conditionals anywhere in code (even for non-payment country-specific logic) — country behavior lives in config tables

☐ AR-27: DO ship all user-visible strings as i18n keys from day one, never hardcoded — adding a new locale in v2 is a bundle file, not a code change