メンバー一覧を「チャンネルに権限のある全員表示」に改め、匿名デフォルト名と参加認知モーダルをセットで導入する案。
コース受講で自動参加する現行モデルは変えない。
メンバー一覧を「各チャンネルにアクセス権のあるメンバーは全員表示」に変更する。
それを安全に行うために、下記①〜⑤をセットで導入する（①だけ先行すると問題2が悪化するため分離不可）。
| 項目 | 現状 | 変更後 | 解消する問題 |
|---|---|---|---|
| 一覧に出る人受講生視点 | 表示名を設定した受講生＋講師＋自分のみ | チャンネルに権限のある全員（未設定者は匿名IDで表示） | 問題1 |
| 人数カウント | channel_members_count は全員を数える定義で一覧と食い違う（現UIは合計未表示のため露見していない） | カウント定義を「権限があり一度でも開いた人」に統一し、一覧＋畳み行と常に一致させる。 @channel / @here の送信前ダイアログに出す人数はこれとは別の「通知対象数」（05 参照） |
問題1 |
| メンション候補受講生視点 | 表示名を設定した受講生しか候補に出ない | 権限のある全員が候補に出る（匿名IDで挿入） | 問題1 |
| メンバー詳細の取得 | 表示名未設定の相手は取得できない（404） | 匿名IDのプロフィールとして取得できる | 問題1 |
| 名前の表示 | display_name があればそれを表示し、無ければ name にフォールバック（本名・メールが露出しうる）。メール形式の display_name もそのまま表示する | display_name（メール形式を除く）があればそれを表示し、無ければ匿名ID。本名・メールに依存しないフォールバックにする | 問題2 |
| 参加の認知 | なし（受講と同時に無通知でメンバー化） | 参加認知モーダル（表示名未設定の間は1日1回）＋未設定の間の常設導線 | 問題3 |
| メンションの解決今回は解消しない | 本文の @表示名 を文字列一致で解決している | 変更しない。既存の重複表示名と、表示名変更前に書かれた過去メッセージでは曖昧性が残る（05 参照） | 将来対応 |
確認するのは2つ。いつ・何が起きるか（下の4ステップ）と、誰にどのモーダルが出るか（出し分け表）。実装の詳細は 05 実装・仕様メモ に分けてある。
community_last_opened_at に記録する| 対象 | いつ出るか | 見出し | 内容の重心 |
|---|---|---|---|
| 1新規メンバー | コミュニティ初回オープン時 | 「◯◯のコミュニティへようこそ」 | 参加の認知（どこに・なぜ参加しているか）＋見え方＋表示名設定 |
| 2既存・表示名 未設定 | リリース後、次に開いた時 | 「名前の表示方法が変わりました」 | 表示ポリシー変更の告知。「ようこそ」は使わない（すでに使っている人に不自然なため） |
| 3既存・表示名 設定済みメール形式でない | 出さない | — | 見え方が変わらないため告知しない。変更したくなったら常設導線から設定する |
| 4既存・メール表示名手入力のメール形式 | リリース後、次に開いた時 | パターン2 と同じ＋注意文 | パターン2 に加えて「メールアドレスは表示名として使えなくなった」ことを明示。登録メールと同一だった人は migration で NULL 化されパターン2 に入る |
| 52日目以降のリマインド1・2・4 を閉じて未設定のまま | 翌日以降、その日の最初のオープン（1日1回） | 「表示名を設定しませんか」 | 告知は繰り返さず設定を促すだけに絞る。設定した時点で出なくなる |
| 相手の状態 | 受講生視点 | 講師視点admin（全受講生）／staff（担当コース内） | 講師視点staff（担当コース外） |
|---|---|---|---|
| display_name 設定済みメールを含まない | ✓メンバー一覧・メンションとも display_name | ✓display_name ＋ account.name・user.email を併記（一覧・メンション候補とも） | ✓display_name のみ（受講生と同じ・併記なし） |
| display_name 設定済みメールを含む（手入力） | ✓匿名ID（display_name は表示しない＝露出解消） | ✓匿名ID ＋ account.name・user.email を併記 ＋「メール表示名」チップ | ✓匿名ID のみ（受講生と同じ・併記なし） |
| display_name 未設定 | ✓匿名ID | ✓匿名ID ＋ account.name・user.email を併記 ＋「未設定」チップ | ✓匿名ID のみ（受講生と同じ・併記なし） |
01〜03 で決めた方針を、実装時に迷わない粒度まで落としたもの。テーマごとに分けてあるので、必要なところだけ読めば足りる。
匿名IDをどう作るか。保存時に何を弾くか（@ 混入・重複・予約語）と、その判定方法。
メンバー0009ix）Account#display_name / EnterpriseManager#display_name とも長さ（最大100）のみ。一意制約も unique index も無いremediation: FIX_INPUT）で返し、フロントはフォーム inline に出す（toast にしない）accounts）と講師（enterprise_managers）は同じ名前空間で見る（同じ一覧に並ぶうえ、講師へのなりすましが最も影響が大きいため）accounts と enterprise_managers の2テーブル横断で、比較も正規化キーのため、単一の unique index では表現できない誰が一覧に出るか・出ないか。02 の対応表を実装レベルで補足する。
03 のフローを支える新設カラムと判定ロジック。
chat_reads / chats を一覧クエリで JOIN する案は不採用（ROM 専の受講生を未利用扱いにする・JOIN と index が重い）chat_reads.updated_at の MAX 等から一括 backfill。値があれば既存 / NULL のままなら新規として、モーダル出し分けの判定にも使うcommunity_last_opened_at の日付 ≠ 今日 で判定できる（専用カラムは増やさない）誰に併記するか（admin / staff）と、どこに出すか。
Enterprise#staffs(courses) と同じ関係）許容する残課題と、その根本解決をどこに置くか。
<@ID>）、表示時に現在の表示名へ解決する方式。表示名の変更にも追随できる