参加モデルの再設計 (チーム招待 / ゲスト参加)

「チームの招待」と「大会の参加枠」が絡んで分かりにくくなっている問題を解きほぐし、 目標モデルと段階移行をまとめる。

現状の絡み

メンバーシップに相当する概念が 2 系統あり、互いに無関係に並走している。

概念	実体	性質
チーム名簿	team_members	永続。チームに紐づく。大会をまたぐ
大会の参加枠	registration_invites(fillKind: invite/direct/placeholder、status: open/filled/…)	大会(registration)単位。join URL で 1 枠ずつ埋める

参加 URL (/join/[joinToken]) は 1 registration に 1 本で、開いた人が 会員ログイン / 新規作成 / ゲストの 3 択で枠を埋める。

問題点

• 既存チームで申し込んでも、名簿(例: 10 人いる)を使わず大会ごとに URL で招待し直す
• registration.memberCount が「ちょうど N 枠」を強制し、人数入力に意味がないのに縛りになる
• 「チーム招待」と「大会のゲスト参加」が 1 本の URL に混在して分かりにくい

目標モデル

チーム名簿を真実の源にし、URL はゲスト参加専用にする。

• チーム(名簿)= メンバーシップ。 会員 / 新規登録の人はチームに招待して team_members に入れる(大会非依存・永続)
• 大会申込 = チームが出る。 参加者は名簿から選ぶ(人数入力なし・上限なし)
• ゲスト = ニックネーム参加(アカウントなし)。 その大会限り。URL の出番はこれだけ。 確認 URL は大会終了 +7 日(既存設計を踏襲)
• 旧 join URL の 3 択は 2 系統に分割:
  • チーム招待 URL(会員 / 新規)→ team_members に加入
  • ゲスト参加 URL(大会単位)→ ニックネームのみ
• memberCount は カラムだけ残す(入力・上限・満員判定には使わない。実参加人数の目安表示)
• tournament.capacity(チーム数の枠)は別物として維持(availability の上限)

   チーム招待URL ──会員/新規──▶  team_members (名簿・永続)
                                      │
   大会申込 ───────────────────────┤ 名簿から参加者を選ぶ (上限なし)
                                      │
   ゲスト参加URL ──ニックネーム──▶  guest (その大会限り・名簿に入らない)

段階移行

1. A: 人数枠の制約撤廃(contained)
   • TeamRegistrationDraftInputSchema の invites.length === memberCount 一致チェック(superRefine)を撤廃
   • join.ts の「残り枠 0 → 満員(URL 無効)」を撤廃し URL を開いたままに
   • 申込フォームの人数入力を任意化
   • tournament.capacity は維持
2. チーム招待フロー新設 + join 再編
   • 名簿への招待 URL(会員 / 新規 → team_members、大会非依存)を新設
   • join の 3 択を「チーム招待 / ゲスト」の 2 系統に再編
   • registration_invites のメンバー枠用途を縮小し、ゲスト枠中心に
3. 申込を名簿ベースに
   • 申込フォームを「名簿から参加メンバー選択 + ゲスト追加」に
   • registration の参加者表現を名簿参照ベースに整理

影響範囲(調査メモ)

• registration_invites (fillKind/status)、join.ts、/join/[joinToken](3択)
• team_members、teams、チーム詳細 (/mypage/teams/[id])
• ゲスト: guest_view_token、/guest/[guestViewToken]、member-link-requests(ゲスト→会員紐付け)
• memberCount 参照箇所(表示・集計)